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

From: "Elwell, John" <[email-masked]>
Date: Wed, 1 Sep 2010 10:16:31 +0200

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of sipcore issue tracker
> Sent: 31 August 2010 18:45
> To: [email-masked]
> Cc: [email-masked]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 2 Sep 2010 16:08:06 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Elwell, John [[email-masked]]

There seem to be two separate "operations" in H-I:

1. a UAS echos in the response the H-I in the request

2. an element updates the H-I in the request, which includes

   2.a. adding an additional hi-entry if the incoming request-URI is not the one specified in the H-I, which itself includes:

      2.a.1. adding an initial H-I with one hi-entry if the request does not contain one

   2.b. inserting an updated H-I into outgoing proxied requests

I've been assuming that both 1 and 2 are triggered by the presence of "Supported: histinfo".  But since the text is unclear, I might be wrong.  Indeed, there is no strong reason that elements that support H-I might not perform both actions even if "Supported: histinfo" is not present, as the presence of H-I in a request or response would not affect the behavior of an element that does not support it.

Dale

---

From: Mary Barnes <[email-masked]>
Date: Thu, 2 Sep 2010 15:25:35 -0500

Supported was intended to be used strictly speaking as John noted -
i.e., to indicate whether or not the History-Info entries should be
included in responses in particular whether or not the UAC would need
the information.  However, it was also listed as one of the criteria
by which a Proxy might decide to add History-Info in RFC 4244 in
section:
 "  Whether a proxy adds the
   History-Info header or a new hi-entry as it forwards a Request
   depends upon the following considerations:

      1. Whether the Request contains the "histinfo" option tag in the
         Supported header.
....

4244bis pretty much removes the concept that it's optional for a proxy
that supports 4244bis as to whether it adds History-Info entries
except as it relates to privacy.

I don't have an issue with the notion that we also remove the use of
supported in terms of whether or not the History-Info is included in
responses.  As noted, an entity that doesn't understand it would just
ignore it.

Mary.

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 2 Sep 2010 21:05:07 -0400

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

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 3 Sep 2010 08:47:11 +0200

This raises the question whether the option tag is needed at all. What harm would be done by removing the option tag?

John 

> From: Worley, Dale R (Dale) [mailto:[email-masked]] 
> Sent: 03 September 2010 02:05
> To: Elwell, John
> Cc: [email-masked]
> Subject: RE: [sipcore] #27: Functionality of "Supported: 
> histinfo" is not clear
> 
> From: [email-masked] [[email-masked]] On 
> Behalf Of Elwell, John [[email-masked]]
> 
> 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
>

---

From: Shida Schubert <[email-masked]>
Date: Fri, 3 Sep 2010 23:33:51 +0900

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

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 3 Sep 2010 10:43:06 -0400

________________________________________
From: Elwell, John [[email-masked]]

To some extent we're constrained by compatibility with RFC 4244.  Even if we wanted to eliminate histinfo, UACs would still need to include "Supported: histinfo" to cause 4244-but-not-4244bis proxies to do H-I processing.

Dale

---

From: Mary Barnes <[email-masked]>
Date: Fri, 3 Sep 2010 09:48:54 -0500

Yes, you would need it in the case that a proxy might only be
capturing HI if the supported tag is there. But, that's not mandatory
behavior.   However, it does no harm to keep the tag to ensure
backwards compatibility - it's just that a 4244bis proxy would just
ignore it.

Mary.