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

From: Brett Tate <[email-masked]>
Date: Tue, 13 Jan 2015 12:59:14 -0500

Hi,

The following are some comments concerning
draft-kyzivat-dispatch-trs-call-info-purpose-00.

Thanks,
Brett

------

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

Section 2: Concerning the example, the sip-uri should be within brackets.

Section 2: Concerning the example, the original-identity should not be
within quotes.

Section 3 paragraph 1: Comparing it to an identify header (instead of
Contact) might be more accurate since it might be displayed to the user
and has a billing impact.  However, I guess that the same could be said
about Contact and they both can be spoofed.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Jan 2015 13:30:34 -0500

Brett,

Thanks for commenting.

> originated the header field and trusts that element."

So your concern is that with Call-Info the information might be rendered 
to the user?

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)

IMO using Call-Info for original-identity seems in line with the other uses.

> Section 2: Concerning the example, the original-identity should not be

Thanks for catching these. The fixes will be in the next version.

> about Contact and they both can be spoofed.

Yes. I think making an analogy to the Identity header would raise lots 
of other concerns that aren't appropriate here.

	Thanks,
	Paul

---

From: Brett Tate <[email-masked]>
Date: Wed, 14 Jan 2015 09:20:14 -0500

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.

> I don't think that is an important concern. Other purposes
> aren't intended for rendering. E.g.

At first glance, it seems like they are some that would potentially be
rendered to the user (directly or indirectly).

> IMO using Call-Info for original-identity seems in line with

I wasn't sure if you selected Call-Info for 1) potential rendering, 2)
better B2BUA traversal, or 3) some other reason.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Jan 2015 10:28:45 -0500

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

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

> 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