The application/cms Media Type
draft-turner-application-cms-media-type-08
Yes
No Objection
Recuse
Note: This ballot was opened for revision 07 and is now closed.
(Stephen Farrell; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
(Brian Haberman; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
I'm not a fan of MUSTs and SHOULDs in media type registrations; if they are really necessary, I suspect a protocol document is needed rather than hiding them in the registration. But the two paragraphs with occurrences of these things give me pause:
id-data [RFC5652] MUST NOT be used if it is the only inner content
listed and the data is MIME content; when id-data is used to
encapsulate MIME, the media type application/pkcs7-mime media type
defined in [RFC5751] SHOULD be used.
Really? What harm will come of me or the rest of the Internet if I use id-data in one of these things? Color me suspicious that there is an interoperability problem here.
When processing a SignedData around any of the inner content type
the [RFC5652] validation rules MUST be used. The PKCS #7 [RFC2315]
validation rules MUST NOT be used.
Would someone really consider using 2315 validation rules? Isn't it enough that 5652 is standards track and 2315 is Informational (and old)?
The Content-Type header field of all application/cms objects SHOULD
include the optional "encapsulatingContent" and "innerContent"
parameters.
It might be *nice* to use encapsulatingContent and innerContent, but I'm not sure why you SHOULD. I think it would be sufficient to explain in the definitions of those parameters *why* they are useful and then you wouldn't need to say this.
(Spencer Dawkins; former steering group member) No Objection
(Stewart Bryant; former steering group member) No Objection
(Ted Lemon; former steering group member) No Objection
(Sean Turner; former steering group member) Recuse