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

[Mohamed Boucadair via Datatracker <[e-mail]>]

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?

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

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

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


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# Minor/nits

## (general) I would change “calling parties” with “initiating parties”,
“called parties” with “terminating parties”, and “incoming calls” with
“incoming sessions”.

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

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

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

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

# 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

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

(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? (*)

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

# 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

# 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

# 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

# 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.? (*)

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

# 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

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