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

[Ben Campbell <[e-mail]>]

Oops, I forgot to add that TS 26.141 is about messaging and presence applications, not voice calling per se. (But it does seem likely that requirements overlap.)

Thanks!

Ben.

> On Apr 3, 2024, at 11:22 AM, Ben Campbell <[e-mail]> wrote:
> 
> Signed PGP part
> Hi Pierce,
> 
> On a quick scan, I don’t see anything in RCC.07 or RCC.20 that bears on icon formats. But I did find some in 3GPP TS 26.141 that is not too far off from what is in RFC 9399.
> 
> (Does anyone use GIF for static images anymore?)
> 
> I think the interesting point of RFC 9399 is that logotype images are used with external content with signed hashes, which seems pretty close to the RCD application. 
> 
> 
> Thanks!
> 
> Bne.
> 
>> On Apr 3, 2024, at 8:25 AM, Pierce Gorman <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 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] <mailto:[e-mail]>>
>> Sent: Tuesday, April 2, 2024 7:38 PM
>> To: Orie Steele <[e-mail] <mailto:[e-mail]>>
>> Cc: Alec Fenichel <alec.fenichel=[e-mail] <mailto:alec.fenichel=[e-mail]>>; 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
>>  
>> 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
> 
> _______________________________________________
> stir mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/stir