Subject: Last Call on Language Tags (RE: draft-phillips-langtags-08)

From: John C Klensin <[email-masked]>
Date: Mon, 03 Jan 2005 07:56:06 -0500

Hi.

I have been following the extensive discussions of this subject
on the IETF and Language-Tags lists (somewhat over 100 relevant
messages by my rough count, although with the vast major of them
from around five participants).  I note that much of it has not
been explicitly copied to the IESG list.   For a number of
reasons, I've deliberately avoided making public comments to
date, but want to summarize some reactions before the Last Call
closes.

(1)  I had two key concerns when Harald asked me to look at an
early version of this draft.  They continued with the first last
call version, and a still concerns with this version.   They
were and are:

	(i) It is significantly more complicated than RFC 3066,
	which it proposes to replace.  While this is clearly an
	interesting intellectual exercise, that additional
	complexity is not clearly justified.  I.e., if we are
	going to replace a standard that is in
	(apparently-successful) use with one that is more
	complex, the added complexity should be strongly
	justified in terms of requirements and problems being
	solved.    While section 6 of the current draft provides
	some of the relevant motivation, it is not nearly strong
	enough, IMO, to justify the replacement.
	
	(ii) The notion of "converting" an IANA registry (see
	Appendix C) has little precedent in the IETF or in IANA
	and I would suggest that we do not have a good track
	record for such conversions.  The authors propose to
	maintain the existing registrations in the existing
	registry but not add new ones there.   The resultant
	status of standards-track documents that reference 3066
	and its registry is unclear.  Presumably, those
	documents would need to be revised and re-processed to
	update them to reference the new spec and registry and
	implementations that are non-conformant to the new rules
	would need to be changed.   From an IETF procedural
	standpoint, that would require replacing at least some
	documents that are now at Draft Standard with new
	Proposed Standards, which has been a major source of
	user and implementer confusion.  It is something we have
	done when we have to, but the justification does not
	appear to be present in this document
	
	(iii) As the section above implies, and as has been
	pointed out on the list, this specification is not
	precisely upward-compatible with the specification of
	RFC 3066.  The document claims otherwise, then proceeds
	to point out the incompatibilities (e.g., if it were
	completely upward-compatible, registry conversion would
	not be needed).  That situation, again, should pose a
	very high level of requirement for justification of the
	change.

(2) Some days ago, the authors indicated that they were
producing and posting a new version of the draft in response to
some of the on-list comments.   Some of those comments were
quite substantive, others probably not.   That new draft has not
yet appeared; I suggest that, if any of the changes might be
substantive, it will require a new round of community review to
determine whether any changes that have been made have a
negative impact on requirements or other details that were
previously acceptable and to identify any comments that were
withheld pending the new draft.  This is particularly important
since the document proposes to supercede and replace an existing
BCP and IANA registry that are in active use.  I.e., this is
going to need yet another Last Call.

(3) Rather than moving to an almost-unprecedented third Last
Call (with more to come if this process is to continue as it has
proceeded in the past), I'd like to offer three alternate
suggestions.  I hope these are mutually exclusive.

	(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.
	
	(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.
	
	(iii) One way to read this document, and 3066 itself for
	that matter, is that they constitute a critique of IS
	639 in terms of its adequacy for Internet use.   From
	that perspective, the difference between the two is that
	3066 was prepared specifically to meet known and
	identifiable Internet protocol requirements that were
	not in the scope of IS 639.  The new proposal is more
	general and seems to have much the same scope as ISO
	639-2 has, or should have.  It is not in the IETF's
	interest to second-guess the established standards of
	other standards bodies when that can be avoided and,
	despite the good efforts of an excellent and qualified
	choice or tag reviewer, this is not an area in which the
	IETF (and still less the IANA) are deeply expert.  So
	there is a case to be made that this draft should be
	handed off to ISO TC 37 for processing, either for
	integration into IS 639-2 or, perhaps, as the basis of a
	new document that integrates the language coding of
	639-2 with the script coding of IS 15924.

thanks,
    john

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 03 Jan 2005 16:43:58 +0100

At 13:56 03/01/2005, John C Klensin wrote:
>I hope these are mutually exclusive.

Yes, if this means that the three of them should be aggregated into the 
final strategy.

>         written and have achieved community consensus.

100% in agreement.

>         disappear if this document paralleled, rather than

idem.

>         639-2 with the script coding of IS 15924.

Full agreement to refer to stabilized ISO 639-2 and 15924 (and to a more 
geographically/politically precise list that 3166 only), but through 
documents adapting them to the Internet multiple orthogonal and/or related 
demands and permitting to generalize them to the Internet usage for global 
application consistency.

Otherwise we would have two (or more) geopoliticalinguistic grids in use. 
IMHO the correct solution are dedicated RFCs (compatible with RFC 1591 for 
country codes) encapsulating ISO 639-3 and 15924 into a more global 
information container including application destination and sources 
descriptors.

ISO provides lists. Internet is about networking and needs internetworked 
lists. This internetworking calls for additional ad hoc descriptors.
Thank you.
jfc

---

From: [email-masked]
Date: Mon, 03 Jan 2005 07:44:27 -0800 (PST)

> date, but want to summarize some reactions before the Last Call

I believe I did comment on this once on the languages list, but
otherwise I'm in pretty much the same position as John on this.

> 	enough, IMO, to justify the replacement.
	
John, I could not agree more. It seems to me that the significant increase in
complexity called for by this document is at best an attempt to address issues
faced by at best a tiny fraction of the community that uses language tags. The
vast majority of uses don't require any of this. And I suspect the overwhelming
response to this proposal is going to be to simply ignore it. And this, in
turn, is likely to create an unfortunate situation where the majority of use is
aligned with obsoleted documents and the current documents describe usage
that's restricted to largely academic venues.

More generally, there's often a big difference between designing a good
operational standard for the Internet and designing a good scheme for
academic use. All too often a successful standard depends on identifying
and specifying a "sweet spot", whereas academic use depends on total
inclusiveness. I believe 3066 came pretty close to hitting a
sweet spot for language tags, whereas this revision favors
inclusiveness over usability.

> 	appear to be present in this document
	
This is all just more impetus to keep on using the old stuff and ignore
the current effort entirely.

> ...

> going to need yet another Last Call.

I reluctantly have to agree with this assessment.

> 	written and have achieved community consensus.
	
Given the trouble folks already have identifying the right specification to use
(I still routinely receive comments about RFC 1521, which was obsoleted quite
some time ago) I really don't think this is a good idea.

> 	disappear if this document paralleled, rather than
	
This is going to be tricky to do, but if it can be done, I'm for it.

> 	639-2 with the script coding of IS 15924.

I simply don't know enough about the groups involved to comment on this
approach.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Mon, 03 Jan 2005 12:04:47 -0500

--On Monday, 03 January, 2005 16:43 +0100 "JFC (Jefsey) Morfin"
<[email-masked]> wrote:

> Yes, if this means that the three of them should be aggregated
> into the final strategy.

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.   What is needed here is, IMO, less
confusion, not more.

>>         written and have achieved community consensus.

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.

>>         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

>>         (iii) One way to read this document, and 3066 itself
>>         for that matter, is that they constitute a critique
>>         of IS 639 in terms of its adequacy for Internet use.
>>         From that perspective, the difference between the two
>>         is that 3066 was prepared specifically to meet known
>>         and identifiable Internet protocol requirements that
>>         were not in the scope of IS 639.  The new proposal is
>>         more general and seems to have much the same scope as
>>         ISO 639-2 has, or should have.  It is not in the
>>         IETF's interest to second-guess the established
>>         standards of other standards bodies when that can be
>>         avoided and, despite the good efforts of an excellent
>>         and qualified choice or tag reviewer, this is not an
>>         area in which the IETF (and still less the IANA) are
>>         deeply expert.  So there is a case to be made that
>>         this draft should be handed off to ISO TC 37 for
>>         processing, either for integration into IS 639-2 or,
>>         perhaps, as the basis of a new document that
>>         integrates the language coding of 639-2 with the
>>         script coding of IS 15924.

And, while possibilities I haven't foreseen are certainly
possible, it is generally the case that one cannot throw
something over a wall and hold onto it as well.

> Full agreement to refer to stabilized ISO 639-2 and 15924 (and
> to a more geographically/politically precise list that 3166
> only), but through documents adapting them to the Internet
> multiple orthogonal and/or related demands and permitting to
> generalize them to the Internet usage for global application
> consistency.
> 
> Otherwise we would have two (or more) geopoliticalinguistic
> grids in use. IMHO the correct solution are dedicated RFCs
> (compatible with RFC 1591 for country codes) encapsulating ISO
> 639-3 and 15924 into a more global information container
> including application destination and sources descriptors.

I have no idea what you are talking about.  If you have a
specific proposal, might I suggest that you generate an
Internet-Draft and indicate whether it should be taken as an
alternative or supplemental to the draft-phillips-langtag
document?  If you do so, _please_ precisely identify what
problem of the actual Internet --rather than some fantasy
replacement-- you are proposing to solve. 

> ISO provides lists. Internet is about networking and needs
> internetworked lists. This internetworking calls for
> additional ad hoc descriptors.

Which is what 3066 does.   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.

    john

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 04 Jan 2005 00:08:16 +0100

On 18:04 03/01/2005, John C Klensin said:
>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.

>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).

> >>         rather than superceding, 3066.

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.

>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

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