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
<magnus(_dot_)westerlund(_at_)ericsson(_dot_)com> 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