Subject: [Sipping] request to adopt registration package as WG item

From: Rohan Mahy <[email-masked]>
Date: Tue, 28 May 2002 19:50:38 -0700 (Pacific Daylight Time)

Hi,

Several reviewers have noted that the mechanism in:

http://www.ietf.org/internet-drafts/draft-beckmann-sip-reg-event-01.txt

is really a general purpose requirement for an event package which
monitors SIP registrations.

Jonathan Rosenberg proposed an alternate version of such a package which
is here:

http://www.jdrosen.net/papers/draft-rosenberg-sip-reg-event-00.txt

Is there interest in adopting this new package as a WG item?

If so, which draft should it based on?
a) the "beckmann" draft
b) the "rosenberg" draft
c) a new draft

thanks,
-rohan mahy
SIPPING co-chair

_______________________________________________
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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 May 2002 15:21:53 -0400

> If so, which draft should it based on?

I think the functionality being sought is a good thing. But I am concerned that we are well on our way to erecting a tower of babel for presence information, and that
something can and should be done to prevent it:

- The "beckmann" draft reuses the presence document, so it doesn't make things worse.

- The "rosenberg" draft introduces new features about registrations that are useful, but at the expense of defining a new document format that may often be produced and
consumed by entities that also produce and consume presence documents.

- Then there is draft-rosenberg-simple-buddylist-package-00, which is about to expire but that addresses another related need. It can get by with the standard presence
document, but to avoid an excess of notifications it must resort either to multipart bodies, or else it may introduce a new document format almost solely for the purpose of
carrying presence data for multiple presentities.

Among the above there are also three distinct event package names.

I believe this situation could be improved by a simple extension to the PIDF presence document format plus slightly respinning the packages that use it:

- introduce a new root element into application/cpim-pidf+xml that may contain multiple <presence> elements. (Given the current state of PIDF, I suppose logistically this
kind of change would require defining a new content type for the enhanced format.)

- the presence package could simply use the new format as an alternative to the old.

- the registration event package could remain a separate package, but share the document format. Internally it can define new status types for the registration-specific
information identified in the "rosenberg" draft. It needs to be a different package because it would be possible to have both for the same presentity, and they could be
different. But a combined presence/registration server could choose by default to treat a subscription for presence as a subscription for registration.

- the "buddylist" package could then use the new document format. It would no longer need to be a new event package at all - a buddylist could simply be a special sort of
presentity that accepts presence subscriptions. And it would make sense to subscribe to either presence or registration via a buddylist. In some cases it would then make
sense to subscribe to presence of either presentities or buddylists without needed to know which is which.

Producers and consumers of these documents would have only one document format to deal with, and we get better and clearer alignment between the semantics of registration
and presence. 

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 30 May 2002 01:37:47 -0400

inline:

Paul Kyzivat wrote:
> I think the functionality being sought is a good thing. But I am
> concerned that we are well on our way to erecting a tower of babel for
> presence information, and that
> - The "rosenberg" draft introduces new features about registrations that
> are useful, but at the expense of defining a new document format that
> may often be produced and

Yes, but they are for different things. Registration state does not
EQUAL presence state, presence state is derived from registration state
(and possibly lots of other things too) after much filtering. As such,
registration information needs to provide a much lower level of detail.
Specifically, registration state really needs to provide information on
the specific contact addresses, their expirations, q values, and so on.
Almost none of that information is really useful for presence. A
presence document wouldn't use the contact addresses at all; it would
advertise the address-of-record. Indeed, a presence server generating a
PIDF document using a registration document as input would probably just
check that there exists at least one registered contact that hasn't
expired, and if that exists, the PIDF would contain a "contact address"
(in the rfc 2778 sense) that contains the address-of-record from the
registration, with a status of open. There is therefore a significant
filtering process going on, since the two things represent different
pieces of information.

> I believe this situation could be improved by a simple extension to the
> PIDF presence document format plus slightly respinning the packages that
> use it:
> 
> - introduce a new root element into application/cpim-pidf+xml that may
> contain multiple <presence> elements. (Given the current state of PIDF,
> I suppose logistically this

THis is not unreasonable. THe other "list" types of document formats
we've done (like watcherinfo) do exactly this. I think the PIDF
assumption was that the presence server never modifies presence
documents; it merely takes those provided by the end users, and
distributes them. I believe this is a narrow vision of the usage of
presence... 

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. 

> - the registration event package could remain a separate package, but
> share the document format. Internally it can define new status types for
> the registration-specific
> information identified in the "rosenberg" draft. It needs to be a
> different package because it would be possible to have both for the same
> presentity, and they could be
> different. But a combined presence/registration server could choose by
> default to treat a subscription for presence as a subscription for
> registration.

See above comments; I do think this is different. Indeed, there are a
bunch of attributes in the registration doc format that don't exist (and
don't make sense) for presence. This includes the contact states, the
params, callid, and cseq attributes...

> 
> - the "buddylist" package could then use the new document format. It
> would no longer need to be a new event package at all - a buddylist
> could simply be a special sort of
> presentity that accepts presence subscriptions. And it would make sense
> to subscribe to either presence or registration via a buddylist. In some
> cases it would then make

There are differences, most notably in the need for diffs in the case of
buddylist. 

-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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 May 2002 09:39:58 -0400

comments inline.

	Paul

> filtering process going on, since the two things represent different

I think this is a difference of degree rather than of kind. It is true that I *might* want all of my registered contact information rolled together into one aggregate
presence status for my address of record. 

But that isn't necessarily the case. If I have managed to get both home and office phones registered, it might well make sense to represent them as separate <tuple>s in the
presence document, each with its own contact address. The address of record of the presentity is still there in the document, giving the caller a bit more choice.

Using the same format for both doesn't seem to hurt, and it provides the potential to exploit the similarities when desired. So, as I suggested, one *option* for a combined
registrar / presence server might be to return the same document for both registration and presence. Another might be to summarize the registration information in some way,
and a third might be to return the registration data when asked, but to proxy presence subscriptions to one of the registered contacts. 

In many/most cases all of these alternatives would probably result in reasonable results for presence subscribers.

> params, callid, and cseq attributes...

A bunch of these do make sense for presence documents - the params and maybe the contact states make reasonable sense as specialized <tuple> status values, the q-value of a
Contact maps directly as a <priority>, and the description from the contact maps well to a <note>.

They don't exist now in the presence document, but I think they should. Given the intended extensibility of the presence document, I think it makes perfect sense to define
these in a schema having to do with subscribing to registration data, but incorporated into a presence document format.

I've said it before, and I will say it again - I think there is an important duality between the callerprefs in registration and the status of presence tuples. By default,
there ought to be some consistency between the presence status I expose that indicates my willingness to take calls, and the preferences I indicate for accepting calls at
the devices I register. Defining the callerprefs parameter types as new presence status alternatives would help in adding some richness to the current alternatives of
"open" and "closed".

I admit that the callid and cseq don't make much sense in a presence document, but it wouldn't hurt to put them there anyway. They would simply be ignored by those who
don't care, or could be filtered away. (BTW, why did you include them in the document? What possible use could a subscriber make of them?)

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

> > it would then make

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.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 May 2002 13:25:43 -0400

Ben - comments inline.

	Paul

Ben Campbell wrote:
> 
> One thing to consider is that CPIM PIDF is designed very much for
> portability between different presence protocols--in effect making it
> fairly abstract. That may be very useful for presence, and possibly even
>   buddylists.
> 
> But registration is a very SIP specific thing. Do you envision a
> situation where a non-SIP application would expect to do anything useful
> with registrations?

Yes and No.

I am suggesting that if you really want/need registration information you should subscribe to a registration specific event package. The returned document would be a form
of presence document, but containing specific extensions for representing registration information. This case would not apply to a non-SIP application.

But I am also suggesting that when subscribing to presence, whether via SIP, or via some non-SIP application, the presence document you receive MAY contain
registration-specific information. It could be treated as such, treated simply as interesting additional presence status, or ignored.

You might get such a document because it was convenient to hand you a registration document in lieu of a presence document. Or a presence server might choose to use some or
all of the registration specific extensions intentionally when constructing a presence document, because they are useful to convey presence status.

In the case of SIP-aware applications, having the two documents share the same format could make it easier to write code that uses both.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 30 May 2002 11:02:34 -0500

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 31 May 2002 13:57:16 -0400

Paul Kyzivat wrote:
> I am suggesting that if you really want/need registration information
> you should subscribe to a registration specific event package. The
> returned document would be a form
> of presence document, but containing specific extensions for
> representing registration information. This case would not apply to a
> non-SIP application.

Undoubtedly information that can be represented in a presence document
wouldn't be meaningful in a subscription to a registration package, and
vice a versa. When an element receives a document for a registration
package, which it wants to use to genreate a presence document, I
suspect it will want to generally parse it, process it, remove the
extraneous data, and regenerate a presence document. This is the same
set of operations you need independent of whether the formats are the
same. The savings, I suppose, is the need to understand a second
document format, and potential ease of making new elements for a
registration document available in a presence document. I see the latter
as not important, and the former can be good or bad depending on your
point of view. It might lead to accidental leakage of information from
one to the other when that is not intended.

It all boils down to this basic model that we have for presence, which
is that a presentity's presence information can be obtained from the
collection of a variety of disparate sources. As an example, some of the
things which could be used as inputs to determine user presence:

* registrations
* user specified status
* HLR/VLR information
* call state obtained from the phone the user is using
* geolocating information, from GPS or otherwise
* chair sensor data which detects whether I am sitting in my chair or
not
* motion sensors which determine whether I am in a room or not

ad infinitum. All of these things above fundamentally generate
asynchronous events about a user, and all of that data is collected and
aggregated by the PA which generates presence for the presentity. 

If you accept this model, then I would ask next whether you think ALL of
the things above should all use the same document format? If not, why
the special case exception for registrations? If so, I see this as
potential for a huge mess of parameters and values that make usage of
the document format in any one application too complicated.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 31 May 2002 14:09:21 -0400

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:

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

> 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

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.