RE: Last Call: 'Tags for Identifying Languages' to BCP

At 04:41 29/08/2005, Peter Constable wrote:
> > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com]
> > This means that the legitimate URI tag:
> > "tags:x-tags.org:constable.english.x-tag.org"
> > must be accommodated into the format
> > "x-xxxxxxxx-xxxxxxxx-xxxxxxxx-etc." instead of
> > "0-x-tags.org:constable.english.x-tag.org"
>
>As I mentioned in another message, Mr. Morfin submitted a request to the
>WG that the syntax in the draft be loosened to permit tags of the form
>indicated, and that the consensus of everyone else in the WG was to
>reject that request on the basis that (i) it would result in backward
>incompatibility with existing processes designed to conform to RFC 3066,

Dear Peter,
thank you to repeat your argument so everyone understands that the 
principle of the draft is:
- to keep conformity with what never existed before (by nature new 
applications have never used RFC 3066)

>and (ii) it was possible to create a scheme for semantically equivalent
>tags without breaking compatibility with RFC 3066.

- repeating this ad nauseam in carefully avoiding to explain it does 
not help. Just document this in the case of example above. Since it 
is "possible to create a scheme for semantically equivalent tags" 
spell out the resulting tag.

 > Peter takes a loosely applied chancy non-exclusive proposition, to
> > make it the significantly constrained exclusive rule of the Internet
> > instead of correcting it and following the ISO innovation (ISO 639-6
> > and ISO 11179) as directed by the Charter. This permits him to
> > exclude competitive propositions following or preceding that
>innovation.
>
>The LTRU charter makes no reference whatsoever to ISO 639-6 or to ISO
>11179.

Repeating errors and response, makes that by-now the entire IETF must 
know by core the Charter says: "[the WG] is also expected to provide 
mechanisms to support the evolution of the underlying ISO standards". 
It happens you were just kind enough to document the latest 
"evolution", back from the yearly ISO meeting in Varsaw. I quote your mail:

<quote>
I'm on my way home from the TC 37 meeting in Warsaw, and thought I'd 
give a quick update on projects in the ISO 639 series.

ISO 639-3 is being advanced to its last stage, FDIS. If things stay 
on schedule, the FDIS ballot will be over  and ISO 639-3 will be an 
ISO standard -- before the end of the year.

Work is progressing on ISO 639-4 and ISO 639-5. These are not 
expected to have much impact on RFC 3066 or its successors, though 
(unless we change our minds about wanting to use additional IDs for 
collections).

  An updated working draft for ISO 639-6 was made available just 
before the meeting. The leads for that project have been working 
through the impact of adopting the ISO 11179 framework for that 
project. The working group gave them the go ahead to reference ISO 
12620, which (roughly) is the TC 37 counterpart to ISO 11179. They 
may still need to reference directly to ISO 11179 for certain 
purposes. The team for that project will be preparing a new working 
draft this fall for review by the working group, with the aim of 
getting it reading for a CD ballot  so potentially a CD ballot will 
be distributed before the end of the year.

</quote>

>As I have explained elsewhere, Mr. Morfin's suggestion that the
>draft is incompatible with ISO 11179 while his alternative would be
>conformant is far from valid.

The whole IETF must also know by core that I proposed the Draft to be 
ISO 11179 conformant and I was opposed by an unanimous "consensus" 
you documented. But I know that in repeating the same proposition you 
usually decide the opposite. You already have documented that the 
Draft was ISO 11179 compatible. I suppose you will soon tell it ISO 
11179 conformant.

None will be happier than me. And - as I proposed you already several 
times privately - I am fully ready to cooperate to make it a reality.

>  Finally, I have not excluded competing
>propositions; I was one voice among many that rejected a request to
>permit "." and ":" in the syntax, and to my recollection no other
>concrete proposal wrt syntax, let alone an overall system of metadata
>elements, was submitted by Mr. Morfin to the WG.

The whole IETF must also know by core that I proposed, want and was 
denied the support of URI-tags along the URI-tags RFC (unfortunately 
the number of that RFC has not been allocated by the Editor). And 
that I support a global compatibility in having your ABNF as a 
default and the URi-tag area introduce by the "0-" reserved singleton.

> > With the trick above: length and character wise a private tag is a
>subtag.
> > .... and the lack of explanation of how billions of machines will
> > know about the daily updated version of his 600 K file, without
> > anyone paying for it, but me and the like.
>
>It is completely unclear on what basis Mr. Morfin is suggestion that
>billions of machines will need to update "my" (?? I did not create it!)

No offence in giving to Caesar what belongs to Caesar. A long work I 
fully appreciate, with practical serious pros and some cons. But a 
blockage over an exclusivity you cannot obtain and which is 
detrimental to every interest you defend. Ruling the world on 
something is fun. But it only works if you serve, not if you want to lead.

>600K file on a daily basis. There is no indication or likelihood that
>the language subtag registry proposed by this draft will change with a
>frequency approaching anything close to daily. Indeed, it is entirely
>likely that it will change rather less frequently than the RFC 3066
>registry was likely to change.

This file which includes ISO tables and will have to follow the ISO 
table evolution. From the input of Doug Ewell its _initial_ version 
withISO 639-6 will include 40.000 lines. So a change a day would 
represent only 1% change, update and addition, for a registry 
established to accept additions.

But, Peter, what you do not probably realise since the WG has not 
worked on the matter, is how such a system is to work. We all have an 
well established 22 years old experience in the area. This is the DNS 
root. The DNS root is changed 60 times a year. However it is updated 
twice daily. Why? Because whenever you access a copy of it, through 
whatever mean and successive copy,you MUST know if the content is up-to--date.

So, however it may be updated far less than one correction a day, 
what I think realistic from other tables, it needs to have the update 
date changed every day. And one way or another every user must know 
everyday (unless you still consider there are "end-users" of lesser 
concern who may be more poorly served). One can find solutions to 
that (I proposed monthly updates), one can devise other mechanisms, 
one can use the DNS, etc. etc. But one has at least to allude to the 
solution the IANA is to adopt. One did say "I create the list of the 
ccTLDs: up to the IANA to imagine the DNS".

Interesting.
jfc