Re: [jose] POLL(s): header criticality

Casper Biering <cb@peercraft.com> Thu, 07 February 2013 10:36 UTC

Return-Path: <cb@peercraft.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C1821F85D0 for <jose@ietfa.amsl.com>; Thu, 7 Feb 2013 02:36:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 Q5CQ6De23bTv for <jose@ietfa.amsl.com>; Thu, 7 Feb 2013 02:36:45 -0800 (PST)
Received: from mail.netamia.com (mail.netamia.com [83.221.146.12]) by ietfa.amsl.com (Postfix) with ESMTP id EC4EF21F85F0 for <jose@ietf.org>; Thu, 7 Feb 2013 02:36:44 -0800 (PST)
Received: from [10.32.2.1] (unknown [213.173.228.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cb@netamia.com) by mail.netamia.com (Postfix) with ESMTPSA id ED87739828B; Thu, 7 Feb 2013 10:36:41 +0000 (UTC)
Message-ID: <1360233401.21958.3.camel@amber>
From: Casper Biering <cb@peercraft.com>
To: "odonoghue@isoc.org" <odonoghue@isoc.org>
Date: Thu, 07 Feb 2013 11:36:41 +0100
In-Reply-To: <C5B52B5A-528A-4014-831E-ACF60010FE1E@adm.umu.se>
References: <510FCA42.5000704@isoc.org> <C5B52B5A-528A-4014-831E-ACF60010FE1E@adm.umu.se>
Organization: Peercraft
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.4.4 (3.4.4-2.fc17)
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Cc: "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] POLL(s): header criticality
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Feb 2013 10:36:46 -0000

FIRST POLL:  YES
SECOND POLL:  YES
THIRD POLL:  A

-- 
-- Casper


On Thu, 2013-02-07 at 08:04 +0100, Roland Hedberg wrote:
> FIRST POLL:  YES
> SECOND POLL:  YES
> THIRD POLL:  A
> 
> 4 feb 2013 kl. 15:48 skrev Karen O'Donoghue <odonoghue@isoc.org>rg>:
> 
> > Folks,
> > 
> > I am wrestling with how to help drive consensus on the topic of 
> > criticality of headers. For background, please review the current 
> > specification text, the minutes to the Atlanta meeting (IETF85), and the 
> > mailing list (especially the discussion in December with (Subj: Whether 
> > implementations must understand all JOSE header fields)). We need to 
> > come to closure on this issue in order to progress the specifications.
> > 
> > As a tool to gather further information on determining a way forward, 
> > the following polls have been created. Please respond before 11 February 
> > 2013.
> > 
> > Thanks,
> > Karen
> > 
> > *******************
> > FIRST POLL: Should all header fields be critical for implementations to 
> > understand?
> > 
> > YES – All header fields must continue to be understood by 
> > implementations or the input must be rejected.
> > 
> > NO – A means of listing that specific header fields may be safely 
> > ignored should be defined.
> > 
> > ********************
> > SECOND POLL: Should the result of the first poll be "YES", should text 
> > like the following be added? “Implementation Note: The requirement to 
> > understand all header fields is a requirement on the system as a whole – 
> > not on any particular level of library software. For instance, a JOSE 
> > library could process the headers that it understands and then leave the 
> > processing of the rest of them up to the application. For those headers 
> > that the JOSE library didn’t understand, the responsibility for 
> > fulfilling the ‘MUST understand’ requirement for the remaining headers 
> > would then fall to the application.”
> > 
> > YES – Add the text clarifying that the “MUST understand” requirement is 
> > a requirement on the system as a whole – not specifically on JOSE libraries.
> > 
> > NO – Don’t add the clarifying text.
> > 
> > ************************
> > THIRD POLL: Should the result of the first poll be "NO", which syntax 
> > would you prefer for designating the header fields that may be ignored 
> > if not understood?
> > 
> > A – Define a header field that explicitly lists the fields that may be 
> > safely ignored if not understood.
> > 
> > B – Introduce a second header, where implementations must understand all 
> > fields in the first but they may ignore not-understood fields in the second.
> > 
> > C - Other??? (Please specify in detail.)
> > _______________________________________________
> > jose mailing list
> > jose@ietf.org
> > https://www.ietf.org/mailman/listinfo/jose
> 
> -- Roland
> ------------------------------------------------------
> Roland Hedberg
> IT Architect/Senior Researcher
> ICT Services and System Development (ITS) 
> Umeå University 
> SE-901 87 Umeå, Sweden	
> Phone +46 90 786 68 44
> Mobile +46 70 696 68 44 
> www.its.umu.se 
> 
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose