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