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

FIRST POLL:  YES
SECOND POLL:  YES
THIRD POLL:  no opinion

Am 04.02.2013 15:48, schrieb Karen O'Donoghue:
> 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