Re: New 2822upd-04 - obs-NO-WS-CTL

On 1/16/08 at 12:37 PM +0000, Charles Lindsey wrote:

>In <p06250100c3b2cdde7d7b@[74.134.5.163]> Pete Resnick 
><[email protected]> writes:
>
>A couple of typos:
>
>In 2.2 s/ unfolding"/ "unfolding"/
>
>In 3.2.2, %d42-91 appears to have got omitted from <ctext>.

Good catch! Don't know how I missed those.

>This is a good time to ask how long it is intended that the 
>obs-syntax should remain in the standard. One hopes that it will no 
>longer be a REQUIREMENT to recognize it in 1000 years time, but 
>maybe some earlier deadline might be in order.
>
>How burdensome is it to have to recognize this ancient stuff? I 
>suspect that NUL and naked CR and LF are the bits that cause the 
>most problem - the rest is probably easier. So one might like to 
>remove the NUL and naked CR and LF sooner rather than later. For 
>sure, there should no longer be a need to recognize ANY obs-stuff 
>coming off the wire, even today. We are concerned only with ancient 
>emails that are still in people's archives.

A few things on this point (and I believe we've had this discussion 
multiple times before):

1. What would an implementation do, in the face of a bare CR, LF, or 
NUL, if the specification did not have this stuff in the obs- syntax? 
As it currently says:

       Note: This section identifies syntactic forms that any
       implementation MUST reasonably interpret.  However, there are
       certainly Internet messages which do not conform to even the
       additional syntax given in this section.  The fact that a
       particular form does not appear in any section of this document is
       not justification for computer programs to crash or for malformed
       data to be irretrievably lost by any implementation.  It is up to
       the implementation to deal with messages robustly.

The reason that bare CR, LF, and NUL are in there is because these 
things have cropped up in messages over the years and implementations 
may need to deal with them. It's fair warning to have these 
constructs in the spec.

2. I find the whole concept of deadlines in protocol specifications 
silly. If we say, "you MUST accept bare LF until January 1, 2010 at 
12:00:00 UTC, at which point you MAY", what have we accomplished? If, 
by any particular date, we find that it is unreasonable to ask 
implementations to do any particular thing, we change the spec at 
that time.

I strongly object to protocol specifications trying to impose 
deadlines on implementations. Write an Informational RFC with 
prognostications if so desired.

>A. I see that <quoted-pair> is still present in <dcontent>...
>
>B. As regards the use of SP after the ':' in header fields...

I did not see support on the list for either of your positions on 
these. In fact, the only response to your Sept. 20 message on B was 
an objection by Frank to doing what you said. Cite some support for 
either of these positions if you would.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102