ietf
[Top] [All Lists]

RE: Last Call: 'Tags for Identifying Languages' to BCP

2005-08-24 09:27:07
On Wed, August 24, 2005 9:02 am, JFC (Jefsey) Morfin said:
On 13:24 24/08/2005, Scott Hollenbeck said:
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org 
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On
Behalf Of JFC (Jefsey) Morfin
Sent: Wednesday, August 24, 2005 5:03 AM
To: iesg(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: Re: Last Call: 'Tags for Identifying Languages' to BCP

I would like to understand why
http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-12.txt
claims to be a BCP: it introduces a standard track proposition,
conflicting with current practices and development projects under way?

I support it as a transition standard track RFC needed by some, as
long as it does not exclude more specific/advanced language
identification formats, processes or future IANA or ISO 11179
conformant registries. In order to avoid conflicts, its ABNF should
be completed in dedicating a singleton to the general tag
URI

(<http://www.ietf.org/internet-drafts/draft-kindberg-tag-uri-07.txt>

accepted RFC).

Jefsey,
First, let's agree that you've asked this question [1], made this
suggestion
[2], and engaged in discussion of these topics on the LTRU working group
mailing list.  I know you haven't been happy with the way the discussion
went, but these are not new topics.  Agreed?

Dear Scot
This an IESG last call. The IESG solicited final comments on its
intent to take a decision on the document - not on the WG methods. I
am honored to be involved in an internal discussion to the IESG by
the AD in charge, but if the IESG has already set-up its mind, what
is the use of a Last Call period?

This is not an internal discussion.  You sent a question to both the IESG
mailing list and the IETF discussion list.  The people on these lists are
not necessarily familiar with the discussion that took place on the LTRU
working group mailing list.  I believe it is necessary to help those readers
understand your questions and comments by putting them in context.

The IESG has not made up it's mind about anything.  We do, however, need to
understand what transpired during the course of working group deliberations
as we attempt to understand your questions and comments.

The considered Draft does not describe a practice. It is a standard
track proposition among many others, existing or possible, including
better ones (according to his author), in an area where expertise is
scarce.

Thank you for that comment.  It will be considered by the IESG.

Why a BCP?  Production of this document is a direct requirement of the
group
charter: "This working group will address these issues by developing
two documents.
The first is a successor to RFC 3066." 3066 is BCP 47.  The
introduction and list of changes included in the
document describe why and how it is obsoleting 3066.

A successor is not necessarily a replacement. This question marred
the two last previous Last Calls of this proposition. Time has come
to address this in deprecating RFC 3066/BCP 47 and in considering
this Draft as what it is: a standard track RFC.

The working group was chartered to produce a document that replaces RFC 3066
according to my reading of the charter.  The registry draft notes this
status in the Introduction.  Yesterday the working group received an AD
evaluation comment that this status also needs to be more explicitly noted
in the first page document header.  I consider this an editorial issue that
can be resolved in the context of any other edits required as a result of
last call review.

If you are suggesting that this document does not meet the requirements of
the working group charter, then that is a valid comment that must be
considered by the IESG.

The ABNF suggestion has been discussed, partially accepted, and partially
rejected by the working group.  If you have new information to describe
why
you think the working group decision was a mistake, please describe it.

The IESG is to determine is if there is a consensus or not about the
Draft. It is not new the sun is not blue. It is not new that
commercial interests are in conflict with open sources. There are on
this list - and this is the purpose of a LC - all the IETF
competences to evaluate if the partial acceptance of my suggestions
went far enough or not.

A technical conflict remains a conflict. One may dislike it, but one
has to address it. We have two contradicting propositions, one
accepted as an RFC, one here under discussion. Both use W3C needs as
a motive, but both authors claim (one by disclaimer in his text, the
other in the WG debate) they do not represent the W3C positions. May
be a LC is the proper time, and this list the best place, for W3C to
tell us officially the tags, the private use tags or the other tag
formats they (also) want. And the same for all the other concerned SDOs.

I provided a link to your working group comment to help readers of this
exchange (including the IESG) review both your suggestion and the working
group response to your suggestion.  Thank you for this clarifying
information.

-Scott-


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf