Subject: RE: [Sipping] Comment on request history discussion

From: "Mark Watson"<[email-masked]>
Date: Wed, 20 Mar 2002 10:33:58 -0000

Eric wrote:
>
> Now the implementation of the requirements, as so far 
> expostulated by the
> reason draft, isn't perfect, but that's an e-mail in that thread...
> 

Please don't jump to any conclusions about how request history might be
implemented. We are trying to be good citizens and follow the new
requirements process. Until the requirements are agreed, we should not start
discussing implementation (unless it clearly impacts back on the
requirements).

Once the requirements are agreed, we start by evaluating existing solutions
(re-use is usually better than re-invention) and if none of those are
suitable, we look for new ideas.

...Mark

---

From: "Mark Watson"<[email-masked]>
Date: Wed, 20 Mar 2002 10:24:24 -0000

Robert wrote:
> 
> 1) Some want to be able to build a composite service that 
> does all kinds
> of interesting stuff based on information in a SIP request other than
> what's in the RURI. There is concern there that the SIP request isn't
> providing enough information to do that, and a claim that the 
> work that
> it would take to put that in the RURI is prohibitively complicated.
> 
> 2) Some want to be able to decompose that same composite service into
> functional elements, some which provide decision logic, 
> others which do
> the legwork (possibly nesting these). There is concern there that the
> ability to develop/deploy distributed services will be hindered by the
> additional mechanisms being asked for by those in 1.
> 
> There are valid calls for being able to do both kinds of things and it
> would shock me if everyone here didn't agree we should be able to do
> both _AS LONG AS_ the mechanisms created to enable one does 
> not prevent
> reasonable development of the other.
> 
> The recent decoupling of the history requirements goes a long way
> towards making sure we can find the right way to carry good 
> information
> without promoting a particular service architecture over another and
> urge folks to focus on ensuring this property.

I agree - the above is a better characterisation. To be completely clear, it
is my view that both approaches (1) and (2) are needed in SIP and of course
one should not hinder development of the other.

Regards...Mark