Subject: [Sip] RE: What does 3087 say (Was Re: [Simple] ad-hoc list subscription s)

From: "Mary Barnes" <[email-masked]>
Date: Thu, 20 Nov 2003 10:54:47 -0600

Ben,

I think rather than being taken private, this discussion needs to be
discussed in SIP (or SIPPING) since it is relevant to the History-Info draft
and I think it's this topic that has been one of the primary concerns folks
have had with this work.  Although, I want to clearly state that VM is not
at all the only use case we have for this and isn't the primary motivation
at this point (and it's unfortunate that it was the initial use case that we
had when we first approached this topic).

Mary. 

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]]
Sent: Thursday, November 20, 2003 10:31 AM
To: Jonathan Rosenberg
Cc: Paul Kyzivat; Cullen Jennings; Adam Roach; [email-masked];
Dean Willis; [email-masked]
Subject: Re: What does 3087 say (Was Re: [Simple] ad-hoc list
subscriptions)

As I commented in a previous note, this seems to be vearing a bit off 
topic for SIMPLE. I am trimming the simple list from this response. If 
anyone things this discussion is really relevant to the list at large, 
feel free to put it back.

More inline:

Jonathan Rosenberg wrote:

> 
> 
> Paul Kyzivat wrote:
> 
>>
>>
>> Ben Campbell wrote:
>>
>>>
>>> VM is sort of in a gray area, as I think there is room for all sorts 
>>> of interesting, non-conventional approaches. One _really_ big problem 
>>> facing carriers these days is difficulty in deploying new services. I 
>>> think this will be the death of some of the "conventional" telecom 
>>> carriers in the long run. 3087 is all about trying to make it easier 
>>> to create new (hopefully innovative) services. This was something 
>>> that my employer (at the time of the original writing) was really 
>>> worrying about.
>>
>>
>>
>> This makes a lot of sense, and I like the approach. But I can see how 
>> a supplier of VM systems would want to hedge its bets. This approach 
>> depends on the user having a configurable proxy that can select among 
>> all the VM alternatives. Much of the intelligence has been moved from 
>> the VM to the proxy.
> 
> 
> Well, this is perhaps the essence of the long standing dispute on 
> history vs. URI-invocation as the way to talk to voicemail systems.
> 
>>
>> That is great if the VM provider is also the proxy provider. It is 
>> also probably ok if all the possible proxy providers that the VM is 
>> likely to find itself deployed with provide that functionality. But 
>> today those aren't necessarily good assumptions. To hedge the bets, 
>> the VM provider will probably want to have an alternative way to 
>> discriminate the different services on its own.
>>
>> So the tricky part is getting all the pieces to a stage where they can 
>> smoothly interoperate with one another.
> 
> 
> The other issue is that, even if you dont standardize the syntax, and 
> leave that up to configuration, there needs to be common understanding 
> of the semantics. Going back to the VM case, if invocation of a 
> voicemail drop requires the VM server to get the subscriber ID, the 
> reason for the voicemail connection, and the desired prompt, there needs 
> to be sufficient logic in the proxy to extract that information from the 
> request and make sure it finds its way into the r-uri.
> 
> As such, I think the 3087 model only works for cases where the service 
> invocation is parameterless; i.e., its a pure proxy function, without 
> the need for the proxy to know how to pull information out of messages 
> or other context, and shove it into an r-uri.

The scenario you describe is _exactly_ what 3087 was intended to cover. 
In this particular case, the VM system associates a mailbox and menu 
tree entry point with a key, in the form of a specific, arbitrarily 
named URI. The only reason it needs to be encoded in the URI is for 
human-readability.

I agree with your comment for things like ad-hoc list exploders, in that 
the list membership cannot be known in advance, so it must be encoded in 
someway.

Also, to reiterate, there were 2 concepts in 3261. The first was to use 
the r-URI for this sort of things in the first place. The second was the 
arbitrariness of said URIs. Exploders can fit into the first concept, 
but not the second. So even here, 3087 partially applies.

> -Jonathan R.

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 20 Nov 2003 09:53:03 -0800

I think Jonathan really nailed this exactly right in the comment below.