Subject: [Simple] Re: PIDF for buddylists

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Jun 2002 17:00:25 -0400

Jonathan,

Maybe I missed a document. You mention below the importance of diffs when reporting presence for buddylists. But I don't find any mention of diffs in
draft-rosenberg-simple-buddylist-package-00. Or do you just mean that delivery of presence documents individually from each member of the buddylist as it changes is a form
of diff?

Upon thinking about this further, I think the existing presence document might be sufficient.

Consider - is there any fundamental difference between a named buddylist and an address of record? If I view a buddylist as an address of record, then to populate it I
simply REGISTER the addresses of the buddies as contacts. Then instead of a BLSS, I need a presence server with access to the location service populated by the registrar.
And instead of a presence document with multiple presentities, I get a presence document with a single presentity (my buddylist name) and a bunch of contacts for my
buddies. 

This would put a high priority on permitting diffs in the presence documents.

Having buddylists represented this way would provide other opportunities to use them.

	Paul

Jonathan Rosenberg wrote:
> 
> I think my comments on using PIDF for the reg package are covered in a
> separate email; I'll focus here on the PIDF v. buddylist concept.
> However, this is well into simple territory (and IMPP), so I am cc'ing
> those lists.
> 
> inline:
> 
> Paul Kyzivat wrote:
> >
> > comments inline.
> >
> 
> > > However, note that in cases of notifications of changes, this issue
> > > becomes largely moot. Changes in presence of buddies happen one at a
> > > time, so that each notify would usually contain just a single presenec
> > > doc anyway. THe exception is if the buddylist server is batching the
> > > notifies in order to reduce overhead.
> >
> > I think batching is potentially an important application of buddylists.
> > Buddylist servers may also be a good place to implement filtering to
> > further reduce the traffic that
> > the subscriber is exposed to. These potentials would be enhanced by
> > being able to return the presence of multiple presentities in a single
> > presence document.
> 
> I agree it would be helpful, although the difference between multipart
> and multiple presentities in a single document is not huge. The real
> problem is that this is somewhat of a new direction for PIDF late in the
> game, and in PIDF was engineered to be minimalistic. Adding support for
> a new feature is likely to meet with some resistance. I suppose we could
> define an extension to PIDF, although to be honest, from a read of the
> schema its not clear to me that a single document with multiple presence
> elements is actually disallowed, in whcih case its already there. Of
> course, its not likely to be interoperable...
> 
> >
> > > > it would then make
> > > > sense to subscribe to presence of either presentities or buddylists
> > > > without needed to know which is which.
> > >
> > > There are differences, most notably in the need for diffs in the case
> > of
> > > buddylist.
> >
> > Seems to me these aren't important differences. The features that seem
> > important for buddylists and less important for presence of an
> > individual are also at least
> > potentially useful for the presence of an individual.
> 
> Well, the diff feature is critical for buddylist, and currently
> undefined for presence. Therefore, we need to have at least a new
> package for it. We would also need some new attributes to support the
> diffs (a partial/full flag, as we needed for watcherinfo), so we are at
> least talking about an extension to PIDF even if multiple presence
> elements are allowed. I would be OK with doing that; the difference
> between it and multipart is not huge, but its definitely better.
> 
> -Jonathan R.
> 
> --
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> [email-masked]                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> 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
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Jun 2002 17:21:38 -0400

Comments inline. Best results when viewed in fixed width font.

	Paul

Jonathan Rosenberg wrote:
> 
> Paul Kyzivat wrote:
> > Jonathan,
> >
> > Maybe I missed a document. You mention below the importance of diffs
> > when reporting presence for buddylists. But I don't find any mention of
> > diffs in
> > draft-rosenberg-simple-buddylist-package-00.
> 
> You're right, actually. I thought about this more since posting, and its
> not really needed. With watcherinfo (which does have diffs), you are
> again getting notified about a list of things. However, the list itself
> is dynamic and conveyed through the notifications itself. You therefore
> need to have a flag as to whether the update is full state or partial
> state, so that you know whether or not to delete a watcher because their
> entry is not in the list (delete for full state, don't for partial).
> 
> Now, in the case of buddylists, presumably the list itself is known to
> the client through other means, and therefore, this particular flag is
> not needed.

I'm not sure this is a reasonable assumption. As long as we remain silent on how the list is managed, it is risky to assume that every subscriber has complete knowledge of
the list content.

There seem to be two reasonable alternatives here: provide diff information on presence reports from buddylists, or else provide a defined way to monitor the content of a
buddylist itself.

> 
> > Or do you just mean that
> > delivery of presence documents individually from each member of the
> > buddylist as it changes is a form
> > of diff?
> >
> Wayne convinced me that we need to define a trivial new format; one that
> has a new top-level XML element, and the sub-element is presence from PIDF.

Depends on outcome of discussion below. Possibly some form of change will be required.

> 
> >
> > Consider - is there any fundamental difference between a named buddylist
> > and an address of record? If I view a buddylist as an address of record,
> > then to populate it I
> > simply REGISTER the addresses of the buddies as contacts.
> 
> Are you proposing an actual REGISTER for this? I think this is a pretty
> big deviation from the meaning of REGISTER.

I am proposing (as a strawhorse) that the concept of buddylist be subsumed into a slightly broader role for address of record. This is largely a conceptual change - I don't
think the mechanics of managing address of record need to change.

It is already permissible to populate a location service with an address of record either by using REGISTER or by some other method. One other method might be by uploading
a buddylist.

> 
> > Then instead
> > of a BLSS, I need a presence server with access to the location service
> > populated by the registrar.
> > And instead of a presence document with multiple presentities, I get a
> > presence document with a single presentity (my buddylist name) and a
> > bunch of contacts for my
> > buddies.
> 
> How would you have out the contacts for the buddies? You've shifted
> everything down a layer, so the bottom falls out as far as I can tell...

Yeah, I didn't bother to mention that, and you caught me. :-)

What I have in mind is that presence should be viewed as hierarchical. It is already that way, sort of, but only two levels are acknowledged in the hierarchy. The
presentity can have status, and each of the contacts can have status.

In registrations, it is permissible for the Contacts defining one address of record to themselves be addresses of record that have lower level definitions, etc. (I realize
there aren't many, if any, published use cases for this.)

If you want to understand the full hierarchical structure of registrations of that sort, you have to drill down one level at a time. It should be possible to do exactly the
same thing for presence. Alternately, it might be more helpful for a presence subscription to be recursive, perhaps optionally. (This would be something like what has been
proposed for the conference info event package.)

As an example, consider the following hierarchy:

                     [email-masked]
                     /         |         \
    [email-masked]  [email-masked] [email-masked]
          /             /      |        \        \
        ...            /       |         \       ...
                      /        |          \
                     /         |           \
[email-masked] [email-masked] [email-masked];user=phone

These could all be valid sip addresses to call. They are also potentially all valid presentities to request presence documents for. What is the difference if I ask for the
presence of 'everybody' and get info about its three subordinates, or if I ask for the presence of 'fred' and get the status of his three alternate devices? 

Why does there have to be an arbitrary distinction that 'everybody' is a buddylist, but 'fred' is an address of record?

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 06 Jun 2002 15:26:39 -0400

-Jonathan R.

---

From: Bryan Thale <[email-masked]>
Date: Thu, 06 Jun 2002 18:17:49 -0500

>     [email-masked]  [email-masked] [email-masked]

Looking at it from the other direction, what does it mean to call a
buddylist?

Placing a call to 'fred' will eventually resolve down to one device or
at least one user.  That probably isn't what would be intended by a call
to 'everybody' which sounds
more like a multiparty call.  If buddylists and AoRs are
indistinguishable, how would a SIP application know what is the right
thing to do?

> and an address of record?

Isn't the difference that a buddylist is simply a handle used to
conveniently reference a group of AoRs for the purpose of reporting
presence info while an AoR is an alias
whose purpose is to stand in for a particular destination address until
such time as it can be fully resolved?  Thus, a buddylist represents a
group of information sources
while an AoR represents a single destination.

Bryan.

--
Bryan Thale
Networks & Infrastructure Research, Motorola Labs
mailto:[email-masked]
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Bryan Thale <[email-masked]>
Date: Thu, 06 Jun 2002 18:05:34 -0500

>     [email-masked]  [email-masked] [email-masked]

Looking at it from the other direction, what does it mean to call a buddylist?

Placing a call to 'fred' will eventually resolve down to one device or at least one user.  That probably isn't what would be intended by a call to 'everybody' which sounds
more like a multiparty call.  If buddylists and AoRs are indistinguishable, how would a SIP application know what is the right thing to do?

> and an address of record?

Isn't the difference that a buddylist is simply a handle used to conveniently reference a group of AoRs for the purpose of reporting presence info while an AoR is an alias
whose purpose is to stand in for a particular destination address until such time as it can be fully resolved?  Thus, a buddylist represents a group of information sources
while an AoR represents a single destination.

Bryan.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Jun 2002 13:28:51 -0400

> more like a multiparty call.  If buddylists and AoRs are indistinguishable, how would a SIP application know what is the right thing to do?

Well, maybe I should have called it 'anybody' instead of 'everybody'.

It certainly is plausible that I want just want to talk to any member of bedrock. In this respect it is just like calling 'fred' and getting any of fred's devices.

Calling all of them is harder, in many respects. It probably requires establishing a conference mixer, etc. If that is what you want, it can be achieved in a variety of
ways. You could subscribe to presence, and then call all the contacts that are present. Or you could send an INVITE with a Request-Disposition of 'redirect'. This would
return you all the contact addresses of the members in a 300 response, and you could use that to do multiple invitations.

> while an AoR represents a single destination.

They still sound like the same thing to me.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 09 Jun 2002 01:55:48 -0400

Paul Kyzivat wrote:
> I'm not sure this is a reasonable assumption. As long as we remain
> silent on how the list is managed, it is risky to assume that every
> subscriber has complete knowledge of
> the list content.

Well, the question is whether this package is the right thing to let 
someone know that the list itself has changed, as opposed to just the 
presence of a user on the list changing.

> 
> There seem to be two reasonable alternatives here: provide diff
> information on presence reports from buddylists, or else provide a
> defined way to monitor the content of a
> buddylist itself.

Right. My preference is to have a separate package for that. Indeed, 
there are several "lists" that one might have and wish to watch for 
changes in - authorization lists, deny lists, group lists (for group IM, 
for example), and so on. Itd' be nice those were all handled consistently.

> I am proposing (as a strawhorse) that the concept of buddylist be
> subsumed into a slightly broader role for address of record. This is
> largely a conceptual change - I don't
> It is already permissible to populate a location service with an address
> of record either by using REGISTER or by some other method. One other
> method might be by uploading
> a buddylist.

I am still very uncomfortable with this. If an INVITE arrives for that 
"address of record" the call will fork to the people in your buddy list. 
I don't think this is what you really want to have happen. Probably you 
really want a conference call. Thats generally different from a call to 
an AOR that represents a user, as we know it today. Since I personally 
would only communicate with one of my registered contacts, forking and 
then cancelling unanswered branches makes sense. However, if the AOR 
represents a group, all of the "registered contacts" would communicate, 
and therefore, the conference call makes more sense.

> What I have in mind is that presence should be viewed as hierarchical.
> It is already that way, sort of, but only two levels are acknowledged in
> the hierarchy. The
> In registrations, it is permissible for the Contacts defining one
> address of record to themselves be addresses of record that have lower
> level definitions, etc. (I realize

Generally, call forwarding.

> 
> If you want to understand the full hierarchical structure of
> registrations of that sort, you have to drill down one level at a time.
> It should be possible to do exactly the
> same thing for presence. Alternately, it might be more helpful for a
> presence subscription to be recursive, perhaps optionally. (This would
> be something like what has been
> These could all be valid sip addresses to call. They are also
> potentially all valid presentities to request presence documents for.
> What is the difference if I ask for the
> presence of 'everybody' and get info about its three subordinates, or if
> I ask for the presence of 'fred' and get the status of his three
> alternate devices? 

At the very least, I think users who subscribe to this thing will want 
to know the difference.

Beyond that, there is likely to be differences in the information you 
would want to convey at each level. Indeed, in PIDF today, very little 
information exists at the presentity level; its all at the contact 
level. To show that your model is sensible, I think you need to 
demonstarte that the same information and state applies to any level in 
the hierarchy above.

Don't get me wrong - I am not saying that what you are proposing is a
bad idea. In fact, its quite intriguing. But, its a big deviation from 
PIDF today, and from the architectural model that has been the 
foundation of PIDF for some time (RFC 2778).

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Jun 2002 15:55:13 -0400

Jonathan - more comments below.

	Paul

> for example), and so on. Itd' be nice those were all handled consistently.

Whether there is a separate package or not, there may still be a need for diff information. 

The presence event package doesn't provide for diffs. In the absence of filters, it returns all information about the presentity, including all tuples, in each
notification.

Your proposal has distinguished buddylist from presentity. The buddylist eventpackage returns a full set of information about all buddy presentities upon an initial
subscription, and thereafter effectively returns diffs in the sense that it only returns information about individual buddies whose presence status has changed.

So the effect is that there is support for diffs on some but not all of the information. This makes sense if you assume that there might be a lot of buddies per buddylist,
but not a lot of tuples per presentity. But this is only an assumption. There are plausible cases where there might be many tuples for a presentity.

Now I have suggested we merge the concept of a buddylist that has a number of presentities with the concept of a presentity that has a number of tuples. If we do this, then
it gets harder to distinguish when to use a diff behavior and when not to. While this presents a problem to be solved, once it is solved, it will work when the application
is conceptually a presentity with lots of tuples as well as when it is a buddylist with lots of buddies.

One solution would be analogous to what you have already proposed: use two different event package names to distinguish whether the returned notification stream uses diffs
or not. (Even though the addressed entity being subscribed to is an address of record in both cases.) But while this would still be possible, I think there is probably a
better choice. For instance, this might be incorporated into a filter definition.  

> and therefore, the conference call makes more sense.

Which makes sense depends on context. There are lots of useful examples of a group address that I might want to call and really only want to talk to one member of the
group. For instance I might want to call anybody in a particular household, or in a department of an organization.

Nor do I think a given list will only be used one way or the other. There are times when I might want to send a reminder to all members of a group, and other times when I
just need to deal with some member of the group. So this is a matter of expressing the desired manner of using the list, rather than a characteristic of the definition of
the list.

> At the very least, I think users who subscribe to this thing will want

If we can come up with a clear definition of what the difference is, then it should be relatively simple to encode that in a presence document, e.g. as a new sort of status
value.

The hard part is defining the difference. This is *already* a problem: suppose I have two devices, a phone that does voice, and a PC that does chat. I register them both
with the same address of record: sip:[email-masked]. If this same information is translated or rerepresented as a presence document, then it will appear as two tuples for the
presentity. 

What are the implications of doing this:

1) Suppose you have a device capable of either voice or chat. It can generate in invitation offering both. If you send an invitation to my address of record, it will
presumably be forked, and one or the other of my endpoints will be chosen, but you will have little choice in which.

2) A suitable presence client will show them both, perhaps annotated to indicate what media each supports. Using the same device as above, coupled to the presence client,
you can choose which device to send an invitation to. If you wish, you can initiate an invitation to each, and so use both media.

3) In (2) I assumed that your presence-coupled UA sent invitations to the contact address of a tuple. If instead it send the invitation to the presentity address (address
of record) then the results are more like (1), but more disconcerting. I may think I am calling your phone but get your chat UA instead.

There would perhaps be a better, or at least more consistent, result if we consider the location service to have the full set of information that the presence document
represents for a presentity. A forking proxy for an address-of-record would be able to use all of this information to process a call. But to get reasonable and consistent
behavior for calls that are presence driven and those that are not, the presence information almost certainly needs to be enriched to indicate *why* multiple tuples are
present and how choices among them should be made. This is similar to the information provided by callerprefs, but may need further enrichment.

> demonstarte that the same information and state applies to any level in

The presentity level information is pretty minimal in pidf today. Its not clear whether this is a problem or not. In large measure the extra information at the tuple level
is there to characterize the differences between the tuples, or the intended role of each tuple. As long as you assume there is a single top level element, then it needs
less of this information.

OTOH, there is some merit in producing a rollup for the top of the hierarchy - e.g. a status value that somehow represents the aggregate status. This is probably pretty
easy as long as you restrict status to OPEN and CLOSED. (Presentity is OPEN if any of the tuples are OPEN.) However this is probably simplistic. There may be no general
algorithm for deriving the status of the presentity from the status' of the tuples. If this has to be explicitly generated, then it may not be worth providing.

One simple way of reflecting the general model would be to change the schema so that a <contact> could contain another <presentity> as an alternative to anyURL. This would
permit the hierarchy to be exploded in a single document. But even without this, there is nothing to prevent interpretation of the URL in a <contact> as a reference to
another presentity.

> foundation of PIDF for some time (RFC 2778).

Hey, I'm happy not be be considered insane for proposing it. :-)

I reread that, and I don't think what I am suggesting does a violence to that model. Of course that model doesn't suggest or imply this sort of implementation, but neither
does it seem to prevent it. But were we to go in this direction it would probably be advisable to discuss these concepts specifically.

I realize that this is still half baked. I'm just testing the ideas now. My earlier comments on the registration event package were also part of this same concept. I
haven't responded to your comments on that because that part is still in the oven.

	Paul

---

From: "Adrian Bateman" <[email-masked]>
Date: Mon, 10 Jun 2002 22:50:26 +0100

On 10 June 2002 20:55, Paul Kyzivat wrote:
> I reread that, and I don't think what I am suggesting does a violence 
> to that model. Of course that model doesn't suggest or imply this sort

> of implementation, but neither does it seem to prevent it. But were we

> to go in this direction it would probably be advisable to discuss 
> these concepts specifically.

Don't forget that 2778/2779 only defined the base
vocabulary/requirements. CPIM/PIDF/etc define the implementation
decisions taken to produce our standard IMPP that fits the model.

Adrian.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Jun 2002 18:51:33 -0400

> decisions taken to produce our standard IMPP that fits the model.

Yes. I'm mindful that what we are discussing here is likely at minimum an extension to PIDF. I don't want to derail plans for timely progress on presence.

Hopefully extensions should be sufficient, and could come down the pipeline after the current stuff progresses.

One way to represent more than one level of hierarchy is simply to include a <presence> element in a <tuple> as an extension element. So it could also be added as an
optional element in a future extension and be backward compatible.

A subscription option to receive differences rather than full updates could be encoded in the body as part of a filter. This would make sense, since it is a sort of filter.
And it would be compatible with the current direction.

One thing that might be a problem would be indicating that a response has had filtering and/or differencing applied. Some of it could be handled as extension values in
tuples, but I can foresee a need to know this at the <presence> level too. One possible change to the current proposed PIDF format that might help here would be to make
explicit provision for extension values within <presence> itself. This would look like:

      <xs:complexType name="presence">
         <xs:sequence>
            <xs:element name="tuple" type="tns:tuple" maxOccurs="unbounded"/>
            <xs:element name="note" type="xs:string" minOccurs="0"
                maxOccurs="unbounded"/>
*           <xs:any namespace="##other" processContents="lax" minOccurs="0"
*              maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute name="entity" type="xs:anyURI" use="required"/>
      </xs:complexType>

Another approach for handling this kind of change would be to simply define a different presence document type for representing diffs and multilevel presence status.
Clients wanting to use it would then have to be prepared for servers that can't handle it, by falling back to the old PIDF.

	Paul

---

From: "Adrian Bateman" <[email-masked]>
Date: Tue, 11 Jun 2002 06:49:48 +0100

On 10 June 2002 23:51, Paul Kyzivat wrote:
> One thing that might be a problem would be indicating that a response 
> has had filtering and/or differencing applied. Some of it could be 
> handled as extension values in tuples, but I can foresee a need to 
> know this at the <presence> level too. One possible change to the 
> current proposed PIDF format that might help here would be to make 
> explicit provision for extension values within <presence> itself. This

> would look like:

This has been mentioned in the past, but AFAIK, this is the first
concrete example of *why* we should make it. In the past, I think I've
probably stuck with the letter of 2778 using our current approach, but
on the basis that this is such a small change, has been requested a few
times, and generally looks like a good idea, I think we should adopt it.

> Another approach for handling this kind of change would be to simply 
> define a different presence document type for representing diffs and 
> multilevel presence status. Clients wanting to use it would then have 
> to be prepared for servers that can't handle it, by falling back to 
> the old PIDF.

I'd like to avoid that if possible - I think we should make the change.

Adrian.