Message-Id: <6.2.1.2.2.20050506013029.03612910@mail.jefsey.com>
Date: Fri, 06 May 2005 01:52:12 +0200
To: "McDonald, Ira" <imcdonald@sharplabs.com>,
	"'Addison Phillips'" <addison.phillips@quest.com>,
	Doug Ewell <dewell@adelphia.net>, LTRU Working Group <ltru@ietf.org>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: RE: [Ltru] Re: John Cowan's substantive comments
	ondraft-ietf-ltr u-registry-01
In-Reply-To: <CFEE79A465B35C4385389BA5866BEDF00C7B95@mailsrvnt02.enet.sh
	arplabs.com>
References: <CFEE79A465B35C4385389BA5866BEDF00C7B95@mailsrvnt02.enet.sharplabs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: 
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

At 18:27 05/05/2005, McDonald, Ira wrote:> > Have all of John Cowan's items 
from April 6 been addressed?
> > > 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.

"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.

> > > 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.

RFC 1958. Full stop. Here is IETF and Intenet. If this was not the case, 
the proposition would not fly.

> > > 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.

I would disagree: reminding people is good. If well worded a ballanced 
presentation clarifies a presentation.

> > > 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.

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


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru