ietf-smtp
[Top] [All Lists]

Re: RFC2821bis-02 Issue 27 (and 28): Received clauses

2007-04-24 08:45:49



--On Tuesday, 24 April, 2007 12:51 +0100 Paul Overell
<paul(_dot_)overell(_at_)thus(_dot_)net> wrote:

In message <462DE5E3(_dot_)2A82(_at_)xyzzy(_dot_)claranet(_dot_)de>, Frank 
Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> writes

Pete Resnick wrote:

All of those have surrounding CFWS.

That's why 2821bis should stay away from using similar terms
like <Atom>, there are no comments and no line folding in the
envelope.  For <Mailbox> any attempt to clean it up is likely
too late, but it deserves a note in 2821bis that <Mailbox> is
syntactically very different from <mailbox>.


If we wish to distinguish between <mailbox> and <Mailbox> then
we ought to use different names, not just different case.
...

Sigh.
First, I agree with you in principle.

Second, this, and a few other notes in this thread, have caused
me to change my (personal) mind again about doing an ABNF
overhaul.  A week ago, I was taking the position that an ABNF
overhaul, however attractive, was just going to be too hard to
get right (a position very similar to the one Dave took in a
recent note).  Then I was convinced, yesterday, that it was
possible to do it and check it carefully enough to make the
effort worthwhile.

For whatever my personal opinion is worth, I've just changed my
mind again:

The grammatical element "Mailbox" is in upper-case in 2821 to
distinguish it from the informal term "mailbox", which is used
throughout the text.  The alternative would have been to use
"<mailbox>" and "mailbox", which is more or less what 821 did.
The choice of word and capitalization has nothing to do with
what was done in 2822 -- 2821 references 2822 only for terminal
and near-terminal productions and is, I hope, fairly clear about
where it does that.

Now, while it would be better if they didn't use similar-looking
terms for different productions, fixing that is not a matter of
fixing the ABNF -- it requires revisions to the text of the
specifications.  When I made the changes for "headers" that are
the topic of this issue, I discovered that it wasn't as easy as
I expected to make those corrections without ending up with some
extremely clumsy and hard-to-read sentences.  I think I've
gotten that right (or close enough), but my prediction is that
the odds of getting thing right if we change "Mailbox" into some
other term is that they are about zero.  

So I'm back to where we started, i.e., with a personal
conviction that we should fix things that are clearly bugs, take
care of low-lying fruit in the clarifications area, but
otherwise avoid any changes to things that are not broken and,
in particular, any changes that have sweeping implications to
the text.

Just my opinion, of course.

     john