Subject: [Simple] Updated presence spec

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 31 Aug 2001 14:38:32 -0400

Folks,

I've just submitted an update to the presence spec. Until the update appears
in the archives, you can grab a copy from:

http://www.jdrosen.net/papers/draft-ietf-simple-presence-02.txt

Changes are documented in the changes section. Mostly, it incorporates
things agreed to from IETF 51 and now makes use of the new presence data
format from IMPP.

Thanks,
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, 04 Sep 2001 11:08:40 -0400

> http://www.jdrosen.net/papers/draft-ietf-simple-presence-02.txt

Here are some comments to this document. I suspect some of them apply
equally well to earlier verions, and I apologize for not providing them
sooner.

----------

1) Frequency of presence changes:

Section 5.11 suggests a maximum rate of one notification every 5
seconds. This kind of limit could damage the effectiveness of some call
queuing mechanisms. 

For instance, to support call queuing it could be useful for a PA to
generate presence notifications in response to on-hook/off-hook and
off-hook/on-hook transitions in a UA. If an off-hook/on-hook transition
generates a presence notification, this might well result in the arrival
of an immediate INVITE, and that in turn lead to an immediate
on-hook/off-hook transition. This kind of scenario could lead to
frequencies on the order of a second or less.  Even so, an *average*
maximum rate of once per 5 seconds may be ok in such a scenario.

Section 5.4 also gives examples of when presence changes, and suggests
that the frequency of occurrence ranges from minutes to hours. This
fails to mention the possibility that on-hook/off-hook and
off-hook/on-hook transitions of a phone might alter presence. This
doesn't alter the conclusion of section 5.4 regarding subscription
duration, but mentioning it might alter the implication that a minute is
a practical lower bound on frequency of presence changes.

----------

2) Sourcing presence documents:

Section 2 says:

    Presence User Agent (PUA): A Presence User Agent manipulates
    presence information for a presentity. In SIP terms, this
    means that a PUA generates REGISTER requests, conveying
    some kind of information about the presentity.

whereas section 5.8 says:

   The means by which the PA learns the state of the presentity are
   also outside the scope of this recommendation. Registrations 
   provide one way, and the means by which a PA uses registrations
   to construct a presence document are an implementation choice.

Seems like the statement in section 2 is a bit strong. Perhaps the
sentence beginning with "In SIP terms..." should just be deleted.
Section 5.8 is also too strong. Seems like it can at most state:
"Registrations MAY provide a way, though the means (if any) by which a
PA uses registrations to construct a presence document are an
implementation choice."

Those changes would help achieve the apparent objective of eliminating
any stardard way of making presence state known. But I don't understand
why this is a good thing. Wouldn't it be better to have one way of doing
this that is always available, even while permitting other ways?

----------

3) Routing of Subscribe refreshes

Section 5.10 says:

   Furthermore, when refreshing the
   subscription, the refresh SHOULD make use of the tags from the 202
   and make use of any Contact or Record-Route headers in order to
   deliver the SUBSCRIBE back to the same PA that sent the 202.

while 5.12 says:

   For the second phase, the PA destroys the subscriptions and then
   sends a NOTIFY to each subscriber, with an Subscription-Expires
   header with value 0 [3]. This informs the subscribers that their
   subscription was destroyed, and should be re-established with a
   new SUBSCRIBE (with a new Call-ID).

   The subscribers then create brand new subscriptions, with a new
   Call-ID, no route set and no To tag, and this is sent to recreate
   the subscription.

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.

----------

4) The followng in section 3 is grammatically incorrect:

   When an entity, the subscriber, wishes to learn about presence
   information from some user, it creates a SUBSCRIBE request.
   This request identifies the desired presentity in the request
   URI, using either a SIP URL. 
              ^^^^^^

Something is missing - either a SIP URL or what???

----------

	Paul Kyzivat
	Cisco Systems