The application/cms Media Type
RFC 7193

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

(Stephen Farrell; former steering group member) Yes

Yes ( for -07)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Barry Leiba; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Benoît Claise; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Brian Haberman; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Joel Jaeggli; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Martin Stiemerling; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Pete Resnick; former steering group member) No Objection

No Objection (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.

(Spencer Dawkins; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Stewart Bryant; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Ted Lemon; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Sean Turner; former steering group member) Recuse

Recuse ( for -07)
No email
send info