- From: James Snell <jsnell@lemoorenet.com>
- Date: Mon, 2 Oct 2000 22:20:01 -0700
- To: <xml-dist-app@w3.org>
Hmmm... I think I would tend to ask: what really is the difference between: <?xml .. ?> <XP-SOAP Extensible XML Header> ... </XP-SOAP Extensible XML Header> XP-Header-Length=XXXX XP-Content-Type=YYYY XP-Start-Data-Here- - - - - - - - - [Lump-O-Binary/XML/Any Data...] And something like: <?xml .. ?> <Envelope> <Header> <ContentType>YYYY</ContentType> </Header> <Body> <!-- Lump-O-Binary/XML/Any Data --> </Body> </Envelope> There really is no difference as long as we can come to an agreement on exactly how to insert the lump-o-binary into the body. That issue could be addressed through adjustments to the XML specification rather easily. Such a solution would still be compatible with existing application architectures (it would still be compatible with MIME, HTTP, etc) and would solve several problems in a single go (not just XML-protocol related issues). Personally, I think that building an XML-based protocol that forms the basis of a new SMTP/HTTP/etc would not have a strong impact on network security administration. If you think about it, there really wouldn't be much of a difference than what we have today. XHTTP would be accepted on Port X, XFTP would be accepted on Port Y, XSMTP on port Z, and so on. The beneficial part about such an architecture, however, would be that the server would only need to implement a single processor for each, with protocol specific plugins performing the actual work -- so, instead of multiple applications monitoring multiple ports, with separate security configurations for each, you could have a single application monitoring multiple ports, across multiple protocols with a standard security configuration for all. Just a thought though, I don't claim to be an expert on security related issues either. As for the simplicity versus purity argument... I would agree that the final solution must weigh in more on the side of simplicity than purity, however, as I've already mentioned, I do not think there are enough differences in the two ideas (MIME-style enveloping versus XML-based enveloping) to cause much problems in the way of simplicity. Once we've settled on a standard method of embedding binary into XML, in my opinion it would be just as easy to take either path. - James Snell -----Original Message----- From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On Behalf Of Jack, Adam Sent: Monday, October 02, 2000 5:03 PM To: Henrik Frystyk Nielsen; Kurt Cagle; xml-dist-app@w3.org Subject: RE: ebXML Abandons SOAP Henrik et al, I don't see why being able to transfer binary and/or xml data within a message has much do with what the message is being used for. In other words, whether the message is being used for messaging or RPC or whatever seems to me to be orthogonal to the question of how to embed binary and xml data within a message. Sure they are theoretically orthogonal, and maybe that is sufficient to close this argument. That said however, one attribute of a successful/interoperable standard has been simplicity not theoretical purity. (I was involved w/ X.400 many moons ago and SMTP, for all its warts, has done the world more favours.) I think that "a simple way to pass any type of message" is a worthy goal for a messaging mechanism (and it need not be for an RPC mechanism.) Passing references to data or encoding the data is a workable theoretical solution but I wonder if it is practical, and simple enough to be interoperable. Say that XP runs on an IP port, then will firewall admins open one port -- or many? Will it mean HTTP can come into an enterprise to access data, plus FTP, plus .... etc etc. Sending packets of XML in/out of an enterprise is scary (and exciting) enough, I just don't believe that dependence upon another protocol is practical, or going to be widely adopted/accepted. [Note: I don't claim to be an expert to know for sure, I am just stating my opinion (as somebody who wants to use XP to do these things.)] The purpose of the SOAP message is to provide a consistent and well-defined processing model for the whole message and to allow for a rich composability model where features can live side by side in the same message without stepping on each other. This is the reason for the definition of the term "SOAP processor". Doing this for XML in anything but XML would be extremely difficult unless the data model is the same as for XML in which case we might as well use XML in the first place. Am I missing something to ask if this is not orthogonal to where the data sits in the message? ;-) Is this not still valid if XP looked more something like: <?xml .. ?> <XP-SOAP Extensible XML Header> ... </XP-SOAP Extensible XML Header> XP-Header-Length=XXXX XP-Content-Type=YYYY XP-Start-Data-Here- - - - - - - - - [Lump-O-Binary/XML/Any Data...] ... and this (to me) looks less like a function call, and more like a message. To me this is simple: XML (today) just isn't a good XML envelope, but it is good for extensibility of headers, and as a message body part. Why make us mess around with encodings when a simple enveloping mechanism would remove the need, keep it simple, and still have it extensible. regards, Adam
Received on Tuesday, 3 October 2000 01:22:22 UTC