Subject: Re: [sipcore] Long reply to: Target URI and History Info bis

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Sun, 3 May 2009 15:42:59 -0400

Hello

I agree with Christer, there was clear consensus on the path forward for this issue, no opposition.

Martin

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Dean Willis <[email-masked]>; Hans Erik van Elburg <[email-masked]>
Cc: SIPCORE <[email-masked]>
Sent: Sun May 03 14:00:28 2009
Subject: Re: [sipcore] Long reply to:  Target URI and History Info bis

Hi,

I think the why-is-this-needed questions should have been asked when we
decided to start working on this in the first place. And, again, the
different drafts that have been produced on this topic DO describe
different use-cases.

Regarding the solution, again, we had a long discussion about it, argued
about different alternatives, and finally decided to go for a H-I based
solution.

I am sure there are other ways to do this than using H-I, but everybody
had his/her chance to participate in the beauty contest on which
solution to choose, so at this point I don't think we should revise our
decission - unless it can be shown that the H-I based solution doesn't
work. 

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dean Willis
Sent: Friday, May 01, 2009 4:31 AM
To: Hans Erik van Elburg
Cc: SIPCORE
Subject: Re: [sipcore] Long reply to: Target URI and History Info bis

Hans Erik van Elburg wrote:
> 
> 
> Dean Willis wrote:
>>
>> 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.
>>
> 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.

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 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.
>>
>>
>> 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.
>>
> 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.

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
> information to be destroyed for no good reason. We're just trying to 
> fix that, no more no less.
>> 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.
>>
> 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.
> 

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
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore