Subject: RE: [Simple] Final day - WG LAST CALL : draft-ietf-simple-presenc e-02

From: "Sean Olson (EUS)" <[email-masked]>
Date: Fri, 21 Sep 2001 15:36:29 -0500

Hello,
Here are some minor comments. Hope they are
not too late.

1) Section 3, second paragraph, second sentence
   ",using either a SIP URL." should become
   ",using either a SIP URL or a presence URL [4]".

2) Section 5.6, second to last paragraph
   I think it would be useful to move the text
   about generation of subscription refreshes
   from Section 5.10 to here. The text I am
   referring to is:

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

    This text makes sense not only for the forking case
    but also for the case where pres: URLs are used.
    That is, I believe that if the first SUBSCRIBE request
    contained a pres: URL in the Request-URI, subsequent
    refreshes of that SUBSCRIBE should take advantage of
    the SIP URL present in the Contact: of the 202 response
    to avoid that lookup again (particularly when the 
    client generating the SUBSCRIBE cannot directly handle
    the pres: URL lookup)

3) Section 5.7

    Regarding the use of the Remote-Party-ID header in a
    SUBSCRIBE, do you intend to allow pres: URLs as well
    or only SIP URLs? (very small point)

4) Section 5.12, description of three phases of migration

   It seems that there is a fourth (optional) phase
   missing before the current PA sends NOTIFYs with a
   Subscription-Expires: of 0 to force the current
   subscribers to migrate. This phase would push the
   current presence information from the current PA
   to the new target PA using the same potential 
   mechanisms described in Section 6.3 

   The reason for doing so is to allow the new PA client
   to act on behalf of other non-PA UserAgent:s for this
   presentity.

5) Section 8

   You might want to add a "Content-Length: 0" to 
   appropriate messages.

   You may also want to show an example Notifier
   migration triggered by a REGISTER request
   with ";methods="SUBSCRIBE,MESSAGE". This would
   show the use of the Subscription-Expires header.

Best Regards,
Sean Olson
Ericsson Inc.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 2 Oct 2001 01:53:58 -0400

-----Original Message-----
From: Sean Olson (EUS) [mailto:[email-masked]]
Sent: Friday, September 21, 2001 4:36 PM
To: 'Robert Sparks'; [email-masked]'
Subject: RE: [Simple] Final day - WG LAST CALL : draft-ietf-simple-presenc
e-02

>Here are some minor comments. Hope they are 

Well, I was hoping that -03 would be OK, but I won't refuse comments
received after the end of the official last call.

>   ",using either a SIP URL or a presence URL [4]". 

Right, thanks. Section 4 has it correct, but it needs to be consistent.

>    client generating the SUBSCRIBE cannot directly handle 

Good point. I will move this text to 5.6.

>    or only SIP URLs? (very small point) 

Sure; the text doesn't seem to imply otherwise. I see no need for any
additional text to state this explicitly.

>   to act on behalf of other non-PA UserAgent:s for this 

THe assumption is that any entity that is a PA for a particular presentity
knows the full presence state for that presentity. How the PA knows this, is
outside the scope of the spec. One way is for someone who does know, to push
it to the PA. However, that is really orthogonal to the issue of migration.
As such, I don't really see that as a separate phase of migration.

>   You might want to add a "Content-Length: 0" to 

OK.

>  show the use of the Subscription-Expires header. 

The examples section is already really long; I don't think we need to show
all cases, so I'd rather not add more at this point.

-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