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

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Oct 2010 12:23:56 -0600

I finally got around to updating this one. It's still incomplete, in the
sense that it doesn't discuss recommendations or desired changes to
behavior. However, I figured a revised I-D was in order because the
issue came up recently on the HTTPBIS list -- see thread starting here:

http://lists.w3.org/Archives/Public/ietf-http-wg/2010OctDec/0105.html

-------- Original Message --------
Subject: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt
Date: Tue, 19 Oct 2010 11:15:01 -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-01.txt
	Pages           : 6
	Date            : 2010-10-19

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 "standard" and "experimental" parameters
by prefixing experimental 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-01.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: Bill McQuillan <[email-masked]>
Date: Wed, 20 Oct 2010 00:51:27 -0700

I have a concern with the blanket deprecation of the X- convention.

The ID presumes that the only use of X- values is for experimentation and
rightly point out the problem of eventually trying to transition to a non
X- value when the experiment has succeeded. However, in at least the case
of Email header fields, there is another reason for X- names: Private Use.

Note that neither of the rules quoted in RFC822 and RFC1154 mentions the
word "experimental".

In the message I'm replying to that Peter Saint-Andre sent to this list
contains 16 X- header fields in my local store. Many of these are not
intended to be interpreted by the mail system, but by humans for diagnostic
purposes or possibly by a SIEVE script. This seems to be an indication that
many implementers are not seeing a problem with them.

I am especially fond of a header field I saw years ago, "X-NSA-Bait:" which
was followed by a bunch of words intended to waste some eavesdropper's
time.

Thus, I would modify the recommendation of the ID to specify that X- names
should not be used for global interoperability experimentation, but that
local private use is less of a problem.

As a point of reference, the following is a list of the X- header field
names in the previous message as I received it:

-- 
Bill McQuillan <[email-masked]>

---

From: SM <[email-masked]>
Date: Wed, 20 Oct 2010 02:44:35 -0700

Hi Peter,
>behavior. However, I figured a revised I-D was in order because the

I read draft-saintandre-considered-harmful.

Quoting Section 3.8.1 of RFC 2821 (3.7.1 in RFC 5321):

   "Other mail systems gatewayed to the Internet often use a subset of
    the RFC 822 header section or provide similar functionality with a
    different syntax, but some of these mail systems do not have an
    equivalent to the SMTP envelope.  Therefore, when a message leaves
    the Internet environment, it may be necessary to fold the SMTP
    envelope information into the message header section.  A possible
    solution would be to create new header fields to carry the envelope
    information (e.g., "X-SMTP-MAIL:" and "X-SMTP-RCPT:");"

That's not an issue as the Xdash is for private use.  The Xdash may 
be a problem when used over the Internet.  I suggest that the draft 
discusses that angle.

The draft mentions a rule in RFC 1154:

    "Keywords beginning with "X-" are permanently reserved to
     implementation-specific use.  No standard registered encoding
     keyword will ever begin with "X-".

The fact that no standard registration is required and because 
"everybody does so" might provide an explanation as to why Xdash is 
in common use.

Now, does Xdash stand for Experimental or Extension?  It doesn't 
really matter as there are provisional registries to cater for such 
usage.  Maybe the problem is:

  (i) people do not know about the registration procedures; or

  (ii) the registration procedures are too tedious; or

  (iii) Think local, act global.

Section 2.5 of RFC 5064 recommends that:

   "For backwards compatibility, this document also describes the
    X-Archived-At header field, a precursor of the Archived-At header
    field.  The X-Archived-At header field MAY also be parsed, but SHOULD
    not be generated."

That's one way to deal with the Xdash issue.

One of the arguments for the registration of Xdash is that the 
implementations have already been deployed and it is too costly to fix.

In Section 3, there is a typo for "parameters".

I support the recommendation against the creation of new names with 
the special "X" prefix in IETF protocols.

Regards,
-sm

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Oct 2010 07:24:32 -0700

>of Email header fields, there is another reason for X- names: Private Use.

In other WGs, we have had problems with the term "private use" and "vendor specific" and so on. A more descriptive term is "never intended for interoperable use". It's not as easy to say, but it is much more precise for what we want.

--Paul Hoffman, Director
--VPN Consortium

---

From: Dave Cridland <[email-masked]>
Date: Wed, 20 Oct 2010 15:29:38 +0100

On Wed Oct 20 15:24:32 2010, Paul Hoffman wrote:
> In other WGs, we have had problems with the term "private use" and  
> "vendor specific" and so on. A more descriptive term is "never  
> intended for interoperable use". It's not as easy to say, but it is  
> much more precise for what we want.

Vendor tokens work much better for this kind of thing.

ACAP had them, but enterprise OID arcs are an earlier example, too,  
and very successful in SNMP.

(ACAP's are getting - painfully - extracted from RFC 2244 currently,  
since they're used by IMAP ANNOTATE/ANNOTATEMORE).

The problem with X- is that they leak beyond their scope without  
indication of what their scope might be.

FWIW, ACAP had per-user tokens, too. I never found a use for them,  
but I imagine that if ACAP were more commonplace, it might have found  
some deployment for personal experiments.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Tony Hansen <[email-masked]>
Date: Wed, 20 Oct 2010 10:34:53 -0400

> much more precise for what we want.

I've long felt that a large number of header fields that seem to appear 
as X- should really be vendor specific.

I started writing an I-D once defining and registering a "Vendor 
Specific" header field prefix ala the MIME media type vendor prefix.

Is it time to resurrect that idea and actually finish writing the I-D?

     Tony

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Oct 2010 07:55:02 -0700

>Vendor tokens work much better for this kind of thing.

That has *not* been our experience in the IPsec world. We have had repeated, serious problems with this in IKEv1.

>ACAP had them, but enterprise OID arcs are an earlier example, too, and very successful in SNMP.

There are many people in the ops world who would disagree with the latter part. Having to follow a dozen vendors OIDs for a feature that eventually becomes widespread is a nightmare.

>The problem with X- is that they leak beyond their scope without indication of what their scope might be.

Yes, definitely. But that doesn't mean that having a vendor namespace helps.

--Paul Hoffman, Director
--VPN Consortium

---

From: Dave Cridland <[email-masked]>
Date: Wed, 20 Oct 2010 16:14:37 +0100

On Wed Oct 20 15:55:02 2010, Paul Hoffman wrote:
> >>In other WGs, we have had problems with the term "private use"  
> and "vendor specific" and so on. A more descriptive term is "never  
> That has *not* been our experience in the IPsec world. We have had  
> repeated, serious problems with this in IKEv1.
> 
> 
It'd be useful (to me, and I think the community) to know what those  
problems are.

> There are many people in the ops world who would disagree with the  
> latter part. Having to follow a dozen vendors OIDs for a feature  
> that eventually becomes widespread is a nightmare.
> 
> 
Yes, I can appreciate that. One always hopes that implementations  
migrate to the standards, but that's not always easy, and it  
certainly doesn't always happen. On the other hand, I suspect the  
alternative - an "X-" oid - would be significantly worse - that just  
makes my eyes water.

> Yes, definitely. But that doesn't mean that having a vendor  

They do allow for interoperability in spite of a lack of a common  
[~ly followed] standard, and prevent multiple overlapping uses of the  
same identifier.

So I'd argue that they do help, although I'm willing to admit they  
don't solve the problems entirely.

Dave.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 20 Oct 2010 10:13:44 -0500

On Wed, Oct 20, 2010 at 07:55:02AM -0700, Paul Hoffman wrote:
> latter part. Having to follow a dozen vendors OIDs for a feature that
> eventually becomes widespread is a nightmare.

Depending on the protocol, vendor extensions might be unavoidable.
Context is everything.

For example, the NFSv4 WG maintains very tight control over the
protocol, while SSHv2 allows for _some_ vendor extensions; Kerberos V5
has lots of typed holes, and KRB-WG does not maintain tight control over
their use (there is a registrar, and it isn't the IANA, but it doesn't
require protocol specifications for its assignments), ...

For e-mail we can expect vendor extensions to RFC2822 headers for the
simple reason that they abound today.  Correct MTA implementations ought
to filter out such extensions when e-mail crosses administrative domains
or gateways that don't understand the forwarding node's vendor
extensions.  Vendor extensions in delivered e-mail seem OK to me because
users can often interpret them in many cases without extra help.

> Yes, definitely. But that doesn't mean that having a vendor namespace

Indeed.  But maybe we should have a scope identifier.  Something like:

Z-<vendor>-<ext-name>[-<domain>]: <goop>
                       ^^^^^^^^
		       (this is the scope)

For example:

Z-JoeSixPackSW-spamscore-foo.example: 37

which would be stripped from e-mail being forwarded to MTAs outside
foo.example, while this:

Z-JoeSixPackSW-spamscore: 51

wouldn't be (though since one administrative domain's MTAs' spam scoring
of e-mail isn't likely to be useful to other domains, thus this
particular sort of extension header should have a scope ID).

Or maybe the scope ID should be more fine grained than just a
domainname:

Z-<vendor>-<ext-name>-<scope>[-<domain>]: <goop>

Here the scope would be something like: 'transient' (used only by MTAs,
stripped on delivery or when crossing administrative domains) and
'persistent' (persisting all the way until and including delivery).

We might also want references to vendor extension specs:

Z-<vendor>-<ext-name>-spec: <URN>

Nico
--

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 20 Oct 2010 16:49:27 -0700

Disclaimer:

      I was editor for the document that introduced it, 28 years ago, but am 
pretty sure the idea came from a participant on the mailing list that was 
discussing RFC 822 development, rather than coming from my own brain.

      In any event, during the IETF DRUMS working group, which produced RFC2822, 
I lobbied for eliminating the construct.  I think it was an excellent idea, but 
I think it's downside is far more significant than its upside.  And indeed, the 
upside has largely been eliminated.  /d

On 10/20/2010 2:44 AM, SM wrote:
> the RFC 822 header section ...  A possible
> That's not an issue as the Xdash is for private use. The Xdash may be a problem
> when used over the Internet. I suggest that the draft discusses that angle.

Hmmm.  That's a creative and even thoughtful point, but I suspect it does not 
really affect much.

Essentially, the need for some additonal header fields, for messages being 
gatewaying in from another system, is merely one more source of "private" 
content labeling.  It does not really ahve any special characteristics.

> The fact that no standard registration is required and because "everybody does
> so" might provide an explanation as to why Xdash is in common use.

There are two different issues.  One is that people like to invent header fields 
frequently and conveniently.  I'd say that's a pretty safe assessment.

The second is that they somehow "prefer" using X-, rather than inventing a name 
that does not use X-.

My anecdotal sense of things is that they actually believe they are /required/ 
to use X-, for any non-standardized header field.  Of course, this is not the 
rule, but they seem to think it is.

> Now, does Xdash stand for Experimental or Extension?

I don't remember that it had any specific meaning.

On 10/20/2010 12:51 AM, Bill McQuillan wrote:
 >     However, in at least the case

In fact, I believe that 'private use' was the original expectation.

But I don't think it matters.  What matters is that non-standardized use has a 
sneaky habit of becoming standardized use.

 > should not be used for global interoperability experimentation,

First of all, what is now private tends to later become public.  What is now 
local later becomes global.

Second, it doesn't matter.  The X- does not add or decrease the amount that the 
header field is "private" or "public" or "experimental" or "production".  It 
makes no difference to the utility of the header field... except to add to the 
burden of makiing the function of that field a standard.

> On 10/20/2010 7:34 AM, Tony Hansen wrote:
>> I've long felt that a large number of header fields that seem to appear as X-
>> should really be vendor specific.

Indeed, it is not unusual for a vendor to create "X-<vendorname>-...".  In terms 
of de facto registration, just the <vendorname> will suffice.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: John C Klensin <[email-masked]>
Date: Wed, 20 Oct 2010 21:25:28 -0400

--On Wednesday, October 20, 2010 07:24 -0700 Paul Hoffman
<[email-masked]> wrote:

>> The ID presumes that the only use of X- values is for
>> experimentation and rightly point out the problem of
>> eventually trying to transition to a non X- value when the
>> experiment has succeeded. However, in at least the case of
>> Email header fields, there is another reason for X- names:
>> Private Use.
> 
> and "vendor specific" and so on. A more descriptive term is
> "never intended for interoperable use". It's not as easy to
> say, but it is much more precise for what we want.

Yes.  And, even while understanding that things that start out
intended as private sometimes become public, I think that narrow
usage may be worth preserving... or at least that it deserves a
rather careful discussion in the I-D.

    john

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 20 Oct 2010 18:39:02 -0700

On 10/20/2010 6:25 PM, John C Klensin wrote:
>    And, even while understanding that things that start out
> usage may be worth preserving

X- does not enable, facilitate or preserve private usage.

All it does it to make moving to standardized usage (significantly) more difficult.

d/
-- 

   Dave Crocker

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 21 Oct 2010 12:47:36 +1100

On 21/10/2010, at 10:49 AM, Dave CROCKER wrote:

> The second is that they somehow "prefer" using X-, rather than inventing a name that does not use X-.
> 
> My anecdotal sense of things is that they actually believe they are /required/ to use X-, for any non-standardized header field.  Of course, this is not the rule, but they seem to think it is.

Exactly.

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

---

From: Claudio Allocchio <[email-masked]>
Date: Thu, 21 Oct 2010 08:45:23 +0200 (CEST)

On Wed, 20 Oct 2010, Dave CROCKER wrote:

>     In any event, during the IETF DRUMS working group, which produced 
> RFC2822, I lobbied for eliminating the construct.  I think it was an 
> excellent idea, but I think it's downside is far more significant than its 
> upside.  And indeed, the upside has largely been eliminated.  /d
>
>

for this one you I can blame guilty, but I share the burden with Steve 
Kille. It was a workaround to allow SMTP to be the intermediate carrier 
between 2 non-standard, or "different" standard mail systems:

  A-type-mail-system-->gw-->SMTP-->gw-->A-type-mail-system

> content labeling.  It does not really ahve any special characteristics.

true.

> There are two different issues.  One is that people like to invent header 
> fields frequently and conveniently.  I'd say that's a pretty safe assessment.
>
> My anecdotal sense of things is that they actually believe they are 
> /required/ to use X-, for any non-standardized header field.  Of course, this 
> is not the rule, but they seem to think it is.

I agree. people tend to be a bit lazy... "let's use an X-... and tere will 
be less discussion, no need to follow standards approval procedures.."

Some fields which are of general use MUST be considered for standard, thus 
"no X-"

> I don't remember that it had any specific meaning.

nor do I.

all the best!

PS: this was the X- section of Dave's message as I received from the ML:

as you can see... none of them has any gateway meaning (ok we do not use 
gateways often anymore), and most of it is for informational purpouses to 
the human recipient (... and 98% of recipents will never see them).

but... at least the "spam information" ones could have easily been 
standardised, but are we still in time now?

:-)

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

---

From: Nathaniel Borenstein <[email-masked]>
Date: Thu, 21 Oct 2010 10:23:27 +0100

Clearly this discussion is in need of a contrarian voice, so as a public service I'll provide one.  :-)

I disagree strongly with Peter's statement, in the draft, that "The practice is at best useless and at worst harmful."  I think it is both harmful and useful, and that there's a baby that shouldn't be thrown out with the bathwater.

I'm not a big fan of X-, but if we're going to discourage/deprecate/eliminate it, we should address at least two cases for which it has often been viewed as a solution.  Saying "don't use X-" won't accomplish much if we don't spell out clearly just what people *should* do in these situations, the first of which has already been discussed on this list:

1.  Vendor-specific usage.  It's true that X- wasn't intended for this, but many vendors have gravitated to it in the absence of a preferred technique.  It is not unreasonable for a vendor to want to create a header field that doesn't need to interoperate, but also doesn't conflict with other vendors' usages.  If two vendors both wanted a header field to (fancifully) document the cost of security scanning a message, for use downstream in their own systems, it's arguably fine if they use completely different syntax and semantics, but it is asking for trouble if they both call it "Security-cost."  Vendors have favored X- for this purpose simply because they know that interoperability isn't generally expected, so it seems safer.  

I'd prefer something like a "VENDOR-vendorname-fieldname" convention, such as "VENDOR-GuppyLake-SecurityCost."  We might even want to define the syntax so that it gives a clue to anyone who needs/wants to find out what it means, as in "VENDOR-emailaddress-SecurityCost" or "VENDOR-url-SecurityCost."

2.  Truly experimental usage.  It's undoubtedly less common than it once was, but sometimes a mail system implementor comes up with an idea that requires a new header field.  When you're not sure if it's really going to be useful or if you've correctly identified what needs to be in it, you want to conduct some trials, and only go to IANA or write an RFC if the results justify continued effort.  I've done this many times; being able to just define an X- header myself, without worrying about a rigorous definition or naming conflicts, facilitates experimental research.  The Internet has matured, but research still matters.

Peter correctly asserts that simpler registration rules make this less onerous, but any registration process can feel onerous for an early-stage experiment, especially for those who've never registered anything with IANA nor written an RFC.  I fear Peter's proposal would lead to a proliferation of unregistered types that do NOT start with X-, a situation worse than the present one.   Peter also describes as problematic cases where both an X- and a non-X- version of a field name persist, such as "gzip: and "x-gzip".  But the solution to this is typically one or two lines of code, which I find preferable to a proliferation of unregistered non-X- types.

Only using X- for true experiments would be fine with me, but I can also imagine deciding that it has been so corrupted that a new prefix is preferable.  I would have no problem with deprecating X- in favor of something like Vendor- and Experiment-.  But we should address the legitimate situations where registering the field name simply doesn't make sense.  Otherwise I fear Peter's draft will at worst create a proliferation of unregistered non-X- types, and at best will have as much effect as preaching abstinence to teenagers.  -- Nathaniel

On Oct 21, 2010, at 2:39 AM, Dave CROCKER wrote:

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: John C Klensin <[email-masked]>
Date: Thu, 21 Oct 2010 10:29:09 -0400

+1.  Much better described than my earlier comment.

    john

--On Thursday, October 21, 2010 10:23 +0100 Nathaniel Borenstein
<[email-masked]> wrote:

> Clearly this discussion is in need of a contrarian voice, so
> as a public service I'll provide one.  :-)
> 
> I disagree strongly with Peter's statement, in the draft, that
> "The practice is at best useless and at worst harmful."  I
> think it is both harmful and useful, and that there's a baby
> that shouldn't be thrown out with the bathwater.
> 
> I'm not a big fan of X-, but if we're going to
> discourage/deprecate/eliminate it, we should address at least
> two cases for which it has often been viewed as a solution.
> Saying "don't use X-" won't accomplish much if we don't spell
> out clearly just what people *should* do in these situations,
> the first of which has already been discussed on this list:
> 
> 1.  Vendor-specific usage.  It's true that X- wasn't intended
> for this, but many vendors have gravitated to it in the
> absence of a preferred technique.  It is not unreasonable for
> a vendor to want to create a header field that doesn't need to
> interoperate, but also doesn't conflict with other vendors'
> usages.  If two vendors both wanted a header field to
> (fancifully) document the cost of security scanning a message,
> for use downstream in their own systems, it's arguably fine if
> they use completely different syntax and semantics, but it is
> asking for trouble if they both call it "Security-cost."
> Vendors have favored X- for this purpose simply because they
> know that interoperability isn't generally expected, so it
> seems safer.  
> 
> I'd prefer something like a "VENDOR-vendorname-fieldname"
> convention, such as "VENDOR-GuppyLake-SecurityCost."  We might
> even want to define the syntax so that it gives a clue to
> anyone who needs/wants to find out what it means, as in
> "VENDOR-emailaddress-SecurityCost" or
> "VENDOR-url-SecurityCost."
> 
> 2.  Truly experimental usage.  It's undoubtedly less common
> than it once was, but sometimes a mail system implementor
> comes up with an idea that requires a new header field.  When
> you're not sure if it's really going to be useful or if you've
> correctly identified what needs to be in it, you want to
> conduct some trials, and only go to IANA or write an RFC if
> the results justify continued effort.  I've done this many
> times; being able to just define an X- header myself, without
> worrying about a rigorous definition or naming conflicts,
> facilitates experimental research.  The Internet has matured,
> but research still matters.
> 
> Peter correctly asserts that simpler registration rules make
> this less onerous, but any registration process can feel
> onerous for an early-stage experiment, especially for those
> who've never registered anything with IANA nor written an RFC.
> I fear Peter's proposal would lead to a proliferation of
> unregistered types that do NOT start with X-, a situation
> worse than the present one.   Peter also describes as
> problematic cases where both an X- and a non-X- version of a
> field name persist, such as "gzip: and "x-gzip".  But the
> solution to this is typically one or two lines of code, which
> I find preferable to a proliferation of unregistered non-X-
> types.
> 
> Only using X- for true experiments would be fine with me, but
> I can also imagine deciding that it has been so corrupted that
> a new prefix is preferable.  I would have no problem with
> deprecating X- in favor of something like Vendor- and
> Experiment-.  But we should address the legitimate situations
> where registering the field name simply doesn't make sense.
> Otherwise I fear Peter's draft will at worst create a
> proliferation of unregistered non-X- types, and at best will
> have as much effect as preaching abstinence to teenagers.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 21 Oct 2010 08:01:48 -0700

>I disagree strongly with Peter's statement, in the draft, that "The practice is at best useless and at worst harmful."  I think it is both harmful and useful, and that there's a baby that shouldn't…

Maybe "often harmful and rarely useful".

>I'm not a big fan of X-, but if we're going to discourage/deprecate/eliminate it, we should address at least two cases for which it has often been viewed as a solution.  Saying "don't use X-" won't accomplish much if we don't spell out clearly just what people *should* do in these situations,

Agree.

>I'd prefer something like a "VENDOR-vendorname-fieldname" convention, such as "VENDOR-GuppyLake-SecurityCost."  We might even want to define the syntax so that it gives a clue to anyone who needs/wa…

It still would be good to say "if you use a vendor name instead of registering a new header, it can never be standardized and will thus never be interoperable; think carefully about whether you really want that outcome".

>2.  Truly experimental usage.  It's undoubtedly less common than it once was, but sometimes a mail system implementor comes up with an idea that requires a new header field.  When you're not sure if…

We fully disagree here. It is *trivial* for an experimenter with any sense to create your own non-conflicting headers for "truly experimental usage": use a random string. md5 is your friend here. Encouraging any sort of structure over-encourages this use.

>Peter correctly asserts that simpler registration rules make this less onerous, but any registration process can feel onerous for an early-stage experiment, especially for those who've never registered anything with IANA nor written an RFC.  I fear Peter's proposal would lead to a proliferation of unregistered types that do NOT start with X-, a situation worse than the present one.

We are trying to guess what experimenters *who never read RFCs* might do, and yet none of us know them.

>   Peter also describes as problematic cases where both an X- and a non-X- version of a field name persist, such as "gzip: and "x-gzip".  But the solution to this is typically one or two lines of code, which I find preferable to a proliferation of unregistered non-X- types.

We disagree here as well. As we discovered in the IPsec world, the registered version is usually a bit different than the last experimental (or, in our case, vendor-specific) version, yet some implementers assume exactly what you did and therefore interoperability between the two goes two hell.

--Paul Hoffman, Director
--VPN Consortium

---

From: John C Klensin <[email-masked]>
Date: Thu, 21 Oct 2010 11:02:59 -0400

--On Wednesday, October 20, 2010 18:39 -0700 Dave CROCKER
<[email-masked]> wrote:

>> intended as private sometimes become public, I think that
>> narrow usage may be worth preserving
> 
> 

Dave,

To add just one thing to Nathaniel's more comprehensive and,
IMO, better, note...

Uniqueness is good and a unique binding of header name to syntax
and semantics is better.   Having two header fields in wide use
with different definitions but the same name is the biggest
impediment to standardization of all: if we want to standardize,
we may need to end up changing both of them.

If we could somehow guarantee that every header name, including
private-use, experimental (and certain to be redesigned somewhat
if it ever went public), and vendor-specific ones would be
registered --at least to stake a claim on uniqueness even if not
a precise definition-- I'd favor doing away with "X-" (or
special treatment of "X-" because I think the odds of getting
rid of it at this stage are zero).  But our track record there
is pretty bad, both for the reasons that Nathaniel identifies
and because, sooner or later, we seem to always get to the point
with IANA registries that someone feels a need to evaluate
proposed registrations for quality or desirability and to push
back on some of them as a result.

Until and unless we can solve those really fundamental problems,
it seems to me that it actually is useful to have a flag that
says "unless you have external information from other fields or
private agreements between particular senders and recipients,
you need to treat this header field as if you have no clue what
it means or how it should be interpreted".  I think it is a
problem that we have never made _that_ definition of "X-" quite
clear enough.  I think Nathaniel's proposals for more structured
private/ vendor/ experimental fields are a much better solution.
But it doesn't seem to me that "declare harmful; discard
bathwater, baby, and sink" without providing any replacement
plan for the relevant uses would be a good idea.

    john

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 21 Oct 2010 09:28:32 -0700

On 10/21/2010 2:23 AM, Nathaniel Borenstein wrote:
> 1.  Vendor-specific usage.
...
> It is not unreasonable for a vendor to want to create a header field that
> doesn't need to interoperate, but also doesn't conflict with other vendors'
> usages.

X- neither aids nor impedes this.  The way that vendors create vendor-specific 
header fields is by affixing their own clever string to the name, such as their 
company or product name.  This works equally well (or poorly) with or without 
the X-.

> I'd prefer something like a "VENDOR-vendorname-fieldname" convention, such as

What is the value add of the prefatory string?  Some other vendor can come along 
and use the same vendorname.  (Yes, really.)  They won't do this, unless the 
string is extremely generic and the later developer is extremely naive; but they 
can, absent a registry.  Given a registry, the prefatory string is still not 
needed.  The question then will be why a special registry for vendor stuff is 
needed, rather than simply having a single, uniform header-field registry, such 
as we already have.

> 2.  Truly experimental usage.
...
>  When you're not sure if it's really going to be useful or
> if you've correctly identified what needs to be in it, you want to conduct
> some trials, and only go to IANA or write an RFC if the results justify
> continued effort.

X- neither aids nor impedes this.  Anyone may already affix whatever new 
header-fields they want.  Just do it.

> Peter correctly asserts that simpler registration rules make this less
> onerous, but any registration process can feel onerous for an early-stage

And, indeed, there is already no requirement to register the field name.

>    Peter also describes as problematic cases where both an X- and
> a non-X- version of a field name persist, such as "gzip: and "x-gzip".  But
> the solution to this is typically one or two lines of code, which I find
> preferable to a proliferation of unregistered non-X- types.

That line (pun) of thinking says that combinatorial explosion isn't a problem. 
One or two lines of code here; one or two lines of code there.  Pretty soon...

The only thing that X- accomplishes is to require long-term support for a 
non-standard name and a standard name, if a feature gets sufficiently popular.

d/
-- 

   Dave Crocker

---

From: Dave Cridland <[email-masked]>
Date: Thu, 21 Oct 2010 17:55:54 +0100

On Thu Oct 21 17:28:32 2010, Dave CROCKER wrote:
> X- neither aids nor impedes this.  The way that vendors create  
> vendor-specific header fields is by affixing their own clever  
> string to the name, such as their company or product name.  This  
> works equally well (or poorly) with or without the X-.
> 
> 
No, a defined convention encourages people to follow it. By making  
X-* a free-for-all, nobody is encouraged into adding a vendor prefix  
that they weren't aware needed adding.

>> convention, such as
> What is the value add of the prefatory string?  Some other vendor  
> can come along and use the same vendorname.  (Yes, really.)  They  
> won't do this, unless the string is extremely generic and the later  
> developer is extremely naive; but they can, absent a registry.   
> Given a registry, the prefatory string is still not needed.  The  
> question then will be why a special registry for vendor stuff is  
> needed, rather than simply having a single, uniform header-field  
> registry, such as we already have.
> 
> 
You can register just the vendor token, in which case - even if not  
all vendors register themselves there - it will reduce collisions. In  
any case, fussing over whether two vendors might choose sufficiently  
generic names that their choice of vendor token my clash seems to my  
mind to be reaching - it seems apparent to me that it will be a  
considerably lesser occurence than a an X- clash, and in addition  
there is the benefit that someone desiring to find out the semantics  
of the header mgith be able to deduce a contact to ask.

> X- neither aids nor impedes this.  Anyone may already affix  
> whatever new header-fields they want.  Just do it.

But how can one be assured that their header will be treated as, and  
remain treated as, an private experiment?

> That line (pun) of thinking says that combinatorial explosion isn't  
> a problem. One or two lines of code here; one or two lines of code  
> there.  Pretty soon...

I still say that this is the lesser evil compared to a bun-fight in  
the header.

> The only thing that X- accomplishes is to require long-term support  
> for a non-standard name and a standard name, if a feature gets  
> sufficiently popular.

That's not the only thing it accomplishes at all.

X- header field names *do* have a harmful effect.

The question is whether this is outweighed by their benefits, and  
secondly whether there exists a better solution we can promote for  
those wishing to use X- fields.

Dave.

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 21 Oct 2010 10:19:33 -0700

On 10/21/2010 9:55 AM, Dave Cridland wrote:
> No, a defined convention encourages people to follow it. By making X-* a
> free-for-all, nobody is encouraged into adding a vendor prefix that they weren't
> aware needed adding.

X- has been a free-for-all for 33 years.  You aren't likely to change that.

If you want to encourage adding a vendor prefix, encourage adding a vendor 
prefix.  X- has nothing to do with this.

> You can register just the vendor token, in which case - even if not all vendors
> register themselves there - it will reduce collisions.

This sounds like a reasonable enhancement to the existing header field 
registry[1].  X- has nothing to do with this.

> But how can one be assured that their header will be treated as, and remain
> treated as, an private experiment?

Nothing can ensure that.

> I still say that this is the lesser evil compared to a bun-fight in the header.

Collisions have not been a problem for 33 years.  What now makes it a problem?

In constrast, combinatorial explosion in email implementation of variants /has/ 
been a problem.

> X- header field names *do* have a harmful effect.

Please document the harm, beyond the adoption barrier when a feature becomes a 
standard.

d/

[1] <http://www.rfc-editor.org/rfc/rfc3864.txt>
-- 

   Dave Crocker

---

From: Tony Finch <[email-masked]>
Date: Thu, 21 Oct 2010 18:28:05 +0100

On Wed, 20 Oct 2010, Nicolas Williams wrote:
>
> Correct MTA implementations ought to filter out such extensions when
> e-mail crosses administrative domains or gateways that don't understand
> the forwarding node's vendor extensions.

That kind of information loss seems like a bad idea to me. If it were
common it would have made it impossible to add features like MIME and
MDNs.

> Vendor extensions in delivered e-mail seem OK to me because

That sounds like a contradiction of the previous sentence. If they are OK
to deliver, why strip them?

> Indeed.  But maybe we should have a scope identifier. For example:
>
> foo.example

If there's a scope tag there's no need to strip since only software within
the scope will try to interpret it.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

---

From: "Al Costanzo" <[email-masked]>
Date: Thu, 21 Oct 2010 13:34:34 -0400

> What is the value add of the prefatory string?  Some other vendor can come 
> along and use the same vendorname.  (Yes, really.)  They won't do this, 
> unless the string is extremely generic and the later developer is 
> extremely naive; but they can, absent a registry.

I have had to deal with this "first hand" that a different vendor used our 
company name (Dynamic Software) We had to trademark the name to stop them.

IMHO, I if you are going to be creating an RFC the "Vendor" name needs to be 
the company name as on the Incorporation papers etc.  They just cannot pick 
the name willy nilly.

Regards,

Al Costanzo

Therefore if you are going to write an RFC
----- Original Message ----- 
From: "Dave CROCKER" <[email-masked]>
To: "Nathaniel Borenstein" <[email-masked]>
Cc: "Apps-Discusssion" <[email-masked]>; "Paul Hoffman" 
<[email-masked]>; "Bill McQuillan" <[email-masked]>
Sent: Thursday, October 21, 2010 12:28 PM
Subject: Re: [apps-discuss] Fwd:I-D 
Action:draft-saintandre-xdash-considered-harmful-01.txt

> vendor-specific header fields is by affixing their own clever string to 
> the name, such as their company or product name.  This works equally well 
> (or poorly) with or without the X-.
>
>
> What is the value add of the prefatory string?  Some other vendor can come 
> along and use the same vendorname.  (Yes, really.)  They won't do this, 
> unless the string is extremely generic and the later developer is 
> extremely naive; but they can, absent a registry.  Given a registry, the 
> prefatory string is still not needed.  The question then will be why a 
> special registry for vendor stuff is needed, rather than simply having a 
> single, uniform header-field registry, such as we already have.
>
>
> That line (pun) of thinking says that combinatorial explosion isn't a 
> problem. One or two lines of code here; one or two lines of code there. 
> Pretty soon...
>
>

---

From: Graham Klyne <[email-masked]>
Date: Thu, 21 Oct 2010 21:24:51 +0100

Hi,

Both of the situations you suggest are covered by provisional registration, per 
http://tools.ietf.org/html/rfc3864.  The bar for approval is set deliberately 
low to facilitate getting some form of public documentation.

#g
--

---

From: Julian Reschke <[email-masked]>
Date: Fri, 22 Oct 2010 12:27:19 +0200

On 21.10.2010 19:34, Al Costanzo wrote:
> ...
> IMHO, I if you are going to be creating an RFC the "Vendor" name needs
> to be the company name as on the Incorporation papers etc. They just
> cannot pick the name willy nilly.
> ...

Incorporation papers in which country?

(I note that RFC 2774 uses URIs for disambiguation, essentially copying 
the design of XML namespaces; just saying...)

Best regards, Julian