Message-Id: <6.2.1.2.2.20050808224556.03e53750@mail.afrac.org>
Date: Mon, 08 Aug 2005 23:25:05 +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: <42F7B249.2FEC@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>
	<6.2.1.2.2.20050808173842.03e6ac50@mail.afrac.org>
	<42F7B249.2FEC@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 21:28 08/08/2005, Frank Ellermann wrote:
>r&d afrac wrote:
> > there is no reason the world messes all its formats to
> > please Harald's old fancy
>
>As I said, the results would be very different if we break
>backwards compatibility,

Dear Frank,
again, this is not a competition between Addison's proposition and mine. 
This is to find what can support all the needs and not harm the others.

1. Addison wants to preserve backward compatibility. This is legitimate. 
But is of no use for applications which never used RFC 3066.
2. Lee documents that there is actually a possible interest with "x-" 
8alphanum. This can have been used: I fully accept it is respected.
3. we need and use langtags with no relation with RFC 3066. The "0-" escape 
sequence permits to introduce them.

Now, let review the impact on the propositions to make sure it is possible.

1. Addison's proposition is not affected by the "x-" support since it is a 
scheme used by RFC 3066. There is an error that Addison documented if "0-" 
is used. But "0-" is intended to be NOT supported by RFC 3066 compatible 
libraries. So we get what we actually _want_: an error.

2. the impact on our usage is to replace "xxx.xxx:xxx.xxx" by 
"0-xxx.xxx:xxx.xxx". This is a more substantial change. However, we are OK 
to make it. Should we have an agreement on that, we could then introduce 
the multilingual gobal tag proposition I documented in my response to Lee.

3. the Addison's format is a default scheme our libraries are to support. 
So, the Addison's format as no problem with me.

>The first thing I'd kill would be the weird 3166-1 region code zoo.  PN is 
>too small and US is too big.

You should remember that langtags are to be used under many circumstances. 
When the langtag is to specify something related to a country (commecial 
agent, contractual obligations, IPRs, censoring, rates, e-commerce legal 
obligations, etc. etc.) there is no objection.

The objection is to rigidity. The Draft makes me younger. It reminds me 20 
years ago when we discussed X.500 in Geneva. I fought these ideas on the 
same grounds as today (complex ABNF, rigid constraints, etc.). We 
ultimately won ....

You may want to use post codes, telephone areas, states, lingual, business, 
cultural, etc. areas. The real point is not what is in an IANA tables, but 
what you, your correspondant and your programs will commonly understand. If 
you decide to name your local German version 
"0-nobody@xyzzy.claranet.de:addison" and your friends' programs accept it, 
let it be!

>But that's dreaming, in reality breaking 3066 compatibility
>when it's not absolutely necessary is a bad idea.

I would rather say "there must be an absolute necessity to keep a dumb 
stupid compatibility with a four years old arbitrary format". That your 
laibraries have not been updated is a good reason. But the main good reason 
is that you must be able to read old pages which used it. I suppose that 
for some times people found a solution: some are still keeping reading 
compatibility with the Egyptian hieroglyphs but some of us also use ASCII 
code....

> >> take hex. 0123456789ABCDEF and insert hyphens after eight
> >> hex. digits.
>
> > :-) Are you not a little bit kidding?
>
>Look at RfC 2047, IDNA, IRIs, UTF-8, etc.:  Squeezing a new
>concept into the syntactical restrictions of older concepts
>is a bit ridiculous - but OTOH it's necessary if you are
>not free to start the whole Net from scratch.

RFC 1958. There is only one permanent principle in the Internet 
architecture: except that principle everything may, has and will change.

> > I just add the "0-" sequence.
>
>Fair enough, 3066bis doesn't allow a digit as singleton, so
>even the most stupid 3066 or 3066bis implementation should
>immediately get the idea "this is no 3066 / 3066bis tag".

Yes. Addison fully documented that after testing on Mozilla.
jfc


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru