Subject: [sipcore] Target URI and History Info bis

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 24 Apr 2009 11:31:10 +0300

Hi,

discussions about the target URI and history info bis work has focused 
too much on the historical background and not enough on the best way to 
proceed with this work. I would like to have discussions on what we 
think would be the best and fastest way to specify what needs to be 
specified.

Mary claims that having the following draft tackle both the target URI 
issue and the revision of History Info would be the fastest and cleanest 
way to be done with everything we want to specify.

http://tools.ietf.org/html/draft-barnes-sip-rfc4244bis-00

Others claim that tackling the target URI issue in an independent draft 
that does not depend on the revision of History info would be the 
fastest way to proceed with the target URI issue.

http://tools.ietf.org/html/draft-rosenberg-sip-target-uri-delivery-01

I would like to hear opinions on how we should proceed and why. I would 
prefer to get reasons related to clearness of the specifications, speed 
of the process, etc., instead of about the historical background on 
these two drafts.

Thanks,

Gonzalo

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 24 Apr 2009 10:36:16 +0100

I would prefer to move forward with a single draft covering all the
enhancements necessary to History-Info.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
> Sent: 24 April 2009 09:31
> To: SIPCORE
> Subject: [sipcore] Target URI and History Info bis
> 
> Hi,
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 24 Apr 2009 09:18:48 -0500

Just one clarification, I do not necessarily think there should be one
document - my primary concern has been that normative History-Info
header processing should be in a single document. Even in that case, it
might still be useful to have target-uri provide the usecases and
details as to how those use cases are accomodated using History-Info -
i.e., informational.  

As far as keeping the normative text in target-URI, that increases the
potential for inconsistencies and there will be duplication of text to
comprehensively describe the use of the extensions - what's in the
document right now is incomplete. And, the point about speed is really
moot IF the WG can agree the scope of changes to 4244 now - i.e., if we
can agree we will make normative changes to support target-uri and keep
the other core History-Info requirements, there is no problem. There is
an error in the ABNF that should be fixed and we've already discussed a
few other issues such as making a recommendation not to apply privacy to
the entire message. And, that change is really required to support
target-uri. So, I believe that if you were to complete the target-uri
solution in a separate document, you will find more things like this at
which time the most sensible thing to do would be to bis 4244. So, to
me, it seems much easier to make the decision now.

The changes to add a tag to support target-uri are minimal, but they
have been carefully integrated into the current processing for RFC 4244.
Note, this does not yet address the point about privacy above, which
will be added to the revision.  The other changes to 4244 were
previously summarized along with target-uri changes in an email that
Shida sent that was from him and myself:
http://www.ietf.org/mail-archive/web/sip/current/msg26880.html

As I previously sent to the list, here's the diff between 4244 and
4244bis:
http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/rfc/rfc4244.tx
t&url2=http://tools.ietf.org/id/draft-barnes-sip-rfc4244bis-00.txt

And, please note that the normative text for handling what's called the
"retarget" tag in 4244bis is a superset of that in the target-uri
document - i.e., the normative functionality in target-uri was pulled
into 4244bis with additional text added to complete the solution. 

Personally, I don't think we need to debate documents as much as we need
to discuss the issues that were summarized in the email and that
Francois attempted to discuss during the meeting
Issue 1: Marking hi-entries
Issue 2: Pruning of hi-entries
Issue 3: TLS

And, these are pretty much the same points that we tried to get
discussed in the threads before the meeting, with a little discussion
post-meeting on SIP WG mailing list.  Issue 1 is really the most
important as that's what is needed for the target-uri uses cases and
that gets us into the terminology issue. 

The issue folks have with the current security in RFC 4244 (Issue 3
above) is that the bar is higher than it is for any other header (that's
where we get into the "history" of "History-Info").  It would be nice if
the WG could agree that this text can be loosened slightly - i.e., TLS
RECOMMENDED vs mandated.  There is the slightest amount of wiggle room
in there now, but it's not obvious. The plan is to make the changes in
the next version. 

And, I honestly have a hard time understanding why folks are so
resistant to updating an RFC that was published 4 years ago.  This is
the norm, is it not, to update documents that have been out for a while
once we have more implementation experience and additional use cases to
consider?  

Regards,
Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Gonzalo Camarillo
Sent: Friday, April 24, 2009 3:31 AM
To: SIPCORE
Subject: [sipcore] Target URI and History Info bis

Hi,

Thanks,

Gonzalo

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 24 Apr 2009 10:36:19 -0500

I agree with John.

Document fragmentation for something like History-Info will result
in implementations that are not interoperable. I can not imagine
anybody would want to implement Target-URI on top of the current
4244, and then do a bis.

Here is what I propose on how to go FORWARD:

1) There is a bunch of non-controversial things we agreed to in 
San Francisco that I can tackle right away on 4244bis (cleanup 
stuff), starting on Monday. Nothing controversial.

2) Then, I would say the highest priority will be rolling in
the agreed-to content of Target-URI into 4244bis. Again, I
don't believe there is anything controversial (this will 
cover only the "last hop" original intent of Target-URI).

3) And then last, the marking of or mid-stream redirect. That's
I believe the only place where there is still some issues
to sort out.

By following those steps in that order, I think we can
achieve progress. The reason I'm confident about this
is that the thorny topic (3) is not blocking the non-thorny
ones (1-2). 

> [mailto:[email-masked]] On Behalf Of Elwell, John
> Sent: Friday, April 24, 2009 02:36
> To: Gonzalo Camarillo; SIPCORE
> Subject: Re: [sipcore] Target URI and History Info bis
> 
> I would prefer to move forward with a single draft covering 
> all the enhancements necessary to History-Info.
> 
> John
> 
> > too much on the historical background and not enough on the 
> best way 
> > to proceed with this work. I would like to have discussions 
> on what we 
> > issue and the revision of History Info would be the fastest and 
> > cleanest way to be done with everything we want to specify.
> > 
> > Others claim that tackling the target URI issue in an independent 
> > draft that does not depend on the revision of History info would be 
> > the fastest way to proceed with the target URI issue.
> > 
> > 
> > I would like to hear opinions on how we should proceed and why. I 
> > would prefer to get reasons related to clearness of the 
> > specifications, speed of the process, etc., instead of about the 
> > historical background on these two drafts.
> > 
> > Thanks,
> > 
> > Gonzalo
> >

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 24 Apr 2009 11:36:25 -0500

2) is already done based on current target-uri content and honestly, I
think it makes no sense to add anything more normative to that document
since it is less than what is in 4244bis.  We just need to change the
name of the tag to whatever. 

I agree 3) is the remaining issue from a technical perspective as long
as we can agree that updates to the security are covered by 1).

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Audet, Francois (SC100:3055)
Sent: Friday, April 24, 2009 10:36 AM
To: Elwell, John; Gonzalo Camarillo; SIPCORE
Subject: Re: [sipcore] Target URI and History Info bis

I agree with John.

Document fragmentation for something like History-Info will result in
implementations that are not interoperable. I can not imagine anybody
would want to implement Target-URI on top of the current 4244, and then
do a bis.

1) There is a bunch of non-controversial things we agreed to in San
Francisco that I can tackle right away on 4244bis (cleanup stuff),
starting on Monday. Nothing controversial.

2) Then, I would say the highest priority will be rolling in the
agreed-to content of Target-URI into 4244bis. Again, I don't believe
there is anything controversial (this will cover only the "last hop"
original intent of Target-URI).

3) And then last, the marking of or mid-stream redirect. That's I
believe the only place where there is still some issues to sort out.

By following those steps in that order, I think we can achieve progress.
The reason I'm confident about this is that the thorny topic (3) is not
blocking the non-thorny ones (1-2).

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 24 Apr 2009 11:35:17 -0500

Yes, I'm just saying let's roll it into 4244bis. 

> From: Barnes, Mary (RICH2:AR00) 
> Sent: Friday, April 24, 2009 09:36
> To: Audet, Francois (SC100:3055)
> Cc: SIPCORE
> Subject: RE: [sipcore] Target URI and History Info bis
> 
> 2) is already done based on current target-uri content and 
> honestly, I think it makes no sense to add anything more 
> normative to that document since it is less than what is in 
> 4244bis.  We just need to change the name of the tag to whatever. 
> 
> I agree 3) is the remaining issue from a technical 
> perspective as long as we can agree that updates to the 
> security are covered by 1).
> 
> Mary. 
> 
> [mailto:[email-masked]] On Behalf Of Audet, 
> Francois (SC100:3055)
> Document fragmentation for something like History-Info will 
> result in implementations that are not interoperable. I can 
> not imagine anybody would want to implement Target-URI on top 
> of the current 4244, and then do a bis.
> 
> 1) There is a bunch of non-controversial things we agreed to 
> in San Francisco that I can tackle right away on 4244bis 
> (cleanup stuff), starting on Monday. Nothing controversial.
> 
> 3) And then last, the marking of or mid-stream redirect. 
> That's I believe the only place where there is still some 
> issues to sort out.
> 
> achieve progress. The reason I'm confident about this is that 
> the thorny topic (3) is not blocking the non-thorny ones (1-2). 
>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 24 Apr 2009 22:42:43 +0200

Lets finish the target-uri document first independently, before dragging 
it into another endless 4244bis discussion. It can focus on the topic 
for which it was created.

If 4244bis can work on the other issues it seems to instantiated for and 
it is ready in time, we can always decide to merge the then provided 
target-uri solution in to 4244bis.

This would speed up the process as several people have expressed that 
they need the target-uri solution in due time. The target-uri draft has 
a very clear scope, the 4244bis seems an open ended attractor for 
History-Info issues...

Best Regards,
/Hans Erik

Gonzalo Camarillo wrote:
> too much on the historical background and not enough on the best way 
> to proceed with this work. I would like to have discussions on what we

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 24 Apr 2009 15:54:38 -0500

Just to re-iterate once more, 4244bis already contains a superset of the
normative text for History-Info header from the current target-uri
document.  Francois has proposed a fairly straightforward path for
4244bis that should allow us to avoid any of the hurdles and open ended
debates as to History-Info issues - the known issues are quite
straight-forward to solve and the issues at hand really are providing a
solution for target-uri.  The idea that the target-uri document would
progress much quicker than 4244bis is a red herring - in particular
based on my comments that you need more changes to 4244 to support
target-uri than just the new tags. 

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hans Erik van Elburg
Sent: Friday, April 24, 2009 3:43 PM
To: Gonzalo Camarillo
Cc: SIPCORE
Subject: Re: [sipcore] Target URI and History Info bis

Best Regards,
/Hans Erik

---

From: Dean Willis <[email-masked]>
Date: Fri, 24 Apr 2009 16:57:04 -0500

On Apr 24, 2009, at 3:31 AM, Gonzalo Camarillo wrote:

> Hi,
>
> discussions about the target URI and history info bis work has  
> focused too much on the historical background and not enough on the  
> best way to proceed with this work. I would like to have discussions  
> on what we think would be the best and fastest way to specify what  
> needs to be specified.

I'd like to take this back to getting a clear statement on what needs  
to be SOLVED, rather than what needs to be specified. I strongly  
suspect we have lost track of our mission as we progressed through the  
vast labyrinth of complexity that litters our back-trail.

So let's go back to the fundamental problem and see if we can regain  
consensus on what we're trying to fix.

One model of application structure derives from the way that HTTP CGI  
applications are written. In this model, the request-URI encodes not  
only the target (in this case, the application), but also any  
parameters being delivered to the application.

For example, let's take the expansion of a URL I recently sent to the  
sipcore list:

http://snurl.com/ghlt8

which expands into (yes, the lines are going to get wrapped by the  
email system)

http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-sipcore-subnot-etags-00.txt&url2=http://tools.ietf.org/id/draft-ietf-sipcore-subnot-etags-02.txt

Here the application-identifying portion of the URL is "http://tools.ietf.org/rfcdiff 
". The first parameter is "url1=http://tools.ietf.org/id/draft-ietf-sipcore-subnot-etags-00.txt 
" and the second is "url2=http://tools.ietf.org/id/draft-ietf-sipcore-subnot-etags-02.txt 
". The application (which you can exercise with a browser) generates a  
side-by-side diff of the two IETF-style documents referenced by the  
URLs that are sent as parameters.

In SIP, we might encode the parameters onto the request URI slightly  
differently, but the same basic approach applies. This philosophy of  
application design is described in RFC 3087.

This approach works very nicely for SIP applications that are directly  
addressable. RFC 2543 broke it for any SIP applications that required  
traversing a proxy to reach the application, because RFC 2543 rather  
stupidly (and yes, I complained about it at the time) rewrote the  
request-URI on every proxy hop. We sort of fixed this in RFC 3261 with  
"loose routing", but it was STILL broken for any target that used  
"contact routing", that is, where the contact stored by a registrar  
replaced the AOR in the request URI.

This defect made URI application and parameter encoding useless for  
most user-to-user applications, because somewhere in there, a contact- 
routing proxy is probably going to replace the request-URI and break  
things.

Jonathan's ua-loose-route draft was an attempt to fix the problem by  
making SIP proxies stop rewriting the request URI entirely. We thought  
this wasn't all that backward compatible (it's hard to be backward  
compatible with something that's pretty much broken), so it didn't  
make the cut. We've also proposed that the destination might be able  
to retrieve the original URI and parameters from the seething mass of  
History-Info entries and parameters, but that's also unappetizing in  
certain respects.

So what was the original goal again? We're trying to convey, from UAC  
to UAS  enough information about an application to enable the UAS to  
select the correct application and pass the request to that  
application, along with any parameters supplied by the UAC. And we're  
trying to do this in a way that survives all sorts of proxy  
processing, It doesn't have to survive redirect processing, UNLESS a  
proxy acts on the redirect on behalf of the UAC. And we're trying to  
do it in a way that doesn't require extending the SIP specification  
for every new application, because even though we know our layering  
model is all messed up, we don't really want to make it exponentially  
worse.

This basic problem of "application invocation" keeps coming up again  
and again. The whole service-indicator context-guessing thing is tied  
up in it. Explicit service indicators encoded as SIP extensions are  
VERY VERY BAD, because they tie the SIP protocol to the application in  
ways that keep requiring us to extend SIP to support new applications.  
Consider what would have happened to the world wide web if it required  
an HTTP extension for every new web application. Going down that path  
would be profoundly stupid, which we mostly know and have been trying  
to avoid.

We've further complicated the problem with the idea that maybe  
middleboxes (ala proxies or SBCs) might need to "meddle" with the  
application-to-application information. The main problem here is that  
there are really two sorts of applications: those in the middle, that  
operate by rewriting the app-to-app information, and those on the  
ends, that rely on pristine app-to-app information. Prevent  
interactions between these two sorts of applications is IMPOSSIBLE, as  
their scopes, by definition, overlap.

Consider for example the interaction of a speed-dial application with  
a voicemail application. The speed dial application might take "sip:[email-masked] 
", when the authenticated user is "[email-masked]", and  
translate it to "sip:[email-masked]". This works fine --  
it;s an easy string replacement at the proxy, we can code it in CPL,  
and so on.

But assume that the voice-mail application needs parameters For  
example, let's say that it has "record" and "play" modalities, and "sip:[email-masked]&play 
" tells it to play my messages, whereas "sip:[email-masked]&record 
" tells it to record a new greeting. Barring subtle variations on  
parameter-encoding separators (we're still arguing about how that  
works), this is easy to implement in a voice-mail server. But the  
speed-dial application is going to break it. Trying to figure out  
which, if any, parameters need to be copied from the incoming request- 
URI and into the outgoing request-URI is difficult. Given that we've  
encoded some of the application context in the user-part (voicemail- 
dean vs voicemail-alice) , the problem is an even bigger furball.

So here's my suggestion: Let's stop arguing about history-info, ua- 
loose-route, diversion, etc. and go back to the REAL underlying  
problem: How, in a consistent, predictable, and programmable way, do  
we pass application context from UAC to UAS? And we need to pay  
attention to the inversely-related question: What limitations do we  
allow the transport-support mechanism (proxies, sbcs, whatever) do we  
expect to place on the expressive range of this mechanism?

Here's a hint: HTTP clearly defines what the transport-support  
mechanisms (proxies) can and cannot do. With HTTPS proxies, they can't  
do much except convey the info end to end. So HTTP applications can  
use request URI for parameter passing, they can use SOAP, they can use  
AJAX to funnel XML back-and-forth over a long lived connection, and so  
on. HTTP applications can do all this without adding new HTTP methods,  
new HTTP headers, new HTTP request types, and so on. So the HTTP model  
is, I argue "That which is not reserved to the HTTP protocol is  
available to the application".

What's the SIP model? Is it possible to define one that is backward  
compatible with the hash we've made of our applications space with all  
these app-specific functions in our transport protocol?

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 27 Apr 2009 08:28:39 +0200

Hi,

I can't remember that, when we agreed to use H-I for target delivery, a
"precondition" would have been that we also must update 4244. I DO
support the work on 4244bis, but that is a separate issue.

Mary, could you please re-indicate why the target-uri draft doesn't work
with 4244?

Regards,

Christer

> [mailto:[email-masked]] On Behalf Of Mary Barnes
> Sent: 24. huhtikuuta 2009 23:55
> To: Hans Erik van Elburg; Gonzalo Camarillo
> Cc: SIPCORE
> Just to re-iterate once more, 4244bis already contains a 
> superset of the normative text for History-Info header from 
> the current target-uri document.  Francois has proposed a 
> fairly straightforward path for 4244bis that should allow us 
> to avoid any of the hurdles and open ended debates as to 
> History-Info issues - the known issues are quite 
> straight-forward to solve and the issues at hand really are 
> providing a solution for target-uri.  The idea that the 
> target-uri document would progress much quicker than 4244bis 
> is a red herring - in particular based on my comments that 
> you need more changes to 4244 to support target-uri than just 
> the new tags. 
> 
> Mary. 
> 
> [mailto:[email-masked]] On Behalf Of Hans Erik van Elburg
> Lets finish the target-uri document first independently, 
> before dragging it into another endless 4244bis discussion. 
> It can focus on the topic for which it was created.
> 
> If 4244bis can work on the other issues it seems to 
> instantiated for and it is ready in time, we can always 
> decide to merge the then provided target-uri solution in to 4244bis.
> 
> This would speed up the process as several people have 
> expressed that they need the target-uri solution in due time. 
> The target-uri draft has a very clear scope, the 4244bis 
> seems an open ended attractor for History-Info issues...
> 
> Best Regards,
> /Hans Erik
> 
> Gonzalo Camarillo wrote:
> > Hi,
> >

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 27 Apr 2009 08:37:44 -0500

Christer,

Based on your response in the first paragraph, I'm not sure I understand
your second question, since you seem to be agreeing with the approach
I've been suggesting in terms of putting the normative text to support
the requirements and use cases identified in the target-uri in 4244bis.

As far as my email response below, I'm not so much saying that the
target-uri draft currently doesn't work with 4244, so much as that the
current solution in terms of normative History-Info text is incomplete.
In my opinion, to add enough text to make that solution complete, and
alter the normative text for the Privacy header to ensure you actually
get the headers, requires bringing in additional text for context from
4244. In the end you would need to at least "update" 4244, so my
suggestion is to start with 4244bis now and save ourselves some pain
down the road. So, I'm disagreeing with the suggestion that it is so
much faster to progress target-uri than 4244bis.

Mary. 

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Monday, April 27, 2009 1:29 AM
To: Barnes, Mary (RICH2:AR00); Hans Erik van Elburg; Gonzalo Camarillo
Cc: SIPCORE
Subject: RE: [sipcore] Target URI and History Info bis

Hi,

Regards,

Christer

> Just to re-iterate once more, 4244bis already contains a superset of 
> the normative text for History-Info header from the current target-uri

> 4244bis that should allow us to avoid any of the hurdles and open 
> ended debates as to History-Info issues - the known issues are quite 
> straight-forward to solve and the issues at hand really are providing 
> a solution for target-uri.  The idea that the target-uri document 
> would progress much quicker than 4244bis is a red herring - in 
> particular based on my comments that you need more changes to 4244 to 
> support target-uri than just the new tags.
> 
> Mary. 
> 
> Lets finish the target-uri document first independently, before 
> dragging it into another endless 4244bis discussion.
> If 4244bis can work on the other issues it seems to instantiated for 
> and it is ready in time, we can always decide to merge the then 
> provided target-uri solution in to 4244bis.
> 
> they need the target-uri solution in due time.
> The target-uri draft has a very clear scope, the 4244bis seems an open

> ended attractor for History-Info issues...
> 
> Best Regards,
> /Hans Erik
> 
> Gonzalo Camarillo wrote:
> > Hi,
> >

---

From: Adam Roach <[email-masked]>
Date: Mon, 27 Apr 2009 10:59:07 -0500

[as a participant]

Dean:

You've described about half the requirements (getting parameters from a 
UAC to a UAS). There is a complementary, and just as important, set of 
requirements we need to keep in mind: getting the parameters to the UAC 
in the first place.

I'll use your analogy. While it's possible, it's not very likely that 
you manually typed 
"http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-sipcore-subnot-etags-00.txt&url2=http://tools.ietf.org/id/draft-ietf-sipcore-subnot-etags-02.txt 
" into a web browser somewhere. In all likelihood, that was generated 
programmatically by some web application, and sent to your browser in an 
HTML body somewhere.

In SIP, of course, we don't have HTML bodies. We have Contact header 
fields, Refer-To header fields, information in UA profiles, and a large 
number of similar constructs. They uniformly contain SIP URIs.

So, for the other half of this puzzle, we need to make sure that the 
parameters you're talking about can be expressed as part of a SIP URI, 
so that they can be communicated to the UAC in the first place.

/a

Dean Willis wrote:
> Here the application-identifying portion of the URL is 
> "http://tools.ietf.org/rfcdiff". The first parameter is 
> "url1=http://tools.ietf.org/id/draft-ietf-sipcore-subnot-etags-00.txt" 
> and the second is 
> "url2=http://tools.ietf.org/id/draft-ietf-sipcore-subnot-etags-02.txt". The 
> application (which you can exercise with a browser) generates a 
> most user-to-user applications, because somewhere in there, a 
> contact-routing proxy is probably going to replace the request-URI and 
> break things.
>
> a voicemail application. The speed dial application might take 
> "sip:[email-masked]", when the authenticated user is 
> "[email-masked]", and translate it to 
> "sip:[email-masked]". This works fine -- it;s an easy 
> string replacement at the proxy, we can code it in CPL, and so on.
>
> example, let's say that it has "record" and "play" modalities, and 
> "sip:[email-masked]&play" tells it to play my messages, 
> whereas "sip:[email-masked]&record" tells it to record a 
> new greeting. Barring subtle variations on parameter-encoding 
> separators (we're still arguing about how that works), this is easy to 
> implement in a voice-mail server. But the speed-dial application is 
> going to break it. Trying to figure out which, if any, parameters need 
> to be copied from the incoming request-URI and into the outgoing 
> request-URI is difficult. Given that we've encoded some of the 
> application context in the user-part (voicemail-dean vs 
> voicemail-alice) , the problem is an even bigger furball.
>
>
> So here's my suggestion: Let's stop arguing about history-info, 
> ua-loose-route, diversion, etc. and go back to the REAL underlying

---

From: Dean Willis <[email-masked]>
Date: Mon, 27 Apr 2009 14:44:59 -0500

On Apr 27, 2009, at 10:59 AM, Adam Roach wrote:
> parameters you're talking about can be expressed as part of a SIP  
> URI, so that they can be communicated to the UAC in the first place.
>

Ah, but they can. It's not any harder than doing it with HTTP. We just  
don't use it much since it doesn't work well due to contact-routing.

Instead, we use all sorts of ugly hacks with new SIP headers and  
protocol extensions.

That's why SIP WG never had a charter item on expressing the  
parameters as part of the URI, just on fixing the transport mechanism.

--
Dean

---

From: Adam Roach <[email-masked]>
Date: Mon, 27 Apr 2009 15:45:02 -0500

Dean Willis wrote:
> Ah, but they can.

With the mechanisms under discussion, yes, they can. But you stripped it 
down to base principles. Your summary missed this aspect of the problem. 
I could easily design mechanisms that meet the requirements you state, 
but would be cumbersome to encode in a URI (e.g., encoding parameters in 
request body, a la HTTP POST requests).

I just want to make certain that we don't end up taking things in that 
direction.

/a

---

From: Dean Willis <[email-masked]>
Date: Mon, 27 Apr 2009 19:29:15 -0500

On Apr 27, 2009, at 3:45 PM, Adam Roach wrote:

>>> URI,
> With the mechanisms under discussion, yes, they can. But you  
> stripped it down to base principles. Your summary missed this aspect  
> of the problem. I could easily design mechanisms that meet the  
> requirements you state, but would be cumbersome to encode in a URI  
> (e.g., encoding parameters in request body, a la HTTP POST requests).
>
> I just want to make certain that we don't end up taking things in  
> that direction.

The URI-parameter approach is one we got from HTTP, and have had a  
rough standing consensus on all along, but it hasn't achieved world  
domination by any means.

And given that the URI mechanism in RFC 3261 is "just broken", if we  
assume a backwards-compatibility requirement, it may well be that some  
other mechanism might be more suitable. So, despite my having been a  
long-standing proponent of the URI approach, I now have to say that  
I'd be open to considering an alternative.

For example, perhaps slapping user-to-user parameters into a new  
header field (as Alan proposed for UUI) or into a body part WOULD be  
easier than untangling the spider-web of URI revisions that could  
ostensibly be stacked-up in using History-Info. Do we need to have an  
entire SVN revision history on the parameter set as it traverses the  
SIP relay chain? Certainly we COULD solve the parameter problem  
thusly, but is it the best way?

Certainly H-I is a reasonable approach of the problem is "knowing  
everything that has happened to the Request-URI". However, that's one- 
step removed from what I think the actual problem is (delivery of  
parameters to the application). I think we've lost focus on that  
underlying problem in our quest for a solution, and I think this is  
why we've gotten all wrapped around the axle in our debate.

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 28 Apr 2009 07:09:53 +0200

Hi Mary,

To clarify, I think we can work on both documents at the same time.

Regards,

Christer

> From: Mary Barnes [mailto:[email-masked]] 
> Sent: 27. huhtikuuta 2009 16:38
> To: Christer Holmberg; Hans Erik van Elburg; Gonzalo Camarillo
> Cc: SIPCORE
> Based on your response in the first paragraph, I'm not sure I 
> understand your second question, since you seem to be 
> agreeing with the approach I've been suggesting in terms of 
> putting the normative text to support the requirements and 
> use cases identified in the target-uri in 4244bis.
> 
> 
> As far as my email response below, I'm not so much saying 
> that the target-uri draft currently doesn't work with 4244, 
> so much as that the current solution in terms of normative 
> History-Info text is incomplete.
> In my opinion, to add enough text to make that solution 
> complete, and alter the normative text for the Privacy header 
> to ensure you actually get the headers, requires bringing in 
> additional text for context from 4244. In the end you would 
> need to at least "update" 4244, so my suggestion is to start 
> with 4244bis now and save ourselves some pain down the road. 
> So, I'm disagreeing with the suggestion that it is so much 
> faster to progress target-uri than 4244bis.
> 
> Mary. 
> 
> superset of 
> providing 
> instantiated for 
> expressed that 
> seems an open

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 28 Apr 2009 19:56:03 +0200

Hi,

I don't think the problem we are trying to solve is "delivery of
parameters", or "user-to-user parameters". The problem we are tying to
solve is to deliver the original target URI (which, of course, may
include parameters).

The proposal from me and Hans Erik could have been to use a dedicated
Target header. That would have solved the problem, only the problem and
nothing but the problem.

But, the discussion outcome, and WG decission, was then to use
History-Info. Good or bad, but that is the decission the WG made.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dean Willis
Sent: Tuesday, April 28, 2009 3:29 AM
To: Adam Roach
Cc: SIPCORE
Subject: Re: [sipcore] Long reply to: Target URI and History Info bis

> With the mechanisms under discussion, yes, they can. But you stripped 
> it down to base principles. Your summary missed this aspect of the 
> problem. I could easily design mechanisms that meet the requirements 
> you state, but would be cumbersome to encode in a URI (e.g., encoding 
> parameters in request body, a la HTTP POST requests).
>

---

From: Dean Willis <[email-masked]>
Date: Tue, 28 Apr 2009 18:02:46 -0500

> solve is to deliver the original target URI (which, of course, may

Why do we need to deliver the original target URI and its parameters?  
What useful purpose does this serve? Could that purpose be better  
served by a different mechanism?

> Target header. That would have solved the problem, only the problem  

Yet we know that sometimes, the "server in the middle" legitimately  
needs to replace some part of the parameter set.

> History-Info. Good or bad, but that is the decission the WG made.

I suspect a large part of the WG was confused by the discussion  
leading up to the decision point. We have a tendency to get caught up  
in polishing the bull's horn while we are being gored . . . the  
problem is not "the horn", it's the "standing in front of a charging  
bull" part..

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 29 Apr 2009 09:47:17 +0200

Hi, 

>>parameters", or "user-to-user parameters". The problem we 
>>are tying to solve is to deliver the original target URI (which, of
course, may 
>What useful purpose does this serve? 

Chapter 4 of the draft contains use cases where it is needed.

>Could that purpose be better served by a different mechanism?

I don't know. The proposals we had on the table were the ua-loose-route
draft and the target-draft, and then it was decided to use H-I.

Anyone could have provided different mechanism proposals. In fact, you
and/or Keith even explicitly gave a deadline for mechanism proposals, if
I remember correctly.

Regards,

Christer

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 29 Apr 2009 10:15:19 +0200

Dean,

I truely think that you are trying to solve a different problem then was set
out in the target-uri discussion. Of course this is a usefull discussion but
I think it deserves a separate draft/discussion item of its own.

Best Regards,
/Hans Erik van Elburg

On Wed, Apr 29, 2009 at 1:02 AM, Dean Willis <[email-masked]>wrote:

> Why do we need to deliver the original target URI and its parameters? What
> useful purpose does this serve? Could that purpose be better served by a
> different mechanism?
>
> Yet we know that sometimes, the "server in the middle" legitimately needs
> to replace some part of the parameter set.
>
> I suspect a large part of the WG was confused by the discussion leading up
> to the decision point. We have a tendency to get caught up in polishing the
> bull's horn while we are being gored . . . the problem is not "the horn",
> it's the "standing in front of a charging bull" part..
>
>
> --
> Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 29 Apr 2009 14:25:57 -0500

On Apr 29, 2009, at 3:15 AM, Hans Erik van Elburg wrote:

> Dean,
>
> I truely think that you are trying to solve a different problem then  
> was set out in the target-uri discussion. Of course this is a  
> usefull discussion but I think it deserves a separate draft/ 
> discussion item of its own.
>

That's possible. Historically, the target-URI discussion was started  
in order to solve the problem I set out initially many many years ago.  
It's possible I didn't clearly state the problem at that time, and  
that as a result we have been going down the wrong rabbit hole ever  
since.

--
Dean

---

From: Ben Campbell <[email-masked]>
Date: Wed, 29 Apr 2009 16:50:58 -0500

On Apr 27, 2009, at 2:44 PM, Dean Willis wrote:

>> So, for the other half of this puzzle, we need to make sure that  
>> the parameters you're talking about can be expressed as part of a  
>> SIP URI, so that they can be communicated to the UAC in the first  
>> place.
>>
>
> Ah, but they can. It's not any harder than doing it with HTTP. We  
> just don't use it much since it doesn't work well due to contact- 
> routing.
>

Assuming you mean to say that, if we choose to send application  
parameters in some non URI mechanism (e.g. new headers, bodies, etc),  
we can still encode that in URIs, in the same way you can encode any  
arbitrary SIP bits into a URI?

If so, that is true--but it makes for an insanely complicated URI, and  
I wouldn't bet on any given UA handling it correctly.

---

From: Dean Willis <[email-masked]>
Date: Wed, 29 Apr 2009 19:28:05 -0500

On Apr 29, 2009, at 4:50 PM, Ben Campbell wrote:

> parameters in some non URI mechanism (e.g. new headers, bodies,  
> etc), we can still encode that in URIs, in the same way you can  
> encode any arbitrary SIP bits into a URI?
>
> If so, that is true--but it makes for an insanely complicated URI,  
> and I wouldn't bet on any given UA handling it correctly.

No, not what I was saying. I was saying that we know how to encode  
arbitrary things in the request URI (without encoding them as embedded  
headers in the request URI) , which makes me sure that what Adam  
called  "the parameters you're talking about" can be expressed as part  
of a SIP URI.  If we can express the parameters in any way, then we  
can express them as parts of SIP Request-URI , since Request-URI is  
linguistically complete and has a well-defined grammar for encoding  
things.

I believe what Adam was worrying about was the specification of those  
things which I wish to encode as parameters; that is, that they be  
specified as parameters and not as body parts, header fields, or  
something else. We in fact have an IANA registry for just exactly this  
task.

Let's cast this back in the light of my 11+ year-old fight with the  
Diversion header -- I thought it should have been encoded in the  
Request-URI, not encoded in a transport-layer header field. Making it  
a header field conflated the application with the transport. We should  
not have needed to extend SIP as a transport protocol and modify the  
core SIP ABNF just to handle this new application.  I feel this way  
about a LOT of the functionality we've grafted onto SIP through the  
years, or are still talking about grafting on. The "service  
identifier"  is one example that comes to mind.

--
Dean

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 30 Apr 2009 11:38:22 +0200

Overloading in general is not a good design strategy, why do you think 
that trying to mold everything (diversion/history info) into Request URI 
is a good idea??

The problem here is that this information has nothing to do with 
application invocation, but tells something about how the signalling 
reached the callee (target). And this information is only relevant to 
the callee if that decides that it is.

/Hans Erik

Dean Willis wrote:
>>> just don't use it much since it doesn't work well due to 
>>> contact-routing.
>>>
>>

---

From: Dean Willis <[email-masked]>
Date: Thu, 30 Apr 2009 12:30:05 -0500

On Apr 30, 2009, at 4:38 AM, Hans Erik van Elburg wrote:

> Overloading in general is not a good design strategy, why do you  
> think that trying to mold everything (diversion/history info) into  
> Request URI is a good idea??

The reason that we're having this conversation is that we have  
proposals, History-Info being one, for 1) putting our parameters in to  
the original request-URI, and 2) recovering that original request-URI  
after it has been contact-routed (and otherwise mangled) so that the  
parameters can be used at the UAS.

So the presumption exists that the original request URI is useful to  
the UAS. SIP did, and now SIPCORE has, a chartered item for making  
that happen.

I'm trying to back up and make sure that we know WHY we're trying to  
deliver the original request URI to the UAS, and then asking if some  
other approach that meets the same requirements might actually be  
easier to do.

> reached the callee (target). And this information is only relevant  
> to the callee if that decides that it is.

That's a profound philosophical assertion. HTTP, for example, makes no  
consideration for "how the signaling reaches the target" in  
determining how to process a request. The fact that some think SIP  
should take this into consideration indicates to me that we have a  
layering problem in our design.

 From one perspective, this makes the application invocation implicit;  
the UAS has to guess what to do based on clues sprinkled throughout  
the communication and across several layers of the ISO stack. It's  
much better to have this sort of determination made based on explicit  
indicators at a single application layer.

--
Dean

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 30 Apr 2009 20:51:47 +0200

> other approach that meets the same requirements might actually be 
That is fine of course, but the point is that we are not talking about 
delivering parameters to an application, but about recovering a complete 
URI that has gone lost on the way.
> layering problem in our design.
I don't think SIP and HTTP are comparable at all in this respect. In 
HTTP you directly address the server that you like to get (post, delete, 
update) information from. In SIP you adress the URI of a user, that will 
lead you to the home proxy in most cases and which is then forwarded to 
the UAS by overwriting the Request URI.

No layering problem, just a flaw in SIP's design that causes usefull 
information to be destroyed for no good reason. We're just trying to fix 
that, no more no less.
> indicators at a single application layer.
No. The goal of the target-uri discussion is to have all the relevant 
target-uri information readily available in the SIP request received by 
the UAS. That is all on the same OSI layer, layer 7.

/Hans Erik

---

From: Dean Willis <[email-masked]>
Date: Thu, 30 Apr 2009 20:30:53 -0500

> URI that has gone lost on the way.

but why exactly do we need to recover the URI? What is it that is
special about the URI or is likely to get used in some useful sort of
way downstream? If it isn't the "Request URI-ness" that is important,
maybe we can find some more convenient way to deliver that information.

> the UAS by overwriting the Request URI.

Well, HTTP has proxies too, and SIP were originally intended to be
comparable.

'> No layering problem, just a flaw in SIP's design that causes usefull
> the UAS. That is all on the same OSI layer, layer 7.

I disgaree -- the goal is to make the information that was encoded into
the requestURI (and maybe as modified by intermediates, that use case is
open) available to the UAS.

--
dean