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/