I misunderstood the Third Poll options.
I was thinking that all properties to be ignored would be a property of the
header object. ie. all ignorable properties are sub property of a "ignorable"
property.
eg. all "ign" properties can be ignored
{ "alg": "ES256"
, "ign":
{ "notes":"this property can be ignored" }
}
So I am voting C for the third poll, a different option.
btw: I continue to be surprised that we are using JSON and only doing
name/value pairs.
-- Dick
On Feb 6, 2013, at 9:03 AM, Dick Hardt <[email protected]> wrote:
> FIRST POLL: Yes
>
> SECOND POLL: YES
>
> THIRD POLL: B
>
> On Feb 4, 2013, at 6:48 AM, Karen O'Donoghue <[email protected]> wrote:
>
>> 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
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/jose
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
