Agree with Juergen, these artifacts are all CMS signed-data content Type, so COSE signed CBOR, JWS signed JSON is more nature to me.
-Qin -----邮件原件----- 发件人: Iotops [mailto:[email protected]] 代表 Juergen Schoenwaelder 发送时间: 2020年11月4日 4:24 收件人: Michael Richardson <[email protected]> 抄送: [email protected]; [email protected]; [email protected] 主题: Re: [Iotops] [netconf] what to call different RFC8366 format artifacts On Tue, Nov 03, 2020 at 12:05:35PM -0500, Michael Richardson wrote: > > So to bikeshed the whole thing, please comment on preference in naming: > > 1) RFC8366: CMS-signed-JSON vs JSON-in-CMS. > 2) CV: CMS-signed-CBOR vs CBOR-in-CMS. > 3) CV: COSE-signed-CBOR vs CBOR-in-COSE. > 4) future ID: JWS-signed-JSON vs JSON-in-JOSE. > > I note that for some of these "signed" is redundant. > We do not have COSE-signed-JSON, or JWS-signed-CBOR. > > Which feels more natural to you? > For me, all the $foo-signed-$bar expansions make sense and they stress the signature aspect: CMS-signed-JSON = Cryptographic Message Syntax signed JavaScript Object Notation CMS-signed-CBOR = Cryptographic Message Syntax signed Concise Binary Object Representation COSE-signed-CBOR = CBOR Object Signing and Encryption signed Concise Binary Object Representation JWS-signed-JSON = JSON Web Signature signed JavaScript Object Notation The $foo-in-$bar alternative somehow stresses containment but I assume the primary reason for using CMS / COSE / JWS is for signatures, not for containment. /js (German, in case that matters.) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> -- Iotops mailing list [email protected] https://www.ietf.org/mailman/listinfo/iotops _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
