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

From: "Dylan N. Pierce" <[email-masked]>
Date: Fri, 08 Jul 2005 18:09:17 -0500

Randy Presuhn wrote:

 > ....  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."
 >
 > (2[a]) "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

How about a non-ridiculous middle ground?

(3) "Private-use subtags require private agreement between parties 
intending to use them. They MUST NOT be designed for distribution 
outside of the private agreements for which they are intended. Tags 
intended for wider distribution SHOULD be registered instead as 
extensions with the [registration authority]. There MUST NOT be 
consequences for any application which chooses to ignore private use 
tags. Developers of private use tags should use great caution in 
ensuring that their applications are aware of, and can handle, the 
possibility of a conflicting private use tag from an external private 
agreement which appears similar to one of their own."

If we can't get rid of them, after all, the least we can do is ensure 
that the poor working hacks like me receive a heads-up in unambiguous 
language. Programmers /do/ read these things, but we can't always assume 
they think through the implications well. No harm in throwing them a rope.

--Dylan

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 8 Jul 2005 16:38:00 -0700

Hi -

> From: "Dylan N. Pierce" <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, July 08, 2005 4:09 PM
> Subject: Re: [Ltru] Re: [psg.com #1061] eliminate (or proscribe)Private UseTags
...
> they think through the implications well. No harm in throwing them a rope.
...

As a technical contributor, I agree whole-heartedly with your rationale.
I'd tweak the proposal a bit...

 (4) "Private-use subtags require agreement between parties
  intending to use them. They MUST NOT be distributed beyond the scope
  of the relevant agreements. Subtags intended for wider
  distribution MUST be registered. Developers of private-use subtags are
  warned that, despite this prohibition, private-use subtags might
  "leak" beyond the scope of the agreement defining them.  This means that
  applications making use of private-use tags need to be able to cope with
  conflicting (same character sequence but differing semantics) and unknown
  private-use tags.

Randy

---

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

>   conflicting (same character sequence but differing semantics) and unknown

Let's go with this language and close the issue.

-- 
While staying with the Asonu, I met a man from      John Cowan
the Candensian plane, which is very much like       [email-masked]
ours, only more of it consists of Toronto.          http://:www.ccil.org/~cowan
        --Ursula K. Le Guin, Changing Planes

---

From: "Dylan N. Pierce" <[email-masked]>
Date: Fri, 08 Jul 2005 18:52:01 -0500

>   conflicting (same character sequence but differing semantics) and unknown

I have no problem with any of the changes you made here; just one point 
on an omission which I'm willing to abandon immediately if my case is 
unconvincing. Regarding the line in my original:

"There MUST NOT be consequences for any application which chooses to 
ignore private use tags."

This, in my mind, was a protection against the MS-JVM phenomenon, where 
an organization with wide product distribution can implement its own 
private refinements, and then, simply through product saturation, win a 
position with products that don't quite "work" without their 
refinements. To make sure that even an enormous company or organization 
can't, simply through product share, implement a fait accompli 
adaptation of the standard.

If that possibility doesn't bother anyone, I willingly abandon the 
petition on that line.

Dylan

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 8 Jul 2005 17:05:30 -0700

Hi -

> Sent: Friday, July 08, 2005 4:52 PM
> Subject: Re: [Ltru] [psg.com #1061] eliminate (or proscribe)Private Use Tags
>
...

To clarify...
As a technical contributor, I had dropped the "consequences" sentence
because I couldn't figure out exactly what it was supposed to mean,
particularly in the RFC 2119 interpretation of the "MUST NOT" keyword.
There isn't anything we can really do about a private-use subtag that
enters the wider realm of discourse.  Those familiar with SMTP and NNTP
headers may be able to think of similar situations from the past.  :-)
It's one of the inherent risks of having this kind of mechanism, but it's
already a legacy problem.

Randy

---

From: "Mark Davis" <[email-masked]>
Date: Fri, 8 Jul 2005 17:25:06 -0700

We can't say:

>> They MUST NOT be distributed beyond the scope
> >   of the relevant agreements.

since people doing the distribution may not know what the scope is.

>> Subtags intended for wider
> >   distribution MUST be registered.

This is not actionable. wider than what? If I am using a protocol that
transports language tags, is it incumbent upon me to examine the meaning of
all of them? I think not.

The only thing we can really say is that:
- don't use private use tags if you can at all avoid it
- the only meaning they have is up to private agreement between parties
- be aware if you do use them that they have no meaning -- or a different
meaning! -- outside of the scope of a particular private agreement.

Randy's original is better:

> (2) "Private-use subtags require private agreement between parties

Except that the "Private-use subtags MUST conform to the format constraints
specified in the ABNF." is redundant. ALL subtags must conform to the format
constraints specified in the ABNF. So I would just suggest the simpler

(2) "Private-use subtags have no meaning outside of a private agreement
between parties. They may also be given different meanings by different
private agreements between those or other parties. Thus they SHOULD NOT be
used wherever there is alternative, and they SHOULD NOT be used in content
or protocols intended for general use.

‎Mark

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 8 Jul 2005 18:00:23 -0700

Hi -

> From: "Mark Davis" <[email-masked]>
> To: "John.Cowan" <[email-masked]>; "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, July 08, 2005 5:25 PM

That's the point of using an RFC 2119 "MUST NOT".  It means "things
won't work if you do this".

> all of them? I think not.

No.  Again, this is an RFC 2119 "MUST".  It means, "in order for things
to work correctly , you have to do this".  It is not imposing a requirement
on the things that shovel tags around, just on the entity (which may be a human)
that decides how to tag something.

> meaning! -- outside of the scope of a particular private agreement.

Here we're agreed.

> constraints specified in the ABNF. So I would just suggest the simpler

The reason I included the redundant element is because there indications
that someone plans to disregard the ABNF in their implementation.  Such
is their right, but I don't want them to have any excuses when things
don't work correctly.

...

I could also live with this, if it will allow us to put this item to rest,
though I'd prefer if the second "SHOULD NOT" were a "MUST NOT".

Randy

---

From: "Mark Davis" <[email-masked]>
Date: Fri, 8 Jul 2005 18:16:24 -0700

> is their right, but I don't want them to have any excuses when things

The thing that bothers me is that some might conclude that *other* subtags
don't have to conform to the format constraints. So how about:

Private-use subtags, like all other subtags, MUST conform to the format
constraints specified in the ABNF.
> though I'd prefer if the second "SHOULD NOT" were a "MUST NOT".

I thought of saying MUST NOT, but that is too strong. There may be a private
use tag for something that is later added. You wouldn't want to say that the
tag is then not conformant. So I suggest the language plus the format clause
you wanted:

(2) "Private-use subtags have no meaning outside of a private agreement
between parties. They may also be given different meanings by different
private agreements between those or other parties. Thus they SHOULD NOT be
used wherever there is alternative, and they SHOULD NOT be used in content
or protocols intended for general use. Private-use subtags, like all other
subtags, MUST conform to the format constraints specified in the ABNF.

What do you think of that?

‎Mark

---

From: r&d afrac <[email-masked]>
Date: Sat, 09 Jul 2005 04:44:15 +0200

>What do you think of that?

Dear Mark and Randy,
I submit that this is not a very important change in text, but it 
translates an important change in the spirit of RFC 3066. This is a true 
lack of spirit retrocompatibility. I have nothing against that. To the 
contrary the abandon of strict retrocompatbility permits interesting other 
innovations. But I do not want to suggest them without being supported by a 
consensus, otherwise Randy will say I rise closed issues.

There are 57 folks on this list. I suppose that we could say that this 
proposition is supported by a consensus if 29 (50% +1) supports it. Either 
this proposition is adopted by consensus (I support it), strict 
retrocompatibility is forgotten: then I will propose something everyone 
could agree with to replace x-tags (but which would be opposed now on the 
grounds of retrocompatibility) - or it is not and we will continue with x-tags.

So please every supporter of  this change, and/or opponent to x-tags as we 
want to use them rises hand or humms.

Those who supports x-tags, IMHO you can support Mark's text because if 
strict retrocompatibility is abandonned, the solution I would propose could 
even be better. But there is no need to work on it if there is not a real 
consensus.
Thank you.
jfc

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 8 Jul 2005 23:04:31 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Sent: Friday, July 08, 2005 6:16 PM

...

This, too, would be ok for me.

Randy