Re: [sipcore] #28: UACs should add H-I if they implement it

This makes sense to me.

John 

> -----Original Message-----
> From: sipcore-bounces@ietf.org 
> [mailto:sipcore-bounces@ietf.org] On Behalf Of sipcore issue tracker
> Sent: 31 August 2010 18:49
> To: worley@alum.mit.edu
> Cc: sipcore@ietf.org
> Subject: [sipcore] #28: UACs should add H-I if they implement it
> 
> #28: UACs should add H-I if they implement it
> ---------------------------------+----------------------------
> --------------
>  Reporter:  worley@...             |       Owner:            
>      Type:  defect               |      Status:  new       
>  Priority:  major                |   Milestone:  milestone1
> Component:  rfc4244bis           |     Version:            
>  Severity:  In WG Last Call      |    Keywords:            
> ---------------------------------+----------------------------
> --------------
>  In section 4.1 is:
> 
>      Normally, UACs are not expected to include a 
> History-Info header in an
>  initial request as it is more of a Proxy function; the main 
> reason it is
>  allowed is for B2BUAs who are performing proxy-like functions such as
>  routing.
> 
>  This is not a good idea; a UAC that wants History-Info should add the
>  initial hi-entry.  The reason is that the UAC does not know 
> that the next
>  proxy that will modify the request-URI implements H-I; if 
> the UAC does not
>  provide an hi-entry, the UAS won't see the original request-URI.
>  Conversely, adding "History-Info: <[request-URI]>;index=1" 
> is not much
>  more work than adding "Supported: histinfo", which we 
> already assume the
>  UAC will do.
> 
> -- 
> Ticket URL: <http://trac.tools.ietf.org/wg/sipcore/trac/ticket/28>
> sipcore <http://tools.ietf.org/sipcore/>
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> 