[media-types] Re: Media Type Registration Review Request for draft-ietf-scitt-architecture

Hi Amaury,


Registrations below seem reasonable, just a few small comments below:


On 20/06/2025 15:44, Amaury Chamayou wrote:
> Hello,
>
> I would like to request a review of the registration request in 
> draft-ietf-scitt-architecture 
> (https://ietf-wg-scitt.github.io/draft-ietf-scitt-architecture/draft-ietf-scitt-architecture.html#name-media-type-application-scit). 
> Section content is duplicated below:
>
> 10.2.  Media Type application/scitt-statement+cose Registration   IANA 
> is requested to add the following Media-Type to the "Media   Types" 
> registry [IANA.media-types].       
> +======================+======================+============+       | 
> Name                 | Template             | Reference  |       
> +======================+======================+============+       | 
> scitt-statement+cose | application/scitt-   | Section 6  |       |     
>                  | statement+cose       | of RFCthis |       
> +----------------------+----------------------+------------+
The table says "application/*scitt-*statement+cose", but the 
registration template below is using "application/statement+cose". So 
which one is correct?
>         Table 1: SCITT Signed Statement Media Type Registration   Type 
> name:  application   Subtype name:  statement+cose   Required 
> parameters:  n/a   Optional parameters:  n/a   Encoding 
> considerations:  binary (CBOR data item)   Security considerations: 
>  Section 9 of RFCthis
Let me think a bit more about this, I think you can do better than what 
in Section 9. (But it is a good start!). I will send a separate email on 
this.
>   Interoperability considerations:  none   Published specification: 
>  RFCthis   Applications that use this media type:  Used to provide an 
>      identifiable and non-repudiable Statement about an Artifact 
> signed      by an Issuer.   Fragment identifier considerations:  n/a   
> Additional information:  Deprecated alias names for this type:  N/A   
>                          Magic number(s):  N/A                         
>    File extension(s):  .scitt                            Macintosh 
> file type code(s):  N/A   Person and email address to contact for 
> further information: [email protected]
IESG might object to that, as they are not necessarily experts on SCITT. 
This should probably be the SCITT WG mailing list address.
>   Intended usage:  COMMON   Restrictions on usage:  none   
> Author/Change controller:  IETF
> 10.3.  Media Type application/scitt-receipt+cose Registration   
> +====================+================================+============+   
> | Name               | Template                       | Reference  |   
> +====================+================================+============+   
> | scitt-receipt+cose | application/scitt-receipt+cose | Section 7  |   
> |                    |                                | of RFCthis |   
> +--------------------+--------------------------------+------------+   
>            Table 2: SCITT Receipt Media Type Registration   Type name: 
>  application   Subtype name:  receipt+cose
Should it be "scitt-receipt+cose" to match the table above?
>   Required parameters:  n/a   Optional parameters:  n/a   Encoding 
> considerations:  binary (CBOR data item)   Security considerations: 
>  Section 9 of RFCthis   Interoperability considerations:  none   
> Published specification:  RFCthis   Applications that use this media 
> type:  Used to establish or verify      transparency over Statements. 
>  Typically emitted by a Transparency      Service, for the benefit of 
> Relying Parties wanting to ensure Non-      equivocation over all or 
> part of a Statement Sequence.   Fragment identifier considerations: 
>  n/a   Additional information:  Deprecated alias names for this type: 
>  N/A                            Magic number(s):  N/A                 
>            File extension(s):  .receipt                           
>  Macintosh file type code(s):  N/A   Person and email address to 
> contact for further information: [email protected]
As above, this should probably be the SCITT WG mailing list address.
>   Intended usage:  COMMON   Restrictions on usage:  none   
> Author/Change controller:  IETF
> Along with the corresponding Content-Format registrations:
> 10.4.  CoAP Content-Format Registrations   IANA is requested to 
> register the following Content-Format numbers in   the "CoAP 
> Content-Formats" sub-registry, within the "Constrained   RESTful 
> Environments (CoRE) Parameters" Registry   [IANA.core-parameters] in 
> the 0-255 Range:
>        +======================+================+=====+===========+     
>    | Content-Type         | Content Coding | ID  | Reference |       
>  +======================+================+=====+===========+        | 
> application/scitt-   | -              | 103 | RFCthis   |        | 
> statement+cose       |                |     |           |       
>  +----------------------+----------------+-----+-----------+        | 
> application/scitt-   | -              | 104 | RFCthis   |        | 
> receipt+cose         |                |     |           |       
>  +----------------------+----------------+-----+-----------+
>
> Could you please review?
>
> Thank you,
> Amaury

_______________________________________________
media-types mailing list -- [email protected]
To unsubscribe send an email to [email protected]