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

Pete Resnick <presnick@qualcomm.com> Mon, 07 April 2008 18:14 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 EF7EF28C161; Mon, 7 Apr 2008 11:14:56 -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 0187F28C106 for <ietf@core3.amsl.com>; Mon, 7 Apr 2008 11:14:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 uYVp1wvLa7nm for <ietf@core3.amsl.com>; Mon, 7 Apr 2008 11:14:51 -0700 (PDT)
Received: from episteme-software.com (mail.episteme-software.com [75.145.176.241]) by core3.amsl.com (Postfix) with ESMTP id 5EABB28C1B1 for <ietf@ietf.org>; Mon, 7 Apr 2008 11:14:51 -0700 (PDT)
Received: from [75.145.176.242] (127.0.0.1) by episteme-software.com with ESMTP (EIMS X 3.3.7); Mon, 7 Apr 2008 13:15:02 -0500
Mime-Version: 1.0
X-Sender: resnick@resnick1.qualcomm.com
Message-Id: <p06250119c4201006af1b@[75.145.176.242]>
In-Reply-To: <8BB8410A1437A8973C333DCE@p3.JCK.COM>
References: <20080403231146.5F0853A683E@core3.amsl.com> <47F57508.3040107@gmail.com> <ft57m4$csu$1@ger.gmane.org> <8BB8410A1437A8973C333DCE@p3.JCK.COM>
User-Agent: Eudora 6.2.5b1(Macintosh)
Date: Mon, 07 Apr 2008 11:14:54 -0700
To: John C Klensin <john-ietf@jck.com>
From: Pete Resnick <presnick@qualcomm.com>
Subject: Re: Last Call: draft-resnick-2822upd (Internet Message Format) toDraft Standard
Cc: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>, ietf@ietf.org
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

Coming to consensus on this is going to be messy, as it was in DRUMS, 
which is what landed us with no comment in the document. To wit:

On 4/4/08 at 5:47 PM -0400, John C Klensin wrote:

>There are two ways to interpret the "X-" and I think they yield 
>different answers about what should be done.  
>
>If they are seen as experimental, we promptly run into the problem 
>that, if I recall, caused DRUMS to remove the text: If the 
>experiment succeeds, it is hard to get rid of the "X-" part. If it 
>doesn't succeed, then the header is likely to vanish with little 
>trace whether it contains "X-" or not. And one clearly, at least in 
>the retrospect of the last many years, wants to have experimental 
>headers registered (presumably in the 3864 registry) to reduce the 
>odds of header names being reused for conflicting purposes.

I think on this point, folks in DRUMS agreed: If it's experimental 
(in the sense that it is hoped that *this* field name will eventually 
be interoperable), we *don't* want it to have an "X-". We want it 
registered in the provisional registry. And for this, the 
"optional-field" syntax in 2822[upd], which is what 822 called 
"extension-field", is exactly what you want.

>On the other hand, they can be seen as "private-use between parties 
>who have adequately identified each other and therefore know what 
>they mean". For a private-use header, there is no requirement to 
>register the thing externally because, once one registers (and 
>ideally describes) them, they are no longer private.

But this is the real problem that DRUMS got stuck on: It was argued 
by opponents of "X-" fields that "private-use" fields (what 822 
referred to as "user-defined-filed") are never really private; they 
invariably leak onto the net writ large. And once that happens, 
restrictions on the registration or other public description of those 
fields becomes a silly state: I can't register or document it because 
I named it with an "X-", but it's leaked out onto the net and lots of 
people are using it, so it needs documentation. "X-" fields (in the 
private-use sense) were supposed to mean "You will be able to use 
this name without fear of conflicting with another field of the same 
name out on the Internet." In practice, that's simply false.

There are those of us who, during DRUMS, concluded that private-use 
is not only a broken concept, but that 2822 ought to have said 
"trying to use 'X-' fields to indicate private-use is a bad idea 
because it won't work and you shouldn't do it." We could not garner 
consensus for such text.

So, in all honesty, I don't think the problem is because we 
misunderstood the difference between "experimental" and 
"private-use"; it's because (some people claim) that private-use is a 
bogus concept, but we couldn't get consensus to say so.

>(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.

>(2) Treat <optional-field> as consisting of either "X-headers" or 
>"Non-X-headers" (probably there are better names).

That's what it does now.

>(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.

>(4) Make it clear that the distinction between X-headers and 
>Non-X-headers is guidance, not firm rules.  Should an X-header 
>become widely deployed (for a definition of "widely" I don't think 
>we need to pin down), then it is perfectly reasonable to treat it as 
>an ordinary (non-X) header, register it, and even potentially write 
>up RFCs describing it.  We just recommend against getting into that 
>situation if possible.

But if we say that, then one has to ask oneself what the use of "X-" 
fields is in the first place. If you can't depend on any field that 
starts with an "X-" being of private use, then the "X-" hasn't bought 
you anything. In which case, it would be better to include text 
saying, "Since 'X-' field names were once used to mean 'private-use' 
only, and since no field can be guaranteed to ever be private-use 
only, we discourage the use of any field starting with 'X-' so as not 
to confuse folks into thinking it's private-use. It may not be."

I don't think we can get consensus on such text.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf