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

Ben Niven-Jenkins <> Tue, 28 June 2011 17:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B42AC11E8107 for <>; Tue, 28 Jun 2011 10:14:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.52
X-Spam-Status: No, score=-103.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GrEJFsErc2+r for <>; Tue, 28 Jun 2011 10:14:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EE03711E80F4 for <>; Tue, 28 Jun 2011 10:14:53 -0700 (PDT)
Received: from ([] by with esmtpa (Exim 4.71) (envelope-from <>) id 1QbbsC-0006dP-PL; Tue, 28 Jun 2011 18:14:53 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ben Niven-Jenkins <>
In-Reply-To: <>
Date: Tue, 28 Jun 2011 18:14:50 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
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: Tue, 28 Jun 2011 17:14:54 -0000


On 27 Jun 2011, at 22:29, Dave CROCKER wrote:
> On 6/27/2011 2:21 PM, Ben Niven-Jenkins wrote:
>> 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?
> It can't be only for documents within the IETF.
> The entire purpose of the X- construct, when we first introduced it in RFC822, was to support /private/ activities.
> It defined a safe haven for that private work, within a naming structure defined by the equivalent of the IETF.  But 'private' means outside the IETF.
> What motivates the current document is that 'safe haven' turns out not to be nearly as important as making it easier to take the private efforts that have become popular and make then standardized, with the minimum transition pain.

That's what I thought based on the initial sections of the document but the wording of the final guidance is such that it wasn't clear what was actually being recommended. I'd suggest changing the language to make it clear to non-IETF regulars that the guidance is wider than just documents produced by the IETF.

It was the use of "produced within the IETF" that got me confused, so maybe drop it and just have "Therefore, this document recommends against the creation of new names with the special "X-" prefix in application protocols"?