[sipcore] Re: regarding draft-ietf-sipcore-callinfo-rcd-15

[Chris Wendt <[e-mail]>]

Patience is my middle name in this business. :)

> On Mar 10, 2025, at 10:52 PM, Richard Shockey <[e-mail]> wrote:
> 
> 
> 
> Andy I don’t want to go into issues of how IETF process has become so pathetically tortured.  Its frankly an embarrassment.
> 
> This draft has the full support of the US Government and the US telecom industry. The USG has indicated that existing CNAM is fundamentally useless and is prepared to mandate RCD at some future point in time.   I wont go into issues of the movement to transition to an all IP network.
> 
> Related to that ATIS and the SIP Forum jointly developed SIP error code 603+ to satisfy the requirements of industry for call blocking notification. We had to do that since it was  universally understood that trying to do that within the IETF process was futile if not impossible.
> 
> We need a RFC. NOW.  We totally understand the concerns of the vendor community that they will not fully code without a rock solid RFC. We appreciate the comments from Christian Huitema <[e-mail] <mailto:[e-mail]>> on legitimate privacy concerns however what we are trying to do here is protect consumers from fraud and scams and this draft has the full support of some of the largest corporations in the US.  Financial Services...health care you name it. Pierce Gorman definitely knows this.
> 
> https://docs.fcc.gov/public/attachments/DOC-405219A1.pdf
> 
> 
> Can we just "get er done"?  Brother Wendt has been too patient here. I'm a very very cranky old curmudgeon these days with a short fuze.
> 
> 
> 
> 
> Richard Shockey 
> Shockey Consulting LLC 
> Chairman of the Board SIP Forum 
> www.shockey.us <http://www.shockey.us/> <http://www.shockey.us <http://www.shockey.us/>> 
> www.sipforum.org <http://www.sipforum.org/>
> 
> richard<at>shockey.us <http://shockey.us/>
> Skype-Linkedin-Facebook –Twitter rshockey101 
> PSTN [phone] 
> 
> 
> 
> 
> 
> On 3/10/25, 7:18 PM, "Andrew Newton (andy)" <[e-mail] <mailto:[e-mail]> <mailto:[e-mail]>> wrote:
> 
> 
> +artads
> 
> 
> Richard,
> 
> 
> I don't know the history of this document but have taken note of the circular dependency. If you have ideas about how this could have been better, feel free to provide suggestions. BTW, we are holding ART AD office hours at 122.
> 
> 
> -andy
> 
> 
> On 3/10/25 18:39, Richard Shockey wrote:
>> Andy can we just get this done. This has dragged on for over 3 years. We want to deploy.
>> 
>> This process has been simply insane. Its why none of us in the real time communications business want to take any new standardizations into the IETF.
>> 
>> 
>> Richard Shockey
>> Shockey Consulting LLC
>> Chairman of the Board SIP Forum
>> www.shockey.us <http://www.shockey.us/> <http://www.shockey.us <http://www.shockey.us/>> <http://www.shockey.us&gt; <http://www.shockey.us&gt;/>>
>> www.sipforum.org <http://www.sipforum.org/>
>> 
>> richard<at>shockey.us <http://shockey.us/>
>> Skype-Linkedin-Facebook –Twitter rshockey101
>> PSTN [phone]
>> 
>> 
>> 
>> 
>> 
>> On 3/10/25, 6:19 PM, "Chris Wendt" <[e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>> 
>> 
>> Thanks Andy. Will submit a -16 that incorporate those changes as well as the ask from Brian around the IANA request.
>> 
>> 
>>> On Mar 10, 2025, at 12:45 PM, Andrew Newton (andy) <[e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>>> 
>>> Top posting here...
>>> 
>>> This all looks good. Thanks for taking a look and your patience. Also,
>>> thanks for a very well-written and high-quality document.
>>> 
>>> -andy
>>> 
>>>> On Mon, Mar 10, 2025 at 8:49 AM Chris Wendt <[e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>> wrote:
>>>> 
>>>> Hi Andy,
>>>> 
>>>> On Mar 4, 2025, at 8:36 PM, Andrew Newton (andy) <[e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> Murray has submitted draft-ietf-sipcore-callinfo-rcd-15 for balloting by the IESG, however this document will not make it on to the next telechat meaning it will likely fall to me as incoming ART AD. After reviewing the draft, I have a couple of minor comments/questions. I also ask for your patience regarding my knowledge of this topic as it is new to me.
>>>> 
>>>> 
>>>> Of course, discussion inline:
>>>> 
>>>> 
>>>> Line numbers are from https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-sipcore-callinfo-rcd-15.txt <https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-sipcore-callinfo-rcd-15.txt> <https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-sipcore-callinfo-rcd-15.txt> <https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-sipcore-callinfo-rcd-15.txt&gt;>
>>>> 
>>>> 
>>>> 
>>>> 328 The jCard is intended to contain multiple information elements about
>>>> 329 the calling party. A call and its corresponding single RCD-related
>>>> 330 Call-Info header field MUST only contain a single "jcard" token.
>>>> 
>>>> 332 The fields like "fn", "photo", or "logo" if used with the use of
>>>> 333 "icon" calling name in From or P-Asserted-ID header field or purpose
>>>> 334 token, as described in the previous section, MUST either match or be
>>>> 335 avoided to allow the called party to clearly determine the intended
>>>> 336 calling name or icon.
>>>> 
>>>> 338 An example of a Call-Info header field is:
>>>> 
>>>> 340 Call-Info: <https://example.com/qbranch.json>;purpose=jcard <https://example.com/qbranch.json&gt;;purpose=jcard> <https://example.com/qbranch.json&gt;;purpose=jcard> <https://example.com/qbranch.json&amp;gt;;purpose=jcard&gt;>
>>>> 
>>>> 342 An example of the contents of a URL-linked jCard JSON file is shown
>>>> 343 as follows:
>>>> 
>>>> 345 ["vcard",
>>>> 346 [
>>>> 347 ["version",{},"text","4.0"],
>>>> 348 ["fn",{},"text","Q Branch"],
>>>> 349 ["org",{},"text","MI6;Q Branch Spy Gadgets"],
>>>> 350 ["photo",{},"uri","https://example.com/photos/q-256x256.png" <https://example.com/photos/q-256x256.png&quot;> <https://example.com/photos/q-256x256.png&quot;> <https://example.com/photos/q-256x256.png&amp;quot;&gt;>],
>>>> 351 ["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg" <https://example.com/logos/mi6-256x256.jpg&quot;> <https://example.com/logos/mi6-256x256.jpg&quot;> <https://example.com/logos/mi6-256x256.jpg&amp;quot;&gt;>],
>>>> 352 ["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg" <https://example.com/logos/mi6-64x64.jpg&quot;> <https://example.com/logos/mi6-64x64.jpg&quot;> <https://example.com/logos/mi6-64x64.jpg&amp;quot;&gt;>]
>>>> 353 ]
>>>> 354 ]
>>>> 
>>>> What happens if there are multiple cards in the "vcard" array? Are they all required to match (see paragraph starting line 332)?
>>>> 
>>>> 
>>>> The text on line 330 does say “MUST” for only containing a single “jcard” token.
>>>> I took a look at RFC7095 Section 3.2 that talks about the top level jCard Object syntax and while it looks like you can have multiple jcard objects within the same JSON array, that isn’t the intent of this document to have more than one entity. So I will clarify that statement further with the following:
>>>> 
>>>> "A call and its corresponding single RCD-related Call-Info header field MUST only contain a single jCard object represented by an array with two elements. The array MUST only include a single first element with the string "vcard", and the second element is an array of jCard properties corresponding to the single entity jCard object."
>>>> 
>>>> 
>>>> 356 An example SIP INVITE using the "data" URI scheme is as follows:
>>>> 
>>>> 358 INVITE sip:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> SIP/2.0
>>>> 359 Via: SIP/2.0/TLS pc33.atlanta.example.com <http://pc33.atlanta.example.com/>;branch=z9hG4bKnashds8
>>>> 360 To: Alice <sip:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
>>>> 361 From: Bob <sip:[e-mail] <mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>;user=phone>;tag=1928301774>
>>>> 362 Call-ID: a84b4c76e66710
>>>> 363 Call-Info: <data:application/json,["vcard",[["version",{},"text",
>>>> 364 "4.0"],["fn",{},"text","Q Branch"],["org",{},"text","MI6;Q Branch
>>>> 365 Spy Gadgets"],["photo",{},"uri","https://example.com/photos/quart <https://example.com/photos/quart> <https://example.com/photos/quart> <https://example.com/photos/quart&gt;>
>>>> 366 ermaster-256x256.png"],["logo",{},"uri","https://example.com/log <https://example.com/log> <https://example.com/log> <https://example.com/log&gt;>
>>>> 367 os/mi6-256x256.jpg"],["logo",{},"uri","https://example.com/logos/ <https://example.com/logos/> <https://example.com/logos/> <https://example.com/logos/&gt;>
>>>> 368 mi6-64x64.jpg"]]]\>;purpose=jcard;call-reason="Rendezvous for
>>>> 369 Little Nellie"
>>>> 370 CSeq: 314159 INVITE
>>>> 371 Max-Forwards: 70
>>>> 372 Date: Fri, 25 Sep 2015 19:12:25 GMT
>>>> 373 Contact: <sip:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
>>>> 374 Content-Type: application/sdp
>>>> 
>>>> 376 v=0
>>>> 377 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com <http://pc33.atlanta.example.com/>
>>>> 378 s=Session SDP
>>>> 379 c=IN IP4 pc33.atlanta.example.com <http://pc33.atlanta.example.com/>
>>>> 380 t=0 0
>>>> 381 m=audio 49172 RTP/AVP 0
>>>> 382 a=rtpmap:0 PCMU/8000
>>>> 
>>>> 384 An example SIP INVITE using the "cid" URI scheme is as follows:
>>>> 
>>>> 386 INVITE sip:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> SIP/2.0
>>>> 387 Via: SIP/2.0/TLS pc33.atlanta.example.com <http://pc33.atlanta.example.com/>;branch=z9hG4bKnashds8
>>>> 388 To: Alice <sip:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
>>>> 389 From: Bob <sip:[e-mail] <mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>;user=phone>;tag=1928301774>
>>>> 390 Call-ID: a84b4c76e66710
>>>> 391 Call-Info: <cid:[e-mail] <mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>;purpose=jcard;
>>>> 392 call-reason="Rendezvous for Little Nellie"
>>>> 393 CSeq: 314159 INVITE
>>>> 394 Max-Forwards: 70
>>>> 395 Date: Fri, 25 Sep 2015 19:12:25 GMT
>>>> 396 Contact: <sip:[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
>>>> 397 Content-Type: multipart/mixed; boundary=boundary1
>>>> 398 Content-Length: ...
>>>> 
>>>> 400 --boundary1
>>>> 
>>>> 402 Content-Type: application/sdp
>>>> 
>>>> 404 v=0
>>>> 405 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com <http://pc33.atlanta.example.com/>
>>>> 406 s=Session SDP
>>>> 407 c=IN IP4 pc33.atlanta.example.com <http://pc33.atlanta.example.com/>
>>>> 408 t=0 0
>>>> 409 m=audio 49172 RTP/AVP 0
>>>> 410 a=rtpmap:0 PCMU/8000
>>>> 
>>>> 412 --boundary1
>>>> 
>>>> 414 Content-Type: application/json
>>>> 415 Content-ID: <[e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>
>>>> 
>>>> 417 ["vcard",[["version",{},"text","4.0"],["fn",{},"text","Q Branch"],
>>>> 418 ["org",{},"text","MI6;Q Branch Spy Gadgets"],["photo",{},"uri","
>>>> 419 https://example.com/photos/quartermaster-256x256.png" <https://example.com/photos/quartermaster-256x256.png&quot;> <https://example.com/photos/quartermaster-256x256.png&quot;> <https://example.com/photos/quartermaster-256x256.png&amp;quot;&gt;>],["logo",
>>>> 420 {},"uri","https://example.com/logos/mi6-256x256.jpg" <https://example.com/logos/mi6-256x256.jpg&quot;> <https://example.com/logos/mi6-256x256.jpg&quot;> <https://example.com/logos/mi6-256x256.jpg&amp;quot;&gt;>],["logo",{},
>>>> 421 "uri","https://example.com/logos/mi6-64x64.jpg" <https://example.com/logos/mi6-64x64.jpg&quot;> <https://example.com/logos/mi6-64x64.jpg&quot;> <https://example.com/logos/mi6-64x64.jpg&amp;quot;&gt;>]]]
>>>> 
>>>> These examples are great, btw!
>>>> 
>>>> Can user-agents and intermediaries cache jCards? Or is this information only for the context of this SIP session? Or is the usage of this information outside of SIP out-of-scope for this document?
>>>> 
>>>> 
>>>> In general SIP does not use a caching mechanism as a real-time protocol that is generally call specific. But as you are likely imagining if there is a URI or URL with a jcard that describes a caller, certainly the referenced HTTP resource could be used in multiple calls and caching of the same URL for multiple calls could apply, however i think this document does not want to have any opinions on that.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 875 10.5.1. "adr" Property
>>>> 
>>>> 877 The "adr" property provides the delivery address of the object the
>>>> 878 jCard represents. Reference: [RFC6350], Section 6.3.1.
>>>> 
>>>> 880 Value type: A single structured text value separated by the SEMICOLON
>>>> 881 character (U+003B).
>>>> 
>>>> 883 Cardinality: *
>>>> 884 Example:
>>>> 885 ["adr", {"type":"work"}, "text",
>>>> 886 ["", "", "3100 Massachusetts Avenue NW", "Washington", "DC",
>>>> 887 "20008", "USA"]
>>>> 
>>>> The 7th item in the 'adr' property is country name, not country code. In this example "USA" should be "United States of America". RFC 8605 does define a country code parameter for jCard, but it is the two-letter variety.
>>>> 
>>>> Also, the 3rd item which is the street address may also be an array of strings. An example of such is useful as that is often not easy to distill from the vCard/jCard specs and can cause interoperability issues.
>>>> 
>>>> 
>>>> Ok, here is my proposal to replace and add to lines 884-887, i’ll use “U.S.A.” to save a little room.
>>>> 
>>>> Example:
>>>> 
>>>> ["adr", {“type”:”work"}, "text",
>>>> ["", "", "3100 Massachusetts Avenue NW", "Washington", “DC”, "20008", “U.S.A."]
>>>> ]
>>>> 
>>>> "adr" also allows a structured value element that itself has multiple values. In this case, the
>>>> element of the array describing the structured value is itself an array with one element for each of the component's multiple values. The following example shows alternate values for the address string.
>>>> 
>>>> Example:
>>>> 
>>>> ["adr", {“type”:”work"}, "text",
>>>> ["", "", ["3100 Massachusetts Avenue NW”,"Embassy of the United Kingdom"], "Washington", “DC”, "20008", “U.S.A."]
>>>> ]
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 1229 The security framework of signing and providing integrity to this
>>>> 1230 data [I-D.ietf-stir-passport-rcd] should be followed, and the use of
>>>> 1231 constraints and other certificate-based associations should be
>>>> 1232 considered. This includes considerations for information about the
>>>> 1233 calling party, which is generally constant, versus per-call data,
>>>> 1234 which is more transient. This also includes the relationship that
>>>> 1235 certificates with constraints presents to how they relate to each
>>>> 1236 other and how that information is managed, protected, and associated
>>>> 1237 with the correct call corresponding to a calling party.
>>>> 
>>>> Am I correct to assume passport-rcd is the mechanism to prevent spoofing and tampering of callinfo data? Is it possible to elaborate on the issues relevant to the calling-party versus per-call data (line 1233)? It is not clear to me what the differences might be.
>>>> 
>>>> 
>>>> Agreed, this does need more context and clarity. How about this:
>>>> 
>>>> The use of the Call-Info header for transporting Rich Call Data ('rcd') is intended primarily for providing verified information at the termination of a call, where a verification service has a trusted UNI relationship with the user agent. To ensure the integrity and authenticity of this data, the security framework established by STIR, including the use of the 'rcd'PASSporT as defined in [I-D.ietf-stir-passport-rcd], should be followed. This framework enables digital signatures to verify the issuer of assertions related to the calling party’s identity, distinguishing persistent identity attributes from transient, per-call details. Implementers should also consider certificate-based constraints to ensure proper binding between caller identity assertions and call-specific metadata while maintaining the integrity of the information throughout transmission. Since Call-Info serves as a means to convey verified caller information to the end user, mechanisms should be in place to validate the authenticity of the assertion, enforce appropriate certificate associations, and preserve the trustworthiness of Rich Call Data from origination to termination.
>>>> 
>>>> 
>>>> 
>>>> 1291 [I-D.ietf-stir-passport-rcd]
>>>> 1292 Wendt, C. and J. Peterson, "PASSporT Extension for Rich
>>>> 1293 Call Data", Work in Progress, Internet-Draft, draft-ietf-
>>>> 1294 stir-passport-rcd-26, 5 June 2023,
>>>> 1295 <https://datatracker.ietf.org/doc/html/draft-ietf-stir- <https://datatracker.ietf.org/doc/html/draft-ietf-stir-> <https://datatracker.ietf.org/doc/html/draft-ietf-stir-> <https://datatracker.ietf.org/doc/html/draft-ietf-stir-&gt;>
>>>> 1296 passport-rcd-26>.
>>>> 
>>>> Ahem!... this normative dependency has been sitting in the RFC editors queue for almost 2 years.
>>>> 
>>>> 
>>>> Robert’s previous email addressed this.
>>>> 
>>>> 
>>>> Overall, this is a very well-written draft. Thanks for your patience.
>>>> 
>>>> 
>>>> Thank you.
>>>> 
>>>> 
>>>> 
>>>> -andy
>>>> 
>>>> _______________________________________________
>>>> sipcore mailing list -- [e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
>>>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
>>>> 
>>>> 
>> 
>> _______________________________________________
>> sipcore mailing list -- [e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>