User-Agent: Microsoft-MacOutlook/16.94.25022327
Date: Mon, 10 Mar 2025 18:39:10 -0400
From: Richard Shockey <richard@shockey.us>
To: Chris Wendt <chris-ietf@chriswendt.net>,
	Andrew Newton <andy@hxr.us>
Message-ID: <CA02ABF5-75BA-49DC-BF2D-4D62BA9FF7EE@shockey.us>
Thread-Topic: [sipcore] Re: regarding draft-ietf-sipcore-callinfo-rcd-15
References: <D78C5766-C183-45F9-AA04-0143E8BF62A5@chriswendt.net>
In-Reply-To: <D78C5766-C183-45F9-AA04-0143E8BF62A5@chriswendt.net>
Mime-version: 1.0
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable
Message-ID-Hash: JOBJ4WXOIPISUM3LFMAMALSIEKCVGCG4
CC: sipcore@ietf.org
Precedence: list
Subject: =?utf-8?q?=5Bsipcore=5D_Re=3A_regarding_draft-ietf-sipcore-callinfo-rcd-15?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/sipcore/k3k6M-STPf83HQ8bkvE_YNkp5_4>


Andy can we just get this done. This has dragged on for over 3 years. We wa=
nt to deploy.

This process has been simply insane. Its why none of us in the real time co=
mmunications business want to take any new standardizations into the IETF.


Richard Shockey=20
Shockey Consulting LLC=20
Chairman of the Board SIP Forum=20
www.shockey.us <http://www.shockey.us>=20
www.sipforum.org=20

richard<at>shockey.us=20
Skype-Linkedin-Facebook =E2=80=93Twitter rshockey101=20
PSTN +1 703-593-2683=20





=EF=BB=BFOn 3/10/25, 6:19 PM, "Chris Wendt" <chris-ietf@chriswendt.net <mailto:ch=
ris-ietf@chriswendt.net>> wrote:


Thanks Andy. Will submit a -16 that incorporate those changes as well as th=
e ask from Brian around the IANA request.


> On Mar 10, 2025, at 12:45 PM, Andrew Newton (andy) <andy@hxr.us <mailto:a=
ndy@hxr.us>> wrote:
>=20
> =EF=BB=BFTop posting here...
>=20
> This all looks good. Thanks for taking a look and your patience. Also,
> thanks for a very well-written and high-quality document.
>=20
> -andy
>=20
>> On Mon, Mar 10, 2025 at 8:49 AM Chris Wendt <chris-ietf@chriswendt.net <=
mailto:chris-ietf@chriswendt.net>> wrote:
>>=20
>> Hi Andy,
>>=20
>> On Mar 4, 2025, at 8:36 PM, Andrew Newton (andy) <andy@hxr.us <mailto:an=
dy@hxr.us>> wrote:
>>=20
>> Hi all,
>>=20
>> 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 me=
aning it will likely fall to me as incoming ART AD. After reviewing the draf=
t, 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.
>>=20
>>=20
>> Of course, discussion inline:
>>=20
>>=20
>> Line numbers are from https://author-tools.ietf.org/api/idnits?url=3Dhttps=
://www.ietf.org/archive/id/draft-ietf-sipcore-callinfo-rcd-15.txt <https://a=
uthor-tools.ietf.org/api/idnits?url=3Dhttps://www.ietf.org/archive/id/draft-ie=
tf-sipcore-callinfo-rcd-15.txt>
>>=20
>>=20
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 338 An example of a Call-Info header field is:
>>=20
>> 340 Call-Info: <https://example.com/qbranch.json>;purpose=3Djcard <https:/=
/example.com/qbranch.json&gt;;purpose=3Djcard>
>>=20
>> 342 An example of the contents of a URL-linked jCard JSON file is shown
>> 343 as follows:
>>=20
>> 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;>],
>> 351 ["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg" <https:=
//example.com/logos/mi6-256x256.jpg&quot;>],
>> 352 ["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg" <https://=
example.com/logos/mi6-64x64.jpg&quot;>]
>> 353 ]
>> 354 ]
>>=20
>> What happens if there are multiple cards in the "vcard" array? Are they =
all required to match (see paragraph starting line 332)?
>>=20
>>=20
>> The text on line 330 does say =E2=80=9CMUST=E2=80=9D for only containing a single =E2=80=
=9Cjcard=E2=80=9D token.
>> I took a look at RFC7095 Section 3.2 that talks about the top level jCar=
d Object syntax and while it looks like you can have multiple jcard objects =
within the same JSON array, that isn=E2=80=99t the intent of this document to have=
 more than one entity. So I will clarify that statement further with the fol=
lowing:
>>=20
>> "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 ele=
ments. The array MUST only include a single first element with the string "v=
card", and the second element is an array of jCard properties corresponding =
to the single entity jCard object."
>>=20
>>=20
>> 356 An example SIP INVITE using the "data" URI scheme is as follows:
>>=20
>> 358 INVITE sip:alice@example.com <mailto:alice@example.com> SIP/2.0
>> 359 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=3Dz9hG4bKnashds8
>> 360 To: Alice <sip:alice@example.com <mailto:alice@example.com>>
>> 361 From: Bob <sip:12155551000@example.com <mailto:12155551000@example.c=
om>;user=3Dphone>;tag=3D1928301774>
>> 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 <h=
ttps://example.com/photos/quart>
>> 366 ermaster-256x256.png"],["logo",{},"uri","https://example.com/log <ht=
tps://example.com/log>
>> 367 os/mi6-256x256.jpg"],["logo",{},"uri","https://example.com/logos/ <h=
ttps://example.com/logos/>
>> 368 mi6-64x64.jpg"]]]\>;purpose=3Djcard;call-reason=3D"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:12155551000@gateway.example.com <mailto:12155551000@ga=
teway.example.com>>
>> 374 Content-Type: application/sdp
>>=20
>> 376 v=3D0
>> 377 o=3DUserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com
>> 378 s=3DSession SDP
>> 379 c=3DIN IP4 pc33.atlanta.example.com
>> 380 t=3D0 0
>> 381 m=3Daudio 49172 RTP/AVP 0
>> 382 a=3Drtpmap:0 PCMU/8000
>>=20
>> 384 An example SIP INVITE using the "cid" URI scheme is as follows:
>>=20
>> 386 INVITE sip:alice@example.com <mailto:alice@example.com> SIP/2.0
>> 387 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=3Dz9hG4bKnashds8
>> 388 To: Alice <sip:alice@example.com <mailto:alice@example.com>>
>> 389 From: Bob <sip:12155551000@example.com <mailto:12155551000@example.c=
om>;user=3Dphone>;tag=3D1928301774>
>> 390 Call-ID: a84b4c76e66710
>> 391 Call-Info: <cid:12155551000@example.com <mailto:12155551000@example.=
com>>;purpose=3Djcard;
>> 392 call-reason=3D"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:12155551000@gateway.example.com <mailto:12155551000@ga=
teway.example.com>>
>> 397 Content-Type: multipart/mixed; boundary=3Dboundary1
>> 398 Content-Length: ...
>>=20
>> 400 --boundary1
>>=20
>> 402 Content-Type: application/sdp
>>=20
>> 404 v=3D0
>> 405 o=3DUserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com
>> 406 s=3DSession SDP
>> 407 c=3DIN IP4 pc33.atlanta.example.com
>> 408 t=3D0 0
>> 409 m=3Daudio 49172 RTP/AVP 0
>> 410 a=3Drtpmap:0 PCMU/8000
>>=20
>> 412 --boundary1
>>=20
>> 414 Content-Type: application/json
>> 415 Content-ID: <12155551000@example.com <mailto:12155551000@example.com=
>>
>>=20
>> 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://examp=
le.com/photos/quartermaster-256x256.png&quot;>],["logo",
>> 420 {},"uri","https://example.com/logos/mi6-256x256.jpg" <https://exampl=
e.com/logos/mi6-256x256.jpg&quot;>],["logo",{},
>> 421 "uri","https://example.com/logos/mi6-64x64.jpg" <https://example.com=
/logos/mi6-64x64.jpg&quot;>]]]
>>=20
>> These examples are great, btw!
>>=20
>> 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 informatio=
n outside of SIP out-of-scope for this document?
>>=20
>>=20
>> 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 f=
or multiple calls could apply, however i think this document does not want t=
o have any opinions on that.
>>=20
>>=20
>>=20
>>=20
>> 875 10.5.1. "adr" Property
>>=20
>> 877 The "adr" property provides the delivery address of the object the
>> 878 jCard represents. Reference: [RFC6350], Section 6.3.1.
>>=20
>> 880 Value type: A single structured text value separated by the SEMICOLO=
N
>> 881 character (U+003B).
>>=20
>> 883 Cardinality: *
>> 884 Example:
>> 885 ["adr", {"type":"work"}, "text",
>> 886 ["", "", "3100 Massachusetts Avenue NW", "Washington", "DC",
>> 887 "20008", "USA"]
>>=20
>> 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 defi=
ne a country code parameter for jCard, but it is the two-letter variety.
>>=20
>> Also, the 3rd item which is the street address may also be an array of s=
trings. An example of such is useful as that is often not easy to distill fr=
om the vCard/jCard specs and can cause interoperability issues.
>>=20
>>=20
>> Ok, here is my proposal to replace and add to lines 884-887, i=E2=80=99ll use =
=E2=80=9CU.S.A.=E2=80=9D to save a little room.
>>=20
>> Example:
>>=20
>> ["adr", {=E2=80=9Ctype=E2=80=9D:=E2=80=9Dwork"}, "text",
>> ["", "", "3100 Massachusetts Avenue NW", "Washington", =E2=80=9CDC=E2=80=9D, "20008"=
, =E2=80=9CU.S.A."]
>> ]
>>=20
>> "adr" also allows a structured value element that itself has multiple va=
lues. 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.
>>=20
>> Example:
>>=20
>> ["adr", {=E2=80=9Ctype=E2=80=9D:=E2=80=9Dwork"}, "text",
>> ["", "", ["3100 Massachusetts Avenue NW=E2=80=9D,"Embassy of the United Kingdo=
m"], "Washington", =E2=80=9CDC=E2=80=9D, "20008", =E2=80=9CU.S.A."]
>> ]
>>=20
>>=20
>>=20
>>=20
>> 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 o=
f
>> 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 associate=
d
>> 1237 with the correct call corresponding to a calling party.
>>=20
>> 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 r=
elevant to the calling-party versus per-call data (line 1233)? It is not cle=
ar to me what the differences might be.
>>=20
>>=20
>> Agreed, this does need more context and clarity. How about this:
>>=20
>> 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 s=
ecurity framework established by STIR, including the use of the 'rcd'PASSpor=
T as defined in [I-D.ietf-stir-passport-rcd], should be followed. This frame=
work enables digital signatures to verify the issuer of assertions related t=
o the calling party=E2=80=99s identity, distinguishing persistent identity attribu=
tes from transient, per-call details. Implementers should also consider cert=
ificate-based constraints to ensure proper binding between caller identity a=
ssertions and call-specific metadata while maintaining the integrity of the =
information throughout transmission. Since Call-Info serves as a means to co=
nvey verified caller information to the end user, mechanisms should be in pl=
ace to validate the authenticity of the assertion, enforce appropriate certi=
ficate associations, and preserve the trustworthiness of Rich Call Data from=
 origination to termination.
>>=20
>>=20
>>=20
>> 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://da=
tatracker.ietf.org/doc/html/draft-ietf-stir->
>> 1296 passport-rcd-26>.
>>=20
>> Ahem!... this normative dependency has been sitting in the RFC editors q=
ueue for almost 2 years.
>>=20
>>=20
>> Robert=E2=80=99s previous email addressed this.
>>=20
>>=20
>> Overall, this is a very well-written draft. Thanks for your patience.
>>=20
>>=20
>> Thank you.
>>=20
>>=20
>>=20
>> -andy
>>=20
>> _______________________________________________
>> sipcore mailing list -- sipcore@ietf.org <mailto:sipcore@ietf.org>
>> To unsubscribe send an email to sipcore-leave@ietf.org <mailto:sipcore-l=
eave@ietf.org>
>>=20
>>=20
>=20


_______________________________________________
sipcore mailing list -- sipcore@ietf.org <mailto:sipcore@ietf.org>
To unsubscribe send an email to sipcore-leave@ietf.org <mailto:sipcore-leav=
e@ietf.org>