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
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
