Re: [sipcore] #27: Functionality of "Supported: histinfo" is not clear

My understanding is that the presence of Supported: histinfo triggers the UAS to send back H-I in the response. The issue that Dale raises makes me wonder whether H-I should unconditionally be echoed in the response, since proxies and B2BUAs might find a use for it, even if the UAC does not request it. A UAC that does not support H-I would just ignore the header field anyway.

John

> -----Original Message-----
> From: sipcore-bounces@ietf.org 
> [mailto:sipcore-bounces@ietf.org] On Behalf Of sipcore issue tracker
> Sent: 31 August 2010 18:45
> To: worley@alum.mit.edu
> Cc: sipcore@ietf.org
> Subject: [sipcore] #27: Functionality of "Supported: 
> histinfo" is not clear
> 
> #27: Functionality of "Supported: histinfo" is not clear
> ---------------------------------+----------------------------
> --------------
>  Reporter:  worley@...             |       Owner:     
>      Type:  defect               |      Status:  new
>  Priority:  major                |   Milestone:     
> Component:  rfc4244bis           |     Version:     
>  Severity:  In WG Last Call      |    Keywords:     
> ---------------------------------+----------------------------
> --------------
>  The functionality of "Supported: histinfo" is not clear.  It 
> seems that
>  the intention is for it to activate History-Info processing, 
> but there is
>  no generalized statement of that and some of the H-I 
> processing is not
>  explicitly conditionalized on the presence of "Supported: histinfo".
>  E.g., the proxy processing is not conditionalized, and 
> adding a H-I header
>  to an incoming request that does not have one appears to be 
> unconditional.
> 
> -- 
> Ticket URL: <http://trac.tools.ietf.org/wg/sipcore/trac/ticket/27>
> sipcore <http://tools.ietf.org/sipcore/>
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> 