Subject: RE: [Simple] Updated presence spec

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 2 Oct 2001 10:21:41 -0400

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, October 02, 2001 9:34 AM
> To: Jonathan Rosenberg
> Cc: [email-masked]'
> Subject: Re: [Simple] Updated presence spec
> 
> 
> 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 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.

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

> 
> 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.
If a client wishes to directly affect their presence information, they
should instead upload a presence document that describes it explicitly. 

-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: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Oct 2001 11:02:46 -0400

Comments below.

	Paul

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

> \cite{draft-ietf-sip-events}, the PUA {\SHOULD} reject those requests

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

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