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

[Paul Kyzivat <[e-mail]>]

Brett,

Thanks for commenting.

On 1/13/15 12:59 PM, Brett Tate wrote:
> 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."

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 sip-uri should be within brackets.
>
> Section 2: Concerning the example, the original-identity should not be
> within quotes.

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

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

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

	Thanks,
	Paul