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

[Brett Tate <[e-mail]>]

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

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