> From: JFC (Jefsey) Morfin [ mailto:jefsey@xxxxxxxxxx]
> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf