Deprecating the X- Prefix and Similar Constructs in Application Protocols
draft-ietf-appsawg-xdash-04

The information below is for an old version of the document
Document Type Active Internet-Draft (appsawg WG)
Last updated 2012-03-15 (latest revision 2012-03-12)
Replaces draft-saintandre-xdash
Stream IETF
Intended RFC status Best Current Practice
Formats plain text pdf html
Stream WG state WG Document
Consensus Unknown
Document shepherd Alexey Melnikov
Shepherd write-up Show (last changed 2012-02-22)
IESG IESG state IESG Evaluation::Revised I-D Needed
Telechat date
Needs 4 more YES or NO OBJECTION positions to pass.
Responsible AD Pete Resnick
Send notices to appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-xdash@tools.ietf.org
APPSAWG                                                   P. Saint-Andre
Internet-Draft                                       Cisco Systems, Inc.
Intended status: BCP                                          D. Crocker
Expires: September 13, 2012                  Brandenburg InternetWorking
                                                           M. Nottingham
                                                               Rackspace
                                                          March 12, 2012

    Deprecating the X- Prefix and Similar Constructs in Application
                               Protocols
                      draft-ietf-appsawg-xdash-04

Abstract

   Historically, designers and implementers of application protocols
   have often distinguished between "standard" and "non-standard"
   parameters by prefixing the names of "non-standard" parameters with
   the string "X-" or similar constructs.  In practice, that convention
   causes more problems than it solves.  Therefore, this document
   deprecates the convention for the names of newly-defined textual
   parameters in application protocols.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 13, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of

Saint-Andre, et al.    Expires September 13, 2012               [Page 1]
Internet-Draft               Deprecating X-                   March 2012

   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Recommendations for Implementers of Application Protocols  . .  3
   3.  Recommendations for Creators of New Parameters . . . . . . . .  4
   4.  Recommendations for Protocol Designers . . . . . . . . . . . .  4
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  4
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  5
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  5
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  5
     8.2.  Informative References . . . . . . . . . . . . . . . . . .  5
   Appendix A.  Background  . . . . . . . . . . . . . . . . . . . . .  8
   Appendix B.  Analysis  . . . . . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12

Saint-Andre, et al.    Expires September 13, 2012               [Page 2]
Internet-Draft               Deprecating X-                   March 2012

1.  Introduction

   Many application protocols use parameters with textual names to
   identify data (media types, header fields in Internet mail messages
   and HTTP requests, vCard parameters and properties, etc.).
   Historically, designers and implementers of application protocols
   have often distinguished between "standard" and "non-standard"
   parameters by prefixing the names of "non-standard" parameters with
   the string "X-" or similar constructs (e.g., "x."), where the "X" is
   commonly understood to stand for "eXperimental" or "eXtension".  That
   is, instead of just identifying the data, the name also embedded the
   status of the name as "non-standard" into the name itself.

   Although in theory the "X-" convention was a good way to avoid
   collisions (and attendant interoperability problems) between standard
Show full document text