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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Peter

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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]