On 3/16/12 4:00 AM, t.petch wrote: > ----- 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. As I said in my previous reply, this document says absolutely nothing about the values of parameters, only about the names of parameters. I must admit that I an confused as to why you construe otherwise. If indeed strings leak out of the space of parameter names into the space of parameter values, as in your example, that is purely a byproduct of the leakage, and does not change the fact that the recommendations in this I-D apply to parameter names. > 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). Suggested text is always welcome. Peter -- Peter Saint-Andre https://stpeter.im/