Re: [sipcore] WGLC: draft-ietf-sipcore-callinfo-rcd-06

[Chris Wendt <[e-mail]>]

Hi Paul, 

Thanks for the review responses inline:

> On Aug 14, 2023, at 11:37 AM, Paul Kyzivat <[e-mail]> wrote:
> 
> I haven't looked carefully at this for a long time. The wglc prompted me to look again. I noticed the following things worth bringing up:
> 
> * Section 3 - "currently":
> 
>   The Call-Info header field, defined in [RFC3261] Section 20.9,
>   defines a purpose parameter currently with "info", "icon", and "card"
>   tokens. ...
> 
> The "currently" above is not right. RFC3261 was first to define this and defined those three mentioned values. But many additional values have been subsequently defined by other RFCs.
> 
> I suggest omitting ", defines a purpose parameter currently with "info", "icon", and "card" token".
> 
> (Unfortunately no specific IANA registry was ever set up listing the defined values or the purpose parameter. Instead, each new RFC that defines a value has been updating the IANA SIP Parameters registry by adding another RFC number to the list of RFCs referenced in the registry for the Call-Info purpose parameter.)

I agree, I will remove those words.  I also see that Brian has started another thread for establishing an IANA registry.  I would prefer not holding up this document, but certainly support that idea.

> 
> * Section 3 - jcard vs
> 
> This section also explains why it is defining "jcard" rather than using "card". But something isn't clear to me about this:
> 
> Is the intent that "jcard" replace the use of "card", or are the two intended to coexist and be used for carrying differing data? If they are to coexist, how are they to be reconciled?

The intent was to coexist, the text in 3261 is a bit loose, vcard and LDIF formats are referenced as examples.
I think the point might be that this document is saying that jcard references the RCD flavor of jcard defined in this document.  If we agree with that interpretation and using jcard for this document definition only vs jcards more generally (where i think “card” could be used), i can make that explicit.
I would also be open to using something like “rcd-jcard” if we want to make the distinction more clear.

> 
> * Section 4, 1st paragraph
> 
> This has similar text to that in the intro, using "currently". In this case I suggest simply removing the word "currently".

Agree

> 
> * Section 6, multiple appearances of info-params
> 
> The syntax for Call-Info is defined in RFC3261 has info-params such as "purpose" and "call-reason" bound to individual URIs within the Call-Info header. Hence if there are multiple Call-Info headers or multiple URIs per Call-Info, then there could be multiple instances of the "call-reason" parameter, and they might be bound to the same or different URIs and may or may not be alongside a purpose parameter.
> 
> It isn't evident what these different usages might mean or how they are intended to be used. Some additional specification is needed. For instance, you might specify that "call-reason" SHOULD only appear once per sip request, or that when there are more than one all but the first are to be ignored.

Yes i can clarify that, i think the intent is to only have one set of RCD information per call and one Call-Info related to RCD.

> 
> The same issues arises for "jcard".

Will clarify as above.

> 
> Also, is there significance to "purpose=jcard" and "call-reason" appearing with the same URI, vs appearing with separate URIs?
> 
> Perhaps call-reason should only be allowed alongside certain values of purpose.

This was the intent, purpose is associated with URI before it, and call-reason is a related but separate parameter.
The intent was that the RCD info would be contained on the same Call-Info header, but similar to above i can clarify that and make that restriction if we agree on this.

> 
> (Some of this ambiguity should have been specified in 3261 in the base definition of Call-Info. But it wasn't, so its up to explicit usages to pick up the slack.)

agree

> 
> * Section 7:
> 
> I'm dubious of using a null data: URI with purpose=icon. There may be existing implementations supporting purpose=icon that will choke on this. I think it would be better not to use this as an example. You are free to specify how a null data: URI works in conjunction with purpose=jcard. Then you could use that in your example.

There was a lot of past discussion on this, including Henning and others.  I think at the end, null data URI seemed to be clearest/most pragmatic path forward.  We thought about a URI to MIME body with essentially “null" and other thoughts, but i think they also have potential implementation issues too.  I would hope that most implementations that see a data: URI would know to at least ignore if they don’t support, but your point was part of those past discussions as well.

> 
> * Section 8.2 - Usage of multimedia data:
> 
> I'm troubled by this section. I'm especially confused about which of these "requirements" apply to the sender vs. the receiver. What are receivers to do when they are unable to understand or render the data they receive? What should senders do in order to best support an arbitrary recipient?
> 

I know this is an often debated thing in IETF, but we wanted to provide some guidance.  “icon” in 3261 basically says nothing about formats, i’d prefer not getting into codec debates etc :) but i think the text represents a baseline that most would not debate at this point since it’s all widely supported in OS’s/browsers/many devices. I can put some text to clarify your specific questions above and make it very optional support, we are just trying to give some baseline guidance.  

> * Section 8.3:
> 
> In addition to talking about cardinality of properties per jcard, I think there is need to talk about the cardinality of references to multiple jcards? Is it valid for there to be references to multiple jcards? If so, how should they be interpreted? (This is similar to the issue of coexisting "jcard" and "card".)

Yes, agree, in the context of a specific call,  “rcd” both this document and passport extension spec is intending there will only be one “rcd” object describing the caller.  The terminal should not have to make a decision on multiple “rcd” objects (which is different than deciding what objects in the “rcd” it can render to the user (e.g. a phone with a text only display will choose to not render a logo/photo).  I will make sure that is clear.

> 
> 	Thanks,
> 	Paul
> 
> On 8/10/23 6:58 PM, A. Jean Mahoney wrote:
>> Hi all,
>> This starts the Working Group Last Call of draft-ietf-sipcore-callinfo-rcd-06. Please provide any feedback before August 25th.
>> https://datatracker.ietf.org/doc/draft-ietf-sipcore-callinfo-rcd/
>> Thanks!
>> Jean
>> _______________________________________________
>> sipcore mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sipcore
> 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>