Re: Last Call: draft-resnick-2822upd (Internet Message Format) toDraft Standard

Dave Crocker <dhc2@dcrocker.net> Mon, 07 April 2008 18:34 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F44D3A6A71; Mon, 7 Apr 2008 11:34:16 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B5F53A6A71 for <ietf@core3.amsl.com>; Mon, 7 Apr 2008 11:34:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.963
X-Spam-Level:
X-Spam-Status: No, score=-1.963 tagged_above=-999 required=5 tests=[AWL=0.636, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMpo43SR9kTG for <ietf@core3.amsl.com>; Mon, 7 Apr 2008 11:34:14 -0700 (PDT)
Received: from sbh17.songbird.com (unknown [IPv6:2001:470:1:76:0:ffff:4834:7146]) by core3.amsl.com (Postfix) with ESMTP id 206E73A6A31 for <ietf@ietf.org>; Mon, 7 Apr 2008 11:34:13 -0700 (PDT)
Received: from [192.168.0.4] (adsl-67-127-190-96.dsl.pltn13.pacbell.net [67.127.190.96]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id m37IYL6P001304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf@ietf.org>; Mon, 7 Apr 2008 11:34:26 -0700
Message-ID: <47FA692D.5030307@dcrocker.net>
Date: Mon, 07 Apr 2008 11:34:21 -0700
From: Dave Crocker <dhc2@dcrocker.net>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: Last Call: draft-resnick-2822upd (Internet Message Format) toDraft Standard
References: <20080403231146.5F0853A683E@core3.amsl.com> <47F57508.3040107@gmail.com> <ft57m4$csu$1@ger.gmane.org> <8BB8410A1437A8973C333DCE@p3.JCK.COM> <p06250119c4201006af1b@[75.145.176.242]>
In-Reply-To: <p06250119c4201006af1b@[75.145.176.242]>
X-Virus-Scanned: ClamAV 0.92/6649/Mon Apr 7 09:09:17 2008 on sbh17.songbird.com
X-Virus-Status: Clean
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 07 Apr 2008 11:34:26 -0700 (PDT)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


Pete Resnick wrote:
  >> (1) Partially restore the 822 text, stressing "private use", rather
>> than "experiental".
> 
> I don't think we'll be able to do this; see (3) below.
...
>> (3) Encourage X-headers for strictly private use, i.e., they SHOULD 
>> NOT be used in any context in which interchange or communication 
>> about independent systems is anticipated and therefore SHOULD NOT be 
>> registered under 3683.
> 
> I think this is DOA. There are many folks (myself included) who think 
> this should not be encouraged in any way, shape, or form.


Folks,

One of the lessons of the community's 30+ years of protocol work is that 
specification details which are actually usage guidance, rather than concrete 
interoperability details, often have little impact on a global community.  The 
community formulates its own preferences.

When X- as original proposed, I thought it was marvelously clever.  I still do.

But it doesn't work.

While it does protect a privately-developed header field label from being 
preempted by a standards process, it creates a much more serious problem of 
moving from private-use to public standards and having to (try to) re-label the 
field.  This is a highly disruptive impact./

In other words, if the model is true that existing practices get standardized -- 
and in this realm they often are, I think -- then we need to design things to 
make the transition from private-to-public be comfortable.  Defining a 
private-use naming space runs counter to that goal.

Valuable lesson.  We should learn it.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf