[media-types] Re: [EXTERNAL] Re: Media Type Registrati on Review Request for draft-ietf-scitt-architecture
Amaury Chamayou <[email protected]>
| Newsgroups | gmane.ietf.types |
|---|---|
| Message-ID | <AS8PR83MB04887003993C5F2709CD78A3F946A@AS8PR83MB0488.EURPRD83.prod.outlook.com> |
Hi Alexey,
Thank you very much for the review! The omission of the scitt- prefix in the Subtype fields is an oversight, an early iteration did not have it. It was meant to be there, apologies for the confusion. I look forward to your separate email on improving security considerations (I drew inspiration from https://mailarchive.ietf.org/arch/msg/media-types/fAnT_Wy32kB4mpUEg21mc2u9zi8/), but in the meantime, here is an updated version for consideration, where the mailing list has also been amended.
Thank you,
Amaury
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 |
+----------------------+----------------------+------------+
Table 1: SCITT Signed Statement Media Type Registration
Type name: application
Subtype name: scitt-statement+cose
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 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]
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: scitt-receipt+cose
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]
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 | | | |
+----------------------+----------------+-----+-----------+
________________________________
From: Alexey Melnikov <[email protected]>
Sent: 30 June 2025 2:36 PM
To: Amaury Chamayou <[email protected]>; [email protected] <[email protected]>
Subject: [EXTERNAL] Re: [media-types] Media Type Registration Review Request for draft-ietf-scitt-architecture
You don't often get email from [email protected]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
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]<mailto:[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]<mailto:[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]