Subject: [Simple] presence-02 comments

From: Ben Campbell <[email-masked]>
Date: Fri, 21 Sep 2001 15:52:26 -0500

Oops, first attempt bounced.
--------------------------

A few comments, mostly nits. Apologies if these repeat comments from
others(If so, I claim senility):

Section 2:

PUA definition (nit) definition states a PUA sends REGISTERS. Since this
islikely to change with a new publication method we might should drop
the phrase.

PA definition says "Typically colocated with proxy/registrar" This is a
possible configuration, but not necessarily typical.

5.3: reads: "In general, subscriptions will normally
     not contain bodies. The request URI, which identifies the presentity,
     combined with the event package name, are sufficient for user
     presence."

suggested (remove redundant "In general" and fix singular/plural
mismatch: "Subscriptions will normally not contain bodies. The request
URI, which identifies the presentity,combined with the event package
name, is sufficient for user presence."

5.4: Language appears to say that presence only gets changed by
one of the example events.

p7 paragraph2: I thought we were removing "polite blocking" as an
explicitly required feature. In any case, I would not consider it part
of the minimum allowed set of authorization decisions.

5.10: Forking (NIT): text mentions that each PA responds with 202 response.
Should be 2xx class response, since 200's are also allowed.

6.4: Call state subscription: While I assume this is non-normative,
I am afraid its presence will confuse people.

7.3: Refers to PGP authentication in SIP. Hasn't that been removed from
SIP?

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 24 Sep 2001 15:37:08 -0400

Responses inline.

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Friday, September 21, 2001 4:52 PM
> To: [email-masked]; jdrosen
> Subject: presence-02 comments
> 
> 

Even with a different method for UPLOADING presence docs, it is still true
that a PUA can use REGISTER, and that this information can result in a
change in presence. But, I agree it doesn't read quite right. I changed it
to:

\item[Presence User Agent (PUA):] A Presence User Agent manipulates
presence information for a presentity. This manipulation can be the
side effect of some other action (such as sending a SIP REGISTER
request to add a new \header{Contact}) or can be done explicitly
through the publication of presence documents. We explicitly allow
multiple PUAs per presentity. This means that a user can have many

> possible configuration, but not necessarily typical.

Good point. Text now reads:

\item[Presence Agent (PA):] A presence agent is a SIP user agent which
is capable of receiving SUBSCRIBE requests, responding to them, and
generating notifications of changes in presence state. A presence
agent must have complete knowledge of the presence state of a
presentity. One way to do this is by co-locating the PA with
the proxy/registrar, or the presence user agent of
the presentity. However, this is not the only way, and this
specification makes no recommendations about where the PA function
should be located. A PA is always addressable with a SIP URL.

> name, is sufficient for user presence."

Changed.

> one of the example events.

Well, it does say "events that include", meaning the set of events is
larger. But, I'll clarify. Now reads:

> of the minimum allowed set of authorization decisions.

Agreed its not minimum. I changed that bit to read:

Authorization decisions can be very complex. At a minimum, these are
be reject, accept, and pending. Pending occurs when

But I kept the text below which defines how to accomplish polite blocking,
since that particular policy is described in rfc 2779.

> Should be 2xx class response, since 200's are also allowed.

Good catch. Fixed.

> I am afraid its presence will confuse people.

OK, I removed the section.

> 7.3: Refers to PGP authentication in SIP. Hasn't that been 

Yes. It is in rfc2543, which is the normative reference for this, but in
reality no one has it and no one will. SO, I removed the pgp references.

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