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/