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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf