Re: [apps-discuss] "X-" revisited

Ben Niven-Jenkins <> Mon, 27 June 2011 21:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C186221F8664 for <>; Mon, 27 Jun 2011 14:21:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.56
X-Spam-Status: No, score=-103.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P+GRqK4a45vV for <>; Mon, 27 Jun 2011 14:21:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 58C8D21F865D for <>; Mon, 27 Jun 2011 14:21:47 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpa (Exim 4.71) (envelope-from <>) id 1QbJFa-0002CC-DT; Mon, 27 Jun 2011 22:21:46 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ben Niven-Jenkins <>
In-Reply-To: <>
Date: Mon, 27 Jun 2011 22:21:45 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Peter Saint-Andre <>
X-Mailer: Apple Mail (2.1084)
X-Mailcore-Auth: 9600544
X-Mailcore-Domain: 172912
Cc: "" <>
Subject: Re: [apps-discuss] "X-" revisited
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Jun 2011 21:21:49 -0000


On 27 Jun 2011, at 19:36, Peter Saint-Andre wrote:

> Based on comments received to date, I've published a heavily-revised
> version of the "X-" proposal:
> Further feedback is welcome!

One question. The draft concludes that:

   The foregoing considerations lead to the conclusion that segregating
   non-standard parameters into an "X-" ghetto has few if any benefits,
   and has at least one significant cost in terms of interoperability.
   Therefore, this document recommends against the creation of new names
   with the special "X-" prefix in application protocols produced within
   the IETF.

Is the guidance aimed only at documents produced within the IETF or is the intention that it is more general guidance. For example is it saying that someone defining a private extension that they do not intend to (at least initially) to bring to the IETF should still avoid use of "X-" because forseeing the future is hard and although at definition time they do not intend to standardise it, at some future point that might happen and it could cause the interoperability problems outlined in the draft?