Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xdash-02.txt

From: Randall Gellens <[email-masked]>
Date: Sun, 13 Nov 2011 18:20:17 -0800

One thing I noticed is that the text in Appendix B, to me, makes an 
argument for preserving some mechanism to distinguish between 
standard and ad-hoc:

    Furthermore, often standardization of a non-standard parameter or
    protocol element leads to subtly different behavior (e.g., the
    standard version might have different security properties as a result
    of security review provided during the standardization process).  If
    implementers treat the old, non-standard parameter and the new,
    standard parameter as equivalent, interoperability and security
    problems can ensue.

To me, this text points out that sometimes people slap together an 
ad-hoc "x-" parameter, and later go for a standard version, which 
after wider review is modified to address security or other issues; 
the text notes that if this happens, and if implementations treat the 
old and new versions as identical, then they are being exposed to the 
vulnerabilities.  However, the solution proposed here means that, 
once an ad-hoc version is deployed, there won't be a standard 
version, and hence no wider review, no revised version with a non-x 
name, and no chance for implementations to avoid the problems.  It 
seems to me that it would be better for the standard version to 
deprecate the non-standard in these cases, or at least describe how 
to avoid its problems.

I can't help but think that we'd be better off with a middle ground, 
similar to "vnd." namespace, for ad-hoc parameters that might or 
might not be standardized, but that clearly have not been through 
IETF consensus.  One advantage is that it provides some impetus 
(however slight) to develop a standard version if it's useful. 
Another advantage is that it might provide better clues as to the 
source of and change control over the ad-hoc parameter.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Anyone can do any amount of work provided it isn't the work he is
supposed to be doing at the moment.               --Robert Benchley
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
It has always seemed to me that the most difficult part of building
a bridge would be the start.                      --Robert Benchley