Message-Id: <6.2.1.2.2.20050808173842.03e6ac50@mail.afrac.org>
Date: Mon, 08 Aug 2005 18:33:01 +0200
To: Frank Ellermann <nobody@xyzzy.claranet.de>, ltru@ietf.org
From: r&d afrac <rd@afrac.org>
Subject: Re: [Ltru] Re: W3C tag policy disclaimers and IETF RFCs
In-Reply-To: <42F76A26.6F4@xyzzy.claranet.de>
References: <F8ACB1B494D9734783AAB114D0CE68FE06BBA085@RED-MSG-52.redmond.corp.microsoft.com>
	<42F60ECC.E62@xyzzy.claranet.de>
	<6.2.1.2.2.20050807161837.05694d40@mail.afrac.org>
	<42F66D85.7DE5@xyzzy.claranet.de>
	<6.2.1.2.2.20050808003809.056569e0@mail.afrac.org>
	<42F76A26.6F4@xyzzy.claranet.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: 
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

Dear Frank,

At 16:20 08/08/2005, Frank Ellermann wrote:
>r&d afrac wrote:
> > I object you want to impose it to me who do not want it.
>If you don't like 3066bis language tags don't use them.

:-) This is unfortunately not possible.
RFC 3066 is a most unfortunate legacy of Harald Alvestrand. As an RFC and 
as a BCP. If the Draft is accepted it gets an _exclusive_ over language 
tagging/identification. The IESG like it or not. Some IESG people seem to 
feel they have been trapped into this problem.

>All language tags I'm personally interested in (on my
>Web pages) have a Suppress-Script: Latn.  From my POV
>nothing changes, I can even keep one en-GB-oed.

I am personally interested in ISO 11179 compatible 20.000 language tags.

>Why should I join you and try to derail a draft allowing
>scripts for those who need it ?

??? Please stop thinking as Addison is. This is not a competition !!!
No one asks you to "join me". We only as why would you exclude us and 
derail our approach, while we permit all yours?

>All problems in the old draft as far as I could identify them are fixed.

No. All the non Draft ABNF conformant format are excluded from the Internet 
standards.

>I'm not at all interested in private-use language tags:
>Do what you like and hurt nobody.  If that "restricts"
>you to letter-digit-hyphen and at most eight letters or
>digits before the next hyphen laugh about it, use UTF-8,
>encode it with base-64, insert hyphens, ready.

1. there is no reason the world messes all its formats to please Harald's 
old fancy
2. but even if the world accepted it: I documented practical case (K/H RFC 
conformant) which cannot be supported IMO. No one responded except by ad 
hominem.

Without taking them again: these formats use ":,@/.?=%-" characters and 
"xn--" please document how you support them in hexatridecimal.

>"Jefsey insists on some funny private tags" would be
>SmVmc2V5IGluc2lzdHMgb24gc29tZSBmdW5ueSBwcml2YXRlIHRhZ3M=
>resulting in:
>x-SmVmc2V5-IGluc2lz-dHMgb24g-c29tZSBm-dW5ueSBw-cml2YXRl-IHRhZ3M

this example is a joke. Respond the question above.

>Okay, case sensitive won't work, so find the RfC about
>base-32, or roll your own encoding scheme.  If you're
>lost take hex. 0123456789ABCDEF and insert hyphens after
>eight hex. digits.

:-) Are you not a little bit kidding?

>If length doesn't matter percent-encode it replacing all
>"%" by "-".  If that's not good enough for whatever you
>want check out Dublin Core or similar activities.

:-) I am sure now you are kidding.

> > What is wrong is when the standard favors a commercial
> > implementation and blocks others or open source projects.
>
>The proposed standard favors KISS and compatibility with
>existing 3066 implementations.  Apparently the latter is
>irrelevant for you, in that case you're free to propose
>whatever you like.

No intent to oppose. I just add the "0-" sequence.

>Obviously not more related to LTRU -
>see the WG charter - but if you find new and interesting
>applications for the future registry ignoring the syntax
>for combined tags, just do so.

I am not considering "future" applications. I have long, long standing 
applications. It is as simple as that: or you add yours in a way which does 
not hurt ours (or we can accept to adapt to) or they will be denied.

>After all that's exactly what we did here, combined stuff
>found elsewhere to 3066bis tags.

Obviously not. Or there would be no problem.

>You're free to use the
>3066bis subtags in completely different ways.  Or free to
>ignore them if they don't do what you want.

No, I am not. But I am free to use Internet standard process rules and 
international agreement to block what is hurting my interests. Since I 
observe that my interests are also those of the German, of the French, of 
the EU, of Chinese, of Indian, etc. etc. interests I do not really feel 
alone in the process :-)

The only problem I see with these guys is that they dont feel it is 
appropriate to step down in an IETF WG and do not want to oppose to this 
before it is at IANA stage. This means they will kill the project (until 
now I wanted to protect it, as I thought it was a W3C proposition) what may 
be a problem for some, as you point it out. This also means at least one or 
tow years delay, what interests no one.

> > I wish I am sure your next free OS box is free of locale
> > related patented features.
>
>Software patents in our part of the world are meaningless.
>
>Has somebody really patented locales ?  I hope they catch
>him before he hurts himself or others, he needs medical
>care in a closed environment.

You may be the one proposing it. I suggest you consider the CLDR project 
carefully.
It may be a fully open source project for Windows? It may be a Windows 
project for Linux?
I do not know: I asked and responses were refused (search archives for 
jefsey and CLDR).
I think the question to be important enough to be asked and answered.
I am at least sure some in the community will too.
As people in Brussels also do.

> >> Of course the result will be something W3C and Unicode and
> >> ICU can live with, and it will be also something IMAP, MIME,
> >> etc. can live with.  That was the purpose of this LTRU WG.
>
> > But not AFRAC?
>
>No idea, I don't know what "AFRAC" is and what it does.  That
>doesn't mean anything, I also have no clue about IMAP, I only
>trust that Ira, Ned, or Bruce would tell us if we try something
>that won't work with IMAP.

But you deny me the right to tell you that it does not work with us?

>So far all you told us about "AFRAC" was that it distributes
>CD ROMs mirroring IANA registries, and we calculated that the
>maximal registry size after the addition of 7000+ languages
>(= 3066ter, not more 3066bis) could be about 500 KB and still
>fit on your CD ROM.

It works on CRC (Common Reference Centers - distributed granular dramatic 
extension of IANA). Just go look at http://afrac.org. This means ISO 11179 
compliant support of tags. Including language tags in any scheme:format. 
Some may want to develop libraries to use a  centralised ASCII scheme as 
the one proposed by the Draft. No objection to that and we will fully 
support it.

But K/H RFC fully documents why this is limited. The Draft for us is like a 
child saying "I know how to read 'abc', I do not want you to read anything 
else". We respect the programers/standardiser language equal opportunity 
declaration.

Our interest is MGN (Multilingual Global NGN).

>Maybe you or AFRAC offer a whois server, query = tag, reply =
>corresponding subtag entries in the complete registry.

Yes. This is one of the key issue we have. An RCP like "shuttle" protocol.
The basic architectual option we took is to have:

scheme:tag -> itemID
query = itemID + authentication
reply = crypted (response)

One of the oddity of the Draft (this is one the many reasons why I say it 
is a "typographer" system) is that however we are in a network the tag name 
is flat. There is an absolute need for a scheme, even in the case you use a 
single central reference center: you must say the origin of the tag. When I 
say "x-jfc-angl" this may be the same as when you say "en-Latn-GB".

Another oddity is that the Draft is so rigid, it must wait years to support 
ISO 639-3 and may be sometimes ISO 639-6. We already use them and whatever 
people want to use, we support them. This is just a double enntry in a 
table....

Another oddity of this Draft is that it does not document the class of the 
tags. All the tags are supposed to be language tags. Languages are 
important, but they are not alone?

But most of all, the Draft is so constrained with its 3 main subtags. I 
obviously understand the reason why :-) ... but that cannot work. So why 
not to correct it.

Definitly "0-" is the solution, unless you propose a better one.... But it 
is also a huge commercial/political loss for some ...
IF the Draft goes through.
jfc













>Bye
>
>
>
>_______________________________________________
>Ltru mailing list
>Ltru@lists.ietf.org
>https://www1.ietf.org/mailman/listinfo/ltru


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru