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

[Paul Kyzivat <[e-mail]>]

th,Kei

On 8/14/23 12:35 PM, Keith Drage wrote:
> Even at this late stage, there is nothing that prevents this i-d 
> requesting a new IANA registry and populating with all the currently 
> defined values from other RFCs. As the IANA information is essentially 
> informative (i.e. just an instruction to IANA on how to treat and 
> document requests), it does not require additional review, nor an 
> amendment of the other RFCs that have added values..
> 
> Rather the WG would need to decide whether the creation of a new 
> registry is justified, i.e. to prevent duplicate registrations, and also 
> to decide whether any modifed registration criteria for new values is 
> required.

While I think it would be good if there were a registry of purpose 
values, I am undecided whether the value of having it is worth the 
hassle of setting it up. (And, if it is to be done, whether it should be 
done by this document.) I'd be interested in hearing what others think.

As is usually the case, the desirability is highlighted each time a new 
document defines a new value. But in every case the act of doing so is a 
distraction for the authors of the document.

	Thanks,
	Paul

> Keith
> 
> On 14/08/2023 16:37, Paul Kyzivat 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.)
>>
>> * 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
>>
>> _______________________________________________
>> sipcore mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sipcore
> 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore