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

Dzonatas Sol <> Tue, 28 June 2011 19:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA50A11E8118 for <>; Tue, 28 Jun 2011 12:22:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.892
X-Spam-Status: No, score=-5.892 tagged_above=-999 required=5 tests=[AWL=-2.293, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5f89Ix5DEn1E for <>; Tue, 28 Jun 2011 12:22:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 42DB611E8100 for <>; Tue, 28 Jun 2011 12:22:51 -0700 (PDT)
Received: by pwj5 with SMTP id 5so441998pwj.31 for <>; Tue, 28 Jun 2011 12:22:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=sYtsntMzQY2SWivDHpLw7SaIlQIqaOn5njiHKEt1BBU=; b=YKTYXTDkGlJokwttxAB3TQqGcX8rpHlGA7hDXMiWFI/7RtFSzDkZPbx7CLUbz1nkjX o1RY0EhgDN8QMeTJ3kl2VdPYtQpCxsdmIMuI777FdK/2X6nAp665SuLcjMjIf+9QoYdc 8ZzK/Sa5vpiKAeEeYX9uzmhGmcuL4qH5CgrY4=
Received: by with SMTP id l8mr1554770wfa.12.1309288970939; Tue, 28 Jun 2011 12:22:50 -0700 (PDT)
Received: from [] ([]) by with ESMTPS id e6sm326828pbm.87.2011. (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Jun 2011 12:22:49 -0700 (PDT)
Message-ID: <>
Date: Tue, 28 Jun 2011 12:22:12 -0700
From: Dzonatas Sol <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110505 Icedove/3.0.11
MIME-Version: 1.0
References: <><><> <> <9CAEFAF597924B478936B2FB7B277884@upstairs>
In-Reply-To: <9CAEFAF597924B478936B2FB7B277884@upstairs>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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 19:22:52 -0000

The only reason I have seen the use "X-" other than experimental were 
for non-standard distributions (past transition from USENET), except for 
no-delay or non-blocking I/O (i.e. "X-Non-Blocking:..." which helps 
denote not-critical).

Some servers may want to avoid botnets and catch headers like 
"X-Trends:" or other cookie monsters. On that note, maybe the "X-" 
headers are less harmful if some rules like the use of atomic names if 
they are used at all, like "X-Oxygen:".

The atomic names are well-known (universal, translatable), so servers 
then know what "X-" headers to prune, especially as an optimization 

On 06/28/2011 10:27 AM, Al Costanzo wrote:
> 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
> _______________________________________________
> apps-discuss mailing list

--- ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant