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

[Pierce Gorman <[e-mail]>]

RFC 9399 would be more useful if it were adopted by wireless service providers and mobile device manufacturers who can be very particular about audio/video codec and image formats they will support.

Generally, the wireless service provider and mobile device manufacturer community pays more attention to content formats defined by 3GPP (e.g., AMR, AMR-WB, EVS) and GSMA than they do recommendations from the IETF.   E.g., GSMA published the RCC.07 and RCC.20 specifications that have been influential in defining Rich Communication Services (RCS) content formats which have been adopted more or less globally by mobile device manufacturers.

Pierce

From: Ben Campbell <[e-mail]>
Sent: Tuesday, April 2, 2024 7:38 PM
To: Orie Steele <[e-mail]>
Cc: Alec Fenichel <alec.fenichel=[e-mail]>; IETF STIR Mail List <[e-mail]>; Peterson, Jon <[e-mail]>; Chris Wendt <[e-mail]>
Subject: Re: [stir] "rcdi" vs MIME Content-Encoding

Thanks, that’s the reference that started me down this path :-)

Ben.


On Apr 2, 2024, at 6:12 PM, Orie Steele <[e-mail]<mailto:[e-mail]>> 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=[e-mail]<mailto:[e-mail]>> 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/>
[e-mail]<mailto:[e-mail]>
[phone]<tel:[phone]>

From: Ben Campbell <[e-mail]<mailto:[e-mail]>>
Date: Monday, April 1, 2024 at 17:09
To: Alec Fenichel <[e-mail]<mailto:[e-mail]>>
Cc: IETF STIR Mail List <[e-mail]<mailto:[e-mail]>>, Peterson, Jon <[e-mail]<mailto:[e-mail]>>, Chris Wendt <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> 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/>
[e-mail]<mailto:[e-mail]>
[phone]<tel:[phone]>

From: stir <[e-mail]<mailto:[e-mail]>> on behalf of Ben Campbell <[e-mail]<mailto:[e-mail]>>
Date: Monday, April 1, 2024 at 16:21
To: IETF STIR Mail List <[e-mail]<mailto:[e-mail]>>
Cc: Peterson, Jon <[e-mail]<mailto:[e-mail]>>, Chris Wendt <[e-mail]<mailto:[e-mail]>>
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/stir