Re: [dispatch] draft-kyzivat-dispatch-trs-call-info-purpose-00: comments

[Paul Kyzivat <[e-mail]>]

On 1/14/15 9:20 AM, Brett Tate wrote:
> Hi,
>
> Thanks for the response; reply is inline.
>
>>> General comment: It might be better to introduce a new header
>>> instead of using Call-Info.  For instance, is the following
>>> RFC 3261 section 20.9 recommendation acceptable for the new
>>> purpose value?
>>>
>>> "Therefore, it is RECOMMENDED that a UA only render the
>>> information in the Call-Info header field if it can verify the
>>> authenticity of the element that originated the header field
>>> and trusts that element."
>>
>> So your concern is that with Call-Info the information might be
>> rendered to the user?
>
> Actually, I couldn't tell from the draft if it was intended to be somehow
> rendered to the user or not.  Similarly I'm not sure if any clients render
> Call-Info values if the purpose is unknown.

AFAIK each call-info purpose is expected to be handled independently 
based on its individual definition. For the built-in ones it clearly is 
not intended that the URI itself be rendered as a string. Rather then 
intent is that the URI be dereferenced and rendered in a 
purpose-specific way. Without knowing what the purpose-specific way is, 
you can't do anything useful with it.

Presumably a receiving device that doesn't understand could decide to 
render the URI as a sort of "diagnostic". This is equally an issue for 
any newly specified purpose value.

>> I don't think that is an important concern. Other purposes
>> aren't intended for rendering. E.g.
>> - list-management (RFC5367)
>> - call-completion (RFC6910)
>> - impp (RFC6993) (Though this might end up being rendered indirectly)
>> - ccmp (RFC7082)
>
> At first glance, it seems like they are some that would potentially be
> rendered to the user (directly or indirectly).

As I noted above, that could be the case for impp, though a rich client 
will presumably simply use the URI to establish an xmpp session. 
Possibly the UI for the XMPP session might show that URI.

This seems much less likely for list-management and call-completion.

>> IMO using Call-Info for original-identity seems in line with
>> the other uses.
>
> I wasn't sure if you selected Call-Info for 1) potential rendering, 2)
> better B2BUA traversal, or 3) some other reason.

For better B2BUA traversal.

Do you have any suggestions on how to make this all clearer?

	Thanks,
	Paul