Subject: RE: [Simple] Another idea for presence authorization

From: "Christian Huitema" <[email-masked]>
Date: Mon, 16 Jul 2001 09:45:14 -0700

> We have a presence server and a presence client.
> We can standardize the interface between the presence
> server and the presence client, but we can't standardize
> the interface between the presence server and the presentity
> (a human).

I think that Brian is right on target here. In the basic implementation, there is no reason that the authorization to SUBSCRIBE be treated differently from the authorization to INVITE. Very precisely, we don't do anything specific about the authorization to INVITE because we assume that the INVITE triggers a "ringing", would get the attention of the user, and would get an explicit authorization, e.g. by lifting the handset after checking the caller-id. The basic implementation of SUBSCRIBE should do just that: the subscription goes all the way to an UA under direct control of the user, triggers some form of alerting, and is explicitly authorized by the user through some interface.

The more complex scenarios occur when the UA wants to delegate publishing rights to a server in the middle of the network. This is a substantial deviation from the basic SIP architecture. The equivalent for INVITE would be to send the calls to a gateway, and to use some form of out of band mechanism such AUTH or NOTIFY in order to decide whether or not that specific call should be picked.

Indeed, I am not so naïve as to believe that all implementations will be end-to-end. I am just restating the obvious: the remote control of a publisher from the edge of the network is a complex operation that allows for a variety of solutions. Which solution you use is part of the reason why you pick a specific publisher; it may involve the support of specific authorization mechanisms, special rule for merging presence information from multiple terminals, support for various authentication schemes, etc. I don't believe that we can easily standardize that, and I doubt that we should.

-- Christian Huitema

---

From: "Zane Thomas" <[email-masked]>
Date: Wed, 25 Jul 2001 22:33:05 -0700

Jonathan et al,

I spent a number of hours today reading through the messages posted since
the end of April.  Thanks to all for the effort you put into discussing the
issues, hopefully I understand them at least well enough now to participate
in some way.

After reading all the discussion I'm inclined towards the view that a
SUBSCRIBE by A when A is not authorized should not cause B to have to do
anything.  Mixing the authorization and subscription requirements into a
single multistep process seems to be an unnecessary coupling of what should
be loosely related functionality.  The result would be, it seems to me,
difficulties in implementation and lack of flexibility - as has been well
pointed out by Brian.  It also seems to me that embedding urls for
accept/reject into the protocol might unnecessarily cause implementation
headaches for some.

Related to the url concern I also have some concerns about the idea of using
HTTP as *the* way of 'uploading' information.  I think that's fine if that's
what some implementations find convenient.  But I also see the need for a
SIP alternative.  For instance, I might like to run a PS on a small mobile
device or on a server which doesn't allow me access to port 80.

Zane
---
Zane Thomas
President - Mabry Software Inc.
www.mabry.com