Subject: [Simple] ad-hoc list subscriptions

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Nov 2003 17:11:14 -0500

Orit,

Some comments on:
http://www.ietf.org/internet-drafts/draft-levin-simple-adhoc-list-00.txt

Generally, I do think we need something like this. It seems 
particularly useful in environments where the list is not syncrhonized 
with the network, but for which we want to get the benefits of list 
subscriptions, in terms of reducing overhead.

Firstly, this feels to me like it has a lot in common with the filter 
work. Both this and the filter work use body objects to push policy 
about the subscription to the server. Both have needs for updates to 
these policy objects during the lifetime of the subscriptions. Both 
have similar lifecycle managamenet requirements. Both provide details 
on exactly what the subscription is for. Have you considered trying to 
unify this with the filter work? Indeed, it might be useful to start 
off with some requirements to define what we want to do here, we may 
not all be on the same page.

Secondly, one big question is - what is the request URI? I can see 
several options:

(1) its a well-known service URI, for example, 
sip:[email-masked], where the server knows that for any 
subscriptions to sip:adhoclist@<any domain>, it means that the 
subscription has its contents in the body

(2) its a SIP URI that doesnt match any existing resource in the 
domain. Thus, the act of subscribing basically creates that resource 
as a list resource

(3) its a CID URI, referring to the list in the body of the request

I think you have (2) in mind. But, I'm not sure thats the right way to 
go.

Thirdly, you talk about all subscribed parties to the list receiving a 
notify when the list content changes:

> When a resource is added to /deleted from the list, the RLS SHOULD
>    generate a NOTIFY as if the list had been updated by any possible
>    out-of-band means and in accordance with the notification mechanism
>    and format established for this list. The updated information SHOULD
>    be sent to all the parties being subscribed to this list (including
>    the "list-owner").

I dont get this. I thought that an ad-hoc list would be scoped to the 
subscription, in which case, there wouldnt be any other subscribers. 
Am I missing something?

Thanks,
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

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

---

From: Adam Roach <[email-masked]>
Date: Mon, 10 Nov 2003 13:32:32 -0600

> (3) its a CID URI, referring to the list in the body of the request

That has the potential to make routing very difficult. If the first proxy
that you hit doesn't know what the cid scheme means, then things won't work.
It seems to me that the most flexible approach would be something like:

SUBSCRIBE sip:[email-masked];list=cid:[email-masked] SIP/2.0

Nice thing about this is that you could also do something like:

SUBSCRIBE
sip:[email-masked];list=http://xcap.example.com/services/presence-lists/u
sers/bill/fr.xml SIP/2.0

/a

---

From: [email-masked]
Date: Tue, 11 Nov 2003 05:32:07 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Jonathan Rosenberg
> Sent: Saturday, November 08, 2003 12:11 AM
> To: Simple WG
> Subject: [Simple] ad-hoc list subscriptions
> 
> 
> Orit,
> 
> Some comments on:

I'm not sure how they can be unified. I actually don't see the link between the two.

Regards,
Hisham

---

From: [email-masked]
Date: Tue, 11 Nov 2003 05:32:07 +0200

Regards,
Hisham

---

From: [email-masked]
Date: Wed, 12 Nov 2003 19:23:17 +0200

Hi,

I support Adam's proposal below compared to using a CID URI directly as the Request-URI, even though it might be possible to get the routing work with pre-loaded Routes. I believe this would be the way also to solve requirement 5 in http://www.ietf.org/internet-drafts/draft-camarillo-sipping-exploders-00.txt. In any case it would be better to solve the sending-to-an-ad-hoc-list issue more generally than just for SUBSCRIBE.

Also the support for XCAP resource list is very useful in some scenarios. In a recent discussion I proposed that we could define extensions like <messageable> to XCAP resource list, and this would mean that you could send a MESSAGE to that list too. I still believe this to be useful, but I see Adam's proposal complementary to this.

Markus

> ext Adam Roach
> Sent: 10 November, 2003 21:33
> To: Jonathan Rosenberg; Simple WG
> Subject: RE: [Simple] ad-hoc list subscriptions
> 
> 
> sip:[email-masked];list=cid:[email-masked] SIP/2.0
>

---

From: [email-masked]
Date: Wed, 12 Nov 2003 19:23:17 +0200

Hi,

Markus

---

From: [email-masked]
Date: Wed, 12 Nov 2003 19:33:04 +0200

Hi,

I believe the best way would be for them to subscribe to conference-state event package, if that is available. But I guess there is a bigger issue here: What is the relationship between a conference started through an exploder and a conference setup for with CPCP a la XCON. Is it possible to migrate from an exploder conference to CPCP-controllable one (given that the server supports CPCP, conference notification service etc.)?

I have yet another requirement for this ad hoc list / exploder solution. Especially in the case of MESSAGE to a list, it would be nice to be able to convey to the recipients the list of other recipients. It should be possible for the original sender to indicate this. It shouldn't be too hard to map the headers/payload from incoming to outgoing side for this purpose within the "exploder server".

Markus 

> ext Dean Willis
> Sent: 12 November, 2003 16:56
> To: Jonathan Rosenberg
> Cc: Simple WG
> Subject: Re: [Simple] ad-hoc list subscriptions
> 
> 
> 
> > subscription, in which case, there wouldnt be any other 
> subscribers. Am 
> > I missing something?
> 
> Ok, assume I send an INVITE to an ad-hoc list, forming an ad-hoc 
> conference. Would "members" of the list (i.e., participants in the 
> conference) subscribe to the list, or to the conference in order to 
> learn about changes to the participant set?
> 
> --
> Dean
> 
> 
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 12 Nov 2003 13:34:30 -0600

I would argue that, as with every other request you send,
the application behavior depends on the request URI.

So, for example, I could deploy an application server in
the middle of the network that treats:

INVITE sip:[email-masked];list=cid:[email-masked]
SIP/2.0

...very differently than...

INVITE sip:[email-masked];list=cid:[email-masked] SIP/2.0

/a

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, November 12, 2003 12:39
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> There seems to be an assumption here that sending an INVITE 
> to an ad hoc 
> list should create a conference. That is certainly one 
> interpretation, 
> but not the only possible one. If the ad hoc list server is a simple 
> message exploder then you probably aren't going to get a conference.
> 
> If you have a list of people and want to set up a conference 
> there are 
> other ways to do it, so trying to bend ad hoc list to do this 
> may not be 
> justified.
> 
> 	Paul
> 
> [email-masked] wrote:
> > Hi,
> > 
> > I believe the best way would be for them to subscribe to 
> conference-state event package, if that is available. But I 
> guess there is a bigger issue here: What is the relationship 
> between a conference started through an exploder and a 
> conference setup for with CPCP a la XCON. Is it possible to 
> migrate from an exploder conference to CPCP-controllable one 
> (given that the server supports CPCP, conference notification 
> service etc.)?
> > 
> > I have yet another requirement for this ad hoc list / 
> exploder solution. Especially in the case of MESSAGE to a 
> list, it would be nice to be able to convey to the recipients 
> the list of other recipients. It should be possible for the 
> original sender to indicate this. It shouldn't be too hard to 
> map the headers/payload from incoming to outgoing side for 
> this purpose within the "exploder server".
> > 
> > Markus 
> > 
> > 
> >>From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> >>ext Dean Willis
> >>>I dont get this. I thought that an ad-hoc list would be 
> >>
> >>scoped to the 
> >>

---

From: [email-masked]
Date: Thu, 13 Nov 2003 05:09:31 +0200

Hi,

Would you consider the decision whether the list contents are included in the request sent by the application server as application logic, or should this be explicitely signaled by the original sender? 

In general it is not clear to me what kind of behaviours should be standardized/signaled, and which are just left to each application to decide. In fact I'm inclined to think that this kind of very basic cases, i.e. conference establishment or B2BUA forking, should be made explicit. More advanced/niche features, such as if the app. server sends e-mail to people not reached, can be left to the imagination of the developers. One of the reasons is that I would like the basic features to work uniformly accross service providers. I believe this to be the advantage of the "ordinary" users.

Markus 

> From: ext Ben Campbell [mailto:[email-masked]]
> Sent: 13 November, 2003 00:20
> To: Adam Roach
> Cc: 'Paul Kyzivat'; Isomaki Markus (NRC/Helsinki);
> [email-masked]; Jonathan Rosenberg; [email-masked]
> I concur with Adam. The basic URI (not counting the list parameter) 
> identifies an application that knows to do something with the list 
> parameter. Some other application might just ignore the list 
> parameter.
> 
> Adam Roach wrote:
> 
> > INVITE 
> sip:[email-masked];list=cid:[email-masked]
> > SIP/2.0
> > 
> > INVITE 
> sip:[email-masked];list=cid:[email-masked] SIP/2.0
> > 
> > /a
> > 
> >

---

From: Adam Roach <[email-masked]>
Date: Thu, 13 Nov 2003 09:26:44 -0600

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.

/a

---

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

Ben Campbell [mailto:[email-masked]] writes:
> 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

---

From: "Orit Levin" <[email-masked]>
Date: Tue, 18 Nov 2003 18:20:15 -0800

SIMPLE **IS** a specific application that uses SIP (with its SUBSCRIBE
and NOTIFY) as a signaling infrastructure.

Therefore, the question whether the ad-hoc list should be standardized
in SIP as a general mechanism is an implementation issue from the SIMPLE
perspective.

The question is whether we need to standardize the ad-hoc list SUBSCRIBE
in SIMPLE.

The more general and the real question is how our SIMPLE systems are
going to look like:

(1)Arbitrary configuration and management protocols (XCAP as one of
them) and SIP infrastructure (e.g. routing and security) for all dynamic
signaling (including signaling of lists) and event reporting.

(2) Arbitrary configuration and management protocols; XCAP for all
dynamic application infrastructure (e.g. all the Presence lists) and SIP
infrastructure for routing of events only.

(3) XCAP for configuration, management and all dynamic application
infrastructure (e.g. all the Presence lists) and SIP infrastructure for
routing of events only.

I definitely vote for option (1). For example, how are we planning to
move forward and build scalable interoperable SIMPLE systems relying
exclusively on XCAP? 

Are we planning to automatically distribute the dynamic lists across the
network using XCAP?

Orit. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ben Campbell
Sent: Monday, November 17, 2003 6:32 PM
To: Adam Roach
Cc: 'Paul Kyzivat'; [email-masked]; [email-masked];
Jonathan Rosenberg; [email-masked]
Subject: Re: [Simple] ad-hoc list subscriptions

> 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: "Orit Levin" <[email-masked]>
Date: Tue, 18 Nov 2003 18:20:15 -0800

Orit.

---

From: Adam Roach <[email-masked]>
Date: Wed, 19 Nov 2003 17:54:13 -0600

Orit Levin [mailto:[email-masked]] writes:

> Are we planning to automatically distribute the dynamic lists 
> across the network using XCAP?

To my understanding, that was the original plan.

That said, companies working in the wireless space have
been promoting a requirement that devices that use
short-lived lists must be able to send the list and the
operation that uses the list in a single transaction.

I understand this requirement, and think we need some
specification to address it. I plan to submit an internet
draft that expands on the ideas I have championed in this
thread as soon as I have time.

Your recent draft makes it clear that using XCAP for these
temporary lists doesn't meet your requirements either --
but it doesn't clarify what requirements you have on short-
lived lists. What I would like to know from you is: is this
requirement (a single transaction to specify and use a list)
the same as what you need, or do you have additional and/or
different requirements?

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 19 Nov 2003 17:54:13 -0600

/a

---

From: "Orit Levin" <[email-masked]>
Date: Wed, 19 Nov 2003 17:34:07 -0800

First of all, I am glad that I am not alone :-)

As a direct outcome of the discussion around the ad-hoc list topic in
the SIMPLE session, I identified to myself a clear AI to come up with a
requirements draft for how we distribute the dynamic information, vital
for building scalable and interoperable SIMPLE infrastructures.

The user's "subscribe list" - is one simple example.
- "Single transaction mechanism" is an important requirement to me as
well. - Ability to send deltas of a list is also crucial (apropos the
discussed exploders' syntax).

I also see requirements for exchanging highly dynamic information
between/among "Presence Servers" in optimized (e.g. compact) way.

When doing all this, I will love to reuse as many basic XML presence
schemas as possible.

Creation of the requirements draft is a very high priority on my list. I
suggest that we join our efforts and create a taskforce in order to come
up with suggestions/conclusions/directions... faster than usually.

I believe that we are in shortage of time here in order for the
standards to be adopted by the industry.

Orit. 

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Wednesday, November 19, 2003 3:54 PM
To: Orit Levin; [email-masked]
Subject: RE: [Simple] ad-hoc list subscriptions

/a

---

From: "Orit Levin" <[email-masked]>
Date: Wed, 19 Nov 2003 17:34:07 -0800

Orit. 

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Wednesday, November 19, 2003 3:54 PM
To: Orit Levin; [email-masked]
Subject: RE: [Simple] ad-hoc list subscriptions

/a

---

From: [email-masked]
Date: Thu, 20 Nov 2003 09:39:39 +0200

As I said on the mike in the SIMPLE meeting, this issue is not just limited to SUBSCRIBE, but the problem also includes MESSAGE, INVITE, etc.

There are already requirements documented in http://www.ietf.org/internet-drafts/draft-camarillo-sipping-exploders-00.txt

Should we discuss those in sipping?

Regards,
Hisham

> ext Orit Levin
> Sent: 20.November.2003 03:34
> To: Adam Roach; [email-masked]

---

From: [email-masked]
Date: Thu, 20 Nov 2003 09:39:39 +0200

Regards,
Hisham

---

From: "Orit Levin" <[email-masked]>
Date: Thu, 20 Nov 2003 10:54:34 -0800

I believe that we should work on two sets of requirements - one in
SIMPLE and one in SIPPING.

SIMPLE is a very important :-) standard application on the top of SIP.
This is the reason for having a dedicated WG and a dedicated set(s) of
requirements.

We must identify the SIMPLE requirements and then feed them back to
SIPPING/SIP.
If SIP manages to meet the SIMPLE requirements as a subset of the
"exploder" concept - great.
My quess is that it is not that simple.

Thanks, Orit. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, November 19, 2003 11:40 PM
To: Orit Levin; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Simple] ad-hoc list subscriptions

As I said on the mike in the SIMPLE meeting, this issue is not just
limited to SUBSCRIBE, but the problem also includes MESSAGE, INVITE,
etc.

There are already requirements documented in
http://www.ietf.org/internet-drafts/draft-camarillo-sipping-exploders-00
.txt

Regards,
Hisham

> the SIMPLE session, I identified to myself a clear AI to come up with 
> a requirements draft for how we distribute the dynamic information, 
> vital for building scalable and interoperable SIMPLE infrastructures.
> 
> Creation of the requirements draft is a very high priority on my list.

> I suggest that we join our efforts and create a taskforce in order to 
> come up with suggestions/conclusions/directions... faster than 
> usually.
> 
> > Are we planning to automatically distribute the dynamic lists across

> > the network using XCAP?
> That said, companies working in the wireless space have been promoting

> a requirement that devices that use short-lived lists must be able to 
> send the list and the operation that uses the list in a single 
> transaction.
> 
> I understand this requirement, and think we need some specification to

> address it. I plan to submit an internet draft that expands on the 
> ideas I have championed in this thread as soon as I have time.
> 
> Your recent draft makes it clear that using XCAP for these temporary 
> lists doesn't meet your requirements either -- but it doesn't clarify 
> what requirements you have on short- lived lists. What I would like to

> know from you is: is this requirement (a single transaction to specify

> and use a list) the same as what you need, or do you have additional 
> and/or different requirements?
> 
> /a
> 
> 
>

---

From: "Orit Levin" <[email-masked]>
Date: Thu, 20 Nov 2003 10:54:34 -0800

Thanks, Orit. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, November 19, 2003 11:40 PM
To: Orit Levin; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Simple] ad-hoc list subscriptions

Regards,
Hisham

---

From: Adam Roach <[email-masked]>
Date: Thu, 20 Nov 2003 14:18:08 -0600

> SIMPLE and one in SIPPING.

I want to make absolutely certain that we don't come up with
divergent solutions for ad-hoc lists. Doing the work in two
places increases the risk of that happening significantly.

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 20 Nov 2003 14:18:08 -0600

/a

---

From: "Orit Levin" <[email-masked]>
Date: Thu, 20 Nov 2003 12:52:20 -0800

Mixing SIMPLE requirements with their SIP realization or much worse -
reversing the order - is what seems very wrong to me.

Anyway, I am working on my AI - the SIMPLE requirements. I hope very
much (obviously!!!) to use a SIP mechanism for most of them.

Orit.

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Thursday, November 20, 2003 12:18 PM
To: Orit Levin; [email-masked]; Adam Roach; [email-masked]
Cc: [email-masked]
Subject: RE: [Simple] ad-hoc list subscriptions

/a

---

From: "Orit Levin" <[email-masked]>
Date: Thu, 20 Nov 2003 12:52:20 -0800

Orit.

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Thursday, November 20, 2003 12:18 PM
To: Orit Levin; [email-masked]; Adam Roach; [email-masked]
Cc: [email-masked]
Subject: RE: [Simple] ad-hoc list subscriptions

/a