Re: [Ietf-message-headers] [W3C BPWG] HTTP header fields X-* and normal ones / request for advice

SM <> Tue, 27 January 2009 22:40 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 547183A6B09; Tue, 27 Jan 2009 14:40:58 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B73C3A6B09 for <>; Tue, 27 Jan 2009 14:40:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uPTB9eyfse6x for <>; Tue, 27 Jan 2009 14:40:55 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6E0AA3A69C1 for <>; Tue, 27 Jan 2009 14:40:55 -0800 (PST)
Received: from ([]) (authenticated bits=0) by (8.14.4.Alpha0/8.14.4.Alpha0) with ESMTP id n0RMeRTT005935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <>; Tue, 27 Jan 2009 14:40:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail; t=1233096036; x=1233182436; bh=ei1Vty3UyClMrter3Pn+aksqxisHuvHI69GO4KMDI3A=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=GSFsMye4yOyTuI2QiLUunq7fV0CEwqMF9p8xLtGAqrGeJ0Zj0S3M5VNDrmGXmtdrF L8YVuAGk6HOiCW1cr/6dfxdUuUSMtnGhCmW8LGKgzAmV16kJxWukcgRF6wRReV9elM vFv3Rm5+Gftrex9L5N1LYJiph3kpfPCuKCXqg8II=
DomainKey-Signature: a=rsa-sha1; s=mail;; c=simple; q=dns; b=xJ7WWuaLHev0KnNUqoZvjnPmnaXuwMrBtfC0KUHmuScD7slLHsE6cppa1hhMZpEft PMGxLvgpeHWuTks7jO+vX3nTWkengSEmBccJccYJzi0Gf7m9BpSbHjhK6/MzvOiIrU1 ynJBWkD2se/RgOXGErngl9Ix1pC4pn7FmB2NYWc=
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Tue, 27 Jan 2009 14:40:01 -0800
From: SM <>
In-Reply-To: <000001c97fbf$f4de4be0$d29aca3e@AREPPIM002>
References: <000001c97fbf$f4de4be0$d29aca3e@AREPPIM002>
Mime-Version: 1.0
Subject: Re: [Ietf-message-headers] [W3C BPWG] HTTP header fields X-* and normal ones / request for advice
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion list for header fields used in Internet messaging applications." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

At 06:11 26-01-2009, wrote:
>We would be grateful to get advice from the IETF with respect to handling
>coexistence of X- and non-X- prefixed fields, and the phasing out of
>3.a: What is the IETF policy regarding the registration of X- prefixed

The following is personal opinion and not advice about IETF policy 
.  Refer to BCP 90 for the registration procedures.

>3.b: What is the IETF policy regarding the promotion of X- prefixed header
>fields (registered or not) to non-X-prefixed, standard registered ones?

X- prefixed header fields are generally not registered.  For the 
example you mentioned, the header field was registered with 
"depreciated" as the status.

>3.c: What is the IETF policy regarding the simultaneous deployment and
>utilization of two sets of header fields, which have the same semantics, one
>comprising X- prefixed and the other equivalent non-prefixed fields?

You can depreciate the existing one in favor of the one defined in your RFC.

>3.d: What is the IETF policy regarding the deprecation and discontinuance of
>HTTP header fields?

See Section 4.5 of BCP 90 about Change Control.  RFC 4229 defines the 
initial contents of a permanent IANA registry for HTTP header fields.


Ietf-message-headers mailing list