Re: Last Call: <draft-ietf-appsawg-xdash-03.txt> (Deprecating Use of the"X-" Prefix in Application Protocols) to Best Current Practice

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

On 3/13/12 4:19 PM, Peter Saint-Andre wrote:
> On 3/13/12 3:37 AM, t.petch wrote:
>> I am surprised at the lack of comment on this I-D on its use of terminology.  I
>> have seen and learnt from many discussions on this list that have teased out
>> what concept it is we are really talking about (e.g. identity v identifier) and
>> this I-D seems somewhat weak in that regard.
>>
>> Thus the summary 
> 
> Clarifying quesiton: do you mean the abstract?
> 
>> talks of
>> 'parameters by prefixing the latter '
> 
> http://tools.ietf.org/html/draft-ietf-appsawg-xdash-04 does not contain
> that string. The discussions on this list and with the IESG have led to
> some changes in the text. The Abstract now reads:
> 
>    Historically, designers and implementers of application protocols
>    have often distinguished between "standard" and "non-standard"
>    parameters by prefixing the names of "non-standard" parameters with
>    the string "X-" or similar constructs.  In practice, that convention
>    causes more problems than it solves.  Therefore, this document
>    deprecates the convention for the names of newly-defined textual
>    parameters in application protocols.
> 
>> while the  introduction changes that to
>> 'the "X-" convention for named parameters in application protocols '
>> which is then refined to
>> 'only parameters with textual names, not parameters that are expressed as
>> numbers'
>> which seems to me a false dichotomy.
> 
> The relevant paragraph of the Introduction now reads:
> 
>    Many application protocols use parameters with textual names to
>    identify data (media types, header fields in Internet mail messages
>    and HTTP requests, vCard parameters and properties, etc.).
>    Historically, designers and implementers of application protocols
>    have often distinguished between "standard" and "non-standard"
>    parameters by prefixing the names of "non-standard" parameters with
>    the string "X-" or similar constructs (e.g., "x."), where the "X" is
>    commonly understood to stand for "eXperimental" or "eXtension".  That
>    is, instead of just identifying the data, the name also embedded the
>    status of the name as "non-standard" into the name itself.
> 
>> The I-D seems to be conflating the ideas of name and value 
> 
> In my opinion, I think those ideas are clearer now in -04, again based
> on feedback we have received and addressed. Please take a look at the
> latest version and let us know what you think.
> 
>> and a few other
>> things as well. 
> 
> Please do clarify what other things you think are conflated.
> 
>> I know of very few parameters in IETF protocols that do not
>> have names and cannot recall one where the name is not textual. 
> 
> The contrast is with parameters whose names are numerical, not textual.
> Often parameter spaces whose names are numerical are smaller, i.e., do
> not allow such a wide range of names; in such cases, the considerations
> in BCP 82 might apply.
> 
>> The I-D seems
>> to be assuming that the parameter name and the parameter value and so on are
>> synonymous, identical, equivalent and perhaps a few other things as well, and
>> having assumed that, then it is sufficient to say that one or other of these
>> concepts are textual and it is to these that this I-D applies.  This seems to me
>> to be rather too loosely worded to become an RFC.
> 
> This I-D says absolutely nothing about parameter values. If some folks
> have understood differently, then we need to clarify the wording. I can
> now see that "the names of newly-defined textual parameters" in the
> Abstract could be misconstrued, although I think the phrasing in the
> Introduction is clearer: "parameters with textual names". In both
> instances we could further clarify our intent by using the phrase
> "parameters with textual (as opposed to numerical) names".

In our working copy I have changed the last sentence of the Abstract to:

   Therefore, this document deprecates the convention for newly-defined
   parameters with textual (as opposed to numerical) names in
   application protocols.

Peter

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