Subject: [sipcore] #4: The new "hit" parameter is gonna cause problems

From: "sipcore issue tracker" <[email-masked]>
Date: Wed, 25 Aug 2010 23:46:41 -0000

#4: The new "hit" parameter is gonna cause problems
------------------------------------+---------------------------------------
 Reporter:  hkaplan@…               |       Owner:            
     Type:  defect                  |      Status:  new       
 Priority:  major                   |   Milestone:  milestone1
Component:  rfc4244bis              |     Version:  2.0       
 Severity:  In WG Last Call         |    Keywords:            
------------------------------------+---------------------------------------
 If I understand it right, this draft creates a new SIP/SIPS URI param
 named "hit", whose value indicates the type of H-I entry that will be
 added when processing the SIP/SIPS URI as a target.  It's used in the
 Contact-URI of a 3xx, or location service database entries, to
 differentiate registered-contact targets vs. mapped targets, right?  In
 other words, it's a way to signify when the retargeting is simply routing
 to the same identity vs. diverting to a new identity, right?  (I am
 inferring this, since there's no text I can find that actually just says
 that in a simple sentence)

 If so, it's got issues.  First, it assumes the processor of the 3xx
 response actually understands the new param - if a legacy proxy sends a
 request to a H-I-capable redirect server, and the redirect server encodes
 this "hit" param in the contact-uri of the 3xx, bad things happen.
 Second, it accounts for SIP/SIPS but not TEL URIs.  Third, it should be a
 header param not a URI param, I think (which would solve the previous
 issues).

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/sipcore/trac/ticket/4>
sipcore <http://tools.ietf.org/sipcore/>

---

From: Mary Barnes <[email-masked]>
Date: Sat, 28 Aug 2010 17:03:13 -0500

I do not think that this URI parameter will cause the problems you
mention - responses inline below [MB].

> #4: The new "hit" parameter is gonna cause problems

[MB] The parameter is only used in the Contact-URIs in the 3xx
response.  The current text is intended to imply that  the URI
parameter is set in the same manner that the target element is
determined, but we can add more text here to clarify that.  The reason
this has to be done by the Redirect server is that it is the one that
knows the mechanism by which those entries are determined.  The URI
parameter is used by proxies that implement 4244bis to determine the
value for the target parameter when it uses the specific contact-URI
to build an hi-entry. In this manner all the hi-entries have the same
format - i.e., you don't use the value of the URI parameter in the
hi-entries.[ /MB]
>  this "hit" param in the contact-uri of the 3xx, bad things happen.
[MB] I'm not at all clear about what bad things you think might
happen. If the proxy has not implemented 4244bis, then the URI
parameter is ignored (and may be removed by the proxy as can any URI
parameter). But, that doesn't provide any less functionality since a
proxy that only implements 4244 will NOT use the target  URI parameter
anyways and a proxy that doesn't implement History-Info at all totally
ignores the parameter.  [/MB]

>  Second, it accounts for SIP/SIPS but not TEL URIs.
[MB]  The value for this URI parameter is determined by the same
mechanisms by which the target parameter is determined by a proxy when
accessing a location service database.  So, it's not clear to me why
this URI parameter introduces a specific problem for tel-URIs.  [/MB]

> Third, it should be a

[MB] It's not at all clear to me why you think this needs to be a
header parameter or how such would solve the problems you anticipate
(although that's because I don't understand what problems you think
will happen with the current approach).[/MB]

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Aug 2010 08:53:19 -0400

[as individual]

> this URI parameter introduces a specific problem for tel-URIs.  [/MB]

TEL URIs can't have URI parameters in the way that SIP URIs can.

> will happen with the current approach).[/MB]

IMO its a red flag any time there is talk about a URI parameter that is 
only to be used when that URI is present in a particular header. That is 
a case that instead calls for a header parameter. Having it be a URI 
parameter then raises all sorts of questions about what should happen if 
that parameter appears in the URI in some other context.

(We've been seeing that problem a lot with TEL URI parameters.)

	Thanks,
	Paul

---

From: "sipcore issue tracker" <[email-masked]>
Date: Tue, 31 Aug 2010 15:47:19 -0000

Comment(by worley@…):

 "hit" is defined as a URI-parameter on the Contact values in 3xx
 responses, but in reality, it is metadata *describing* the URI, not *part*
 of the URI.  Naively it would seem that "hit" should be a header
 parameter.

 This change would require some parallel changes in the description of
 proxy functioning.

 This change would remove some processing steps in which the "hit" URI-
 parameter value is removed from the URI portion of the Contact value.

 This change would also aid backward compatibility, in that a proxy that
 does not understand 4244bis that receives a 3xx response with a Contact
 header that contains a "hit" header parameter would automatically not
 transfer the "hit" value to the request-URIs of further forked requests.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/sipcore/trac/ticket/4#comment:1>
sipcore <http://tools.ietf.org/sipcore/>