Subject: RE: [Simple] Updated presence spec

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 2 Oct 2001 03:09:52 -0400

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, September 25, 2001 5:36 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]'
> Subject: Re: [Simple] Updated presence spec
> 
> 
> Jonathan,
> 
> In reviewing the new document, I noticed something 
> troublesome about the
> migration description:
> 
> It suggests that a PUA can indicate ability to act as a PA by 
> sending a
> REGISTER with a caller preferences "methods" parameter listing
> SUBSCRIBE, and goes on to say that a PUA MUST NOT do this unless it
> knows definitively that it has complete presence information 
> for a user.
> The problem with this is that the PUA may also be a UA for 
> reasons other
> than presence, and may need to support SUBSCRIBE for event packages
> other than presence. Then it is stuck - it is forced to implement PUA
> functionality as a precondition to advertising support for the other
> event package.

This is an excellent observation.

Fortunately, its not required to implement PUA functionality for all
packages. If it should end up getting a request for a package it doesn't
support, it simply generates a 489. This would be a problem if the text
about not forking were still in there; but its not. A proxy will fork the
SUBSCRIBE to all registered contacts that support it, and so long as one PUA
supports the event package thats been requested, things work fine. In a
world where there are lots of packages, this could cause more useless
traffic to the PUA than you might otherwise want. I'll note this in the
spec.

The right way to fix this, ultimately, is to use caller preferences some
more. Caller preferences is extensible, so that one can define new
attributes. You would simply define "events" as another attribute, which
indicates the set of events it supports. A proxy server could then use this
to route requests with specific Event headers to those contacts which have
explicitly supported it. That would eliminate all unecessary overheads.

However, I suspect this is a problem in theory only for the time being, and
we can fix it with the caller prefs parameters when the time comes where it
is a real problem.

-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 09:33:46 -0400

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
  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
  unless it knows definitively that it has complete presence
  information for a user. Because of the forking rules described in
  Section 5.10, a subscriber will only get presence information from
  one PA, and this information has to be complete."

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.

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

	Paul