Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03

From: John C Klensin <[email-masked]>
Date: Sat, 10 Mar 2012 13:35:03 -0500

--On Thursday, March 08, 2012 16:22 -0700 Peter Saint-Andre
<[email-masked]> wrote:

>...
>> The class is "names that are syntactically designed to be
>> outside of standards space" because such names have a
>> regularly tendency to become de facto standards, which makes
>> formally standardizing them problematic.

Agreed.

>> This is true for "experimental" names, "vendor" names, and
>> any other kind of non-standard name.

The leap to "any other kind of non-standard name" doesn't
follow.  

>> The premises behind the concern are a) registration is
>> difficult, b) the name should flag the status.
>> 
>> What the community has learned or the thirty-or-so years of
>> the construct is that it's better to have a single, clean
>> name space and leave status of the name as a separate issue.
> 
> Well put.
> 
> Yet the inclusion of delimiters in parameter names could be
> construed as just another way segregating the namespace. So I
> think it might be best to remove the fourth bullet point in
> Section 4:
> 
>    4. SHOULD identify a convention to allow local or
> implementation-       specific extensions, and reserve
> delimeters for such uses as       needed.

I admit I found that bullet point confusing.  However, an
interpretation of Dave's statement could extend to a
prohibition, not only on faceted or hierarchical names but on
the "+xml" arrangements and the like that we've used in media
types.  I would encourage you to go even further than simply
removing that bullet point: stick to "X-" parameters and field
names and to "X" commands in this document and let the other
naming and registry issues get sorted out elsewhere.  The cost
of overreaching into very broad statements could be to create a
situation in which all of those other arguments need to be
sorted out twice or, perhaps worse, blocking this until all of
the registration strategy arguments are settled.

   john

p.s. Dave, apologies for forgetting that "extension" was used in
822.  I obviously didn't go back and look.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 10 Mar 2012 10:39:49 -0800

On 3/10/2012 10:35 AM, John C Klensin wrote:
> However, an
> types.

Unless I've entirely misunderstood the use of that qualifier, it indicates an 
encoding framework for the labeled data, not it's 'status'.

As such it would seem irrelevant to the current topic.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Pete Resnick <[email-masked]>
Date: Sat, 10 Mar 2012 12:48:45 -0600

On 3/10/12 12:39 PM, Dave Crocker wrote:

> Unless I've entirely misunderstood the use of that qualifier, it 
> indicates an encoding framework for the labeled data, not it's 'status'.

Ah! That would be a lovely distinction to make in the introduction in so 
many words: It's when a piece of the name is used to indicate a *status* 
rather than a *type* that presents the problem. That would be a great 
clarification.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: John C Klensin <[email-masked]>
Date: Sat, 10 Mar 2012 22:23:51 -0500

--On Saturday, March 10, 2012 12:48 -0600 Pete Resnick
<[email-masked]> wrote:

>> Unless I've entirely misunderstood the use of that qualifier,
>> it  indicates an encoding framework for the labeled data, not
>> it's 'status'.
> 
> Ah! That would be a lovely distinction to make in the
> introduction in so many words: It's when a piece of the name
> is used to indicate a *status* rather than a *type* that
> presents the problem. That would be a great clarification.

Sure.  Except that, while "experimental" or "private use" are
examples of "status", "extension" is a type.  And that, I
believe, takes us back to square one.

    john

---

From: Dave Crocker <[email-masked]>
Date: Sat, 10 Mar 2012 19:32:30 -0800

> believe, takes us back to square one.

1.  It's not a type.

2.  This isn't an exercise in semantics.

The document describes what it is targeting in pretty plain language.  The added 
clarification that Pete has suggested ought to make the language even more plain.

In any event, I've no idea what concern it is that you have.

Perhaps you can state, in simple terms, exactly what problem passage of this 
document causes or what benefit exists in retaining the convention of 
distinguishing X- prefixes, and the like?

d/
-- 

   Dave Crocker

---

From: Pete Resnick <[email-masked]>
Date: Sat, 10 Mar 2012 21:33:36 -0600

> believe, takes us back to square one.

No, you've misunderstood my distinction, which means we haven't gotten 
the wording quite right. When I said "type", I meant "type of *content* 
being named". So, "+xml" is indicating a "type" of data or content. 
"Extension" is a status. It's how the *name* is being used, not what the 
*content* is.

pr

---

From: Dave Crocker <[email-masked]>
Date: Sat, 10 Mar 2012 19:37:29 -0800

On 3/10/2012 7:33 PM, Pete Resnick wrote:
> No, you've misunderstood my distinction, which means we haven't gotten the
> wording quite right. When I said "type", I meant "type of *content* being
> named". So, "+xml" is indicating a "type" of data or content. "Extension" is a
> status. It's how the *name* is being used, not what the *content* is.

+1

d/
-- 

   Dave Crocker

---

From: Pete Resnick <[email-masked]>
Date: Sat, 10 Mar 2012 21:37:52 -0600

On 3/10/12 9:32 PM, Dave Crocker wrote:

> Perhaps you can state, in simple terms, exactly what problem passage 
> of this document causes or what benefit exists in retaining the 
> convention of distinguishing X- prefixes, and the like? 

Perhaps you can indentify the particular word in John's message you 
didn't understand.

Oh, you mean....nevermind.

(Sometimes the forms of queries are attacking and are therefore not 
useful to bringing a conversation to a good conclusion.)

(*grumble*)

pr

---

From: Pete Resnick <[email-masked]>
Date: Sat, 10 Mar 2012 21:38:55 -0600

On 3/10/12 9:37 PM, Pete Resnick wrote:

(Something obnoxious)

I'm VERY sorry. Accidental reply all.

Damn.

pr

--

---

From: John C Klensin <[email-masked]>
Date: Sat, 10 Mar 2012 22:40:18 -0500

--On Saturday, March 10, 2012 21:33 -0600 Pete Resnick
<[email-masked]> wrote:

> No, you've misunderstood my distinction, which means we
> haven't gotten the wording quite right. When I said "type", I
> meant "type of *content* being named". So, "+xml" is
> indicating a "type" of data or content. "Extension" is a

I can buy that, but I don't think the terminology is clear.

    john

---

From: Dave Crocker <[email-masked]>
Date: Sat, 10 Mar 2012 19:41:50 -0800

On 3/10/2012 7:37 PM, Pete Resnick wrote:
> (Sometimes the forms of queries are attacking and are therefore not useful to
> bringing a conversation to a good conclusion.)

indeed sometimes they are.  this wasn't one of them.

for the life of me, I can't figure out what John's substantive concern is with 
the document being considered.

d/

-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Sat, 10 Mar 2012 19:46:24 -0800

> I'm VERY sorry. Accidental reply all.

First email system I built defaulted to reply all.  Head of the Army Materiel 
Command was one of the earliest users and provided a similar demonstration of 
why it's a really, really bad default.

d/

-- 

   Dave Crocker

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 10 Mar 2012 20:48:20 -0700

On 3/10/12 8:46 PM, Dave Crocker wrote:
> First email system I built defaulted to reply all.  Head of the Army
> Materiel Command was one of the earliest users and provided a similar
> demonstration of why it's a really, really bad default.

Hey, would you guys stop sending all these messages on a Saturday night?
I'm trying to write an Internet-Draft... :P

---

From: Pete Resnick <[email-masked]>
Date: Sat, 10 Mar 2012 22:00:47 -0600

Presenting my still purple face, and this time intentionally replying to 
all...

On 3/10/12 9:41 PM, Dave Crocker wrote:
> for the life of me, I can't figure out what John's substantive concern 
> is with the document being considered.

As I said before, I think making the "status vs. type" distinction is 
worth doing, though apparently even I was unable to do it the first shot 
to make it clear to John, though apparently I did on the second 
go-round. An attempt at text:

To the first paragraph of the intro:

    Many application protocols use parameters with textual names to
    identify data (media types, header fields in Internet mail messages
    and HTTP requests, vCard parameters and properties, etc.).
    Historically, designers and implementers of application protocols
    have often distinguished between "standard" and "non-standard"
    parameters by prefixing the latter with the string "X-" or similar
    constructions (e.g., "x."), where the "X" is commonly understood to
    stand for "eXperimental" or "eXtension".

Add: "That is, instead of just identifying the data, the name also 
embedded the status of the name as "non-standard" into the name itself."

Does that help? Do we need more elsewhere in the intro.

pr

---

From: Dave Crocker <[email-masked]>
Date: Sat, 10 Mar 2012 20:08:28 -0800

On 3/10/2012 8:00 PM, Pete Resnick wrote:
>
> Add: "That is, instead of just identifying the data, the name also embedded the
> status of the name as "non-standard" into the name itself."

wfm.

d/
-- 

   Dave Crocker

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 10 Mar 2012 21:23:45 -0700

On 3/10/12 9:08 PM, Dave Crocker wrote:
>> embedded the

For me, too.

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 10 Mar 2012 21:32:07 -0700

>>> status of the name as "non-standard" into the name itself."

Done in our working copy and checked into SVN:

http://svn.tools.ietf.org/svn/wg/appsawg/xdash/

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: John C Klensin <[email-masked]>
Date: Sun, 11 Mar 2012 14:09:28 -0400

--On Saturday, March 10, 2012 22:00 -0600 Pete Resnick
<[email-masked]> wrote:

> Presenting my still purple face, and this time intentionally
> replying to all...
> 
>> for the life of me, I can't figure out what John's
>> substantive concern  is with the document being considered.
> 
> As I said before, I think making the "status vs. type"
> distinction is worth doing, though apparently even I was
> unable to do it the first shot to make it clear to John,
> though apparently I did on the second go-round. An attempt at
> text:
> 
> Add: "That is, instead of just identifying the data, the name
> also embedded the status of the name as "non-standard" into
> the name itself."
> 

Yes, it helps.  And I like Peter's proposed new text.

To answer Dave's question, I have had two specific concerns.
The first is largely covered above and by the new text.  I don't
want to see over-broad statements in this document that could
accidentally constrain approaches, such as specific prefixes or
suffixes for other purposes, that we've found more useful than
harmful in other contexts.

The second is still outstanding.  I think killing off "X-" for
any use that might become widely-used or require standardization
is a great idea and long overdue.   On the other hand, I think
there are private use cases that will never be registered or
standardized no matter what we do.  For them, even if they are
observed in use, I'm concerned about third-party registrations,
unless we want to find ourselves needing to do trademark
searches and/or embroiled in the middle of trade secret
disclosure problems.  As a result, I think it might (please note
that word) be in the Internet's best interest to continue to
have a syntax convention for strictly private (and "agreement
among parties") use.  

I think that option needs a good deal of explanation, most of
which is already present in the document and other things we
have written: inappropriate for experimental use (keywords for
experiments should be registered so that different semantics
don't use the same keyword and so that, if the experiment
succeeds, we don't have multiple keyword issues), inappropriate
for general-purpose extension use (extensions should be
registered so they can be used with reasonable confidence that
both parties are talking about the same thing), and so on.  But,
for true private-use cases, I don't see the harm in permitting
(or even encouraging) "X-" and see some advantages in terms of
putting receivers on notice.

To look at that same position from another point of view, we
have ample evidence that experimental, preliminary, and
extension use of "X-" causes problems and that we should get rid
of those uses on that basis.   We have little or no evidence
that the private use cases are problematic.  Let's not try to
discard / prohibit the latter until we have that evidence... or
until someone makes a really compelling argument that the
community is incapable of distinguishing "private" from
"experimental".

     john

---

From: Dave Crocker <[email-masked]>
Date: Sun, 11 Mar 2012 11:15:50 -0700

On 3/11/2012 11:09 AM, John C Klensin wrote:
> On the other hand, I think
> standardized no matter what we do.

1. The experience with X- is that we can't know ahead of time which cases will 
qualify.  You appear to believe we can.  How?

2. What specific benefits accrue from providing for these cases?

3. What specific problems accrue from the provisions in the current draft?

By 'specific', I'm not asking for a restatement of your concern but for the 
operational effects.

d/
-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Sun, 11 Mar 2012 15:19:05 -0400

Dave,

I think I've explained the answer to your questions several
times.  I'm going to try again but, unless others are also
confused, I'm going to assume that our misunderstanding is
localized and stop cluttering up the list.  No offense is
intended by that statement: I believe that just about everyone
reading this knows that we often see things from perspectives
that are different enough to make misunderstandings common.

 
> 1. The experience with X- is that we can't know ahead of time
> which cases will qualify.  You appear to believe we can.  How?

I believe that the true "private use" cases --e.g., "I'm going
to use this field, or this parameter, to communicate within my
organization or with my business partners" -- are easily
distinguished from the "likely to end up in general use" and
"likely to be standardization candidates" group. are easily
distinguished from the problem cases.  If we really think people
need help, I think we can provide guidance via two questions and
perhaps a third.

	(i) Is this really intended for use strictly within your
	organizational context and not for general use or later
	standardization?
	
	(ii) If you changed your mind and decided it was
	appropriate for more general use, would it need
	significant redesign for use out of your context?

	(iii) Is the meaning or interpretation of this parameter
	or command something that you would consider to be a
	trade secret or other proprietary information?

If the answer to the first two questions is not "yes", then the
application is probably not "private use".  The third question
further qualifies the situation; if the answer to all three is
"yes", then the application is almost certainly private use.

> 2. What specific benefits accrue from providing for these

Non-conflicting use or, more specifically, a warning about
possible conflicting use, of commands, parameters or fields that
are clearly private and that will not be registered and/or
publicly explained no matter how much we change the registration
rules.  Also see "standard for action" below.

> 3. What specific problems accrue from the provisions in the

The current draft deprecates the use of "X" and "X-", even in
those private use cases and does so without providing any
practical recommendation about how to avoid conflicts.
Registration is not practical, or, at least, has never been used
in the past for these cases, there is no reason to believe that
it will be used in the future, nor that it would be effective if
we could convince people to use it.   Use of a syntax convention
for private-use cases provides a warning to implementations that
they need to know with whom they are talking before interpreting
the parameter.   If we get rid of "X-" for other purposes, it
makes that particular use even more attractive.  And, again, we
don't have a practical alternative that preserves that
functionality.

> By 'specific', I'm not asking for a restatement of your
> concern but for the operational effects.

I hope the above is responsive to your request.  In case it
isn't clear, I have seen examples of such private-use parameters
and commands in the past, often to carry organization-specific
magic cookies or classificatory information.

_Standards for Action_

It is worth noting that we have a more or less philosophical
question about the criteria that should used by the IETF for
including or withdrawing a feature.  For the latter, I believe
the standard should be "this specific use causes harm" and not
"some members of the set of capabilities enabled by this feature
cause harm, therefore the whole feature should be banned unless
people can _prove_ that all capabilities are reasonable and
safe".  So, to me, if it is established that experimental and
normal extension uses are problematic and have very little
benefit (and I believe that has been established), we should
deprecate those uses.  It does not follow that we should
automatically depreciate all other uses, nor that anyone
advocating retention of those uses until and unless there is
evidence of harm should be required to prove that they are safe
or even beneficial in a large number of cases.  I think we
should have a commitment to stability to be careful about
blanket deprecation of a feature that has been around for circa
30 years and that such care should lead us to be conservative
and narrow about the actions we take to restrict it.

Otherwise, we can engage in exchanges that amount to "you prove
it is ok" and "no, you prove it is not ok" until long after
exhaustion sets in.

    john

---

From: Bill McQuillan <[email-masked]>
Date: Sun, 11 Mar 2012 12:28:18 -0700

> community is incapable of distinguishing "private" from

Very much agree.

Let's not presume we know all possible ways to use this
convention and pre-declare them all "bad." We have run this
"experiment" (X- names) for a couple of decades and found *some*
problems with them in transitioning from experimentation to
standardization, but I think that with some guidance they *are*
useful for true private use.

-- 
Bill McQuillan <[email-masked]>

---

From: Dave Crocker <[email-masked]>
Date: Sun, 11 Mar 2012 12:42:01 -0700

On 3/11/2012 12:28 PM, Bill McQuillan wrote:
>   I think that with some guidance they*are*

Given two decades of experience, can you site those that have been both 
successful and needed an explicit, standards-level convention (like X-)?

d/
-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Sun, 11 Mar 2012 12:54:25 -0700

On 3/11/2012 12:19 PM, John C Klensin wrote:
> times.

I'm happy to have you cut and paste from your previous notes where you explained 
the specifics.  As I say, I didn't see them.

...
> 	standardization

X- was for these cases.

> 	significant redesign for use out of your context?

The current draft answers that question, with a yes.  It is not about 'redesign' 
but total switching cost.  The former is a rather small subset of the latter.

There's this odd concept, called "installed base", which proves nettlesome for 
such transitions.

> 	trade secret or other proprietary information?

And this requires a public syntax convention why?

Remember this is not about private actions taken privately.  This is about 
public conventions that 'protect' private actions.

> Non-conflicting use

That was the premise for X-.  It has proved more problematic than beneficial.

What actual evidence -- specifics -- do you have to the contrary?  What makes 
other similar conventions subject to different outcomes?

> practical recommendation about how to avoid conflicts.

Ahh, so you actually want to continue to have X-.  It's semantics are exactly 
what you are lobbying for: "won't become a standards-based name"?

> I hope the above is responsive to your request.

Alas, it's not.  You are only stating broad hypotheticals.

> In case it

Excellent.  Those would be specifics.  What are they?

> including or withdrawing a feature.

have or should have?

if have, please cite where it is stated.

if should have, then that's a philosophical debate that I hope is conducted 
separately.

d/
-- 

   Dave Crocker

---

From: Pete Resnick <[email-masked]>
Date: Sun, 11 Mar 2012 15:09:52 -0500

On 3/11/12 2:54 PM, Dave Crocker wrote:
>> I think I've explained the answer to your questions several times.
>
> I'm happy to have you cut and paste from your previous notes where you 
> explained the specifics.  As I say, I didn't see them.
> [...]
> What actual evidence -- specifics -- do you have to the contrary?  
> What makes other similar conventions subject to different outcomes?

Sorry, process interrupt, speaking as the person who is trying to 
determine consensus in the Last Call:

First of all, I did see in John's previous notes several specific 
explications of answers to Dave's questions. I find the Socratic 
questions sent back, and sent at alarming speed, not helpful to my 
assessment of consensus, but rather inviting silly tit-for-tat 
discussion. Indeed, the speed with which the replies are sent with these 
Socratic questions indicates to me a lack of consideration of the issues 
and a lack of well-reasoned response. I would ask that it please stop.

Second, I believe it is likely the case that the concerns that John and 
Bill have expressed have been discussed in the WG and answered. I am 
endeavoring to collect together those answers to see if they do show 
that John and Bill are "in the rough. *If* John and Bill (or others) 
have concerns that were *not* answered in those discussions, which they 
will be able to determine by my laying out what I think are the answers 
from the WG, they can highlight the appropriate distinctions in their 
arguments so that I can figure out if they have new issues that the WG 
needs to address in the document. But until that time, I find continued 
interrogation and answers on these topics non-useful.

Whether you agree or disagree with John and Bill on this particular 
topic, please hold your comments in abeyance unless you think you are 
able to consisely explain to John or Bill why their concerns are 
unfounded or already answered. Otherwise, please allow me (or Alexey as 
chair/shepherd) to collect together what the WG has said previously on 
this topic and see if that answers John and Bill (and perhaps simply 
needs some additional text in the document), or whether they actually 
have a new issue that needs to be addressed.

pr

---

From: Bill McQuillan <[email-masked]>
Date: Sun, 11 Mar 2012 13:11:13 -0700

> successful and needed an explicit, standards-level convention (like X-)?

Her are the X- Header Fields from your message to this list and 
then to me:

------------------------------------------------------------------
X-CT-Class: Clean
X-CT-Score: 0.00
X-CT-RefID: str=0001.0A020203.4F5D0046.0065:SCFSTAT16494284,ss=1,re=-4.000,fgs=0
X-CT-Spam: 0
X-Authority-Analysis: v=1.1 cv=/ZwqEBlPVGrPjyTYV1SQchNqYCp4wKr9chc4/hMuKn4=
 c=1 sm=1 a=311X-zf45VgA:10 a=njq9vhlBZ1cA:10 a=eOGH69Cg1f0A:10
 a=6fD_dijBfH4A:10 a=wPDyFdB5xvgA:10 a=kj9zAlcOel0A:10
 a=GU4rwa5YvsQnE15YQEkOQw==:17 a=k7Ga1wGzAAAA:8 a=48vgC7mUAAAA:8
 a=xT979wAqctAob7kwSJkA:9 a=CjuIK1q_8ugA:10 a=x3I_HB9Tk8MA:10
 a=ClmATp4dOM8A:10 a=lZB815dzVvQA:10 a=fsYzn3yOqi5YVgO2YBcNBQ==:117
X-CM-Score: 0.00

X-Pobox-Orig-Sender: <[email-masked]>
X-Pobox-Delivery-ID: 68B0C71E-6BB2-11E1-B45E-81693F681118-07228702!sienna.pobox.com
X-Original-To: [email-masked]
x-pobox-client-address: 12.22.58.30
x-pobox-client-name: mail.ietf.org

X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 11 Mar 2012 12:42:27 -0700 (PDT)

X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.12
------------------------------------------------------------------

I see no problems with them and believe that they are all for 
"private use" and I would not like to see them forbidden.

I especially like the "X-BeenThere: [email-masked]" field
since I would guess that it is for anti-looping purposes, but
perhaps it is for debugging or even vanity, but it doesn't matter
because it clearly only has any meaning to [email-masked].

Now perhaps these could have been registered names, but I don't 
see the advantage in these cases.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 11 Mar 2012 13:43:29 -0700

> "private use" and I would not like to see them forbidden.

Bill,

You think the new draft prohibits people from having private conventions?

It doesn't.

d/
-- 

   Dave Crocker

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Mar 2012 09:32:41 -0600

> useful for true private use.

This document does not recommend against the practice of private, local,
preliminary, experimental, or implementation-specific parameters, only
against the use of "X-" and similar constructs in the names of such
parameters. I haven't seen anyone argue for deprecating the former
practice, only the latter convention. (I've provisionally added the
first sentence of this paragraph to the introduction in our working copy
of the document, because I think it answers what could be a common
misunderstanding.)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Mar 2012 11:24:24 -0600

> "yes", then the application is almost certainly private use.

John, your description helps to clarify the notion of private use, which
this I-D currently uses but does not define (perhaps assuming that
people know it when they see it).

To apply that notion to the subject matter of this I-D, do you think
that the "X-" prefix or a similar construct is needed to mark off
private-use parameters? Or would you find it acceptable for folks
needing private-use parameters to follow the guidelines mentioned in
Appendix B? (The following text is copied from our working version,
which might be slightly different from what's in -03.)

###

   In some situations, segregating the parameter name space used in a
   given application protocol can be justified:

   1.  When it is extremely unlikely that some parameters will ever be
       standardized.  In this case implementation-specific and private-
       use parameters could at least incorporate the organization's name
       (e.g., "ExampleInc-foo" or, consistent with [RFC4288],
       "VND.ExampleInc.foo") or primary domain name (e.g.,
       "com.example.foo" or a Uniform Resource Identifier [RFC3986] such
       as "http://example.com/foo").  In rare cases, truly experimental
       parameters could be given meaningless names such as nonsense
       words, the output of a hash function, or UUIDs [RFC4122].

###

> practical recommendation about how to avoid conflicts.

I think the text quoted above does provide several practical
recommendations about how to avoid conflicts: incorporate the name or
domain name of the organization that has minted the private-use
parameter, or in rare cases even create a nonsense string, use the
output of a hash function, or generate a UUID.

> don't have a practical alternative that preserves that

I think we do.

[philosophical topic elided]

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: John C Klensin <[email-masked]>
Date: Mon, 12 Mar 2012 14:23:57 -0400

--On Monday, March 12, 2012 11:24 -0600 Peter Saint-Andre
<[email-masked]> wrote:

>...
>> If the answer to the first two questions is not "yes", then
>> the application is probably not "private use".  The third
>> question further qualifies the situation; if the answer to
>> all three is "yes", then the application is almost certainly
>> private use.

> John, your description helps to clarify the notion of private
> use, which this I-D currently uses but does not define
> (perhaps assuming that people know it when they see it).

I had assumed the latter too, but some of the earlier
correspondence led me to the conclusion that maybe I was wrong
and that people could not, in practice, distinguish private use
from the other cases.

> To apply that notion to the subject matter of this I-D, do you
> think that the "X-" prefix or a similar construct is needed to
> mark off private-use parameters? Or would you find it
> acceptable for folks needing private-use parameters to follow
> the guidelines mentioned in Appendix B? (The following text is
> copied from our working version, which might be slightly
> different from what's in -03.)
> 
>### 
> 
>    In some situations, segregating the parameter name space
> used in a    given application protocol can be justified:
> 
>    1.  When it is extremely unlikely that some parameters will
> ever be        standardized.  In this case
> implementation-specific and private-        use parameters
> could at least incorporate the organization's name
> "com.example.foo" or a Uniform Resource Identifier [RFC3986]
> such        as "http://example.com/foo").  In rare cases,
> truly experimental        parameters could be given
> meaningless names such as nonsense        words, the output of
> a hash function, or UUIDs [RFC4122].
> 
>### 

At the risk of being facetious, the answers to both "is the
construct needed" and to "are the Appendix B guidelines
sufficient" is "yes".

To answer Pete's question, I don't think the tradeoffs in this
have been adequately examined in the WG and earlier discussions.
I think it is more important that examination occur, and
preferably be described in the document, than that there be any
particular answer. I am, to some extent, trying to play devil's
advocate for a position I think is relevant but that has not,
IMO, been sufficiently discussed in the rush to get rid of "X-"
entirely.

To be specific about the range of ways in which the document
could satisfy my concerns (without necessarily making me
completely happy), I believe Appendix B would be a lot stronger
if its introduction said something equivalent to "as long as
what you are doing is really and exclusively private use, there
is nothing to prevent you from using the 'X-' convention or
anything else.  Nonetheless, we believe you would be better off
using one of the conventions outlined in this section to further
reduce the odds of ambiguity".   

That goes a bit further than "segregating the name space", which
may not mean the same thing to everyone.  Indeed, the
private-use folks may not see "X-" as a segregation of the name
space as much as a "hands off unless you are part of a prior
agreement" warning. Note that "ExampleInc-foo",
"com.example.foo", and so on do not provide that warning because
ExampleInc could easily and sensibly have 

	  ExampleInc-foo (private use)
	  ExampleInc-bar (public use, described in ExampleInc's
	     documentation, but not registered with IANA)
	  ExampleInc-baz (registered with IANA)

I believe that trying to distinguish between the latter two --by
syntax or otherwise-- is hopeless and counterproductive.  But
the first one does seem really different to me, different enough
to justify X-foo or X-ExampleInc-foo.

>> possible conflicting use, of commands, parameters or fields
>> that are clearly private and that will not be registered
>> and/or publicly explained no matter how much we change the
>> registration rules. 

See above for a bit more about the "warning" distinction which,
unless we can successfully require registration of all
non-private uses, would seem to me to benefit from some specific
syntax.  Again, I don't see the absence of such syntax as a
showstopper, largely because the private use folks will do
whatever they want to do.  At the same time, I believe making a
prohibition that will be ignored is not in the IETF's collective
best interest.

What is and is not reasonable for private use (and ultimately
whether Appendix B is realistic) involves a problem I don't
think we know how to talk about.  I think it would be easy to
get very broad consensus agreement in the IETF for statements
like "security by obscurity is bad" or "security by obscurity
doesn't provide much protection".  On the other hand, the number
of people who could honestly say that they had never relied on
obscurity as part of a security strategy, or incorporated some
obscure characteristics into a protocol in the hope of
strengthening or improving its performance it slightly, would
be, I think _much_ smaller.  Whether or not the Appendix B
suggestions are likely to be followed probably depends a great
deal on whether an implementer believes that disclosure of the
company name increases the risk, even slightly. 

Of course, creating a hash or partially-nonsense string would
eliminate that problem.  But, in practice, if someone sees the
string as truly private use, I just don't see that happening.
Ever.

> recommendations about how to avoid conflicts: incorporate the
> name or domain name of the organization that has minted the
> private-use parameter, or in rare cases even create a nonsense
> string, use the output of a hash function, or generate a UUID.

See above.

best,
    john

---

From: Ned Freed <[email-masked]>
Date: Mon, 12 Mar 2012 11:35:47 -0700 (PDT)

> and that people could not, in practice, distinguish private use

I don't think the problem has much to do with people's ability to discern the
difference. I think they're well aware of that, but either:

(1) They think their application meets the private use criteria, and it may
    even meet them at the time the choice is made, but later events
    conspire to falsify that conclusion,

(2) They want to develop something in private and if successful transition
    to public identifiers, but seriously underestimate the difficulty of
    making that transition,

(3) They would like to do the right thing, but percieve, rightly or wrongly,
    that the barriers to entry are too high, or

(3) They're the sort who take the path of least immediate resistance,
    long term consequences be damned.

And finally, there's the more general case of someone who is completely unaware
of any of the rules and simply apes what they see someone else doing. This is
actually quite different from being aware of the rules but not understanding
them. We may be able to address the lack of understanding, but it's hard to get
the horse to drink our koolaide when it doesn't know that the pitcher exists.
(How's that for a mixed metaphor?)

I think if you analyze the various subcases of spaces where we've seen flagrant
abuse of x- names, including but not limited to media types and email headers,
you'll find it isn't any one thing, but a combination of factors, probably
including some I haven't thought to list here.

And no, this doesn't answer the question of what do to to clean up existing
messes. But it does suggest that in cases where names are plentiful defining a
private use space naming convention may be a bad idea for reasons we have no
control over.

				Ned

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Mar 2012 13:01:57 -0600

> (How's that for a mixed metaphor?)

I think your more general case is the most common. Someone creates a
parameter and unthinkingly slaps an "X-" on the front because that's
what everyone else has done, or because they don't want to be seen as
presumptuous about the status of their little extension (which often
enough becomes a big extension).

> messes. 

This I-D decidedly does not attempt to clean out that Augean stable.

> But it does suggest that in cases where names are plentiful defining a

Agreed.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Dave Crocker <[email-masked]>
Date: Mon, 12 Mar 2012 12:07:24 -0700 (PDT)

Ned's note is a nice survey of 'reasons'.

/d

--

Dave Crocker
bbiw.net

-----Original Message-----
From: Peter Saint-Andre <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: John C Klensin <[email-masked]>, [email-masked], [email-masked], The IESG <[email-masked]>
Sent: Mon, 12 Mar 2012 12:01 PM
Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03

Agreed.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Mar 2012 13:15:03 -0600

> to justify X-foo or X-ExampleInc-foo.

Interesting. I had not seen it that way, so thank you for the new
perspective. I now need to think about it a bit more. My first reaction
is that I think few people perceive "X-" as a hands-off warning (it's
much more cryptic than those silly email footers about the message being
intended only for the addressee), but I suppose that such a notion might
be floating around in the heads of some people who have created such
parameters.

> be, I think _much_ smaller. 

If they're being honest, yes. :)

> Whether or not the Appendix B

Perhaps we are, indeed, merely tilting at windmills there.

Given that the I-D cutoff is less than 5 hours from now and you have
raised an issue that needs further airing, I will submit -04 today
(which addresses other issues that folks have raised) so that we have a
clear baseline, then circle back to this private use issue again in the
coming days.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: John C Klensin <[email-masked]>
Date: Mon, 12 Mar 2012 15:15:04 -0400

--On Monday, March 12, 2012 13:01 -0600 Peter Saint-Andre
<[email-masked]> wrote:

>>>> John, your description helps to clarify the notion of
>>>> private use, which this I-D currently uses but does not
>>>> define (perhaps assuming that people know it when they see
>>>> it).
>> 
>>> correspondence led me to the conclusion that maybe I was
>>> wrong and that people could not, in practice, distinguish
>>> private use from the other cases.
>> 
>> I don't think the problem has much to do with people's
>> ability to discern the difference. I think they're well aware
>> of that, but either:
>> 
>> (1) They think their application meets the private use
>> criteria, and it may even meet them at the time the choice is
>>     made, but later events conspire to falsify that
>>     conclusion,
>> 
>> (2) They want to develop something in private and if
>> successful transition to public identifiers, but seriously
>>     underestimate the difficulty of making that transition,
>> 
>> (3) They would like to do the right thing, but percieve,
>> rightly or wrongly, that the barriers to entry are too high,
>>     or
>> 
>> (3) They're the sort who take the path of least immediate
>> resistance, long term consequences be damned.
>> 
>> And finally, there's the more general case of someone who is
>> completely unaware of any of the rules and simply apes what
>> they see someone else doing. This is actually quite different
>> from being aware of the rules but not understanding them. We
>> may be able to address the lack of understanding, but it's
>> hard to get the horse to drink our koolaide when it doesn't
>> know that the pitcher exists. (How's that for a mixed
>> metaphor?)
> 
> I think your more general case is the most common. Someone
> creates a parameter and unthinkingly slaps an "X-" on the
> front because that's what everyone else has done, or because
> they don't want to be seen as presumptuous about the status of
> their little extension (which often enough becomes a big
> extension).

First of all, this is exactly the discussion I wanted to see. I
care much less about how it comes out than I do about being sure
it occurred even though I'd prefer that it be reflected in the
document.

That said, if that more general case applies, there is
absolutely no reason to expect that this specification will have
any impact whatsoever on what those people do, so neither the
text in Appendix B nor my suggested guidance about how to figure
out if something is "private use" are particularly meaningful,
rather than just provide more KoolAid for the unseen pitcher.  I
think that implies we should either do more (explain the
situation even more carefully in Appendix B or elsewhere in the
hope that, despite our experience, someone relevant will read
it) or do less (reduce Appendix B to a simple statement that,
while the document cannot apply to actual private use cases,
those cases are lots less frequent than people often believe and
that is it usually best to construct names on the assumption
(however unlikely it may appear) that they will eventually
become public enough that registration is desirable.

>> I think if you analyze the various subcases of spaces where
>> we've seen flagrant abuse of x- names, including but not
>> limited to media types and email headers, you'll find it
>> isn't any one thing, but a combination of factors, probably

While I completely agree with that, I remain concerned about the
cases that are not abuses of x- names, flagrant or otherwise.  
 
>> And no, this doesn't answer the question of what do to to
>> clean up existing messes. 
> 
>> But it does suggest that in cases where names are plentiful
>> defining a private use space naming convention may be a bad
>> idea for reasons we have no control over.
> 
> Agreed.

It also suggests that, for reasons we have no control over,
trying to prohibit that usage is pretty hopeless... at least
unless one can get the horse's nose into the pitcher well past
the nostrils.  Based on experience, if one decides to try that,
one should be very sure to not be within kicking range.

     john

---

From: John C Klensin <[email-masked]>
Date: Mon, 12 Mar 2012 15:25:43 -0400

--On Monday, March 12, 2012 13:15 -0600 Peter Saint-Andre
<[email-masked]> wrote:

> Given that the I-D cutoff is less than 5 hours from now and
> you have raised an issue that needs further airing, I will
> submit -04 today (which addresses other issues that folks have
> raised) so that we have a clear baseline, then circle back to
> this private use issue again in the coming days.

Wfm.  Thanks.
    john