ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-appsawg-xdash-03.txt> (Deprecating Use of the"X-" Prefix in Application Protocols) to Best Current Practice

2012-03-16 13:33:09
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/