Re: [jose] Header criticality -- hidden consensus?

[Mike Jones <[e-mail]>]

See my answer in http://www.ietf.org/mail-archive/web/jose/current/msg01523.html.  There are several ways to layer solutions and easily meet the intent of the specs.

Out of respect for everyone else's time, who probably don't want to continue reading ongoing minutiae of semantic arguments that don't seem to be converging, maybe we could let this topic go until Monday? ;-)

Enjoy your weekend.

                                                                -- Mike

From: Richard Barnes [mailto:[e-mail]]
Sent: Friday, February 08, 2013 4:17 PM
To: Mike Jones
Cc: [e-mail]
Subject: Re: Header criticality -- hidden consensus?

So your answer is "No".

Conversely, if it DOES reject headers it doesn't recognize, it is also out of compliance, because they might be recognized at a higher layer.

So you're saying that nothing can implement this spec besides a complete system that can never have anything layered on top of it. Of course, you can always layer something on top, so you can actually never implement this spec.

This is what I meant about the "whole system" language bein meaningless. You have to draw a line somewhere.

--Richard






On Friday, February 8, 2013, Mike Jones wrote:
It implements part of them.  That's the truth. :)

From: Richard Barnes [mailto:[e-mail]<javascript:_e(%7b%7d,%20'cvml',%20'[e-mail]');>]
Sent: Friday, February 08, 2013 3:54 PM
To: Mike Jones
Cc: [e-mail]<javascript:_e(%7b%7d,%20'cvml',%20'[e-mail]');>
Subject: Re: [jose] Header criticality -- hidden consensus?



Suppose I write a JOSE library.  It can encrypt and decrypt JWEs, sign and verify JWSs.  It does not check that every header in an object is supported.  Should it be considered to implement the JWE and JWS specs or not?



The answer to that question has to be "Yes" or "No".  No cheating :)



--Richard



On Fri, Feb 8, 2013 at 6:33 PM, Mike Jones <[e-mail]<mailto:[e-mail]>> wrote:

I'm not going to spend a lot of time arguing semantics, but there are lots of ways to meet this requirement in a library and still allow extensions to be used by the system as a whole that are not understood by the library.



One would be to have the caller pass a list of header parameter values to the library informing it to allow the use of particular parameters not understood by the library.  For instance, the list ["notes", "vsf"] might be passed in, informing the library not to reject inputs using the "notes" and "vsf" header parameters, since they are understood by the caller.



A dual of this is to have the library return a list of header parameters present in the input that it did not understand to the caller, letting the caller decide whether the input needs to be rejected.



I don't see the word "library" anywhere in RFC 2199. :)



                                                                Cheers,

                                                                -- Mike



From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Richard Barnes
Sent: Friday, February 08, 2013 3:25 PM
To: Mike Jones
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [jose] Header criticality -- hidden consensus?



Allow me to quote RFC 2119, which defines the requirements terminology for IETF documents:

"

1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the

   definition is an absolute requirement of the specification.

"



By that definition, a system that imp