Re: [apps-discuss] Review of draft-ietf-appsawg-xdash-04

[Peter Saint-Andre <[e-mail]>]

Hi Henry, thanks for the review. Comments inline.

On 3/30/12 4:20 AM, Henry S. Thompson wrote:
> I have been selected as the Applications Area Directorate reviewer for
> this draft (for background on appsdir, please see
> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).
> 
> Please resolve these comments along with any other Last Call comments
> you may receive. Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
> 
> Document: draft-ietf-appsawg-xdash
> 
> Title: Deprecating the X- Prefix and Similar Constructs in Application Protocols
> 
> Reviewer: Henry S. Thompson
> 
> Review Date: 2012-03-30
> 
> IETF Last Call Date: 2012-03-15
> 
> Summary: This draft is almost ready for publication as an Proposed
>          Standard but has a few issues that should be fixed
>          before publication
> 
> Major Issues:
> 
> Abstract and Introduction
> 
> [This started out as a nit about the use of scare-quotes in the
> Abstract, but now that I see how much depends on it throughout the
> document, I have promoted it]
> 
> I have an allergy to scare-quotes, I guess, but putting
> quotes around "standard" here seems . . . odd.  If what you mean is
> more along the lines of "distinguished between the names of parameters
> defined in the relevant standards and those without such definitions",
> then words along those lines might serve better. . .  

I'm not a big fan of scare quotes, either. The point here is that people
have assumed that parameters without X- or similar constructs are
produced in accordance with a standards process (e.g., even if they are
registered directly with the IANA such a registration has been handled
as defined in a specification produced by a recognized standards
development organization), and have assumed that parameters with X- or
similar constructs are produced outside a standards process. Given the
leakage of the latter parameters into the standards space, we included
the scare quotes to indicate that the categories of standard parameters
and non-standard parameters are imprecise and illegitimate (some
apparently non-standard parameters are de facto standards on the wire).
In our discussions with the IESG, Dave Crocker suggested the term
"standardized", and after a bit of reflection I now think that would be
clearer because a de facto standard simply emerges and can't be said to
have been actively standardized / produced in accordance with a
standards process.

> If you make such
> a change, then "newly-defined parameters" could become something such
> as "parameters getting their names outside the standards process".

Well, newly-defined parameters are any parameters that people create and
name after this document is published as a BCP, so they will have gotten
their names in accordance with a standards process. :)

> More importantly, the distinction between "parameters named in, or by
> means licensed by, the relevant standard" and "parameters named
> elsewhere" deserves more careful definition than that implied just by
> contrasting, in quotes, "standard" and "non-standard", given the
> weight the distinction has to bear later on.

My take is that people have conflated standardized parameters with
standard parameters, thinking that a parameter that was never
standardized cannot become a standard. Clearly that's not true, because
some parameters that were never standardized (that were not produced in
accordance with a standards process) have become standard parameters.

The more I think about it, the more I would prefer the terms
'standardized' and 'unstandardized' (without any scare quotes) over the
terms 'standard' and 'non-standard'.

Thus, I suggest the following clarifications to the Introduction (as
well as appropriate terminology changes throughout):

   Many application protocols use parameters with textual (as opposed to
   numerical) 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 standardized
   and unstandardized parameters by prefixing the names of
   unstandardized parameters with the string "X-" or similar constructs
   (e.g., "x."), where the "X" is commonly understood to stand for
   "eXperimental" or "eXtension".

   Under this convention, the name of a parameter not only identified
   the data, but also embedded the status of the parameter into the name
   itself: a parameter defined in a specification produced by a
   recognized standards development organization (or registered
   according to processes defined in such a specification) did not start
   with "X-" or similar constructs, whereas a parameter defined outside
   such a specification or process started with "X-" or similar
   constructs.

> Section 2.  Maybe not major?  Depends on the answer.  What does
> "discriminate between 'standard' and 'non-standard' parameters"
> actually _mean_?  Either a parameter is defined in the relevant
> standard, or via a standards-licensed route, or it isn't.  This
> section seems to imply there is some kind of generic processing
> reserved to parameters named in or licensed by the relevant standard
> (or, perhaps, to parameters _not_ so named), but this reader at least
> is not clear what such generic processing might be. 

Based on IESG feedback, we changed Section 2 to read:

   Implementations of application protocols MUST NOT make any
   assumptions about the status of a parameter, nor take automatic
   action regarding a parameter, based solely on the presence or absence
   of "X-" or a similar construct in the parameter's name.

> It seems that the
> authors of this RFC know, or suspect, that some application
> implementers are lazy, and deploy such processing without actually
> using a list derived from the relevant specs and registries---if so,
> give an example?  If not, what is this section for, exactly?

Mark, would you like to provide some examples based on your experience?

> Minor Issues:
> 
> 3  Maybe, if you think there are relevant cases, add something along
> the lines of "MUST follow any naming guidelines set out in the
> relevant standard(s)".

We do say that this specification does not override naming rules for
existing application protocols (e.g., the "x-name" token in RFC 5545).
Are there other naming guidelines that you have in mind here?

Thanks again,

Peter

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