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

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

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 01 Sep 2005 04:19:04 +0200

Randy Presuhn wrote:

> it's OK to disagree with a review comment

Or to agree, if it's something we have missed above the
editorial level.

> From: "Elwyn Davies" <[email-masked]>
[...]
> Subject: Gen-art review: draft-ietf-ltru-registry-12.txt

Thanks.

> 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)

It's IMHO better readable this way.  Otherwise "fr" vs. "FR"
would result in "fr" vs. "fr" gibberish.  That's nothing new
in the draft, 3066 has the same non-issue.  It's not a real
issue, because the syntax guarantees that a primary tag "fr"
or "fr-" can be always distinguished from a subtag "-fr".

But from a purely editorial POV it's better readable to say
"fr" vs. "FR" instead of "fr" vs. "-fr".

> 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

Yes, that makes sense, the language tag reviewer could "fix"
it before it's forwarded to IANA.  But it would be ugly if
all lower case subtags make it to the registry proper, for
the reasons outlined above (readability, minimize potential
causes for confusion).

So this unnecessary bureaucracy is not completely pointless
and IMHO harmless.  In practice the tag reviewer would just
propose to fix an "erroneous" registration request (or do
it silently), and so we get the _desired_ effect.

Whether that should be a MUST or only RECOMMENDED is also
a matter of taste, I'd like to change it as proposed.  Bye

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 01 Sep 2005 04:32:20 +0200

Elwyn Davies wrote:

> [Out of interest...] Why not economic groupings?  Their
> bureaucrats have languages all their own ;-)

Yes, nevertheless they are not really "regions".  If you'd
want something like en-legalese register it as a variant,
don't try to approximate it by obscure "region" codes...

...so let's say that the region zoo is already bad, and you
found a way to make it worse.  The ISO 3166-1 Web page also
has tons of obscure WIPO codes.  This isn't about regional
aspects of languages.
                         Bye, Frank

http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/iso_3166-1_decoding_table.html?printable=true#AA

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 01 Sep 2005 04:39:54 +0200

Elwyn Davies wrote:

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

Yes.  What's the proper term, "alphanumerically" maybe, or
"lexicographically" ?   The latter cries for a reference.

                        Thanks, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 01 Sep 2005 04:48:39 +0200

Elwyn Davies wrote:

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

As you say the difference is "exactly" vs. "at least" one.
The last statement in this paragraph is:

| Variant registration requests are REQUIRED to include at
| least one "Prefix" field in the registration form.

Is it that what you're looking for ?  Bye, Frank

---

From: "John.Cowan" <[email-masked]>
Date: Wed, 31 Aug 2005 23:05:06 -0400

> Is it that what you're looking for ?  Bye, Frank

I forgot about this.  Do we really want to forbid variants that apply
to every language?  "signed" would be a reasonable such candidate;
it can be applied to any spoken language to specify the (exact)
signed equivalent: thus en-signed would be a mapping from English
to signs.  This is not the same as sign languages proper.

-- 
Income tax, if I may be pardoned for saying so,         John Cowan
is a tax on income.  --Lord Macnaghten (1901)           [email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 01 Sep 2005 05:02:04 +0200

Elwyn Davies wrote:

> 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 ist intended that both complete tags
> are used?

If it's Latin it's not Braille (and v.v.), same idea as Latin
vs. Cyril etc.

If you're talking about combined documents (e.g. a movie with
captions) you could either tag the different parts / aspects
separately, or just don't specify the script (or any similar
subtag).  There are also subtags like "mul", "und", "Zxxx",
"Zyyy", "Zzzz", etc. for special purposes.

                         Bye, Frank