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

From: "Christian Huitema" <[email-masked]>
Date: Fri, 8 Jun 2001 10:39:43 -0700

I think it would be more efficient to just use SOAP, and carry it either
over HTTP, or over SIP using a "service" verb.

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, June 08, 2001 4:39 AM
> To: Jonathan Rosenberg
> Cc: [email-masked]'
> Subject: Re: [Simple] Thoughts on uploading authorization documents
> 
> 
> 
> Jonathan Rosenberg wrote:
> >
> > 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
> 
> I fail to see the technical difference between direct-routed SIP/TCP
and
> HTTP in terms of efficiency.
> 
> > 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.
> 
> 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).
> 
> > 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
> 
> 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.
> 
> > 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
> 
> 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.
> 
> > 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
> >
> > _______________________________________________
> > simple mailing list
> > [email-masked]
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: "Robert Brown" <[email-masked]>
Date: Fri, 8 Jun 2001 12:35:43 -0700

This is a good summary of the options.

I believe that there may be deployment issues with HTTP POST, in that
the fact that we have SIP connectivity between two points is not
sufficient to imply that we also have HTTP request connectivity, or that
there is a reliable way to map a SIP URI to an HTTP URL.

I agree that overloading REGISTER semantics introduces some nasty
scenarios.  This is a good example of tight coupling and why designs
should avoid it.

I agree that a data update method could be viewed as a corruption of the
intent of SIP in that it is not session management.  However, this
proposal also appears to have the most practical benefit.

There are plenty of approaches that can be taken here - none of which
are particularly elegant (unfortunately).  For example SOAP over SIP, or
SETDATA that was described in a previous mail, or something analogous to
LDAP 3 or WEVDAV (RFC 2518).

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>

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, June 07, 2001 11:17 PM
> To: [email-masked]'
> Subject: [Simple] Thoughts on uploading authorization documents
> 
> Folks,
> 
moment
> authorization document gets uploaded to the server. Three things have
been
> The benefit of using HTTP POST is that HTTP is far more suitable as a
pure
talking
> about here. The drawback is that we need to authenticate the upload of
the
> databases used for SIP level authentication. Tying the identity in an
HTTP
> 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
bindings,
> not upload arbitrary documents. One can imagine a case where you have
a
because
> (1) the contact list had some kind of problem, or (2) the CPL had some
> kind
reasons,
that
separate
> documents, or can be more general. Presumably, we would want to use it
for
What
> 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
> is in the request URI, and the body of the request contains the value
of

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 11 Jun 2001 00:07:16 -0400

> From: Robert Brown [mailto:[email-masked]]
> Sent: Sunday, June 10, 2001 9:06 PM
> To: Jonathan Rosenberg; [email-masked]
> Subject: RE: [Simple] Thoughts on uploading authorization documents
> 
> 
> > AUTH sip:[email-masked] SIP/2.0
> > Content-Type: application/xml+authdata
> > Content-Length: 290
> 
> AUTH is simple and flexible.  Both good things.
> 
> But is it so flexible that it will end up encouraging the 
> things you're
> trying to avoid?  While the description of AUTH is narrow enough to
> hopefully discourage abuse, it seems that the semantics of AUTH depend
> entirely on the content-type.

Generality and flexibility is a two-edged sword. On the one hand, it allows
you to do things you hand't previously thought of. At the same time, it
opens things up for misuse. Finding the right balance is a very tough task.
I think this thread is all about feeling out where that line is. I think
AUTH is getting closer, but of course nothing can prevent it from being
abused.

-Jonathan R.

---

---

From: Neil Deason <[email-masked]>
Date: Mon, 11 Jun 2001 09:49:23 -0400

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jonathan
> Rosenberg
> Sent: 11 June 2001 05:07
> To: 'Robert Brown'; [email-masked]

On this philosophical point I take the view that
flexibility for unforeseeable good things is better.
We are not the protocol police and neither should
we be the thought police.

What strikes me about the above is that whether you use a
method name of AUTH or SERVICE make little difference,
it is the content type that really matters. The additional
definition of a specific content type application/xml+authdata
would be required to try and make the misuse of things
harder (it is never impossible) at the acknowledged cost
of limiting flexibility.

How about tossing another idea into the melting pot
for discussion. The authorization service could be
specified using Web Services Description Language (WSDL).
This allow a great deal of flexibility but still provides
reasonable control over how we solve the immediate problem.

The details of WSDL data types, messages, operations and
sets of operations for authorization could be defined
within a namespace described by a doc created here and
owned by the IETF. This document can then be imported
into a WSDL describing the implementation of a presence
authorization service by anyone seeking to support it.
The actual binding supplied by each vendor can specify
the details of their implementation of the authorization
service.

Implementations can choose to make the presence
authorization service available through any interface
that has a WSDL binding schema. This could be SOAP over
HTTP, SOAP over SIP (for SIP/UDP only supporting clients),
HTTP POST (for non SOAP supporting clients), even SIP
alone if the binding was defined. There is no restriction
on the number of bindings a service provider makes available.
Also within their own WSDL implementors can take advantage
of extensibility to provide value add differentiators as they
see fit. Meanwhile the standard components can evolve within
the IETF namespace document over time.

So for a simple (and doubtless buggy) example the
following document describes a trivial watcher
authorization methods and operation. There is a
single operation - AuthorizeWatcher with takes the
input of the watcher ID (string) and authorization
status (boolean) and the output is string describing
the result. This abstract description of the service
would be defined by the SIMPLE WG/IETF.

http://schemas.ietf.org/simple/presenceauthorization.wsdl

<?xml version="1.0"?>
<definitions name="PresenceAuthorization"

targetNamespace="http://schemas.ietf.org/simple/definitions"
          xmlns:tns="http://schemas.ietf.org/simple/definitions"
	    xmlns:xsd="http://www.w3.org/1999/XMLSchema"
          xmlns="http://schemas.xmlsoap.org/wsdl/">

    <message name="AuthorizeWatcherInput">
        <part name="watcher" type="xsd:string"/>
        <part name="authorized" type="xsd:boolean"/>
    </message>

    <message name="AuthorizeWatcherOutput">
        <part name="return" element="xsd:string"/>
    </message>

    <portType name="PresenceAuthorizationPortType">
        <operation name="AuthorizeWatcher">
           <input message="tns:AuthorizeWatcherInput"/>
           <output message="tns:AuthorizeWatcherOutput"/>
        </operation>
    </portType>
</definitions>

This can then be used in specific implementations to
provide a standard interface into a SIMPLE authorization
service. Implementors provide access to their service by
publishing a WSDL doc built on top of the above.

This example provides an implementation using a SOAP/HTTP
binding but others interfaces to the service could easily
be added within the same WSDL.

http://www.example.com/presenceauthorizationservice.wsdl

<?xml version="1.0"?>
<definitions name="PresenceAuthorization"

targetNamespace="http://example.com/presenceauthorization/service"
          xmlns:tns="http://example.com/presenceauthorization/service"
          xmlns:defs="http://schemas.ietf.org/simple/definitions"
          xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
          xmlns="http://schemas.xmlsoap.org/wsdl/">

   <import namespace="http://schemas.ietf.org/simple/definitions"

location="http://schemas.ietf.org/simple/presenceauthorization.wsdl"/>

    <binding name="PresenceAuthorizationSoapBinding"
type="defs:PresenceAuthorizationPortType">
        <soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
        <operation name="AuthorizeWatcher">
           <soap:operation
soapAction="http://example.com/AuthorizeWatcher"/>
           <input>
               <soap:body use="literal"/>
           </input>
           <output>
               <soap:body use="literal"/>
           </output>
        </operation>
    </binding>

    <service name="WatcherAuthorizationService">
        <documentation>A Watcher Authorization Service using SOAP over
HTTP</documentation>
        <port name="AuthorizeWatcherPort"
binding="tns:AuthorizeWatcherBinding">
           <soap:address
location="http://example.com/authorizewatcher"/>
        </port>
    </service>
</definitions>

Cheers,
Neil.
--
Ubiquity Software Corporation, UK        http://www.ubiquity.net

---

From: "Robert Brown" <[email-masked]>
Date: Mon, 11 Jun 2001 08:45:47 -0700

Sorry, but I fail to see the technical distinction between AUTH and
SERVICE.  There has to be more than just the name of the method.

> Sent: Sunday, June 10, 2001 9:07 PM
> To: Robert Brown; [email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 11 Jun 2001 18:22:36 -0400

> Sent: Monday, June 11, 2001 11:46 AM

Of course. The distinction is in what it does. AUTH uploads a policy
document that is enabled to define who is able to access the resources at
the URI specified in the method of the AUTH request. There can be separate
types of policy docs, but you can't just put any old thing in there. This
method would preclude someone from, say, setting the value of a variable, or
invoking a media resource. People could abuse it to do other things, but it
won't be interoperable across products, since correct implementations would
only accept policy documents, not arbitrary RPC requests.

-Jonathan R.

---

---

From: Neil Deason <[email-masked]>
Date: Tue, 12 Jun 2001 05:34:45 -0400

> Sent: 11 June 2001 23:23
> types of policy docs, but you can't just put any old thing in 
> there. 

Well anything with a legal media-type is allowed in any SIP 
request. Which includes, amongst many other, things SOAP 
requests described as text/xml.

> This

As I said on my previous post on this thread it is the
content type that is really important not the method name.
So putting to one side the issue of the many different allowed
content types there is a nastier problem lurking if you hope
to act as the thought police by defining some authdata XML
schema to limit usage. 

Presumably authdata would follow CPL and allow extensions 
through XML namespaces. Thus you enable something that is 
designed to be authorization specific to be easily reused 
for non authorization things. Definite misuse but people 
will do it as it is there to be done and the bar is low. 
The results may not be interoperable but what happens if 
it turns out to actually provide a popular feature and we 
want to standardise it later to provide interoperability. 
There is a user base in existence with an implementation 
based on over loading an inappropriate mechanism like CPL or 
authdata.

I would prefer to provide a more appropriate mechanism as a 
starting point for inventiveness through something like SOAP.
Within this generic mechanism things that need to be defined 
as interoperable can be still be specified. In my other 
posting on this thread I gave an example of one way this could 
be done using WSDL for presence authorization. Other things may
not even be specified but at least they can be implemented 
in a more appropriate manner. Maybe some even prove to be good 
ideas and get incorporated into standards later based on 
sensible implementations. Rather than a good idea becoming 
widespread based on popularisation of a misguided 
implementation over-loading something like authdata.

Cheers,
Neil

---

From: "David Simons" <[email-masked]>
Date: Tue, 12 Jun 2001 11:45:20 -0700

It is obvious to me that SIP was written to be a protocol between two
entities that have direct access to the end user.  Without the real
concept that agents may be used on servers that users must accessed form
a remote clients.  The control of these agents will require a
significant number of requests form the user's client.  Authentication
upload is just one of several interactions that will be needed for real
world deployments.  So instead of polluting SIP with a lot of different
methods I think we should give serious consideration to endorsing a
single method to be used by clients to communicate with remote agents.
I think that SERVICE is the solution.  We on SIMPLE can define several
standard SOAP methods that can be used to request services of a general
nature from agents.  Individual implementers can add additional requests
as a value add for their services.

Regards,

David J. Simons
Development Lead
Microsoft Windows RTC

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Monday, June 11, 2001 3:23 PM
To: Robert Brown; [email-masked]
Subject: RE: [Simple] Thoughts on uploading authorization documents

Of course. The distinction is in what it does. AUTH uploads a policy
document that is enabled to define who is able to access the resources
at
the URI specified in the method of the AUTH request. There can be
separate
types of policy docs, but you can't just put any old thing in there.
This
method would preclude someone from, say, setting the value of a
variable, or
invoking a media resource. People could abuse it to do other things, but
it
won't be interoperable across products, since correct implementations
would
only accept policy documents, not arbitrary RPC requests.

-Jonathan R.

---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Jun 2001 01:30:47 -0400

> From: Neil Deason [mailto:[email-masked]]
> Sent: Tuesday, June 12, 2001 5:35 AM
> To: Jonathan Rosenberg; 'Robert Brown'; [email-masked]

Well, by this argument, I should simply dispose of all the SIP methods.
Instead, we'll just have SERVICE. When SERVICE has application/sdp, thats
setting up a session. When it has xml+soap, its invoking a service. In fact,
we can do away with all the SIP headers too, since its the body which really
tells you what to do with the request....

Just because any body type is syntactically allowed, does not mean that all
body types can and should be understood in every request. 

> content type that is really important not the method name.

I'm sorry, but that is just false. The method name describes what function
is being invoked on the server. Period. Are you telling me that INVITE is
meaningless?

> to act as the thought police by defining some authdata XML

I don't know how you come to the ridiculous conclusion that I, or anyone
else, is trying to act as thought police. We have a problem - how to allow
clients to explicitly allow or disallow subscriptions. The approach is just
one way to provide authorization policy, and not the only way. I expect
people to run CPL scripts, java servlets, use web interfaces, and so on, to
determine authorization as well.

> starting point for inventiveness through something like SOAP.

Why don't you just come the whole 9 yards, and specify that CORBA should be
used, and rather than defining any standardized IDLs, we should allow anyone
to use any IDL they like! Wow! Unlimited flexibility. Zero interoperability.

> implementation over-loading something like authdata.

So, if I understand you correctly, you are arguing that because people will
extend and break the protocol anyway, lets design a mechanism that has
virtually limitless extensibility because it actually defines nothing? 

-Jonathan R.

---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Jun 2001 01:39:59 -0400

> From: David Simons [mailto:[email-masked]]
> Sent: Tuesday, June 12, 2001 2:45 PM
> To: Jonathan Rosenberg; Robert Brown; [email-masked]
> a remote clients. 

Not really. The most common form of SIP UA is an agent thats quite remote
from the client - a PSTN gateway. The interface between the user and its
"agent" - the gateway - is via PSTN signaling protocols. Totally outside the
scope of SIP. Indeed, a SIP client is a "user agent", so the notion of it
being an agent on behalf of a user is core to the model.

Others have written applications, like click-to-talk, where the user is on a
web browser, and calls are initiated through web clicks to a remote server
that acts as the user agent. Works just fine.

Others have written apps where the interface between the user and the agent
is voice. THings like personal attendants, where you call up and say "call
bob", are examples of this. The agent speaks SIP to make the call, but the
communication between the user and the agent is via speech recognition.

> The control of these agents will require a
> significant number of requests form the user's client. 

Sure. And in the current uses, its done via HTTP, ISUP, speech, etc.

> Authentication

A truly general mechanism for users to communicate with remote agents is far
beyond the scope of SIP or SIMPLE. As I have pointed out above, things like
HTTP (and the HTML forms that are used to driver user input) and ISUP are
protocols used for this purpose. Regular, HTTP based SOAP might be another
example of such a thing. 

I think we have a fairly concrete problem here, and I'd prefer to solve it
in as simple and well defined manner as possible. 

-Jonathan R.
---

---

From: Neil Deason <[email-masked]>
Date: Wed, 13 Jun 2001 04:55:52 -0400

comments inline...

> Sent: 13 June 2001 06:31
> To: 'Neil Deason'; Jonathan Rosenberg; 'Robert Brown';

Agreed. I just wanted to highlight the possibilities, not
advocate their use.

> is being invoked on the server. Period. Are you telling me

No. I am saying the proposal for AUTH as a solution is
incomplete without the definition of authdata to go with
it. This needs to include how authdata can be extended.

> to use any IDL they like! Wow! Unlimited flexibility. Zero

Not true, interoperability could be defined through WSDL.
I contributed quite a detailed example of how this might work
for presence authorization. I would really appreciate hearing
what you think about it.

> virtually limitless extensibility because it actually defines

I don't think you do understand me correctly. What I am
saying is that any successful protocol will be extended.
Why not provision a sensible starting point for extensions
rather than just letting people find starting points such
as inappropriately adding to CPL or authdata. SOAP could
provide this mechanism and WSDL could define interoperable
usage. As this a wider point than presence authorization
it probably belongs on SIPPING. However, I would still like
to hear your thoughts on the specific usage suggested here
for presence authorization.

Cheers,
Neil.

---

From: Neil Deason <[email-masked]>
Date: Wed, 13 Jun 2001 05:19:06 -0400

> [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: 12 June 2001 17:44
> To: 'Robert Brown'; Jonathan Rosenberg; [email-masked]
> > I imagine valid AUTH requests like the following...
> > may cause some discomfort...
> >
> > AUTH sip:[email-masked] SIP/2.0
> > Content-Type: text/xml+soapenvelope
> > ...
> > <SOAP-ENV:Envelope
> >     <UpdateDatabase>
> >        <prop>foo</prop>
> >        <value>1234</foo>
> >     </UpdateDatabase>
> If people were stupid enough to do this sort of thing with methods
> obviously designed for different purposes, we'd already see this
> sort of abuse with, say, REGISTER, INFO, MESSAGE, and NOTIFY.
>
> Oh, wait.
>
> Darn it, Pandora -- where did you put that lid?

If only we had ASN.1 encoded everything that would
have kept a lid on things ;) I thought flexibility and
extensibility were good. That's why we're not using H.323
right? The flexibility and extensibility of SIP allow us
to build new services which consequently allows service
providers to develop new revenue streams (oh yeah and
SIP implementors like us to sell kit ;).

So how about this for a converged application
providing a new service. Say I am finishing work in the
UK but want to know the value of my shares portfolio
when the US markets close. However, I am going to the pub
after work and due to fear of immediate notification of my
losses sending me on a major drinking binge I prefer the
results to be emailed to my work account. Besides, then I
can work out what impact it has on my planned retirement
date on the companies time in the morning which seems only
fair.

I can have this service today through an application
that has wisely decided to support SIP for its flexibility
and extensibility. As I leave I send a MESSAGE to my broker's
stock watcher service carrying a SOAP payload. SOAP is
_not_ just an RPC mechanism it is actually an XML messaging
protocol. RPC is but one application that can be built over
SOAP messaging. This example is of a one way messaging
operation using SOAP. The SOAP message carries all necessary
info about me, my portfolio, where I want the response emailed
to etc.

Using SOAP for encoding this message in XML works _today_.
Using MESSAGE for transporting a XML message doesn't seem
that unreasonable to me. After all if MESSAGE should only be
used as seen to date, to carry plain/text for simple IM
clients, we should redefine the semantics of INVITE to be
a method for only setting up telephony calls.

Finally using SIP in general means I can use the end to
end authentication and encryption (well one day) mechanisms
for security. It means that providers can offer the service
reusing their SIP infrastructure so making a cost saving.
It means that hand held devices can use the same protocol
from IM + Presence as well as this additional type of
service. So is the consensus that this is reasonable use
or abuse?

Cheers,
Neil

---

From: "David Simons" <[email-masked]>
Date: Wed, 13 Jun 2001 17:56:21 -0700

Yes there are solutions out there that use other protocols to
communicate between clients and agents but this doesn't mean that SIMPLE
should use that as a crutch.  We are trying to find enabling solutions
to real world problems.

In particular I'm concerned about HTTP; some in the SIP community seem
to see it as a panacea.  It is true that SIP and HTTP share common
elements but their native topology and namespaces are different.  As
Jonathan pointed out in a previous posting to this group there are
issues with identifying SIP identities in HTTP Post.  And then there is
the issue of finding the appropriate HTTP server to send POST.  A
standardized mapping from SIP URI to an HTTP URL will always cause some
deployment problems, the SIP DNS SRV record may point to a different
server than the HTTP DNS SRV record.  Purity of protocol only ever works
until real-world problems must be solved by it.    

Enabling SIP to provide real-world solutions in its problem space isn't
an abuse of the protocol.  SIP based clients, agents, and services are
going to need to communicate with each other to coordinate that handling
of sessions.  You can argue that there isn't a session to be found but
this coordination is required to properly handle sessions and is
therefore strongly related to sessions.

I don't believe that we are doing SIP or SIMPLE a service by limiting
the protocol such that it can't provide deployable solutions without the
assistance of other high level protocols (please, no one need to point
to DNS and DHCP as counter examples) HTTP doesn't require SMTP or FTP.
So why should SIP/SIMPLE require HTTP?

We should recognize that implementers are going to write application
specific extensions and try to minimize the impact of these extension on
SIP by saying, "Put you application specific extensions here."  Then SIP
will have the following major pieces: Session Management, Notification,
Messaging, Application Data and other broadly expected extensions. 

CPL and presence authorization are two specific examples of the need for
clients to send data to agents and/or server.  So it is obvious to me
that SIP needs a mechanism for some form a session handling data
exchange.  

So if we can agree that application specific extensions and data
exchange are a reality of the SIP/SIMPLE then why don't we just combine
them?  Both SERVICE and SETDATA have been proposed.  It seems to me that
they are really the same thing.  Each is sending content from one SIP
entity to another with the expectation that that content will be used in
the SIP solution space.  

The question then is what do we call this new SIP method?  My personal
preference would be to call it SERVICE.  SETDATA implies storages and
everything discussed so far has centered on providing a server or agent
with some data it can use to provide session handling.  Therefore, the
client is requesting a service from the server and/or agent.   What
content is carried by this new method is application specific.  In the
case of SIMPLE we should specify this content.  Other extensions and
application might choose SOAP.  I for one would like to see SIMPLE use
SOAP, one encoding scheme that is extensible and already defined with a
growing implementation base.   

Regards,

David J. Simons
SDE Lead
Window RTC

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Tuesday, June 12, 2001 10:40 PM
To: David Simons; Jonathan Rosenberg; Robert Brown;

> concept that agents may be used on servers that users must 

Not really. The most common form of SIP UA is an agent thats quite
remote
from the client - a PSTN gateway. The interface between the user and its
"agent" - the gateway - is via PSTN signaling protocols. Totally outside
the
scope of SIP. Indeed, a SIP client is a "user agent", so the notion of
it
being an agent on behalf of a user is core to the model.

Others have written applications, like click-to-talk, where the user is
on a
web browser, and calls are initiated through web clicks to a remote
server
that acts as the user agent. Works just fine.

Others have written apps where the interface between the user and the
agent
is voice. THings like personal attendants, where you call up and say
"call
bob", are examples of this. The agent speaks SIP to make the call, but
the
communication between the user and the agent is via speech recognition.

> single method to be used by clients to communicate with remote agents.

A truly general mechanism for users to communicate with remote agents is
far beyond the scope of SIP or SIMPLE. As I have pointed out above,
things like
HTTP (and the HTML forms that are used to driver user input) and ISUP
are protocols used for this purpose. Regular, HTTP based SOAP might be
another example of such a thing. 

[David Simons]I would disagree that providing rich solutions to session
management is beyond the scope of SIP.  The use of other protocols will
cause issues that we solve in an expectable manor. 

I think we have a fairly concrete problem here, and I'd prefer to solve
it
in as simple and well defined manner as possible. 

[David Simons]Concrete yes but simple is doesn't seem to be.  Else we
would have had consensus on a solution by now.  Access control is always
more complex then it seems. 

-Jonathan R.
---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 16 Jun 2001 13:47:17 -0400

> Sent: Wednesday, June 13, 2001 5:19 AM
> To: [email-masked]; 'Robert Brown'; Jonathan Rosenberg;
> stock watcher service carrying a SOAP payload. 

This is the part that baffles me. Stock price notification is a classic SOAP
application, and something that people are using SOAP over HTTP for. You can
build exactly this app, as you describe it, with regular, normal,
well-defined, w3c supported SOAP over HTTP. Why does it ALL have to be SIP?
Would you propose that the email that gets sent to be over SIP too?? In
fact, SOAP, as I understand it, is most commonly used between back end
systems, and so is not likely to be seen by client devices in many cases..

> that unreasonable to me. 

What is the value proposition over regular SOAP over HTTP? You now need to
go out to all these B2B e-commerce guys and convince them to send you SOAP
messages in SIP instead of HTTP. Why? There is no user discovery, there is
no session  (as there is for both presence and IM). SIP provides little
value in this scenario.

> After all if MESSAGE should only be

MESSAGE can carry all different types of content, but the semantics of what
MESSAGE means remains unchanged - this content is for rendering to a person.

> reusing their SIP infrastructure so making a cost saving.

But the SOAP messages are not routed to a "person" (for which existing SIP
infrastructure is built to support), they are sent to an ecommerce stock
site, in your example. Such a thing doesn't move around, doesn't have
multiple points of attachment, etc., all of the things that a SIP network is
built to support.

> service. So is the consensus that this is reasonable use

Using the "same protocol" needs to be considered carefully. It makes sense
only when there is a strong tie between the needed function and the existing
protocols. 

-Jonathan R.
---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 16 Jun 2001 13:50:40 -0400

-----Original Message-----
From: David Simons [mailto:[email-masked]]
Sent: Wednesday, June 13, 2001 8:56 PM
To: Jonathan Rosenberg; Robert Brown; [email-masked]
Subject: RE: [Simple] Thoughts on uploading authorization documents

>So if we can agree that application specific extensions and data exchange
are a 
>reality of the SIP/SIMPLE then why don't we just combine them?  Both
SERVICE 
>and SETDATA have been proposed.  It seems to me that they are really the
same 
>thing.  Each is sending content from one SIP entity to another with the 
>expectation that that content will be used in the SIP solution space.  

AUTH has also been proposed. I believe it covers the case of CPL and
authorization data upload, but is more well defined that SETDATA or SERVICE.

-Jonathan R.

---

---

From: "Robert Brown" <[email-masked]>
Date: Mon, 18 Jun 2001 09:36:31 -0700

> Sent: Saturday, June 16, 2001 10:51 AM
> To: David Simons; Robert Brown; [email-masked]

But AUTH _isn't_ better defined than SERVICE or SETDATA.

As far as I can tell the semantics of AUTH are:
1. You send an AUTH request to a URI to deliver a document to it.
2. The type and contents of the document are arbitrary, but are intended
for "authorization".
3. "Authorization" is not defined but does include uploading CPL and
approving watchers of a person's own presence.

Am I missing something?  Or is AUTH more intent than spec?

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 21 Jun 2001 02:04:41 -0400

> Sent: Monday, June 18, 2001 12:37 PM
> To: Jonathan Rosenberg; David Simons; [email-masked]

There is more definition than that. When a document is uploaded for some
request URI foo@bar, that means that when a request arrives later on for
foo@bar, the document that is uploaded provides a way to determine whether
to accept, reject, or proxy the request elsewhere. Only document formats
that provide a way for a server to determine what to do with a request that
arrives, can be uploaded. That includes CPL and it includes a policy list of
accept/rejecfts. But, it doesn't include things like HTML, JPEgs, or
whatever, since they make no sense for this method definition.

So, AUTH seems pretty specific. Its much more specific than SERVICE. SERVICE
just means, do something, and the body says what to do. So, here are some
examples of what one might try to do with service that make no sense with
AUTH:

1. Send a SERVICE request asking for notifications when a stock reaches a
specific value. AUTH can't do this at all, since there is no notion of a
subsequent request here. 

2. send a SERVICE request asking for a third party call to be set up between
A and B. The body is a doc which contains the numbers for A and B. This
makes no sense for AUTH, since, again, there is no subsequent request for
the request URI  for which some processing is done.

-Jonathan R.
---

---

From: "David Simons" <[email-masked]>
Date: Mon, 25 Jun 2001 09:34:57 -0700

Jonathan's comment below about SOAP over HTTP being equal to SOAP in a
sip message assume the topology of a deployed HTTP and SIP network are
always that same.  And that it is a trivial task to map a SIP address to
an HTTP address (URL) in a generic way.  I believe that neither of these
is correct.

Deployment of SIP shouldn't require deployment of HTTP.  Never should we
require this.  All solutions that SIMPLE determines useful enough to
standardize should have a SIP solution. 

I believe those of us that advocate SOAP over SIP are only advocating
its use in support of a SIP deployment not as a general application
server solution.  

Regards,   

David J. Simons
Development Lead
Microsoft Windows RTC

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Saturday, June 16, 2001 10:47 AM
To: 'Neil Deason'; [email-masked]; Robert Brown;

> stock watcher service carrying a SOAP payload. 

This is the part that baffles me. Stock price notification is a classic
SOAP
application, and something that people are using SOAP over HTTP for. You
can
build exactly this app, as you describe it, with regular, normal,
well-defined, w3c supported SOAP over HTTP. Why does it ALL have to be
SIP?
Would you propose that the email that gets sent to be over SIP too?? In
fact, SOAP, as I understand it, is most commonly used between back end
systems, and so is not likely to be seen by client devices in many
cases..

> Using MESSAGE for transporting a XML message doesn't seem

What is the value proposition over regular SOAP over HTTP? You now need
to
go out to all these B2B e-commerce guys and convince them to send you
SOAP
messages in SIP instead of HTTP. Why? There is no user discovery, there
is
no session  (as there is for both presence and IM). SIP provides little
value in this scenario.

> a method for only setting up telephony calls.

MESSAGE can carry all different types of content, but the semantics of
what
MESSAGE means remains unchanged - this content is for rendering to a
person.

> reusing their SIP infrastructure so making a cost saving.

But the SOAP messages are not routed to a "person" (for which existing
SIP
infrastructure is built to support), they are sent to an ecommerce stock
site, in your example. Such a thing doesn't move around, doesn't have
multiple points of attachment, etc., all of the things that a SIP
network is
built to support.

> service. So is the consensus that this is reasonable use

Using the "same protocol" needs to be considered carefully. It makes
sense
only when there is a strong tie between the needed function and the
existing
protocols. 

-Jonathan R.
---

---

From: "Francois-Frederic Ozog" <[email-masked]>
Date: Mon, 25 Jun 2001 20:47:03 +0200

David,

I hope you could explain why SOAP is more desirable than plain XML in SIMPLE context:
1) what do we have with it ?
2) what do we miss without it ?

Thank you

---

From: Neil Deason <[email-masked]>
Date: Tue, 26 Jun 2001 09:03:50 -0400

> I agree that SOAP is very powerful. When I see WSDL 
> descriptions such as the
> one following the one attached, I cannot do but think that 
> SIP payloads will
> become very big and the computing resources needed to handle 
> them may be to
> important.

The WSDL would not go in the payload of a SIP message
carrrying SOAP!! Just like the fact that the CPL DTD 
does not go in a REGISTER when uploading scripts. 

IP fragamentation can be an issue for any large SIP 
messages over UDP but it applies in exactly the same 
way to PIDF, CPL, SOAP and indeed any other XML based 
content. The same computing resources are required for 
these type of applications too. (Bear in mind that that 
PDAs with 200+ MHz processors and 64M RAM are around 
today).

> As Jonathan said, the group does not focus on architecture 
> and a presence
> agent may end-up in a PDA. As the size of SOAP client for 
> Windows is already
> 1.5MB
> (http://msdn.microsoft.com/downloads/default.asp?URL=/code/sam
> ple.asp?url=/m
> sdn-files/027/001/580/msdncompositedoc.xml), I am quite 
> concerned about
> keeping SIMPLE ubiquitous (from server to PDA). 
> Alternatively, the group
> could drop some design goals like the mobility of the Presence Agent.
> 
> What do you think?

I don't think you should base estimations of size on 
the installation executable of a single implementation 
written for a completely different environment. Why
not conclude all SOAP libraries will be 131KB instead?
(Size of the Apache SOAP library.)

Supporting mobility of Presence Agent is obviously
a fundamental design goal for SIMPLE. However, it seems 
likely to me that most SIMPLE devices will need to support 
SIP and XML as a baseline. This naturally opens the way for 
them to run SOAP over SIP for services. Memory and 
processor limited devices actually benefit from this type of 
protocol re-use. But as I said previously this is really 
a matter for outside of SIMPLE. 

Cheers,
Neil.