Re: draft-klensin-rfc2821bis-10: ABNF discuss

[John C Klensin <[e-mail]>]

A few personal comments in the hope of getting a discussion
started and this resolved quickly...

--On Tuesday, 01 July, 2008 10:30 +0200 Magnus Westerlund
<[e-mail]> wrote:

> (resending after having subscribed to ietf-smtp)
> 
> Dear SMTP interested people,
> 
> As some may have seen I held a discuss in two parts. The
> second part was
> unfortunately not discussed until last week at all with me. I
> would like to get your input into this question.

The "not discussed at all" issue is one that could open up yet
another whole discussion of the information the tracker gives to
authors, editors, mailing lists, etc., and just what the
expectations are of both IESG members and document shepherds.
Since those topics are probably as controversial as the ones
associated with the pending appeal, I'm going to try to avoid
them here and hope that, if people do want to raise them, they
will at least change the subject line.
 
> My discuss was started due to there was a rule which wasn't a
> rule, i.e.
> it didn't contain any elements. A clear syntax violation in
> ABNF. The
> rule in the issue was "Standardized-tag", this can be seen in
> version 10 of the draft in section 4.1.3.

> I have received a proposal from John Klensin that would make
> section
> 4.1.3 read as below. The change is in the rule for
> General-address-literal and removal of Standardized-tag as a
> defined rule.
> 
>     General-address-literal  = <Standardized-tag> ":"
> 1*dcontent
>          ; Standardized-tag MUST be specified in a
>          ; standards-track RFC and registered with IANA
> 
> 
> However, my personal objection against this resolution of the
> error is
> that it leaves use with a undefined rule that is intended for
> future
> extensions. I see this as a interoperability issue as any
> parser
> implemented according to the rules in this document will have
> the
> potential to fail on any future tag. If one could clarify what
> possible
> syntax that the future tags could have then this would not be
> an issue.
> I fully understand that the old implementation will still not
> understand
> the content, however, by not having the parsing fail an
> implementation
> can at least take the correct action. Thus I wonder why one
> can't specify it like:
> 
> Standardized-tag = ehlo-keyword

>From my point of view, it certainly could.  If I recall, Tony
and the list discussions gave me three options for solving this.
I was told to pick one.  I did.  My main reason for doing so was
to minimize the number of placeholder productions we needed.

I can certainly see Magnus's point that limiting the syntax for
the tag lexically would be an advantage.  My recollection is
that we decided to not do that during the DRUMS discussions, but
I no longer remember why.  

But, given the controversy about what I believe are stylistic
issues, I'm not willing to make any further changes in this
document without list review because some AD has a preference
for a different approach or language.

> Any rule that defines what combination of character are
> allowed in any
> future tag would be fine as a solution to this issue from my
> perspective.
 
> Is there a any problem with defining a rule for what
> characters is
> allowed in future tag for identifying literal address formats
> that is
> large enough to motivate living with the interoperability
> issue?

The question, for me, has never been about "is there any problem
with doing it <this way> rather than the way the group decided
to do it?" (even if the group decision was a trust a lazy and
incompetent editor).  The question is whether this approach
provides enough of an improvement to make a change that might
risk unintended consequences.     In this particular area, my
own, personal, guess is "probably it is".  But that is, IMO, up
to the list to decide.

best,
   john