[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