Subject: RE: [Simple] ad-hoc list subscriptions

From: Adam Roach <[email-masked]>
Date: Mon, 17 Nov 2003 18:57:00 -0600

Ben Campbell [mailto:[email-masked]] writes:
>
> Adam Roach wrote:
> 
> > Paul Kyzivat [mailto:[email-masked]] writes:
> > 
> > 
> >>[U]nless there is an agreement on how to standardize 
> >>servers (by name or whatever), there isn't really much need to 
> >>standardize *anything* about this behavior - even the name of the 
> >>parameter (list=). It perhaps just becomes some sort of best 
> >>practices or informational draft.
> > 
> > 
> > I came to the same conclusion. I think I like that fact.
> > 
> 
> I don't think this affects the need for standardization one way or 
> another. We can standardize that the R-URI designates the application 
> receiving the request, and leave the rest open. 

Isn't that precisely what RFC 3087 already says?

> But we could also decide that a particular application (e.g.
> subscribing to an add-hoc list) is sufficiently interesting when
> interoperable to standardize that application.

I could easily see a standards-track document that defines
semantics for a "list" parameter on a SIP URI (i.e. it points
to a URI that, when dereferenced, contains a list of recipients
that the application being invoked knows how to handle). Would
that accomplish what you want to do?

/a

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

---

From: Ben Campbell <[email-masked]>
Date: Mon, 17 Nov 2003 20:31:39 -0600

> that accomplish what you want to do?

My point was not that we need to standardize anything. It was to say 
that deciding to structure things this way, and deciding if anything 
needs to be standardized, are mostly orthagonal decisions. It seemed 
like we were going down the path of saying that, if we make this 
decision, we don't have to standardize anything. If that is a true 
statement, then we probably didn't need to standardize anything before, 
either.

I suspect I am stating something so obvious that the act of stating it 
causes confusion. Nevermind.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 17 Nov 2003 20:31:39 -0600

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 19 Nov 2003 07:10:50 -0800

Several people have mentioned my previous VM-URI draft demonstrated a
completely lack of understanding of 3087 on my part. This is true - I don't
think I fully get what is says. So help me understand in context of this
ad-hoc subscription stuff....

I think you are suggesting that Customer A might configure their phones and
proxies to use a URI like

[email-masked]

Customer B might configure them to be

[email-masked]

Customer C might use

fluffy%40cisco.com;[email-masked]

Customer D might use

exploder:to=fluffy%40cisco.com:to=[email-masked]

And the proxies and UA are coning to be arbitrarily configurable to support
all of these in a way that the administrator understands even when they all
come from different vendors. Just look a the problems caused by configuring
the most trivial of dial plans in phones today.

I really hope this is not what 3087 recommended, because if it does, I
suspect it will never pass the running code test. Can you imagine what the
manual for the proxy would like that explained to some network administrator
how to do this, It's just not practical. What about a phone that formed
composites sets of names differently depending on where it was going to
request the same service from.

If you think the ad-hoc lists or exploders idea is useful, then we should
work out a convention for doing it. I don't care if it is in a body, header,
or URI.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 19 Nov 2003 07:10:50 -0800

Customer C might use

Customer D might use

---

From: Ben Campbell <[email-masked]>
Date: Wed, 19 Nov 2003 11:48:31 -0600

3087 has two major ideas. The first is, application behavior can be 
controlled by the r-URI. This is basically an extension of the idea that 
the r-URI designates the resource for the request. This is controversial 
in some areas, but not so much as the other idea.

The second idea is that the _customer_ owns the namespace, not the 
equipment vendor. A large customer, like a major carrier will most 
likely have an existing provisioning system that will build and enforce 
said namespace. The large carrier will expect a hardware device to be 
remotely provisionable by automata, and will write code to actually talk 
to specific devices. In a lot of cases, this is done by screen-scraping 
a console, but other approaches can work. (Note that Robert and I were 
at Worldcom when we wrote the draft that became 3087...)

So, from that perspective, imagine I have some proxies from vendor A, 
and some VM boxes from B and C. I want my provisioning system to be able 
to add voice mail for a user, and except for the physical mechanism of 
talking to the devices, I don't to think too much about which VM vendor 
box is used for a particular user.

So, I build build my own scheme for the various URIs. The provisioning 
system tells a VM box to build a mailbox for User, with the URIs 
something like:

sip:[email-masked] -- Top level menu
sip:[email-masked]  -- User Entry pt for busy
sip:[email-masked]  -- User entry pt for no answer
sip:[email-masked] -- Entry pt for when User is calling

Note that my provisioning system created those URIs, using whatever 
method I like. Maybe they were just random.

Then the provisioning system provisions the proxy to forward to those 
particular URIs in the appropriate circumstances.

Now, of course, some vendors have customers that are not so large to 
have great big complicated provisioning systems. In this case, the 
vendore can create their own provisioning layer that exposes some 
standardized naming convention to the customer, but works exactly the 
same way underneath the layer.

The useful thing about this approach, is if I create a completely new VM 
related application, I can simply add it without any new standards work. 
For example, pehaps I want an entry point for when the caller is a known 
telemarketer. If we depend on standardized naming conventions, then it 
is harder for me to deploy any new service for which a convention does 
not already exist.

Now, to the point of exploders: This is a little different, because we 
expect the UAC to feed dynamic information to the UAS, thus requiring 
the UAC to know how to construct the r-URI. The UAC may need to do this 
for many different exploders in different management domains. Therefore, 
it may make sense to have a URI convention for this.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 19 Nov 2003 11:48:31 -0600

---

From: Ben Campbell <[email-masked]>
Date: Wed, 19 Nov 2003 18:35:50 -0600

Cullen Jennings wrote:

> On 11/19/03 9:48 AM, "Ben Campbell" <[email-masked]> wrote:
> 
> 
>>equipment vendor.
> Ok, that makes some sense but clearly interoperable conventions in this
> namespace are very useful. For example if the r-URI to most PSTN gateways
> was something like 
> 
> [email-masked];user=phone the result would be pretty
> predictable. 

I do not disagree. Conventions definitely make interop easier. But they 
also tend to limit what you can talk about.

I do not have a problem coming up with conventions for well-known 
applications that everyone uses. Your example above probably qualifies. 
Exploders may qualify. 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.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 19 Nov 2003 18:35:50 -0600

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 19 Nov 2003 16:19:41 -0800

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Nov 2003 09:10:56 -0500

Ben Campbell wrote:
> 
> VM is sort of in a gray area, as I think there is 

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.

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.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Nov 2003 09:10:56 -0500

Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 20 Nov 2003 11:02:19 -0500

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

Well, this is perhaps the essence of the long standing dispute on 
history vs. URI-invocation as the way to talk to voicemail systems.

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

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 20 Nov 2003 11:02:19 -0500

-Jonathan R.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 20 Nov 2003 10:18:36 -0600

This is becoming an abstract discussion of 3087, and I am not sure if it 
is of interest to the SIMPLE list. Should we keep this conversation 
here, or take it private?

More inline:

> all the VM alternatives. Much of the intelligence has been moved from 

This is true, but to a certain extent it is true without 3087 as well. 
For example, if you want to distinguish between Busy and No Answer, a 
proxy could either forward to a distinct URI, or it could encode an 
appropriate reason in a History header. Either way, it has to understand 
the difference. But in the 3087 case, it does not need to understand 
anything about VM--it just needs to understand that, under a certain set 
of circumstances, it forwards to a particular URI.

> 
> That is great if the VM provider is also the proxy provider.

This is not required if the customer controls the namespace.

  >It is also

Right. That is why I suggested that the vendor supplied provisioning 
mechanism could be layered. A "raw" layer lets the customer arbitarily 
assign names. A higher level layer could implement a name space of the 
vendor's choosing (perhaps based on some convention.)

---

From: Ben Campbell <[email-masked]>
Date: Thu, 20 Nov 2003 10:18:36 -0600

More inline:

---

From: Ben Campbell <[email-masked]>
Date: Thu, 20 Nov 2003 10:30:44 -0600

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:

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

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.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 20 Nov 2003 10:30:44 -0600

More inline:

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 21 Nov 2003 17:02:00 -0600

> or other context, and shove it into an r-uri.

Not sur we agree here. The Proxy doesn't have to understand ANY of this.
Whoever sets up the forwarding entries on the proxy has to understand it.

Case in point:

If you call +1 972 473 5455, this ends up as an INVITE to
sip:[email-masked].

This SIP URL is served by a proxy -- in fact, it's a really stupid antique
proxy that hasn't been updated in years. All it knows how to do is apply a
primitive version of CPL to the call . . .

So this week, my CPL says "Fork to all registrations".

As a result, all my phones ring -- and if none of them answer, after ten
seconds, the Asterisk voice mail server that also registered to
[email-masked] asnwers, and the caller gets my voice mail.

Two weeks ago, my cpl said: "Fork to all registrations, and if not answered
in 8 seconds, cancel all forks and forward to phone number 2142821376",
which diverted it to my cell phone, which if not answered diverts to voice
mail.

Let's say I go to VoiceMailsRUs and rent a voice mail box. They tell me the
CFBNA URI for my new box is:

sip:[email-masked];boxid=172.98

Cool. My proxy doesn't have to understand this. All I have to do is paste it
into my cpl, and we're good to go.

Now, let's say I wanted a different greeting for when my one and only SIP
phone is busy. I go back to VoiceMailsRUs, and the tell me to use the
optional code GR with a value of 27 to get the nifty new "Hi, this is Austin
Powers. The swinging cat you have called is too groovy to chat right now.
Behave, and leave a message" message.

So, I go change my CPL to forward calls, on "busy" at all forks, to 

sip:[email-masked];boxid=172.98,GR=27

And once again, despite complete ignorance of anything above the level of
SIP response codes in my proxy, I get the service I wanted.

THERE IS ABSOLUTELY NO NEED TO MAKE VOICEMAILSRUS CONFORM TO ANY EXTERNAL
SEMANTIC MAP.

The flip side of the rationale of 3087 is to ask "And how does VoiceMailsRUs
feel about this?" After all they're going to buy some VM boxes from Bob, and
some from Alice, and they want both brands to work with thir provisioning
system, which uses a naming convention made up a demented gnome who retains
his position by controlling incriminating photos from the 1999 company party
. . .

So VoiceMailsRUs wants their provisioning system to be able to hook up to a
new VM box and say to it "Make me a new box named
vlmner@vmhost;boxid=172.198,GR=27, and provision it with the greeting
APSWCYCISTGTCRNBALM.WAV".

VoiceMailrsRUs does NOT want to have to change their provisioning system to
understand the behavior-specific mailbox generation semantics of Alice, or
of Bob, or Charlie, or any other smug vendor who thinks they can replace the
entire installed base at VoiceMailsRUs.

And that's where 3087 came from.

--
Dean

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 21 Nov 2003 17:02:00 -0600

Case in point:

--
Dean