Subject: RE: [Simple] Thoughts on uploading authorization documents

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 10 Jun 2001 00:33:42 -0400

> -----Original Message-----
> From: Robert Brown [mailto:[email-masked]]
> Sent: Friday, June 08, 2001 3:36 PM
> To: Jonathan Rosenberg; [email-masked]
> Subject: RE: [Simple] Thoughts on uploading authorization documents
> 
> 
> Perhaps the most flexible and least like a specific database-update
> protocol is SOAP over SIP.  This could be used for setting CPL,
> authorizing watchers, or whatever else, by documenting the appropriate
> SOAP method in each case, but would not necessarily imply a general
> purpose database protocol.
> 
> For example something like this could be used to authorize watchers:
> 
> SERVICE sip:[email-masked] SIP/2.0
> To: sip:microsoft.com
> From: [email-masked] 
> Content-Type: text/xml+authorizewatcher
> Content-Length: XXX
> 
> <SOAP-ENV:Envelope
> xmlns:SOAP-ENV='http://schemas.xmlsoap.org/soap/envelope/' >
>   <SOAP-ENV:Body>
>     <AuthorizeWatcher>
>       <URI>SIP:[email-masked]</URI>
>       <rights>allow</rights>
>     </AuthorizeWatcher>
>   </SOAP-ENV:Body>
> </SOAP-ENV:Envelope>

I really fail to see what value SOAP brings here to the table. It seems to
combine the worst of everything - its still an abuse of SIP and yet still
requires additional code on the clients beyond baseline SIP. As far as
slippery-slopes go, if INFO seemed a problem (and it has been proposed for
all kinds of awful things), SERVICE is going to be even worse. Please lets
not.

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

Perhaps for data push its not signficantly different. For data pull, I can
make some arguments about the existence of caches, special treatment in
routers, etc. which generally make http better for bulk data fetch.

> 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).

It doesn't rule it out; presumably there is only the "real" web server, and
this server is running a cgi script for all requests for
host.com/some/fixed/magic/path/*, placing the scripts into the appropriate
place in the DB. The real disadvantage is that we will need to define this
standardized mapping. 

> > 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
> 
> 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.

Perhaps a reasonable compromise point is to use a SIP method, but keep it
specific for uploading of authorization policies. This avoids the abuse and
slippery slope issues of SERVICE or SETDATA, both of which make me nervous.
So:

AUTH sip:[email-masked] SIP/2.0
Content-Type: application/xml+authdata
Content-Length: 290

.....

AUTH would have the explicit purpose of setting authorization documents that
define access to the resource in the request URI for any method. The
content-type (or a content-disposition) would give further information on
what methods the authorization document applies to.

This is probably a broad enough definition to include CPL (which is, after
all, a form of an authorization document for a URL), but narrow enough to
exclude more general DB operations, or worse.

-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: Sun, 10 Jun 2001 21:12:42 -0400

> routers, etc. which generally make http better for bulk data fetch.

Special treatment in routers? Which router vendor are you using? (I knew
layer violation was common, but routers peeking at HTTP headers is new
to me...) Caches don't apply here, as this is not static data, but
rather similar to HTTP cgi-bin and other non-cacheable content.

> place in the DB. The real disadvantage is that we will need to define this

And we have to make sure that every server and installation can do this
easily. For example, locally, such scripts would have to be at
http://www.cs.columbia.edu/~user_running_server. Plus, you'll have to be
root to run web servers on port 80, so there's yet another configuration
issue.

> exclude more general DB operations, or worse.

This seems about right.