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

[Keith Drage <[e-mail]>]

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.

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