Subject: RE: [Ltru] Re: John Cowan's substantive comments ondraft-ietf-ltr u-registry-01

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 5 May 2005 09:27:45 -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 Addison Phillips
> Sent: Thursday, May 05, 2005 11:53 AM
> To: Doug Ewell; LTRU Working Group
> Subject: RE: [Ltru] Re: John Cowan's substantive comments
> ondraft-ietf-ltru-registry-01
> 
> > 
> > Have all of John Cowan's items from April 6 been addressed?
> [Addison Phillips] 
> 
> No they haven't been inserted because there was no consensus 
> on them. Yes, they were addressed: I, at least, didn't agree 
> with some of them.
> 
> > 
> > http://www1.ietf.org/mail-archive/web/ltru/current/msg00607.html
> > 
> > Here's a summary:
> > 
> > 1.  Require that extension subtags already be sorted by 
> singleton order
> > in well-formed tags.
> [Addison Phillips] 
> 
> No. I feel that is a function of canonicalization, not wellformedness.
> > 

Agree with Addison.

> > 2. and 3.  Disallow "i", "y", and "z" as singletons in extension
> > subtags.
> [Addison Phillips] 
> 
> No. I feel there is no reason to further restrict the 
> available letters. Extensions cannot start a tag (the place 
> where the subtag 'i' currently appears in tags). 
> > 

Agree with Addison - no need for the restriction.

> > 4.  Canonicalizing a tag also normalizes the case of the 
> letters in it.
> [Addison Phillips] 
> 
> There is no reason to insist on this. We can add a note suggesting it.
> > 

Wait - canonicalization should always involve case normalization,
if possible, so that the resulting strings can be binary compared.
The various cases used for elements currently (e.g., "Latn", "GB",
"en", etc.) are coherent with the ISO source standards but are a
pain for canonicalization.  For what it's worth, all printing
industry standards (CIP4 JDF, IEEE PWG PSI, etc.) follow IETF IPP/1.1 
(RFC 2911/2910) usage and require that language tags be normalized to 
lowercase.  Since language tags themselves are a subset of ASCII, 
this is simple and appropriate.

> > 5. and 6.  (already resolved)
> > 
> > 7.  Remove private use tags from the registry, which in 
> turn makes the
> > definition of value ranges superfluous.
> [Addison Phillips] 
> 
> We could do that, but it is useful to remind people of the 
> private use subtags.
> > 

Agree with Addison.

> > 8.  Reform the language tag registration form, and add 
> information from
> > that form to the registry.
> [Addison Phillips] 
> 
> I'm partial to John's suggestion here and I did reform the 
> registration form, but the following items have no field 
> defined currently:
> 
> 1. Name of requester:
> 2. E-mail address of requester:
> 4. Intended meaning of the subtag:
> 5. Reference to published description
> of the language (book or article):
> 6. Any other relevant information:
> 
> Name of the requester could be given a field ("Registered-By"??)
> 
> Email address of the requester and reference to published 
> description would probably require us to add support for the 
> other valid URI (RFC3986) characters to a field-value, since 
> a common way to reference materials is in the form of a URI. 
> Otherwise the reference is a comment-like field. I'm not sure 
> that putting the email address into the registry is a good 
> idea: it's useful during the registration process, but not 
> necessarily useful afterwards.
> 
> "Any other relevant information" could be "Comment" and can 
> be removed. It is good form to put such a field into a form, though.
> 
> I'm not sure how "intended meaning" differs from the 
> description field in the record. We could probably remove that.
> 

Disagree with Addison - as Mark Davis has replied, we should
archive the registration forms and extract only the minimum
necessary fields into the registry itself.

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

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 06 May 2005 01:52:12 +0200

At 18:27 05/05/2005, McDonald, Ira wrote:> > Have all of John Cowan's items 
from April 6 been addressed?
>Agree with Addison - no need for the restriction.

"extensions cannot start a tag" should not be taken for granted. The 
proposed melt langtag (script, language, region, etc.) sustains a confusion 
in usage that will certainly be used by many to other needs. The same you 
identified the need this time to insert scripts into langtags, the next RFC 
3066 bis reviewer will propose to correct the imposed lack of extensibility 
resulting from associating a langtag with a identfied language (what is 
pretty absurd when you consider that we all use polylingual, single script, 
keyboards).

So, you should consider how to reduce the complexity of their task.

>this is simple and appropriate.

RFC 1958. Full stop. Here is IETF and Intenet. If this was not the case, 
the proposition would not fly.

> > We could do that, but it is useful to remind people of the

I would disagree: reminding people is good. If well worded a ballanced 
presentation clarifies a presentation.

>necessary fields into the registry itself.

The IANA registry can only contain the same fields as the completed 
standard. You would otherwise engineer conflicts. You would also have to 
document the case where an existing ISO code is to be registered to add 
information the ISO standard does not contain.

Let take an example you love, en-Latn-US. What if someone wants to register 
it in adding a comment "Internet koine, its command is required to access 
to the Internet standards and programing environment", the debate will most 
probably result into an Internet split. Do you really want it?

jfc