XML Protocol WG DRAFT Requirements

Last Modified: $Date: 2000/11/10 05:04:31 $

Latest revision
This revision
Previous revisions
Vidur Apparao, Netscape, vidur@netscape.com
Paul Cotton, Microsoft, pcotton@microsoft.com
David Ezell, Hewlett Packard, david_e3@verifone.com
David Fallside, IBM, fallside@us.ibm.com
Oisin Hurley, IONA Technologies, ohurley@iona.com
John Ibbotson, IBM, ibbotson@uk.ibm.com
R. Alexander Milowski, Lexica, LLC, <alex@milowski.com>
Eric Newcomer, IONA Technologies, eric.newcomer@iona.com
Henrik Frystyk Nielsen, Microsoft, <frystyk@microsoft.com>
Mark Nottingham, Akamai Technologies, mnot@akamai.com


This document specifies a set of DRAFT requirements for the XML Protocol specification.

Status of this Document

This document represents the current status and thinking of the XML Protocol WG's work on requirements and does not imply concensus within the WG. The document will be updated in the near future as the thinking evolves.

This document is not an official W3C Technical Report. It is to be considered work in progress and does not imply endorsement by the W3C membership nor by the XML Protocol WG. A future revision of this document will become an official W3C Technical Report as a deliverable of the XML Protocol WG in accordance with the WG Charter.

Discussion of this document will take place on the public <xml-dist-app@w3.org> mailing list (Archives) as indicated by the email communiation rules provided in the WG charter.

The current organization of this document follows closely the WG charter which has a section on in scope requirements and out of scope requirements. The exact organization of which items are in each section may change provided that the work is within the WG charter. The WG charter provides a background for this organization and it is recommended that the reader reads the charter before reading this document. The organization may change in a later revision.

The WG has so far concentrated on the in scope requirements and little efforts have been put into editing the current out of scope requirements. Please note the guidance given in the section on Notations used in this document for more details about the layout.

Table of Contents

1 Notations
2 Requirements on Requirements
3 In-Scope Requirements
3.1 General Requirements (5xx)
3.2 Simplicity and Stability (3xx)
3.3 Data Encapsulation and Evolvability (7xx)
3.4 Intermediaries (8xx)
3.5 Data Representation (4xx)
3.6 Protocol Bindings (6xx)
3.7 Convention for RPC (2xx)
4 Out-of-Scope Requirements
4.1 Direct Handling of Binary Data
4.2 Compact Encoding and Compression Issues
4.3 Additional Transport Services
4.4 Application Semantics
4.5 Metadata Descriptions of Services
5 External Requirements
5.1 XForms Requirements
6 Other Requirements
7 Glossary

1 Notations

The following terminology and typographical conventions have been used in this document:

2 Requirements on Requirements

The XML Protocol Requirements must include usage scenarios that describe how XML Protocol is used in various environments. The set of usage scenarios must represent the expected range of XML Protocol's use. The scenarios must be used as design cases during the development of XML Protocol, and it must be possible to determine whether or not the XML Protocol design enables each scenario. In addition, the usage scenarios are intended to help a technically competent person understand the role of XML Protocol.

3 In-Scope Requirements

The subsections here are the same as the subsections of the in-scope section of the charter except for two additional sections.

3.1 General Requirements

The envelope and the serialization mechanisms developed by the Working Group may not preclude any programming model nor assume any particular mode of communication between peers.

The specification will make reasonable efforts to support a broad range of programming models suitable for the applications intended for XP.
The specification developed by the Working Group may not preclude any particular protocol binding between communicating peers.
The specification developed by the Working Group must support either directly or via well defined extension mechanisms different messaging patterns and scenarios. The specification will directly support One-way and Request-response patterns as part of permanently and intermittently connected scenarios. The specification will not preclude the development of other patterns at either the application or transport layers. Examples of such patterns may include Publish-subscribe or Multicast delivery. All patterns and scenarios will be described by relevant use cases.
The Working Group will coordinate with W3C XML Activities through the XML Coordination Group and shall use available XML technologies whenever possible. If there are cases where this is not possible, the reasons must be documented thoroughly.
The specification developed by the Working Group shall be as lightweight as possible keeping parts that are mandatory to the minimum. Optional parts of the specification should be orthogonal to each other allowing non-conflicting configurations to be implemented.
The specification must be suitable for use between communicating parties that do not have a priori knowledge of each other.
The specification must focus on the encapsulation and representation of data being transferred between peers. A peer is a party capable of generating and/or accepting an XP protocol envelope.

3.2 Simplicity and Stability

Focus must be put on simplicity and modularity and must support the kind of extensibility actually seen on the Web. In particular, it must support distributed extensibility where the communicating parties do not have a priori knowledge of each other.

Simplicity is a key element in making distributed systems easy to understand, implement, maintain, and evolve. Modularity and layering are two important design principles for achieving simplicity. Although simplicity can only be measured in relative terms, the Working Group must ensure that the complexity of any solution produced is comparable to that of other current and widespread Web solutions.

Another important aspect of simplicity is ease of deployment. The Working Group will look at various ways of deploying XML Protocol in a manner that is compatible with the existing Web infrastructure.

Over the years, many different companies and individuals have proven the ability to design and implement workable open protocols for distributed computing that operate largely within organisational boundaries. The design centre for XP must include the interoperation of systems across organisational boundaries. The aim is to exploit Web philosophy and Web design principles in order to help foster widespread decentralized computing on the Web.

XP MUST be suitable for widespread use across organisational boundaries in support of the application use cases supplied elsewhere in this document. This suitability requirement implies simplicity in the language of the XP specification, which itself describes a technology that is simple to understand and to implement correctly (see also DR301, DR301a, DR303). Although simplicity can only be measured in relative terms, the Working Group should ensure that the complexity of any solution produced is comparable to that of other current and widespread Web solutions.
XP is a foundation protocol, and therefore its definition MUST be stable over time. Express use of modularity and layering in the resulting design will help assure usability and longevity. Such a framework will allow subsequent extension of the design while leaving the foundation of the design intact. (DR300, DR302 and DR305 relate to stability).

Requirements for simplicity and stability arise in the context of the specification documents and in the context of the protocol technologies being defined.

3.2.1 The XML Protocol Specification Documents

DR300 (absorbs old DRs: DR023, DR0053, DR088)

The requirements that XP be modular, extensible, layered and transport independent (or neutral) (DR308 references modularity, DR302 and DR700 reference extensibility, DR502 and DR800 reference transport neutrality) imply that there is an architectural design model behind XP. This architecture and the extensibility framework MUST be explicitly defined

In this context, layering refers to both XP's support of applications layered on top as well as the capability of XP to be layered on top of (or bound to) a variety of underlying protocols.

The XML protocol specifications MUST be clear and easy to understand. This clarity implies that considerable editorial effort will be required in the structuring of the narrative through both outline/overview and normative reference material.
The XP specification MUST clearly identify conformance requirements in a way that enables the conformance of an implementation of the specification to be tested (see also the W3C Conformance requirements).

3.2.2 The XML Protocol Technologies

DR302 (Absorbs old DR's: DR107)
The XML Protocol MUST support modular extensibility between communicating parties in a way that allows for decentralized extensibility without prior agreement. The WG must demonstrate through use cases that the solution supports decentralized extensibility in a modular and layered manner.

To date the web has been enormously successful because it has enabled the creators of web services to evolve and adapt the interfaces they provide to human clients of the web. A goal of XP is to achieve a similar levels of evolvability, extensibility and adaptability for interfaces between web services.
DR303 (Absorbs old DRs: DR108)
The XML protocol MUST be easy to understand, use, extend and implement. This implies articulation of the concepts embodied in the protocol; modularity around those concepts so that optional features may be skipped if not relevant to a particular application of the protocol; an extensions framework that ensures extensions to the protocol are themselves modular. Modular specification should also provide a pattern for modular implementation.
The XML protocol MUST facilitate the creation of simple applications. Simple applications are those with simple message exchange patterns: one-way or event, synchronous, or two-way request response interactions. The specification will make such simple exchange applications as easy as possible to create and use.
DR305 (Absorbs old DRs: DR003)
The XML Protocol SHOULD provide functionality to enable the creation of complex applications. As the consequences of a failure increase, the need to ensure message integrity and privacy, the need to be aware of delivery semantics, and the need to support more complex exchange patterns for long-lived sessions and for transactional semantics also increase. The XML protocol SHOULD provide facilities (possibly optional standardised header and/or trailer elements) to encourage a common approach for providing facilities such as: authentication, encryption, reliable delivery, sessions and transactions.
DR306 (Absorbs old DRs: DR090)
The XML Protocol and applications of the XML Protocol MUST/SHOULD be easy to deploy - especially in systems already supporting XML technologies like XML namespaces and XML schemas.

The ease with which XP applications can be deployed will be crucial to the success of XP. The design of the protocol architecture must be sensitive to the issues arising in the full spectrum of deployment environments ranging from resource constrained embedded devices (appliances) through high performance service engines..
In cases where there is prior knowledge of the specific interactions that will arise between given XP implementations, it should be possible to create implementations supporting these interactions using only a minimal amount of XML infrastructure.

3.3 Data Encapsulation and Evolvability

For two peers to communicate in a distributed environment, they must first agree on a unit of communication. The XML Protocol Working Group must define such a unit by defining an encapsulation language that allows for applications to independently introduce extensions and new features. In this context, the following requirements for extensions and features must be met:

DR701 Requirement for Encapsulation
The XP specification must define the concept of an envelope or outermost syntactical construct or structure within which all other syntactical elements of the message must be enclosed. The envelope must be described with XML Schema.

The XP specification must also define a processing model that defines what it means to properly process an XP envelope or produce a fault. This processing model must be independent of any extensions carried within the envelope. The processing model must apply equally to intermediaries as well as ultimate destinations of a XP envelope.

DR700 Requirement for Extensibility
The XP specification must define a mechanism or mechanisms that allow applications to submit application-specific content or information for delivery by XP. In forming the standard for the mechanisms, the XP specification may consider support for: To manage the mechanisms, the XP specification must define a set of directives which will unambiguously indicate to an XP processor which extensions are optional and which are mandatory so that it can: In both cases above, the XP processor must fail in a standard and predictable fashion.
DR702 Requirement for Evolution
The XP specification must define the concept of protocol evolution and define a mechanism or mechanisms for identifying XP revisions. This mechanism or mechanisms must ensure that given two XP messages it should be possible, by simple inspection of the messages, to determine if they are compatible. The specification must define the concepts of backwards compatible and backwards incompatible evolution. Furthermore, the XP envelope must support both optional and mandatory extensibility of applications using the XP envelope.
DR703 Requirement for Encapsulation of Status Information
The XP specification must define a means to convey error information as a fault. The capability of XP carrying a fault message must not depend on any particular protocol binding. The XP specification must define a mechanism or mechanisms to allow the transfer of status information within an XP message without resort to use of XP fault messages or dependence on any particular interaction model.

3.4 Intermediaries

Intermediaries are essential parts of building distributed systems that scale to the Web. Intermediaries can act in different capacities ranging from proxies, caches, store-and-forward hops, to gateways. Experience from HTTP and other protocols has shown that intermediaries cannot be implicitly defined but must be an explicit part of the message path model for any data encapsulation language. Therefore, the Working Group must ensure that the data encapsulation language supports composability both in the vertical (within a peer) as well as in the horizontal (between peers).

Intermediaries are essential parts of building distributed systems that scale on the Web. As a result, XML Protocol must support intermediaries.

Because XML Protocol separates the message envelope from the transport binding, two types of intermediaries are possible; transport intermediaries and processing intermediaries.

3.4.1 Transport Intermediaries

Transport intermediaries are interposed by a transport binding, as part of the message exchange pattern that it implies. They do not define a processing model for messages; they only operate as part of the transport binding, as a message routing mechanism and they can not be addressed from within an XP envelope.

XML Protocol must accommodate transport bindings that define transport intermediary roles such as store-and-forward, proxies and gateways.

3.4.2 Processing Intermediaries

Processing intermediaries are full XML Protocol processors; they process the message, but are not the ultimate recipient of it. They may be colocated with transport intermediaries, using them as a routing mechanism, or they may use in-message routing mechanisms.

To enable the interposition of processing intermediaries into the message path, two core requirements must be met:

Targeting - XML Protocol must define mechanisms to enable determination of which message components are eligible for processing by a particular processing intermediary. Message components must be able to be targeted at one or more processing intermediaries.
Reporting - XML Protocol must enable the generation of status and/or error messages by processing intermediaries, and propagation and proper identification of status and/or error messages through processing intermediaries.
XML Protocol must enable processing intermediaries to locate and process the portions of messages intended for them without reading or processing the entire message. This allows them to operate efficiently.

To assure scalability and functionality, XML Protocol must also accommodate, but not define, these processing intermediary mechanisms;

Routing - in-message dictation of a complete or partial path through processing intermediaries
Tracking - enabling message recipients to determine a message's path through preceding intermediates
Caching - defining mechanisms to allow intermediates to reuse messages or parts of messages
Quality of Service - defining required and requested service levels in messages

3.5 Data Representation

With the introduction of XML and Resource Description Framework (RDF) schema languages, and the existing capabilities of object and type modeling languages such as Unified Modeling Language (UML), applications can model data at either a syntactic or a more abstract level. In order to propagate these data models in a distributed environment, it is required that data conforming to a syntactic schema can be transported directly, and that data conforming to an abstract schema can be converted to and from XML for transport.

The Working Group should propose a mechanism for serializing data representing non-syntactic data models in a manner that maximizes the interoperability of independently developed Web applications. Furthermore, as data models change, the serialization of such data models may also change. Therefore it is important that the data encapsulation and data representation mechanisms are designed to be orthogonal.

Examples of relationships that will have to be serialized include subordinate relationships known from attachments and manifests. Any general mechanism produced by the Working Group for serializing data models must also be able to support this particular case.

The XML Protocol data encapsulation and data representation mechanisms must be orthogonal.
The XML Protocol data representation must support using XML Schema simple and complex types.
The XML Protocol data representation must be able to serialize data based on data models not directly representable by XML Schema simple and complex types. These data models include object graphs and directed labeled graphs. It must be possible to reconstruct the original data from the data representation.
Data serialized according to the XML Protocol data representation may contain references to data outside the serialization. These references must be Uniform Resource Identifiers (URIs).
The XML Protocol data representation must be able to encode arrays which may be nested.

3.6 Protocol Bindings

A mechanism for using HTTP transport in the context of an XML Protocol. This does not mean that HTTP is the only transport mechanism that can be used for the technologies developed, nor that support for HTTP transport is mandatory. This component merely addresses the fact that HTTP transport is expected to be widely used, and so should be addressed by this Working Group.

Mapping onto existing application layer protocols may lead to scalability problems, security problems and semantic complications when the application semantics defined by those protocols interfere with the semantics defined by an XML Protocol. The WG may consider issuing a warning about the possible problems of reusing non-safe "transports" like SMTP and others. A mapping onto transport services other than HTTP will only be started if enough interest is shown and time is available.

General transport issues were investigated by the HTTP-NG Activity, which designed a general transport mechanism for handling out-of-order delivery of message streams between two peers. While we do strongly encourage work to be undertaken in this area, it is expected that work in this area will be done in collaboration with the IETF and not as part of this Working Group

The XP specification must not mandate any dependency on specific features or mechanisms provided by a particular transport protocol beyond the basic requirement that the transport protocol must have the ability to deliver the XP envelope as an whole unit. This requirement does not preclude a mapping or binding to a transport protocol taking advantages of such features. It is intended to ensure that the basic XP specification will be transport neutral.
The XP specification must consider the scenario where an XP message may be routed over possibly many different transport or application protocols as it moves between intermediaries on the message path. This requirement implies it must be possible apply many transport or application protocol bindings to the XP message without information loss from the message.
The XP specification should not preclude the use of XP messaging over popular security mechanisms.

Discussion: Whatever this means, I think it may be more suitable to do something like define a standard extension to deal with forms of security mechanisms.

The XP specification should mandate the use of UTF-8 as its character set of choice.

Discussion: There is a very good discussion currently on the WG private mailing list about this topic, when this discussion recedes we can formulate the requirement from the consensus.

The XP specification must provide a normative description of the default binding of XP to the HTTP transport. This binding, while normative, is not to be exclusive. Any protocol binding to HTTP must respect the semantics of HTTP and should demonstrate that it can interoperate with existing HTTP applications.

This requirement does not extend to the provision of normative bindings to other important Internet protocols such as TCP/IP, UDP and SMTP in the XP specification.

Furthermore, the XP specification must provide a normative description of a binding of XP to a subset of HTTP that is compatible with pre-XP Internet browser technology.

Discussion: The latter paragraph, regarding the subset of HTTP, needs use case.

3.7 Convention for RPC

A convention for the content of the envelope when used for RPC (Remote Procedure Call) applications. The protocol aspects of this should be coordinated closely with the IETF and make an effort to leverage any work they are doing

The XML Protocol will contain a convention for representing calls and replies between RPC (Remote Procedure Call) applications. The conventions will include the following:
  1. Unique specification of the program or object and procedure or method to be called based on URI syntax.
  2. The ability to specify the parameters to a call in a request message and the results of a call in a reply messages.
  3. Provisions for specifying errors in a reply message.

Where possible, an attempt will be made to leverage any related work done by the IETF. .

The RPC conventions within the XML Protocol will use the Data Representation model discussed in section 3.5 to represent parameters to a call in the request message and results of the call in the reply message. There will be straightforward mappings of the data types used to a wide variety of widely deployed programming languages and object systems
The XML Protocol will allow applications to include custom encodings for data types used for parameters and results in RPC messages. Mechanisms for automatically binding data represented in RPC messages to native constructs in a programming language will not be precluded.
The XML Protocol will guarantee that RPC messages that encode parameters and results using the default encoding for the base set of data types will be valid for any conformant binding of the RPC conventions. "Valid" in this context means that the semantics of the call should remain identical, irrespective of the programming language or object system used by the caller or receiver.

4 Out-of-Scope Requirements

The subsections contained within are the same as the subsections of the out-of-scope section of the charter.

4.1 Direct Handling of Binary Data

Direct Handling of Binary Data: XML Namespaces provide a flexible and lightweight mechanism for handling language mixing as long as those languages are expressed in XML. In contrast, there is only very rudimentary support (base-64 encodings etc.) for including data languages expressed in binary formats. Such formats include commonly used image formats like PNG, JPEG etc. Although it is inconceivable to imagine a Web without such data formats, it is not considered a priority of this Working Group to solve this problem. This is in part because other organizations (e.g. ebXML and RosettaNet) are already addressing the issue using an approach based on MIME multipart. The Working Group can consider solutions proposed by other groups as a matter of low priority, if there is sufficient interest.
Support passing arbitrary content from third parties (send digitally signed doc w/o touching data) [other than the mechanisms described under 3.5 Data Representation].
It is a requirement that binary data is supported.

Issue (i.040.01):

Do we need to support explicit binary data (or just base64 encoding is fine). Absolute NO on one side, yes on other side. (open for discussion) We should get requirements for binary binding.

Issue (i.040.02):

Duplicate (Does support mean must specify one or more mechanisms?. Lots of discussion of whether this is needed it not). Is this is a part of the core or not? The charter says that we should make this a low-level priority. It is not clear that we should actually do this. It is not fair to say that we have nailed it simply because of demonstrating that it can be done on top. Glossary: what is binary and what is the use cases. What are the ways that SOAP can do it?

4.2 Compact Encoding and Compression Issues

Compact Encoding and Compression Issues: One of the guiding design goals of XML has been that "terseness in XML markup is of minimal importance." Meanwhile, XML is being applied in extremely bandwidth-sensitive environments such as wireless devices. While we recognize the importance of bandwidth optimizations, it is seen as being out of scope of this Working Group to investigate specific compression and encoding mechanisms of XML payloads. In particular, it is outside the scope of this Working Group to define an XML subset.

4.3 Additional Transport Services

Additional Transport Services: Transport services are extremely important in order to actually deliver packages in an efficient and scalable manner. Many current XML messaging proposals use existing application layer protocols such as SMTP, HTTP and BEEP. The XML Protocol Working Group will initially focus on providing a (non-exclusive) mapping to HTTP. Other transports can be addressed if the WG has sufficient resources and time, but are a low priority.
Mapping onto existing application layer protocols may lead to scalability problems, security problems and semantic complications when the application semantics defined by those protocols interfere with the semantics defined by an XML Protocol. The WG may consider issuing a warning about the possible problems of reusing non-safe "transports" like SMTP and others. A mapping onto transport services other than HTTP will only be started if enough interest is shown and time is available.
General transport issues were investigated by the HTTP-NG Activity, which designed a general transport mechanism for handling out-of-order delivery of message streams between two peers. While we do strongly encourage work to be undertaken in this area, it is expected that work in this area will be done in collaboration with the IETF and not as part of this Working Group.
Is multicast a requirement?

Issue (i.025.01):

This is a duplicate.

Requirement that it should be able to run on top of directly TCP - get a port number (not HTTP on other port).

Issue (i.022.01):

This first part is a duplicate and the port number bit needs discussion.

Multicast should be supported (not inventing multicast solutions)

Issue (i.028.01):


4.4 Application Semantics

Application Semantics: The introduction mentioned several additional types of semantic that we expect would be required for common applications including transactions, security etc. Many of the existing XML based protocol proposals include clear application layer semantics that make them well suited for specific tasks including defining specific message exchange patterns, message integrity, user authentication etc. However, the purpose of the Working Group is to provide a framework that can support a vide variety of applications and application protocol semantics including the aforementioned.
We do not expect the Working Group to actively take on defining application layer semantics except where such semantics are general enough to accommodate a large set of applications. In particular, it is anticipated that other initiatives including other W3C Activities and potentially other Working Groups within this Activity (if approved by the W3C Membership) will undertake the important work of defining application layer semantics that use the XML Protocol framework. These work efforts may take place at the same time as those of the Working Group.
Support uniquely identifying messages as entities, so that correlating related message (such as requests and responses) is possible over any transport.

Issue (i.006.01):

The use of the word "entity" is confusing with the XML use of the term.

Support object references

Issue (i.019.01):

Maybe split into targeting on the request and identifying the data in response. Define "object". One definition is that it is a "resource". This may be specific to a programming model and therefore be out of scope. This needs discussion.

Issue (i.019.02):

Everything on the Web is a resource. SOAP has the notion of passing by a URI which has a specified lifetime.

There must be a way to deal with audit trails of the protocol flow.

Issue (i.027.01):

Dominant duplicate.

Requirement for support for routing information to be carried.

Issue (i.031.01):


Requirement that doesn't preclude UI interactions but should not define that UI.

Issue (i.033.01):

Do things put in XP should be human friendly or should it be possible to use more human friendly or allow interaction with human.

xml protocol should work well with popular security mechanisms.

Issue (i.046.01):

Popular ones are smime/ssl/digital signatures.

Issue (i.046.02):

For example SSL, SMIME, DSIG.

A message must have a globally unique identifier.
Shall support multiple interaction patterns (e.g. request/response, RPC, point-to-point, publish/subscribe).
Must not preclude transaction support, discovery of service definitions and security.
Develop an XML-based messaging and remote procedure call system.

4.5 Metadata Descriptions of Services

Metadata Descriptions of Services: An important feature of communicating in a distributed environment is the ability to discover and exchange information that describes how communication between peers can occur.
The focus of the Working Group is generally seen as being the encapsulation and data representation aspect of a larger area of data exchange and processing. As such, we do not expect to distinguish between metadata and data, as we believe this is a choice of the application rather than of the data itself, and the act of communicating about how to communicate is itself communication. Therefore, service discovery and description will not to be taken on by this Working Group.

5. External Requirements

The subsections contained within have been submitted from other W3C Working Groups.

5.1 XForms Requirements

Sent to XP WG mailing list:

XForms models the data to be obtained from the user, specifies how a user interface for obtaining the data is declared using XHTML markup, and finally specifies how the populated data is shipped backed to the server. The [SEND] subgroup is responsible for the interactions between the XForms client and the backend server.

The work on [SEND] could be a replacement for the various methods for posting data to an HTTP server such as application/x-www-form-urlencoded or multipart/form-data.


  1. An XForms client needs to send and receive well-formed XML data that has been defined through the XForms specification. For example, XML data will be "sent" when the user agent is done filling out an XForm or XML data will be "received" when a server ships out initial values for populating a form.
  2. An XForms client needs to send/receive partially completed XML data to/from the server for persistence. This functionality will allow a user agent to "save" or "load" a form in progress. Therefore, the XML data may not fully conform to a schema when only partially completed.
  3. An XForms client needs to be able to send/receive arbitrary binary content along with the XML data. This will be used to support features such as the "file upload" feature available in many WWW browsers. There needs to be support for both 'in-band' (i.e. the binary data is within the XML data in an XML compatible encoding such as base64) and 'out-of-band' data (i.e. the binary data is available at some other location, and the XML data refers to the other location).

6 Other Requirements

Ed Note: These requirements have been placed here because it was not certain where they fit within the structure of this document. They will be deleted if left unclaimed

What is the fundamental minimum business message that is necessary for business-level exchange? Or, what minimum level of messaging fundamentals are required for best-effort and guaranteed processing? This is a the fundamental difference between component-level RPC and business-level messaging.
message content.
other interaction patterns.

7 Glossary

Need Definition.
Need Definition.
binary data
Need Definition.
Need Definition.
Need Definition.
connection oriented
Need Definition.
Need Definition.
envelope process model
Need Definition.
Need Definition.
Need Definition.
Need Definition.
Need Definition.
Need Definition.
message path
Need Definition.
message pattern
Need Definition.
Need Definition.
non-syntactic data
Need Definition.
Need Definition.
Need Definition.
protocol binding
Need Definition.
Need Definition.
references (uris)
Need Definition.
Need Definition.
Need Definition.
resource and resource manifestation
Need Definition.
rpc convention (programming model)
Need Definition.
Need Definition.
Need Definition.
session oriented
Need Definition.
Need Definition.
Need Definition.
Need Definition.
ultimate receiver
Need Definition.
wire format
Need Definition.

A Acknowledgments

B References

  1. XML Protocol Working Group Charter>