XML Protocol WG DRAFT Requirements

Last Modified: $Date: 2000/11/03 21:40:08 $

Latest revision

http://www.w3.org/2000/xp/Group/xp-reqs

This revision

http://www.w3.org/2000/xp/Group/xp-reqs-01

Previous revision

http://www.w3.org/2000/xp/Group/requirements

Editors:

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

Abstract

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

Status of this Document

This represents the current status of the XML Protocol WG's work on requirements. It does not imply concensus at this point in time. The document will be updated or made obsolete by other documents at a later time. This is work in progress and does not imply endorsement by the W3C membership.

Table of Contents

1 Notations

2 Requirements on Requirements

3 In-Scope Requirements

3.1 General Requirements

3.2 Simplicity and Stability

3.3 Data Encapsulation and Evolvability

3.4 Intermediaries

3.5 Data Representation

3.6 Protocol Bindings

3.7 Convention for RPC

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:

• "DR" means Draft Requirement
• "R" means Requirement
• Italics indicates a term taken directly from the charter .

2 Requirements on Requirements

R900

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.

DR500

The specification will make reasonable efforts to support a broad range programming models suitable for the applications intended for XP.

DR501

The specification developed by the Working Group may not preclude any particular protocol binding between communicating peers.

DR502

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.

DR503

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.

DR504

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.

DR505

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

DR506

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 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 is aim to exploit web philosophy and web design principles to enable widespread distributed computing on the web.

DR307

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* [refs 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.

DR308

XP is a foundation protocol and its definition MUST be stable over time. Express use of modularity and layering in its design will help assure its usability and longevity by enabling subsequent extension within a framework that leaves the foundation 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(s) Documents

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

The requirements that XP be modular, extensible, layered and transport independent (or neutral) [cross refs to those specific requirements] 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.

DR301

The XML protocol specification(s) MUST be clear and easy to understand and testing for conformance must be straightforward. This clarity implies that considerable editorial effort will be required in the structuring of the narrative through both outline/overview and normative reference material.

DR301a

The XP specification MUST clearly identify conformance requirements in a way that enables the conformance of an implementation of the specification to be tested.

3.2.2 The XML Protocol Technology(ies)

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 programmatic interfaces between web service clients and web service providers.

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.

DR304

The XML protocol MUST not preclude the creation of simple applications. Simple applications are those with simple message exchange patterns, either one-way or simple, synchronous, two-way request response interactions. The financial and/or social consequences of a failure ensure the integrity of a message or the complete failure to deliver a message in the context of a simple application is negligible.

DR305 (Absorbs old DRs: DR003)

The XML Protocol SHOULD provide functionality to enable the creation of complex applications. As the financial and/or social 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 conversations (sessions) and transactional semantics also increase. The XML protocol SHOULD provide facilities (possibly optional standardised header and/or trailer elements) to encourage a common approach to the provision of 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 success of XP. The design of the protocol architecture must be sensitive to the practicalities of deployment and to the issue arising in the full spectrum of deployment environments ranging from resource constrained embedded devices (appliances) through to high throughput service engines.

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:

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

DR700 Requirement for Extensibility

The XP specification must define standard mechanisms for extending an XP message. The form of these mechanisms must deal with

• the possibility of extending the message by the addition of payloads outside the independent XP envelope,
• the possibility of extending the message by the addition of XP envelopes within the independent XP envelope,
• the possibility of extending the message by the addition of XP headers within the independent and embedded XP envelopes.

To manage the mechanisms, the XP specification must define a set of directives which will require an XP processor to

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

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

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 specification must also define a mechanism to support the referencing of external payloads which are carried outside the envelope.

DR702 Requirement for Evolution

The XP specification must define the concept of protocol evolution and define a mechanism or mechanisms for establishing and recognizing XP versions. The specification must define the concepts of backwards compatible and backwards incompatible evolution and specify mechanisms and techniques to establish compatibility between XP versions.

DR703 Requirement for Encapsulation of Status Information

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.

DR704 Requirement for Vocabularies

The XP specification must define a list of acceptable syntax elements or vocabulary for the XP envelope and for any defined extension mechanism. The vocabulary may contain optional syntax elements and must be identified using an XML Namespace.

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

DR800

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.

DR803

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:

DR806

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.

DR808

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.

DR802

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;

DR805

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

DR807

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

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.

DR400

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

DR401

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

DR402

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.

DR403

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

DR404

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.

Needs serious editing!!!

• [DR 002, DR 057, DR 070, DR 071, DR 073, DR 105] DR 600 Nothing in the architecture should preclude running over a variety of protocols, including at least standard internet ones such as: HTTP, Asynchronous messaging, TCP, SMTP, message queuing [LIST TBD], 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.
• [DR 006] DR 601 Support uniquely identifying messages as entities, so that correlating related message (such as requests and responses) is possible over any transport.
• [DR 008] DR 602 Support passing arbitrary content from third parties (send digitally signed doc w/o touching data)
• [DR 016] DR 603 Support intermittently connected scenarios such as mobile devices. This is extraordinarily important in the case where TCP is converted to UDP for package transmission as bandwidth permits, such as in the case of CDPD wireless connectivity.
• [DR 017] DR 604 Support messages where multiple transports along a message path are allowed.
• [DR 021, DR 022, DR 121] DR 605 XP should be able to run on top of various transport/transfer bindings Requirement that it should be able to run on top of directly TCP -get a port number (not HTTP on other port). 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.
• [DR 030, DR 056] DR 606 Requirement for support of multiple message exchange patterns (connection oriented and session oriented, async). Enable bindings to be created to multiple protocols, especially http/s (may consider requirements for bindings to smtp tcp file messaging).
• [DR 031] DR 607 Requirement for support for routing information to be carried.
• [DR 046] DR 608 XML protocol should work well with popular security mechanism.
• [DR 047] DR 609 Requirement restricted to UTF-8.
• [DR 049] DR 610 There must be a clear separation of messaging semantics and transport issues or bindings such that the message creator need not know how the message will be delivered to the intended recipient.
• [DR 050] DR 611 URI Tracker Use Case: You request to be notified when a URI changes but you request via HTTP and want to be notified via SMTP
• [DR 072] DR 612 Must support a subset of HTTP that can be effectively generated by a browser
• [DR 105] DR 613 Bindings to Transports: 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. For coordination with the IETF, see below.
• [DR 122] DR 614 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.
• [DR 123] DR 615 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.

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

DR200

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 [1].
2. Provisions for matching response messages to request messages for cases in which matching is not provided by the underlying transport protocol.
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.

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

DR201

The RPC conventions within the XML Protocol will use the Data Representation schemes defined 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.

DR202

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.

DR203

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.