Deprecating Use of the "X-" Prefix in Application Protocols (IETF Draft) -- https://news.ycombinator.com/item?id=3539663

(edit, from W3 discussion:) "dbaron: Email headers with X-. Supposed to be experimental. But the world still works."

Not only is the X- prefix draft topical on Hacker News (as it was less than a week ago that it first got posted here, despite having been published in 2011), but it is from another standards body that is addressing the same underlying issue as this link to the W3.

As an example of how the content has severe overlap:

IETF: "Creators of new parameters to be used in the context of application protocols: 1. SHOULD assume that all parameters they create might become standardized, public, commonly deployed, or used across multiple implementations."

W3: "Steve: Suggest that group establish a goal that members who introduce experimental properties submit a description to the WG"

IETF: "Although in theory the "X-" convention was a good way to avoid collisions (and attendant interoperability problems) between standard parameters and non-standard parameters, in practice the benefits have been outweighed by the costs associated with the leakage of non-standard parameters into the standards space."

W3: "tantek: Once it's on the open Web, it's not proprietary...it can be considered experimental, but claiming it is proprietary-only is inaccurate ... plinss: Thing we need to spend some energy minimizing the escape of prefixes into the wild"

IETF: "The primary problem with the "X-" convention is that non-standard parameters have a tendency to leak into the protected space of standard parameters (whether de jure or de facto), thus introducing the need for migration from the "X-" name to the standard name."

W3: "tantek: One possible proposal is to only parse other vendors' prefixes in conjunction with parsing unprefixed. e.g. with -webkit-transform. We wouldn't parse that until we also parse transform. Thereby giving authors option to just use unprefixed, hopefully biasing new authors to using that instead."

IETF: "Furthermore, often standardization of a non-standard parameter or protocol element leads to subtly different behavior (e.g., the standard version might have different security properties as a result of security review provided during the standardization process). If implementers treat the old, non-standard parameter and the new, standard parameter as equivalent, interoperability and security problems can ensue."

W3: "macpherson: If we change the spec after implementation, you'll need to return the value in the old form as a prefix. ... szilles: What do you do if the values changed between property versions? alexmog: We'll adjust the output to match the syntax of the given version. Rossen: I don't think that's right. Today we only have aliases."

IETF: "We have already seen this phenomenon at work with regard to FTP in the quote from [RFC1123] in the previous section. The HTTP community had the same experience with the "x-gzip" and "x-compressed" media types, as noted in [RFC2068]:"

W3: "glazou: [clarifies his understanding, and asks about prefixed values as well] ... florian: Now, for prefixed values. I say just return the one you got. plinss: Agreed. TabAtkins: Agreed."

  <br type=lunch>

tantek: I think if you're working on open standards, you should propose your features before you implement them and discuss that here.

smfr: We can't do that.

sylvaing: We can't do that either.

tantek: We're going to push you to do that sooner and sooner.

jdaggett: If you're proposing something that's going to be put on a Web page, how is that proprietary?

I'm with tantek & jdaggett. Why can't browser vendors propose a standard before implementing it?

Because W3 takes forever to discuss, let alone approve it. HTML5 isn't going to be ratified until 2014, for example.

I think the idea is to start the process, so that you don't just show up at the door with a fully working implementation leaving others to play catch-up.

   plinss: You said this is a short-terms solution. Quirks mode was supposed to be a short-term solution.
   tantek: No it wasn't.
   plinss: Yes it was.
   plinss: I implemented it before you did.

I dont think -draft1-border-radius is the same problem as -webkit-border-radius, I am pretty sure its how I would like these things to be developed, it allows the vendors to work together on the same specification, with opportunity for others to diverge, but web developers only need to know the particular draft, not each various browsers implementation.

I also think that by the time vendors are implementing other vendors prefixes, they should just be pushing to drop the prefix, that is the point

I think tantek advocates this approach, but in a different order. First make sure you can support the feature without a prefix, and then support both.

   tantek: One possible proposal is to only parse other vendors' prefixes in
           conjunction with parsing unprefixed.
   tantek: e.g. with -webkit-transform. We wouldn't parse that until we also
           parse transform

What else?