Re: Last Call on Language Tags (RE: draft-phillips-langtags-08)
2005-01-03 17:24:04
On 18:04 03/01/2005, John C Klensin said:
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
|
|