Subject: Re: [Simple] collection template

From: Rohan Mahy <[email-masked]>
Date: Fri, 4 Oct 2002 17:22:51 -0700

I found this culling through half-finished replies....

On Monday, September 16, 2002, at 11:02 AM, Adam Roach wrote:

>> From: Ben Campbell [mailto:[email-masked]]
>>
>> If I susbscrbe to "collection"
>> without an event scope, I now have to expect NOTIFY requests for
>> arbitrary events.
>
> Unless the proposal is something of an overhaul of event processing
> (which I advise against), your NOTIFY messages would be NOTIFY for
> the event "collection" under Jonathan's proposal.
>
> I've got to admit, I share Ben and Sean's reservations about this
> approach.

I am likewise concerned by treating collections as a package.  The 
multiple-event type especially bothers me.  I'm with Adam and Sean.  A 
collection template would clearly work and give us the semantics we 
need.  The package approach is dancing on a slippery slope.  As I add 
to this 2 weeks later I will compare this to the combined 
REGISTER/SUBSCRIBE discussion in SIP.  The arguments for doing a 
package instead of a template are sort of vague and squishy.  Let's 
please just do the template instead.  It will work.

thanks,
-rohan

> /a
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Adam Roach <[email-masked]>
Date: Fri, 25 Oct 2002 17:04:22 -0500

[Sliding in under the wire for the -00 deadline]

An i-d describing a template event package for collections has been
submitted to the drafts editor. Until a copy appears in the archives,
you can download a copy from:

http://pages.sbcglobal.net/roaches/ietf/draft-roach-sip-list-template-00.txt

HTML version also available:
http://pages.sbcglobal.net/roaches/ietf/draft-roach-sip-list-template-00.htm
l

This work is still rather rough around the edges, but I think it gives a
good starting point for discussion.

/a

---

From: Adam Roach <[email-masked]>
Date: Mon, 28 Oct 2002 13:43:28 -0600

> -----Original Message-----
> From: George Foti (LMC) [mailto:[email-masked]]
>
> is it correct
> to assume that either of the following is correct:
> 
> a) The RLS will send *individual* SUBSCRIBE to all members of 
> all sub-lists
> included in the main resource list created by the user when 
> he SUBSCRIBEs to
> that list.

That would be valid. Of course, the RLS has to know the membership
of all of the sublists to do so.

> b) The RLS can do procedure (a) for 1 or more sub-lists (in 
> the original
> list) but can also send a SUBSCRIBE to another RLS for some 
> sub-lists (in
> the original list). The later RLS can be responsbile for 
> maintaining some
> lists, and in turn will implement procedure (a).   

That would also be valid. The only revision I would make to your
assertion is: "can do procedure (a) for _zero_ or more sublists..."

Finally, the RLS might have complete information about all of
the states involved, in which case it would generate *no*
subscribes to any other node at all.

/a

---

From: "George Foti (LMC)" <[email-masked]>
Date: Mon, 28 Oct 2002 14:18:46 -0500

Some clarification Adam:

When a user creates a resource list, I assume that he can refer to other
lists there in, so basically we have a case of recursion. Now is it correct
to assume that either of the following is correct:

a) The RLS will send *individual* SUBSCRIBE to all members of all sub-lists
included in the main resource list created by the user when he SUBSCRIBEs to
that list.

b) The RLS can do procedure (a) for 1 or more sub-lists (in the original
list) but can also send a SUBSCRIBE to another RLS for some sub-lists (in
the original list). The later RLS can be responsbile for maintaining some
lists, and in turn will implement procedure (a).   

Thnx/gf

> From: Adam Roach [mailto:[email-masked]]
> Sent: Friday, October 25, 2002 6:04 PM
> To: [email-masked]
> Subject: RE: [Simple] collection template
> 
> 

/a