Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03

[John C Klensin <[e-mail]>]

--On Thursday, March 08, 2012 16:22 -0700 Peter Saint-Andre
<[e-mail]> wrote:

>...
>> The class is "names that are syntactically designed to be
>> outside of standards space" because such names have a
>> regularly tendency to become de facto standards, which makes
>> formally standardizing them problematic.

Agreed.

>> This is true for "experimental" names, "vendor" names, and
>> any other kind of non-standard name.

The leap to "any other kind of non-standard name" doesn't
follow.  

>> The premises behind the concern are a) registration is
>> difficult, b) the name should flag the status.
>> 
>> What the community has learned or the thirty-or-so years of
>> the construct is that it's better to have a single, clean
>> name space and leave status of the name as a separate issue.
> 
> Well put.
> 
> Yet the inclusion of delimiters in parameter names could be
> construed as just another way segregating the namespace. So I
> think it might be best to remove the fourth bullet point in
> Section 4:
> 
>    4. SHOULD identify a convention to allow local or
> implementation-       specific extensions, and reserve
> delimeters for such uses as       needed.

I admit I found that bullet point confusing.  However, an
interpretation of Dave's statement could extend to a
prohibition, not only on faceted or hierarchical names but on
the "+xml" arrangements and the like that we've used in media
types.  I would encourage you to go even further than simply
removing that bullet point: stick to "X-" parameters and field
names and to "X" commands in this document and let the other
naming and registry issues get sorted out elsewhere.  The cost
of overreaching into very broad statements could be to create a
situation in which all of those other arguments need to be
sorted out twice or, perhaps worse, blocking this until all of
the registration strategy arguments are settled.

   john

p.s. Dave, apologies for forgetting that "extension" was used in
822.  I obviously didn't go back and look.