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

[[e-mail]]

Hi Chris, 

Thank you for the follow-up.

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Chris Wendt <[e-mail]>
> Envoyé : jeudi 10 avril 2025 18:07
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> Cc : The IESG <[e-mail]>; draft-ietf-sipcore-callinfo-
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-sipcore-
> callinfo-rcd-16: (with DISCUSS and COMMENT)
> 
> 
> 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.
> 

[Med] ACK, thanks.

> 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.)
> >
> >
> > ----------------------------------------------------------------
> > 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.

[Med] Any comment about this part? :-)

> 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 …"

[Med] This rewording is better. Thanks.

Still, because we "provides an overlapping functionality for non-emergency cases", I think we need to have a guidance about which one takes precedence if it happens that both are enclosed or say whether we discard such use. 

> 
> >
> > ## 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.

[Med] Great.

  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.
> 

[Med] From what you explained, removing would be the simple fix in such case, then. 

> >
> > ## 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).

[Med] I also agree this is important to meet as external behavior. However, as you mentioned this can't be detected. We need at least say that fact in the text. I wouldn't push much to discuss mitigations, though. 

> 
> >
> > ## 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 …”

[Med] Wfm

> 
> >
> > ## 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."
> 

[Med] Thanks

> >
> > ----------------------------------------------------------------
> > 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.

[Med] ACK

> 
> >
> > ## (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.
> 

[Med] ACK.

> >
> > ## 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

[Med] Thanks

> 
> >
> > ## 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

[Med] OK

> 
> >
> > # 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

[Med] ACK

> 
> > # 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
> 

[Med] ACK

> >
> > # 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)."

[Med] This is better. "s/e.g/e.g.,"

Thanks.

> 
> >
> > (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.
> 

[Med] ACK

> >
> > (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

[Med] Thanks.

> 
> >
> > # 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

[Med] ACK

> 
> >
> > # 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

[Med] ACK

> 
> >
> > # 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
> 

[Med] ACK

> >
> > # 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.

[Med] Can we please include text among these lines into the draft?

> 
> >
> > (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 :)

[Med] You escape the question. Ha ha ha

> 
> >
> > # 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
> 

[Med] Thanks.

> >
> > (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

[Med] Thanks.


____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.