The application/cms Media Type
RFC 7193

Note: This ballot was opened for revision 07 and is now closed.

(Stephen Farrell) Yes

(Jari Arkko) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Ted Lemon) No Objection

(Pete Resnick) No Objection

Comment (2014-01-08 for -07)
No email
send info
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.

(Martin Stiemerling) No Objection

(Sean Turner) Recuse