ietf-smtp
[Top] [All Lists]

Re: Changes in CWFS location in 2821bis ABNF

2005-09-12 11:50:29

--On Sunday, 11 September, 2005 16:21 +0200 Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:

Frank,

FWIW, some of the positions you are taking seem to me to be
pushing us toward the "WG needed before more drafts" position
that you claim to dislike.  Just my opinion, of course.

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.
...

FWIW, I used to do programming language standards, where the
requirement --especially with formal and semi-formal
definitions-- for quality, clarity, and precision of syntax
definitions has historically been much higher than it has been
in the IETF.  I'm not, personally, a big fan of ABNF.  I wasn't
a fan of the version in the early 1980s.  The current version is
an improvement in a number of major respects, but adds enough
metarules and metasyntax to make it unattractive to me on that
dimension.  However, DRUMS very clearly decided, with relative
strong consensus (even if not unanimity) to use ABNF in 2821
rather than the BNF of 821 or some other system and to revise
ABNF as it did.   I didn't do the ABNF for 2821.  Drawing me
personally into a debate about whether one ABNF structure is
aesthetically more pleasing than another is likely to result in
rude analogies, but little progress.  If something is an actual
error, please point it out.  Otherwise, please start writing a
WG charter.

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>.

Yeah.  From my point of view, we had comments defined in 822 by
a bit of handwaving that, generally, worked.  We updated ABNF
and tried to define comments by syntax and didn't get it quite
right because of the character of ABNF.   See "not a fan" above.
 
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 ";".

To review this bit of esoterica for those who are reading the
thread, but not the spec, one of the key differences between
2821 and 2821 bit in this area is that 2821 used the productions

   Stamp = From-domain By-domain Opt-info ";"  FWS date-time
   From-domain = "FROM" FWS Extended-Domain CFWS
   By-domain = "BY" FWS Extended-Domain CFWS
   Opt-info = [Via] [With] [ID] [For]
   Via = "VIA" FWS Link CFWS
   With = "WITH" FWS Protocol CFWS
   etc.

The net effect of that sequence, which is not obvious unless one
looks carefully at it, is to require white space or a comment
before the semicolon.  That was not the requirement of 821 and
having the semicolon appear without leading white space is
fairly common practice.

2821 moves the CFWS terms around, so we have 

   Stamp = From-domain By-domain Opt-info [CFWS] ";" FWS
                  date-time
   From-domain = "FROM" FWS Extended-Domain
   By-domain = CFWS "BY" FWS Extended-Domain
   Opt-info = [Via] [With] [ID] [For]
   Via = CFWS "VIA" FWS Link
   With = CFWS "WITH" FWS Protocol
   etc.

That fixes the "required space before semicolon" problem.  It's
aesthetics?  Well, don't ask me about ABNF aesthetics.

And, yes, it seems obvious to me that whatever 2821 does in this
area, either 2822 should do as well or we should be sure that
everything permitted by 2821 is permitted by 2822 and that 2822
should contain an explanation of the difference.
 
Either way, I'd claim this change needs coordination with
2822bis, which is another reason to move the documents forward
together.  To address this point in the context of another note
of yours, "or its successor" doesn't work for me --it turns
2821bis into an unstable standard whose interpretation depends
on knowing which version of 2822x is relevant at the time (or on
the assumption that 2822* won't change in this area, but...).

And it's also incorrect, both 2821 and 2821bis -00 clearly say
"Received:" FWS Stamp CRLF, _not_ "Received:" [CFWS] Stamp CRLF

Much as I think that difference, if 2822bis chooses to preserve
it, should be justified in text there, the forms that 2822
permits are a superset of the forms that 2821 can produce, so
this doesn't seem to me to be harmful.

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 />

Then, IMnvHO, USEFOR made a poor strategic decision.  It would
have been far preferable to generate a "CFWS-everywhere in 2822
considered harmful and unprecedented" draft and to try to get it
processed as a PS, updating 2822.  Or, as a different option,
you could have warped the generate/accept distinction in 2822 by
saying in the USEFOR document "MUST NOT generate and MAY NOT
accept" wrt some of these stranger insertions of comments.
That said, "CWFS-everywhere" is not new to 2822: it is pretty
much implicit in the "comments as delimiters" construction of
822 and hence should not have come as a surprise to USEFOR
(again, see my fan club comment above -- I am trying to describe
the situation, not to praise it).

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.)

I've tried reading this several times and don't understand what
you are proposing and/or complaining about.  Perhaps that is
because I haven't been following USEFOR.


 [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.

That isn't what I intended to say and I don't think it is what I
said.  The IESG interprets both the rules for document
classification and the consensus of the community, doing that
using whatever mechanisms it likes and subject only to appeal
and/or recall if they get it wrong.  I believe that the IESG
usually acts with good intent and consistent with their
perception of the position of the community.  If the community
has an opinion about these things, it needs to be clearly
expressed.  Otherwise, the IESG is _forced_ to use its own
judgment (or to interpret silence as lack of strong community
support and interest and just drop the relevant document into a
black hole, which I wish they would do somewhat more often).

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.

"Of course" has nothing to do with it.   As an individual who
has only a finite amount of time to devote to IETF work, I have
regularly concluded that there are things I would rather do with
my time than fuss with a 2821 rewrite.  You might infer that
from the fact that there has been a note on my personal task
list since early May of 2001 to get this draft out and that I
clearly didn't do so until recently.  Left to my own devices, I
might have continued to ignore it, or spent time working on more
general ways to advance documents like this via a
minimally-necessary list of corrections rather than full
rewrites and replacement of the documents themselves (anyone who
wants to assume that was the motivation for
draft-ietf-newtrk-repurposing-isd-03 and its predecessors, feel
free: while that conclusion would not be accurate, the
experience with creating 2821 certainly figured into the
formula).   I was finally persuaded that it was time to do this
by others, and others, notably Tony Hansen, assumed
responsibility for one of the intermediate tasks that I had been
using as an excuse to not do so.

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.

To the extent to which you are correct, I wouldn't use terms
like "lottery".  Either the community disagreed with your
interpretation of what would bar advancement in grade or some
incompatible and inappropriate chance slipped through due to
inadequate review (during Last Call or earlier).  It is a little
late in the game to appeal the approval of 3986 on that basis,
but you (and others) clearly had that opportunity too.   That
sort of decision process turns into a lottery iff you assume
that the IESG is required to be infallible about finding and
interpreting problems with documents that are not identified to
it by the community.  I have very high, perhaps unreasonably
high, expectations of the IESG, but infallibility is not on my
list.

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 ?

No, I'd say that, if we can't get to DS now and with this
revision, I'd rather proceed with an "updating" document at PS,
now, that identifies and fixes the errors, wait the requisite
six months, and then fold those changes into 2821bis and move
the two to DS together.  There are three reasons for that
approach; the third one highly personal:

(i) We already have more than enough confusion about whether
2821 or 821 are authoritative on a number of issues.  Issuing a
2821bis that doesn't clearly supercede 2821 in context and grade
would, IMO, be a mistake.

(ii) If we open 2821, we simultaneously opens up corrections of
a number of small editorial matters (anyone think that the
appearance of "with with" or "and and" due to editing errors
undermines understanding of the document?), attempts to fix
minor errors in the syntax and make it less ugly, substantive
clarifications to existing text, general questions of theory,
model, and requirements, and, like it or not, the need to
coordinate a certain number of potential changes or
clarifications with 2822[bis].  People have been pretty good
about it so far, but there is also potential for revisiting and
trying to second-guess decisions that were made, very painfully,
during the DRUMS effort.  The discussions of the last couple of
weeks make those problems very clear.  It just isn't, IMO, worth
the effort to go through that more times than needed.

(iii) If work is initiated on such an update PS, I won't feel
any obligation to either edit it or to try to coordinate and
balance comments.  I could even take 2821bis off my calendar
until a few months after that effort converged :-)

 
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'm not that confident of my own infallibility.  I feel some
responsibility for this and obligation toward it, but, if
someone were to come forward who wanted to do it who could
convince the community (or at least the ADs) that he or she had
adequate skill, perspective, and motivation --motivation that
did not include axe-grinding about, e.g., spam or a particular
product-- I'd hand it over with enthusiasm.

...

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.

I think we agree on that particular approach.

    john