--On Tuesday, 17 June, 2008 11:30 +0200 Simon Josefsson
<simon@xxxxxxxxxxxxx> wrote:
> Brian Dickson <briand@xxxxxxxxxxxxxxx> writes:
>
>> Here's my suggestion:
>>
>> List 2606 in the informative references, and footnote the
>> examples used to indicate
>> that they are "grandfathered" non-2606 examples.
>>
>> So, in text that previously read "not-example.com", it might
>> read "not-example.com [*]",
>> with the references section having "[*] Note - non-RFC2606
>> examples used. Please read RFC2606."
>>
>> Something along those lines, should hopefully be enough to
>> keep both sides happy, and resolve the DISCUSS,
>> and hopefully both set a suitable precedent *and* make moot
>> the appeal.
>
> I think this sounds like a good compromise, and it does
> improve the document quality IMHO. John, would this be an
> acceptable addition to the document?
Simon,
I've responded to Brian off-list and continue in my
determination to not engage in a debate about the appeal itself:
under the procedures as I read them and as they have been
applied in the past, the IESG will decide however it decides.
However, unless they make it one by composing a statement or
appeal response and issuing a Last Call on it (I believe they
have the right to do that, but certainly not any obligation, and
it would be unprecedented), the appeal itself is neither a
community popularity contest nor a consensus call. Remember
that 2026 does not even require that appeals be made public when
they are submitted.
Without endorsing them (the authors speak for themselves and
have written clearly), you might want to re-read any of several
recent notes and the appeal text: the core issue that motivated
the appeal was not whether or not these examples were to be
changed.
Changing the examples (or not) has _never_ been the core
question. If it were, I would have included a discussion of
compromise positions and counter-suggestions that had already
been offered. Even with such a discussion, the appeal text
would have been much shorter. The core issue has to do with how
the IESG manages document reviews, whether the community likes
late surprises that could easily be avoided, how rules are
formulated and applied in the IETF, how AD judgments relate to
consensus in the IETF Community or applicable subgroups, and so
on.
As to Brian's suggestion, please consider the following, derived
from RFC3501 and hypothesize that, at some point, an RFC 2606bis
might be created (and go through the consensus process to BCP)
that offers special reserved names for newsgroups or mailing
lists as well as domain names (many of the arguments offered for
using only reserved domain names, including "rude to the
owners", would probably apply to newsgroups and other sorts of
network entities as well) and that included a form of Brian's
suggestion as normative.
RFC3501 now includes:
> Example: C: A002 LSUB "#news." "comp.mail.*"
> S: * LSUB () "." #news.comp.mail.mime
> S: * LSUB () "." #news.comp.mail.misc
> S: A002 OK LSUB completed
Now, suppose, per Brian's suggestion, that were changed to
Example: C: A002 LSUB "#news." "comp.mail.*" *
S: * LSUB () "." #news.comp.mail.mime
S: * LSUB () "." #news.comp.mail.misc
S: A002 OK LSUB completed
or
Example: C: A002 LSUB "#news." "comp.mail.*" [Foobar]
S: * LSUB () "." #news.comp.mail.mime
S: * LSUB () "." #news.comp.mail.misc
S: A002 OK LSUB completed
or
Example: C: A002 LSUB "#news." "comp.mail.*" [1]
S: * LSUB () "." #news.comp.mail.mime
S: * LSUB () "." #news.comp.mail.misc
S: A002 OK LSUB completed
any of which would be consistent with what I interpret as the
spirit of Brian's suggestion, with the "*", "[Foobar]", or "[1]"
being anchors for a reference or footnote.
Now _that_, folks, is confusing, since a reasonable reader might
have trouble figuring out whether the footnote/reference anchor
was part of the IMAP syntax and example or not. It would be so
confusing that I'd argue that it involved a substantive issue,
rather than an editorial/stylistic one as Brian Carpenter
suggests sometimes occurs. I'd expect people to notice it
during Last Call and complain, and I'd think an AD would be
entirely justified in asking hard questions and forcing
discussions.
Whether the examples in 2821bis are like that case simply
because they fail to use 2606 names is something that you should
judge for yourselves. But, because of possibilities that the
examples above illustrate, be careful what you wish for.
john
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf