Subject: [Sipping] SIP and SOAP (was RE: [Simple] Thoughts on uploading authorizatio n documents)

From: Neil Deason <[email-masked]>
Date: Mon, 18 Jun 2001 08:42:13 -0400

I have moved the more general discussion of SIP and
SOAP to SIPPING from SIMPLE ... further comments in-line.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
>
> > -----Original Message-----
> > From: Neil Deason [mailto:[email-masked]]
> >
<snip>

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

[Actually I wouldn't want to use MESSAGE for this. I think
defining a new method, SERVICE, is preferable.]

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

I am not saying that SIP should replace HTTP as the
primary transport mechanism for SOAP. HTTP is
massively deployed and the binding for SOAP well
established. But SOAP over SIP can still be useful
in some real world applications. Defining a
standardised SIP binding within the IETF would be a
good thing to promote interoperability amongst
those parties that do want to use it.

Generally the prime motivation for using SOAP over
SIP should be the partipation of a SIP entity and
a possible association with a wider session.
When the desired destination of a SOAP message is
a SIP entity using HTTP for transport would require
standardization, and widespread (re)configuration,
of a mapping for HTTP to SIP namespaces. Including
SOAP messaging within transaction of a call naturally
creates an association with a session.

Taking one example, close to both our hearts, within
a highly distributed and decentralized arch for services
why shouldn't two SIP entities exchange SOAP messages
over SIP. After all as Henning pointed out recently
there is no real technical difference between HTTP
and direct routed SIP/TCP.

Another differentiator between SIP and HTTP as
a transport for SOAP is that HTTP is not inherently
bi-directional. There are limitations in the use
of HTTP for peer-to-peer applications.

In the above example the same protocol reuse arguments
that can be made for IM + Presence over SIP also
apply. A service client could be a memory limited
handheld device that only supports SIP. The
service can then be provided across a service
providers SIP network infrastructure. The security
mechanisms defined by SIP can also be re-used and
therefore accounts/relationship I have with a service
provider re-used too.

> Would you propose that the email that gets sent to be over
> SIP too??

Of course not. SMTP already has its own in built
transport mechanism defined SOAP does not.

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

This is only what has been commonly seen so far in the first
SOAP applications. But it is not due to any limitation of SOAP.
If anything it is more related to the limitations of HTTP as
a transport for SOAP. HTTP is not greatly suited for peer to
peer applications.

> > Using SOAP for encoding this message in XML works _today_.
> > Using MESSAGE for transporting a XML message doesn't seem
> > 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 usaer
> discovery, there is
> no session  (as there is for both presence and IM). SIP
> provides little
> value in this scenario.

I still believe in SOAP over HTTP as the primary transport.
I also believe in choice. SOAP is transport neutral and so
there is no reason to limit it to HTTP only. Bindings for
SOAP over SMTP and BEEP already exist.

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

It would helpful to see such text on semantics in
Section 6 of the IM draft.

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

SIP networks are also built to support the sender
who may do all of these things in this example.
The application layer routing provided by SIP and
the ability to return a response code are directly
applicable to SOAP messaging. Plus there are the
other gains for using SIP, as I indicated above, even
if the receiver isn't mobile - the fact you can use
a SIP device in the first place, the security mechanisms
and infrastructure re-use (which could also give passage
through FW/NATs).

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

I believe that such a case can be made.

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

_______________________________________________
Sipping mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/sipping

---

From: "Eric Burger" <[email-masked]>
Date: Fri, 22 Jun 2001 20:38:39 -0400

The other, other, other reason, besides end-points that only do SIP and the
ease of session correlation, is that for time critical message passing
related to a SIP session, who wants to establish a TCP connection?

_______________________________________________
Sipping mailing list  http://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP