Subject: RE: [Simple] Updated presence spec

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

Paul,

Thanks for your comments. Responses inline.

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

Its not a hard maximum, its just a recommended one. I'm trying to avoid the
"one update per millisecond" kind of volume. So, its just a question of
where to draw the line, and its quite hard to find that point. 

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

I'll change it to seconds.

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

I've fixed section 2 already as a result of Ben's comments, as he had a
similar concern. I'll soften 5.8 as you describe.

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

Indeed, I'd like a solid way for a PA to upload presence data to a server.
Steve Donovan recently wrote a draft on requirements for such a protocol. We
should move it forward, but we need to clear some work out of the way first.

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

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

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

Or nothing. Old text from when we were using presence urls in the protocol.
Its just SIP URL.

Thanks for your comments,
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: Mon, 24 Sep 2001 16:58:45 -0400

Further comment below.

	Paul

> required for migration of subscriptions to work (and other things are

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