Subject: Re: [apps-discuss] "X-" revisited

From: Eric Burger <[email-masked]>
Date: Sun, 3 Jul 2011 12:15:13 -0400

On the one hand, we often DO have binary codes for protocol parameters, cf. IP as an example.

Is it easier to read ASCII text? Sure.
It is easier to understand English text, if you can read English? Sure.

It is a requirement a protocol be in ASCII and in English? Absolutely not.

That is the difference between a protocol parameter and the DNS. No one will sue you for creating an amex parameter.

On Jun 30, 2011, at 2:45 PM, Dirk Pranke wrote:

> If we wanted protocol parameters to be arbitrary strings, we'd just
> use huffman-encoded binary data or something similar. We don't, and it
> is well acknowledged that having protocols composed of human-readable
> text has a lot of advantages. In addition, since the protocol *is*
> text and not always hidden behind an API, the protocol *is* the API,
> and a well-designed API is easier to use.
> 
> -- Dirk
> 
> On Thu, Jun 30, 2011 at 4:22 AM, Eric Burger <[email-masked]> wrote:
>> The difference between protocol parameters and domain names is domain names are meant for human consumption, while protocol parameters are arbitrary strings of ASCII or UTF-8 text. A protocol might use the string "kritisch" to mean "something critical." Great -- people building user interfaces will read the RFC, know that parameter is "kritisch" and will display "critical," "crucial," "krytyczny," or whatever is appropriate for the user. For that matter, one could really use the string "foobar" to mean "something criticial" or even the number 42. The protocol will work just fine, and users (who do NOT read what is on the wire) can have a great experience.
>> 
>> The point is *this* name space is huge and fungible, whereas the DNS is large and NOT fungible.
>> 
>> On Jun 29, 2011, at 6:05 PM, Dirk Pranke wrote:
>> 
>>> Your draft has:
>>> 
>>>>  In some situations, segregating the name space of parameters used in
>>>>  a given application protocol can be justified:
>>>>  ...
>>>>  2.  When parameter names might have significant meaning.  This case
>>>>      is rare, since implementers can almost always find a synonym
>>>>      (e.g., "urgency" instead of "priority") or simply invent a new
>>>>      name.
>>> 
>>> It seems to me that a primary benefit of the "X-" convention is that
>>> it makes unprefixed parameter names less socially acceptable; i.e.,
>>> there's a pretty clear rule of thumb that if the name isn't X-
>>> prefixed, it probably has seen a pass through a committee and hence it
>>> stands at least a chance of having the same meaning in multiple
>>> implementations.
>>> 
>>> I am concerned that if you abandon the X- practice, you will lose this
>>> benefit and finding untainted, available parameter names might become
>>> harder. Sure, you can often find a synonym, but it is not usually as
>>> good as the original choice. I would hate to see things move to a
>>> namespace land-grab like we have seen in DNS.
>>> 
>>> Has this been raised as an issue before?
>>> 
>>> -- Dirk
>>> 
>>> 
>>> On Mon, Jun 27, 2011 at 11:36 AM, Peter Saint-Andre <[email-masked]> wrote:
>>>> Based on comments received to date, I've published a heavily-revised
>>>> version of the "X-" proposal:
>>>> 
>>>> http://www.ietf.org/id/draft-saintandre-xdash-00.txt
>>>> 
>>>> Further feedback is welcome!
>>>> 
>>>> Peter
>>>> 
>>>> --
>>>> Peter Saint-Andre
>>>> https://stpeter.im/
>>>> 
>>>> 
>>>> _______________________________________________
>>>> apps-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>>> 
>>> _______________________________________________
>>> apps-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>> 
>>

---

From: Dzonatas Sol <[email-masked]>
Date: Sun, 03 Jul 2011 09:34:31 -0700

> It is a requirement a protocol be in ASCII and in English? Absolutely not.

ASCII is a protocol with-in itself, so there is no question about "a 
protocol be in ascii".

>> On Thu, Jun 30, 2011 at 4:22 AM, Eric Burger<[email-masked]>  wrote:
>>      
>>>> On Mon, Jun 27, 2011 at 11:36 AM, Peter Saint-Andre<[email-masked]>  wrote:
>>>>          

-- 
--- http://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 05 Jul 2011 21:52:53 -0600

> http://www.ietf.org/id/draft-saintandre-xdash-00.txt

Based on list feedback, I've submitted a further revision (including
much more specific recommendations for spec authors and implementers):

http://www.ietf.org/id/draft-saintandre-xdash-01.txt

Keep those cards and letters coming! ;-)

Peter

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

---

From: Tim Williams <[email-masked]>
Date: Wed, 6 Jul 2011 07:02:24 -0400

> Keep those cards and letters coming! ;-)

Hi Peter,
I'm interested in the "Recommendations" section and two things appear curious:

 "4.  Implementers wishing to experiment with parameters that are
       unlikely to be standardized are encouraged to generate
       meaningless names such as UUIDs or the output of a hash function."

Why?  It's not clear to me why names with obfuscated meaning is better
or worse than an X- prefix (or any other name) - when they are clearly
not intended for standardization?  Can you share more about *why*
that's encouraged?

   5.  Implementers wishing to create parameters for use in
       implementation-specific applications or on private networks are
       encouraged to mint URIs or generate names that incorporate the
       relevant organization's name or primary domain name.

Not sure if this is atypical for a spec like this but an example or
two would help for #5.  Is the intent something like:
urn:com:example:headers:myheader
or
http://example.com/headers/myheader
or
headers:example.com/myheader

or, it just doesn't matter?

FWIW, I'd also suggest substituting "subclass" or somesuch in the
following in the place of "ghetto":

"   Therefore it appears that segregating non-standard parameters into an
   "X-" ghetto has few if any benefits, and has at least one significant
   cost in terms of interoperability."

Thanks,
--tim

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 06 Jul 2011 09:11:08 -0600

> not intended for standardization?  Can you share more about *why*

I don't know if they're obfuscated, instead I see them as truly "wild"
experiments to see if an idea is worth exploring in a more serious
manner. Someone could just as well come up with a nonsense word if they
please.

> or, it just doesn't matter?

There are examples earlier in the document. I'm happy to add examples
for each of the recommendations in that section so that people can just
read the recommendations without all the background. :)

>    cost in terms of interoperability."

Yes, that's better.

I'll push out a revised I-D before the Monday cutoff, incorporating
whatever other feedback people provide.

Thanks!

Peter

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

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 06 Jul 2011 11:02:28 -0700

>  Use of the "X-" Prefix in Application Protocols

That title is neutral, but this document is not.  I suggest the title 
communicate the goal.  Something like:

    Deprecating use of the "X-" Prefix in Application Protocols

Hmmm.  There were various messages that criticized the document for being a 
warning rather than a constructive directive.  The current draft offers some 
specific advice (which I recommend be phrase normatively.)

Perhaps this document also should cite specific changes for specific protocols 
that currently call for x-?  (Email already fixed this, going from RFC822 to 
RFC2822, though that's probably worth citing.)

Generically, it might cite the known cases of use and simply direct not using 
them, instead giving examples of what to do for each case.

The most general form of the directive would be "Make the assumption that the 
use will become popular and eventually attain standards status.  What name is 
preferred in this case?  Normally it would be the same as is chosen with the X- 
preface, but without that preface.  In some cases, a different string might be 
preferred.

> Abstract
...
>                                   although it can be
>    appropriate in certain circumstances.

although it can still be appropriate to use in certain circumstances.

> 1.  Background
...
> Although this usage is purely conventional and is not mandated by the
>    Internet Standards Process [BCP9] or IANA registration rules [BCP26],
>    some implementers, and even some RFCs, have interpreted the
>    convention in a more normative way (e.g., [RFC5451] states that
>    "result codes not beginning with 'x-' MUST be registered with the
>    Internet Assigned Numbers Authority (IANA) and published in an RFC").

The approach to this text seems odd to me.  It's also a bit misleading to say 
'purely conventional' for something that has been, in fact, formally 
standardized.  (RFC822 was a standard and specified this formally.)

So, perhaps:

      Use of this naming convention is not mandated by the Internet Standards 
Process [BCP9] or basic IANA registration rules [BCP26].  Rather it is an 
individual choice by each specification that defines it or administrative 
process that chooses to use it.  For example, [RFC5451] states that "result 
codes not beginning with 'x-' MUST be registered with the Internet Assigned 
Numbers Authority (IANA) and published in an RFC").

> Parameters prefaced with the "X-" string are currently used in
>    application protocols for two different purposes:

Given the line of concern of this document, I suggest that the emphasis be about 
intent rather than effect or "use".  So...

      Parameters prefaced with the "X-" string are currently motivated by two 
different goals:

> 2.  Analysis
...

Looking at the pattern of the numbered items, pro and con, the template is a 
very terse (partial sentence) statement of the pro, followed by some sentences 
discussing the con.  What's missing is a clear and complete explanation of the 
pro view, in each case.  As a consequence, I didn't understand the opening point 
a number of times...

>    1.  When it is extremely unlikely that some parameters will ever be
>        standardized.

The problem, here, is predicting the future.  It never works and is, in fact, 
the underlying problem with the X- construct.

Perhaps this #1 really intends to cover the case in which is considered to be 
/undesirable/ to have the parameter standardized?

> 2.  When parameter names might have significant meaning.

I don't understand what this one means.  From the rest of its text, perhaps it 
means that the x- name includes an string that is already standardized by some 
other spec?

>  3.  When parameter names need to be very short

I've no idea how this requirement can justify an x- name.  (A minor point, but 
note that x- adds two bytes to the length of the name...)

> There are two primary objections to deprecating the "X-"

Meta-issue:  Since the preceding sequence was numbered and this following 
section parallels it, it should be numbered, too.

> Implementers are easily confused.

I don't understand how using or not using x- creates or alleviates confusion in 
implementers.

> Collisions are undesirable.

I think that the premise to this statement is that dropping x- will increase the 
likelihood of collisions.  That should be stated explicitly.  It was, after all, 
the motivating concern for justifying the x- convention.  I think the question 
is how realistic the concern really is, especially given the ability to make 
registration much easier than it used to be.

>  Furthermore, the existence of [BCP82]

In formatting terms, I think this should be another item in the list of 
objections (#3).

> 3.  Recommendations
...
>  1.  Authors of application protocol specifications are discouraged
>        from imputing special meaning to parameters with the "X-" prefix.

The goal is to change normative behavior, so let's use normative language (and I 
suggest changes to the ordering):

    1.  Implementers wishing to experiment with parameters that have any
        potential to be standardized SHOULD generate names without the
        "X-" prefix.

    2.  Authors of application protocol specifications SHOULD NOT
        mandate that all parameters without the "X-" prefix need
        to be registered with the IANA.

(#2 seems odd.  I don't really understand why it is needed or what it does 
that's significant, given the recommendation of not using x- parameters ever. 
Is there a way of stating what is desired affirmatively?)

    3.  Authors of application protocol specifications are discouraged
        from imputing special meaning to parameters with the "X-" prefix.

    4.  Implementers wishing to experiment with parameters that are
        intended not to be standardized SHOULD generate meaningless
        names such as UUIDs or the output of a hash function.

    5.  Implementers wishing to create parameters for use in
        implementation-specific applications or on private networks SHOULD
        mint URIs or generate names that incorporate the relevant
        organization's name or primary domain name.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: SM <[email-masked]>
Date: Wed, 06 Jul 2011 12:49:27 -0700

Hi Dave,
At 11:02 06-07-2011, Dave CROCKER wrote:
>The goal is to change normative behavior, so let's use normative 
>language (and I suggest changes to the ordering):
>
>(#2 seems odd.  I don't really understand why it is needed or what 
>it does that's significant, given the recommendation of not using x- 
>parameters ever. Is there a way of stating what is desired affirmatively?)

This is more of an open question; is it about standardizing the 
parameter or using the parameter over the Internet?  If an 
implementer wishes to use a parameter over the Internet, generate an 
I-D and ask for a provisional registration.  The problem with (2) is 
that it takes us back to the X- debate where "X-" was a way to have a 
parameter without IANA registration.

If the goal is to explain that X- has more cost than benefits, I am 
fine with what the document says.  For anything else, RFC 4122 
derived parameters or one derived from the domain name might do.  The 
issue with the latter can be addressed by getting a IANA registration.

Regards,
-sm

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 06 Jul 2011 14:05:16 -0600

>    Deprecating use of the "X-" Prefix in Application Protocols

Done in my working copy.

> Hmmm.  There were various messages that criticized the document for
> being a warning rather than a constructive directive.  The current draft
> offers some specific advice (which I recommend be phrase normatively.)
> 
> Perhaps this document also should cite specific changes for specific
> protocols that currently call for x-?  (Email already fixed this, going
> from RFC822 to RFC2822, though that's probably worth citing.)

Done.

> Generically, it might cite the known cases of use and simply direct not
> using them, instead giving examples of what to do for each case.

People like examples. :)

> The most general form of the directive would be "Make the assumption
> that the use will become popular and eventually attain standards
> status.  What name is preferred in this case?  Normally it would be the
> same as is chosen with the X- preface, but without that preface.  In
> some cases, a different string might be preferred.

Seems right.

> The approach to this text seems odd to me.  It's also a bit misleading
> to say 'purely conventional' for something that has been, in fact,
> formally standardized.  (RFC822 was a standard and specified this
> formally.)
> 
> So, perhaps:
> 
>      Use of this naming convention is not mandated by the Internet
> Standards Process [BCP9] or basic IANA registration rules [BCP26]. 
> Rather it is an individual choice by each specification that defines it
> or administrative process that chooses to use it.  For example,
> [RFC5451] states that "result codes not beginning with 'x-' MUST be
> registered with the Internet Assigned Numbers Authority (IANA) and
> published in an RFC").

Better. I think we can just reference RFC 822 and RFC 5451 here, without
going into specifics.

> Given the line of concern of this document, I suggest that the emphasis
> be about intent rather than effect or "use".  So...
> 
>      Parameters prefaced with the "X-" string are currently motivated by
> two different goals:

I've incorporated something along those lines, thanks.

>> 2.  Analysis
> ...
> 
> Looking at the pattern of the numbered items, pro and con, the template
> is a very terse (partial sentence) statement of the pro, followed by
> some sentences discussing the con.  What's missing is a clear and
> complete explanation of the pro view, in each case.  As a consequence, I
> didn't understand the opening point a number of times...

Yes, a more complete description would be helpful.

> The problem, here, is predicting the future.  It never works and is, in
> fact, the underlying problem with the X- construct.
> 
> Perhaps this #1 really intends to cover the case in which is considered
> to be /undesirable/ to have the parameter standardized?
> 
> 
> I don't understand what this one means. 

I don't fully understand it either. :) I pulled it from previous list
discussion but didn't ask the person who posted it for clarification.

> From the rest of its text,
> perhaps it means that the x- name includes an string that is already
> standardized by some other spec?

That's my sense.

> I've no idea how this requirement can justify an x- name.  (A minor
> point, but note that x- adds two bytes to the length of the name...)

Well, "x-foo" is shorter than "VND.BrandenburgInternetWorking.foo".

> Meta-issue:  Since the preceding sequence was numbered and this
> following section parallels it, it should be numbered, too.

Done.

> I don't understand how using or not using x- creates or alleviates
> confusion in implementers.

I don't either, but that was one of the objections.

> I think that the premise to this statement is that dropping x- will
> increase the likelihood of collisions.  That should be stated
> explicitly.  It was, after all, the motivating concern for justifying
> the x- convention.  I think the question is how realistic the concern
> really is, especially given the ability to make registration much easier
> than it used to be.
> 
> 

Done.

> language 

WFM.

> (and I suggest changes to the ordering):
> 
> (#2 seems odd.  I don't really understand why it is needed or what it
> does that's significant, given the recommendation of not using x-

The point is directed at the kind of thing we find in RFC 5451, which
says that x- params MUST NOT be registered and non-x- params MUST be
registered. That seems wrongheaded to me.

>        organization's name or primary domain name.

Yep, and I have some more changes and examples in the recommendations
section now, too.

Dave, I'll push out a new version with you and Mark Nottingham as
co-authors and we can fight over who presents on the topic in Quebec City.

Peter

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

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 06 Jul 2011 13:53:56 -0700

> Well, "x-foo" is shorter than "VND.BrandenburgInternetWorking.foo".

Mumble.  This issue seems like one that is going to take vastly more effort than 
it ought, but that's probably true for the entire topic.  (Entire topic:  X- was 
a good idea to avoid collisions with standards, but turns out to be a much worse 
idea for uses that become standards.  So, don't use X-".)

Anyhow...

"X-foo" is longer than "foo".

And I believe the real comparision to VND should be 
"X-BrandenburgInternetWorking.foo"...

> I don't either, but that was one of the objections.

OK, but whoever was/is objecting needs to explain their concerns, of course.

> registered. That seems wrongheaded to me.

OK.  I think this reduces to a new phrasing along the lines of:

   Authors of application protocol specifications SHOULD provide extensible 
registries for all parameters and SHOULD mandate use of the registries, for all 
values of the parameters, independent of the form of the parameter names.

(The absence of any reference to X- is intentional.)

d/
-- 

   Dave Crocker

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 06 Jul 2011 15:01:54 -0600

On 7/6/11 2:53 PM, Dave CROCKER wrote:
> Mumble.  This issue seems like one that is going to take vastly more
> effort than it ought, but that's probably true for the entire topic. 
> (Entire topic:  X- was a good idea to avoid collisions with standards,
> but turns out to be a much worse idea for uses that become standards. 
> So, don't use X-".)
> 
> Anyhow...
> 
>   Authors of application protocol specifications SHOULD provide
> extensible registries for all parameters and SHOULD mandate use of the
> registries, for all values of the parameters, independent of the form of
> the parameter names.

The second SHOULD strikes me as somewhat controversial. :)

The first SHOULD is fine by me, although I'm not sure what an extensible
registry is -- did you mean "both permanent and provisional registries"?

Peter

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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 6 Jul 2011 14:25:41 -0700

> The second SHOULD strikes me as somewhat controversial. :)

Not much more controversial than the whole topic. I can quickly name many protocols for which "some values are reserved for experimental use" have had horrible problems in practice, either where an experimental value ended up being baked into shipping products or two vendors used the same experimental use value for different things.

Maybe the Apps Area is not as familiar with "values 250 through 255 are reserved for experimental use" than the rest of the IETF, but the topic is quite germane to this draft. Dave's proposed wording is hard to swallow, but probably best for the real-world long-lived Internet.

> registry is -- did you mean "both permanent and provisional registries"?

And extensible registry is one where there is a registration procedure so that today's registry might be larger tomorrow.

--Paul Hoffman

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 06 Jul 2011 14:50:24 -0700

> The second SHOULD strikes me as somewhat controversial. :)

Yup.  But I figured, in for a penny...

> registry is -- did you mean "both permanent and provisional registries"?

That was a tad cryptic, wasn't it.

To be extensible, I meant that it needs to be listed with IANA, with procedures 
for making additions.

d/

-- 

   Dave Crocker

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 06 Jul 2011 19:43:47 -0600

On 7/6/11 3:50 PM, Dave CROCKER wrote:
> To be extensible, I meant that it needs to be listed with IANA, with
> procedures for making additions.

Got it. Tweaked in my working copy to:

   2.  Specification authors SHOULD provide unlimited registries with
       well-defined registration procedures and SHOULD mandate
       registration of all parameters, independent of the form of the
       parameter names.

Peter

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

---

From: Dave Crocker <[email-masked]>
Date: Wed, 06 Jul 2011 18:45:58 -0700

Peter Saint-Andre <[email-masked]> wrote:

>On 7/6/11 3:50 PM, Dave CROCKER wro
>       parameter 

wfm.

d/
--
Dave Crocker
bbiw.net

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 06 Jul 2011 20:24:50 -0600

On 6/29/11 4:05 PM, Dirk Pranke wrote:
> it makes unprefixed parameter names less socially acceptable; 

That's tautological -- the "X-" convention attempts to segregate the
parameter space by dividing it into the standard area (a good, clean,
safe, respectable place to be) and the non-standard area (a bad, dirty,
unsafe, slightly scandalous place to be). Naturally it's less socially
acceptable to be in the non-standard part of town.

> i.e.,

The fact of leakage from the non-standard area into the standard area
shows that it's quite possible for one of those raffish parameters
starting with "X-" to have the same meaning in multiple implementations.

And I'll not that passing through a committee does not necessarily
guarantee that a parameter will have the same meaning in multiple
implementations, or be a better parameter for the experience.

Is your argument that we want to encourage folks to cross the tracks
into the more respectable part of the parameter space by publishing
Internet-Drafts and gaining consensus on their proposals? That seems to
be a good thing no matter what the form of the parameter name. Shedding
the mark of the "X-" strikes me as a rather insignificant benefit of
standardization.

> namespace land-grab like we have seen in DNS.

As Eric Burger noted, there's not much danger of a land grab here.
Although it's nice for protocol parameter names to be readable to
developers (for debugging and the like), they're not intended to be
shown to end users, so there's not much need or incentive to reserve the
cool names before some parameter shark gets to them.

Is there some kind of attack lurking here that we're not aware of?
Parameter phishing or somesuch?

Peter

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

---

From: Dirk Pranke <[email-masked]>
Date: Wed, 6 Jul 2011 20:30:57 -0700

> Parameter phishing or somesuch?

No, that was not my concern. I am mostly trying to map your arguments
onto the way we're currently evolving the HTML APIs, which follow a
similar convention to X- (the vendor prefixes).

-- Dirk

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 06 Jul 2011 21:54:38 -0600

> similar convention to X- (the vendor prefixes).

Can you provide a pointer for this work?

Peter

---

From: Dirk Pranke <[email-masked]>
Date: Thu, 7 Jul 2011 14:12:06 -0700

> Can you provide a pointer for this work?

Here are a few links culled from few minutes of searching my email and
the internet. I wouldn't claim that they are the best sources,
necessarily ...

http://wiki.csswg.org/spec/vendor-prefixes - conventions for prefixing
new features in CSS. This probably has the most real-world experience.
The convention that the major browsers seem to be adopting is that
proposed features are prefixed by a vendor-specific token until a
specification reaches the stage of Candidate Recommendation (i.e.,
pretty frozen and the semantics should be pretty well agreed).

http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#extensibility
- similar, but less battle-tested examples for HTML attributes and DOM
interfaces

http://lists.w3.org/Archives/Public/www-style/2011Apr/0794.html - one
particular mail thread in the CSS working group on this topic; there
are many others

http://blogs.msdn.com/b/ie/archive/2010/11/15/ie9-vendor-prefixes-and-developers.aspx
- a statement from Microsoft on their attitude towards vendor
prefixes; you can probably find similar statements from most of the
other vendors.

http://www.alistapart.com/articles/prefix-or-posthack/ - an
independent article and discussion from Eric Meyer, a well-known name
in the CSS and HTML community describing the virtues of this approach.

I will note that the vendor prefix convention certainly has its
detractors as well, but they don't seem to be winning at the moment. I
am also well aware that the constraints on web pages are not directly
comparable to the constraints on newtork-level protocols, so these
arguments don't carry over 100%.

-- Dirk

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 08 Jul 2011 02:13:03 +0200

>http://www.ietf.org/id/draft-saintandre-xdash-01.txt

The mechanism here allows to encumber public infrastructure that's been
developed with attention to consensus and decent documentation with uni-
lateral and usually poorly documented extensions. If the mechanism sur-
faces too often, everybody should feel annoyed and desire changes so it
stays in its confined place. You writing this draft tells me that it is
actually working good. Overdoses are supposed to cause problems.

With extension schemes there are things we want to have, things we want
to avoid, there are social and other dynamics, and they vary among pro-
tocols. I would expect an argument against `X-` to establish a context
in this sense, and then show how `X-` is unfit, possibly by showing how
some other mechanism is proved to be better. Your document does not do
that, so I find it rather unconvincing.

I would more generally think extensibility is hard and there is no one
approach suitable for all situations. You recommend for instance that
implementation-specific feature names should include reference to the
implementation. This is done with Cascading Style Sheets, after vendors
have been bitten sufficiently many times that not doing that would have
social repercussions in addition to the technical ones.

That leads to a situation where authors complain they have to specify
`-opera-feature`, `-mozilla-feature`, and so on in order to use certain
features, as the feature in principle is not implementation-specific,
but experimental implementations of it are. That's largely a social de-
fect of course, vendors put more effort into their implementations than
they do with respect to the standardization process; with the argument
above, the complaints are a good thing. But that's rather contentious,
and people regularily ask for a "-wd-" or "-w3c-" or "-x-" prefix. For
them, `-X-` would actually be an improvement (until their stuff breaks).

There is a migration point where implementers move from these prefixes
to the standard name. We largely call that making progress in standar-
dization of the feature, I find it a bit odd that you cite this as the
primary problem with the mechanism here. You actually argue both that
changing the name is a problem, and that the standard name may imply a
different behavior, which is also a problem. I would think the opposite,
standardization allows for corrective actions, so the standardization
is a good thing (you don't say it's bad, but you get close).

With people adding to public infrastructure, I care about avoiding the
issues that very typically arise when documentation is poor or absent
and when those making the additions do not consult with interested but
otherwise independent parties. Whether "X-" is good or bad does not play
a large role in that; I do think a document detailing what we want to
have with extensibility mechanisms, what we want to avoid, what problems
individual approaches have, would be valuable; a document arguing contra
"X-" without the larger discussion, not so much.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: John C Klensin <[email-masked]>
Date: Sat, 09 Jul 2011 10:11:53 -0400

--On Tuesday, July 05, 2011 21:52 -0600 Peter Saint-Andre
<[email-masked]> wrote:

> Based on list feedback, I've submitted a further revision
> (including much more specific recommendations for spec authors
> and implementers):
> 

Peter,

With the disclaimer that I'm still a fan of "x-" under very
limited circumstances, a few observations that I think are
complementary to some of those already made in this thread.

First, while you can reasonably argue that most applications for
"X-" that are either "experimental" or even "extension" are
bogus and can be handled in other ways, there are private-use
cases that, IMO, remain legitimate.  Those private-use cases
are, IMO, legitimate.  They are very similar to RFC 1918
addresses: if something reaches you that contains an X-
parameter, and the sender and receiver don't have a clear
private agreement about what it means, then the correct action
is to discard it or treat it is gibberish.  Those private
agreements may require some degree of authentication, but that
is a separate issue.  Note that "private use" really does imply
"private": suggesting or requiring an IANA registration, no
matter how lightweight, is out of line if only because it
identifies the registrant.  

Your document implicitly assumes that the world consists of
public stuff that is intended to be standardized, public stuff
that is experimental and not likely to be standardized, and
things for which embedding organization names in the parameter
(see below) are satisfactory.  I don't believe it.

Second, remember that the motivation that took us down this path
(see Dave's notes), and a motivation for IANA registration on
parameters and the IANA itself, was to prevent two parties from
accidentally using the same parameter value for different
purposes and thereby causing serious interoperability problems.
As Dave indirectly points out, we could have mandated
arrangements like "X-BrandenburgInternetWorking.foo" or, more
likely, "X-BrandenburgInternetWorking--foo".  But we didn't and,
unless the DNS is used (which has its own set of problems,
especially in the world ICANN is creating) it would just require
the creation of another registry that would have to be managed
and that might be controversial among intellectual property
folks ("X-BrandenburgInternetWorking.foo" and "X-Klensin.foo"
are probably fine, but "X-JoesPizza.foo" is the introduction to
a nightmare).

To discourage a mandate for parameters to be registered with
IANA is to encourage those interoperability problems.    At a
minimum, if you are going to make that recommendation, its
implications need to be explicitly discussed in Security
Considerations.  I think it is a bad recommendation, even if
some people will certainly ignore it.   Making it a useful
recommendation, however, requires that the IETF get completely
over its self-proclaimed role as an arbiter of taste in
identifier names and descriptions.

Similarly, if "you better know who sent this to you and what
they think it means" is a "special meaning to parameters with
the 'X-' prefix", then I think you are looking for other
problems.   FWIW, "X-JoesPizza.foo" (or just "JoesPizza.foo")
involves the imputation of a special meaning by parsing the
parameter string and isolating the "relevant organization's name
or primary domain name".  Interestingly, from the way you write
that recommendation, "foo.JoesPizza" is equally legitimate,
after which it becomes really easy to fall back into the trap of
conflicting names and interoperability problems.

Recommendation: There is too much history and you can't get this
right without causing even more interoperability issues than we
have today.  Private-use cases are legitimate and it is
appropriate to provide some syntax that will identify them and
shift the burden of figuring out what they mean to private
agreements (and authentication of the parties to those
agreements that is appropriate to the protocol in question).  

Encouraging more protocols to organize their parameters as
trees, allow for vendor and personal trees, and define
sufficient syntax and registries to actually make those trees
work is actually a fine idea, but it may still not eliminate the
need for private-use parameters.

Finally, two asides/nits:

(1) If you want to talk about "X-", your reference should be to
RFC 5322 and its predecessors, not 5321, or you need more text.
RFC 5321 (and its predecessors) use "X" (no hyphen") for
private-use commands (and calls them that, not extensions or
experiments, see Section 4.1.5).  "X-" is used only in passing
and in an example discussing gateways in Section 3.7.1.  FWIW,
my guess is that the leading "X" idea started with FTP and
migrated, in "X-" form, to 822, but I don't remember (if I ever
knew), so it is really just a guess.

(2) While provisional URI schemes keep coming up as examples of
how one might do these special extensions instead (as in your
Section 2), I think a careful understanding of the history of
"X-" to which people most object (and that RFC 1123 discusses in
the context of experimental FTP commands, providing an example
in its Section 4.1.3.1 that may be better than the two you cite
and that is certainly earlier) suggests that the only thing
"provisional" about a provisional registration is tolerance for
rotten or missing documentation.  Just like a command or
parameter starting in "X-" or "X", once the name associated with
a provisional registration is used and incorporated into
protocols, it is "used up": if the definition is changed, or
even clarified in a way that eliminates some interpretations, it
is usually better to select a new parameter string than to
pretend that the new definition applies retroactively to the old
parameter name.  Even if you disagree with that, I think it
deserves some discussion in the document if you are going to
recommend provisional registrations as an option.

best,
   john

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 11 Jul 2011 11:18:28 +1000

> similar convention to X- (the vendor prefixes).

I think the difference there is that the number of implementations is relatively small.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 11 Jul 2011 11:18:48 +1000

On 07/07/2011, at 6:53 AM, Dave CROCKER wrote:

> (Entire topic:  X- was a good idea to avoid collisions with standards, but turns out to be a much worse idea for uses that become standards.  So, don't use X-".)

Can we get this into the abstract... or make it the abstract?

Cheers,

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 11 Jul 2011 08:00:33 -0600

> Can we get this into the abstract... or make it the abstract?

Wordsmithed in my working copy to:

   Many application protocols use named parameters to identify data
   (media types, header fields in Internet mail messages and HTTP
   requests, etc.).  Historically, protocol designers and implementers
   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".  Although in theory the "X-"
   convention was a good way to avoid collisions between standard
   parameters and non-standard parameters, in practice the costs
   associated with leakage of non-standard parameters into the standards
   space outweigh the benefits.  Therefore this document deprecates the
   "X-" convention for most application protocols.

I'll push out a revised I-D today, then we can discuss it further on the
list and in Quebec City.

/psa

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 11 Jul 2011 08:35:14 -0600

> identifies the registrant.  

I agree that mandating registration of private parameters or extensions
is wrong.

> Your document implicitly assumes 

I think it would be helpful to make the assumptions explicit.

> that the world consists of

You don't think those buckets exist, or you think that there are
additional buckets? The document does mention private stuff, and I agree
that private stuff needs to be handled differently.

> identifier names and descriptions.

I'm comfortable with saying that all parameters should be registered,
with a carve-out for truly private parameters. As you say, it appears
that many implementers will simply ignore the mandate.

> problems.  

By "special meaning" I was trying to capture only the assumption that
any parameter with the "X-" prefix is non-standard (and that any
parameter without the "X-" prefix is standard). Given the fact of
leakage from the non-standard space into the standard space, such an
assumption is unwarranted. I'll make this clearer in -02.

> FWIW, "X-JoesPizza.foo" (or just "JoesPizza.foo")

You're right that humans tend to impute other meaning to strings by
parsing them into patterns that make sense. I see no solution to that
problem.

> need for private-use parameters.

What prevents an implementer with a truly private-use parameter from
assigning a UUID, a hash, or some other unmeaningful string of characters?

> RFC 5322 and its predecessors, not 5321, 

Yes, I'd already caught that bug in -01, it's fixed in -02.

> or you need more text.

Interesting. I just found the following in RFC 691:

   Thus, FTP servers which care about the distinction between Telnet
   print and non-print could implement SRVR N and SRVR T.  Ideally
   the SRVR parameters should be registered with Jon Postel to avoid
   conflicts, although it is not a disaster if two sites use the
   same parameter for different things.  I suggest that parameters
   be allowed to be more than one letter, and that an initial letter
   X be used for really local idiosyncracies.

This convention appears to have been used in some early FTP RFCs, such
as 737, 743, and 775 (mentioned in RFC 1123, as you point out).

> parameter name. 

Yes.

> Even if you disagree with that, I think it

Agreed.

I'm not sure I'll have time to work these matters into -02 of the
document given time constraints today, but if not we'll do so in -03.

Peter

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

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 11 Jul 2011 07:41:29 -0700

>     "X-" convention for most application protocols.

I like the paragraph.

The specific re-casting of my terse "entire topic" statement is in the sentence:

>      Although in theory the "X-"
>>     space outweigh the benefits.

That looks fine, except that and I'd suggest saying evolution or movement, 
rather than leakage.

Whether the standardization is intentional or not, it's viewed as a Good Thing, 
whereas "leakage" is typically taken as a negative.

d/
-- 

   Dave Crocker

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 11 Jul 2011 09:50:36 -0600

On 7/11/11 8:41 AM, Dave CROCKER wrote:
>>>> (Entire topic:  X- was a good idea to avoid collisions with
>>>> standards, but turns out to be a much worse idea for uses that
>>>> become standards.  So, don't use X-".)
>>>
> That looks fine, except that and I'd suggest saying evolution or
> movement, rather than leakage.
> 
> Whether the standardization is intentional or not, it's viewed as a Good
> Thing, whereas "leakage" is typically taken as a negative.

True. I've changed all instances of "leak[age]" to "advance[ment]". I
think of the "X-" area as the wrong side of the tracks, and advancement
into the non-"X-" area as moving up in the world. :)

I'll submit -02 shortly and look forward to making -03 after IETF 81.

Peter

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

---

From: Dirk Pranke <[email-masked]>
Date: Mon, 11 Jul 2011 11:37:35 -0700

> I think the difference there is that the number of implementations is relatively small.

Hmm. I agree that the number of browser implementations with
significant market share is fairly small, but I don't know that this
is unusual. I'd be hard pressed to think of a significant application
or transport-layer protocol that has had more than a half dozen major
(read: others have to adopt their extensions) implementations either.

-- Dirk

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 12 Jul 2011 10:17:14 +1000

> (read: others have to adopt their extensions) implementations either.

Right, but think of HTTP headers; any random person can (and does) add them, all of the time, and then they're in use. 

This is where "implementation" breaks down, because it's the "server" + frameworks + site-specific code. While there are a few handful* of HTTP server implementations, there are hundreds of frameworks, and millions of sites with their own code. Then there are conventions that people layer over top, for interop between sites / frameworks (e.g., Atompub).

Cheers,

* From what I can see, the number of HTTP server implementations is exploding as well, over the last few years.

---

From: Larry Masinter <[email-masked]>
Date: Mon, 11 Jul 2011 18:26:09 -0700

Don't the considerations around "x-" also apply to "vnd." in media types?

vendor-specific media types become standards. standard media types get vendor-specific extensions.

The additional "information" that we imagine is associated with "x-" or "vnd." is 
* not testable
* can evolve over time with no transition method, plan, policy in place
* has no cost associated with mis-use  (calling something x- or vnd. when it isn't, or not using x- or vnd. when proscribed).

In the general area of registry values, any lexical convention for registry values must have some actual implementation consequences for most of the community to take the restrictions seriously. 

Larry
--
http://larry.masinter.net

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 13 Jul 2011 09:53:48 +1000

> vendor-specific media types become standards. standard media types get vendor-specific extensions.

It's a somewhat different path, I think. A vendor who uses a vnd and then later standardises the format has demonstrated a willingness to do the right thing, and the incremental effort for them is small.

Contrast that with the common case for X-; IME it's usually started by someone who has an incomplete understanding of the standards process, and doesn't want to put much effort in. X- has become a sort of cargo cult whereby it's OK to do anything if you just put X- in front of it, so that's what people do -- even for things that end up getting widely used. 

We basically need a leaflet that we can drop on that island of cargo culters, to gently clue them in. Except that the island is really the rest of the world. But you get the idea.

Cheers,

P.S. A vnd that later gets standardised is likely to have differences between the versions, so a different identifier is necessary anyway.

---

From: Dirk Pranke <[email-masked]>
Date: Tue, 12 Jul 2011 18:14:41 -0700

> This is where "implementation" breaks down, because it's the "server" + frameworks + site-specific code. While there are a few handful* of HTTP server implementations, there are hundreds of framewo…

I think I did not make myself clear. Just because some implementation
uses a header named 'X' does not mean that everyone else cares. We
ignore headers we don't recognize. We usually only care about header X
when a significant percentage of our traffic starts using it.

On the other hand, your point about there being a lot of frameworks is
valid, and I agree that there's a lot more than six of them :) Then
again, frameworks rarely create new headers in my (admittedly limited)
experience.

-- Dirk