[sipcore] Re: Mohamed Boucadair's Discuss on draft-ietf-sipcore-callinfo-rcd-16: (with DISCUSS and COMMENT)

[Chris Wendt <[e-mail]>]

Hi Mohammed,

Appreciate your very comprehensive review and suggestions, comments inline.  I am planning to submit a corresponding -17 with the agreed changes/fixed discussed below, if there is further discussion can update as well.

Note to the larger working group, i’m also including a nit fix in -17 from Scott Hollenbeck Artart review (cc’d) that i had noticed previously missed fixing. 

s/jCard is a comprehensive and extensible mechanism defined in the STIR RCD
framework./jCard is a comprehensive and extensible mechanism utilized as part of the STIR RCD framework.

-Chris

> On Apr 5, 2025, at 3:10 AM, Mohamed Boucadair via Datatracker <[e-mail]> wrote:
> 
> Mohamed Boucadair has entered the following ballot position for
> draft-ietf-sipcore-callinfo-rcd-16: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sipcore-callinfo-rcd/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Hi Chris/Jon,
> 
> Thank you for the effort put into this specification.
> 
> Thanks also to Giuseppe Fioccola for the OPSDIR review.
> 
> # Meta comment
> 
> Overall, I like the flow the document and like Giuseppe I found sections 9/10
> very useful. There are, however, many repetitions in the text. Some
> cleanup/simplification are worth.
> 
> I found it intriguing that the document reasons about “calls” while I think
> this can be used independent of the media session under establishment. Under
> there are subtle things I didn’t catch, I strongly suggest the text is
> refreshed with that change in mind. The mysterious “to answer the phone” in the
> abstract made be lough.
> 
> I have few DISCUSS points and COMMENTs (tagged with (*) main ones).
> 
> # DISCUSS
> 
> ## Co-existence
> 
> CURRENT:
>   [RFC7852] provides a means of carrying additional data about callers
>   for the purposes of emergency services (especially Section 4.4
>   (Owner/Subscriber Information) of [RFC7852]).  This specification
>   provides an overlapping functionality for non-emergency cases.
>   Rather than overloading its "EmergencyCallData" Call-Info 'purpose'
>   parameter value, this document defines a separate 'purpose' parameter
>   for the more generic delivery of information via jCard [RFC7095].
>   This document borrows from [RFC7852] the capability to carry a data
>   structure as a body, through the use of the "cid" URI scheme
>   [RFC2392].
> 
> Do we need to say something about co-existence? Any usage guidance we want to
> add here for the new parameters, especially for emergency sessions?

This was the working group recommended way of stating this, the purpose/URI mechanism of call-info is unfortunately problematic for many reasons, so this was the mechanism we settled on.  I don’t think co-existence is the issue, perhaps you are reading “defines a separate ‘purpose’ parameter” to mean something different than intended.

I could rephrase that “defines a separate ‘purpose’ parameter value ‘jcard’ for the more generic …"

> 
> ## How to enforce the recommendation on future documents?
> 
> CURRENT:
>   It may be that future specifications extend
>   information types and, similar to how this document extends the Call-
>   Info header field to provide corresponding functionality to STIR RCD,
>   it is RECOMMENDED that future specifications also provide
>   corresponding Call-Info extensions.
> 
> How we enforce this? Show we consider this specification be tagged to update
> other base spec on the matter?
> 
> Absent concrete means, I fail to see how we will ensure in the future that this
> will.
> 
> May be this is not a recommendation at the first place. I’m neutral on the
> outcome but I think this should be fixed.

I don’t think it’s hurts, but i also agree it’s not strictly enforceable.  I think this was a fragment of other text that was previously removed due to other comments, so i don’t mind removing it now because it’s less meaningful guidance.

> 
> ## I failed to find how misbehaving intermediate nodes are detected. Can we
> have some reference or expand on this?
> 
> CURRENT:
>   Any additional parties involved in the call path MUST NOT modify the
>   Call-Info header field or add additional Call-Info header fields
>   related to RCD.

This is what stir is intended to validate as explained in the proceeding sentences, but whether or not you use stir or this is part of the UNI interface that may not carry the stir protection, we want this guidance. I agree, this can’t be detected, but I think it’s important guidance for those that are building eco-system/implementation policies that can and likely will enforce this.  This was important property that only a single representation of RCD is received at the end-point (and touches on some of your other comments).

> 
> ## What is the behavior at the terminating side when more objects are present
> for 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.

Following the theme of your last comment, I don’t think there is a lot of motivation to define a deterministic behavior here other than potentially ignoring the jcard information. I don’t think we should give explicit advice to create an error condition or just pick the first one rather let the implementation and local policy determine how to impact the call. 
It simply doesn’t make sense to use the capability of jcard to include multiple and was clarified and added based on other review comments which i think was correct.  
I could add a qualifier:  "Because the use and purpose of this specification is to provide a single presentation of rich call data information, a call and its corresponding …” 

> 
> ## Is there a chance that this can be a clickable text? If so, can we say that
> the display should not be clickable, by default?
> 
> CURRENT:
>   As a general guideline, this message SHOULD be no longer
>   than 64 characters; displays that support this specification may be
>   forced to truncate messages that cannot fit onto a screen.  This
>   message conveys the caller's intention in contacting the callee.  It
>   is an optional parameter, and the sender of a SIP request cannot
>   guarantee that its display will be supported by the terminating
>   endpoint
> 

That’s a valid comment, i can add that guidance.
"In general, use of strings that could be forms of URIs or other potential strings that could be used or interpreted as a 'clickable' action is discouraged."

> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> # Minor/nits
> 
> ## (general) I would change “calling parties” with “initiating parties”,
> “called parties” with “terminating parties”, and “incoming calls” with
> “incoming sessions”.

I do acknowledge this struggle, i do note that you’ve provided a lot of these corrections in your comments below, so i did fix those suggestions, but didn’t check for every case.  In general “calling/called party” is sort of a term of art where “initiating/terminating parties” is less used would be my argument.

> 
> ## (general) (*) there are many examples given with EN US, are other languages
> supported in such text parts (see the example below)? I hope as I’d like to
> have ⵎⵓⵃⵎⵎⴰⴷ ⴱⵓⵇⴷⴰⵢⵔ or محمد بوقداير supported :
> 
> CURRENT:
>  ["fn", {}, "text", "Mr. John Q. Public\, Esq."]

Sounds like a great goal which i agree with the sentiment, but I can’t commit to add unicode examples this at this stage and a tight turnaround.

> 
> ## Title: s/ SIP Call-Info Parameters for Rich Call Data/ SIP Call-Info
> Parameters for Rich Call Data (RCD)
> 
> ## Abstract: simplify + generalize “call” + fix the “answer the phone”
> 
> OLD:
>   This document describes a usage of the SIP Call-Info header field
>   that incorporates Rich Call Data (RCD) associated with the identity
>   of the calling party in order to provide to the called party a
>   description of the caller or details about the reason for the call.
>   RCD includes information about the caller beyond the telephone number
>   such as a calling name, or a logo, photo, or jCard object
>   representing the caller, which can help the called party decide
>   whether to answer the phone.  The elements defined for this purpose
>   are intended to be extensible in order to accommodate related
>   information about calls and to be compatible and complementary with
>   the STIR/PASSporT RCD framework.
> 
> NEW:
>   This document describes a usage of the SIP Call-Info header field
>   that incorporates Rich Call Data (RCD) associated with the identity
>   of the originating party in order to provide to the terminating party a
>   description of the caller (including details about the reason for the
>   session). RCD includes information about the caller beyond the telephone
>   number such as a calling name, a logo, photo, or jCard object representing
>   the caller, which can help the called party decide how to handle the session
>   request.

Fixed

> 
> ## Introduction
> 
> (1) As another new parameter is already introduced separately and given that
> the abstract says 3, consider:
> 
> s/this document defines two new/this document defines two other new
> 
> (2) s/the concept of successful verification/successful verification
> 
> (3) “SIP network or the SIP provider”: remind these concepts.


Fixed

> 
> # Section 3
> 
> (1) s/In this document, provide a/ This document provides a
> 
> (2) s/guided by two things/guided by two aspects
> 
> (3) “and manipulation of data on IP networks”: may be the scope of the claim is
> too wide :-) I personally don’t think the full sentence is needed to justify
> the use of JSON.
> 
> (4) s/ parameter 'call-reason' provides a string or other object that conveys/
> parameter 'call-reason' conveys
> 
> (5) s/[I-D.ietf-stir-passport-rcd] in Section 8.2/Section 8.2 of
> [I-D.ietf-stir-passport-rcd]
> 

Fixed

> # Section 4
> 
> (1) s/SIP-based call involves/SIP-based session involves
> 
> (2) s/[RFC3261], Section 20.9 defines/Section 20.9 of [RFC3261] defines

Fixed

> 
> # Section 5
> 
> (1)
> 
> CURRENT
>   Alternatively, the URI
>   MUST define the use HTTPS or a transport that can validate the
>   integrity of the source of the resource as well as the transport
>   channel through which the resource is retrieved.
> 
> I don’t parse what is meant in the first part of this sentence.

Included the following alternative wording: "Alternatively, the Call-Info header field URI MUST use a transport that can validate the integrity of the source of the resource (e.g HTTPS tied to a specific validated domain)."

> 
> (2)
> 
> CURRENT:
>   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.
> 
> What is the behavior at the terminating side when more are present? (*)

This is discussed above.

> 
> (3)
> 
> CURRENT:
>      Date: Fri, 25 Sep 2015 19:12:25 GMT
> 
> It smells like this was grabbed from other RFCs ?), but updating the date to
> match the publication date would make sense. Also, this would be consistent
> with the other examples. Thanks.

Fixed

> 
> # Section 6
> 
> Consider simplifying (there are other similar constructs)
> 
> OLD:
>   This specification defines a new parameter that extends the overall
>   content of the RCD-related Call-Info header field.  As other
>   parameters may be defined in the future, this
> 
> NEW:
>   This parameter

Fixed

> 
> # Section 7
> 
> (1) Already stated, please simplify
> 
> OLD: This specification defines an additional new parameter, the 'verified'
> parameter NEW: The 'verified' parameter
> 
> (2) simplify
> 
> OLD: This parameter is to be used to indicate
> NEW: This parameter indicates
> 
> (3) (several occurrences)
> 
> OLD: [I-D.ietf-stir-passport-rcd] Section 8
> NEW: Section 8 of [I-D.ietf-stir-passport-rcd]
> 
> (4) s/NNI network relationship to/NNI

Fixed

> 
> # Section 8
> 
> Consider simplifying:
> 
> OLD:
>   This specification defines an additional new parameter, the
>   'integrity' parameter, that extends and complements the integrity
>   information conveyed specifically by the 'rcdi' claim in the RCD-
>   related Call-Info header field.  This parameter is intended to be
> 
> NEW:
>   The 'integrity' parameter extends and complements the integrity
>   information conveyed specifically by the 'rcdi' claim in the RCD-
>   related Call-Info header field.  This parameter is

Fixed

> 
> # Section 9
> 
> (1) Is there any provisioning required to make use of the extensions? Are there
> logs for session that were rejected because the reason does not match, etc.? (*)

The management of Rich Call Data does require a lot of provisioning and validation of information upfront which the industry is currently building and offering commercial solutions for branded calling, so yes if i understand your question.
The mechanism i’m aware of is that a stir ‘rcd’ PASSporT is received and that is translated into the call-info header to transport the rich call data into the UNI toward the end user device.  Theoretically it’s the responsibility of the end customer provider to do that correctly and they should match, unless they have local policies that may change that, but there is no standards defined logging or anything currently.  Hopefully that is what you are asking.

> 
> (2) On the “generally” part, ere there cases where this is not followed?
> 
> CURRENT:
>   The procedures for the usage of URIs and 'purpose' parameter tokens
>   should generally follow the procedures defined in [RFC3261].

Removed the word generally :)

> 
> # Section 10
> 
> (1)
> 
> Please fix the following and add a reference for Base64 encoding:
> 
> OLD:
>   For the use of the 'purpose' token "icon" or for the cases where the
>   jCard either incorporates URIs or includes digital images and sounds
>   directly via Base64 encoding, we provide recommendations
> 
> NEW:
>   For the use of the 'purpose' token "icon" or for the cases where the
>   jCard either incorporates URIs or includes digital images and sounds
>   directly via Base64 encoding, this document provides

Fixed with a little more color

> 
> (2)
> 
> OLD: (e.g., 16 bit, 8 bit, or 1 bit)
> NEW: (e.g., 16-bit, 8-bit, or 1-bit),
> 
> (3) I don’t think the part with “future” is needed. I would keep only the first
> part:
> 
> CURRENT:
>   jCard is an extensible object;
>   therefore, there may be future specifications that extend the set of
>   properties relevant to the applications that implement this
>   specification.
> 
> 
> 
Fixed