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

From: "Addison Phillips" <[email-masked]>
Date: Wed, 31 Aug 2005 12:49:23 -0700

Responses follow.

Addison

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 
> 
> 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
> 
> <<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.
[Addison Phillips] 

I agree.
> 
> <<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.
[Addison Phillips] 

Yes. The meaning of any subtag is defined and can't change in different contexts. That is, '1996' is subtag describing a particular orthography of German. It can't just be used as an arbitrary year number. The subtag 'cmn' will mean "Mandarin Chinese" and won't have any meaning with a different macro language.
> 
> 
> <<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.
[Addison Phillips] 

It's easy to do and therefore probably worthwhile. I'll work up a version.
> 
> >>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.
[Addison Phillips] 

Yes. I'll propose suitable text modifications.
> 
> >>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.
[Addison Phillips] 

Actually, I think this point was raised before. I'll propose suitable text for the "independent" part and the extlang material.
> 
> >>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".
[Addison Phillips] 

I do mean 2.2.5.
> 
> <<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>>
[Addison Phillips] 

No, the usage is meant to be similar. The redundant tags are "no longer wanted" in that all of their subtags are now separately defined. A grandfathered tag must be handled in an implementation by an exceptional process--there is a list of grandfathered values used to validate these tags--while redundant tags are described entirely by various subtags in the registry and the registry entries can be entirely ignored by an implementation. The entry merely exists so that people know where the RFC 3066 registered value went.
> 
> >>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>>
[Addison Phillips] 

Yes, and appropriately too!

Here is the corrected sentence: 
--
At least one of the 'Description' fields MUST contain a description of the tag being registered, written or transcribed into the Latin script;
--

The point is at least one description must be in the Latin script, not that the tag must be in the Latin script (of course it is---> it is required to be in our particular subset of ASCII).
> 
> >>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.
> 
We could as easily (actually, since it's an RFC and draft-matching is a draft, more easily) refer to matching as described in RFC 3066, RFC 3282 and, of course, RFC 2616 Section 14.4. 

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 31 Aug 2005 11:28:03 -0700

Hi -

I'd like to thank the GenART reviewer for the thoughtful comments.
I'm forwarding the comments to the ltru working group for discussion
in conjunction with the other IETF last call comments that have been
received.

If any of the people on the Cc: list would like to listen in on the WG's
discussion, I suggest subscribing to the ltru working group mailing list
at https://www1.ietf.org/mailman/listinfo/ltru  Since there are many issues
raised in this review, I can't promise that a Cc: list would survive the
many threads that will probably be spawned.

The editors are hereby directed to correct the purely editorial typos in
their working copies.

In anticipation that this review might result in DISCUSS comments from
the IESG, for the issues which involve the substance of the document, or result
in signficant change (such as reorganization or rewriting whole paragraphs),
I'd like to see working group discussion and agreement on (1) whether changes
are needed, and (2) agreement on specific replacement text.  Working group
participants note well: it's OK to disagree with a review comment; in such
case a result might be a purely editorial clarification of what was intended,
rather than an actual subtantive change.

For my own sanity, I'll be entering these (and other IETF last call issues)
into the issue tracker at https://rt.psg.com/ (user and password "ietf"),
In the meantime, in responding to the comments that are not purely editorial,
PLEASE use an appropriate subject line (e.g. "subtag reviewer recall") and
limit each of your postings to a single issue.  Though this results in
higher message volume, it makes the discussion *much* easier to follow.

Randy, ltru co-chair
----- Original Message ----- 
From: "Elwyn Davies" <[email-masked]>
To: <[email-masked]>
Cc: "Randy Presuhn" <[email-masked]>; "Mary Barnes" <[email-masked]>; "Scott Hollenbeck"
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, August 31, 2005 7:19 AM
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.

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:

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.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?

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.

s3.1: Seems rather long... maybe could be broken up into subsections.

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.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!