Subject: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-00.txt

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 02 Jul 2010 15:32:56 -0600

FYI. Feedback is welcome.

-------- Original Message --------
Subject: I-D Action:draft-saintandre-xdash-considered-harmful-00.txt
Date: Fri,  2 Jul 2010 14:15:05 -0700 (PDT)
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : "X-" Considered Harmful
	Author(s)       : P. Saint-Andre
	Filename        : draft-saintandre-xdash-considered-harmful-00.txt
	Pages           : 5
	Date            : 2010-07-02

Many application protocols use named parameters to represent data
(for example, header fields in Internet mail messages and HTTP
requests).  Historically, protocol designers and implementers have
often differentiated between "official" and "unofficial" parameters
by prefixing unofficial parameters with the string "X-".  This
document argues that on balance the "X-" convention has more costs
than benefits.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-saintandre-xdash-considered-harmful-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 2 Jul 2010 16:00:29 -0700

It feels like you undershot on this one. X- is probably "harmful", except in two case:

- Where the namespace size is limited
- Where the names have semantic value

The first is why we have "RFC required" or "IETF approval" or "expert review" or whatever. I think it is non-controversial.

The second is much more challenging. Would you automatically take a registration for a mail header called "Cisco-compatibility-mode" from a known troll? What about "High-priority" if there is already a registered header called "Priority"?

This topic was beaten to death well over a decade ago, but the arguments are no different now.

--Paul Hoffman, Director
--VPN Consortium

---

From: John C Klensin <[email-masked]>
Date: Fri, 02 Jul 2010 19:27:30 -0400

+1

--On Friday, July 02, 2010 16:00 -0700 Paul Hoffman
<[email-masked]> wrote:

> The first is why we have "RFC required" or "IETF approval" or
> "expert review" or whatever. I think it is non-controversial.
> 
> The second is much more challenging. Would you automatically
> take a registration for a mail header called
> "Cisco-compatibility-mode" from a known troll? What about
> "High-priority" if there is already a registered header called
> "Priority"?
>

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 02 Jul 2010 17:07:49 -0700

Peter,

We created the X- convention in 1977, for RFC 733, the predecessor to RFC 822. 
It became popular and entrenched, very quickly.

It's premise was to permit private conventions that would not be stepped on by 
later standards efforts.  By 'private', I mean ad hoc and unregistered. Even the 
lowest-overhead registration process is still significant overhead. So the goal 
was zero overhead avoidance of private and public name usage.  (It did nothing 
about private vs. private name collision, of course.)

It was an entirely reasonable idea, but I've long felt it suffers a fundamental 
flaw:  Private conventions become publicly successful and they cannot then be 
standardized.  The name is fixed on this 'private' string.

So I think the problem is a bit different from the one you cite, but related. 
Both of us are expressing a concern about a cross-over between private and 
standardized.

As for concerns about namespace limitation, X- is used for variable length text 
names.  Namespace limitations aren't an issue.

As for a name having 'semantic' value, essentially any string used in this realm 
has semantic value.  I don't see how that's relevant here, either.

As you note, names are cheap.  Collisions aren't impossible -- there is a human 
tendency that tends to restrict choices to relatively more common strings that 
have some semantic appeal.

At this point, it's pretty easy to argue that an automated name registry should 
instead be used.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 2 Jul 2010 17:56:26 -0700

Hi -

> From: "Peter Saint-Andre" <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, July 02, 2010 2:32 PM
> Subject: [apps-discuss] Fwd: I-DAction:draft-saintandre-xdash-considered-harmful-00.txt
>

> FYI. Feedback is welcome.

Was this intended to apply to the BCP 47 mechanism of using
x- to introduce private-use subtags?

FWIW, RFC 5646 says about private use subtags:

   ... Private use subtags have
   no meaning outside the private agreement between the parties that
   intend to use or exchange language tags that employ them.  The same
   subtags MAY be used with a different meaning under a separate private
   agreement.  They SHOULD NOT be used where alternatives exist and
   SHOULD NOT be used in content or protocols intended for general use.

   Private use subtags are simply useless for information exchange
   without prior arrangement.  The value and semantic meaning of private
   use tags and of the subtags used within such a language tag are not
   defined by this document.

(Historical note: the ltru WG seriously considered changing the "SHOULD NOT"
into "MUST NOT".)

Randy

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 03 Jul 2010 06:40:40 -0700

> It became popular and entrenched, very quickly.

One of the problems with having a bad memory is that I forget I have a bad 
memory and should check things.

X- was introduced in RFC 822, not RFC 733.  So, 1982, not 1977.

d/

-- 

   Dave Crocker

---

From: Adam Barth <[email-masked]>
Date: Sat, 3 Jul 2010 16:21:39 -0700

I'm not sure how much you all follow the goings on higher up in the
stack, but vendor prefixes for CSS (cascading style sheets) has been
very successful.  For example, -webkit-border-radius is the
vendor-specific CSS attribute that generates rounded corners.  Vendor
prefixes let folks experiment in a "private" namespace, and a number
of these extensions have gone on to be part of the core CSS language
without their vendor prefix.

Of course, the situation with CSS is quite different than with HTTP.
For example, there are only a handful of vendors innovating in CSS and
the vendor prefixes are quite "well-known" in some unofficial sense.

Adam

On Sat, Jul 3, 2010 at 6:40 AM, Dave CROCKER <[email-masked]> wrote:
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 03 Jul 2010 17:11:30 -0700

On 7/3/2010 4:21 PM, Adam Barth wrote:
>       Vendor

My point was not that it is bad to have privately-initiated names, but that it 
is problematic to have a separate name space for them.  The private names 
develop an installed base and it is a hassle to force that base to migrate over 
to using new names.

It would therefore be better to have names remain stable.  This requires 
assigning private names and public (ie, standards-based) names out of the same pool.

And I think this is the premise of Peter's draft, too.

d/

-- 

   Dave Crocker

-- 

   Dave Crocker

---

From: Adam Barth <[email-masked]>
Date: Sat, 3 Jul 2010 20:55:21 -0700

On Sat, Jul 3, 2010 at 5:11 PM, Dave CROCKER <[email-masked]> wrote:
> My point was not that it is bad to have privately-initiated names, but that
> it is problematic to have a separate name space for them.  The private names
> develop an installed base and it is a hassle to force that base to migrate
> over to using new names.
>

Oh, I understand your point.  I was just mentioning a situation where
the opposite has worked out quite well for folks.  There's lots
different between the two situations (HTTP headers and CSS
attributes).  It might be worth thinking about those difference to
develop a more nuanced understanding of when using separate namespaces
works out well and when it works out less well.

Adam

---

From: Graham Klyne <[email-masked]>
Date: Mon, 05 Jul 2010 10:12:45 +0100

> This topic was beaten to death well over a decade ago, but the arguments are no different now.

Well, in the case of message header fields, this is exactly the problem that RFC 
3846 (http://tools.ietf.org/html/bcp90) was designed to address.  The registry 
has been quietly ticking over for some time now.

So I think things have moved on a little.

#g
--

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 05 Jul 2010 20:09:12 +0900

Hello Adam, others,

> the vendor prefixes are quite "well-known" in some unofficial sense.

Yes, and the vendors watch each other closely. Also, an important 
difference might be that in the end, the CSS properties have to end up 
in the standard, not just in some registry. Mail headers can just be 
registered, which at first sight should make it easier to get rid of 
prefixes, but apparently also makes it easier to ignore (why register if 
X- already works).

Another important difference seems to be that a vendor prefix in the 
browser world isn't something some other vendor will copy (e.g. it would 
be strange for Microsoft to implement -webkit-border-radius; if they 
implement it, they call it -ms-border-radius). With X-, it's much easier 
for a competitor to just also implement the X-, which means there is 
less pressure to get rid of the X-.

Yet another difference in my view is that the CSS user space (i.e. 
designers and others using CSS) may be less fragmented than the mail 
header user space. As an example, if some browser implements rounded 
corners, many designers, and therefore all browsers, want rounded 
corners. On the other hand (to take an example in which I was personally 
involved but which may not necessarily be very representative), if some 
people come up with the idea for mailing list archives to add an 
(X-)Archived-At header (http://tools.ietf.org/html/rfc5064) to mails, 
there are some people who like that a lot and use it a lot, and others 
who couldn't care less, or even claim that it's impossible to be of any use.

Also, related to the above, CSS properties are to the most part used in 
a single group of applications. Mail headers, on the other hand, may be 
very specific to one or two pieces of a very diversified toolchain. To 
again use Archived-At as an example, it's added by mailing list 
expanders in connection with mailing list archives, and it should just 
be shown by MUAs and is used directly by users. MUAs don't have to do 
any processing on it, and mail servers of various kinds just have to 
forward it, which they do anyway.

The above example (Archived-At) is actually very unrepresentative 
because I put in the effort to get it to an RFC, and the deployments in 
the X- stage were concentrated in two places (W3C and 
http://gmane.org/), so it was easy to remove the X-es.

Regards,    Martin.

P.S.: I wish the IETF mailing list archives would also provide 
Archived-At headers. They are invaluable to quickly point others to past 
discussions on a mailing list, or to summarize such a discussion as a 
chair, or to provide links to mails from other places such as issue 
trackers and the like.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: Barry Leiba <[email-masked]>
Date: Tue, 6 Jul 2010 22:53:27 -0400

On Mon, Jul 5, 2010 at 5:12 AM, Graham Klyne <[email-masked]> wrote:
> Well, in the case of message header fields, this is exactly the problem that
> RFC 3846 (http://tools.ietf.org/html/bcp90) was designed to address.

That'd be "3864", in case anyone else tried to look it up by RFC number.

Barry