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

Dave CROCKER <> Mon, 27 June 2011 21:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A72AD11E8144 for <>; Mon, 27 Jun 2011 14:29:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4R5WN9YuJRuj for <>; Mon, 27 Jun 2011 14:29:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A430511E807F for <>; Mon, 27 Jun 2011 14:29:12 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id p5RLT6Qr019448 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 27 Jun 2011 14:29:12 -0700
Message-ID: <>
Date: Mon, 27 Jun 2011 14:29:07 -0700
From: Dave CROCKER <>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Ben Niven-Jenkins <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 ( []); Mon, 27 Jun 2011 14:29:12 -0700 (PDT)
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:29:13 -0000

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.



   Dave Crocker
   Brandenburg InternetWorking