Re: [stir] "rcdi" vs MIME Content-Encoding

You might find some of the original media type registration helpful:

https://mailarchive.ietf.org/arch/msg/media-types/ae8mKgX7vWp9-KyhMnOtDjcoQr4/

There are currently no registry entries that include multiple suffixes, but
there is a draft that proposes to enable multiple suffixes, and your
comments on the topic would be welcome on the media types list.

https://mailarchive.ietf.org/arch/msg/media-types/6XKaJ1dEgBGKcOinoMagyhMFRkQ/

OS

On Tue, Apr 2, 2024, 7:37 PM Ben Campbell <ben@nostrum.com> wrote:

> Thanks, that’s the reference that started me down this path :-)
>
> Ben.
>
> On Apr 2, 2024, at 6:12 PM, Orie Steele <orie@transmute.industries> wrote:
>
> Is this reference helpful?
>
> https://datatracker.ietf.org/doc/html/rfc9399#section-7
>
> If you believe you have a use case for multiple suffixes, like this
> example, I would like to understand it.
>
> Regards,
>
> OS
>
> On Mon, Apr 1, 2024, 4:17 PM Alec Fenichel <alec.fenichel=
> 40transnexus.com@dmarc.ietf.org> wrote:
>
>> Ben,
>>
>>
>>
>> I had not thought about this until you sent this email and this is an
>> important point, so I think it should be clarified.
>>
>>
>>
>> Sincerely,
>>
>>
>>
>> Alec Fenichel
>>
>> Chief Technology Officer
>>
>> TransNexus <https://transnexus.com/>
>>
>> alec.fenichel@transnexus.com
>>
>> +1 (404) 369-2407 <+14043692407>
>>
>>
>>
>> *From: *Ben Campbell <ben@nostrum.com>
>> *Date: *Monday, April 1, 2024 at 17:09
>> *To: *Alec Fenichel <alec.fenichel@transnexus.com>
>> *Cc: *IETF STIR Mail List <stir@ietf.org>, Peterson, Jon <
>> jon.peterson@transunion.com>, Chris Wendt <cwendt@somos.com>
>> *Subject: *Re: [stir] "rcdi" vs MIME Content-Encoding
>>
>> Yeah, I was just thinking that after sending the question.
>>
>>
>>
>> Does draft-ietf-stir-passport-rcd need to say something about
>> Content-Encoding? Or is that sufficiently understood by everyone (other
>> than myself)?
>>
>>
>>
>>
>>
>> On Apr 1, 2024, at 3:29 PM, Alec Fenichel <alec.fenichel@transnexus.com>
>> wrote:
>>
>>
>>
>> It needs to be the decoded data. At the time the rcdi is sent, the
>> content encoding is not necessarily known. A web server may support
>> multiple content encodings and return the best encoding supported by the
>> client (indicated by the Accept-Encoding header).
>>
>>
>>
>> Sincerely,
>>
>>
>>
>> Alec Fenichel
>>
>> Chief Technology Officer
>>
>> TransNexus <https://transnexus.com/>
>>
>> alec.fenichel@transnexus.com
>>
>> +1 (404) 369-2407 <+14043692407>
>>
>>
>>
>> *From: *stir <stir-bounces@ietf.org> on behalf of Ben Campbell <
>> ben@nostrum.com>
>> *Date: *Monday, April 1, 2024 at 16:21
>> *To: *IETF STIR Mail List <stir@ietf.org>
>> *Cc: *Peterson, Jon <jon.peterson@transunion.com>, Chris Wendt <
>> cwendt@somos.com>
>> *Subject: *[stir] "rcdi" vs MIME Content-Encoding
>>
>> Hi,
>>
>>
>>
>> In thinking about the “rcdi” hashes and  RCD “icn” keys:
>>
>>
>>
>> What if the target has Content-Encoding? Would the “rcdi” hash be over
>> the raw or decoded data?
>>
>>
>>
>> For example, lets say that I get the following headers when dereferencing
>> the “icn” key:
>>
>>
>>
>> Content-Type: image/svg+xml
>>
>> Content-Encoding: gzip
>>
>>
>>
>> Should the “rcdi” hash be over the compressed or uncompressed version of
>> the data? I assume since draft-ietf-stir-passport-rcd-26 does not mention
>> content-encoding, that the hash would be over the actual octets we get back
>> on the wire prior to decoding.
>>
>>
>>
>> But I see that RFC 9399 (Certificate Logotypes), which seems like a
>> similar-if-not-identical application, says the opposite for this specific
>> example:
>>
>>
>>
>> Whether the SVG image is GZIP-compressed or uncompressed, the hash value
>> for the SVG image is calculated over the uncompressed SVG content with
>> canonicalized EOL characters, as specified above.
>>
>>
>>
>> Thoughts?
>>
>>
>>
>> Thanks!
>>
>>
>>
>> Ben.
>>
>>
>> _______________________________________________
>> stir mailing list
>> stir@ietf.org
>> https://www.ietf.org/mailman/listinfo/stir
>>
>
>