> 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.
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.
> (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.
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.
> (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
This is all just more impetus to keep on using the old stuff and ignore
the current effort entirely.
> ...
> (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.
I reluctantly have to agree with this assessment.
> (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.
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.
> (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.
This is going to be tricky to do, but if it can be done, I'm for it.
> (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.
I simply don't know enough about the groups involved to comment on this
approach.
Ned
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
