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

 I agree with Mary about not having an issue 
with removing the "use of supported + hist-info option tag" 
to request h-i in response. 

 Regards
  Shida

On Sep 3, 2010, at 3:47 PM, Elwell, John wrote:

> This raises the question whether the option tag is needed at all. What harm would be done by removing the option tag?
> 
> John 
> 
>> -----Original Message-----
>> From: Worley, Dale R (Dale) [mailto:dworley@avaya.com] 
>> Sent: 03 September 2010 02:05
>> To: Elwell, John
>> Cc: sipcore@ietf.org
>> Subject: RE: [sipcore] #27: Functionality of "Supported: 
>> histinfo" is not clear
>> 
>> ________________________________________
>> From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On 
>> Behalf Of Elwell, John [john.elwell@siemens-enterprise.com]
>> 
>> 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.
>> _______________________________________________
>> 
>> Indeed, and you've reminded me that a proxy that receives H-I 
>> in a response may well integrate it into the H-I of the 
>> corresponding request and send that in further forks of the 
>> request.  So I think we're pretty well demonstrating that 
>> even if the UAC doesn't understand H-I, other elements may be 
>> using it to pass information to each other.
>> 
>> Dale
>> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore