Subject: RE: [Ltru] W3C tag policy disclaimers and IETF RFCs

From: "Peter Constable" <[email-masked]>
Date: Sat, 6 Aug 2005 20:15:38 -0700

> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of John Cowan

> This is a clear statement of the author's intent to spam this mailing
> list and other IETF mailing lists until he gets his way.  It should be
> obvious to all that this will never happen.

> I call for an immediate warning under BCP 94, to be followed by
suspension
> under BCP 94 and if necessary under BCP 83 as well.

I agree. I came back from a week's vacation to find a barrage of mail to
this list, 40% of which involved this one person's attempt, once again,
to get his way on proposals everyone that had previously been rejected.
This is not collaborative contribution; this is obstruction of progress.

Peter Constable

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

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 07 Aug 2005 15:38:20 +0200

Peter Constable quoted:

>> From: [email-masked]
[...]
>> On Behalf Of John Cowan

That mail didn't make it to GMaNe (or I screwed up), see also
http://www.ietf.org/mail-archive/web/ltru/current/msg03201.html

>> I call for an immediate warning under BCP 94, to be followed
>> by suspension under BCP 94 and if necessary under BCP 83

BCP 83 is Marhall's RfC 3683 about DoS attacks on IETF lists.

Language tags and the tag: URI scheme are completely unrelated,
the latter is something like UUIDs or Message-IDs, it's only an
informational RfC (waiting to be published).  JFTR, bye, Frank

---

From: r&d afrac <[email-masked]>
Date: Sun, 07 Aug 2005 17:44:14 +0200

Dear Doug and Peter,
as everyone knows for eight months now this debate lasts, I consider the 
proposition introduced by Addison and Mark, you sponsor, would lead to a 
terrible world cultural, societal and political catastrophe due its central 
positioning and to the technical inadequacy of its layer violations 
(confusing typography and network needs - and ignoring, refusing to 
consider [as for ISO 11179] or conflicting [as with Kindberg/Hawke RFC] 
with the work of other SDOs, international organisations and of thousands 
of local initiatives), the impact the scarcity of its options favoring the 
language industry dominant commercial interests, against competing and open 
source innovation I work on, or the dangers of supporting political 
discrimination it creates (and it documents in its security section).

As everyone also knows, I still believe that a consensus is possible. 
Because this is what IETF is about.

I will make therefore sure that all the Internet standard process 
possibilities (WG, Lasts Calls, appeals), legal procedures, international 
organisation political fora and conferences are properly respected and that 
procedures insuring their transparency are enabled. As the same time I lead 
R&D and share in Open Source work to technically address the real needs. 
The target is to unlock the exclusion introduced by this proposition, and 
simplify and open it until it permits the ultimate support of _every_ 
stakeholder without exclusive.

I do regret the bias your comments document: the longer it will take for 
you to accept the legitimacy of this effort and to cooperate in a true IETF 
spirit, the latter a final consensus will be possible.

I am sorry but these ad-hominems are not proper technical answers to:
- my question about the ABNF conflicts between the RFC ruling IETF generic 
tags and the Draft, which does not update accordingly the RFC 3066 ABNF 
(Charter: "[registry] likely to be updated by the document ")
- my request to the authors to propose us solutions, to address this 
questions since they refuse my propositions.

On 03:58 07/08/2005, John Cowan said:
>r&d afrac scripsit:
>
> > I only long for clear, stable, efficient, scalable IETF tags we all can 
> use in
> > peace. This is a legitimate demand I will repeat again and again until I
> > get them: this is what the IETF is about.
>

To call "spam" the normal usage of the Internet standard process towards an 
equal IETF success, says a lot of the work unfortunately remaining to 
accomplish before we can reach a rough consensus.

I regret that you consider this WG will never share in a clear, stable, 
efficient, scalable IETF tags. I would not share in it if I did not believe 
it will.

>Since there is at least a good possibility that this WG will continue
>for some time, through the matching draft, RFC 3066ter (ISO 639-3), and
>perhaps even quater (ISO 639-6), I see no reason at all why we should
>continue to put up with this treatment.

I note that this "treatment" is the normal respect of the Internet standard 
process ... I am not sure this is a correct manner to qualify it. May I 
suggest that instead you bring technical answers to technical questions. At 
least we agree that your current technical positions may make this WG to 
last a long time.

>I call for an immediate warning under BCP 94, to be followed by suspension

This is a good documentation of the exclusion spirit of the proposition.

At 05:15 07/08/2005, Peter Constable wrote:
I agree. I came back from a week's vacation to find a barrage of mail to
>This is not collaborative contribution; this is obstruction of progress.

This unfortunately only documents a lack of interest in the WG Last Call, 
the very limited number of contributors and support. This is a real problem 
since a WG LC is to prepare the EISG LC. Excluding the only one interested 
in finding a common consensus will then not help.

---

From: r&d afrac <[email-masked]>
Date: Sun, 07 Aug 2005 17:34:32 +0200

At 15:38 07/08/2005, Frank Ellermann wrote:
>Language tags and the tag: URI scheme are completely unrelated, the latter 
>is something like UUIDs or Message-IDs, it's only an

This is the kind of simple answer I expected to receive! Thank you.

However, your answer does not address the point. The Charter says that "The 
RFC 3066 standard for language tags has been widely adopted in various 
protocols and text formats, including HTML, XML, and CLDR, as the best 
means of identifying languages and language preferences." Let ignore CLDR 
since Mark wants his project to be ignored. But let consider HTML and XML.

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 for the reasons noted in the RFC 3066 and in the Draft security 
sections; and because other solutions (modular documentation of the meta 
elements of a document) exist which are able to far better support the 
flexibility required by architexts. I also contested it because this is 
inadequate to the network architecture needs and does not properly scale. 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.

But I accepted to share in this WG to try to obtain against every odds an 
acceptable opening of the intended closed standard. I did that, and 
documented it many times, because I was convinced this was a true genuine 
request of the W3C. Because in the archives of this WG-ltru the mention 
"Chair, W3C Internationalization Core Working Group" appears 168 times todate.

But Addison says:
- he considers the WG as a competition instead of a work in common, 
violating the IETF commonly agreed spirit.
- his proposition is private and has nothing to do with the W3C, what makes 
the Draft lose my support.
- yet he does not consider a W3C disclaimer as did S. Hawke, what makes it 
also supicious to me.

Then I see that no one (but you) tries to technically respond. That I am on 
the contrary opposed ad hominems (will I be banned for having proposed 
Addison to loyally help him respecting the Internet standard process and 
get his Draft accepted...?).

I must say that I quite lost faith in the possibility to save this Draft.
jfc

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 07 Aug 2005 22:22:29 +0200

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.

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.
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 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 certainly hope that my next box will run under a "free" OS,
with a browser supporting UniCode and 3066bis and CSS.  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.

> 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 ?

> 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".

> 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.

> 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.

Network Working Group                          A. Phillips, Ed.
Internet-Draft                                  Quest Software
Expires: February 5, 2006                         M. Davis, Ed.
                                                           IBM

Network Working Group                              T. Kindberg
Internet-Draft                     Hewlett-Packard Corporation
Expires: August 4, 2005                               S. Hawke
                                     World Wide Web Consortium

Major difference.  Maybe Sandro is an employee of the W3C, and
felt that it's necessary to point out that the tag: URI idea
was his private business.  If you're curious ask him.

Harmless political details at the border between W3C and IETF,
I don't care at the moment.  It also has its funny sides, see
Martin's discussions with Leslie about the proper URI list.

Of course I miss tons of background history, it could be very
important, and I only can't judge it.  Like Haralds fights with
Bob, all these reorganization BCPs.  But in that case I could
at least guess that it was about money paid by the visitors
of IETF meetings and spent for the Secretary.  Or whatever, I'm
no "paying member", it's none of my business.

> I must say that I quite lost faith in the possibility to save

It's not threatened, only Bruce has the power to kill a draft,
because I'd let him if he has good reasons.  The last time he
did it his review was longer than the draft... <shudder />  But
I'm 100% certain that this won't happen with the LTRU drafts.

Okay, the IESG has its own tricks to kill drafts, they approve
them as "experimental", one big experiment with 700.000 domains
and about 10 implementations, one small experiment with a few
hundreds of domains and one implementation.  Because that's too
obvious the big experiment is decreed to be a part of the small
experiment.  An experiment with non-consenting participants -
maybe the G in IESG stands for "Godwin".  It definitely means
that I'm now excessively far off topic, bye, Frank

---

From: r&d afrac <[email-masked]>
Date: Mon, 08 Aug 2005 02:49:08 +0200

>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 ...

>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.

>no problem to do both at the same time, support 3066bis _and_

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.

>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.

>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

The point is not to say if someone is right or wrong. It is to support 
everyone's needs.

>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.

>Yeah, maybe, so what ?  Probably as often as "Quest Software".

Correct. But I am here as AFRAC R&D.
Randy says he is not as W3C.

>can live with.  That was the purpose of this LTRU WG.

But not AFRAC?

>"disclaimers" would make it worse from my POV.

????
jfc

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 08 Aug 2005 16:20:22 +0200

r&d afrac wrote:

> You probably know better why there is a W3C disclaimer.

No, when I wrote "maybe" I was guessing, and when I said
"if you're curious ask him" I meant it, literally.  See
<http://mid.gmane.org/[email-masked]> for
the complete thread, it was with the other tag: author.

> 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.

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.

Why should I join you and try to derail a draft allowing
scripts for those who need it ?  All problems in the old
draft as far as I could identify them are fixed.

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.

"Jefsey insists on some funny private tags" would be
SmVmc2V5IGluc2lzdHMgb24gc29tZSBmdW5ueSBwcml2YXRlIHRhZ3M=
resulting in:

x-SmVmc2V5-IGluc2lz-dHMgb24g-c29tZSBm-dW5ueSBw-cml2YXRl-IHRhZ3M

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.

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.

> 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.  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.

After all that's exactly what we did here, combined stuff
found elsewhere to 3066bis tags.  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.

> 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.

>> 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.

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.

So yes, we also considered that aspect, overall registry size.

We also considered that I really hate to download big files
with my V.90 line.  But 500 KB is okay.  And if it gets worse
somebody will offer split views on the language tag registry:

Maybe you or AFRAC offer a whois server, query = tag, reply =
corresponding subtag entries in the complete registry.  Bye

---

From: r&d afrac <[email-masked]>
Date: Mon, 08 Aug 2005 18:33:01 +0200

Dear Frank,

>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.

>nothing changes, I can even keep one en-GB-oed.

I am personally interested in ISO 11179 compatible 20.000 language tags.

>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.

>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.

>x-SmVmc2V5-IGluc2lz-dHMgb24g-c29tZSBm-dW5ueSBw-cml2YXRl-IHRhZ3M

this example is a joke. Respond the question above.

>lost take hex. 0123456789ABCDEF and insert hyphens after

:-) Are you not a little bit kidding?

>want check out Dublin Core or similar activities.

:-) I am sure now you are kidding.

>whatever you like.

No intent to oppose. I just add the "0-" sequence.

>Obviously not more related to LTRU -

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.

>found elsewhere to 3066bis tags.

Obviously not. Or there would be no problem.

>You're free to use the

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.

>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.

>that won't work with IMAP.

But you deny me the right to tell you that it does not work with us?

>(= 3066ter, not more 3066bis) could be about 500 KB and still

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).

>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

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 08 Aug 2005 21:28:09 +0200

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,  The first thing I'd kill would be
the weird 3166-1 region code zoo.  PN is too small and US
is too big.

But that's dreaming, in reality breaking 3066 compatibility
when it's not absolutely necessary is a bad idea.

>> 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.

> 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".

                          Bye, Frank

---

From: r&d afrac <[email-masked]>
Date: Mon, 08 Aug 2005 23:25:05 +0200

At 21:28 08/08/2005, Frank Ellermann wrote:
>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 
"[email-masked]:addison" and your friends' programs accept it, 
let it be!

>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....

>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.

>immediately get the idea "this is no 3066 / 3066bis tag".

Yes. Addison fully documented that after testing on Mozilla.
jfc