Subject: IESG Response to Jefsey's appeal against draft-ietf-ltru-registry

From: IESG Secretary <[email-masked]>
Date: Tue, 21 Feb 2006 12:23:38 -0500

On January 14, 2006 the IESG received an appeal from J-F C. Morfin
regarding the IESG's decision to approve
draft-ietf-ltru-registry-14.txt as a BCP; see
http://www.ietf.org/IESG/APPEALS/jefsey-morfin-appeal.txt . This is
Mr. Morfin's second appeal to the IESG regarding this document; in
http://www.ietf.org/IESG/APPEALS/appeal-iesg-poor-rfc-3066.txt he
appealed the decision to change an example in the text. However, this
appeal concerns the approval of the document.

The IESG considered several sources of information in evaluating this
appeal. We considered the text of the appeal, including the
background provided in section 1. The IESG also considered the text
of the draft and the extensive last call discussion. Of particular
use was the summary of the last call discussion at
http://www1.ietf.org/mail-archive/web/ltru/current/msg03807.html and
comments in the ballot.

The IESG responds to the appeal as follows:

Section 2.1 of the IESG appeal claims that the management implications
of the registry have not been adequately considered. Mr Morfin claims
that the registry which currently documents hundreds of languages
could grow to tens of thousands. The appeal states, "The architecture
of this registry is not intended to link other registries. For
example, every XML document may at some stage call for an updated
direct or indirect access to the IANA langtag registry. Should every
Internet user do it only once a year, it would mean more than 30
(average) 2 Meg file downloads a second." In addition, Morfin claims
that the current registration procedures cannot scale to a registry of
this size and that legitimate use of the registry will eventually be
blocked.

The IESG notes that the registry would not typically be needed by an
end-user application unless that application is validating language
tags. The registry contains information used to determine whether a
language tag is valid (instead of just well-formed) and information on
what tags are deprecated. The registry does include a description
field but this is explicitly not a display name for the language tag:
display of language tags to end-users is not covered by this
specification.

These concerns were discussed at length during last call; they overlap
at least with issue #968 and with other parts of the last call
discussion. The working group specifically added text clarifying that
applications should not depend on the ability to access the registry
over the Internet. The working group also came to a consensus that
the current registration procedures are adequate for expected
registration load. The IESG finds that the working group adequately
considered the issue and that there is no grounds for appeal of this
issue either on technical or process grounds. The IESG also notes
that if demands for registration in this or any IETF protocol registry
exceed our ability to efficiently register new items, we can revise
the registration procedures to be more efficient.

Section 2.2 claims that if the IANA fails to keep up with user demands
and if RFC 3066bis does not meet the needs of the Internet community
alternatives will develop. This may balkanize the Internet because
some systems will support the RFC 3066bis approach and other systems
may support a superset of that approach. This potential problem is
not documented in the security considerations section.

The IETF has a strong interest in working to make sure our standards
meet the community needs. As new needs emerge, we can continue to
address these needs just as we did when we formed the LTRU working
group to address needs not met by RFC 3066. We will always need to
maintain a careful balance between complexity and flexibility. The
LTRU registry draft provides multiple mechanisms for future growth.
Features that were rejected from the current version of the registry
can be added in future updates if we reach a consensus that they are
needed. As with all our protocols, we will need to consider
requirements of interoperability and stability.

The IESG should not hold back a standard simply because it may not
address some future need. Instead, we should all continue to identify
requirements and engineer quality solutions to those requirements in a
timely manner.

Sections 2.3 and 3.4 of the appeal both discuss the concern that the
registry draft does not support other systems for naming languages.
Mr. Morfin proposes that "[the registry draft] MUST support other
language naming systems which are able to replace it along with the
evolution of the state of the arts, the user common practices, the
legal obligations, the international agreements and the not yet
considered security aspects." Section 2.3 makes a claim about a
problem in the ABNF while section 3.4 proposes a solution. The IESG
understands that these sections are not completely linked: the
solution in section 3.4 is intended to address other problems than
those described in section 2.3 and other solutions might address the
concerns raised in section 2.3. However we discuss these two sections
together because we were not able to separate our response.

Mr Morfin wants users to be able to include their own information in
language tags. The registry draft has an extension mechanism that
Mr. Morfin proposes to modify to meet this goal. The extension
mechanism is introduced by one of 34 extension markers (letters
besides x and digits) and followed by one or more groups of two to
eight alpha-numeric characters. In addition, like any component of a
language tag, extensions may be truncated at any subtag boundary.
Formally the extensions are defined by the following ABNF:

extension = singleton 1*("-" (2*8alphanum))

singleton = %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT
; "a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z" / "0"-"9"
; Single letters: x/X is reserved for private use

This extension mechanism does not meet Mr. Morfin's claimed needs for two
reasons. First, extensions require standards action to approve and
there has been insufficient interest in the LTRU working group to
standardize this type of extension at the present time. Secondly,
Mr. Morfin proposes that the data carried in the extension be a tag
IRI [RFC 4151].there is a significant mismatch between attributes of
an IRI and attributes of a language tag or language tag extension.
IRIs can be reasonably long and do not have truncation rules; language
tags need to be able to be truncated to work within existing
applications. There is no significant limit on the length of a
component of an IRI. Language tags are divided into sub-tags each one
of which is limited to eight characters. IRIs can use most of the
Unicode character set; language tags are limited to alpha, digit and
hyphen with additional restrictions described in the ABNF above.

These restrictions are inherited from RFC 3066. The following ABNF
productions describe the tag in RFC 3066:

Language-Tag = Primary-subtag *( "-" Subtag )

Primary-subtag = 1*8ALPHA

Subtag = 1*8(ALPHA / DIGIT)

Applications have been built assuming these constraints. A
Significant part of the discussion that lead to the formation of LTRU
focused on making sure that existing applications would work with the
new language tags. In addition, the discussion leading to the
formation of LTRU focused on the need to support truncation of tags
because some protocols have length limits. For this reason the IESG
rejects Mr. Morfin's proposal to modify the extension mechanism's
grammar to support the character set and length of an IRI. This
proposal runs counter both to the technical necessity of backwards
compatibility and to the strong IETF consensus that backwards
compatibility was critical in the work of the LTRU working group.

However we do note that a mechanism is available for experimenting
with various ways of encoding user data in language tags. The private
use mechanism allows groups of one to eight alpha-numeric subtags to
be added for communication between parties to a private agreement.
Such a mechanism could be used to experiment with mappings of URIs or
IRIs into language tags and to determining when this additional data
would be useful to include in language tags. Such a mapping would
need to describe how to handle truncation and how to handle the
character set conversion. It's clear that such mappings exist. As an
example, consider an encoding where the first character of each subtag
indicates whether this subtag is the final subtag and the remaining
characters contain hexadecimal representations of the octets of a URI.
On decode, the entire URI is discarded if the final subtag has been
truncated. This mapping could be improved on both in the efficiency
of the encoding and in the strategy for handling truncation, but it
demonstrates that the extension and private use mechanisms are
sufficiently flexible. The backward compatibility constraints also
make it clear that we cannot make the specification of such a mapping
easier by doing it in this version of the language tag registry. If
at some future time, parties interested in such a mapping demonstrate
sufficient interest and determine the optimal mapping for applications
that benefit from it, then an extension can be standardized.

Mr. Morfin is correct that two different parties may conflict in their
use of the private use space. That is a fundamental property of
private use space and is clearly documented in section 4.5 of the
registry draft. This was an explicit decision of the LTRU working
group and is consistent with similar decisions throughout the IETF.

One of the chartered requirements of the LTRU working group is the
ability to "easily identifying the role of each subtag in the language
tag, so that, for example, whenever a script code or country code is
present in the tag it can be extracted, even without access to a
current version of the registry." Section 2.4 claims:
This leads to a dramatically easier use of IETF langtags in order to:

· profile traffic for cultural, national, racial, religious evaluation
· cultural, national, racial, religious searches in search engines
· cultural, national, racial, religious relational "marking" in
using retro-meta-spam: one interlocutor "marks" his traffic (web
pages, mails, etc.) with langtags. The returning traffic designates
the persons who were able to understand it. These persons ignored
they were victims of a meta-spam.
· filter national traffic for specific content, as against
human rights or democratic behaviour

The IESG and the security area directors were aware of this concern
and it was discussed during last call. The following two paragraphs
appear in the security considerations section:

Language tags used in content negotiation, like any other
information exchanged on the Internet, might be a source of concern
because they might be used to infer the nationality of the sender, and
thus identify potential targets for surveillance.

This is a special case of the general problem that anything sent is
visible to the receiving party and possibly to third parties as well.
It is useful to be aware that such concerns can exist in some cases.
The evaluation of the exact magnitude of the threat, and any possible
countermeasures, is left to each application protocol (see BCP 72
[RFC3552] for best current practice guidance on security threats and
defenses)..

The IESG believes that this documentation is adequate.

Section 2.5 notes that texts can be tagged with incorrect content.A
specific subset of this concern is documented in the security
considerations section: the security considerations section warns
that the language tag is no defense against homographs; a document
labeled as one language may contain characters from scripts not
associated with that language. The IESG believes that the problem of
misslabeled content is generally well understood and does not believe
that changes to the document are appropriate at this late of a stage
in the process to document this issue.

Section 3.1 proposes documenting the issues raised in section 2 in the
security considerations section. The IESG believes that a relatively
high bar needs to be met in order to delay a document after approval
to add new security considerations. We think this bar will rarely if
ever be met. We conclude that the bar has not been met in this
instance. However, parties wishing to comment on IETF specifications,
including parties wishing to comment on the security of IETF
specifications have a number of options available. One such option is
to write an informational RFC commenting on the specification.

Section 3.2 proposes that the language tag registry could be managed
similar to the DNS with multiple organizations being able to register
language tags. The IESG does not see the need for such a complex
structure. If the structure of the registry needs to be changed in
the future, we can do so.

Section 3.3 proposes adding specific text to the document. The IESG
does not believe that the proposed text addresses any of the issues
raised in section 2. IN addition, we do not believe there is
consensus to add this text in the LTRU working group. AS such, we see
no grounds in a process or technical appeal to add this text.

In conclusion, the IESG rejects Mr. Morfin's appeal in its entirety.
The IESG notes that parties may use the private use space of language
tags in order to experiment with potential future extensions including
proposals to include user data in language tags. Parties wishing to
comment on the security of IETF specifications such as the language
tag registry may do so. One current mechanism for doing so is
independent submissions to the RFC editor.

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