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

From: William Mills <[email-masked]>
Date: Wed, 7 Mar 2012 22:31:55 -0800 (PST)

Document: draft-ietf-appswg-xdash-03
Title: Deprecating Use of the "X-" Prefix in Application Protocols
Reviewer: William J. Mills
Review Date: March 6th, 2012
IETF Last Call Date: unknown
IESG Telechat Date: unknown

Summary: This draft is generally ready for publication, there are some small issues that might be worth adjusting.

Major Issues: 

Minor Issues: 

Section 4.5 through 4.7:  I would change '"X-" prefix' to '"X-" or similar prefix'

Nits: 

Appendix B, numeral 1 and 3, second sentence:  I would strike "However, " and start the sentences  "In this case..."

-    This draft uses the "$statement. However, $argument_against" construction a lot, and I find that somewhat clunky.  However, I doubt it's worth fixing.

-    The references are populated primarily with things from the appendices.  It would make more sense to me if references came last, but I think that breaks the standard format rules.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 08 Mar 2012 10:27:22 -0700

Hi Bill, thanks for the review. A few comments inline.

On 3/7/12 11:31 PM, William Mills wrote:
> 
> 
> Document: draft-ietf-appswg-xdash-03 Title: Deprecating Use of the
> "X-" Prefix in Application Protocols Reviewer: William J. Mills 
> Review Date: March 6th, 2012 IETF Last Call Date: unknown IESG
> Telechat Date: unknown
> 
> Summary: This draft is generally ready for publication, there are
> some small issues that might be worth adjusting.
> 
> Major Issues:
> 
> 
> Minor Issues:
> 

Good point. In our working copy, I have changed those instances to:

   the "X-" prefix or similar constructions

(as we have in the Introduction)

> Nits:
> 
> Appendix B, numeral 1 and 3, second sentence:  I would strike
> "However, " and start the sentences  "In this case..."

Done in our working copy.

> -    This draft uses the "$statement. However, $argument_against"
> construction a lot, and I find that somewhat clunky. 

I suppose it is a bit of beating people over the head. Nevertheless, I
find it clearer to use conjunctive adverbs such as "However".

> However, I
> doubt it's worth fixing.

;-)

> -    The references are populated primarily with things from the
> appendices.  It would make more sense to me if references came last,
> but I think that breaks the standard format rules.

Yes, it does. Alternatively, we could move the appendices to
informational sections before the references if we felt that would help.

Peter

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

---

From: Dave Crocker <[email-masked]>
Date: Thu, 08 Mar 2012 09:43:27 -0800

>     the "X-" prefix or similar constructions

I apologize for not noting this issue earlier.

The document has become a set of rules about /any/ naming method that 
distinguishes standard from non-standard.  It's no longer constrained to "X-".

As such I suggest changing it's name to something like

   Deprecating Specialized Naming for Non-Standard Values (X- and Similar 
Constructs)

I like to have titles help document searching and organizing.

> informational sections before the references if we felt that would help.

Nah.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 08 Mar 2012 10:59:54 -0700

> I like to have titles help document searching and organizing.

+1, good suggestion. Changed in our working copy. I've also done:

s/constructions/constructs/g

Peter

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

---

From: John C Klensin <[email-masked]>
Date: Thu, 08 Mar 2012 15:31:58 -0500

--On Thursday, March 08, 2012 10:59 -0700 Peter Saint-Andre
<[email-masked]> wrote:

>>   Deprecating Specialized Naming for Non-Standard Values (X-
>>   and Similar Constructs)
>> 

Me too.

But note that "prs.xxxxx" and even "vnd.FooCo.yyyy" are
"specialized naming for non-standard values"

    john

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 08 Mar 2012 13:43:23 -0700

> "specialized naming for non-standard values"

Are they specialized naming for local or implementation-specific values,
not non-standard values? Perhaps that's splitting hairs...

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 08 Mar 2012 13:47:22 -0700

> not non-standard values? Perhaps that's splitting hairs...

On further reflection, I think that is splitting hairs. This might be a
more accurate title: "Deprecating the X- Prefix and Similar Constructs
in Application Protocols".

Peter

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

---

From: John C Klensin <[email-masked]>
Date: Thu, 08 Mar 2012 16:06:17 -0500

--On Thursday, March 08, 2012 13:43 -0700 Peter Saint-Andre
<[email-masked]> wrote:

> Are they specialized naming for local or
> implementation-specific values, not non-standard values?
> Perhaps that's splitting hairs...

Given that the media types document (both current and pending
versions) explicitly identifies them as non-standard trees, I
don't think even hair-splitting makes that title correct.  You
could say "specialized non-hierarchical..." or "specialized
non-faceted...".  That is also hair-splitting but would at least
be correct.

   john

---

From: Martin Thomson <[email-masked]>
Date: Thu, 8 Mar 2012 13:40:03 -0800

> non-faceted...".  That is also hair-splitting but would at least

In my mind, the distinction was always experimental vs.
non-experimental, as opposed to vendor-specific vs. standardized.  I
think that's where the document has gone astray.  Different axis of
split, methinks, even if the axes aren't entirely orthogonal.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 08 Mar 2012 13:48:12 -0800

On 3/8/2012 1:40 PM, Martin Thomson wrote:
> On 8 March 2012 13:06, John C Klensin<[email-masked]>  wrote:

X- itself has a rather long and well-documented history and purpose.  The 
current document has expanded scope a bit, to try to cover a class, not merely 
an instance.

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.

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

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.

d/

-- 

   Dave Crocker

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 08 Mar 2012 16:22:06 -0700

On 3/8/12 2:48 PM, Dave Crocker wrote:
> X- itself has a rather long and well-documented history and purpose. 
> The current document has expanded scope a bit, to try to cover a class,
> not merely an instance.
> 
> 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.
> 
> This is true for "experimental" names, "vendor" names, and any other
> kind of non-standard name.
> 
> 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.

Peter

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 8 Mar 2012 15:40:23 -0800

On 8 March 2012 15:22, Peter Saint-Andre <[email-masked]> wrote:
> So I think it might be best

That's the part that confused me.  SHOULD NOT also works, in line with
the rest of the guidance.

+1

---

From: Dave Crocker <[email-masked]>
Date: Thu, 08 Mar 2012 16:57:14 -0800

>        specific extensions, and reserve delimeters for such uses as

I think +1

d/

-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Thu, 08 Mar 2012 23:59:36 -0500

--On Thursday, March 08, 2012 13:40 -0800 Martin Thomson
<[email-masked]> wrote:

>> don't think even hair-splitting makes that title correct.
>>  You could say "specialized non-hierarchical..." or
>> "specialized non-faceted...".  That is also hair-splitting
>> but would at least be correct.
> 
> non-experimental, as opposed to vendor-specific vs.
> standardized.  I think that's where the document has gone
> astray.  Different axis of split, methinks, even if the axes
> aren't entirely orthogonal.

Yes.  And that has been a problem almost since the beginning.
We've talked about it as "experimental" ("extension" is, as far
as I can remember, a very recent retrofit) but described how
implementations are expected to respond to it very much in terms
consistent with "private use", e.g., mutual agreement between
consenting adults, etc.  

We've known for a long time that the transitional issues with
"experimental" make it a bad idea.  That is clear from the
discussion of the FTP commands starting in "X" in RFC 1123 even
though 1123 didn't explicitly deprecate the idea.  In that
regard, this draft can be seen as saying "we've known for a
really long time that using specific syntax, 'X-' or otherwise,
to designate experimental features that might mature into
general use and it is time to finally put a stop to it".
Quibbles about SHOULDs and MUSTs notwithstanding, I think that
is entirely reasonable and the right thing to do.

The "private use" cases are another matter.  Nothing we can do
about changing registration procedures is going to get a lot of
those registered.  Sometimes there aren't good reasons to resist
registration, but sometimes there are what appear to be good
reasons and nothing that the IETF can do is going to change
that.  So, for the private use cases, having something that
designates "unless you, the recipient, have worked out something
in advance with that particular sender, you don't know what this
means whether you think you recognize the string or not" may be
a useful tool to keep around... more useful than hoping that
someone making up a new keyword won't somehow conflict with an
unregistered one that uses different semantics.

    john

---

From: Dave Crocker <[email-masked]>
Date: Thu, 08 Mar 2012 21:23:49 -0800

The construct was introduced with RFC 822:

>      extension-field =
>                    <Any field which is defined in a document
>                     published as a formal extension to this
>                     specification; none will have names beginning
>                     with the string "X-">

d/
-- 

   Dave Crocker

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 09 Mar 2012 09:14:23 -0700

>>        specific extensions, and reserve delimeters for such uses as

Removed in our working copy.

Peter

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