John C Klensin wrote:
someone persuaded me and at least one reviewer that the
change would improve things, fix that bug, and not have
any nasty side effects
Yes, it only surprised me, the old ABNF was more "natural"
wrt. the position of the CFWS. The new ABNF is "ugly",
but for the purpose of allow-no-FWS-before-semicolon it's
probably necessary.
If we insist on this concept. I've no better idea, and I
tried to replace CFWS-as-separator for the References,
because <a(_at_)b>(c)<d(_at_)e> is odd, I'd expect <a(_at_)b> (c) <d(_at_)e>.
It's possible, but the resulting ABNF was so horrible that
it was never seriously considered. Here "From x(c)by y"
is the analogous issue. 2822 says:
| received = "Received:" name-val-list ";" date-time CRLF
| name-val-list = [CFWS] [name-val-pair *(CFWS name-val-pair)]
That's different from both 2821 and 2821bis -00, it's exactly
the opposite of 2821: There can't be any CFWS before the ";".
And it's also incorrect, both 2821 and 2821bis -00 clearly say
"Received:" FWS Stamp CRLF, _not_ "Received:" [CFWS] Stamp CRLF
The 'CFWS-everywhere' attitude of 2822 is a royal PITA, and at
least two of the six USEFOR-years were spent for fights with
some of these 2822-concepts... <sigh />
I'd say stick to "Received:" FWS Stamp CRLF, it's fine. With
a time machine it's what I'd try for all header fields, in
news (instead of the ridiculous "magic SP") and mail (instead
of [CFWS]. That's an optional CFWS for those who don't see it
allowing e.g. Received:From x without any WSP after the colon,
or even Received:(c)From x, etc. plus all the funs of folding.)
[procedural questions about a WG and ADs]
There is a judgment call as to whether adding in the
equivalent of "Opt-info" somewhere would be a change
compatible with going to Draft or not.
Yes. In another thread you just told me that the "community"
should say what it wishes wrt. BCP and PS, because otherwise
the IESG is free to pick what they think is the best status.
Here you tell me that DS vs. PS is something depending on the
ADs. Why is this different here ? From my POV it's simple,
2821 needs to be fixed, it's not urgent, and if the outcome
is "only" a PS it's also okay (other folks _dream_ of PS for
what they have created in about two years). Of course you as
author strongly prefer DS.
Looking at 2396 and 3986 as an example the status is a lottery,
there are important differences between 1738 / 2396 / 3986.
And some bugs in 3986 appendix D.2, but that's another issue.
if they had a "nope, would require a reset" reaction, trying
to convince them otherwise would be, for me, prerequisite to
changing the text.
So you'd say status DS is more important than to get it right ?
While the image that discussion conjures up involves careless
or sadistic ADs ignoring issues until the last possible
moment so that they can then pounce on them, cackling with
glee
[...]
LOL. It's of course okay if you discuss 2821bis with say Scott.
But at the moment that's an individual contribution, you do it
because you want to fix and advance 2821 before somebody else
tries it (and besides the chances that anybody else gets this
"right" for any of your definitions of "right" would be slim.)
I also assume that the point at which this will shift from
mailing list discussion to a WG (or planning for one) is when
(and if) Pete or I stand up and say "gotten too complicated,
need the structure of a WG to determine consensus").
Yes, that's clear.
some suggestions have been made already that I can't imagine
trying to integrate without WG approval.
Let's see how far we get with the less controversional points.
In a difficult case like "at-least-one-dot" it might be also
possible to agree on a clear choice, either this <Domain> or
that <Domain>. In the worst case the hypothetical WG has then
at least a clear input document with all 2821 issues fixed or
outlined. Plus one or more showstoppers from your POV, where
some poor WG Chair has then to divine "consensus" in some way.
Bye, Frank