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

["JFC (Jefsey) Morfin" <jefsey at jefsey.com>]

At 04:41 29/08/2005, Peter Constable wrote:
> > From: JFC (Jefsey) Morfin
> [
> mailto:jefsey at 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


_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf