Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda)

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 18 Mar 2001 23:52:58 -0500

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:[email-masked]]
> Sent: Friday, March 16, 2001 9:38 AM
> To: James Undery
> Cc: Jonathan Rosenberg; Christian Huitema;
> [email-masked]
> Subject: Re: Replacing the QAUTH concept (was [Simple] SIMPLE BoF
> agenda)
> 
> 
> James Undery wrote:
> > 
> 
> > I agree with Jonathan here, I really don't like using 
> REGISTER to upload CPL
> > scripts as it allows the REGISTER to do two independent 
> things either of which
> > could fail, firstly update location information (could fail 
> with 409) and
> > secondly store a script which could be illegal. Reporting 
> these two separate
> > results in a single response is ugly.
> 
> Whether this is done via REGISTER or a new method (which may well be
> preferable), using SIP hasa the advantage that the addressing and
> authentication is consistent and that the number of protocols 
> that need
> to be supported stays finite.

There are a few issues here:

1. addressing

If we use some other mechanism to push policy, how do we know for whom the
policy is targeted?

One way is that this information is obtained by a mapping of the http URL.
Something like:

http://www.mydomain.com/presence/users/sip:[email-masked]

would get mapped to sip:[email-masked]. Kind of a pain, and it will vary
from site to site, meaning yet another thing to administer.

Another possibility is that the SIP URL of the presentity is embedded within
the policy document itself:

<policy>
  <presentity uri="sip:[email-masked]">
    <reject-list>
      ...
    </reject-list>
  </presentity>
</policy>

This is at odds with how CPL works, and would make sharing of policy
documents across multiple presentities more complex.

2. authentication

Since http and sip share authentication mechanisms (for basic and digest at
least), and these are probably stored in some backend database in most
systems (or at least in a file on disk), seems like they could be shared
across http and sip servers.

3. protocol reduction count

I am not generally fond of this argument in devices, since you would argue
that everything on a phone (which right now includes sip, rtp, dhcp, ip,
udp, possibly tcp, snmp, http, ...) should be one protocol.
draft-ietf-sip-guidelines explicitly talks about this argument.

Another issue is the bulk transport issue, since these policy languages
could be quite large. As such, http, or sip over tcp, seem like more or less
a requirement. 

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 19 Mar 2001 10:41:33 -0800

> across http and sip servers.

In practice, this is difficult, since many web servers use just plain
passwd or similar files, while many SIP servers use some form of
database (since the number of users tends to be much larger). Thus, you
will have to use a special-purpose, custom-written web server or be
forced to use the Apache mechanism in your SIP server. Neither seems
ideal, to put it mildly. (I have no ambition to re-write Apache, but
it's current user database mechanism is not very suitable for SIP.)

> draft-ietf-sip-guidelines explicitly talks about this argument.

Just because it's more than one protocol doesn't imply that we should be
adding protocols with abandon. 

> could be quite large. As such, http, or sip over tcp, seem like more or less

If this is policy for pending subscriptions, this is likely to be small.