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

[Peter Saint-Andre <[e-mail]>]

On 7/6/11 12:02 PM, Dave CROCKER wrote:
> 
> 
> 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

Done in my working copy.

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

Done.

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

People like examples. :)

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

Seems right.

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

Better. I think we can just reference RFC 822 and RFC 5451 here, without
going into specifics.

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

I've incorporated something along those lines, thanks.

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

Yes, a more complete description would be helpful.

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

I don't fully understand it either. :) I pulled it from previous list
discussion but didn't ask the person who posted it for clarification.

> From the rest of its text,
> perhaps it means that the x- name includes an string that is already
> standardized by some other spec?

That's my sense.

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

Well, "x-foo" is shorter than "VND.BrandenburgInternetWorking.foo".

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

Done.

>> Implementers are easily confused.
> 
> I don't understand how using or not using x- creates or alleviates
> confusion in implementers.

I don't either, but that was one of the objections.

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

Done.

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

WFM.

> (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?)

The point is directed at the kind of thing we find in RFC 5451, which
says that x- params MUST NOT be registered and non-x- params MUST be
registered. That seems wrongheaded to me.

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

Yep, and I have some more changes and examples in the recommendations
section now, too.

Dave, I'll push out a new version with you and Mark Nottingham as
co-authors and we can fight over who presents on the topic in Quebec City.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/