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/