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

On 18:25 24/08/2005, Scott Hollenbeck said:
   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.

Dear Scott,
what is surprising is that a Draft dealing with standard track 
issues, replacing an RFC dealing with the same issues, itself 
replacing a standard track RFC 1766 considering the same issues, can 
become a BCP.

As you now know it is because RFC 3066 became BCP 47. Alluding to 
WG-ltru is then confusing: the need is for someone with good memory 
to tells us how the content of the Standard Track RFC 3066 has been 
granted a BCP status, while deprecating a Standard Track RFC?

And to discuss how to correct that situation.

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

If you say so. FYI never discussed the RFC 1766 origin because the 
point was out of the WG-ltru scope.

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

I think it is slightly more complex. The Charter says:
"RFC 3066 [a BCP] and its predecessor, RFC 1766 [a Standard Track], 
defined language tags for use on the Internet.".

It then says:
"This working group will address these issues by developing two 
documents. The first is a successor to RFC 3066."

Then, deep in the Charter, it says:
"The current registry contains pairs like uz-Cyrl/uz-Latn and 
sr-Cyrl/sr-Latn, but RFC 3066 contains no general mechanism or 
guidance for how scripts should be incorporated into language tags; 
this replacement document is expected to provide such a mechanism."

You know the lack of Charter analysis by the WG I often complained 
about. This is the reason why the WG has not been in a position to 
elucidate that "thorny" point. I consider legitimate and reasonable to say:

1. we have a need: to better address the language identification in 
Internet protocols
2. this is a standard track issue introduced by RFC 1766 and we need 
to correct the difficulty met by its successor RFC 3066
3. one of these difficulties is that such an Internet core issue to 
the Multilingual Internet is addressed by a closed BCP instead of  an 
open Standard. Let make the successor document a Standard Track 
document replacing a centralised control by a distributed solution.

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

I consider this document meets _some_ but _not_all_ the requirements 
of the working group charter (I could provide a long list if this was 
necessary). I submit this because 25 years of applied R&D, operations 
and survey in this area shown me no one on earth has today the 
expertise to stabilise any standard or practice in the brain to brain 
language interoperability area. This why _any_ proposition can only 
be "ad experimendam".

We met a very similar, however limited, situation in the IDN case. We 
all know the result. I suggest we do not repeat the same approach and 
that we deliver something stable the Internet community can rely on, 
live and develop with.

To do that there are three options.

1. to replace the BCP 47 (RFC 3066) by an Internet standard process 
framework dealing with the Multilingual Internet support. I started 
working on such a Draft one year ago. This was delayed by the 
WG-ltru: it has been a tough but fruitful experience I am now able to 
use in a preliminary  proposition. I hope to be able to publish a 
preliminary draft very soon, with reasonable international support 
expectations. This will probably be a long process.

2. to mend the closed format proposed by the Draft. For the reasons 
above I submit this is not feasible now, because no one has the 
expertise, the vision, the experience and the necessary universal 
support to do it today. I expect however that the community process I 
will propose will help doing it, based upon the experience. I would 
not be surprised if the R&D involved lead to a work of a magnitude 
comparable to IPv6 but calling on many sub-expertises the IETF has 
not right now.

3. to make the proposed Draft a default language identification 
system, supporting any other identification schemes in using one 
singleton as an introduction sequence. I note that during the WG-ltru 
process I have documented the support of my organisation to an ABNF 
included in the URI tags RFC. Some refinements are being discussed. I 
am ready to document such an extension through a WG-ltru specialised draft.

Everyone knows that people from large stakeholders, consortia and 
standardisation entities are involved in the proposition. They may 
find some commercial motivation in the use of the Draft current 
closed format. I submit this would be a mistake because they would 
block their own R&D (which will most probably agree with the results 
of our own experimentation when they have done their own home work). 
They would also run into the risk to attach a poor image to their 
name, if Governments and users are dissatisfied as they will  most 
probably be.

This is why I think my "default" proposition meets the requirements 
and the interests of everyone:

- large stakeholders benefit from a stable solution and lead (rather 
than a controverted IANA)
- their own R&D can develop
- competitive specific propositions and innovation can develop 
without harming anything, comforting the common approach
- community R&D and grassroots projects can develop and boost the 
Multilingual Internet - what we missed in the IPv6 case.

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

I have repeatedly indicated that I would appeal from a positive 
decision of IESG concerning the current status of the Draft. Because 
it would harm and delay the Internet community, for the global reason 
I give above and for many non-detailed "sub-reasons". This lead the 
Shepherding Chair to send you and through you the IESG a summary of 
my objections. I have no copy of this mail.

jfc

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf