Subject: [Simple] Re: Comments on presence-06

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 16 May 2002 17:21:07 -0400

[email-masked] wrote:
> 
> I hope this is not too late.

Well, WGLC expired some time ago, but I need to do an update because of
the privacy mess, so I can eek in some minor stuff.

> 
> 3. Definitions
> 
> In a normal interpretation on client and server, a client requests and a
> server responds. They perform opposite tasks.
> 
> This leads to the confusion in understanding definitions of Presence
> Client and Presence Server. In this specification, they do the same
> thing and that is to respond to SUBSCRIBE requests and generate NOTIFY
> requests.
> 
> I understand that they share the common name of Presence Agent, but
> calling them Presence Client and Server does not make sense to me. My
> suggestion would be to keep Presence Server as is and change Presence
> Client to something like Presence Edge Server (or something similar to
> highlight the fact that it is the end point).
> 
> Presence Client definition is not used in the description through out
> the document. Section 6.11 hardly uses it when talking about migrations.

I think "edge presence server" is a bit better, but beyond that, I see
your point. I'll change.

> 
> 4. Overview of Operation
> 
> Third paragraph states
> 
>   "If authorization could not be obtained at this
>    time, the subscription is considered "pending", and a 202 response is
>    returned. "
> 
> then
> 
>   "As the state of the presentity changes, the PA
>    generates NOTIFYs for all subscribers with authorized subscriptions.
>    The state of the subscription itself is carried in the Subscription-
>    State header of the NOTIFY, and would typically indicate whether the
>    subscription is active or pending."
> 
> Now, if NOTIFYs are generated, as a result of a change in state of
> presentity, to authorised subscribers only, why would you ever send an
> state update NOTIFY with subscription-state of pending. If the last
> sentence was not talking about NOTIFY updates, it should be split from
> the sentence above it.

I added appropriate transitions. The text now reads:

As the state of the presentity changes, the PA generates
NOTIFYs containing those state changes to all subscribers with
authorized subscriptions. Changes in the state of the subscription
itself can also trigger NOTIFY requests; that state carried in the
Subscription-State header of the NOTIFY, and would typically indicate
whether the subscription is active or pending.

> 
> 5. Usage of Presence URLs
> If the protocol-independent form is used in the R-URI, how do you know
> where the next hop is? do you still apply procedures in sip-srv draft on
> the pres url?

Those procedures would actually result in the translation to a sip URL.
No, you would use a local outbound proxy, much like the tel URL
handling. I'll add a sentence.

> 
> 6.3
> "The body of a SUBSCRIBE request MAY contain a body" should say "A
> SUBSCRIBE request MAY contain a body"

Right.

> 
> 6.6.2
> Third paragraph
> 
>   "For pending subscriptions, the
>    state of the presentity SHOULD include some kind of textual note that
>    indicates a pending status."
> 
> Why is that necessary to merit a SHOULD? It sounds like redundant info
> to me. Subscription-state header carries that info already.

Thats true, but I view the end user as the customer of one, and the UA
as a customer of the other. Clearly, the UA can present to the user.
However, it turns out that this split is really useful for the buddylist
package, since the state of the subscription to the entire list is
actually not the same as the state of the subscription to an individual
buddy. To keep things uniform, I'd therefore like to keep this a should.

> 
> 6.11
> - "On occasion" should be "On occasions".

No, I believe the current usage is gramatically correct. 

> 
> - paragraph 4 states
>   "However, just because a PUA indicates it can accept
>    subscriptions, does not mean a PA should migrate the subscriptions
>    there."
> 
> Why not? I thought this was the dynamic means defining the condition of
> the migration to take place in this package.

The next sentence gives the caveat; it shouldn't if its composing
presence information from multiple PUA.

> 
> 9.5 and 9.6.1 is full of missed spaces. eg. "SUBSCRIBEand"

Fixed.

> 
> 13.
> Reference 3 should be "Common Presence and Instant Messaging (CPIM)"

OK, I'll fix.

> 
> General comment:
> - Fetch of presence info is not mentioned at all in the document. Is the
> intentional?

No, its just not specific to presence. I'll add a sentence in the
overview section.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple