Subject: RE: [Simple] Updated presence spec

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 24 Sep 2001 17:07:35 -0400

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, September 24, 2001 4:59 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]'
> Subject: Re: [Simple] Updated presence spec
> 
> > > These seem to conflict - unless the response to receipt of a
> > > Subscription-Expires header with value 0 is treated as a 
> special case
> > > different from normal subscription expiration. That kind 
> of special
> > > casing seems like a bad idea.
> > 
> > It is a special case. Its a forceful termination of a 
> subscription, along
> > with an explicit request to recreate it elsewhere. The 
> difference is really
> > required for migration of subscriptions to work (and other 
> things are
> > supported by it too).
> 
> Then can this be made clearer? In which cases should tags, 
> route headers
> and contacts not be reused in a refresh? Is it in precisely the cases
> where a Subscription-Expires is received with a value of zero? 

Actually, there is supposed to be a parameter in the subscription-refresh
which says you better start from scratch. That would be the explicit hint.

> Or
> perhaps it should be any time that a refresh is being sent after the
> prior subscription has expired? The latter would make sense, 
> and is less
> of a special case.

You may have thought you sent it before the expiration when the server
thought it was afterwards. As such, you don't want this to be time based
IMHO. The explicit flag in the subscription-expires seems most appropriate,
since this is a special case.

That header and this flag should appear in a version of sip-events soon; we
have a dependency issue here unfortunately.

-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: "Brian Stucker" <[email-masked]>
Date: Thu, 4 Oct 2001 16:21:58 -0500

I would have to agree with Paul on a lot of points.

The major concerns that I have with the current draft (and I apologize for
not voicing them earlier,
but I hadn't yet looked into the draft to the level I now am involved in)
are two-fold:

* Migration, as defined in the specification is unreliable without giving a
mechanism to enforce,
  using SIP, that the active PA is able to ensure it's the definitive source
of presence information
  given the restriction that all of the PUA's are registered. 

* The lack of a clear definition of how the PUA's are supposed to
communicate with the PA, or the 
  presence server their presence related attributes (whether this be
caller-prefs in the REGISTER
  for migration, or simply publishing the presence document fragments). We
can all think of ways to
  do this, I'm particularly worried that we all won't come up with the same
way, and won't be able
  to inter-op. Take for example CPL, if someone were to come along today and
try to use CPL in a SIP
  network, where is the draft or RFC (that hasn't expired) that states how
to do it? I've searched, and I
  couldn't find one. The only reason that I can find that CPL
implementations are inter-oping is because
  of an expired draft that gave the publication mechanism.

Jonathan has listed a couple of options for the migration: allow multiple
PA's and let the watchers figure
out the aggregation, or place the restriction that the PA must have the
complete aggregated picture of what
is going on with the various PUA's. I whole-heartedy agree that the first
option is not a good one. However,
since we are operating with a presence mechanism that uses SIP, saying that
the PA had better be definitive,
without having a mechanism (using SIP) to enforce this seems like a gap. The
only solution that any of us
sound like we're willing to live with to solve this problem is to put the PA
in the network, and not let it
migrate, so why not codify this behavior in the draft? I'd suggest just
removing the migration section 
altogether for now.

For the second concern, and just to make things inter-operable, can we make
the REGISTER method the ONLY
way that PUAs can publish presence information to a PA via SIP? Essentially,
remove the references to this
being an example, and just make it the way it works? This leaves the door
open to all of the non-SIP
ways that presence information may be fed to a PA using whatever protocol
someone cares to use, but gives us
an interoperable way of publishing presence via SIP. This wouldn't mandate
that you have to use SIP to 
publish your presence information necessarily, either. Just that if you want
to use SIP, this is the way to
do it. I think this is the direction the Donovan draft is going to take us
anyhow. Right?

Thoughts?

Brian Stucker
Nortel Networks

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Tuesday, October 02, 2001 10:03 AM
To: Jonathan Rosenberg
Cc: [email-masked]'
Subject: Re: [Simple] Updated presence spec

Comments below.

	Paul

Jonathan Rosenberg wrote:
> > Sent: Tuesday, October 02, 2001 9:34 AM
> > To: Jonathan Rosenberg
> > Jonathan,
> > You have satisfactorily answered my concerns, but the text doesn't
> > really reflect what you have said. How about something like the
> > following:
> >
> >  "The first of these phases can occur through configuration,
> > or through
> >   dynamic means. One dynamic means for a presence server to discover
> >   that the function can migrate to a PUA through the REGISTER message.
> >                                         ^
> >                                         is
> 
> Fixed.
> 
> >   Specifically, if a PUA wishes to indicate support for the PA
> >   function, it SHOULD include a contact address in its registration
> >   with a caller preferences "methods" parameter listing
> > SUBSCRIBE [13].
> >   This indicates that it is capable of terminating and processing
> >   SUBSCRIBE, and therefore can act as a PA. A PUA MUST NOT do this
> >                            ^^^                             ^^^^^^^
> >                            may be able to                  act as a PA
> 
> Since a PA is specifically defined for the presence event package, the
> statement "can" is correct, I believe. In fact, the next sentence
validates
> that it can, since it MUST NOT perform this registration if it can't.

I think there is still something wrong here, or at least subject to
misinterpretation.

If a PUA wishes to indicate support for the PA function, it can do as
you say, and it may believe that this indicates that it can act as a PA.
But the situation is different from the point of view of the registrar
that is acting as a PA. It receives the register listing the SUBSCRIBE
method, but it can't know whether this is from a server wishing to act
as a PA, or simply a server that wants to support some other event
package. So from the point of view of the registrar, this only means the
server MAY be able to act as a PA.

It seems like this has further implications for migration of the PA
function. If a PA/REGISTRAR receives a registration that suggests the
possibility of migrating the PA function, it should verify this before
beginning the migration. It could test it by sending a SUBSCRIBE to the
candidate PA and awaiting a successful response.

I think this would work, but it might not be nice for a UAS registering
to handle subscriptions for some other event package. Every time it
updates its subscription it might get dinged by PA testing to see if it
can now handle presence.

> 
> I fixed "do this" as you describe. I also added text at the end of this
> paragraph:
> 
>  Because the ``methods'' parameter does not convey the
> set of event packages for which the PUA can accept SUBSCRIBE, it is
> possible that the PUA will begin receiving SUBSCRIBE requests for
> other packages, possibly ones it doesn't support. As specified in
> \cite{draft-ietf-sip-events}, the PUA {\SHOULD} reject those requests
> with a 489.

Is 489 the best response? What about 305?

The above paragraph covers PAs that inadvertently receive subscriptions
for event packages other than presence. Maybe you need a similar
paragraph for UASs that inadvertently receive subscriptions for
presence:

  Similarly it is possible that a server supporting event 
  packages other than presence will receive SUBSCRIBE requests 
  for the presence package. 

> > I am however still concerned with the notion that a PUA can know
> > definitively that it has complete presence information. Once a PUA as
> > assumed the role of PA, there is nothing to prevent another UA from
> > registering with the original proxy, without notifying the PA
> > of this. I
> > believe the result will simply be unreliable presence information.
> 
> There are really only two choices here. The first choice is that we allow
> multiple PA for a presentity, each of which has access to different
subsets
> of the presence information. This means that we would need to change the
> forking behavior, and then mandate that subscribers be able to merge
> multiple independent presence documents received from multiple sources. We
> discussed that, and elected NOT to do it, since (1) this is a significant
> burden on the watcher, (2) the correct merging process is very policy
> specific, and can only be done reasonably at the presentity's domain where
> the policy resides.
> 
> The second choice is what is documented now - mandate that any PA have
> complete presence state. Enforcement of that can be difficult, but is
easily
> done on a system level. Consider, for example, a provider foo.com that is
> ONLY supporting instant messaging services using SIP. They also provide
> presence to indicate IM status, and only allow one client registered at a
> time. Since foo.com owns and runs the whole system, they can be sure that
> any presence client that has IM status has complete presence state, and
> therefore there is no problem in migrating subscriptions.
> 
> Effectively, enforcement of this requirement cannot be done at an element
> level, but it can be done at a system level.
> 
> I welcome other ideas on how to improve the story on this.

This is clearly a hard problem, and I don't claim to have a complete
answer. Clearly there are special cases where migration can work fine -
such as when there is only one UAS registered for an address. In other
cases the safest policy is probably to not do the migration.

> > I also have a question about the relationship between presence and
> > callerprefs:
> >
> > Suppose a UAS uses callerprefs when registering with a
> > registrar (using
> > callerpref parameters on the Contact headers in the REGISTER). And
> > suppose the registrar is also a PA. Has there been any
> > consideration for
> > reporting the callerpref information in the resulting presence
> > notifications? (I don't see any provision for it now in
> > draft-ietf-impp-cpim-pidf-00.)
> 
> Sure, definitely. Not all can be mapped, but many of them have obvious
> useful presence implications. At one point, we were going to go through
the
> exercise of mapping the caller prefs parameters to the presence data
format.
> However, we decided that this mapping is a matter of local implementation.

Why? This simply guarantees a lack of interoperability.
The mapping of registration to presence provides a base level
of standardization. To the extent that callerprefs is a standard
extension to registration, it also ought to map in a standard way.
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 4 Oct 2001 22:51:28 -0400

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: Thursday, October 04, 2001 5:22 PM
To: Paul Kyzivat; Jonathan Rosenberg
Cc: [email-masked]'
Subject: RE: [Simple] Updated presence spec

>The major concerns that I have with the current draft (and I apologize for
not voicing 
>them earlier, 
>* Migration, as defined in the specification is unreliable without giving a
mechanism to 
>enforce, 
>  using SIP, that the active PA is able to ensure it's the definitive
source of presence 
>information 
communicate with the 
>PA, or the 
caller-prefs in the 
>REGISTER 
can all think 
>of ways to 
way, and 
>won't be able 
>  to inter-op. Take for example CPL, if someone were to come along today
and try to use 
>CPL in a SIP 
to do it? I've 
>searched, and I 
implementations are inter-
>oping is because 

I agree that the issue of knowing when to register with methods=SUBSCRIBE is
a hard one, as we won't always be able to guarantee it can work. I also
agree we need a way for a PUA to be able to push an explicit presence
document to a presence server for distribution (although whether this is the
document that gets distributed is a matter of policy; more on that below). I
think we can kill both these birds with one stone, based on some ideas
mentioned already on the list and some private discussions I've had.

Forget about this stuff about being definitive. If a PUA has presence to
hand out, it is free to register with methods=SUBSCRIBE. Indeed, it may get
a SUBSCRIBE even if it never did such a registration, since the proxy in
front of it might not support caller preferences. In that case, its free to
accept it.

Consider first the case where a presence server acts as a PA. Its job is to
collect presence information from various components that represent the
presentity, and aggregate them together into a presence document. If a few
clients have registered indicating they support the methods=SUBSCRIBE, the
PA can obtain presence information from those clients by subscribing to them
directly. In this case, the watcher is the presence server itself. The PUA
can each upload presence documents to the presence server in NOTIFY requests
for that subscription. Each PUA only sends the presence information it knows
about. The presence server collects and aggregates these. Everything works
great. We have a standard way for the PUA to send presence documents to the
server (through NOTIFY). 

A presence server SHOULD act as PA whenever it is composing presence data
from multiple independent presence sources. If the PA knows that it is, in
fact, not performing a composition function, but merely passing on presence
documents received from a single PUA, then it can migrate the presence
function to that PUA. In this case, when it gets a SUBSCRIBE, it is proxied
to that single PUA.

This puts the burden of deciding on migration into the presence server,
rather than the client, where it really belongs. Since the presence server
knows what inputs to presence are being used, it also knows whether the
function can in fact be migrated.

>I'd suggest just removing the 
>migration section 
>altogether for now. 

I'm willing to entertain that, but its something that can be done within the
scope of the normative aspects of the specification. Thus, it can be done
even if not documented. Describing it makes some sense, I think, so that its
done right.

>For the second concern, and just to make things inter-operable, can we make
the REGISTER 
>method the ONLY 
>way that PUAs can publish presence information to a PA via SIP? 

Absolutely not. One of the fundamental ideas here is that a PA can collect
many sources of presence data. Some are explicit, where a PUA has said "this
is my presence data", such as the NOTIFY mechanism I proposed above. Others
are implicit, where there is some state in the network that describes a
presentity, even though this state was not established for the sole purpose
of presence. Examples of such implicit presence are registrations and
geolocation information.

How a PA combines the explicit and implicit data it has into a final
presence document is a matter of local policy. We should never dictate that,
nor should we ever dictate what sources can be used to create a presence
document. 

>This wouldn't mandate that you have 
>to use SIP to 
>publish your presence information necessarily, either. Just that if you
want to use SIP, 
>this is the way to 
anyhow. Right? 

By no means was the publish requirements draft aimed at producing a spec
that would eliminate using registrations to derive presence data. The aim
was to produce a spec that would allow a PUA to explicitly upload a presence
document fragment to the server. 

-Jonathan R.
---

-----Original Message----- 
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, October 02, 2001 10:03 AM 
To: Jonathan Rosenberg 
Cc: [email-masked]' 
Subject: Re: [Simple] Updated presence spec 

Comments below. 
        Paul 
validates 
subsets 

easily 
the 
format.

---

From: "Brian Stucker" <[email-masked]>
Date: Fri, 5 Oct 2001 09:50:44 -0500

If any PUA is allowed to respond to a SUBSCRIBE, then I think the forking
rules
may cause problems for us. Two questions I would have are:

1. How does the presence server get inserted into the contact list of the
presentity in order to ensure that it sees any inbound SUBSCRIBE requests
for
the user it is serving? Not all proxies are going to be aware of the
presence
server, so would it be the job of the PUA's to register the presence server
as
an additional contact?

2. If a SUBSCRIBE did fork, and it's a free-for-all as to who can respond to
it,
then doesn't this create a race-condition between PA's that have a complete
picture
of the user's presence, and PA's that don't? It would be whomever sends back
the
200 OK the fastest would win out, and you'd wind up with erratic presence
functionality.
Sometimes you'd get the whole picture, sometimes you wouldn't.

...

Using the NOTIFY to publish information from the PUA's to the PA isn't such
a bad idea.
My concerns there would be:

1. How do I push presence information into the network? The network would
have to first
subscribe to my PUA so it could send the NOTIFY.

2. Would we use the same event package for PUA<->PA communication that's
used for PA<->Watcher
communication? If NOTIFY is used, I would argue that we probably shouldn't
use the same event
package so PUA's that don't want to be a PA can discern between a request
for presence information
from a PA, and one from a watcher. The difference being, if a PA is asking
for it, then the PUA can
assume that the presence information is going to be aggregated, whereas with
a watcher, it's not. 

On using the REGISTER, instead of it being the ONLY way, how about making it
the standard way?
People can still send in presence information using NOTIFY, or INVITE, or
whatever else they 
want to use. Just that they need to support at least REGISTER as one of the
ways that they 
publish presence into the network.

...

There's an additional element that is worrying me with migration of the PA
in it's current form.
It leaves additional non-contributory nodes in the routeset between the
watcher
and the PA after a migration has been performed. That worries me. 
Is there a solution to address this that can be put into the draft if the
sections are left in?

Brian

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Thursday, October 04, 2001 9:51 PM
To: Stucker, Brian [NGB:B621:EXCH]; Paul Kyzivat; Jonathan Rosenberg
Cc: [email-masked]'
Subject: RE: [Simple] Updated presence spec

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: Thursday, October 04, 2001 5:22 PM
To: Paul Kyzivat; Jonathan Rosenberg
Cc: [email-masked]'
Subject: RE: [Simple] Updated presence spec

not voicing 
mechanism to 
source of presence 
communicate with the 
caller-prefs in the 
can all think 
way, and 
and try to use 
to do it? I've 

the REGISTER 

want to use SIP, 
anyhow. Right? 

-Jonathan R.
---