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

From: "Francois-Frederic Ozog" <[email-masked]>
Date: Fri, 8 Jun 2001 12:31:14 -0700

I have conceptual and technical issues about HTTP POST.

Building on two protocols SIP and HTTP to provide SIMPLE service does not
look elegant: it should be either full SIP or full HTTP.

HTTP POST is not be available on all devices, for example a WAP J2ME device
does not have HTTP stack.
Presence would require it in addition to the SIP stack wich maight cause
footprint problems.
One could argue we could just use the POST format, but it still requires a
TCP stack, but again TCP may not be available...

Similarly SOAP would require implementation of components that may not be
suitable for the J2ME device.
Basic XML is sufficient.

>
>
> -----Original Message-----
> From: Christian Huitema
> To: Henning Schulzrinne; Jonathan Rosenberg
> Cc: [email-masked]
> Sent: 6/8/2001 10:39 AM
> Subject: RE: [Simple] Thoughts on uploading authorization documents
>
> 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
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif

---

From: Christian Jansson <[email-masked]>
Date: Sun, 10 Jun 2001 18:26:39 +0100

Francois-Frederic Ozog wrote:
> Building on two protocols SIP and HTTP to provide SIMPLE service
> does not look elegant: it should be either full SIP or full HTTP.

Why is the use of two protocols not elegant? Is the use of DNS + HTTP
a non-elegant solution for using the web? Would you rather go for full
HTTP there too? I think one should use the best suited protocol to
solve the given task, and in this case the task is not to set up a
session.

> 
> HTTP POST is not be available on all devices, for example a WAP
> J2ME device does not have HTTP stack. Presence would require it in
> addition to the SIP stack wich maight cause footprint problems.
> One could argue we could just use the POST format, but it still
> requires a TCP stack, but again TCP may not be available...

So you have small device (small footprint requirement) running a
presence app. Is it absolutely necessary to also manage the
authorization from that device? (ok, probably it would be nice)

Consider a SIP app running on UDP or TCP. I'm not into J2ME
but can you have UDP support without TCP? 

And if you don't have a complete HTTP stack, isn't it possible to
reuse the header parsing stuff from the SIP app to minimize the
total footprint?

Christian Jansson
Hotsip
http://www.hotsip.com

> Similarly SOAP would require implementation of components that may
> not be suitable for the J2ME device.
> Basic XML is sufficient.
> 
> 
> >
> >
______________________________________________________________________
________