On 1/16/08 at 12:37 PM +0000, Charles Lindsey wrote:
In <p06250100c3b2cdde7d7b(_at_)[74(_dot_)134(_dot_)5(_dot_)163]> Pete Resnick
<presnick(_at_)qualcomm(_dot_)com> 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