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:[email protected]]
Sent: Friday, February 08, 2013 4:17 PM
To: Mike Jones
Cc: [email protected]
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:[email protected]<javascript:_e(%7b%7d,%20'cvml',%20'[email protected]');>]
Sent: Friday, February 08, 2013 3:54 PM
To: Mike Jones
Cc: [email protected]<javascript:_e(%7b%7d,%20'cvml',%20'[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]<mailto:[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. :)
Cheers,
-- Mike
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Richard Barnes
Sent: Friday, February 08, 2013 3:25 PM
To: Mike Jones
Cc: [email protected]<mailto:[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
