Subject: Clarifications on S*UBSCRIBE/NOTIFY

From: [email-masked]
Date: Mon, 5 Jul 1999 17:01:55 +0530

Hi, Im in the process of doing the S*UBSCRIBE/NOTIFY thingy and have a few
basic questions:

1. When the user first logs into his SIP Phone Client, I  want him to get a
list of all logged in user.
According to SIP for Presence (SFP), I simply need to send S*UBSCRIBE with
expires:0 to get a list without
changing any state.
However, SFP only gives examples where I want to subscirbe to a specific
user, jdrosen. What is the syntax when I want to get all logged in users ?
A "*" ?

2.   Also, could you point me for a doc which discusses the BNF for
subscribe ?

3. The examples mention the uri as pip:<something>. However, since it is a
regular uri, can I use sip: instead without being non conformant ? I dont
want to use pip as of now.

4. Finally, a while ago I mailed to this list saying that Im returning the
list of users in a response to REGISTER request. I was told that this was
non sip compliant, but section 11 , point 2 (REGISTER vs NOTIFY) states
that even REGISTER can return the present state. I agree that SUB. is a
better way, but returning the user list in response to REGISTER does not
seem against compliance as was indicated.
Do correct me if I am wrong.

Regds
Arjun

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 05 Jul 1999 16:16:38 -0400

> user, jdrosen. What is the syntax when I want to get all logged in users ?

The SIP for presence document is quite a long ways from a standard. It
was a proposal for using SIP for presence, and not a complete protocol
spec. The impp working group will be defining a spec for presence and
IM. They are still working on requirements, which is why the SIP for
presence draft hasn't been cycled. SIP is not alone in the proposals for
the impp protocol. There are several other candidates, including SMTP.

> 2.   Also, could you point me for a doc which discusses the BNF for

In terms of its usage for presence, there isn't any. The pint spec gives
some definitions for S_UBSCRIBE for their application. In any case its
just a method, so I'm not sure what BNF you'd need.

> want to use pip as of now.

Again, "conformance" is a bit ill defined for this draft, as its quite
far from an implementable standard. We chose to use a different URL
scheme because a callable user (sip:something-or-other) is a different
resource than a subscribable user (pip:something-or-other). Perhaps
subscriptions and invitations might be handled by different servers. On
the other hand, its the same protocol (assuming a SIP extension is
used), but just a different method, so perhaps a SIP URL is not
unreasonable.

> seem against compliance as was indicated.

Returning a list of users in a register response is not SIP (rfc2543)
compliant. The SIP for presence document is not a part of SIP, and
anyway does not specify this behavior.

I believe returning the list of all logged in users in response to a
register request is a VERY BAD idea:

1. The current SIP spec clearly states that the response to REGISTER
contains a list of the addresses currently registered to the name
provided by the To field in the REGISTER. Thus, returning a list of all
registered users is non-compliant and will confuse a UAC which is not
expecting such a list. 

2. The fact that I am registered somewhere is a sensitive piece of
information. Simply giving this list to anyone else who registers is
bad. In a complete presence system, access lists would allow each user
to define who is allowed access to their presence information. Only if a
user allowed arbitrary people access to their presence, should their
presence be returned to users who ask for "all logged in users".
Furthermore, getting the list of everyone who is logged in (and willing
to advertise it publicly) should be an EXPLICIT action, not a side
effect of a registration. Perhaps S_UBSCRIBE * is appropriate.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen