FIRST POLL: YES, but only for top level keys. SECOND POLL: YES THIRD POLL: C, +1 for defining a ignorable parameters container key as Dick proposed.
On 2013/02/07, at 2:40, Dick Hardt <[email protected]> wrote: > 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 _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
