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

"Al Costanzo" <> Tue, 28 June 2011 17:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C65821F86C8 for <>; Tue, 28 Jun 2011 10:28:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P5ExhFdBXA-e for <>; Tue, 28 Jun 2011 10:28:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3878B21F86C1 for <>; Tue, 28 Jun 2011 10:28:28 -0700 (PDT)
Received: from upstairs ( []) by with SMTP; Tue, 28 Jun 2011 13:27:54 -0400
Message-ID: <9CAEFAF597924B478936B2FB7B277884@upstairs>
From: "Al Costanzo" <>
To: "Ben Niven-Jenkins" <>, <>
References: <><><> <>
Date: Tue, 28 Jun 2011 13:27:52 -0400
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
Subject: Re: [apps-discuss] "X-" revisited
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Al Costanzo <>
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:28:29 -0000

Originally, if I remember, this "X-" was used by vendors, for specific 
headers that they needed and wanted to be "ignored or not used by other 
until possibly they were done with the design and implementation.

Was it not?

Al Costanzo
----- Original Message ----- 
From: "Ben Niven-Jenkins" <>
To: <>
Cc: <>
Sent: Tuesday, June 28, 2011 1:14 PM
Subject: Re: [apps-discuss] "X-" revisited

> Dave,
> 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"?
> Ben
> _______________________________________________
> apps-discuss mailing list