Message-Id: <6.1.2.0.2.20050316113238.038d4260@mail.jefsey.com>
Date: Wed, 16 Mar 2005 12:24:51 +0100
To: "Addison Phillips" <addison.phillips@quest.com>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: RE: [Ltru] Re: "Obsolete" region subtags
In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0A9F4BB0@irvmbxw01.quest.c
 om>
References: <634978A7DF025A40BFEF33EB191E13BC0A9F4BB0@irvmbxw01.quest.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: LTRU Working Group <ltru@ietf.org>
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

On 22:15 15/03/2005, Addison Phillips said:
>I think you should quit comparing this to iDNS, although I note that iDNS 
>*is* explicitly designed to be compatible with the existing DNS system. 
>This explains many of the idiosyncrasies of its design.

Dear Addison,
I think I am will not quit stop talking about the DNS for two good reasons. 
One is that I am a Registry Manager and represent the Registry Manager 
needs in here. Second is that naming is supported by just other standard 
and applications and has a considerable history referenced in a 
considerable number of other standards, laws, international resolutions 
related to international treaties. It also has another very important 
capacity: the capacity to say "no" to your propositions through its command 
of the IANA as an ICANN function.

>RFC 1766/3066 language tags have a considerable history and are referenced 
>by a considerable number of other standards. Your desire to create an 
>incompatible language tagging system for whatever reason is based on the 
>need for some software applications to be updated anyway? That's a silly 
>bit of logic.

I suggest that "silly" is an appropriate word in here.
Up to now RFC 1766/3066 language tags _are_ compatible and I have no 
problem in living for ever with their present status. You introduce a 
perfectly reasonable need to extend and possibly modify their tagging. What 
I wand to discuss - and I think it very fair - is how these standard can be 
extended and possibly modified to suit your needs and if there is not a 
synergy in a common effort to best support my needs and yours.

I do not see what would be "silly" in this.

>Forget applications for a moment. Think document formats. There is 
>considerable content that contains RFC 3066 language tags. The HTML, XML, 
>CSS, HTTP, SMTP, and many derivative standards use these tags internally.

I understand this. I understand that you are a W3C person, also considering 
Unicode concerns, in an IETF WG. But this should not make you forget that 
we also have the same need/problem in the non-web part of the internet.

Let be clear. You may not want to share my analysis of the five issues 
involved in a "multilingual" internet (interidentification, 
internationalisation, multinationalization, multilingualization, 
vernacularization) and group/name them in a different way. I just repeat 
them so you may understand what I mean. In the network standardization 
process obviously W3C brings experience in interidentification (the 
language of a page as being different). Unicode obviously brings a 
huge/reference competence in internationalization. ccTLDs have a deep 
experience in or are by essence (as State bodies) multinationalization 
(what is discussed when referring to ISO 3166). We have in common a problem 
which is the IAB/IETF lack of interest/competence in multilingualization 
(what we globally approach through the tagging) as demonstrated in the IDNA 
inadequate solution and in the total lack of reference to it in the IAB RFC 
3869.

Now we have two possibilities. Either we join forces to reach a stable 
technical consensus everyone can build upon. Or we engage into a total 
fruitless war where States, i.e. ITU will eventually impose their dictat. 
And I suppose we both know what this dictat will be in the present 
situation, because they have been very clear in several consistent 
universal declarations. This will be in favor of multilingual domain names.

The problem is that it will not satisfy you and it will certainly not 
satisfy me.

>Many web sites use them to select content--which means the server 
>component, not the user agent. Many databases and programming languages 
>use them. Content and data has a long shelf life. Breaking compatibility 
>is a serious step.

I know this for 30 years. This is why we have to be careful. There are 
nearly one million name servers around the world. There are hundred of 
millions of names replicated, aliased in them. Ignoring them in a standard 
which affects them in part will not be accepted. These names are used in 
billions pages, much more times than langtags. The question is not to know 
who is bigger. The question is how can we both serve them better and use 
the possible synergy to still spur more innovation there.

>We have devised a format that updates language tags in a compatible manner 
>to meet demonstrable needs. What application cannot be addressed by this 
>(compatible) design?

I said I had no time to review the draft before the end of the week. And 
the debate has not started on it.  But what I can say from the current 
debate is there are four main aspects:

1. the format you quote
2. the maintenance of the format (what we discuss - management of the code 
lists)
3. the content management (organization and procedure)
4. the selection and registration of content (we are not concerned with the 
content, but are concerned with some guidelines).

IRT point 1 (format) My reading is that up to now you have defined a format 
you checked as compatible with your needs. And rather than considering 
others' need as equally acceptable, you have more tried to keep or consider 
them out of the loop. I submit it is not the proper way.

I agree that in the cases which are my own priorities my support background 
if very weak. I am personally interested in four areas: naming, OPES, user 
centric, CRC, multilingualism, scalability. Naming is ill technically 
supported by IETF documents and is now under grassroots effort with very 
large implications (tens of millions of users) that are totally unknown to 
IETF. OPES/MIDCOM are very important issues seriously documented or pushed 
by the IAB but obviously not mature. User centric is an evolution based on 
the core principles of networking (catenet) but long differed by technology 
limitations which comes back now. CRC are a generalized distributed (and 
therefore compatible) vision of what CLDR targets. I discussed 
multilingualism. Scalability is the core problem of IETF as we see it with 
the 11 years delay of IPv6, etc. Happily the new Chair is probably the best 
documenter of this issue. But probably not his priority.

But these are necessary parts of the evolution of the response of the user 
demand.

If you do not care about them, the demand will not care about your 
proposition. The longer it will take for them to realize it, the more 
confusion will have been introduced, the more time and money the correction 
will cost. The more time you will have wasted. And what will be poor is 
that most probably a lot of good work will have been lost. Consider X.400, 
consider EDI ...

Sorry to have been long. I just do not know how to make understood what is 
so obvious to me and to most of those I know ....
jfc


=====================================================
For your convenience:
Draft: 		http://www.inter-locale.com/ID/draft-ietf-ltru-registry-00.txt
Charter: 	http://ietf.org/html.charters/ltru-charter.html
gmane: 	http://dir.gmane.org/gmane.ietf.ltru
If you were Bcced for information and not familliar with the IETF process:
http://www.ietf.org/rfc/rfc2026.txt
http://www.ietf.org/rfc/rfc2418.txt
http://www.ietf.org/rfc/rfc3934.txt
http://www.ietf.org/rfc/rfc3669.txt
http://www.ietf.org/rfc/rfc3160.txt
http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt
=====================================================
Jon Postel (RFC 1591): "The IANA is not in the business of deciding
what is and what is not a country. The selection of the ISO 3166 list
  as a basis for country code top-level domain names was made with
  the knowledge that ISO has a procedure for determining which
entities should be and should not be on that list."
=====================================================
Brian Carpenter (RFC 1958/3.2): "If there are several ways of doing the
same thing, choose one. If a previous design, in the Internet context
or elsewhere, has successfully solved the same problem, choose the
same solution unless there is a good technical reason not to.
Duplication of the same protocol functionality should be avoided as far as
possible, without of course using this argument to reject improvements."
=====================================================
It seems that what works for countries and ISO 3166 since 1978 should
apply to languages and to ISO 693.
=====================================================


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru