Subject: RE: [Ltru] [psg.com #1072] compatibility and private use tags

From: "Addison Phillips" <[email-masked]>
Date: Wed, 27 Jul 2005 09:49:58 -0700

Please leave it closed. To summarize again:

1. Introduction of additional characters, such as "." into language tags was rejected because these characters were not permitted in RFC 1766 or RFC 3066 and compatibility with existing language tag processors is a chief concern.

2. Relaxation of the length restriction on subtags from 8 to a larger number was rejected for the same reason: it would break existing processors.

Furthermore, I don't feel that anyone has demonstrated a need for either change: even JFC's proposals could be accommodated with clever design within the existing framework.

Addison

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 Randy Presuhn
> Sent: Wednesday, July 27, 2005 12:42 AM
> To: LTRU Working Group
> Subject: [Ltru] [psg.com #1072] compatibility and private use tags
> 
> Hi -
> 
> Has anyone been persuaded by Jefsey's arguments that we need to
> re-open the discussion of private-use (sub)tag syntax and compatibility?
> Unless there is support for re-examining this decision, I believe it is
> in the best interest of timely completion of our work to leave this issue
> closed.
> 
> Randy, ltru co-chair
> 
> ----- Original Message -----
> > From: "r&d afrac" <[email-masked]>
> > To: "Martin Duerst" <[email-masked]>; "Randy Presuhn"
> <[email-masked]>; <[email-masked]>
> > Sent: Friday, July 22, 2005 8:21 AM
> > Subject: Re: [Ltru] [psg.com #1073] Last call: IANA adaptation of theUN
> disclaimer
> >
> > Dear Martin,
> > I will try to address this serious mail as seriously as possible. I am
> on
> > vacations with many family things around.
> >
> > At 03:44 22/07/2005, Martin Duerst wrote:
> > >[chair hat on]
> > >Randy is right. "DISCUSS" refers to a very specific part of the process,
> > >in particular to questions, comments or requests some members of the
> IESG
> > >may have on the draft. This is recorded as a "DISCUSS" in the draft
> tracker
> > >(see https://datatracker.ietf.org/public/pidtracker.cgi).
> >
> > We fully agree. The point I rise is a serious point. We are to accept
> > external codes and _mix_ them (ISO 3166/UN M.49) in an area sensible to
> > every government, except may be the USG. Some pointed out there is no
> > Culture Ministry in the USG), and in several English language countries.
> > Members of this WG should understand and accept that in some countries
> > language is considered as _the_ culture, to the point citizens may
> consider
> > anything concerning their language without their due approval as real a
> act
> > of physical war, in cases calling possibly for personal physical
> > retaliation and terror (all the more if they consider it as part of what
> is
> > named "e-colonisation"). We have to take into account this full spectrum
> of
> > understanding of what this WG [mainly composed of English mother tongue
> > people] considers. I would underline that the matter of the debates of
> this
> > WG are quite unconceivable in a French speaking environment.
> >
> > I think this kind of concern is not a concern for a WG. But it is the
> > concern of a WG to inform IESG of the problem. What I say (considering
> the
> > Internet standard process spirit/letter) is there are two solutions:
> >
> > - to propose a text in the hope IESG marks it for DISCUSS.
> > - to report in the text that the identified problem goes beyond the
> > Charter, and that we identified it should be treated somewhere else.
> >
> > In the first case we run into the risk that our text is accepted and
> serves
> > further on as an IETF position. Out of luck, our proposition could be a
> > good one. But it is likely, even if we do our best, it would not be a
> good
> > one as this is a pretty complex one and we are neither lawyers nor
> > international diplomats.
> >
> > The second one is IMHO the most loyal to the IESG. Because the IESG can
> > decide to accept our point and mark it for DISCUSS, or disagree with us
> and
> > remove it.
> >
> > Ideally, the solution would be my reading of the charter: to address all
> > the issue through a global framework for the whole internet, truly
> > correcting and replacing RFC 3066 and then presenting the ABNF and
> filters
> > of this particular case in a technical RFC.
> >
> >
> > >The WG is expected to send the draft(s) to the AD and the IESG ***in
> the best
> > >possible fashion***, after having done everything they think is
> necessary.
> > >If we asa WG come to (rough) consensus that some "political disclaimer"
> or
> > >whatever we may call it is necessary, then we should make our best
> efforts
> > >to get the best possible text.
> >
> > See above. This is a solution. This is the one I initially advocated for,
> > trying to interest Gov officials, ISO people, Language structures,
> UNESCO,
> > etc. etc. The answer I received from everywhere is "we are not
> interested
> > in this commercial trick, IETF means nothing to us in that area, their
> > proposition is absurd and will not fly. Thank you to keep us posted so
> we
> > know where, how and when to kill it".
> >
> > I think it is not a proper answer. Because it is premature to kill the
> > IETF, even if it stays the way it is (RFC 3774). The IETF is also a
> place
> > to protect the technology from all these people: nothing will happen on
> the
> > Internet except through IETF and Open Source and Open Source is not
> ready
> > in terms of network architecture. So I tried to keep an equilibrium, for
> > example with the WGIG, which partly follows some of my points.
> >
> > But there are two main points the WGIG - and this WG - are wrong about:
> >
> > 1. the WGIG places the Internet R&D in private sector, as the WG does in
> > mainly relying on Unicode and W3C private commercial consortia. IAB RFC
> > 3869 clearly says (its "main thesis") that if this is the case the
> > architectural R&D of the internet is "in trouble". I can only confirm
> that:
> > I try to keep (at my family expense, as do others on this list or near-
> by)
> > myself near but financially free from Govs and as much as possible
> > grassroots and non-profit as I can, for free technical thinking and
> > development. This WG only produced a short minded, non scalable,
> excluding
> > solution (I will document this briefly further on).
> >
> > 2. The WGIG (and this WG does not even do that), considers
> multilingualism
> > as DNS and content (this WG excludes DNS what is a grave error, because
> it
> > confuses IETF's IDN mistake with multilingual DNS. Vint Cerf just
> > identified that mistake, put the blame on IETF, and calls for work on
> the
> > matter. He starts from phishing which cannot unfortunately be addressed
> > without changing the proposition, what will call for a change in the
> > architecture of the Internet. So not a little thing.
> >
> > But the main issue for us as a WG is that language is not the same issue
> > when a spoken language for mobiles (reason why mobiles develop far
> faster
> > than the Internet) or when text content for linguists, library and
> language
> > industry. Languages in the IETF must be understood as what IETF
> considers:
> > protocols.
> >
> > These person to person interintelligibility protocols involve R&D issues
> > this WG (financed by commercial interest) has not even alluded to. The
> > result is that a Draft about languages identification does not identify
> > itself what it considers as a language. I have no objection to the idea
> of
> > standardising the commercial tag of languages, to the contrary. But you
> do
> > not start from the price tag of the members of dominant consortium, as
> an
> > R&D specs for the whole deliverable.
> >
> > >If some IESG members then think that this
> > >has to be changed, they will raise a "DISCUSS". But going to the IESG
> > >with a draft that says something like "IESG, for this section, please
> > >do the work we were supposed to do" isn't an option.
> >
> > To do a work we are not supposed, we have not the competence and we have
> > not the authority to do is not an option. It would be a error and if we
> > make believe it would be a disloyalty. Unless you think you have the
> > necessary authority to relate with the IESG liaisons with ISO, IANA, GAC,
> > ccTLDs, UNESCO, UN, etc. and actually engage in it. In which case I
> would
> > certainly support you
> >
> > I will take an example of the difficulty: as a ccTLD (supposed to pay
> the
> > IANA, trustee of a national community, advisor of the Gov - in a country
> > where the culture Minister is also the Minister for ICT) and as the
> > secretary of an independent intergovernmental, interccTLD, inter-
> national
> > Internet communities think tank, and as a Member of the ccTLD committee
> for
> > the Luxembourg ccTLD meeting, I invited Brian Carpenter to come and
> > introduce the way IETF would consider a liaison with ccTLDs. You may
> recall
> > that my call to Greek and Chinese ccTLD Managers on ietf
> > [email-masked] shown the interest and the political need.
> Brian's
> > answer was roughly (published in my presentation) "I considered with IAB.
> > We have nothing to discuss with you. However if there are specific
> topics,
> > please go through ADs" (two Govs I copied the mail asked "what is an AD",
> > showing the relational/cultural divide.
> >
> > Then came the US Statement of principles and then the WGIG, and then
> Vint
> > Cerf which followed in confirming the need and actually supporting my
> > proposition to ccTLDs of an INTF. A TF to structure that relation
> speaking
> > user on one side and IETF on the other. And of an UNITRY test bed (along
> > ICANN criteria), I am working on, with the support of already a few
> > developing/non developing countries.
> >
> > Our role is not to replace IESG, but our job is not either to fool the
> IESG.
> >
> > >If the WG comes to the (rough) consensus that it's better NOT to have a
> > >"political disclaimer", then we submit a draft without a "political
> > >disclaimer".
> > >If somebody on the IESG thinks that this is a problem, then they will
> > >raise a "DISCUSS". If the WG and the IESG then can't agree, the IESG
> > >can request the RFC Editor to attach an "IESG Note" (see e.g.
> > >http://www.ietf.org/rfc/rfc2251.txt).
> > >
> > >Up to this point, everything I have seen from the members of this WG
> > >strongly indicate that we have (rough) consensus to NOT have a
> > >"political disclaimer".
> >
> > This WG is not competent on the matter. For two reasons:
> > - this is not its charter.
> > - the consensus is by exhaustion.
> >
> > Anyway the problem is not the way you, me, IETF sees the things. The
> > problem is the way the concerned external parties see them. Inquire by
> > yourself.
> >
> > > >Since you do not want to call a debate on "complement RFC 3066"
> rather
> > > of "replace RFC 3066", and do not want to consider the Charter  issues
> in
> > > the WG, it seems you want them discussed in the brouhaha of the IESG
> Last Call.
> > >
> > >First, it's not sure the IESG Last Call will create a brouhaha.
> > >Many IESG Last Calls go by without much discussion. This one may,
> > >or it may not.
> >
> > This depends essentially on the "complements/replaces"
> >
> > >Also, as Randy has said (repeatedly), the Charter is up for debate
> after
> > >we have done our work. IETF WGs don't start their work by a charter
> > >debate; if this was ever done in the past, it was abandoned because
> > >it would be very unproductive.
> >
> > Here I am lost. I though Randy was using this "after we have done our
> work"
> > as a delaying joke. Now you repeat it, I must consider you say seriously
> > that an IETF WG (and this is your intent in this case) is to commonly
> > understand the work to achieve in common once that work has been done?
> This
> > is not exactly my own experience of IETF WG, but I am to say that the
> few I
> > shared in have not been successes... This may the reason why?
> >
> > It rings Alice in Wonderlands to me. But if you say it is the way WG
> > proceeds ... I would then be interested in getting a calendar and a
> > procedure. When are you going to send a mail with a subject like "let
> > understand the work we had to do"?
> >
> > > >This may give more support to the proposed additions by more
> > > legal/political oriented people. I will not oppose this due to the
> very
> > > reduced number of participants to the WG Last Call. But beware that if
> > > the document is not mended during the last call, this will probably
> lead
> > > the document to be rejected at some stage (IESG Last Call, IANA, etc.).
> > >
> > >If it turns out, during IETF Last Call, that there is a preference for
> > >a "political disclaimer", and if the WG, the AD, and the IESG agree
> > >to some kind of wording, such a "political disclaimer" can be added
> > >at IESG Last Call. In my judgement, this would in no way mean we would
> > >need to have a second IETF Last Call, or that the IETF Last Call would
> > >have to fail, because the political language that would be added would
> > >most probably not change any of the technical provisions of the draft
> > >nor should it change any other aspects such as registry operation.*
> >
> > I feel you read me incompletely. I say that the document will fail at
> some
> > stage. If the concerned parties want to pay attention to the IETF (and
> this
> > is my prayer, so we can preserve the Internet standard process
> credibility
> > in the Multilingual field) they will attend the IETF last call and the
> > Draft will be killed there (what would be sad, since it could fly as a
> > complement). Or it will more likely (I am not going to spend my life
> > fighting an ill fitting Draft) be diplomatically killed at IANA level.
> The
> > procedure has been already engaged.
> >
> > > >As it is, it focuses on an resticted approach, aiming an exclusive
> for
> > > the language industry, against competitive open sources multilingual
> > > network oriented propositions and evolutions.
> > >
> > >[with my chair hat off]
> > >It is quite clear that the current draft tries to address the needs of
> what
> > >you call the "language industry", because people from this industry
> came
> > >forward with actual needs, and worked hard on solutions.
> >
> > Here is the confusion. Some people of the language industry came
> forwards
> > with this proposition. No the industry. I represent another part (less
> > dominant but more pervasive) of this industry. The way they are treated
> on
> > [email-masked] or on this WG (as F. Charles was) did not
> > pushed them to continue. I commentd already the question of Randy on
> this
> > matter, my response and the support I got.
> >
> > There are others who worked hard, I would even say harder and have a
> much
> > broader vision and support, you totally disregard. So we agreed (and I
> > documented) that we will only proceed outside of this WG - leaving you
> > enjoy your format and using the "x-" compatible escape sequence. We
> think
> > it is better to compromise and show usage, running code, etc.
> demonstrate
> > our open position is better, and to expose the bias of the proposed
> > exclusion. We got our "no way" excluding response.
> >
> > This is why, I am probably the only one concerned still considering that
> > the proposition of this WG may have merits, if not exclusive and
> excluding
> > (at least to satisfy the part of the industry you refer to). I also
> think
> > that coexistence is far better than opposition.
> >
> > If I am considered here as the bad guy against the Draft, and outside as
> > the bad guy or the traitor defending the Draft ...
> >
> > >It is in my view completely wrong to claim that the draft is exclusive.
> > >Indeed, while in RFC 3066, the only way to add language tags was by
> > >one-by-one registration, and there were no private subtags, the current
> > >draft is way more flexible and extensible.
> >
> > I am afraid you miss the point here. RFC 3066 is a wrong solution
> > (sometimes named "yellow star" RFC). People were shocked by the timely
> (was
> > it needed, or unfortunate?) registration of Chinese new tags by
> > [email-masked] (according to the non approved Draft format)
> > just before the Yahoo, Microsoft and Google announcement. This lead this
> > RFC 3066 Bis to be qualified of a "linguistic Yalta".
> >
> > 1. I note that you say "there were no private subtags", while other says
> > 1*8alphanum because compatibility with then must be maintained.
> > 2. No one is really interested in the RFC 3066 format and registry,
> except
> > the Unicode consortium people. No problem with that. The proposed system
> > "flexibility and extensibility" (I am not convinced of, in your own
> > perspective due to the unclear process and ISO relations) is perceived
> as a
> > way to control far more the things than before.
> >
> > >A recent example was language tags for different school grade levels.
> > >With RFC3066, you would have had to register en-grade1, en-us-grade1,
> > >en-gb-grade1, and so on. Now, you could (after some discussion) just
> > >register grade1 through grade6 (on more), and it could be applied to
> > >all kinds of languages, wherever it made sense.
> >
> > Thank you for this example: did you ever consider that "gradeN" is
> > meaningless for most outside of your world and that even then, 1 to 6
> may
> > be meaningless as there may be more grades and in different order? We do
> > not want that kind of registry. We want to be ISO 11179 compatible when
> a
> > registry is really to be considered.
> >
> > > >We only oppose the exclusive, the exclusion and the lack of
> scalability,
> > > flexibility, capacity for innovation and evolution.
> > >
> > >Except for purely superficial syntactical issues such as subtag
> length,...,
> >
> > "superficial syntactical issues" .... I love it. You will be permitted
> to
> > have every name you want if it is less than 9 characters long, is in
> ASCII
> > and does not include anything else than 0-Z characters. Look how liberal
> I am?
> >
> > >I haven't seen any evidence from you (or from others) that the current
> > >draft lacks scalability, flexibility, extensibility, or capacity for
> > >innovation.
> >
> > I suppose you believe it! So I will give you some hint.
> >
> > "x-1*8alphanum" is supposed to support all the private subtags in a non
> > conflicting way. Let consider that one gives every user a different
> number
> > to permit them to differentiate their private subtags. With a billion
> > Internet users, we cannot even give a full subtag to all: 9 numerics are
> > needed.
> >
> > Let try to explain people that a cookie name can only be 8alphanum long.
> > Try to authenticate a private subtag using an MD5 key, etc.
> >
> > A full format for a commercial propositions, 8 alphanums for Open Source,
> > Networking, etc.
> >
> > >It would be good if you could document some actual (not superficial)
> > >cases of how the draft does that. As I said above, there is serious
> > >evidence in the draft that it actually does the contrary: It greatly
> > >increases scalability, flexibility, capacity for innovation and
> > >evolution.
> >
> > No. It greatly increases scalability, flexibility, capacity for language
> > control and evolution reduction to the profit of a dominant part of the
> > commercial language tools industry, because of its exclusive.
> >
> > If the Draft is a complement of RFC 3066 and permits undefined content
> of
> > the "x-tags", permitting every other format to develop and be supported
> we
> > will wind up in a totally acceptable coexistence situation where a
> > "xlang:xxx" is an RFC 3066 retro compatible solution and "<x-xxxx>
> supports
> > all the others. It will then be up to the grassroots process to adapt.
> IMHO
> > (this is what I feel could be a possible stabilisation) "x-abc:xxxx"
> would
> > be a good approach where "abc" is a freely used scheme we could relate
> to
> > CRC format names. This means that x-3066:en-Latn-UK could be a
> legitimate
> > format, also entered in places like "xlang:en-Latn-UK".
> >
> > Obviously, x-tags can support other features the Draft cannot such as
> > multilingual entries (via double indexation: entries use a reference
> number
> > documented by multilingual grids), ISO 11179 intended compatibility
> > supporting locales, MLDN charsets, referent directories, context
> additions,
> > CRCs, etc. ... and as documented Addison and Mark's Draft with their own
> > default format and registry.
> >
> > 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: "Doug Ewell" <[email-masked]>
Date: Fri, 29 Jul 2005 07:47:00 -0700

I have nothing further to add to this thread.  I look forward to IETF
Last Call and to the inevitable appeals.

--
Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/

---

From: "L.Gillam" <[email-masked]>
Date: Fri, 29 Jul 2005 17:42:28 +0100

> From: [email-masked] 
> [mailto:[email-masked]]On
> Behalf Of r&d afrac

[snip]

> I 
> will take a simple example: Domain Names are private yet they cannot 
> conflict. Because we organised the name space for that. As I 
> indicated (and 
> documented) there are many ways to specify the organisation 
> of the "x-" 
> name space so it is both private and conflict free.
>

Jefsey,

Are you considering, for example, the use of Private IP addresses -
the Class B and Class C networks? 
e.g. http://www.michna.com/kb/IpAddressesPrivate.htm

In this scheme, as I understand it, only consenting "machines"
will be referred to by a specific address - e.g. 192.168.0.54
and if you're on another network you should not assume that the
same identifier refers to the same machine.

Similarly, unless you have a private agreement on what follows 
the x-, you should not make any assumptions. Elsewhere, this 
might be described as the difference between "blind" (we know 
what we're getting and don't need to look at it) and "negotiated" 
(we need to make our own agreement about it) interchange.

But, would you willfully ignore the numeric formatting required
for an IPv4 Class B network? It is private use after all.

---

From: r&d afrac <[email-masked]>
Date: Sat, 30 Jul 2005 17:04:36 +0200

Dear Martin,
The problem is simple: this document claims for an exclusive it does not 
support. Exclusive is acceptable if it warranties liberty, stability, 
innovation capacity, equal opportunity for all. Oherwise it is exclusion.

You both acknowledge the right to liberty and you deny it. What is 
interesting is that you do not even ask yourself about the oddity of 
writting a "BCP" opposing documented use and running code. Are you not 
afraid looking a fool when you will be opposed commercial catalogs during 
the IESG last call and appeals ...

At 09:00 30/07/2005, Martin Duerst wrote:
> >At 14:28 29/07/2005, Erkki Kolehmainen wrote:
> >>re your note of 28.7.2005 to Doug Ewell, the following quotation is to 
> me an undisputable hard fact:
> >>  No private-use scheme can ever assure that it will not conflict with 
> another private-use scheme.  That is why they are private! [DE]
> >
> >This pure non-sense!
>
>No, it's not.

Such affirmation should be documented as I did it. Saying that my (correct, 
read ISO 11173, I know ...) example is incorrect proves nothing.

> >The fact that they are private and they permit conflict are orthogonal. 
> I will take a simple example: Domain Names are private yet they cannot 
> conflict. Because we organised the name space for that. As I indicated 
> (and documented) there are many ways to specify the organisation of the 
> "x-" name space so it is both private and conflict free.
>
>Domain names are not private. There is, as far as I know, no 'private use' 
>domain in the global DNS. There are domains that are delegated, to CCTLDs, 
>to organizations, and so on, and within these, these entities may further 
>delegate. That's not at all the same as private use.

Please then define "private use" if not free usage within a private zone 
namespace (IETF) or value domain ISO?

>Private use, in the DNS, would mean e.g. that a .private domain is created,

????

>where anybody could input their own subdomains without a central check.

Central check ??? I am a ccTLD Registry Manager. I  impose no constraints 
on the registrants I serve except protocol's hexatridecimal. It is true we 
are to work very hard to correct, in the field, the impraticalities you 
(partly unwillingly) co-imposed us through IDNA...

>Two different entities could both create mydomain.private. In DNS, this is 
>of course possible in local experiments (so it's truely private), but
>not in the globally visible DNS.

Yes. This is why a domain name can be used as a unique identifier in an 
item scheme (ISO 11 ... I know)

>If you want careful delegation for language tags, then what you need to do 
>is to create some careful proposal and apply for a one-letter prefix
>(other than x).

"Delegation" is a Mokapertis' concept to manage the academic havoc he had 
to connect to "my" naming system. I never delegated anything to ARPA: I 
said "ARPA" is what you want?  there is no one else yet using it?  Vida, 
please register it so others know where they are. And Vida Stafford nicely 
did it, as she managed all the other "TLD"s for years.

What you are describing here is an ICANN dream, or a left-over of the 
Legacy Days.

What I say is simple (and would think the author of docs on URI would 
understand it). It is:

1. To warranty the possibility of non conflicting private use you can:
- either organise it
- or permit others to organise it.

2. If you want to know how this is going to be organised, you look at what 
is a (item) scheme (ISO 117... I know, but aslo some RFCs) and you go by 
the book. Now you can create your own language-scheme registry or you can 
accept existing unique IDs as roots for these schemes.

> >I am only sorry that you comment Doug remarks and my remark on its 
> proposition, rather than the answer I made Doug requested.
>
>Last call is not about having questions answered, it is about making
>comments, usually with concrete suggestions for improval.

Doug challenged me to show his solution could not fit the need. I shown it. 
The ball was in his field. I see he sent it out.

> >I understand why, but so will IETF/IESG/IAB/GAC/WTO/IANA. I would be 
> interested in your comment on the problem rather than a repetition of 
> your ideas.
> >
> >>... and the following highly commendable:
> >>  The scheme proposed in the current draft does prevent conflicts with 
> existing parsers that conform to RFC 3066. [DE]
> >
> >The "highly commendable" is an odd hyperbole. It is correct, or it is not.
> >
> >It is correct only if private use is removed from RFC 3066. The current 
> draft does NOT prevent conflicts with existing parser that conform to RFC 
> 3066 in the private area. This is precisely this claim which is wrong, 
> which is objected by  the previous claim above (you cannot say both: 
> there will always be conflicts and at the same time you prevent 
> conflicts). This reality is not an enhancement called by the Charter.
>
>The above sentence refers to syntactical conflicts. The earlier sentence
>refers to usage conflicts. These are different things.

:-) No big deal, but even a lawyer would turn me right on this one. Reread it.

> >We are here in a search of a consensus. So, we are not really interested 
> in what you support or not: we are interested in what to do for both of 
> us to agree.
>
>To be exact, rough consensus. This does not mean that everybody has to agree.

Bravi for the exclusensus!
JFC wants to agree with everyone, why would we care?

> >I said the two simple things for that:
> >
> >1. not to claim to replace RFC 3066. I do not make it a critical point 
> for the user community however. RFC 3066 is an error. Replacing an error 
> by another error is no big damage. It is however critical for the IETF to 
> decide if it will document the Multilingual Internet or not, as no 
> serious non-US industry aficionado will use that system. We are making 
> IDNA again. Your decision, at the end of the day I am not concerned. I 
> think Harald documented enough, and Brian Carpenter's responses and 
> attitude seem to confirm, and this WG-ltru main topic of interest 
> documented it: IETF is simply not able to understand the problem and 
> should not get into it.
>
>I think there are three different goal that one may look at:
>
>1) a system that allows everybody to use their language(s)
>2) a system that allows to tag any language in use, in a way for others 
>(humans and systems) to determine that language
>3) a system that allows anybody to create tags they personally like to tag 
>any language

This could do, but I will note that the wording implies a vision 
(disrespect IMO) of others I object. This is not an ethical arena, so I 
will not dispute it, but this has technical implications. There are many 
things these goals overlook: in what do you think this wording is IETF 
specific and could not be ISO or Leonardo da Vinci's?

This is typograph language, not networking standardiser.

Let phrase it another limited way you should be able to accept:

1) a system supporting end to end interoperability (what you would probably 
call internationalisation)
2) a system supporting brain to brain interintelligility (what you would 
probably accept to call multilingualisation)
3) a system supporting community interculturation (what you will probably 
object if I call it vernacularisation)

I use "supporting" because you do not refer to tags in (1). I do not refer 
to language because I do not know what a language is, nor a text, nor a 
character, nor a script, etc. in a computer network environment. I will 
take a single example. Script means to scratch the medium to memorise
a part of the content (stone, clay, paper, etc.) to be read by human. Today 
script (and this is your main problem) means a form of temporary 
representation to help the reading through a machine assistant and which 
belong to the content's "architext" (technical source of the text) attributes.

>1) is mostly possible now (with the exception of some languages for
>    which scripts or letters are not yet encoded, which is an extremely
>    low percentage of users, and is being worked on (mostly by the
>    Unicode consortium))

! most of the language are oral.

I an not interested in Unicode consortium here (however I am a paying 
member of it). It is only concerned as in support of ISO 10620 and 15924. 
Unless you consider CLDR? CLDR is certainly a contentious political and 
commercial point. But CLDR is only quoted in Charter. And its boss refused 
to document it and its Copyright policy.

This affirmation shows also a deep lack of information of the matter 
considered (for external future readers).
- today a few hundred languages are documented
- there are 7500 plus extensions in ISO 639-3 and 20.000 in ISO 639-6.
- difficult to discuss since the language concept is not defined - even by 
your WG's draft, and ISO 639-4 is not published.

>2) is what this WG is about. With all the extensibility, my understanding
>    is that we have a very good base.

We do not discuss the base in here. We discuss the semantic of the tag 
permitting its use. This tag wanting to be exlusive is built according a 
non acceptable scarcity not permitting an elementary support except in 
accepting the dominant publisher default context as a forced reference.

You can have any color if it is black.

>3) may be what you want. It may sound great, but it's not helpful
>    for interoperability, and it's not a goal for this WG (although
>    with private tags, it's actually possible with the current draft).

Incredible!

- "it sounds great" but a absurdity about interoperability .... did you 
simply read the filtering part???
- "this is not a goal for this WG" so I fordide it forever for the Internet
- "it is actually possible" (what means it is legitimate) this is why I 
make sure it is not practically feasible.

>There is of course nobody claiming that it is forbidden to anybody to
>create language tags (or any other tags) to their liking. But

Incedible!

Yes, there is one: you!
You make sure that this is forbidden to anyone through the sentence 
"replacing RFC 3066". Or in refusing to consider the last call text I 
propose if you want to keep that sentence.

> >I think that if this is the attitude, some wording should be reviewed by 
> the authors, to protect their future pride.
> >2. no to use a joke to exclude the real world. This joke uses  two 
> elements: "x-" and "8alpha". They are orthogonal. There can be three 
> responses to that:
> >
> >- either to make "x-" free from limitations. You oppose: it is not 
> compatible to RFC 3066. I say I do not care (I am the user) but you want 
> to force me to do what you want. For my good sake, so I stay compatible 
> with the past I never had.
>
>You are not *the* user. You are one of many users.

funny.
Future readers please note the contempt for the user I am and the users I 
defend and represent for 27 years. Hopefully we went through some other 
cases like that :-)

> >- either to create "0-" as a new zero constraint area. This has no 
> problem of retrofit.
>
>Is it allowed by the RFC 3066 grammar?

? I do not understand what the RFC 3066 grammar has to do with the 
_addition_ of an escape sequence. ????

> >The only opposition could be that the authors lose their grip on 
> language tags and industry. But they claim they are not commercially and 
> politically biased. So there is definitely no problem.
> >
> >- either to keep the existing text to make sure it will probably never 
> be used. The inconvenience for some will certainly be real, and the load 
> imposed on us to oppose will be heavy. But the protection granted to many 
> many more is worth it. All the more than Liberty does not mean for us to 
> win anytime soon, or even to win. Just to delay the mistake until the 
> better solutions we work on have taken off and the existing other 
> solutions which are not aware of the threat have been informed (I note 
> that since this Draft claims to be compatible with RFC 3066, nothing 
> impeach the W3C to make it a W3C document tomorrow, or the IESG to make 
> it a complement to RFC 3066 as we propose it).
> >
> >I would not want to be in Randy and Martin shoes today. "0- or not 0-"
>
>I'm wearing sandals today, and am feeling well in them :-).

For further readers, please note that Mercurio wore scandals with a typo 
today :-)

Fun apart, you decide or yourself. I suppose you want to have your final 
text ready for August 2nd, last time. Beware that with the Draft editor 
delays, you are now turning late.

Just tell us when the Last Call over, so I can work on its statistics.
jfc