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

From: Elwyn Davies <[email-masked]>
Date: Wed, 31 Aug 2005 18:41:39 +0100

Thanks for the swift responses - I am fine with most of your responses 
and I hope they get into a revision.

A couple of responses/clarifications below...

Regards,
Elwyn

Addison Phillips wrote:

>Thanks for this note. I'm not sure of what the procedural handling of these comments should be. Many of these comments would make useful additions to the document.
>
>My main question (Randy) is: what is the process impact of incorporating changes based on these comments? 
>
>Response comments below are personal, of course. I expect I'll be sending these to the list also after Randy forwards the message.
>
>Addison
>
>Addison P. Phillips
>Globalization Architect, Quest Software
>Chair, W3C Internationalization Core Working Group
>
>Internationalization is not a feature.
>It is an architecture. 
>
>  
>
>>-----Original Message-----
>>From: Elwyn Davies [mailto:[email-masked]]
>>Sent: 2005?8?31? 7:19
>>To: [email-masked]
>>Cc: Randy Presuhn; Mary Barnes; Scott Hollenbeck; [email-masked];
>>Addison Phillips
>>Subject: Gen-art review: draft-ietf-ltru-registry-12.txt
>>
>>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.
>>
>>    
>>
<<snip>>

>>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.
>>    
>>
>[Addison Phillips] 
>
>It may appear a bit vague. In practice, however, there has only ever been one Language (Sub)tag Reviewer, Michael Everson. The change in appointing authorities was suggested by the IESG itself, so there should be no interregnum. There are rules in place to deal with any in-process registrations, which would mark the main problem source.
>  
>
Assuming Michael is willing to continue you shouldn't have any problems 
with personnel, but it still might be worth asking your AD and IANA 
about phase-in process, and seeing if there is anything worth documenting.

<<snip>>

>>Irritant:
>>Early in the document it is specifically set out that language tags are
>>case insensitive and should be normally represented in lower case.
>>    
>>
>[Addison Phillips] 
>
>This is NOT correct. It actually says:
>
>--
><<snip>>
>
You are of course right!  This was mostly provoked by thinking how messy 
these strings looked with the assortment of case.  Your suggestion later 
on covers most of the irritation.

<<snip>>

> <<snip>>
>
>>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.  
>>    
>>
>[Addison Phillips] 
>
>That's not just the implication, but entirely the idea. Extended language subtags are meant to be closely associated with the primary language subtag. Since they occur directly after the primary language subtag, there are no intervening values or additional variants that can creep into their prefix (requiring more than one prefix). In addition, extlangs are expected to be used with the ISO 639-3 concept of "macro languages" (languages that contain other languages). An example of this is the spoken variation Mandarin Chinese. The tag for this would be zh-cmn and "cmn" would be an extlang with a prefix of "zh". It doesn't make sense to use "cmn" with a different language prefix, such as "de" or "ja".
>
>  
>
What I was perhaps not saying as well as I could was: does this 
therefore mean that you can't use the same extlang tag for different 
primary languages?  the example you give could be a case in point - 
'cmn' is a reasonable abbreviation for 'common' and the space is not 
that big - or are you allowed to register the same extlang with a 
different prefix in a separate record?  I wasn't sure if this would be 
allowed.

<<snip>>

>>pointer to this discussion in the 'Prefix' discussion in s3.1 would then
>>help.
>>    
>>
>[Addison Phillips] 
>
>Good idea.
>  
>
>>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?
>>    
>>
>[Addison Phillips] 
>
>The RFC 3066 registry is maintained in perpetuity and its format is different than that of the draft. That registry is maintained as an obsolete reference (it just seemed prudent to do so). Generating many registration forms for the initial set, however, doesn't seem that useful.
>  
>
If the RFC3066 registry is being maintained then it seems like not 
generating any registration forms at all would be the right answer.

<<snip>>

>>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.
>>    
>>
>[Addison Phillips] 
>
>Would that really add anything to the document? It would be easy to do, yes, but I'm not sure that it is unclear as written.
>  
>
I think the words are currently a little woolly and you are reliant to 
an extent on the examples.  If a formal definition is easy I would add it.

>>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.
>>    
>>
>[Addison Phillips] 
>
>The value in the record that contains a 'Preferred-Value' field should be replaced with the value in the Preferred-Value. That is, Preferred-Value is how a subtag is deprecated in favor of a different subtag. The cases where this applies are then enumerated. Some textual tweaking to make this clearer is probably called for.
>  
>
I know what the overall intent is... I just cannot parse this sentence 
at all!  Something about generating or constructing language tags was 
intended I suspect.

>>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.
>>    
>>
>[Addison Phillips] 
>
>That requirement could be relaxed to SHOULD.
>  
>
I think that would relieve most of my irritation.

<<snip>

>>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'.
>>    
>>
>[Addison Phillips] 
>
>The key word in para 2 is "independently". There are also registrations that can occur due to standards body activity (assignment of a new ISO 3166 code, for example).
>
>Extlangs cannot currently be registered, as noted they are reserved. However, the rules for extlangs are spelled out so that implementations can take them into account. Therefore it is important to point out that they must have a Prefix again here. The conditional nature of their existence might be better mirrored by the wording, though.
>  
>
When I first read through the document I was very confused by the talk 
about what needed to be done with extlangs after Figure 5 but nothing 
about them earlier.  I think you probably need a few extra words to 
distinguish the two cases.. independently didn't trigger the right chain 
of thought for me.

>>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.
>>    
>>
>[Addison Phillips] 
>
>You are looking at the requirement. Perhaps the matching requirement in Section 2.2.4 should be strengthened from MAY to MUST?
>  
>
[I think you mean s2.2.5]: To make it consistent, yes, the s2.2.5 
statement should be "MUST include one or more 'Prefix' fields".

<<snip>>

>>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.
>>    
>>
>[Addison Phillips] 
>
>That isn't correct. Redundant tags are values registered under RFC 3066 that are now defined by (separate) subtags in the registry. For example, the tag "zh-Hant" is now defined by the subtags 'zh' and 'Hant' and thus is redundant. It is NOT deprecated and never may be deprecated by rule. This is in contrast to grandfathered values, which may sometimes become redundant (the only time a zebra in this zoo may change its stripes) or may be deprecated, but which always maintain their validity.
>
>What's important to note is that redundant tags are valid.
>  
>
This is maybe a US/UK usage problem! I was reading 'redundant' in the 
'no longer wanted' sense rather than purely the 'alternative among more 
or less equals'.  A few words to make it clear what is going on would 
help others  to avoid the same trap.
<<snip>>

>>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.)
>>    
>>
>[Addison Phillips] 
>
>Yes. Actually a comma is missing there, but your version works too.
>  
>
I thought there was a comma missing initially but 
s/registered/registered,/ completely alters the sense.
<<snip>>

>>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?
>>    
>>
>[Addison Phillips] 
>
>Do you mean Section 3.6? Matching is actually mentioned sporadically here and there in the document in a general manner. The first occurrence is in S2.1, para2. Matching here can be assumed to mean RFC 3066-style prefix matching. The matching draft enumerates other schemes too.
>
>Originally the matching draft was part of this document, please note.
>  
>
[yes I meant s3.6].  I haven't read the matching draft in detail, but I 
guess it would be useful to refer to it somewhere around s2.1.

<<snip>>
Regards,
Elwyn

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