XML Protocol Requirements

Abstract

This document describes the XML Protocol Working Group's requirements for the XML Protocol specification.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.

This is the first W3C Working Draft of the XML Protocol (XP) requirements document. It is a chartered deliverable of the XML Protocol Working Group (WG), which is part of the XML Protocol Activity. Although the Working Group agreed to request publication of this document, this document does not necessarily represent consensus within the Working Group about XML Protocol requirements. The previous Working Group draft was the 7 December 2000 revision.

Discussion of this document takes place on the public <[email protected]> mailing list (Archives) per the email communication rules in the XP Working Group Charter.

This is a public W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of all W3C technical reports can be found at http://www.w3.org/TR/.

Table of Contents

1 Notations

2 Relationship to WG Charter

3 Requirements on Requirements

4 Requirements

4.1 General Requirements (5xx)

4.2 Simplicity and Stability (3xx)

4.3 Data Encapsulation and Evolvability (7xx)

4.4 Intermediaries (8xx)

4.5 Data Representation (4xx)

4.6 Protocol Bindings (6xx)

4.7 Convention for RPC (2xx)

5 External Requirements

5.1 XForms Requirements

5.2 P3P Requirements

6 Glossary

6.1 General Protocol Concepts

6.2 Data Encapsulation Concepts

6.3 Message Sender and Receiver Concepts

6.4 Data Representation Concepts

7 Other Terms

8 Use Cases

Appendix

A. Acknowledgements

B. References

1 Notations

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

Each requirement has a three digit number prefixed by either "R" or "DR" indicating the status as follows:

• A "DRnnn" notation indicates a requirement that the WG is actively considering (has not reached rough consensus within the WG)
• An "Rnnn" notation indicates a requirement that the WG is not actively considering at present (has reached rough consensus within the WG)

The document includes several verbatim quotes from the XP WG Charter which provide context for the requirements. The quoted text is emphasized and prefixed with "Charter".

Editorial notes are indicated with yellow background (may not appear in all media) and prefixed with "Ednote".

2 Relationship to WG Charter

The XP WG Charter has two sections describing what is in-scope and what is out-of-scope of the problem space defined for the WG. The WG considers all the requirements in section 4 to be in-scope per the Charter.

Reviewers and readers should be familiar with the XP WG Charter because it provides the critical context for the requirements and any discussion of them.

3 Requirements on Requirements

R900

The XML Protocol Requirements must include usage scenarios that describe how XML Protocol is used in various environments (see section 8). 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.

4 Requirements

4.1 General Requirements

Charter: 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.

R500

The specification will make reasonable efforts to support (but not define) a broad range of programming models suitable for the applications intended for XP.

R501

The specification will make reasonable efforts to support (but not define) a broad range of protocol bindings between communicating peers (see also section 4.6).

R502

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.

R503

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.

R504

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.

R505

The specification must be suitable for use between communicating parties that do not have a priori knowledge of each other.

R506

The specification must focus on the encapsulation and representation of data being transferred between parties capable of generating and/or accepting an XP protocol envelope.

4.2 Simplicity and Stability

Charter: 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.

Charter: 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.

Charter: 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.

R307

XP must be suitable for widespread use across organizational 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 R301, R301a). 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.

R308

Since XP is intended to be a foundation protocol, its definition should remain simple and stable over time. Explicit use of modularity and layering in the resulting design will help assure longevity. Such a framework will allow subsequent extension of the design while leaving the foundation of the design intact. (R300, R302 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.

4.2.1 The XML Protocol Specification Documents

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

The requirements that XP support the use of layering and be modular, extensible, and transport independent imply that there is an architectural design model behind XP. This architecture and the extensibility framework must be explicitly defined (R308 references modularity, R302 and R700 series reference extensibility, R502 and R600 reference transport neutrality).

In this context, layering refers to both XP's support of XP modules (the layer(s) "above") as well as the capability of XP to define services required (the layer(s) "below") for implementation across a variety of underlying protocols

R301

The XML protocol specifications should 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.

R301a

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

4.2.2 The XML Protocol Technologies

R302 (Absorbs old DR's: DR107)

The XML Protocol must support extensibility of vocabulary 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 adapt the user interfaces they provide to human users of the web. A goal of XP is to achieve similar levels of evolvability, extensibility and adaptability for interfaces between web services.

R304

The XML protocol should facilitate the creation of simple applications. Simple applications are often characterized by message exchange patterns such as one-way (or event), and two-way (or synchronous) request response interactions. The specification should make such simple exchange applications as easy as possible to create and to use.

DR305 (Absorbs old DRs: DR003) Ednote: Under consideration. Owner: David Ezell

The XML protocol must provide facilities that encourage a common approach for providing features such as authentication, encryption,payment, reliable delivery, sessions and transactions. Such facilities might include optional standardized header and/or trailer elements. These facilities should encourage "best-practice" in implementing the required features.

R306 (Absorbs old DRs: DR090)

The XML Protocol and applications of the XML Protocol must 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.

DR309 Ednote: Pending proposal. Owner: David Ezell

In cases where the contract between entities is well known, the use of XP as a protocol to fulfill those application contracts should allow processing without requiring a complex XML application infrastructure provided the documents exchanged are well-formed and within the tenets of the XML Infoset.

4.3 Data Encapsulation and Evolvability

Charter: 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:

• They are or can be orthogonal to other extensions.
• They can be deployed automatically and dynamically across the Web with no prior coordination and no central authority.
• The sender can require that the recipient either obeys the semantics defined by an extension or aborts the processing of the message.

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

R701b Requirement for Encapsulation

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 an XP envelope.

R700a Requirement for Extensibility Ednote: Pending change. Owner: Oisin Hurley

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:

• carrying application specific payloads inside the XP envelope,
• referring to application specific payloads outside the XP envelope,
• carrying nested XP envelopes as application specific data within the XP envelope,
• referring to XP envelopes as application specific data outside the XP envelope

Regarding the handling of binary data in particular, the XP WG Charter has the following to say:

Charter: Note that 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.

R700b Requirement for Extensibility

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:

• process all of the extensions in an XP envelope or fail,
• process a subset of the extensions in an XP envelope or fail.

R700c Requirement for Extensibility

In both cases above, the XP processor must fail in a standard and predictable fashion.

R702 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 an XP processor, by simple inspection of an XP envelope, may determine whether or not the envelope is compatible with its processing ability. The specification must define the concepts of backwards compatible and backwards incompatible evolution.

R703a Requirement for Encapsulation of Error 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.

R703b Requirement for Encapsulation of Status

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.

4.4 Intermediaries

Charter: 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).

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

4.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 cannot be addressed from within an XP envelope.

R803

XML Protocol must not preclude the use of transport bindings that define transport intermediary roles such as store-and-forward, proxy and gateway.

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

R811

XML Protocol must define and accommodate processing intermediaries.

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

R806

Targeting - XML Protocol must define mechanisms that allow XP processors, including intermediaries, to identify XP blocks which they are eligible to process.

R808

Reporting - XML Protocol must enable the generation of status and/or error messages by processing intermediaries, and enable propagation and proper identification of status and/or error messages through processing intermediaries.

R802

XML Protocol must also enable processing intermediaries to locate and process XP blocks intended for them without processing the entire message.

4.5 Data Representation

Charter: 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.

Charter: 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.

Charter: 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.

R400

The XML Protocol data encapsulation and data representation mechanisms must be orthogonal.

R401

The XML Protocol data representation must support using XML Schema simple and complex types.

R402

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.

R403

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

R404

The XML Protocol data representation must be able to encode arrays which may be nested.

4.6 Protocol Bindings

Charter: 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.

Charter: 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.

Charter: 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

R600

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

R604

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 to apply many transport or application protocol bindings to the XP message without information loss from the XP message content.

R608

The XML Protocol binding mechanism should not preclude the possibility of constructing bindings to protocols that provide a security mechanism.

Typical examples of such protocols are SSL providing a secure channel,and S/MIME which provides a secure wrapper. It should be possible to specify XP bindings for such security protocols.

R609

The XP specification may mandate the use of a specific character encoding, such as UTF-8, at some point in the future.

The Working Group is aware of the complexity resulting in the use of a large set of character encodings and is actively seeking feedback in this area. Until all the feedback has been evaluated, the Working Group will not make a decision in favor of restriction.

R612

The XP specification must provide a normative description of the default binding of XP to HTTP. This binding, while normative, is not to be exclusive. The binding provided by the Working Group will respect the semantics of HTTP and will demonstrate that it can co-exist with existing HTTP/1.0 and HTTP/1.1 implementations.

4.7 Convention for RPC

Charter: 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

R200

The XML Protocol must contain a convention for representing calls and replies between RPC (Remote Procedure Call) applications and services. The conventions must include the following:

1. Complete and unique identification, by means of URI syntax, of the program, service or object and procedure or method to be called.
2. Enable support for matching response messages to request messages for cases in which matching is not provided by the underlying protocol binding.
3. The ability to specify the parameters to a call in a request message and the results of a call in a reply messages.
4. Provisions for specifying errors in a reply message (see also 703a and 703b)

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

R201

The RPC conventions within the XML Protocol should use the Data Representation model discussed in section 4.5 to represent parameters to a call in the request message and results of the call in the reply message. It must be convenient to create straightforward mappings of the data types to a wide variety of widely deployed programming languages and object systems.

R202

The XML Protocol should allow applications to include custom encodings for data types used for parameters and results in RPC messages.

5. Requirements from other W3C WGs

These are requirements submitted by other W3C Working Groups and Activities.

Ednote: These are the verbatim received texts. The WG has not made any decisions regarding these requirements.

5.1 XForms Requirements

These are the requirements that the XP WG has received from the (W3C Members only) XForms WG:

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.

Requirements:

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

5.2 P3P Requirements

These are the requirements that the XP WG has received from the P3P WG:

• It must be possible to associate a P3P Privacy Policy with an XP message.

6 Glossary

Ednote: This is a glossary of terms expected to be defined and used by the XP specification. Feedback is particularly welcome on this section.

For a description of fundamental Web concepts including resources and resource manifestations, see the "Web Characterization Terminology & Definitions Sheet" W3C Working Draft.

6.1 Protocol Layering Concepts

While the XML Protocol itself is intended to be as simple and lightweight as possible, XML Protocol modules can be designed and composed to perform arbitrarily complex operations allowing the core protocol to remain simple.

The XML Protocol itself can be layered on top of a variety of transfer or application protocols that can help facilitate the transfer of XP Messages. Typical examples of protocols that XML Protocol might be layered on top of are HTTP and TCP. The exact rules and conventions for how to layer the XML Protocol on top of another protocol is defined by an XML Protocol Binding.

Figure 1 XML Protocol Layering

Component oriented implementation models may take advantage of the layering model illustrated above to provide a component oriented interface to components driving specific XP modules. However, this is strictly an implementation choice for which XML Protocol has nothing to say.

application

TBD

protocol

TBD

XML Protocol (XP)

The formal set of conventions governing the format and processing rules of an XP message and basic control of interaction among applications generating and accepting XP messages for the purpose of exchanging information along an XP message path.

XP block

A syntactic construct or structure used to delimit data that logically constitutes a single computational unit as seen by an XP processor.

XP handler

An abstraction for the processing and/or logic required to implement a feature or function typically through the transmission or exchange of XP blocks

XP module

Consists of an XP block and the associated XP handler. Services defined by XP modules can range from generic mechanisms for handling security, caching, routing, and eventing to specific functions like submitting a purchase order.

XP binding

The formal set of rules for carrying an XP message within or on top of another protocol for the purpose of transmission. Typical XP bindings include carrying an XP message within an HTTP message, or on top of TCP.

6.2 Data Encapsulation Concepts

The XML Protocol data encapsulation model describes how XP blocks defined by XP modules can be carried within an XP message which is the fundamental unit of communication in the XML Protocol. The following diagram illustrates how an XP message is composed.

Figure 2 Encapsulation model illustrating the parts of an XP message

An XP message is composed of an XP envelope which contains an XP header and an XP body each of which can contain zero, one or more XP blocks.

XP message

The basic unit of communication within the XML Protocol.

XP processor

An XP Processor processes an XP message according to the formal set of conventions defined by the XML Protocol and generates an XP fault if the conventions are not followed. Insufficient or wrong data carried in an XP block can cause an XP processor to generate a fault (see also XP receiver and XP sender)

XP envelope

The outermost syntactical construct or structure of an XP message defined by XML Protocol within which all other syntactical elements of the message are enclosed.

XP header

A collection or zero or more XP blocks which may be intended for any XP receiver within the XP message path.

XP body

A collection or zero, or more XP blocks intended for the ultimate XP receiver within the XP message path.

XP fault

A special XP block which contains fault information generated by an XP processor.

6.3 Message Sender and Receiver Concepts

The XML Protocol message path model is defined in terms of XP senders and XP receivers who can generate and accept XP messages respectively. Behind each XP receiver is an XP processor that processes the message according to the rules of the XML Protocol.

A important part of the XML Protocol message path model is the concept of XP intermediaries. Intermediaries contain both an XP receiver and an XP sender which allows them to forward a message on behalf of the previous sender.

Figure 3 Illustration of XP message path model

Note: In some interactions, more complicated message path models may be required to encapsulate the semantics of multi-party interactions like for example "fan-out" or "fan-in" models. Such models can be built using the basic XP message path model provided that the semantics of message "split" and "merge" are provided by higher layer semantics.

XP sender

An application that can generate an XP message and perform an XP binding to a specific protocol for the purpose of transmitting the message.

XP receiver

An application that can accept an incoming XP message transmitted using some XP binding, extract the message from the XP binding and pass the message to an XP processor.

XP message path

The set of XP senders and XP receivers through which a single XP message passes. This includes the initial XP sender, zero or more XP intermediaries, and the ultimate XP receiver.

initial XP sender

The XP sender that originates an XP message as the starting point of an XP message path.

XP intermediary

An application that can act as both an XP sender and an XP receiver with the purpose of forwarding an XP message along an XP message path.

ultimate XP receiver

The XP receiver that the initial sender specifies as the final destination of the XP message within an XP message path. An XP message may not reach the ultimate recipient because of an XP fault generated by an XP processor along the XP message path.

The relationship between an XP sender and an XP processor and an XP receiver and an XP processor respectively can be illustrated as follows:

Figure 4 Abstract relationship between XP sender, XP receiver and XP processor

6.4 Data Representation Concepts

XP data model

A set of abstract constructs that can be used to describe common data types and link relationships in data defined by XP modules.

XP data encoding

The syntactic representation of data described by the XP data model within one or more XP blocks in an XP message.

binary data

Data which is represented using a non-XML based, non-human readable syntax

7 Other Terms

Ednote: A list of commonly used terms that are not defined by the WG.

8 Use Cases

Ednote: The XP WG is actively soliciting use cases that can be used to represent the expected range of XML Protocol's use (see section 3). As described in the call for use cases which was sent to the public [email protected] mailing list, use cases should be sent to the [email protected] mailing list for consideration by the XP WG.

Ednote: All of the use cases listed below are under active consideration by the WG. They started out as requirements but were moved to this section when the WG decided they were better described as use cases.

DR805

Routing - in-message dictation of a complete or partial path through processing intermediaries

R807

Tracking - enabling message recipients to determine a message's path through preceding intermediates

DR809

Caching - defining mechanisms to allow intermediates to reuse messages or parts of messages

DR810

Quality of Service - defining required and requested service levels in messages

A Acknowledgments

Ednote: TBD...

The WG thanks all participants of the [email protected] mailing list (archives) for directly and indirectly contributing to this document.

B References

1. XML Protocol Activity
2. XML Protocol Working Group
3. XML Protocol Working Group Charter
4. Proposed Telecom Glossary 2000