Re: [core-parameters] Core content-format number allocation

HI Klaus,

Thanks for the quick reaction, and thanks for pointing out some existing 
other smime types.
I did a search in RFC 7030, and came up with other necessary smime 
types.

Below the table as required for est-coap draft: (I will change the draft 
accordingly)

- application/pkcs7-mime; smime-type=“server-generated-key”; Encoding = 
"binary"; ID = TBD1; Reference = RFC5751, RFC7030
- application/pkcs7-mime; smime-type=“certs-only”; Encoding = "binary"; 
ID = TBD2; Reference = RFC5751
- application/pkcs7-mime; smime-type=“CMC-request”; Encoding = "binary"; 
ID = TBD3; Reference = RFC5751, RFC5273
- application/pkcs8; smime-type = ---; Encoding = "binary"; ID = TBD4; 
Reference = RFC5958
- application/csrattrs; smime-type = ---; Encoding = "binary"; ID = 
TBD5; Reference = RFC7030
- application/pkcs10; smime-type = ---; Encoding = "binary"; ID = TBD6; 
Reference = RFC5967

I expect the Encoding is orthogonal to the media type and smime type 
specification.

Many thanks,

peter

Klaus Hartke schreef op 2018-05-25 09:48:
> Hi Peter,
> 
> I see you’re requesting Content-Format IDs for the following
> existing media types:
> 
> - application/pkcs7-mime
> - application/pkcs8
> - application/csrattrs
> - application/pkcs10
> 
> A Content-Format is the combination of a media type and a content
> coding. Please specify the content coding(s) you want to use with each
> media type. The possible set of content codings can be found at
> https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding
> 
> Please format your request as a table that looks like Table 9 in
> https://tools.ietf.org/html/rfc7252#section-12.3 (one row for each
> combination of a media type and a content coding)
> 
> It seems “application/pkcs7-mime“ actually does define a media
> type parameter, “smime-type ”. RFC 5751 says:
> 
>    Because there are several types of application/pkcs7-mime objects,
> a
>    sending agent SHOULD do as much as possible to help a receiving
> agent
>    know about the contents of the object without forcing the receiving
>    agent to decode the ASN.1 for the object.  The Content-Type header
>    field of all application/pkcs7-mime objects SHOULD include the
>    optional "smime-type" parameter, as described in the following
>    sections.
> 
> So it seems the parameter is more or less required. Do you want to
> register a Content-Format ID for each defined smime-type value? Then
> the list of media types (that need to be paired with a content coding)
> looks like this:
> 
> - application/pkcs7-mime; smime-type=“enveloped-data”
> - application/pkcs7-mime; smime-type=“signed-data”
> - application/pkcs7-mime; smime-type=“certs-only”
> - application/pkcs7-mime; smime-type=“compressed-data”
> - application/pkcs8
> - application/csrattrs
> - application/pkcs10
> 
> Klaus
> 
> On Fri 25. May 2018 at 09:27, peter van der Stok <stokcons@xs4all.nl>
> wrote:
> 
>> Dear core parameter experts,
>> 
>> In draft-ietf-ace-coap-est we want to allocate content format
>> numbers to
>> 4 already existing media formats.
>> LWM2M people are implementing the est-coaps specification and want
>> to
>> deploy it as quickly as possible.
>> Therefore, they need to know the allocated numbers to write into
>> their
>> code.
>> An early allocation before publication of the draft as RFC will be
>> appreciated.
>> 
>> Below the IANA text from the draft, using TBD1 - TBD4 as allocated
>> numbers.
>> 
>> Many thanks,
>> 
>> peter
>> 
>> 
> __________________________________________________________________________________________________________
>> 
>> 8.1.  Content-Format registry
>> 
>> Additions to the sub-registry "CoAP Content-Formats", within the
>> "CoRE Parameters" registry are needed for the below media types.
>> These can be registered either in the Expert Review range
>> (0-255) or
>> IETF Review range (256-9999).
>> 
>> 1.
>> 
>> *  application/pkcs7-mime
>> *  Type name: application
>> *  Subtype name: pkcs7-mime
>> *  ID: TBD1
>> *  Required parameters: None
>> *  Optional parameters: None
>> *  Encoding considerations: binary
>> *  Security considerations: As defined in this specification
>> *  Published specification: [RFC5751]
>> *  Applications that use this media type: EST
>> 
>> 2.
>> 
>> *  application/pkcs8
>> *  Type name: application
>> *  Subtype name: pkcs8
>> *  ID: TBD2
>> *  Required parameters: None
>> *  Optional parameters: None
>> *  Encoding considerations: binary
>> *  Security considerations: As defined in this specification
>> *  Published specification: [RFC5958]
>> *  Applications that use this media type: EST
>> 
>> 3.
>> 
>> *  application/csrattrs
>> *  Type name: application
>> *  Subtype name: csrattrs
>> *  ID: TBD3
>> *  Required parameters: None
>> *  Optional parameters: None
>> *  Encoding considerations: binary
>> *  Security considerations: As defined in this specification
>> *  Published specification: [RFC7030]
>> *  Applications that use this media type: EST
>> 
>> 4.
>> 
>> *  application/pkcs10
>> *  Type name: application
>> *  Subtype name: pkcs10
>> *  ID: TBD4
>> *  Required parameters: None
>> *  Optional parameters: None
>> *  Encoding considerations: binar
>> *  Security considerations: As defined in this specification
>> *  Published specification: [RFC5967]
>> *  Applications that use this media type: EST
>> 
>> 
> ___________________________________________________________________________________________
>> 
>> --
>> Peter van der Stok
>> vanderstok consultancy
>> mailto: consultancy@vanderstok.org
>> www: www.vanderstok.org [1]
>> tel NL: +31(0)492474673     F: +33(0)966015248
>> 
>> _______________________________________________
>> core-parameters mailing list
>> core-parameters@ietf.org
>> https://www.ietf.org/mailman/listinfo/core-parameters
> 
> 
> Links:
> ------
> [1] http://www.vanderstok.org