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. J**** > > ** ** > > *From:* Richard Barnes [mailto:[email protected] <javascript:_e({}, 'cvml', > '[email protected]');>] > *Sent:* Friday, February 08, 2013 3:54 PM > *To:* Mike Jones > *Cc:* [email protected] <javascript:_e({}, 'cvml', '[email protected]');> > *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 <[email protected]> > 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. J**** > > **** > > Cheers,*** > * > > -- Mike*** > * > > **** > > *From:* [email protected] [mailto:[email protected]] *On Behalf > Of *Richard Barnes > *Sent:* Friday, February 08, 2013 3:25 PM > *To:* Mike Jones > *Cc:* [email protected] > *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 >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
