Re: draft-resnick-2822upd-02 and Netnews
Russ Allbery <[email protected]>
| Newsgroups | gmane.ietf.rfc822 |
|---|---|
| Organization | The Eyrie |
| Message-ID | <[email protected]> |
Pete Resnick <[email protected]> writes: > Also, Charles alone does not rough consensus make. If there are others > who strongly feel that these changes should be made (and strongly would > be good; we're trying to push this along through the standards track, > and changes at this point would be less than desirable), please speak up > and indicate why the current specification does "the wrong thing". I strongly agree with the message ID changes, and agree in general with the rest (although not as strongly). The space after colon may warrant a SHOULD rather than a MUST, though, following your point about being very serious about the RFC 2119 definitions. (It's truly a MUST in netnews for interoperability reasons -- headers without a space after a colon won't work at all with most common implementations since RFC 1036 has always required the space -- but that doesn't necessarily mean it is in e-mail as well.) > Again, potentially breaking some netnews implementations is not by > itself a reason to remove this IMO. Are there known non-netnews > implementations that break because of this? (And why are netnews > implementations so non-robust in the first place, unable to parse > comments and quoted-pairs?) RFC 1036 doesn't mention comments in the References header, and while RFC 1036 references RFC 822 as well, when there's no real use of comments in References and no netnews implementation has ever generated them, it's not particularly suprising to me that few netnews implementations have ever bothered to expect them and strip them. Netnews has been using References in a structured and protocol-significant fashion for a lot longer than e-mail. As for quoted-pairs in message IDs, message ID parsing is at the heart of the critical path of a netnews server and a typical high-performance server matches message IDs hundreds or thousands of times a second. Simplification of this code path both has a leveraged effect on performance since it's in the heart of the processing loop (not that this sort of parsing is the performance-critical operation, but everything adds up) and makes the core of a server more robust. Properly parsing all the bizarre bits allowed in historic mail message IDs is kind of nuts, and since RFC 1036, netnews has always required a more restrictive syntax for the field. Message ID is far, far more important in netnews than it has been historically in e-mail. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>