----- Original Message ----- From: "Peter Saint-Andre" <stpeter@xxxxxxxxxx> To: "t.petch" <daedulus@xxxxxxxxxxxxx> Cc: <ietf@xxxxxxxx>; "Dave CROCKER" <dcrocker@xxxxxxxx>; "Mark Nottingham" <mnot@xxxxxxxx> Sent: Tuesday, March 13, 2012 11:19 PM > 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? (Yes) > > > 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. Which I think the completely wrong direction in which to make changes:-( I might create a private parameter and decide that it should be named the X-Spam parameter, which can then take values, which may appear in the textual header, of one of Signs-of-Spam-Detected Signs-of-Spam-Not-Detected What you are saying is that because I have named it X-, this is unacceptable. What I think that you are assuming, erroneously, is that the value that appears in the textual header of the protocol is always identical to the name or at least starts with that name. Most people will probably understand your wording, but I still find it sloppy for an RFC (given the way that this list has dissected similar topics in the past). Tom Petch > > > 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/