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

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 27 Jun 2011 12:36:59 -0600

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/

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 27 Jun 2011 22:21:45 +0100

Peter,

> Further feedback is welcome!

One question. The draft concludes that:

   The foregoing considerations lead to the conclusion 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.
   Therefore, this document recommends against the creation of new names
   with the special "X-" prefix in application protocols produced within
   the IETF.

Is the guidance aimed only at documents produced within the IETF or is the intention that it is more general guidance. For example is it saying that someone defining a private extension that they do not intend to (at least initially) to bring to the IETF should still avoid use of "X-" because forseeing the future is hard and although at definition time they do not intend to standardise it, at some future point that might happen and it could cause the interoperability problems outlined in the draft?

Thanks
Ben

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 27 Jun 2011 14:29:07 -0700

> Is the guidance aimed only at documents produced within the IETF or is the intention that it is more general guidance. For example is it saying that someone defining a private extension that they d…

It can't be only for documents within the IETF.

The entire purpose of the X- construct, when we first introduced it in RFC822, 
was to support /private/ activities.

It defined a safe haven for that private work, within a naming structure defined 
by the equivalent of the IETF.  But 'private' means outside the IETF.

What motivates the current document is that 'safe haven' turns out not to be 
nearly as important as making it easier to take the private efforts that have 
become popular and make then standardized, with the minimum transition pain.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 27 Jun 2011 23:16:23 -0000

>become popular and make then standardized, with the minimum transition pain.

Perhaps some advice beyond not using X- would be helpful.

Something like use a descriptive name, and longer (within reason) is
better than shorter to avoid collisions.

R's,
John

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 28 Jun 2011 14:34:18 +1000

On 28/06/2011, at 7:29 AM, Dave CROCKER wrote:

> The entire purpose of the X- construct, when we first introduced it in RFC822, was to support /private/ activities.
> 
> It defined a safe haven for that private work, within a naming structure defined by the equivalent of the IETF.  But 'private' means outside the IETF.
> 
> What motivates the current document is that 'safe haven' turns out not to be nearly as important as making it easier to take the private efforts that have become popular and make then standardized, with the minimum transition pain.

I don't think that it goes far enough, as written. What's needed here is something we can point people at when they ask why they shouldn't use X-. As it is, it says:

> Therefore, this document recommends against the creation of new names with the special "X-" prefix in IETF protocols.

We understand what that means, but to the outside world -- i.e., someone who's NOT an "IETF insider" -- that statement isn't nearly clear enough.

I'd like to see the document rewritten with that target audience in mind -- i.e, instead of talking about applications protocols passively, speak actively about why using X- is a bad design choice for *your* protocol extension. 

Peter, I'll offer to help again, if you're amenable.

Cheers,

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

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 28 Jun 2011 18:14:50 +0100

Dave,

> What motivates the current document is that 'safe haven' turns out not to be nearly as important as making it easier to take the private efforts that have become popular and make then standardized,…

That's what I thought based on the initial sections of the document but the wording of the final guidance is such that it wasn't clear what was actually being recommended. I'd suggest changing the language to make it clear to non-IETF regulars that the guidance is wider than just documents produced by the IETF.

It was the use of "produced within the IETF" that got me confused, so maybe drop it and just have "Therefore, this document recommends against the creation of new names with the special "X-" prefix in application protocols"?

Ben

---

From: "Al Costanzo" <[email-masked]>
Date: Tue, 28 Jun 2011 13:27:52 -0400

Originally, if I remember, this "X-" was used by vendors, for specific 
headers that they needed and wanted to be "ignored or not used by other 
until possibly they were done with the design and implementation.

Was it not?

Al Costanzo
----- Original Message ----- 
From: "Ben Niven-Jenkins" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, June 28, 2011 1:14 PM
Subject: Re: [apps-discuss] "X-" revisited

>>> Is the guidance aimed only at documents produced within the IETF or is 
>>> the intention that it is more general guidance. For example is it saying 
>>> that someone defining a private extension that they do not intend to (at 
>>> least initially) to bring to the IETF should still avoid use of "X-" 
>>> because forseeing the future is hard and although at definition time 
>>> they do not intend to standardise it, at some future point that might 
>>> happen and it could cause the interoperability problems outlined in the 
>>> draft?
>>
>>
>> The entire purpose of the X- construct, when we first introduced it in 
>> RFC822, was to support /private/ activities.
>>
>> It defined a safe haven for that private work, within a naming structure 
>> defined by the equivalent of the IETF.  But 'private' means outside the 
>> IETF.
>>
>> What motivates the current document is that 'safe haven' turns out not to 
>> be nearly as important as making it easier to take the private efforts 
>> that have become popular and make then standardized, with the minimum 
>> transition pain.
>
> That's what I thought based on the initial sections of the document but 
> the wording of the final guidance is such that it wasn't clear what was 
> actually being recommended. I'd suggest changing the language to make it 
> clear to non-IETF regulars that the guidance is wider than just documents 
> produced by the IETF.
>
> It was the use of "produced within the IETF" that got me confused, so 
> maybe drop it and just have "Therefore, this document recommends against 
> the creation of new names with the special "X-" prefix in application 
> protocols"?
>
> Ben
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 28 Jun 2011 11:56:19 -0700

On 6/28/2011 10:27 AM, Al Costanzo wrote:
> Originally, if I remember, this "X-" was used by vendors, for specific headers
> that they needed and wanted to be "ignored or not used by other until possibly
> they were done with the design and implementation.
>
> Was it not?

When I was doing RFC822, there was an associated discussion list.  RFC822 was 
really only a refinement of RFC733.  There was an additional 5 years of email 
experience and a better understanding of some issues, and the task was merely 
tweaking the spec.  The list was informal and collaborative.  There was no IETF 
and no formal standardization in those days, but absent formal processes, it was 
like a working group.(*)

I do not remember who posted the idea of X-, except that it wasn't me, but as I 
recall it got immediate support.  I, for one, thought it a very cool idea.

However, this was long before "vendors" were much of an issue, by nearly 10 
years.  I don't recall any sense, in those days, of "vendor" as a distinct class 
within our work.

However various folk did private stuff.  Lots of experimentation in those days. 
  So the concern was that somebody's private stuff, which invented its own 
header field, would get stepped on by a later group/standards process that chose 
the same header field name.  This was merely to protect against that happening.

Alas, we gave no thought to /wanting/ the private effort to become 'standardized'.

d/

(*)  In 1977, RFC733 was the first RFC to declare itself a standard.  However 
there was no reall standards process.  We got permission from ARPA to use the 
word in the title in order to flag to the community some strong pressure to move 
from whatever ad hoc formats were being used to this one.  In spite of the ARPA 
approval, there was a firestorm of indignation that we would be so presumptious 
as to /demand/ that folks adopt the spec.  That just wasn't they way things were 
adopted in those days...

-- 

   Dave Crocker

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 28 Jun 2011 12:22:12 -0700

The only reason I have seen the use "X-" other than experimental were 
for non-standard distributions (past transition from USENET), except for 
no-delay or non-blocking I/O (i.e. "X-Non-Blocking:..." which helps 
denote not-critical).

Some servers may want to avoid botnets and catch headers like 
"X-Trends:" or other cookie monsters. On that note, maybe the "X-" 
headers are less harmful if some rules like the use of atomic names if 
they are used at all, like "X-Oxygen:".

The atomic names are well-known (universal, translatable), so servers 
then know what "X-" headers to prune, especially as an optimization 
techniques.

On 06/28/2011 10:27 AM, Al Costanzo wrote:
> headers that they needed and wanted to be "ignored or not used by 
> other until possibly they were done with the design and implementation.
>
> Was it not?
>
> Al Costanzo
> ----- Original Message ----- From: "Ben Niven-Jenkins" 
> <[email-masked]>
> To: <[email-masked]>
>>>> Is the guidance aimed only at documents produced within the IETF or 
>>>> is the intention that it is more general guidance. For example is 
>>>> it saying that someone defining a private extension that they do 
>>>> not intend to (at least initially) to bring to the IETF should 
>>>> still avoid use of "X-" because forseeing the future is hard and 
>>>> although at definition time they do not intend to standardise it, 
>>>> at some future point that might happen and it could cause the 
>>>> interoperability problems outlined in the draft?
>>>
>>>
>>> The entire purpose of the X- construct, when we first introduced it 
>>> in RFC822, was to support /private/ activities.
>>>
>>> It defined a safe haven for that private work, within a naming 
>>> structure defined by the equivalent of the IETF.  But 'private' 
>>> means outside the IETF.
>>>
>>> What motivates the current document is that 'safe haven' turns out 
>>> not to be nearly as important as making it easier to take the 
>>> private efforts that have become popular and make then standardized, 
>>> with the minimum transition pain.
>>
>> That's what I thought based on the initial sections of the document 
>> but the wording of the final guidance is such that it wasn't clear 
>> what was actually being recommended. I'd suggest changing the 
>> language to make it clear to non-IETF regulars that the guidance is 
>> wider than just documents produced by the IETF.
>>
>> maybe drop it and just have "Therefore, this document recommends 
>> against the creation of new names with the special "X-" prefix in 
>> application protocols"?
>>
>> Ben
>>

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

---

From: Tony Hansen <[email-masked]>
Date: Tue, 28 Jun 2011 22:32:32 -0400

I think it's worth mentioning the use of the VND.domain.name, PRS and 
reversed.domain.name namespace prefixes as alternative mechanisms that 
*have* worked well in other protocols.

This way the reader isn't left wondering "okay, I've been told what 
*not* to do and *why* I shouldn't do it, but what *should* I do instead?"

     Tony Hansen
     [email-masked]

On 6/27/2011 2:36 PM, Peter Saint-Andre wrote:
> Further feedback is welcome

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 29 Jun 2011 16:27:39 +0900

Hello Peter,

I see:

    To preserve interoperability, newer implementations simply support
    the "X-" name forever, which means that the non-standard name becomes
    a de facto standard (thus obviating the need for segregation of the
    name spaces in the first place).  As one example, we can see this
    phenomenon at work in [RFC2068] (similar examples can be found in
    [RFC5064]):

I would want to propose a tiny change to the last phrase:

"similar examples" -> "a similar example"

(because it's only about one header, and there are no actual examples of 
the X- header in usage).

I'd also want to point out that I consider the
     X-Archived-At -> Archived-At
transition in many ways the 'ideal' success story for a X- prefix. But 
the success was due to some very special circumstances:

- When Archived-At was standardized, it was used only at two (very big)
   places, and these were willing and able to switch over extremely
   quickly.
- Usage is mainly by individuals, with "software update" possible by
   settings in MUAs and the like, which made the transition easy on
   the receiving side.
- There was somebody (me) who was willing to go through all the red
   tape, deal with people who claimed that it was totally useless, and
   so on.

Regards,   Martin.

---

From: Dirk Pranke <[email-masked]>
Date: Wed, 29 Jun 2011 15:05:22 -0700

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

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 30 Jun 2011 09:19:21 +0200

On 27 June 2011 20:36, Peter Saint-Andre wrote:

> I've published a heavily-revised version of the "X-" proposal

Thanks.  The worst case I'm aware of is image/x-icon vs. MIME type
image/vnd.microsoft.icon - add this if you need more bad examples.

Maybe pick some well-known RFCs and honour them with an "updates",
obsoleting their x-foo conventions.

IIRC the NetNews RFC also inherited this x-cruft.  As Dave wrote,
I also considered "x-foo" as cool idea, but it turned out to work
like "bar", and we need no "x-" to arrive at "foobar".

Wrt RFC 5064, as long as the relevant message format / mail /
netnews / MIME / http / etc. RFCs are not updated a BCP calling
for updates doesn't help, and developers will continue to invent
new x-cruft, because it's their only "officially allowed" option.

It could be also tricky to fix x-issues in the future message
format and mail STDs, because STDs are not supposed to be very
different from the DS.  A newer BCP overruling the older DS with
an "updates" could justify to adopt the new state of the art in
the STD.  Or maybe I'm just a bit paranoid... ;-)

-Frank

---

From: Eric Burger <[email-masked]>
Date: Thu, 30 Jun 2011 07:22:56 -0400

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.

---

From: Dirk Pranke <[email-masked]>
Date: Thu, 30 Jun 2011 11:45:40 -0700

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

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 30 Jun 2011 20:13:40 -0700

Eric,

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

You have the theory down exactly correctly, IMO.  The practice however matches 
the theory only partially.  Were all fieldnames fully registered, it would 
probably match completely, but they aren't.

In point of fact, most header fields are meant for human consumption and that 
includes their fieldnames, which frequently are entirely ad hoc and can't be 
predictably translated.

> The point is *this* name space is huge and fungible, whereas the DNS is large and NOT fungible.

I guess I'm missing what the import is, for the distinction(s) you are making.

d/
-- 

   Dave Crocker