On 3/16/12 4:00 AM, t.petch wrote:
----- Original Message -----
From: "Peter Saint-Andre" <stpeter(_at_)stpeter(_dot_)im>
To: "t.petch" <daedulus(_at_)btconnect(_dot_)com>
Cc: <ietf(_at_)ietf(_dot_)org>; "Dave CROCKER"
<dcrocker(_at_)bbiw(_dot_)net>; "Mark Nottingham"
<mnot(_at_)mnot(_dot_)net>
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/