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

[Magnus Westerlund <[e-mail]>]

John C Klensin skrev:
> 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.

I only tried to express that if one tries to resolve a discuss one needs
to involve the Discuss holding AD somehow. And I have personally not
heard a single beep from anyone until a week ago about this part of the
  discuss.

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

And so far I haven't seen it as stylistic issues. I also think it is
correct that you are not doing changes that you are not comfortable
without discussing them with the interested group.

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

Maybe poor choice of words from my side. The fundamental question I like
to understand where people stand on the matter and if there is need for 
corrections if they are reasonable.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Färögatan 6                | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------