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

[Pierce Gorman <[e-mail]>]

Yup.  RCC.20 Section 2.4.2 describes RCS picture transfer procedures and references 3GPP 26.141 Section 4.2 and 4.3 which describe content types and formats.

I was mostly wanting folks to know about the extensive work done outside of IETF that has a more direct impact on RCD content in the arena of mobile communications.

And certainly, the formats identified in RFC 9399 could be adopted for “wireline” SIP phone and soft-client environments, although it makes things more complicated if the calling party have to guess at what the called party can display if they’re not following what was established in the mobile environment.

For the work here, the important thing is what Alec said.  Be sure to clarify “decoded”.

Pierce

From: Ben Campbell <[e-mail]>
Sent: Wednesday, April 3, 2024 11:30 AM
To: Pierce Gorman <[e-mail]>
Cc: Orie Steele <[e-mail]>; 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

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]<mailto:[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