Subject: RE: [Ltru] John Cowan's substantive commentsondraft-ietf-ltru-registry-01

From: "Addison Phillips" <[email-masked]>
Date: Thu, 7 Apr 2005 09:24:11 -0700

I'm in complete agreement with Mark, with the provisos shown interlinearly below.

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: [email-masked] [mailto:[email-masked]] On
> Behalf Of Mark Davis
> Sent: mercredi 6 avril 2005 23:27
> To: John Cowan; [email-masked]
> Subject: Re: [Ltru] John Cowan's substantive commentsondraft-ietf-ltru-
> registry-01
> 
> My comments on John's
> 
> ‎Mark
> 
> ----- Original Message -----
> From: "John Cowan" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, April 06, 2005 17:09
> Subject: [Ltru] John Cowan's substantive comments
> ondraft-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.
> 
> Ok by me.
> 
> >
> >
> > 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.
> 
> No. This is no reason to reduce the extension space.
> 
> >
> >
> > 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.
> 
> No. This is no reason to reduce the extension space. And the extra effort
> to
> sort x at the end, given the other work in canonicalizing, is in the noise.
> 
> >
> >
> > 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.
> 
> Ok by me.
[Addison Phillips] 

Okay by me, but I'd prefer not to do this. It doesn't add anything substantial either. Why make a few implementations that emit tags in one case or another non-canonical?
> 
> >
> >
> > 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.
> 
> Don't care either way.
[Addison Phillips] 

Ditto. Notice that by putting a stake in the ground we can make progress...
> 
> >
> >
> > 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.
> 
> Don't care either way.
[Addison Phillips] 

I don't care, but I strongly prefer entities that are regular in form. The entity &#xc0; is less obviously a Unicode value than the entity &#x00C0;
> 
> >
> >
> > 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.
> 
> Absolutely not. There is a place for private use codes, and they are easy
> to
> check for. (Moreover, I believe this breaks compatibility with 1766,
> although that is not the chief reason for retaining them.)
[Addison Phillips] 

I very much support this. I think John's message wasn't that the private use codes would be outlawed, only that they'd be removed from the registry. However, not having them in the registry might confuse implementers into thinking that they didn't have to support those values. Rationale for including these values is in the draft. They should appear in the registry too.
> 
> >
> >
> > 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.
> 
> Don't care much, but having the registration form be a superset of the
> registration entry is a good feature.
[Addison Phillips] 

Fine by me. Practical questions:

1. Should the email be obfuscated? (addison dot phillips at quest dot com??)

2. Should it be an (ASCII) URI? In other words, how should IDN's be handled?

3. Reference is a text field naming documents. Should there be rules for naming URIs? What other restrictions apply?

4. Are the native name rules I have in the draft sufficient?
> 
> >
> > --
> > 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
> >
> >
> 
> 
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru

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

---

From: John Cowan <[email-masked]>
Date: Thu, 7 Apr 2005 13:13:49 -0400

Addison Phillips scripsit:

> Okay by me, but I'd prefer not to do this. It doesn't add anything
> substantial either. Why make a few implementations that emit tags in
> one case or another non-canonical?

The point of canonicalization is to get rid of meaningless differences.  Case
is a meaningless difference.  Let's get rid of it.  Implementations that
prefer not to smash case need not claim their tags are canonical.

> Ditto. Notice that by putting a stake in the ground we can make progress...

I have done so.

> I strongly prefer entities that are regular in
> form. The entity &#xc0; is less obviously a Unicode value than the
> entity &#x00C0;

It's pretty obvious to me.  But in that case, at least standardize on
a fixed convention (at least four digits, five only if required, six
only if required, say).

> 1. Should the email be obfuscated? (addison dot phillips at quest dot com??)

Up to the proposer, I'd say.

> 2. Should it be an (ASCII) URI? In other words, how should IDN's be handled?

URIs are ASCII by definition.  I am not proposing an IRI.

> 3. Reference is a text field naming documents. Should there be rules
> for naming URIs? What other restrictions apply?

Typically references are to books in hard copy: grammars, dictionaries, etc.

> 4. Are the native name rules I have in the draft sufficient?

I think so.

-- 
On the Semantic Web, it's too hard to prove     John Cowan    [email-masked]
you're not a dog.  --Bill de hOra               http://www.ccil.org/~cowan

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 07 Apr 2005 19:57:52 +0200

Addison Phillips wrote:

 [character references]
> I don't care, but I strongly prefer entities that are regular
> in form. The entity &#xc0; is less obviously a Unicode value
> than the entity &#x00C0;

Let's use <http://www.w3.org/TR/charmod/#C042> up to C048.  It
says "use hex." (C045, C048) and "one form" (C043).  We can use
John's "no leading zeros" or your "4 or 6 digits", but we better
don't allow both.

Your format is not very nice for cases like Réunion and Côte,
and John's format is odd for an odd number of hex. digits.
The syntax for your format would be somewhat simpler:

           hrc = "&#x" ( h4 / h5 / h6 ) ";"
           h4  = hex hex hex hex
           h5  = "0" hex h4
           h6  = "10" h4
           hex = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"

Whatever we do, let's not encode ";" or other printable ASCII
characters, unless it's "&" (&#x26; or &#x0026; resp.)

 [Registration details]
> 1. Should the email be obfuscated? (addison dot phillips at

Yes.

> 2. Should it be an (ASCII) URI? In other words, how should

As specified in RfC 3987, or are you talking about Martin's
mailto I-D ?  I vaguely recall some unanswered questions about
the latter on the URI list.

> 3. Reference is a text field naming documents. Should there
> be rules for naming URIs? What other restrictions apply?

Are angle brackets not good enough, or what is the problem ?

Just in case.  Actually I don't like the proposal to add all
registration details to the registry.

                        Bye, Frank