In <p0625010ec3b3f0926679(_at_)[74(_dot_)134(_dot_)5(_dot_)163]> Pete Resnick
On 1/16/08 at 12:37 PM +0000, Charles Lindsey wrote:
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.
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.
OK, both you and Ned have stated that bare CR, LF, and NUL have indeed
been seen in Real World messages in the past, and that is a sufficient
answer to my point. And Ned claims that recognizing some of the more
obscure forms of addr-spec is more troublesome that dealing with CR, LF
and NUL (though I suspect that just accepting and displaying anything
printable with an '@' in the middle would suffice for software whose only
purpose when faced with obs-stuff was to display it legibly - i.e. nobody
expects replies to such obs-addresses to work).
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
But I suggested no such thing. There is a lot of space between forbidding
it after January 1, 2010 and expecting it still to be working after 1000
years. I.e. we should be anticipating that some future standard (probably
well after 2010) may well decide that the time has come to ditch it.
And, actually, what I would like to see at the moment (and I think this
would be safe as of now) is that one could assume that obs-syntax would
not be seen coming off the wire, and hence that recognizing it should only
be required of MUAs for the purposes of displaying legacy messages, and
hence there should be no requirement for current MTAs to accept it.
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
That is because there are only three (maybe four) people on this list who
are looking at this draft from the interoperability with Netnews POV.
As regards A, nothing useful is served by retaining those <quoted-pairs>,
certainly not in <msg-id>s. And <msg-id>s are hardly of use in the email
environment, except for threading using References, whereas they are
fundamental to the operation of Netnews.
And Frank, as well as myself, has consistently supported their removal
(and has just repeated his support in this thread).
... 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.
No, Frank agreed with what I wanted to do, but suggested an alternative
wording. Here is the full exchange, including my reply to Frank:
| Although in all header fields the CFWS following the colon is
| optional, it is customary to place at least one SP there; moreover
| such a SP is mandatory in some related protocols (notably [NETNEWS]).
| In order to facilitate interoperability with such related protocols,
| that SP SHOULD normally be present.
I'd put it slightly different, AFAIK Netnews is the only case where
that's necessary, and structured header fields defined outside of
2822upd tend to use [FWS] instead of [CFWS] after the colon. And
unstructured header fields like Subject: also use [FWS]. What I get is:
| Although all message header fields allow either [FWS] or [CFWS]
| after the colon, it is customary to place at least one white space
| character after the colon. In NetNews articles [RFC xxxx] it's
| mandatory to use a space character after the colon, and in order
| to faciliate interoperability implementors might wish to separate
| the header field name plus colon from the header field body by a
| space in all Internet messages.
I don't think there is any serious difference between our two wordings
(except that I would still prefer "SHOULD" to "might"). As to other
protocols than Netnews that might be affected, I don't know of any, but
thought it might be useful to allow for the possibility.
There are two diffenences in Frank's text:
i) "might wish to" vs "SHOULD". Breaking a "SHOULD" is not a crime, but
should only be done with full knowledge of the consequences (e.g. in a
special-purpose script where it is clear that Netnews will never become
involved). But if people still want something weaker than "SHOULD", then I
would accept that as better than nothing.
ii) Although Netnews is the only case we know of which would be affected,
I wanted to allow for the possibility there might be others. Hence my
wording "some related protocols (notably [NETNEWS])".
But if we can agree that a wording of some form along the lines of what I
and Frank are suggesting, then the exact wording can be worked on by
further discussion. As I said, either wording is netter than nothing.
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave,
CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5