Subject: [Sipping] Exploders (was: [Simple] ad-hoc list subscriptions)

From: Pekka Pessi <[email-masked]>
Date: Thu, 20 Nov 2003 16:01:29 +0200

"[email-masked]" <[email-masked]> writes:
>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?

Whatever. ;)

It looks like there are at least three kinds of exploders with
slightly different semantics:

1) (subscription) session exploders, like event lists

2) request exploders, like sending IM to a group 

3) forking exploders, where client defines the target locations 

1 - Session exploders establish session with all resources on
the list, and deliver the combined results from sessions to the
originator. I think this kind of exploders include event lists
(SUBSCRIBE) and group calls (INVITE, REFER).

2 - Request exploders send one request to each list members,
combine results from requests, and send combined result to
originator. This include MESSAGE and other MESSAGE-like request.

3 - Forking exploders fork request and send the best result to
orginator. They work jsut like proxies work today, but the
target location list is provided by client. 

If we define a nice mechanism to deliver combined status of an
exploded request for case 2, I would be tempted to to use the
same mechanisms to deliver combined results of ordinary request
that just got forked.

Now, back to the case 2. It looks like REFER on stereoids, at
least if REFER is your favorite SIP remote control method. In
plain REFER, originator sends a REFER request to server, server
sends a request on its own to the final destination and forwards
the response it got back to orinator within NOTIFY. In order to
do explosion, we just put cid uri in the Refer-To header, send
REFER to exploder then let a exploder server do the magic and
send the combined results in NOTIFY. No SIP-level extension
needed, plain old RFC 3515 stuff (with fancy mime types,
however).

BR,
				Pekka

>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]On Behalf Of
>> ext Orit Levin
>> Sent: 20.November.2003 03:34
>> To: Adam Roach; [email-masked]
>> Subject: RE: [Simple] ad-hoc list subscriptions

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

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

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

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

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