--On Wednesday, 18 June, 2008 21:53 +0100 Debbie Garside
<debbie@xxxxxxxxxxxxxxxxxx> wrote:
> Maybe I and a few others thought a BCP was worth something.
> Apparently not. Unlike the authors of these documents I am not
> privy to the reasoning behind them I am just privy to the
> document itself. Neither are countless other people who
> observe IETF BCP's. Perhaps I should not bother recommending
> BCP 47 (full of MAY's and SHOULD's) anymore or indeed
> contributing to the IETF LTRU process. It obviously is not
> worth the digital paper it is printed on.
Debbie,
Please take the time to read the relevant documents, starting
with the full text of the appeal and then the text of "the BCP"
before making comments like this. RFC 2606/BCP32 very clearly
makes the names available for use where authors find them
useful. It does not require them, specify that they SHOULD be
used, or call for a community consensus process to determine the
cases in which they might or might not be used. The author of
that document has commented on this list that nothing else,
especially an implicit requirement, was intended. And no one
else has been able to cite text in RFC2606/BCP32 that imposes a
requirement. But you apparently did not read those notes
either (in addition to not reading the document to which you
claim to be "privy").
The only published requirement for the use of these names is in
the "ID Checklist" (IDNits). That document is not a BCP. It is
not even an IETF consensus documents. It is an IESG statement
about what the IESG intends to look at. And it says "SHOULD
preferably". Traditionally in the IETF, "SHOULD preferably"
is a WG (or author and editor) decision as to whether there are
grounds for doing something other than what the SHOULD
recommends. For the IESG to block a document on that basis
turns a SHOULD into a "MUST unless we choose to grant an
exception". And, in any event, IDNits is not a BCP of any
flavor - there is no evidence of community consensus for
applying IDNits this way.
> A sad day for IETF in my book.
They are always sad days for the IETF when people comment
passionately on documents they haven't read and clearly don't
understand and when they fail to read and consider other
comments in a discussion thread before posting remarks of their
own that could have been informed by those comments.
john
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf