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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf