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

[Dave CROCKER <[e-mail]>]

On 7/5/2011 8:52 PM, Peter Saint-Andre wrote:
> On 6/27/11 12:36 PM, Peter Saint-Andre 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
>
> 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
>

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


> In some situations, segregating the name space of parameters used in
>    a given application protocol can be justified:
>
>    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