Subject: RE: [Simple] Thoughts on list template

From: [email-masked]
Date: Tue, 19 Nov 2002 02:35:56 +0200

That's how I thought it worked in the first place, hence my confusion of what the problem was.

You have a list of buddies, on of the buddies is a list:

[email-masked]
[email-masked]
[email-masked] (I have  Adam's list of friends on my buddy list. I can do that, technically)

My terminal will send out 3 SUBSCRIBEs, one for each of the above. Does my terminal need to recognise that [email-masked] is a list? This has nothing to do with the problem we have now with the list package.

Now, I make a list out of the above and call it [email-masked]

Instead of my terminal sending out 3 SUBSCRIBEs (one of them to [email-masked] with event: presence), it sends out 1.

The question is: should my PLS recognise that [email-masked] is a list? I say no. Its up to dynamicsoft's domain to decide that, somehow.

This "somehow" solves both problems above.

Regards,
Hisham

> -----Original Message-----
> From: ext Adam Roach [mailto:[email-masked]]
> Sent: Tuesday, November 19, 2002 12:04 AM
> To: [email-masked]
> Subject: [Simple] Thoughts on list template
> 
> 
> After giving some thought to the issues raised in today's
> meeting, it occurs to me that there may, in fact, be a
> compromise. I'm throwing the rough description out on the
> list in hope that, if a flaw exists, one of you will
> be able to point it out.
> 
> Basically, it amounts to this: to give the capabilities
> that several people want (e.g. arbitrary depth lists)
> without abandoning templates, we could slightly tweak
> the meaning of the ".list" template. In particular,
> "foo.list" would refer to any arbitrary nesting of
> foo objects; e.g., it would cover what is, under the
> current draft, called any of foo.list, foo.list.list,
> foo.list.list.list, ad infinitum.
> 
> I *think* this still works gracefully when you combine
> it with other templates (e.g. presence.list.winfo.list).
> It *does* impose more of a processing load on aggregators,
> but I don't think it's crippling.
> 
> So, first: does anyone see anything that would prevent
> this working, from a technical perspective?
> 
> And, second: does anyone have any philosophical objections
> to this approach? (I'll admit that I have my own reservations,
> but I want to find a middle ground)
> 
> /a
> 
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

---

From: [email-masked]
Date: Tue, 19 Nov 2002 18:52:02 +0200

Jonathan,

I think this is a good idea. The problem really was that while we were trying to treat lists as part of the event, they really were not. So separating the list handling from the actual event is a good idea, and I think you nailed it here.

Cheers,
Aki

> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, November 19, 2002 6:41 AM
> To: Paul Kyzivat
> Cc: Adam Roach; [email-masked]
> Subject: Re: [Simple] Thoughts on list template
> 
> 
> inline.
> 
> Paul Kyzivat wrote:
>  >
>  > Adam Roach wrote:
>  >
>  >> Basically, it amounts to this: to give the capabilities that
>  >> several people want (e.g. arbitrary depth lists) without 
> abandoning
>  >> templates, we could slightly tweak the meaning of the ".list"
>  >> template. In particular, "foo.list" would refer to any arbitrary
>  >> nesting of foo objects; e.g., it would cover what is, under the
>  > ...
>  >> So, first: does anyone see anything that would prevent this
>  >> working, from a technical perspective?
>  >
>  >
>  > I too hope something like this works. I think we need to dig into
>  > details a bit to figure out if it is going to work.
>  >
>  > 1) Does this imply that the server serving an instance of foo.list
>  > itself issues the subscriptions to all the leaves of the recursive
>  > list expansion? Or is it just responsible for delegating those? Or
>  > are both approaches valid? (They may have different authentication
>  > implications.) The pure template approach clearly implied 
> delegating
>  > the responsibility for the leaf subscriptions.
> 
> I don't see the difference between the two things?
> 
>  >
>  > 2) Either way, the server for foo.list is now responsible for
>  > determining if a particular list entry is an instance of foo, or of
>  > foo.list. Do we have any better way to figure this out 
> than trial and
>  > error? Is that acceptable? (An alternative might be to explicitly
>  > type the entries in a list.)
> 
> This is the big issue.
> 
> It might help to step back and consider how this would work 
> in an IDEAL 
> world of a clean slate, and work backwards. Doing that is 
> what helped us 
> figure out how to do loose routing, and as it turns out, I think it 
> solves this problem too.
> 
> In the ideal world, <gasp> there is no presence package. 
> There is only 
> the equivalent of "presence.list". That is, we assume at the 
> outset that 
> a presence subscription always implies a list, and a valid 
> option is a 
> list of one. Thus, I subscribe to my buddylist with package 
> "presence", 
> and each of the subscriptions it generates are for the same package, 
> "presence". The owner of the URI gets to decide whether its a list of 
> multiple elements, or just one.
> 
> Now, the problem of course is that all of the list features 
> would need 
> to be replicated in each package. So, the ideal solution there IMHO 
> would have been to have list processing be central to rfc3265 in the 
> first place, so that all packages are list enabled from the outset.
> 
> OK, so IF you agree that this is what it ought to have been, 
> how do we 
> achieve as close a goal as possible with the constraints that we have?
> 
> I would define list processing as an EXTENSION to rfc3265, not a 
> template or a new package. How would that work? When a UAC 
> subscribes, 
> it includes a Supported header indicated "lists". The Allow header in 
> the subscribe also lists multipart as a valid body type thats 
> supported, 
> along with the MIME type of this XML list meta-data. So, a buddy list 
> subscription looks like:
> 
> SUBSCRIBE sip:[email-masked] SIP/2.0
> Supported: lists
> Allow: application/pidf+xml, multipart/mixed, application/elist+xml
> Event: presence
> 
> The server knows that mylist is a list, but since the client supports 
> lists, its OK. The server does a SUBSCRIBE to each participant in the 
> list, all of them with the Event: presence header, and all of 
> them with 
> the same Supported and Allow headers. Now, should one of 
> those happen to 
> be a regular presence server that doesn't support the "lists" 
> extension, 
> it works just fine! The server will generate NOTIFYs with plain-old 
> PIDF, no multipart or elist+xml. So, there is no trial-and-error; a 
> subscription to an element in the list is the same in all cases, and 
> doesn't require knowing what it is. If it turns out that its a list, 
> multipart comes back. If not, just plain PIDF.
> 
> Should a user SUBSCRIBE to a list, and not indicate support 
> for "lists" 
> in the Supported header, the server rejects the request with 
> a 420 and 
> the appropriate Require header.
> 
> As far as I can tell, this solution buys us EVERYTHING we want:
> 
> * infinite nesting of lists, without the list server needing to know 
> whether an entry is a list or not
> * no trial and error
> * backwards compatibility
> * graceful evolution, if we want, to a revised rfc3265 that 
> includes the 
> list processing as a native capability
> 
> 
> Comments?
> 
> -Jonathan R.
> 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>