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

Hi Paul, All,

I have submitted a new version (-07) which I believe addresses all of the comments, but please let me know if there is any additional things.

Thanks!

-Chris

> On Aug 18, 2023, at 5:58 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> 
> Hi Chris,
> 
> A few followups below. I've removed everything I agreed with or had no comments on.
> 
> On 8/18/23 12:09 PM, Chris Wendt wrote:
> 
>>> * 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.
> 
> Can you add some words explaining the relationship, and how a recipient should proceed when receiving both? (Especially, if both contain a field with similar semantics.)
> 
>> I would also be open to using something like “rcd-jcard” if we want to make the distinction more clear.
> 
> I don't have an opinion on this.
> 
>>> 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
> 
> Can you add some text to explain this in the context of this document.
> 
> (Extra credit for coming up with general words that apply to all uses of Call-Info with arbitrary parameters.)
> 
>>> * Section 7:
>>> 
>>> I'm dubious of using a null data: URI with purpose=icon. ...
> 
> You cleaned this up with your followup message.
> 
> I think we should not assume the null data URI will work with all purpose values. Safer to assume its only valid with those that define how it works.
> 
> But I'm interested in hearing if others think I'm being overly paranoid.
> 
>>> 
>>> * 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.
> 
> Further clarification would be good. Also, is it recommended to provide multiple URIs with alternative formats and the same purpose? If so, is it to be assumed that all have the same semantics and the recipient can whichever supported one it prefers? (Similar to multipart/alternative.)
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore