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

From: John Cowan <[email-masked]>
Date: Wed, 6 Apr 2005 20:09:30 -0400

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.

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.

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.

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.

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.

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.

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.

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.

--
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: Frank Ellermann <[email-masked]>
Date: Thu, 07 Apr 2005 05:45:40 +0200

John Cowan wrote:

> registry-cowan-01: Alpha order in extension subtags
[...]
> Meaningless variability is reduced.

Sounds like a good idea.

> registry-cowan-02: Ban singleton "i"
[,,,]
> Eliminating "i" does not significantly reduce the space of
> singletons available for registration.

True, besides two out of ijl are enough, let's reserve i for
grandfathered iana tags.

> registry-cowan-03:  Ban singletons "y" and "z"
[...].
> Eliminating "x" and "y" does not greatly reduce the space
> of singletons available for registration.

Why not just add "y" and "z" to the priate-use singletons ?

> registry-cowan-04: Specify case rules for canonical tags

NAK, no case-sensitive tags.  It's okay if the registry adopts
the style of its sources, and if 3066bis documents this, but
otherwise tags are case-insensitive.  Come on, it's only ASCII,
no stringprep headaches.

> registry-cowan-05: RFC 822 line wrapping in the registry

Yes, record-jar as "documented by Google".  RfC 2822 has FWS:

| FWS = ([*WSP CRLF] 1*WSP)    ; Folding white space

We don't want obs-FWS, that's a variant of 2234bis LWSP, if I
got it right, it could result in blank lines (trailing blanks).

> registry-cowan-06: Remove leading zeros from character
> references

Apparently XML does this, and charmod says "one form" + "hex.",
sigh.  Please don't try this in (X)HTML, but here it's okay.

> registry-cowan-07: Remove private use tags from the registry
> and sample registry.
[...]
> remove the concept of value ranges from Section 3.1, which is
> is needed only for private use tags.

How about listing the first and last tags of private ranges ?

> Those who wish to use them can look at the RFC.

If I see something I don't know it could be "new".  If I see a
private tag it's "bad" from my POV, otherwise I would know it.
That's a (small) difference.

> Requester, Requester-Email, Description, Meaning,
> Native-Name, Reference, Comments.

Okay, but I'd prefer to have a URL with the (verbose) form, or
maybe individual files for each tag with the details, and a
compact registry incl. URLs for these files.  Now we would need
a "Content-Base", some more rounds and we reinvent MIME or XML
or both.

> even at the cost of a larger registry.

IBTD, huge documents are evil.  Bye, Frank

---

From: "Jon Hanna" <[email-masked]>
Date: Thu, 7 Apr 2005 05:11:10 +0100

> otherwise tags are case-insensitive.  Come on, it's only ASCII,

Canonicalisation rules can sometimes be usefully mandated in narrow cases
even if they are purely an informal (but documented) style in the source
standard.

Regards,
Jon Hanna
Work: <http://www.selkieweb.com/>
Play: <http://www.hackcraft.net/>
Chat: <irc://irc.freenode.net/selkie>

---

From: John Cowan <[email-masked]>
Date: Thu, 7 Apr 2005 00:59:15 -0400

> Why not just add "y" and "z" to the priate-use singletons ?

One private-use singleton is plenty.

> otherwise tags are case-insensitive.  Come on, it's only ASCII,

I am *not* proposing case-sensitive tags, simply a uniform casing
style for *canonical* tags.  (I'd prefer all lower case myself,
but that doesn't seem to be customary.)

> sigh.  Please don't try this in (X)HTML, but here it's okay.

In fact both HTML and XML now accept hex character references
with or without leading zeros.  The only difference between current
and earlier HTML is that older HTML systems accepted only decimal
character references with or without leading zeros.

> How about listing the first and last tags of private ranges ?

That's in effect what is done now.

> a "Content-Base", some more rounds and we reinvent MIME or XML

IANA will already publish the verbose forms, as it does today.

> IBTD, huge documents are evil.  Bye, Frank

"Larger" doesn't necessarily mean "huge".

-- 
John Cowan  [email-masked]  www.reutershealth.com  www.ccil.org/~cowan
I am he that buries his friends alive and drowns them and draws them
alive again from the water. I came from the end of a bag, but no bag
went over me.  I am the friend of bears and the guest of eagles. I am
Ringwinner and Luckwearer; and I am Barrel-rider.  --Bilbo to Smaug

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 6 Apr 2005 23:26:47 -0700

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

> Meaningless variability is reduced.

Ok by me.

> does not significantly reduce the space of singletons available for

No. This is no reason to reduce the extension space.

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

> are known to be canonical.

Ok by me.

> RATIONALE: Compatibility with RFC (2)822.

Don't care either way.

> is also compatible with XML and allows only one possible encoding for

Don't care either way.

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

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

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 07 Apr 2005 08:37:55 +0200

Jon Hanna wrote:

> Canonicalisation rules can sometimes be usefully mandated in
> narrow cases even if they are purely an informal (but
> documented) style in the source standard.

Okay, probably I got John's idea wrong.  As long as it doesn't
affect matching, parsers, or Addisons's ABNF it's acceptable -
Doug and later the tag reviewer can live with "canonical tags".

                       Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 07 Apr 2005 09:23:58 +0200

> One private-use singleton is plenty.

Probably, but completely excluding "y" and "z" is strange.  How
about reserving "y" and "z" like "i" for alternate schemes at
the begin of a tag, e.g. for Debbie's ISO 639-4 alpha-4 codes ?

> with or without leading zeros.

In theory, in practice 2 of my 4 browsers hate hex. references.
I really tried that the W3C mentions this in "charmod".  But
here we could use your notation for &#A0; up to &#x10FFFF;

        hcr = "&#x" ( h6 / h5 / h4 / h3 / h2 ) ";"
        h6  = "10" hex hex hex hex
        h5  = h1 hex hex hex hex 
        h4  = h1 hex hex hex
        h3  = h1 hex hex
        h2  = ha hex
        ha  = "A" / "B" / "C" / "D" / "E" / "F" 
        h1  = %x31-39 / ha
        hex = %x30-39 / ha

If somebody really insists on &#x85; it's time to close LTRU.

                           Bye, Frank

---

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

> although that is not the chief reason for retaining them.)

To clarify: I am not proposing the elimination of private-use codes
from the set of valid subtags, merely their elimination from the *registry*.

> registration entry is a good feature.

Why?

-- 
Winter:  MIT,                                   John Cowan
Keio, INRIA,                                    [email-masked]
Issue lots of Drafts.                           http://www.ccil.org/~cowan
So much more to understand!                     http://www.reutershealth.com
Might simplicity return?                        (A "tanka", or extended haiku)