Re: [jose] For WG DISCUSSION: #50 - "cty" (content type) should hold a media type

["Manger, James H" <[e-mail]>]

“if the major type is “application” omit the “application/” prefix” is an even simpler rule ;-)


Even if the spec text was “if it doesn’t have a slash in it, add application/ to the front of it” I would be tempted to implement “if it doesn’t have a slash in it (that isn’t after a semicolon), add application/ to the front of it”. That doesn’t break any correct cases. It is merely a little bit lenient in cases where the originator was slightly sloppy by checking the major type but not the parameters (perhaps a parameter was set in a different part of the originator’s code than setting the base media type). But if these slightly sloppy messages interoperate with some recipients, that pressures other recipients to be equally lenient otherwise they lose market share. Hence, I think a dirt-simple rule for originators (always omit “application/”) is a better for the spec.

--
James Manger

From: Mike Jones [mailto:[e-mail]]
Sent: Friday, 4 October 2013 10:34 AM
To: Manger, James H; Jim Schaad; [e-mail]
Subject: RE: [jose] For WG DISCUSSION: #50 - "cty" (content type) should hold a media type


I think that “application/foo;part="1/2"” should be required to retain the “application/” part.  Then the rule can still be the dirt-simple “if it doesn’t have a slash in it, add application/ to the front of it”.



                                                                Cheers,

                                                                -- Mike



-----Original Message-----
From: Manger, James H [mailto:[e-mail]]
Sent: Sunday, September 29, 2013 8:01 PM
To: Jim Schaad; Mike Jones; [e-mail]<mailto:[e-mail]>
Subject: RE: [jose] For WG DISCUSSION: #50 - "cty" (content type) should hold a media type



Media types can have parameters. It is not worth making JOSE a special case by forbidding parameters in "cty" media type values.



As for when a sender omits "application/" and a receiver prepends it...

The “easy” choice for a sender is to drop the prefix when mediaType.startsWith("application/") or when mediaType.type == "application".

The “easy” choice for a receiver is to prepend "application/" when a "cty" value has no ‘/’ character.

These “easy” choices are incompatible when a parameter includes a ‘/’.



My initial suggested text tolerated receivers making the “easy” choice so it couldn’t allow senders to always drop “application/”.

That probably is the wrong way around. It would be better to allow senders to make the “easy” choice and, consequently, require receivers to consider ‘/’ and ‘;’ characters when deciding whether to prepend "application/". It would probably be worth including an example with a ‘/’ in a parameter to help recipients get this right. We may as well make omitting "application/" a MUST (as MUSTs are better than MAYs).



Current proposal:



  To keep messages compact in common situations, a sender MAY omit an

  "application/" prefix of a media type from a "cty" value when no

  other '/' appears in the media type. A recipient reconstructing the

  media type MUST prepend "application/" to a "cty" value that does not

  contain a '/'.



New proposal:



  To keep messages compact in common situations, a sender MUST omit the

  "application/" prefix when the top-level type is "application".

  A recipient reconstructing the media type MUST prepend "application/"

  to a "cty" value that contains no '/' character or no '/' before a ';' character.



  Example: {"cty":"foo;part=\"1/2\""} conveys the media type

  application/foo;part="1/2".



--

James Manger





From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Jim Schaad

Sent: Monday, 30 September 2013 7:34 AM

To: 'Mike Jones'; [e-mail]<mailto:[e-mail]>

Cc: Manger, James H

Subject: Re: [jose] For WG DISCUSSION: #50 - "cty" (content type) should hold a media type



I would prefer going with option 2, however based on the suggested text I got at least one surprise that I was not expecting and want to get confirmed.



It would appear from the text that parameters are expected to be allowed for the content type.  This makes it equivalent to what is allowed by MIME, but I don’t remember it ever being explicitly stated as something to be allowed.



(see below note on use of / as a marker)



Jim





From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Mike Jones

Sent: Wednesday, September 18, 2013 4:05 PM

To: [e-mail]<mailto:[e-mail]>

Cc: James H Manger

Subject: [jose] For WG DISCUSSION: #50 - "cty" (content type) should hold a media type



We discussed issue #50 on Monday’s call and it seems like there are two viable choices before us:



1.  Continue to have “cty” values come from a JOSE registry, while allowing MIME Media Type values to also be used, if desired.

  ADVANTAGES:

    + Keeps values compact

    + Uses case-sensitive value comparison (like all other JOSE parameters), avoiding internationalization issues

    + Already working in production deployments

  DISADVANTAGES:

    - Creates a content type value space distinct from the widely used IANA Media Type Registry (http://www.iana.org/assignments/media-types).

    - Requires a convention to consistently spell media type names so they can be matched case sensitively, when used.

    - Names can come from one of two registries, rather than just one (possibly being disambiguated by the presence of a “/” in the name).



2.  Accept a form of James’ proposal described in http://trac.tools.ietf.org/wg/jose/trac/ticket/50, in which “cty” values are defined to hold MIME Media Type values, also specifying that the “application/” prefix may be omitted for compactness purposes.  (MIME Media Type values are not case sensitive and are limited to ASCII.)  Furthermore, we could keep this from being a breaking change for JWTs by RECOMMENDING that the value “cty”:”JWT” continue to be used for nested JWTs (rather than “application/jwt” or “jwt”, which would break existing deployments).

  ADVANTAGES:

    + Retains the ability to have compact values for application/* media types

    + Uses only the widely used IANA Media Type Registry

    + Can be deployed without breaking changes, provided people use the existing spellings “JWT”, “JWK”, and “JWK-SET” when creating content for those media types

  DISADVANTAGES:

    - Uses case-insensitive value comparison, which can lead to interoperability problems

    - Implementations have to be aware of the need to prefix values not containing a “/” with “application/” to get normal media type names



New text for “cty” under option 2 would look something like this:



4.1.9.  "cty" (Content Type) Header Parameter The cty (content type) header parameter is used to declare the MIME Media Type [IANA.MediaTypes] of the secured content (the payload) in contexts where this is useful to the application. This parameter has no effect upon the JWS processing. Use of this header parameter is OPTIONAL.

Per [RFC 2045], all media type values, subtype values, and parameter names are case-insensitive.  However, parameter values are case-sensitive unless otherwise specified for the specific parameter.

To keep messages compact in common situations, a sender MAY omit an "application/" prefix of a media type from a "cty" value when no other '/' appears in the media type. A recipient reconstructing the media type MUST prepend "application/" to a "cty" value that does not contain a '/'.



[JLS]  I think that this is too restrictive.  It would mean that Foo; separator=”/”

Would not be allowed as there is a slash character, but is not part of the front.  While it is true it makes the test easier, it seems odd that the parameter value should allow for that to be part of the criteria to omit the application text.



As background, see http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-16#section-4.1.9 for the current “cty” text, see http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-16#section-4.1.8 for the related “typ” text, and see http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-16#section-8.2 for the Type Values Registry.



I’m curious what people’s preferences are between the two choices.  I can personally live with either outcome, since both can be deployed without breaking existing deployments.  At this point, it seems to come down to a question of personal taste.  Your thoughts…?



                                                                -- Mike