Document: draft-ietf-ltru-registry-12.txt Reviewer: Elwyn Davies [elwynd@dial.pipex.com] Review Date: Wednesday 8/31/2005 9:19 AM LC Date: 06 Sept 2005 Summary: This document is generally in good shape and well written but is not yet ready for publication. Review: ------- The document has in my view a couple of minor process issues that need to be sorted out, one issue which seems to be an unnecessary irritant, some minor restructuring to improve readability and some editorial nits. I would also suggest that areas which may be affected by the introduction of 'extended language subtags' are all revisited to ensure that they properly and clearly cover both the initial case (with no extlang subtags) and the future development including one or more extlang subtags. [My initial impression was that the new idea was not as well integrated as it might have been but on re-reading most of the 'issues' have become clear... hence the suggestion that some additional clarity might be gained by a few extra words in relevant areas.] Transition issue: I think the transition from RFC3066 to the subtag registry needs a little more attention. There are a few words in s3.7, but I think the process might need a little fleshing out. In particular suggestions about ensuring there is not an interregnum with no reviewer in place (they are appointed by different authorities) and giving notice of the changeover (e.g., a number of weeks after the publication of the RFC(s)). In principle the changeover should be seamless but it would probably be good to have the initial registry in place (i.e., translated from the initial state RFC) and reviewed before it becomes authoritative. Recall of Language Subtag Reviewer: Given recent IETF discussions, should the document set out ways for the community to request the unfrocking (recall) of the Language Subtag Reviewer in the event of non-performance or repeated inappropriate decisions? Also would it be appropriate to suggest that the IESG document the name of the reviewer on their web page and periodically reconfirm the appointment? I don't think a fixed term appointment would be desirable, and I agree this is not something for nomcom to be involved in. Irritant: Early in the document it is specifically set out that language tags are case insensitive and should be normally represented in lower case. However, because the corresponding ISO documents use title case for script codes and upper case for region codes, this representation has been used in the normative text (ss 2.2.3 and 2.2.4) and registrations of these codes MUST use this representation (s3.2). This struck me as unecessary bureaucracy for registrants. It would seem to me enough to RECOMMEND that the registry conform to the case patterns and otherwise allow users and registrants whatever case they choose. Restructuring: The Language Tag Reviewer of RFC3066 has metamorphosed into a Language Subtag Reviewer. The subtag reviewer is first mentioned in s3.1 in a rather sudden way. The role of the reviewer is scattered across several sub-sections of s3 and how the person is appointed is buried in depths of s3.4 (Registration Procedure for Subtags). I think it would be valuable to summarize the role of the Language Subtag Reviewer and set out how this person is appointed (and maybe also recalled) right at the start of s3. Update Load There has been considerable debate about the expected load of updating the registry especially over the next couple of years. It might be worth adding some notes about the expected load and emphasising that such changes will have minimal impact on applications due to the backwards compatibility rules. Review: ======= Substantive: ============ s2.2.2: This states that an extended language subtag '...MUST include exactly one prefix field....' . The implication of this seems to be that the same extended language subtag cannot be used for multiple primary languages. I think it would be worth spelling out the reasoning behind this as it might be seen as an undesirable restriction. A pointer to this discussion in the 'Prefix' discussion in s3.1 would then help. s2.2.3: item 3: Is it desirable to have normative text using other than lower case for tag identifiers? See also s3.2 comment below. s2.2.4: Item 6 and (maybe) examples: as per s2.2.3, Item 3. s2.2.4: Item 3A: [Out of interest...] Why not economic groupings? Their bureaucrats have languages all their own ;-) . s3.1: the 'Language Subtag Reviewer' makes a rather sudden entry here. 'Who is this person?' the naive reader may ask. It would be a good idea to add a sub-section before 3.1 introducing the Language Subtag Reviewer, summarizing the role and setting out how the person is appointed (and recalled) - move text from s3.4. Since the the Language Tag Reviewer (a wholly different person ;-) ) from RFC3066 is also mentioned, it is important that it is clear which one is referred to - the full title should be used throughout (e.g. several incomplete instances in s3.4) - a handy abbreviation (although LSR is already taken in MPLS land) might shorten the document a bit! s3.1: para 1, last sentence: Given that *all* the initial records are in the initial registry load RFC, maintaining registration forms for just the RFC3066 subset seems a little odd. Why not all or none, since presumably they can be created by an automated script? s3.1: para after ABNF: Numeric ranges? This section talks about alphabetic ranges such as c..k. Is this supposed to cover numeric ranges as well? s3.1: definition of 'Tag' field: Presumably the syntax of a tag of type 'grandfathered' is restricted to the 'grandfathered' format from s2.1? (Looking at the initial state it may well be) Given that grandfathered items are all in the initial registry load this is perhaps academic. s3.1: para after definition of 'Added': the 'MUST' requirement to follow the capitalization conventions of the underlying standards in the registry seems a little strange given earlier views on interpretation of case. s3.1: definition of 'Prefix': I think a more formal (ABNF) description of the possible values might help. Presumably an 'extlang' can have a primary language tag and up to 2 other extlangs and a 'variant' can have a complete language (including up to 3 extlangs)and possibly a script and/or a region. s3.1: discussion of 'Preferred-Value': '...SHOULD be preferred when selected language tags.' appears to be garbled... I am not sure exactly what is intended. s3.2: last para: the requirement to get the case pattern of a certain subset of tags right seems an unecessary hurdle - the registry can enforce this if it seems really desirable. s3.3: Item 12: Is there any chance that the meaning of the grandfathered tag and the (later) combination of valid subtags might be different? If so what should happen? The reviewer should take a view on this I think! Should there be some words on how to process such overlaps in the validating processor section? s3.4: para 2 and para next but one after Figure 5: At first sight these paras appear to conflict? the second one appears to indicate that type 'extlang' subtags can be registered but they are not mentioned in the first one. Presumably this is because extlang is currently reserved for future use, but it would be good to mention this in para 2. Text saying something like 'extlang records will also be able to be registered by this process when they are introduced'. s3.4: para next but one after Figure 5: I cannot find the requirement that Variant subtags have at least one Prefix field: extlang fields are explicitly specified to have exactly one but Variants appear to be allowed 0 or more. s4.1: Item 2: example: I am not clear how one would represent the combination of latin and braille since only one script subtag seems to be allowed. Maybe there is a special subtag for the combination? or is it intended that both complete tags are used? Editorial: ========== Global: Some pieces of ABNF are described as 'Figures' but others aren't, and not all figures have titles (e.g., Figure 4, and Figure 5). [Figure 2 and Figure 3 don't appear as such] s2.2.6: Item 2: 'below' should point to s2.2.7. s2.2.8: In reading the document for the first time, I found the use of 'redundant' as a type slightly confusing. It would help to clarify things if text was added (probably in this section) to the effect that subtags that don't come from RFC3066 but eventually become 'redundant' are NOT handled by the use of the 'redundant' type but by marking them as deprecated and (maybe) adding a Preferred-Value as described in s3.1. s3.1: Seems rather long... maybe could be broken up into subsections. s3.1: para next but one after definition of 'Added': s/registered written or transcribed/registered that has been written or transcribed into/ (repeated in s3.4 in para about 'description' field.) s3.1: discussion of Comment field: s/frowned on/strongly NOT RECOMMENDED/ s3.2: s/an change/a change/ s3.2: para before figure 4: is the intent of this that each email contains insertion or modification data for exactly one record? if so it should say this explicitly... at present it is sort of implied in that it appears to forbid mixing of INSERT and MODIFY but doesn't say just one record per email. s5.1 is slightly more precise - it says 'enclosed record' (singular). s3.5: last but one para: This paragraph talks about matching... there is a draft (draft-ietf-ltru-matching) specifically about this matter which does not appear to be referenced. Should this matter be discussed? s3.7: Presumably the language tag reviewer here the RFC3066 person rather than the language subtag reviewer defined in this draft? this should be made crystal clear! it might well be the same person but handover (or retitling) and authority are missing from this document!