W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2005

Re: SOAP XMPP Binding

From: David Fallside <fallside@us.ibm.com>
Date: Mon, 24 Jan 2005 11:17:48 -0800
To: Noah Mendelsohn <noah_mendelsohn@us.ibm.com>
Cc: curbera@us.ibm.com, rubys@us.ibm.com, sanjiva@us.ibm.com, Peter Saint-Andre <stpeter@jabber.org>, www-ws-cq@w3.org, xml-dist-app@w3.org
Message-ID: <OF56A8B7BF.875A9957-ON88256F93.0069FAEF-88256F93.006A0032@us.ibm.com>

i'll put it on this week's agenda

David Fallside
Information Management Stds & OS
Tel 530.477.7169
(TL 544.9665)

             dge/IBM@LOTUS                                              To 
                                       David Fallside/Santa Teresa/IBM     
             01/23/2005 11:53                                           cc 
             AM                        curbera@us.ibm.com,                 
                                       xml-dist-app@w3.org, Peter          
                                       Saint-Andre <stpeter@jabber.org>    
                                       Re: SOAP XMPP Binding(Document      
                                       link: David Fallside)               


Please take a look at the attached.   Although Peter is not asking for a
formal review of his spec at this time,  I suspect he would appreciate some
sort of group response from the XML Protocols workgroup, or at least an
explanation of what the options for coordination might be.

Thank you.

Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142

|         |           Peter Saint-Andre|
|         |           <stpeter@jabber.o|
|         |           rg>              |
|         |                            |
|         |           01/18/2005 06:36 |
|         |           PM               |
|         |                            |
  |                                                                                                                              |
  |       To:       noah_mendelsohn@us.ibm.com                                                                                   |
  |       cc:       www-ws-cq@w3.org, xml-dist-app@w3.org, rubys@us.ibm.com, curbera@us.ibm.com, sanjiva@us.ibm.com              |
  |       Subject:  Re: SOAP XMPP Binding                                                                                        |

Thanks for the quick feedback! Comments inline.

On Mon, Jan 17, 2005 at 12:51:42AM -0500, noah_mendelsohn@us.ibm.com wrote:

> Hey, this is cool!  Thank you for sending this along.  I am not in a
> position at this point to speak formally for the XML Protocols workgroup.

> Indeed the workgroup is meeting more rarely (I.e. trying to declare
> success) and is focussing primarily on bug fixes and maintenance in the
> short- to medium-term, so I don't know what the likelihood is of your
> getting any sort of formal review.

At this point we are looking for an informal review only (i.e., did we
do something really stupid?). When I worked with Shane McCarron on our
spec for XHTML over Jabber/XMPP, we completed an informal review, with
the intent that we will complete a formal review before that spec goes
to Final within the Jabber Software Foundation's standards process.
Presumably we could do the same with the SOAP XMPP Binding.

> * Overall, this looks good, and I'm delighted to see these sorts of
> bindings being created.   We worked hard to layer the SOAP Recommendation

> so that this would be possible, and I'm glad that's proving useful to the

> Jabber community.  Indeed, it would be interesting to hear any comments
> whether the binding framework, abstractions for MEP's etc. met your

The HTTP and Email bindings were not quite defined consistently and it
took me a little while to figure out what the expectations were regarding
proper definition of a binding, which is one reason I think the informal
review would be helpful.

> * I don't know the Jabber protocol in detail, but you mention store and
> forward.  It might be worth saying something about how this relates to
> notion of SOAP intermediaries.  In particular if Jabber is "storing and
> forwarding", you might want to indicate whether and how storage points
> be addressed as intermediaries, and thus whether or not SOAP processing
> can be done at such waystations.

Store and forward in the Jabber/XMPP context means that if an endpoint
is not online at the time a message is sent, the message is stored by
the endpoint's authoritative server for delivery when the endpoint next
becomes available. So if you send a Jabber message to stpeter@jabber.org
but I'm not online, the jabber.org server will store it for me, then
deliver it when I next log in. We don't really have intermediaries in
the Jabber/XMPP world, at least not yet and not as that concept is
defined in SOAP or Web services.

> * I would strongly urge you to consider the emerging MTOM/XOP
> specifications as the basis for your "attachment" work going forward.  I
> think the writing is on the wall that these will be the preferred means
> doing attachments in SOAP.  I'd expect them to go to full W3C
> Recommendation status real soon now.  In the meantime, the Proposed
> Recommendation versions are at:
>     http://www.w3.org/TR/2004/PR-xop10-20041116/
>     http://www.w3.org/TR/2004/PR-soap12-mtom-20041116/
>     http://www.w3.org/TR/2004/PR-soap12-rep-20041116/
> Note that the 3rd of these gives a means not just of carrying binary, but

> of asserting that it is a cached representation of the Web resource at
> some particular URL.  XOP/MTOM map down to multipart/mime as you suggest
> for Jabber, but with a reasonably clean and well-layered processing model

> (in my opinion.)

OK, thanks, I'll have a look at those and discuss the matter with the
main author of the SOAP-Over-XMPP spec (he brought me in to write the
formal binding definition).

> * You probably need to say something about XML 1.0 vs XML 1.1.  For the
> moment, SOAP is XML 1.0 only (primarily because we have a normative
> and there is no way to write a normative schema for an XML 1.1 document
> just yet.)  Not sure where Jabber (or the rest of the industry for that
> matter) is headed on XML 1.1, but it might be worth a sentence or two to
> tell your story, whatever it is.  Specifically, if you allow <?xml
> version="1.1"?> on a Jabber message, then you might have to explicitly
> that the constructs within the <soap:envelope> subtree must result in an
> Infoset that could have been represented in an XML 1.0 document.  No new
> characters in element names, etc.

Currently, XMPP is defined in terms of XML 1.0 and we didn't say
anything about XML 1.1 in RFC 3920, and I think the right place to
discuss this in depth would be rfc3920bis. However, a brief note about
XML 1.1 might be appropriate in the SOAP XMPP Binding for the sake of

> * It would be interesting to consider the pros and cons of supporting the

> SOAP WebMethod feature.  With that, you could have a standard means of
> doing a Jabber request to "Get" a representation of a resource in the
> of an application/soap+xml envelope.  Not sure if that's the sort of
> one commonly does with Jabber.   I'm also not sure whether this is a good

> idea or not.  One advantage of this approach is that it points a way to
> gatewaying into HTTP gets.   Then again, I should admit that industry
> support for WebMethod=GET seems to be all too spotty at the moment, even
> for HTTP.

I still think that the WebMethod functionality is most appropriate for
gateways between XMPP and HTTP, but I'll give some further thought to
whether and how using WebMethod might be appropriate in a more native

> I'm not a WSDL expert, so I haven't reviewed those sections in detail.

I'm no WSDL expert, either, but there are some folks in the Jabber/XMPP
community who might be able to help out with that.

> Similarly, there are others in the XMLP WG who know the HTTP binding
> machine better than I do.  Your equivalent looks close enough to fool me,

> but that doesn't mean much.  Hope this is helpful, and thanks for sending

> it along!

Thanks again for the feedback. I'll be in touch again once I've
addressed some of the open issues mentioned above.


(image/gif attachment: graycol.gif)

(image/gif attachment: pic23949.gif)

(image/gif attachment: ecblank.gif)

(image/gif attachment: doclink.gif)

(image/gif attachment: pic12991.gif)

Received on Monday, 24 January 2005 20:03:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:27 UTC