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 on 
> whether the binding framework, abstractions for MEP's etc. met your needs.

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 the 
> notion of SOAP intermediaries.  In particular if Jabber is "storing and 
> forwarding", you might want to indicate whether and how storage points can 
> 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 of 
> 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 schema 
> 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 say 
> 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
clarity.

> * 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 form 
> of an application/soap+xml envelope.  Not sure if that's the sort of thing 
> 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 
fashion.

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

Peter

Received on Tuesday, 18 January 2005 23:36:55 UTC