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

[Paul Kyzivat <[e-mail]>]

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

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

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

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

The same issues arises for "jcard".

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.

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

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

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

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

	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