Re: [jose] Extensibility (was "Criticality")

As I think you know, there's an open issue in the JOSE working group about whether all header fields must be understood or whether a mechanism should be defined to specify which header fields may be safely ignored if not understood.  John Bradley and Richard Barnes and I have been drafting a note about these choices to the JOSE working group, which I expect should go out any day now.

Per my reply to your note on the OAuth list, the intended meaning is "The use of this header parameter is OPTIONAL."  I'll plan to clarify this in the next version of the specifications.

				Thanks again,
				-- Mike

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Monday, November 26, 2012 3:07 AM
To: jose@ietf.org
Cc: Hannes Tschofenig
Subject: [jose] Extensibility (was "Criticality")

Hi all, 

doing my shepherd writeup of some of the OAuth WG documents I was wondering how the extensibility story for these JSON-based documents should look like given a statement like this:  "Implementations MUST understand the entire contents of the header; otherwise, the JWS MUST be rejected."

Absent a "feature discovery" mechanism I am curious whether any extension is actually possible. 

(Funny enough then all individual parameters then say "This header parameter is OPTIONAL.") 

Since this type of extensibility feature does not seem to a be a new concept I am curious how it has been handled (successfully) in other specifications. 

Ciao
Hannes

PS: I remember that this has been discussed during the meeting but I do not know what the outcome of the discussion was. The meeting minutes do not seem to be available yet.  
_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose