Subject: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) Private Use Tags

From: "Doug Ewell" <[email-masked]>
Date: Fri, 8 Jul 2005 07:41:19 -0700

I do not favor either removing or further discouraging private-use tags
or subtags in "x-".  I'll have more to say about this later.

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

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

---

From: "John.Cowan" <[email-masked]>
Date: Fri, 8 Jul 2005 12:46:12 -0400

> or subtags in "x-".  I'll have more to say about this later.

+1

-- 
John Cowan  [email-masked]  www.ccil.org/~cowan  www.reutershealth.com
If I have seen farther than others, it is because I was standing on
the shoulders of giants.
        --Isaac Newton

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 8 Jul 2005 12:22:45 -0700

Hi -

> From: "John.Cowan" <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, July 08, 2005 9:46 AM
> Subject: Re: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) Private UseTags
>

> > or subtags in "x-".  I'll have more to say about this later.
...

It's clear from the posts so far that "eliminate" won't get consensus
support, due to legacy concerns. So, please, let's narrow the discussion
to whether the text makes the risks / limitations on the use of them
sufficiently clear.  There are currently two proposals for text:

(1) "Private-use subtags require private agreement between the parties
    that intend to use or exchange language tags that use them and they
    MUST NOT be used in content or protocols intended for general use
    unless it can be guaranteed that they will not inadvertently show up
    in parsing agents used by other parties with private-use agreements
    that coincedentally employ the same alphanumeric sequence."

(2) "Private-use subtags require private agreement between the parties
    that intend to use or exchange language tags that use them. Great
    caution SHOULD be used in employing them in content or protocols
    intended for general use. Private-use subtags SHOULD respect the
    general format contraints. Even used in a private context, general
    libraries are legitimate in only using the part of each subtag which
    matches the general ABNF [or in disregarding the subtags wich
    does not match the general ABNF]. Private-use subtags are
    simply useless for information exchange without prior arrangement."

As a technical contributor, I rather like (1), even though its proposer
says it was deliberately written to sound ridiculous.  I can't support
(2) in its current form, but could live with a modified version of (2)
that I'll call (2a):

(2) "Private-use subtags require private agreement between parties
    intending to use them. Use great caution if employing them in
    content or protocols intended for general use. Private-use subtags
    MUST conform to the format contraints specified in the ABNF.
    Private-use subtags are useless for information exchange without
    prior arrangement."

Randy

---

From: r&d afrac <[email-masked]>
Date: Fri, 08 Jul 2005 22:36:25 +0200

>     Private-use subtags are useless for information exchange without

I must apologise for the troll ... I knew you would respond this way.

Randy, you bring nothing new, here. The ABNF is already a MUST. Repeating a 
law you cannot enforce is not what is expected. What is expected is you to 
define the verdict when your MUST is disregarded. You know that we will not 
respect that MUST. We fully documented it, we have an on-line site for that 
- and most probably many others will do it because - as Prof. F. Charles 
documented it - it does not make sense. I know you do not care about 
others, but nevertheless there will be a group of users (may be 
substantial) who will disregard the MUST. What the general developper wants 
to know is what is him to do in that case. I propose two responses. You may 
have another one.
jfc

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 8 Jul 2005 22:20:13 -0700

Re: [psg.com #1061] eliminate (or proscribe) Private Use Tags

Dylan N. Pierce <dylanpierce at megared dot net dot mx> wrote:

> But if it's doing "Just this," then let's put our money where our
> mouths are and say, "Just this." We don't need private use tags at
> all if we are in agreement that corollary information, no matter how
> closely related, should be handled outside the tag and, as Randy
> notes, we shouldn't encourage the twisting of the tag by saying,
> "Here's your scribble area."

I don't think it's a matter of encouraging.  Users who want to twist the
tag will do so, whether we want them to or not.  Private-use subtags in
"x-" give them a way to stay conformant while still tacking private crud
onto the end of a tag, and it gives tag consumers a way to stay
conformant while choosing to either (a) attempt to interpret the crud or
(b) ignore it.

> Cripes, all of XML is the scribble area; we can afford
> to keep the tag clean.

This language-tag thing isn't just for XML, as we've said.

Randy replied:

> Would a stronger version of this (or the following paragraphs address
> the concerns?  If so, proposed text would be appreciated.

I think Section 4.5 is strong enough as it is.  It says that PU tagging
requires a private agreement, which is true.  It says to be cautious
about allowing them to leak into the general environment, which is true.
It employs the rather strong word "useless."  I don't see much benefit
in either removing the feature or beating users over the head with
warnings not to use it.

More later, as I get to additional messages on this topic.  I'm making
my way through 5 digests' worth of LTRU material, which I do NOT get a
chance to respond to while I'm at work.

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 8 Jul 2005 22:30:56 -0700

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

> For _valid_ UN numbers at date-B I got the idea, and that
> covers 831..833 for File-Date: 2005-07-05, even 830, tough.
>
> But not 200. the only "200" on their page belongs to 2005.
> 200 is AFAIK also no "valid candidate for registration".
> And it never was, so even a time machine wouldn't help.

OK, if nobody else objects, I agree to remove 200 from Section 4 of
draft-initial-02.

> IANA:  Are we sure that they manage it to extract the real
> registry from your I-D ?  Scott said "assume the worst" or
> similar.
>
> Maybe a short note "remove page headers and three leading
> spaces in all lines of chapter 3, the first line should
> be the File-Date line" helps in the IANA considerations.

I thought this was already clear enough in the introductory text to
Section 3.  I suppose I could add a pointer to that text in the "IANA
Considerations" section.  Actually repeating the text seems quite
unnecessary.

> Some comments like "replaced by ISO code lb" aren't strictly
> necessary, the Prefered-Value: lb is clear.  But no problem.

I completely agree about the sheer uselessness of comments like this,
whose information is wholly duplicated within other fields.  I don't
like them, and didn't want to put them in.  But others seems to like
them.

>> No ISO 3166 codes fall into this category, only UN numeric
>> codes.
>
> That's still wrong in draft -08 (2.2.4 3E).

The fact that (3E) says unassigned UN codes may be registered is wrong,
and inconsistent with Section 3.3 (11), and needs to be fixed.  (This is
my opinion, and subsequent messages showed there is not complete
agreement about this.  More later.)

The fact that (3E) also mentions ISO codes is not much of a problem; it
is not incumbent on draft-registry to reflect the exact contents of
draft-initial (if so, the latter would be unnecessary).  But the rules
would be different:  ISO codes not already included would be
registrable, while UN codes would not.

> Really, it lists all four #1026 codes, why do they want that
> you have a complete chapter about excatly the same four codes ?
> IANA is most probably not interested what we do NOT register.

But readers might be.  It's not a long chapter.

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 8 Jul 2005 22:52:47 -0700

Dylan N. Pierce <dylanpierce at megared dot net dot mx> wrote:

> The tag "zh-Hans-XQ" provides enough information that parsing agents
> know what they don't know: the region. The legitimate-but-opaque tag
> "zh-Hans-x-whoKnows" might contain a privately-defined region... but
> if so, why not use the first option? It also might contain something
> that's completely outside the intended scope of the language tag. If
> we're serious about what these tags are meant to represent, why make
> it possible to work against it? This returns to the "scribble space"
> issue.

Private-use regions should be encoded as "XQ" (or whatever), private-use
scripts as "Qaaa" (or whatever), and so forth.  I do not question that.
Private-use subtags of the form "x-whoKnows" are best used for concepts
that, if registered, would take the form of a variant or an extension -- 
something for which built-in private-use areas are not available.

I agree completely that "zh-Hans-XQ" is better than
"zh-Hans-x-whoKnows", *IF* the private-use thing in question is a
region.  But if the tagger is attempting to indicate a spoken accent, or
some other attribute of the language variety other than region, and
doesn't have a registered variant or extension RFC to turn to, then the
subtag in "x-" is really her only alternative.

> I'm not sure a stronger version of the warning itself would clarify
> this. It would have to say something like:
>
> "Private-use subtags require private agreement between the parties

I think this is far too strong.  It is impossible to "guarantee" that
such leakage, even if inadvertent, will not occur.  It is possible to
encourage taggers strongly not to toss these things out into the
marketplace willy-nilly, as some sort of corporate de-facto standard
(Dylan talks about this later), and it might be a good idea to add such
wording.  But I think MUST NOT goes too far.

> What does allowing an unknown "something else" gain in clarity or
> interoperability?

The ability to concoct a private agreement and achieve interoperability
within the confines of that agreement.

> So I guess at this point, what I am looking at isn't proposed new
> text, or proposed changes in text, but a proposed elimination of text,
> to whit, the text defining the private-use subtag "x". My question:
> is the gain in "swallowing comfort" won by unregulated, unparsable
> private-use tags worth the corresponding loss in clarity and
> interoperability?

It doesn't tend to work out that way.  Currently, RFC 3066 allows
private-use whole-tags (not subtags) of the form "x-whoKnows" (which of
course are much less interoperable than "zh-Hans-x-whoKnows" since they
don't contain ANY publicly understood information), and it turns out
that there is no great problem with private-use x-tags being generated
and spread all over the internet and elsewhere.  They just aren't that
common in the real world.  (In fact, during the "matching" portion of
our show, we heard repeatedly that many existing tag parsers assume all
RFC 3066 tags are of the form "xx" or "xx-xx" and would choke on script
subtags; these parsers obviously would choke on private tags as well.)
In short, I think the problem is overstated.

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 09 Jul 2005 09:08:53 +0200

Doug Ewell wrote:

> I agree to remove 200 from Section 4 of draft-initial-02.

Fine.
 
 [IANA]
> Actually repeating the text seems quite unnecessary.

Okay, Randy said it should work without more details.

 [Comments replicating the Preferred-Value] 
> I completely agree about the sheer uselessness of comments
> like this, whose information is wholly duplicated within
> other fields.  I don't like them, and didn't want to put
> them in.  But others seems to like them.

I don't recall any "others", but it's no problem, only ugly.

                    Bye, Frank