Message-Id: <6.2.1.2.2.20050808003809.056569e0@mail.afrac.org>
Date: Mon, 08 Aug 2005 02:49:08 +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: <42F66D85.7DE5@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>
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

At 22:22 07/08/2005, Frank Ellermann wrote:
>r&d afrac wrote:
>
> > However, your answer does not address the point.
>
>Yes, the tag: URI scheme is beside the point for this WG.  I
>discussed it on the uri@w3 list, not knowing that it's already
>approved, but some of its problems with percent-encoded email
>addresses and STD 66 oddities also affect problems with the
>mailto: and news: URI schemes.  That's fascinating, but really
>unrelated to the language tags of 1766 / 3066 / 3066bis.

Dear Frank,
I think it is related. You probably know better why there is a W3C 
disclaimer. But  there is a W3C disclaimer  but there is no IESG 
disclaimer. The IESG charter calls for bettering RFC 3066.  The IESG 
approved the tags RFC in the meanwhile. "x-" privateuse needs IRI tags to 
work. So ...

>Maybe relevant for your alternative schemes, if you want to
>allow characters that are not allowed in STD 66 URIs.

> > The reason why RFC 3066 bis is supposed to be urgently
> > needed is a better support of XML. This has been widely
> > documented by Addison.
>
> > I contested that point because I think that this is
> > detrimental to the users
>
>I also "contested" it, IMHO we need the explicit scripts,
>because with Unicode that's not more an implicit attribute
>of the charset.
>
>It's not detrimental for users.  It's better than the old 3066
>rules.  It's the best possible solution compatible with 3066.

I understand you want to get it, I do not object. But I object you want to 
impose it to me who do not want it.

>It's a necessity, we won't win a price for the most beutiful
>standard with our "Suppress-Script" kludge.
>
> > I also contested it because this is inadequate to the
> > network architecture needs and does not properly scale.
>
>Support Bruce's Content-Script I-D if you like it better.  I've
>no problem to do both at the same time, support 3066bis _and_
>Bruce's idea.

I do not any support specific scheme. I support flexibiliy: that the user 
can chose, define and use the schemes he needs, along with his own 
needs.  This is why I propose we work on an IETF language framework to 
replace RFC 3066, and to organise all the different identification tag systems.

> > I also contested it because the limited number of subtags
> > gives a commercial unfair dramatic advantage to the market
> > dominant publishers with a dramatic ecocultural impact.
>
>I don't see any "commercial advantage". But the _technical_
>problems with the "most perverse tag" were real.  That was a
>point in the old last call. Nothing is wrong if standards are
>implemented, and if some implementations are "commercial".

I am not sure I understand all. What is wrong is when the standard favors a 
commercial implementation and blocks others or open source projects.

>I certainly hope that my next box will run under a "free" OS,
>with a browser supporting UniCode and 3066bis and CSS.

I wish I am sure your next free OS box is free of locale related patented 
features. You may recall that one of the first questions I rose was about 
the CLDR IPRs. You may recall the Javascript issue between Netscape and IE.

>And if
>that's exactly what *** wants me to think it doesn't mean that
>it's necessarily wrong.  One company where I'd have serious
>reservations has less than three letters.

The point is not to say if someone is right or wrong. It is to support 
everyone's needs.

> > I was convinced this was a true genuine request of the W3C.
>
>We're here because the IETF last call of the old draft found
>problems above editorial nits, not "on request of the W3C",
>ICANN, VeriSign, Unicode, Redmond, IBM, Thorvald, or who else.
>
>Somebody, IIRC it was John Klensin among others, proposed to
>do it in a proper IETF WG.  Where is the problem with this ?

I was one of those who asked for a WG. The reason why is that a WG has a 
Charter and should have permitted an open debate further to a clean sheet 
review of the Charter. Randy asked me to tell the IESG I supported his 
project.

I still wait for that review.

> > in the archives of this WG-ltru the mention "Chair, W3C
> > Internationalization Core Working Group" appears 168 times
>
>Yeah, maybe, so what ?  Probably as often as "Quest Software".
>Or "AFRAC".  Or "xyzzy".

Correct. But I am here as AFRAC R&D.
Randy says he is not as W3C.

> > his proposition is private and has nothing to do with the
> > W3C, what makes the Draft lose my support.
>
>We're all supposed to contribute / work as individuals.  It is
>an IETF standard, we play by IETF rules.  We've even discussed
>to appoint a W3C liaison, but then we agreed to do it solely by
>IETF rules without such formalities.
>
>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?

> > he does not consider a W3C disclaimer as did S. Hawke,
>
>The BCP 78 / BCP 79 boilerplates are bad enough, inventing new
>"disclaimers" would make it worse from my POV.

????
jfc


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru