Message-Id: <6.1.2.0.2.20050325140226.03d7f760@mail.jefsey.com>
Date: Fri, 25 Mar 2005 14:02:54 +0100
To: ltru@ietf.org
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: RE: [Ltru] Re: Question
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

On 08:23 25/03/2005, Addison Phillips said:
>content-class: urn:content-classes:message
>Content-Type: text/plain;
>         charset="utf-8"
>
> > QUESTION:  Should the draft implement region-code stability: (a) by
> > preserving all assigned ISO 3166 codes with their original meaning,
> > except those that have already been reassigned, and using UN numeric
> > codes in the case of future reassignments; (b) by allowing UN codes in
> > parallel with ISO 3166 codes, as a preferred alternative, and
> > deprecating the ISO codes; or (c) same as (b), but NOT deprecating the
> > ISO codes?
>
>I support (a).
>Frank has convinced me that I would be in favor of a fourth option (d): 
>same as (a) but include the M.49 codes in the description.

This rises the question of the update cycle of the data of reference.

You can use words of the XVIIth century or talk of a network in the meaning 
of 1960.Perfect language, you will be understood by no one.
This is a general question for the IETF (after how long a release is not 
supposed to be supported).

Retro compatibility is offered for a long nowhere. Try to use your 1930 
telephone set, I am not sure it will work. Try to publish an Internet 1990 
terminology. Try to use the root servers file of 1995, it will may be still 
work partly. Try to use DOS on your PC, it works very well, but you are 
missing a lot of things.

We all use anti-virus which are updated once or twice a week or every day.....
Either we are on the Internet or on the Eternet.

Internet is 22 years old (Jan 1st, 1983). It seems reasonable to consider 
that every Internet related system should survive 10 years. Then, that it 
is to the application to consider how to handle the data. Is XML 10 years 
old, will it be around in 10 years time? By the same token it seems 
reasonable (to avoid date format problem and help stability) that standard 
changes should not occur twice yearly, so a version can be indicated by its 
year (archeological retro compatibility being supported). This permits to 
stay compatible for another 30.000 years in using a double byte.

Operationally wise, it is likely that ISP will convert progressively to 
SNHN management assistance (we see that through the evolution of the market 
and the responses we receive to the CRCD program). It will not be to 
morrow, but we can presume that in a decade the whole network will be an 
NGN system where everyone userbox will be maintained for all the 
"information society" related systems as are our anti-virus today. The Y2K 
shown us that the world can survive this kind of problem. There is 
obviously a need for OS designers to incorporate a universal tag as a file 
header with the date of the file, its MD4, its langtag, possibly its handle.

Objection to a decade obsolecense cycle?

I note that this exactly conforms to the RFC 1766 date (1995). I therefore 
support the consensus on this particular case and propose to make it a 
general suggestion for the Internet standard process (which is only a BCP, 
ie a COULD/SHOULD, not a MUST). This establishes a rule which probably 
solves most of the issues risen in the charter on compatibility in time. It 
addresses the CS issue. It leaves open the SU question.

jfc

======================================================
Standardizing Tags for the Identification of Languages should not be a way
to standardize languages and to unify the world under a dominant culture.
======================================================
For your convenience:
RFC 3066: http://www.ietf.org/rfc/rfc3066.txt?number=3066
Draft: 	http://www.ietf.org/internet-drafts/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