Re: New 2822upd-04 - obs-NO-WS-CTL
"Charles Lindsey" <[email protected]>
| Newsgroups | gmane.ietf.rfc822 |
|---|---|
| Message-ID | <[email protected]> |
In <p0625010ec3b3f0926679@[74.134.5.163]> Pete Resnick <[email protected]> writes: >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 >that time. 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 >these. 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: [email protected] 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