Re: 2822upd-06 submitted
"Frank Ellermann" <[email protected]>
| Newsgroups | gmane.ietf.rfc822 |
|---|---|
| Organization | <http://purl.net/xyzzy> |
| Message-ID | <[email protected]> |
Pete Resnick wrote: [quotes rearranged] >>---- Last Call now ? > Tony? I'm all for it. Catch that runaway 2821bis, and maybe even Usefor. Both are not directly affected by the fine prine print of <obs-NO-WS-CTL> in <obs-dtext>. They have their own ways of saying "no obs" or "no CTL". [routes] > Which flatly disagreed with 822 on this point: Yes, and my point was that this was always wrong in the RFC 822 syntax. If you think that serial commas work as expected in a route it is fine, but "something" has to trim them for SMTP. And we are talking about "something" that ignores several SHOULD NOT in 2821bis and 2822upd. I have no idea what happens if serial commas end up in SMTP paths, stricty speaking this is a syntax error. > it was always the case that things which generated > 821 commands from 822 headers had to do all sorts > of normalization. This one is no different. Maybe. But it is "within" the address (or actually the path), likely within angle brackets. Forgetting to trim serial commas is a plausible bug, the place where this might be rejected as SMTP syntax error can be far away. Normally I prefer to avoid such foreseeable trouble. Of course agents trying to use routes are already in so much trouble that nits are likely irrelevant :-) > text before the ABNF is always about syntax and the > text after the ABNF is always about semantics. See 3.1. ACK - I missed that editorial rule in 3.1 on page 10, its effect in 4.4 on page 33 is merely consistent. [obs-empty-list] > its only reason for existing is the obsolete form of > group lists. General, I love it if I can "see" an underlying concept directly in the ABNF. I consider "ABNF-beautification" as essential. RFC 822 never wanted to introduce ASCII art by serial commas, it is just a silly side effect of its #-rule. 2822upd reintroduces inadvertently lost parts of this #-rule. The first attempt <obs-commas> highlighted the aspect "this is some obsolete silliness with commas". But this didn't reflect the spirit of RFC 822, where the commas were only a side effect of its (liberal) #-rule. Therefore you fixed the syntax for obsolete non-empty lists, getting rid of <obs-commas> for non-empty lists. In a certain sense you still have <obs-commas> hidden in three cases of empty lists: <obs-group-list>, and in a part of the ABNF in <obs-bcc> plus <obs-resent-bcc>. There is no "group" in <obs-group-list>, in fact this is no "group list". It's only a consequence of deprecating serial commas, where you have to cover the pathological case of an empty list. And with <obs-empty-list> you could say it as it is: | group-list = mailbox-list / CFWS / obs-empty-list [...] | obs-bcc = "Bcc" *WSP ":" | address-list / CFWS / obs-empty-list CRLF [...] | obs-empty-list = 1*([CFWS] ",") [CFWS] Ditto for <obs-resent-bcc>, and IMO it better expresses the point of what's going on in these three cases than: | obs-bcc = "Bcc" *WSP ":" | address-list / (*([CFWS] ",") [CFWS]) CRLF > (*Shrug*) I just can't get excited about this one. Getting excited about ABNF-beautification is my spleen. Frank