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

From: Scott Kitterman <[email-masked]>
Date: Thu, 01 Mar 2012 14:00:46 -0500

On Thursday, March 01, 2012 10:47:50 AM The IESG wrote:
> The IESG has received a request from the Applications Area Working Group
> WG (appsawg) to consider the following document:
> - 'Deprecating Use of the "X-" Prefix in Application Protocols'
>   <draft-ietf-appsawg-xdash-03.txt> as a Best Current Practice
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2012-03-15. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>    Historically, designers and implementers of application protocols
>    have often distinguished between "standard" and "non-standard"
>    parameters by prefixing the latter with the string "X-" or similar
>    constructions.  In practice, this convention causes more problems
>    than it solves.  Therefore, this document deprecates the "X-"
>    convention for textual parameters in application protocols.
...

2.  Recommendations for Implementers of Application Protocols

   Implementers of application protocols MUST NOT treat the general
   categories of "standard" and "non-standard" parameters in
   programatically different ways within their applications.

Shouldn't this restrict itself to the naming of parameters?  Perhaps:

2.  Recommendations for Implementers of Application Protocols

   Implementers of application protocols MUST NOT treat the general
   naming of parameters in programmatically different ways within
   their applications depending on if they are "standard" or "non-standard".

Other than that nit, I think it looks good.

Scott K

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 01 Mar 2012 15:43:01 -0700

>    their applications depending on if they are "standard" or "non-standard".

How about this?

   Implementations of application protocols MUST NOT programatically
   discriminate between "standard" and "non-standard" parameters based
   solely on the names of such parameters.

> Other than that nit, I think it looks good.

Thanks!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 01 Mar 2012 19:14:41 -0500

>   solely on the names of such parameters.

I'm not quite sure.

Is this supposed to be about how one selects names or how one uses them. I'd thought it meant the former, but your revised text sounds like the latter to me.

Scott K

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Mar 2012 15:19:41 -0700

> Is this supposed to be about how one selects names or how one uses them. I'd thought it meant the former, but your revised text sounds like the latter to me.

The concept behind this text was always about how one uses names, or
more precisely how code implementations treat them, because the authors
are of the opinion that it's a bad idea for implementations to hardcode
their handling of parameter based solely on the existence of the string
'x-' at the start of the parameter name. I think the revised text I
provided captures this more clearly.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 06 Mar 2012 17:24:40 -0500

On Tuesday, March 06, 2012 03:19:41 PM Peter Saint-Andre wrote:
> >>>> The IESG has received a request from the Applications Area Working
> >> 
> >> Group
> >> 
> >>>> The IESG plans to make a decision in the next few weeks, and
> >> 
> >> solicits
> >> 
> >>>> final comments on this action. Please send substantive comments to
> >> 
> >> the
> >> 
> >>>> [email-masked] mailing lists by 2012-03-15. Exceptionally, comments
> >> 
> >> may be
> >> 
> >>>>    parameters by prefixing the latter with the string "X-" or
> >> 
> >> similar
> >> 
> >>>    their applications depending on if they are "standard" or
> >> 
> >> "non-standard".
> >> 
> >> How about this?
> >> 
> > Is this supposed to be about how one selects names or how one uses them.
> > I'd thought it meant the former, but your revised text sounds like the
> > latter to me.

Yes.  Thanks for clarifying.

Scott K

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Mar 2012 15:30:44 -0700

> Yes.  Thanks for clarifying.

Thanks for requesting clarification.

In my working copy I've changed that paragraph to:

   Implementations of application protocols MUST NOT programatically
   discriminate between "standard" and "non-standard" parameters based
   solely on the names of such parameters (i.e., based solely on
   whether the name begins with 'x-' or a similar string of characters).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 06 Mar 2012 17:32:11 -0500

On Tuesday, March 06, 2012 03:30:44 PM Peter Saint-Andre wrote:
> >>> Is this supposed to be about how one selects names or how one uses
> >>> them. I'd thought it meant the former, but your revised text sounds
> >>> like the latter to me.
> >> 

Looks good to me.

Scott K

---

From: Randall Gellens <[email-masked]>
Date: Tue, 6 Mar 2012 15:19:01 -0800

>     whether the name begins with 'x-' or a similar string of characters).

I like this wording, especially because it more clearly gets at the 
heart of the document, which is to not discriminate based only on the 
name prefix.

One question, though: should this be "SHOULD NOT" rather than "MUST 
NOT"?   The interoperability doesn't depend on implementations 
refraining from doing so, rather, we consider it more problematic to 
do so than not, so we are making a strong recommendation to not to 
so.  Hence, "SHOULD NOT".

 From RFC 2119:
    Imperatives of the type defined in this memo must be used with care
    and sparingly.  In particular, they MUST only be used where it is
    actually required for interoperation or to limit behavior which has
    potential for causing harm (e.g., limiting retransmisssions)  For
    example, they must not be used to try to impose a particular method
    on implementors where the method is not required for
    interoperability.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Language is a virus from outer space.  --William S. Burroughs

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Mar 2012 16:32:14 -0700

On 3/6/12 4:19 PM, Randall Gellens wrote:
> refraining from doing so, rather, we consider it more problematic to do
> so than not, so we are making a strong recommendation to not to so. 
> Hence, "SHOULD NOT".

Hi Randall,

My co-author Mark Nottingham feels even more strongly about this issue
than I do, so I will let him comment.

However, note the existence of things like the "x-gzip" and "gzip"
content codings in HTTP, which RFC 2068 says are equivalent. An
implementation that programmatically discriminated between "standard"
and "non-standard" parameters based solely on the parameter names might
automatically reject entities for which a content-coding of "x-gzip" is
specified, but automatically accept entities for which a content-coding
of "gzip" is specified. IMHO that's just wrong, and MUST NOT is appropriate.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 6 Mar 2012 23:46:07 +0000

Hey Peter,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
> Sent: Tuesday, March 06, 2012 3:32 PM
> To: Randall Gellens
> Cc: Mark Nottingham; [email-masked]
> Subject: Re: Last Call: <draft-ietf-appsawg-xdash-03.txt> (Deprecating
> Use of the "X-" Prefix in Application Protocols) to Best Current
> Practice
> 

So should this document note that it "Updates 2068"?

-MSK

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Mar 2012 16:49:57 -0700

> Hey Peter,

Howdy. :)

> So should this document note that it "Updates 2068"?

I don't think so, because "x-gzip" and "gzip" were in fact equivalent
(as far as I can see), so treating them as equivalent seems just fine.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Randall Gellens <[email-masked]>
Date: Tue, 6 Mar 2012 16:03:23 -0800

>  of "gzip" is specified. IMHO that's just wrong, and MUST NOT is appropriate.

Hi Peter,

Is the hypothetical application discriminating between all "x-" and 
everything else, or is it only doing so for parameters it does not 
recognize?  In the case of "x-gzip" and "gzip", wouldn't the 
application be doing whatever it does based on recognizing that this 
is gzip?

Anyway, it's hard for me to imagine a real application doing 
something like what the text suggests (say, bouncing email with 
"x-gzip" or refusing to expand an file or attachment of "x-gzip"), 
and even if there were such an application, it would be a very broken 
implementation, but not something that harmed the Internet or even 
anyone else whose applications worked properly.  At most it would 
harm its own user, who I assume would quickly dump it.

-------------- Randomly selected tag: ---------------
Computers are not intelligent.  They only think they are.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 6 Mar 2012 19:53:40 -0500

> it would be a very broken implementation, but not something
> that harmed the Internet or even anyone else whose applications worked
> properly.  At most it would harm its own user, who I assume would quickly
> dump it.

I don't think harm to the Internet is the bar for MUST.  If your
implementation would generally be considered broken if you did X, then
I think that rates a MUST NOT X.  It's often a bit of judgment whether
to use MUST NOT or SHOULD NOT, and we have some latitude in making
that judgment.  I agree with PSA and MNot that this case should be
MUST NOT.

Barry

---

From: Randall Gellens <[email-masked]>
Date: Tue, 6 Mar 2012 17:02:34 -0800

>  that judgment.  I agree with PSA and MNot that this case should be

Yeah, harm to the Internet is overblown, sorry.  But still, if a 
violation doesn't harm anyone else, then I don't think a MUST NOT is 
justified.  My reading of 2119 is the basis for this:

-------------- Randomly selected tag: ---------------
He knows nothing, and he thinks he knows everything. That points
clearly to a political career.
     -- George Bernard Shaw

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 7 Mar 2012 13:02:17 +1100

> than I do, so I will let him comment.

To me, the target of that language is software that generically treats protocol elements beginning with "x-" in a fundamentally different way, without knowledge of its semantics. That is broken, causes real harm, and I have seen it deployed. 

Regards,

--
Mark Nottingham   http://www.mnot.net/

---

From: Randall Gellens <[email-masked]>
Date: Tue, 6 Mar 2012 18:34:28 -0800

At 1:02 PM +1100 3/7/12, Mark Nottingham wrote:

>  To me, the target of that language is software that generically 
> treats protocol elements beginning with "x-" in a fundamentally 
> different way, without knowledge of its semantics. That is broken, 
> causes real harm, and I have seen it deployed.

Hi Mark,

The point of the draft is to say that it's a bad idea to do this or 
to try and have a system where this is expected.  The draft does a 
good job at saying this.  I just think a "MUST NOT" isn't warranted 
here; I think a "SHOULD NOT" is justified per RFC 2119.  I think a 
"SHOULD NOT" makes the point: Doing it makes bad things happen.

-------------- Randomly selected tag: ---------------
I personally think we developed language because of our
deep need to complain.                    --Lily Tomlin

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 7 Mar 2012 13:50:43 +1100

On 07/03/2012, at 1:34 PM, Randall Gellens wrote:

> The point of the draft is to say that it's a bad idea to do this or to try and have a system where this is expected.  The draft does a good job at saying this.  I just think a "MUST NOT" isn't warranted here; I think a "SHOULD NOT" is justified per RFC 2119.  I think a "SHOULD NOT" makes the point: Doing it makes bad things happen.

I have to disagree; MUST NOT *is* justified. Deploying systems like this causes real interoperability problems, which is in scope for a MUST NOT.

---

From: Randy Bush <[email-masked]>
Date: Wed, 07 Mar 2012 11:52:44 +0900

> To me, the target of that language is software that generically treats
> protocol elements beginning with "x-" in a fundamentally different
> way, without knowledge of its semantics. That is broken, causes real
> harm, and I have seen it deployed.

clue bat please?  is there any general semantic to X-?

randy

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 7 Mar 2012 15:11:04 +1100

> clue bat please?  is there any general semantic to X-?

I think one of the main points of the draft is to answer that question with "no."

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 7 Mar 2012 00:54:07 -0500

But it does clue one in immediately to the fact that the parameter is
non-standard.

Paul

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Mark Nottingham
> Sent: Tuesday, March 06, 2012 11:11 PM
> To: Randy Bush
> Cc: Randall Gellens; [email-masked]
> Subject: Re: Last Call: <draft-ietf-appsawg-xdash-03.txt> (Deprecating Use
> of the "X-" Prefix in Application Protocols) to Best Current Practice
> 
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 7 Mar 2012 16:56:57 +1100

Yes, but (as the draft tries to explain) putting this kind of metadata in a name is prone to issues, because it can change -- i.e., when a header (or other protocol element) becomes standard.

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 7 Mar 2012 01:19:42 -0500

I suppose one could argue that X- should never be on the Public Internet,
anyway.  But they are.  If we remove X-, then what will happen is developers
will use names that don't have X-.  Will that make things better?  No.  I'd
argue it will make it worse.

Non-standard extensions do present issues, that's no in question.  However,
killing X- will only mean other values will be used.  At least X- can be
ignored.

I'm not going to throw up a roadblock to the draft.  Call for the end of X-
if you want, but I know it will not stop introduction of non-standard values
in protocols, so a problem will remain.

One way to help this is to get standards through the IETF faster.  Some take
forever.

Paul

> From: Mark Nottingham [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2012 12:57 AM
> To: Paul E. Jones
> Cc: 'Randy Bush'; 'Randall Gellens'; [email-masked]
> Yes, but (as the draft tries to explain) putting this kind of metadata in
> a name is prone to issues, because it can change -- i.e., when a header
> (or other protocol element) becomes standard.
> 
> 
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> >> Of Mark Nottingham
> >> Subject: Re: Last Call: <draft-ietf-appsawg-xdash-03.txt>
> >> (Deprecating Use of the "X-" Prefix in Application Protocols) to Best
> >> Current Practice
> >>
> >>

---

From: Randall Gellens <[email-masked]>
Date: Tue, 6 Mar 2012 22:26:20 -0800

>  killing X- will only mean other values will be used.  At least X- can be

I was quite skeptical for a while, but came around to seeing the case 
that trying to segregate non-standard parameters ends up creating 
more problems than it solves.

You're right that people will use names without an 'x' and the draft 
encourages this.  So, we'll end up with (as I think the draft 
suggests), situations where 'priority' is the old, non-standard name, 
and 'urgency' is the new, standardized name, instead of 'x-priority' 
and 'priority'.  But the fact is that names which start out as 
non-standard hacks end up being de facto standards.  That's no better.

-------------- Randomly selected tag: ---------------
We adore chaos because we love to produce order.
                                  --M. C. Escher

---

From: "t.petch" <[email-masked]>
Date: Wed, 7 Mar 2012 10:07:30 +0100

----- Original Message -----
From: "Paul E. Jones" <[email-masked]>
To: "'Mark Nottingham'" <[email-masked]>
Cc: "'Randall Gellens'" <[email-masked]>; <[email-masked]>
Sent: Wednesday, March 07, 2012 7:19 AM
Subject: RE: Last Call: <draft-ietf-appsawg-xdash-03.txt> (DeprecatingUse of the
"X-" Prefix in Application Protocols) to BestCurrent Practice

> anyway.  But they are.

Yup, your e-mail reached me with 14 different lines starting X- in the header,
none of which were added by my ISP.  Whether their presence makes any difference
to what I see and I get, I have no idea.

I suspect that like DNS TXT records, they are with use for eternity.

Tom Petch
<snip>

---

From: John C Klensin <[email-masked]>
Date: Thu, 08 Mar 2012 13:01:46 -0500

Hi.

I realize I'm probably in the minority on this, but I think the
document overstates its case a bit and, perhaps recognizing the
actual complexity of the situation, even may contradict itself a
bit.  For example, I note that it says:

	(Section 1) "Therefore this document deprecates the "X-"
	convention for named parameters in application
	protocols" 
	
	but 
	
	(Section 4 (4)) "SHOULD identify a convention to allow
	local or implementation-specific extensions, and reserve
	delimeters for such uses as needed." presumably as long
	as those delimiters don't consist of "X-".

While I believe that the general strategy of treating textual
parameters as hierarchical (or consisting of subsets) so that
private allocations can exist in a separate tree is a good one,
I think we also need to recognize that "X-" is just one more way
to make that division.  If it not a wonderful one, and it
carries around a lot of baggage, but neither justifies the
amount of venom that has been directed toward it over the years
nor some of the strong language of this document (which is much
better than some of its earlier drafts in that respect).  

The reality is that, when "X-" has been used to identify purely
private and/or implementation-specific parameters, it has not
been a problem.  It has been a problem for experimental
parameters, but that is a different matter... and a distinction
this document fails to make clearly enough, at least IMO.

Overstating the case for something like this, e.g., by inserting
MUST NOT language where there is little justification for more
than "SHOULD NOT" won't be likely change the behavior of those
creating or maintaining implementations.  MUST NOTs that are
ignored do nothing positive for the reputation or credibility of
the IETF.  I largely agree with Randy Gellens's reasoning about
this.  However, I don't think the choice of requirements
language is a showstopper: I think it is a judgment call and
that, unless there is a basis for strong consensus, judgment
calls should generally be resolved in favor of a less-strong
requirement.

While Appendix A mentions the history of using "X" (without the
dash) for experimental and private command names, the document
does not address that issue at all.

The second "primary objection" listed in Appendix B is, IMO,
somewhat misstated.  It would be more accurate to say, more or
less, 

	"Collisions are undesirable and it would be bad for a
	parameter 'foo' to designate two different sets of
	semantics, whether either of those sets is standard or
	not.  The only ways to avoid that situation are for all
	parameters to be registered so that someone considering
	defining a new one can determine whether the name string
	is already in use _or_ for all parameters to contain a
	relatively-long randomly-generated substring to make the
	likelihood of accidental collision infinitesimal.  The
	problem is that it is impossible to achieve universal
	registration despite the changes represented by more
	recent registration specifications, so there is some
	merit to being able to lexically distinguish private use
	(not to be accepted in interchange without out-of-band
	knowledge) parameter values from broader-use (and
	possibly standardized) ones."

I note that no one has seriously proposed the "random substring"
solution but, if we were serious about the problem for
parameters users are unlikely to see, it is part of the logical
solution space.

Finally, the effect of this document is to update a rather large
collection of existing specifications, not all of which are
included in textual discussion or references.  Those
specifications are not listed in the text or in an "updates"
header, much less called out in the Introduction and/or Abstract.

Recommendations:

(1) As suggested by several others, remove the "MUST" from
Section 2, replacing it with "SHOULD".

(2) Clarify whether this document is intended to deprecate
giving special treatment to protocol commands starting in "X"
rather than merely parameters starting in "X-" and why or why
not.

(3) Clarify the difference between "private-use" parameters,
"implementation-specific" parameters, and "experimental"
parameters.  Strong language discouraging the latter is probably
appropriate, but clearly-defined private uses may be reasonable
(at least for some protocols), and implementation-specific
parameters may fall somewhere in between. 

(4) Correct the explanation of the counterarguments as outlined
above so that the document is not attacking straw men.

(5) Either (i) explicitly identify the complete list of
specifications that this one updates, doing so with all of the
decorations that the IESG has required in other specifications,
(ii) incorporate language into this specification and a revised
Last Call that identifies the reasons why this specification is
exempt, or (iii) clarify, before this document is approved, what
the requirements (and "really strong suggestions") actually are
in a way that makes it clear why they should not apply to
documents of this type.

Just my opinion.
    john

--On Thursday, March 01, 2012 10:47 -0800 The IESG
<[email-masked]> wrote:

> 
> The IESG has received a request from the Applications Area
> Working Group WG (appsawg) to consider the following document:
> solicits final comments on this action. Please send
> substantive comments to the [email-masked] mailing lists by
> 2012-03-15. Exceptionally, comments may be sent to
> [email-masked] instead. In either case, please retain the

---

From: "t.petch" <[email-masked]>
Date: Tue, 13 Mar 2012 10:37:43 +0100

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 talks of
'parameters by prefixing the latter '
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 I-D seems to be conflating the ideas of name and value and a few other
things as well.  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 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.

Tom Petch

----- Original Message -----
From: "The IESG" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 01, 2012 7:47 PM
Subject: Last Call: <draft-ietf-appsawg-xdash-03.txt> (Deprecating Use of
the"X-" Prefix in Application Protocols) to Best Current Practice

> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-appsawg-xdash/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-appsawg-xdash/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 13 Mar 2012 16:19:08 -0600

On 3/13/12 3:37 AM, t.petch wrote:
> Thus the summary 

Clarifying quesiton: do you mean the abstract?

> talks of

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 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

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/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 13 Mar 2012 16:23:55 -0600

> "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/

---

From: "t.petch" <[email-masked]>
Date: Fri, 16 Mar 2012 11:00:57 +0100

----- Original Message -----
From: "Peter Saint-Andre" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>; "Dave CROCKER" <[email-masked]>; "Mark Nottingham"
<[email-masked]>
Sent: Tuesday, March 13, 2012 11:19 PM

> Clarifying quesiton: do you mean the abstract? (Yes)
>
> > talks of

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 16 Mar 2012 12:32:49 -0600

> 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.

> for an RFC (given the way that this list has dissected similar topics in the

Suggested text is always welcome.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/