At 04:41 29/08/2005, Peter Constable wrote:
> From: JFC (Jefsey) Morfin [mailto:jefsey(_at_)jefsey(_dot_)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(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf