No, I really meant "pick one", since doing any combination I of the three that I have been able to think about would just produce more confusion.
John,
please review your propositions. They are not fully satisfactory because each address (correctly) only one part of the problem. I suggest you reduce the whole confusion to different identified sub-problems. Your solutions are correct, for an RFC context.
What is needed here is, IMO, less confusion, not more.
Correct. This is why I suggest the above. The first confusion is about what a language/country may be. The draft assumes that a language is an ISO 15924 code (and a country an ISO 3166 2 letter code). This fairy "simplification" of the reality is the main source of confusion.
>> (i) Since we have no "Next-Best Current Practices" >> category, publish this as an Informational Document, >> moving it to BCP (and to "obsoletes 3066") only when >> revisions of all documents that reference the 3066 >> registry (that includes not only IETF standards-track >> and BCP documents, but also the ICANN IDN registration >> procedures document and perhaps others) have been >> written and have achieved community consensus. > > 100% in agreement.
To follow up slightly on Ned Freed's comments, I don't really see any procedural way to do this, since it would require synchronizing things that would likely defy synchronization. That is especially true because we can't guarantee knowing about all of them. But, since it is theoretically possible, I thought it deserved mention. But one cannot both publish something as an informational document and as a standards-track/BCP one, which is what the second option calls for.
Full agreement. It is not feasible but it is mandatory: before being a BCP it has to be a practice. This is why the draft can only be accepted as informational in the RFC 3066 area, and to call for a effort towards an interapplication consensus under IAB guidance: the "RFC 3066 ter" idea that nobody opposes. This last document will target to be a standard and to replace RFC 3066. The claim of the draft's author is not to publish a standard, but an enhancement of RFC 3066. (They accepted the matching part cannot belong to a standard).
>> (ii) Revise the introductory material in this document >> to indicate that it is an alternative to 3066 that may >> be more appropriate for some purposes and identify at >> least some of those purposes. Revise the "registry >> conversion" material to provide a way to seed the new >> registry and, if appropriate, providing for >> simultaneous registration in both registries for new >> submissions. Based on those changes, indicate that it >> modifies ("updates") 3066, rather than obsoleting it. >> Most of my important concerns, although not some of >> those that have been raised on the IETF list about >> details, would disappear if this document paralleled, >> rather than superceding, 3066. > > idem.
See above
idem. Indicating this is informational, and to work towards a further consensual document, matches your propositions one and two.
I have no idea what you are talking about.
I am afraid this is the problem. We are not in your technical academic field. We are in real usage, with commercial machines, supporting real life exchanges with legal, cultural, etc. aspects. With real technologies, buiness plan, billions of users and hundred of thousands of micro-cultures etc. What you discuss leads to two disconnected geolinguistic grids. The same as IDNAscii leads to nowhere, the same as IPv6 leads to NATs, this will lead to confusion. Please let us stop being academic and let start being realistic.
> ISO provides lists. Internet is about networking and needs > internetworked lists. This internetworking calls for > additional ad hoc descriptors.
Which is what 3066 does.
No. The two descriptors being used are the language code and the country code. To some extend the scripting code is added. They are not able to render all the dialects, regions and cities, areas, history, cultures, etc. and all scripting, speaking variations and vernaculars the applications may require - yet they assume they are. Most of all, networking them calls for two key missing information in the tag: for which purpose and by which authoritative who is this networking being made. This results into a lot of subjective competent comments on the lists. I am sorry I do not ask my telephone to be academic, I only ask it to work - in my daily world. And this RFC 3066 stuff does not scale.
So the questions remain as to what real problems we have in internetworking that 3066 does not solve and, if there are such problems, whether they can be fixed by a less radical and complex change to the 3066 framework.
There are two basic problems with RFC 3066 and its replacement, a part from the "details" you discuss.
- RFC 3066 is meant for applications layers and does not fit well with the network architecture (RFC 1958) and IANA procedures. I over documented that. But you know this better than me.
- "RFC 3066bis" wants to fix some of the W3C needs, in a way which would make these patches Internet standards. This is not the appropriate way. (There is a W3C document on its way, why two?)
Please, some step by step, serious approach. I documented that already too many times:
1. let start from RFC 3066 which does exist
2. let accept "RFC 3066bis" (after the 09.txt has been reviewed) only for the RFC 3066 users who say they need it.
3. let open a debate on the need for language tags - may be with a specialized WG.The first step will be:
- to define what is a language as far as the internet is concerned
- to document where are they used and to which end (existing protocols, procedures, charters and liaisons groups)
- to identify what are the different parameters permit to fully identify them and which way additional descriptors can be added
- to work on their relations, towards the matching algorithms to be researched
- to look for which existing list could be used to document each descriptor and how to adapt them to the Internet requirements.
4. let work out a consensual way to define a usable and innovation supporting tagging for them - if this is possible.
5. let demonstrate these tags are useful to the identified applications, through a validation by their concerned entities.
I am sorry but doing it the other way around, i.e. starting from an ISO list and adding another ISO list and another ISO list in the hope this will represent the world's reality may look simpler but ... looks surprising to me and not of big use.
But I will not oppose those who enjoy it. I said I would drop the matter and will look for field results of the outcome.
Take care.
jfc
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf