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

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

On 6/29/11 4:05 PM, Dirk Pranke wrote:
> Your draft has:
> 
>>   In some situations, segregating the name space of parameters used in
>>   a given application protocol can be justified:
>>   ...
>>   2.  When parameter names might have significant meaning.  This case
>>       is rare, since implementers can almost always find a synonym
>>       (e.g., "urgency" instead of "priority") or simply invent a new
>>       name.
> 
> It seems to me that a primary benefit of the "X-" convention is that
> it makes unprefixed parameter names less socially acceptable; 

That's tautological -- the "X-" convention attempts to segregate the
parameter space by dividing it into the standard area (a good, clean,
safe, respectable place to be) and the non-standard area (a bad, dirty,
unsafe, slightly scandalous place to be). Naturally it's less socially
acceptable to be in the non-standard part of town.

> i.e.,
> there's a pretty clear rule of thumb that if the name isn't X-
> prefixed, it probably has seen a pass through a committee and hence it
> stands at least a chance of having the same meaning in multiple
> implementations.

The fact of leakage from the non-standard area into the standard area
shows that it's quite possible for one of those raffish parameters
starting with "X-" to have the same meaning in multiple implementations.

And I'll not that passing through a committee does not necessarily
guarantee that a parameter will have the same meaning in multiple
implementations, or be a better parameter for the experience.

Is your argument that we want to encourage folks to cross the tracks
into the more respectable part of the parameter space by publishing
Internet-Drafts and gaining consensus on their proposals? That seems to
be a good thing no matter what the form of the parameter name. Shedding
the mark of the "X-" strikes me as a rather insignificant benefit of
standardization.

> I am concerned that if you abandon the X- practice, you will lose this
> benefit and finding untainted, available parameter names might become
> harder. Sure, you can often find a synonym, but it is not usually as
> good as the original choice. I would hate to see things move to a
> namespace land-grab like we have seen in DNS.

As Eric Burger noted, there's not much danger of a land grab here.
Although it's nice for protocol parameter names to be readable to
developers (for debugging and the like), they're not intended to be
shown to end users, so there's not much need or incentive to reserve the
cool names before some parameter shark gets to them.

Is there some kind of attack lurking here that we're not aware of?
Parameter phishing or somesuch?

Peter

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