Subject: [Gen-art] Gen-art review: draft-ietf-ltru-registry-12.txt

From: Elwyn Davies <[email-masked]>
Date: Wed, 31 Aug 2005 15:19:19 +0100

Background for those on the CC list, who may be unaware of GenART:
GenART is the Area Review Team for the General Area of the IETF.  We 
advise the General Area Director (i.e. the IETF/IESG chair) by providing 
more in depth reviews than he could do himself of documents that come up 
for final decision in IESG telechat.  I was selected as the GenART 
member to review this document.  Below is my review, which was written 
specifically with an eye to the GenART process, but since I believe that 
it will be useful to have these comments more widely distributed, others 
outside the GenART group are being copied.

Document: draft-ietf-ltru-registry-12.txt
Intended Status: BCP
Shepherding AD: Scott Hollenbeck
PROTO Shepherd: Randy Presuhn
Review Trigger: IETF Last Call, ends 6 September 2005

Summary:
This document is generally in good shape and well written but is not yet 
ready for publication.  It 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!

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Wed, 31 Aug 2005 11:26:59 -0400

Randy,

Since we're still in WG last call, please forward the note below to the WG
mailing list for review.

-Scott-

> -----Original Message-----
> From: Elwyn Davies [mailto:[email-masked]] 
> Sent: Wednesday, August 31, 2005 10:19 AM
> To: [email-masked]
> Cc: Randy Presuhn; Mary Barnes; Scott Hollenbeck; 
> [email-masked]; [email-masked]
> Subject: Gen-art review: draft-ietf-ltru-registry-12.txt
>