- From: Dick Brooks <dick@8760.com>
- Date: Fri, 9 Feb 2001 09:47:04 -0600
- To: "Martin Gudgin" <marting@develop.com>, "Williams, Stuart" <skw@hplb.hpl.hp.com>, "Henrik Frystyk Nielsen \(E-mail\)" <frystyk@microsoft.com>, "Jean-Jacques Moreau \(E-mail\)" <moreau@crf.canon.fr>, "John Ibbotson \(E-mail\)" <john_ibbotson@uk.ibm.com>, "Krishna Sankar \(E-mail\)" <ksankar@cisco.com>, "Lynne Thompson \(E-mail\)" <Lynne.Thompson@unisys.com>, "Marc Hadley \(E-mail\)" <marc.hadley@uk.sun.com>, "Mark Baker \(E-mail\)" <mark.baker@Canada.Sun.COM>, "Nick Smilonich" <nick.smilonich@unisys.com>, "Oisin Hurley \(E-mail\)" <ohurley@iona.com>, "Scott Isaacson \(E-mail\)" <SISAACSON@novell.com>, "Yves Lafon \(E-mail\)" <ylafon@w3.org>
- Cc: <xml-dist-app@w3.org>
Gudg wrote: >Conversely if the XML Protocol Layer does NOT support the notion of a path >then it becomes inherently single-hop. In this latter case path becomes an >application level construct and not part of the core definition of the XML >Protocol. This would simplify the core definition of XML Protocol while >still allowing applications to layer intermediary processing on top of XML >Protocol. This is virtually identical to the discussion occurring within ebXML regarding intermediaries. A point-to-point protocol can be used in a "iterative" fashion between multihop exchanges and this makes the protocol/state machine significantly simpler to implement. The trade-off is the loss of "protocol" support for administrative and other functions that cross intermediaries. However, as you indicated, some of this functionality can be supplied as an application level construct. A good metaphor to help understand the relative complexities of the two approaches is to compare IP routing(packet switching) to SS7 routing (circuit based - used for call setup between telco switches). Dick Brooks Group 8760 110 12th Street North Birmingham, AL 35203 dick@8760.com 205-250-8053 Fax: 205-250-8057 http://www.8760.com/ InsideAgent - Empowering e-commerce solutions
Received on Friday, 9 February 2001 10:53:10 UTC