Subject: hierarchies (was RE: [Simple] Extending <status> for presence)

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 21 Jan 2003 16:31:38 -0500

I am wary of explicitly defining hierarchies by having an extension to PIDF
that allows, essentially, tuples within tuples. I am less averse to the
concept that tuples representing a group might each contain a contact
address with a pres: URI where the presence of that group member might be
learned. Indirection rather than hierarchy.

Either way, there will be a significant burden on the watcher to figure out
whether or not the group as a whole should be considered OPEN (considered as
an absolute or through some quantification of partial OPENness). Using
indirection allows the presence composition function to be more easily
distributed, I think. If several members of a group use, say, different
presence services (and I see no reason to rule that out), hierarchies would
seem to imply a publication interface between their various presence
services and some sort of group aggregator. Various sorts of policy
management from the presentity perspective look more complex to me in that
architecture. In very large groups, I would imagine it is also better for a
watcher's client to decide how many members of the group it would like
evaluate, rather than receiving a single massive PIDF document from the
presentity.

Jon Peterson
NeuStar, Inc.

[snip]
> This could perhaps be represented by specifying three tuples, each 
> containing a pres: url. But that is a bit of a stretch. This is the case 
> that seems to cry out for hierarchical tuples.
> 
> I guess my personal preference is to go ahead and define hierarchies.
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 24 Jan 2003 16:05:13 -0500

inline.

> learned. Indirection rather than hierarchy.

Both modes seem useful and should be possible.

I'll note that this concept intersects significantly with the buddy list 
subscription work (draft-roach-sip-list-template). There are many 
interpretations that can be made to the act of subscribing to a group:

1. the subscriber wants to receive a PIDF for each group member when 
their status changes. Each PIDF has a single presentity, but it 
represents a group member. PIDF itself knows nothing abuot groups. There 
is a single subscription for the entire group. This is the 
roach-sip-list-template approach.

2. the subscriber merely wants the state of the group, and doesnt care 
about the members. THus, it also receives a PIDF that talks about one 
presentity, but the presentity represents a group. There are no tuples 
representing members. There is one subscription.

3. the subscriber wants the state of the group and of its members. The 
subscription to the group indicates that it has a bunch of members, each 
represented by a tuple with a pres contact URI. THe subscriber then 
subscribes to each independently. There are N+1 subscriptions for a flat 
group with N members.

4. the subscriber wants the state of the group and of its members. The 
subscription to the group indicates that it has a bunch of members, each 
represented by a tuple, which has sub-tuples with the state of that 
member. Notificatoins of changes would be partial, so that each notify 
contains just the sub-tree that has changed. THere is one subscription.

Cases 1. and 4. are very similar. What is interesting is that 4. is a 
PIDF-specific way to accomplish 1. That might argue that 4. is not 
needed, that its better to do this kind of thing more generally than for 
presence.

I do think we want to allow for cases 2 and 3. However, for them to 
work, the key missing piece is a status that indicates what the tuple 
represents. Indeed, the bigger issue is what the presentity represents. 
As I mentioned in another email, the presentity and tuples could represent:

groups
users
automaton
devices
logical components of a device

So, I would assert that there is a need for another status type, say 
<represents> that can be applied to the tuples or the presentity, and is 
one of the values above.

Another missing piece is, when the subscriber subscribes, how do they 
indicate which of the above 4 (or three, if we rule out #4) they want? 
That might require some presence filters to be defined.

> an absolute or through some quantification of partial OPENness).

I would imagine that the PIDF itself should say what the status of the 
group overall is.

> Using
> services and some sort of group aggregator. 

Group aggregator, yes. We've discussed this extensively as part of the 
buddy list subscription work above. A key goal was to allow hierarchical 
aggregation, which I believe the most recent proposal (using a 
sip-events extension) will allow.

> Various sorts of policy
> architecture.

Yes, authorization is more complicated - its the standard "proxy vs. 
redirect" issue there in terms of security requirements. But, we need 
the proxy case (where there is a network aggregator) to avoid a plethora 
of subscriptions.

  In very large groups, I would imagine it is also better for a
> evaluate, rather than receiving a single massive PIDF document from the

Agreed you don't want a single massive document. It would be multipart 
or separate notifies for each, I would think.

-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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 27 Jan 2003 16:42:04 -0500

> roach-sip-list-template approach.

Even in that case, the PIDF should probably contain some kind of 
identifier that tells the watcher why he is getting this PIDF document. 
This is more than just "this is a group", but rather "you're getting 
Alice's status since you subscribed to [email-masked]".

In SIMPLE, the NOTIFY From will provide this information. Do we need a 
separate indication in PIDF itself?

> subscribes to each independently. There are N+1 subscriptions for a flat 

What does OPEN and CLOSED mean in that context? Would it mean that the 
member temporarily has no presence information available (I think so) or 
that it is no longer a member of the group (I don't think so). In 
general, how would a watcher detect that somebody is no longer a member? 
(The person may still exist, just not as a member of the group.)

> <represents> that can be applied to the tuples or the presentity, and is 

However, I don't think these are all orthogonal, so I wouldn't want to 
lump them into one descriptor. Basically, I want to know whether a 
presentity has a "parent" (which indicates group).

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 28 Jan 2003 14:26:55 -0500

inline.

Henning Schulzrinne wrote:

 >> represents a group member. PIDF itself knows nothing abuot groups.
 >> There is a single subscription for the entire group. This is the
 > In SIMPLE, the NOTIFY From will provide this information.

Exactly.

 > Do we need a

Thats a good question. I think the model we've had to date was that the
information about why you were receiving this notification (i.e., this
user is in the list you subscribed to) was going to be provided via a
separate header or document in the notify. Indeed, in addition to this
presence information, there is other ancillary information that is
needed, such as the status of the subscription from the list server to
the actual presentity. This way, if one of the buddies on my buddy list
denies my subscription, I have a way to see it. This is not PRESENCE
state, its SUBSCRIPTION state.

Now, perhaps we can split this ancillary information into presence
related information (structure of the buddy list, presence in PIDF) and
subscription information, presence in the ancillary body or headers. Not
sure what the benefit is of this split.

 >> subscription to the group indicates that it has a bunch of members,
 >> each represented by a tuple with a pres contact URI. THe subscriber
 >> then subscribes to each independently. There are N+1 subscriptions for
 >> a flat group with N members.
 >
 >
 > What does OPEN and CLOSED mean in that context?

OPEN and CLOSED for a member, you mean?

 > Would it mean that the
 > that it is no longer a member of the group (I don't think so).

Hmm. It comes down to what does OPEN/CLOSED mean. I think it means
"attempts to connect to the URI in the contact will succeed (OPEN) or
fail (CLOSED)". If that contact is a pres URI, or even better, the tuple
indicates that it represents a presentity, the meaning of OPEN is that
you will be able to succesfully subscribe to it. I would expect, as a
result, that OPEN is really the only useful status.

 > In

The next notification would omit that user from the list.

 >> represents. As I mentioned in another email, the presentity and tuples
 >> could represent:
 >>
 >> groups
 >> users
 >> automaton
 >> devices
 >> <represents> that can be applied to the tuples or the presentity, and
 >> is one of the values above.
 >
 >

Thats true, but I do not think its sufficient. I think you really do
want to know what a tuple and a presentity represent.

-Jonathan R.