Subject: RE: [Ltru] issue #1072 Last Call text alternative over languages and Internet

From: "Addison Phillips" <[email-masked]>
Date: Tue, 2 Aug 2005 05:58:18 -0700

-1

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of r&d afrac
> Sent: 2005?8?2? 4:58
> To: Randy Presuhn; [email-masked]
> Subject: [Ltru] issue #1072 Last Call text alternative over languages and
> Internet
> 
> At 11:23 02/08/2005, Randy Presuhn wrote:
> >Hi -
> >The discussion over the past few days makes it clear that there is still
> a
> >rough
> >consensus in the ltru WG on the resolution of issue #1072 on
> compatibility
> >and its consequences for private use and extension tags.
> 
> [for external readers: this an exchange of the WG Last Call debate about
> an
> IETF Draft defining languages on the Internet, and by natural extension,
> for the entire world, starting with the Operating Systems locale files.
> This would result in a "language tag" only based on ISO tables for
> languages, script and countries. It would exclude the flexibility of
> including referent (dictionaries, publishers, etc.), style of usage and
> individual, community, trade, etc. considerations, etc. This Draft also
> defines a syntax for this langtag. My repeated demands that other schemes
> be considered or permitted, such as internationalised domain names and DNS,
> LDAP, computer languages, OPES, etc. and that lingual and cultural bodies
> are called upon for an open debate, are opposed by silence. This mail
> takes
> advantage of the Last Call where co-Chairs should establish their
> evaluation of a consensus on actual expressed support. The Chairs use a
> tracking system where point #1072 refer to a proposition I abandonned
> (using and extending a reduced private use namespace) after a remark by a
> Member. I then introduced a more general and simpler proposition (a
> general
> escape sequence using none of their format resource end permitting any
> scheme).]
> 
> Dear Chairs,
> The issue #1072 should be replaced by the Last Call text I introduced two
> days ago. At this stage this text has been very partly commented only once,
> by the Member who lead to its proposition. Four minutes before your mail
> you also opposed it (privately or as one of the co-Chair?) on the ground
> it
> is ... not in the Draft. Oh! yes: the other co-chair _previously_
> published
> a _private_ final position on the proposition this text replaces.
> 
> At this rate of we will still be stuck into this two years from now. To go
> faster I propose two texts summarising both positions, so Members may
> commit toward a rough consensus, by more than 2 members and 2 co-Chairs.
> This way, no text can be claimed to be accepted by silent rough consensus.
> 
> - Text A, wants both (a) to fully respect the current Draft and its
> enforcement through a ANA registry, (b) to fully permit the empowerment of
> every human individual, community, nation, Government, on their own
> language and culture through the schemes they want.
> 
> - Text B, (a) fully respects the current Draft intent to restrict the lose
> and incomplete RFC 3066 framework and to provide a fomal, stable and
> backward compatible syntax to the "end users'" applications'(introducing
> the "end-user" in the IETF culture) (b) understanding and accepting the
> cost to pay for it.
> 
> Text A:
> 
> "2.2.8 Escape Sequence
> 
> For compatibility with other language tags systems the "0-" singleton
> escape sequence if provided. It means that the "0-" singleton MUST be
> considered as an end of a language tag as documented by this memo.
> Everything following the "0-" singleton escape sequence, even after
> another
> singleton, MUST be treated as foreign to the present rules and documented
> registry; and as defined by another set of rules and another registry. To
> avoid confusion that set of rules and registry SHOULD be identified by a
> scheme built in using a unique identifier belonging to its registry
> manager, or defined by an RFC."
> 
> Text B:
> 
> "As a new version of BCP 47, this memo wants to etablish a final language
> tagging system for the whole Internet, its protocols and its user
> applications. It should exclude every confusion of this scheme by non
> conformant language identification syntax - existing, under development or
> planed. The private usage area ABNF has been carefully designed to contain
> this risk and to limit private use to a miminum. Authors understood it was
> at the cost of excluding every possible global alternative even by open
> source, competition to dominant market leaders, cultural interest,
> authority and communities, Governments, grassroots efforts, individuals,
> etc. , even confoming to or specified by other standard track documents
> and
> even if more complete or adequate. They accepted this constraint as the
> price to pay to warranty applications designers and their end-users the
> perpetual stability and the lingual identification surety they need to
> protect archiving retrieval, lingual interoperablity and content control
> and management processes."
> 
> It is now to the Members to decide, in front of the Global Internet
> Community.
> jfc
> 
> 
> 
> 
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 2 Aug 2005 11:51:20 -0500 (GMT-05:00)

Hi -

> From: r&d afrac <[email-masked]>
> Sent: Aug 2, 2005 11:21 AM
> To: Randy Presuhn <[email-masked]>, [email-masked]
> Subject: Re: [Ltru] Re: issue #1072 Last Call text alternative over  languages and Internet
...
> I find strange that after all this time you are unable to commit if I am or 
> not right in saying that RFC 3066 bis will become BPC 47 and will enjoy the 
> authority of a BCP?

You seem to attribute far more import to the "BCP" designation
than is warranted.  Whether it is designated as a BCP is up to
the IESG.

...
> I repeat that my proposition "0-" (or Text A) is correct.
> That your comment is incorrect.
> That your decision to consider it closed is incorrect.

This co-chair has already ruled.  You may take your problem
to the responsible AD.  If I have misread the WG consensus,
or the WG has collectively committed a technical blunder, our
AD can instruct us to reconsider.

> Up to you to show me wrong about Text B in producing a statement by IESG 
> that the Draft will not become BCP 47 and that it does not pretend to an 
> exclusive.
...

Sorry.  I'm simply not able to make any sense of this sentence.

Randy, ltru co-chair