IETF Logo Mail Archive

Re: [websec] [Ietf-message-headers] HTTP 'Origin' permanent and provisional

Julian Reschke <julian.reschke@gmx.de> Wed, 13 February 2013 20:54 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D940B21F86A8 for <websec@ietfa.amsl.com>; Wed, 13 Feb 2013 12:54:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.266
X-Spam-Level:
X-Spam-Status: No, score=-105.266 tagged_above=-999 required=5 tests=[AWL=-2.667, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4XV1QW0qyz5 for <websec@ietfa.amsl.com>; Wed, 13 Feb 2013 12:54:34 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id BEE7621F86AE for <websec@ietf.org>; Wed, 13 Feb 2013 12:54:25 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.24]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M3xZE-1Uvm072bPm-00rbjq for <websec@ietf.org>; Wed, 13 Feb 2013 21:54:21 +0100
Received: (qmail invoked by alias); 13 Feb 2013 20:54:21 -0000
Received: from p54BB23EA.dip.t-dialin.net (EHLO [192.168.1.102]) [84.187.35.234] by mail.gmx.net (mp024) with SMTP; 13 Feb 2013 21:54:21 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1//u1c9QC3/09hyMt/VD+h6S0jCmxa21cISX4bpwP YD860z/RZ0ZZbg
Message-ID: <511BFD7B.40101@gmx.de>
Date: Wed, 13 Feb 2013 21:54:19 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Yoav Nir <ynir@checkpoint.com>
References: <iljnh8d2cisqlsqvai0662974a0ei71qsn@hive.bjoern.hoehrmann.de> <6.2.5.6.2.20130213113549.0afcce60@resistor.net> <4613980CFC78314ABFD7F85CC3027721119A6FFE@IL-EX10.ad.checkpoint.com> <511BF66F.5070100@gmx.de> <4613980CFC78314ABFD7F85CC3027721119A7198@IL-EX10.ad.checkpoint.com>
In-Reply-To: <4613980CFC78314ABFD7F85CC3027721119A7198@IL-EX10.ad.checkpoint.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: "<websec@ietf.org>" <websec@ietf.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, "<ietf-message-headers@ietf.org>" <ietf-message-headers@ietf.org>
Subject: Re: [websec] [Ietf-message-headers] HTTP 'Origin' permanent and provisional
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Feb 2013 20:54:37 -0000

On 2013-02-13 21:43, Yoav Nir wrote:
>
> On Feb 13, 2013, at 10:24 PM, Julian Reschke <julian.reschke@gmx.de>
>   wrote:
>
>> Well.
>>
>> You make it sound as if it's ok to run two different registries with partly overlapping values. It's not. It's a bug in the way IANA handles this. This is what needs to be fixed.
>>
>> Best regards, Julian
>
> I don't want to turn this into a process debate, but having a provisional registry like this allows you to create interoperable implementations while the document is still at draft. I often see a push to get a document published because we need the IANA assignments for products.

Yes.

> Of course they could still do this with a single registry where provisional entries are somehow marked (with an asterisk?). That way we wouldn't get to a situation where we have double entries.

The key thing being that both registries share the same namespace, so, 
by definition, an entry can not appear in both. If it does, there's a 
process/software problem.

Of course the trivial way to do this right is to implement a *single* 
registry, and to just store a flag for each entry.

Best regards, Julian

v2.9.2 | Report a Bug | By Email