Subject: [Simple] Thoughts on uploading authorization documents

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 8 Jun 2001 02:17:10 -0400

Folks,

As I have mentioned in other emails, the largest open issue at the moment
with the proposed watcherinfo authorization mechanism is how the
authorization document gets uploaded to the server. Three things have been
proposed:

1. HTTP POST
2. SIP REGISTER
3. SIP <newmethod>, call it SETDATA for now

The benefit of using HTTP POST is that HTTP is far more suitable as a pure
data transfer protocol, and this is exactly the scenario we are talking
about here. The drawback is that we need to authenticate the upload of the
document, and the credentials for that will presumably be within the
databases used for SIP level authentication. Tying the identity in an HTTP
POST request to a SIP identity is a little more complex, but not impossible.
Another drawback is the standard "but I don't want to implement yet another
protocol in my device" argument. 

Approach (2) is already in use for uploading of  scripts. The benefit is
exactly that it is already defined. However, many people think this is a bit
of an abuse of REGISTER, which is really meant to convey address bindings,
not upload arbitrary documents. One can imagine a case where you have a
REGISTER with Contacts and a CPL script. This REGISTER might fail because
(1) the contact list had some kind of problem, or (2) the CPL had some kind
of problem. Since the request might fail for two very independent reasons,
response handling becomes complex. Indeed, this is generally a sign that
something should be its own method. 

Approach (3) stems from this argument. We use SIP, but define a separate
method. This method can be specific for uploading of authorization
documents, or can be more general. Presumably, we would want to use it for
CPL uploads and authorization document uploads, if we go this route. What
both of these share is that the method is setting the value for a specific,
well defined document that the user can specify. THus, it is "setting data".
The primary drawback is that this is a real abuse of SIP; as there is not a
session anywhere to be found here. Arguably this is twisting it into a
database update protocol. The distiguished name of the element to be written
is in the request URI, and the body of the request contains the value of tat
element:

SETDATA sip:[email-masked] SIP/2.0
Content-Type: application/cpl+xml
Content-Length: 102

<cpl>
.....

I assure you that I want nothing less than to use SIP as an LDAP
alternative. 

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 08 Jun 2001 04:39:05 -0700

> data transfer protocol, and this is exactly the scenario we are talking

I fail to see the technical difference between direct-routed SIP/TCP and
HTTP in terms of efficiency.

> POST request to a SIP identity is a little more complex, but not impossible.

It requires making assumptions on creating artificial namespaces,
particularly if you want to run a "real" HTTP server on the same host. I
don't know what mapping you have in mind, but if you do something like

[email-masked] -> host.com/foo or host.com/some/fixed/magic/path/foo

this pretty much rules out running a 'real' HTTP server on the same host
(it's not clear how you'd map port numbers to anything but the default,
except with some explicit SIP header making the association).

Also, with DNS SRV, you have to be really careful that the two mappings
are similar (assuming we'd be using SRV here; if not, this is a separate
disadvantage in terms of naming and scaling). 

> CPL uploads and authorization document uploads, if we go this route. What

I don't necessarily see that the methods have to be the same, but that's
a minor issue. We should use the Content-Disposition to indicate the
property to be set for a particular user.

> SETDATA sip:[email-masked] SIP/2.0

I would not modify the SIP URL. This should be associated directly with
the same identifier, not munging the URL in some arbitrary way which
creates restrictions on naming users.

> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple