[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 2822upd-06 submitted
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