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

From: "Addison Phillips" <[email-masked]>
Date: Thu, 5 May 2005 08:53:17 -0700

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

[Addison Phillips] 

Thanks,

Addison

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

---

From: "Doug Ewell" <[email-masked]>
Date: Thu, 5 May 2005 23:13:57 -0700

Addison Phillips <addison dot phillips at quest dot com> wrote:

> No they haven't been inserted because there was no consensus on them.

I knew they weren't all reflected in the draft; that wasn't my question.
Of the ones that weren't, I didn't know which had been rejected and
which had not been discussed adequately to determine consensus pro or
con.

> Yes, they were addressed: I, at least, didn't agree with some of them.

I don't either, as seen below.

>> 1.  Require that extension subtags already be sorted by singleton
>> order in well-formed tags.
>

I agree.  Well-formedness is not related to content at all, except for
grandfathered tags.  "pu-Blaz-FU-scrog" is well-formed.

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

I agree.  The stated benefit of excluding 'i' is that it prevents a
"confusing" situation that may not ever actually materialize.  IETF can
always defer assigning 'i' if they think it will cause confusion.
Excluding 'y' and 'z' to preserve alpha order doesn't make things
significantly easier for implementers (IMHO as someone who's implemented
a validating parser).  The order is already alpha "except for x," which
isn't that hard to implement.

> There is no reason to insist on this. We can add a note suggesting it.

I actually kind of like this one.  Unlike well-formedness,
canonicalization does imply something about the content.  There might be
some trouble with "yi-latn," a grandfathered tag which was registered
with that capitalization (lowercase L).  It's true that strict binary
equivalence is not necessary for matching, but normalizing the case
might make things "prettier" in the same way as sorting the extensions.

>> 7.  Remove private use tags from the registry, which in turn makes
>> the definition of value ranges superfluous.

Moot since John withdrew the proposal.  (I didn't like it because I feel
it's important to point out the validity of the private-use tags, which
were not valid in RFC 3066.)

>> 8.  Reform the language tag registration form, and add information
>> from that form to the registry.

I disagree with adding any more encyclopedic information to the
registry.  It should only contain the information necessary to implement
the tagging mechanism.  In particular, registering the name and e-mail
address of the requester of a subtag may give the impression that that
person is some sort of expert or authority on the language variant (or
whatever), which is not necessarily true; he or she may simply have been
the one who filled out the form.

--
Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/

---

From: Marion Gunn <[email-masked]>
Date: Fri, 06 May 2005 09:42:30 +0100

Surely one field could contain 1-6 below en bloc (as only useful when
taken together). 

'Reg-background' as field tag? 

mg

Scríobh 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:
> Name of the requester could be given a field ("Registered-By"??)...
> Addison

-- 

Marion Gunn * EGTeo (Estab.1991)
27 Páirc an Fhéithlinn, Baile an 
Bhóthair, Co. Átha Cliath, Éire.
* [email-masked] * [email-masked] *