Subject: Re: [sipcore] New Version Notification for draft-wendt-sipcore-callinfo-rcd-00.txt

From: Chris Wendt <[email-masked]>
Date: Sun, 17 Nov 2019 20:23:03 +0800

Hi All,

I’m cross posting this to both STIR and Sipcore mail lists.  For tomorrow’s STIR session we will be discussing the new draft-ietf-stir-passport-rcd draft.  As discussed in the last STIR virtual interim meeting, we have proposed a new Call-Info parameter specific to including “jcard” to support a more standard way of incorporating signed Rich Call Data, supporting compact form and other uses.  The link to this draft is included below.

Please have a look.  On the Sipcore side, we will want to discuss the adoption of this draft, but i think there is an overlap in audiences in both working groups, so hopefully we can start that discussion tomorrow.

Thanks!

-Chris

> On Nov 5, 2019, at 6:59 AM, [email-masked] wrote:
> 
> 
> A new version of I-D, draft-wendt-sipcore-callinfo-rcd-00.txt
> has been successfully submitted by Chris Wendt and posted to the
> IETF repository.
> 
> Name:		draft-wendt-sipcore-callinfo-rcd
> Revision:	00
> Title:		SIP Call-Info Parameters for Rich Call Data
> Document date:	2019-11-04
> Group:		Individual Submission
> Pages:		12
> URL:            https://www.ietf.org/internet-drafts/draft-wendt-sipcore-callinfo-rcd-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-wendt-sipcore-callinfo-rcd/
> Htmlized:       https://tools.ietf.org/html/draft-wendt-sipcore-callinfo-rcd-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-wendt-sipcore-callinfo-rcd
> 
> 
> Abstract:
>   This document describes a SIP Call-Info parameter defined to include
>   rich data associated with the identity of the calling party that can
>   be rendered to called party for providing more useful information
>   about the caller or the specific reason for the call.  This includes
>   extended comprehensive information about the caller such as what a
>   jCard object can represent for describing the calling party.  The
>   element defined for this purpose is intended to be extensible to
>   accommodate related information about calls that helps people decide
>   whether to pick up the phone and additionally with the use of jCard
>   be compatible with the STIR/PASSporT Rich Call Data framework.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 17 Nov 2019 16:07:32 +0000

Hi,

A few editorial comments/questions:

Q1: 

In the Abstract you say:

"This document describes a SIP Call-Info parameter defined to include rich data associated with the identity of the calling party..."

When reading the draft, it is unclear whether you are defining a new parameter, or a new parameter value/token  for the existing purpose parameter.

Q2: 

In Section 4 you  define the token, but it is not included in the example.

Q3:

In Section 5, where you describe the properties, you say "SHOULD be supported" and "MUST be supported". What does supported actually mean in this case? Does it mean that the property SHOULD/MUST be included in the JSON, and/or does it mean that the receiver SHOULD/MUST be able to render it to the called if included in the JSON?

Q4: 

The Call-Info header field can be included in both requests and responses. If the purpose of jcard is to provide information about the calling party then I assume it shall not be used in response? If so, I think it should be explicitly stated.

Regards,

Christer

On 17/11/2019, 20.23, "sipcore on behalf of Chris Wendt" <[email-masked] on behalf of [email-masked]> wrote:

    Hi All,

    
    Thanks!
    
    -Chris
    
    > until the htmlized version and diff are available at tools.ietf.org.
    
    _______________________________________________
    sipcore mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/sipcore

---

From: Chris Wendt <[email-masked]>
Date: Tue, 19 Nov 2019 11:39:30 +0800

Hi Christer,

Responses inline

> On Nov 18, 2019, at 12:07 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 

The intent was to define a new “purpose” parameter which is defined as “jcard” and defines the content of the URI to be specifically a jcard object intended for RCD.

> In Section 4 you  define the token, but it is not included in the example.

Sure i will expand examples, but we had a discussion about how to include content so i was a little vague there for first draft.

> In Section 5, where you describe the properties, you say "SHOULD be supported" and "MUST be supported". What does supported actually mean in this case? Does it mean that the property SHOULD/MUST be…

We talked about this at the STIR session.  I actually plan to take that section out and bring those definitions back to RCD and/or remove completely.  The intent here was to do some better definition of what UA could expect to receive and need to be able to render, but I think the consensus is that this is not the document to do it.

> The Call-Info header field can be included in both requests and responses. If the purpose of jcard is to provide information about the calling party then I assume it shall not be used in response?…

Yes thanks, it is only intended for requests.  Will clarify that.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 19 Nov 2019 04:47:07 +0000

Hi Chris,

    > The intent was to define a new “purpose” parameter which is defined as “jcard” and defines the content of the URI to be specifically a jcard object intended for RCD.

    Please make sure the document says that, and is consistent :)

    Personally I would also suggest to not use "token" terminology. Yes, it is mentioned once in RFC 3261, but in SIP we generally don't refer parameter values as "tokens".

    Regards,

    Christer