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

ht@inf.ed.ac.uk (Henry S. Thompson) Fri, 30 March 2012 10:20 UTC

To: apps-discuss@ietf.org, draft-ietf-appsawg-xdash.all@tools.ietf.org
From: ht@inf.ed.ac.uk
Date: Fri, 30 Mar 2012 11:20:00 +0100
Message-ID: <f5b7gy2v19r.fsf@calexico.inf.ed.ac.uk>
User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: iesg@ietf.org
Subject: [apps-discuss] Review of draft-ietf-appsawg-xdash-04
Precedence: list

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. . .  If you make such
a change, then "newly-defined parameters" could become something such
as "parameters getting their names outside the 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.

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

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

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

[apps-discuss] Review of draft-ietf-appsawg-xdash… Henry S. Thompson
Re: [apps-discuss] Review of draft-ietf-appsawg-x… Peter Saint-Andre