[jose] POLL(s): header criticality

Karen O'Donoghue <odonoghue@isoc.org> Mon, 04 February 2013 14:48 UTC

Return-Path: <odonoghue@isoc.org>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 55CEC21F8461 for <jose@ietfa.amsl.com>; Mon, 4 Feb 2013 06:48:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.265
X-Spam-Status: No, score=-103.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Qu80IUTHfYfJ for <jose@ietfa.amsl.com>; Mon, 4 Feb 2013 06:48:30 -0800 (PST)
Received: from smtp136.dfw.emailsrvr.com (smtp136.dfw.emailsrvr.com []) by ietfa.amsl.com (Postfix) with ESMTP id D10CE21F8460 for <jose@ietf.org>; Mon, 4 Feb 2013 06:48:30 -0800 (PST)
Received: from localhost (localhost.localdomain []) by smtp23.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 6206D2F8678 for <jose@ietf.org>; Mon, 4 Feb 2013 09:48:30 -0500 (EST)
X-Virus-Scanned: OK
Received: by smtp23.relay.dfw1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id 3CEDC2F864A for <jose@ietf.org>; Mon, 4 Feb 2013 09:48:30 -0500 (EST)
Message-ID: <510FCA42.5000704@isoc.org>
Date: Mon, 04 Feb 2013 09:48:34 -0500
From: Karen O'Donoghue <odonoghue@isoc.org>
Organization: ISOC
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: jose@ietf.org
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: [jose] POLL(s): header criticality
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: odonoghue@isoc.org
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: Mon, 04 Feb 2013 14:48:31 -0000


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 


FIRST POLL: Should all header fields be critical for implementations to 

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