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

From: [email-masked]
Date: Tue, 13 Sep 2011 10:07:05 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF.

	Title           : Deprecating Use of the &quot;X-&quot; Prefix in Application Protocols
	Author(s)       : Peter Saint-Andre
                          D. Crocker
                          Mark Nottingham
	Filename        : draft-ietf-appsawg-xdash-00.txt
	Pages           : 12
	Date            : 2011-09-13

   Historically, designers and implementers of application protocols
   have often distinguished between &quot;standard&quot; and &quot;non-standard&quot;
   parameters by prefixing the latter with the string &quot;X-&quot; or similar
   constructions.  In practice, this convention causes more problems
   than it solves.  Therefore, this document deprecates the &quot;X-&quot;
   convention for most application protocol parameters.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-xdash-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-xdash-00.txt

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 15 Sep 2011 14:17:42 +0200

> Filename        : draft-ietf-appsawg-xdash-00.txt

Nice.  Maybe add image/x-icon vs. image/vnd.microsoft.com
as an example where "de facto" vs. "de jure" created an
interoperability mess with dozens of articles offering
their own "one and final truth" about favicons.

-Frank

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sun, 18 Sep 2011 07:28:06 +0300

13.09.2011 20:07, [email-masked] wrote:
> 	Title           : Deprecating Use of the&quot;X-&quot; Prefix in Application Protocols

Some comments:

1.  Throughout the document: s/HTTP headers/HTTP header fields/.

2.  Bullet 3 in Section 4 (and Bullet 1 in Appendix B):

>         Especially if the parameter
>         is intended to have meaning to implementers, the name could be a
>         URI (e.g.,"http://example.com/foo")

I don't think this may be appropriate in most of current 
application-layer protocols (eg. header fields, URI scheme names, URN 
namespaces, FTP/SMTP/POP commands etc.).

3.  Bullet 4 in Section 4:

>     4.  SHOULD generate meaningless names for parameters that will not
>         become standardized or widely used (e.g., because an extension is
>         completely private or purely speculative).

I believe that any parameter, even used in presence of bilateral 
agreement between parties should be named to give enough information 
about its contents.  So I propose to remove this recommendation.

4.  Bullet 1 in Section 5:

>     1.  SHOULD provide unlimited registries with well-defined
>         registration procedures.

Maybe "unlimited registry space" or "registries of unlimited size" here?

5.  Appendix A, X*** FTP commands,  I think you could also provide some 
information on further destiny of the commands as an illustration of 
what you claim in Appendix B: X*** were replaced by non-X *** commands 
in RFC 959, and caused interoperability problems requiring 
implementations to support both variant (what they continue to do even 
now, BTW).

Thanks,
Mykyta Yevstifeyev