Subject: RE: [Ltru] John Cowan's substantive comments on draft-ietf-ltru-r egistry-01

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 7 Apr 2005 09:28:16 -0700

Hi,

My comments inline below.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On
> Behalf Of John Cowan
> Sent: Wednesday, April 06, 2005 8:10 PM
> To: [email-masked]
> Subject: [Ltru] John Cowan's substantive comments on
> draft-ietf-ltru-registry-01
> 
> 
> Proposal registry-cowan-01: Alpha order in extension subtags
> 
> CURRENT: Extension subtags MAY appear in any order in a language tag.
> It is not clear whether the order matters, but probably not, since
> tag canonicalization requires them to be sorted into case-insensitive
> alphabetic order by singleton.
> 
> PROPOSED:  Require that extension subtags already be sorted 
> by singleton
> order in well-formed tags.
> 
> RATIONALE:  Extension subtags are novel, so there is no previous
> practice.  Alphabeticalness of singletons is easy to check for.
> Meaningless variability is reduced.
>

Agree - but only when a tag is claimed to be canonicalized
(and we should recommend that applications display tags in
canonicalized form for best understanding by mere humans). 

> 
> Proposal registry-cowan-02: Ban singleton "i"
> 
> CURRENT: "i" MAY be used as a singleton in extension subtags.
> 
> PROPOSED: "i" MUST NOT be used as a singleton.
> 
> RATIONALE:  The single-character subtag "i" is already used in
> grandfathered tags in a different sense.  Although mechanical 
> processes
> will not confuse the two senses (grandfathered "i" is always initial,
> singleton "i" is never initial), human beings may.  Eliminating "i"
> does not significantly reduce the space of singletons available for
> registration.
> 

Agree - simpler is better.

> 
> Proposal registry-cowan-03:  Ban singletons "y" and "z"
> 
> CURRENT:  "y" and "z" MAY be used as singletons in extension subtags.
> 
> PROPOSED:  "y" and "z" MUST NOT be used as singletons.
> 
> RATIONALE: If cowan-registry-01 is accepted, then accepting 
> this proposal
> as well would allow a simplification of well-formedness 
> checking in that
> the singleton "x" in a non-initial position need not be 
> treated specially.
> Otherwise, the canonical order is "a", "b", ..., "w", "y", "z", "x".
> Eliminating "x" and "y" does not greatly reduce the space of 
> singletons
> available for registration.
> 

Agree - simpler is better - extension space is not at a premium.

> 
> Proposal registry-cowan-04: Specify case rules for canonical tags
> 
> CURRENT:  Canonicalizing a tag does not affect the case of the letters
> in it.
> 
> PROPOSED: Canonicalizing a tag adjusts the case of the 
> letters as follows:
> 
> 	1) The first letter of a script subtag is upper case; 2) Both
> 	letters of an alpha region subtag are upper case; 3) All other
> 	letters are lower case.
> 
> RATIONALE:  These are the de facto canonicalization rules for ISO 639,
> ISO 3166, and ISO 15924 codes.	Since we have not had 
> canonical tags
> before, there is no previous practice to contradict.  The requirement
> for case-insensitive matching may be eliminated if all tags 
> being matched
> are known to be canonical.
> 

Agree - but specify canonicalization as a display technique for
applications and servers, not as a protocol requirement.

> 
> Proposal registry-cowan-05: RFC 822 line wrapping in the registry
> 
> CURRENT: Line wrapping is done with a trailing backslash.
> 
> PROPOSED: Line wrapping is done by replacing a chosen sequence of
> horizontal whitespace with a line terminator followed by horizontal
> whitespace.  (See RFC 2822 for specific text.)
> 
> RATIONALE: Compatibility with RFC (2)822.
> 

Agree - let's not reinvent RFC 2822.

> 
> Proposal registry-cowan-06: Remove leading zeros from 
> character references
> 
> CURRENT: Every character reference MUST contain at least four digits.
> 
> PROPOSED: Character references MUST contain between one and six digits
> inclusive.
> 
> ALTERNATIVE: Character references MUST contain between one 
> and six digits
> inclusive, and MUST NOT have leading zeros.
> 
> RATIONALE:  The proposal is compatible with XML.  The 
> alternative proposal
> is also compatible with XML and allows only one possible encoding for
> each codepoint.
> 

I prefer the Alternative best - I like only one possible encoding.

> 
> Proposal registry-cowan-07: Remove private use tags from the registry
> and sample registry.
> 
> CURRENT:  The private use codes of the ISO standards are included in
> the registry.
> 
> PROPOSED:  Remove them from the registry.  Also remove the concept of
> value ranges from Section 3.1, which is needed only for 
> private use tags.
> 
> RATIONALE:  Private use tags are for private use, and private 
> agreements
> about them do not scale.  They ought not to be contained in a public
> registry.  Those who wish to use them can look at the RFC.
> 

Let's keep them as ranges in the registry to make clear their use.

> 
> Proposal registry-cowan-08: Simplify the language tag 
> registration form
> 
> CURRENT: See Section 3.3.
> 
> PROPOSED: The numbered items 1-3 and 4-8 should be replaced by
> the following new or existing fields in the registry:  Requester,
> Requester-Email, Description, Meaning, Native-Name, 
> Reference, Comments.
> 
> RATIONALE: These registration forms will not be readily available to
> enquirers after the meaning of a specific language or variant tag.
> Making sure that all the information is included in the registry is
> therefore important, even at the cost of a larger registry.  
> Registered
> languages will be very rare, and registered variants fairly 
> rare, based
> on existing experience, so the cost will not be very great.
> 

No - digital ink's not a sparse resource - experience with MIME,
Charset, and other registries implies a more complete registration
form is always better.

Also, the actual registration form _is_ available online for every
MIME type - why shouldn't these language tag forms also be online
(but not in the Registry proper)?

> --
> usage: mt [-v] [--version] [-h] [ -f device ] command [ count ]
> A rabbi whose congregation doesn't want         John Cowan
> to drive him out of town isn't a rabbi,         
http://www.ccil.org/~cowan
and a rabbi who lets them do it                 [email-masked]
isn't a man.    --Jewish saying                 http://www.reutershealth.com

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

---

From: John Cowan <[email-masked]>
Date: Thu, 7 Apr 2005 12:48:17 -0400

> Agree - but only when a tag is claimed to be canonicalized

This is actually a disagreement.  Currently canonicalized tags are required
to use alpha order for extensions, tags in general are not.  I'm proposing
that we require alpha order in all cases, because there is no reason not to.
"Provide every way, one way, or no way to do something."  I'm recommending
one way: alpha order.

> canonicalized form for best understanding by mere humans). 

Most of the time there is no reason to display language tags at all: properly
localized language names make more sense.

> Charset, and other registries implies a more complete registration

I am not recommending that the amount of data on the form be shrunk, merely
that all that data be included in the registry as well.

> (but not in the Registry proper)?

They will be, but will probably not be copied to all systems they way (we hope)
the registry will be.

-- 
De plichten van een docent zijn divers,         John Cowan
die van het gehoor ook.                         [email-masked]
      --Edsger Dijkstra                         http://www.ccil.org/~cowan