XML Protocol Requirements

Draft 25 Oct 2000

R. Alexander Milowski (Lexica, LLC) <alex@milowski.com>
Henrik Frystyk Nielsen (Microsoft) <frystyk@microsoft.com>


This document specifies the 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. This document is the first revision of a non-public draft of the requirements for the XML Protocol specification.

It is a draft requirements document generated from the minutes of the first face-to-face meeting and may be updated, replaced or made obsolete by other documents at any 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
    3.2 Simplicity
    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 Other Requirements
6 Glossary


A Acknowledgments
B References

1 Notations

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

Each draft requirement that was taken at the face-to-face meeting has been grouped under a heading from the charter or an additional section and has been copied verbatim. Any issues appearing under each draft requirement has been extracted from either the text of the draft requirement, the meeting minutes, or the editor's notes (as arranged at the meeting).

2 Requirements on Requirements

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

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

  • DR 001 - Support multiple messaging patterns: One-way, Request-response, Publish-subscribe, Multicast, Perhaps others which need definition based on use cases.

    Issue (i.001.01):

    How do we deal session-oriented communication?

  • DR 005 - We will fully investigate the possibilty of using common XML idioms and tools in the XP architecture.

    Issue (i.005.01):

    What is the definition of "XML idiom"?

    Issue (i.005.02):

    How do we deal session-oriented communication?

  • DR 016 - Support intermittently connected scenarios such as mobile devices.

    Issue (i.016.01):

    This is a specific use case but a very important one. This may need to be reworded.

    Issue (i.016.02):

    Is it a shall not preclude or are we going to provide a mechanism?

  • DR 030 - Requirement for support of multiple message exchange patterns (connection oriented and session oriented, async)

    Issue (i.030.01):

    [We should] reword connection oriented / connection oriented. This should be more explicit and connection with underlying support.

    Issue (i.030.02):

    [This is a] duplicate with exception of connection oriented and session oriented. [We should] reword to only include the latter. What is the use case. Z39.50 is a session oriented protocol. Which one is it (session, connection)? If both then separate things. Add to glossary as well.

  • DR 032 - Requirement that it is lightweight enough (or horizontal) to support many different use cases (small devices, b2b, multiple routing mechanisms, prioritization etc.).

    Issue (i.032.01):

    Do we allow small footprint implementation (subset or not)?

    Issue (i.032.02):

    Example of simple requirement is to enable small foot print implementations. For example through layering [there can be a?] lightweight implementations of XP.

  • DR 044 - It is a requirement that we can deal with PIs but not necessarily all PIs. Problem how this works in intermediaries etc.

    Issue (i.044.01):

    [This is] related to XML schema and other XML parts.

  • DR 047 - Requirement restricted to UTF-8?

    Issue (i.047.01):

    General issue from XML (read XML infoset as background) .

    Issue (i.047.02):

    We have to deal with i18n issues. Does this also tie in to having an infoset for the SOAP? Maybe we should define an abstract data model for the envelope .

  • DR 082 - Must support a variety of messaging patterns:

    • DR 083 - Must support synchronous request-response transactions,

    • DR 084 - Must support asynchronous transactions,

    • DR 085 - Must support multiple recipients/broadcast.

  • DR 086 - Shall not preclude any programming models.

  • DR 087 - Shall not preclude any communications modes between peers.

  • DR 089 - must be usable between communicating parties that do not have a priori knowledge of each other.

  • DR 092 - Must use standard XML tools.

  • DR 093 - Must focus on encapsulating and representing data that is transferred between peers.

3.2 Simplicity

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

  • DR 108 - Simplicity: 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.

    • DR 109 - 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 (see the relationship with other external groups).

  • DR 003 - The architecture will make simple applications easy to build, and provide sufficient power to make more complex ones possible.

    Issue (i.003.01):

    Define "simple application".

    Issue (i.003.02):

    Clarify what type of applications.

  • DR 023 - We should define a protocol using a layered/modular architecture.

    Issue (i.023.01):

    We should provide a representation showing where XP fits in a layered stack model to go along with this.

  • DR 053 - There must be a clear architectural definition of a abstract messaging model upon which everything operates and to which it relates.

  • DR 088 - Must be modular.

  • DR 090 - Must be easy to deploy.

3.3 Data Encapsulation and Evolvability

  • DR 094 - Must be extensible.

    • DR 095 - Must have an encapsulation language for introducing new extensions and features.

    • DR 096 - Must support orthogonal extensions.

    • DR 097 - Must support automatic and dynamic deployment with no prior coordination or central authority.

    • DR 098 - Must support semantics that allow for message abort if extension support is required but not supported.

  • DR 102 - Envelope: An envelope for encapsulating XML data to be transferred in an inter-operable manner that allows for distributed extensibility and evolvability as well as intermediaries.

  • DR 110 - 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:

    • DR 111 - They are or can be orthogonal to other extensions.

    • DR 112 - They can be deployed automatically and dynamically across the Web with no prior coordination and no central authority.

    • DR 113 - The sender can require that the recipient either obeys the semantics defined by an extension or aborts the processing of the message.

  • DR 015 - Must have an architecture to support versioning the protocol, and defined behavior for entities with different versions.

    Issue (i.015.01):

    Clarify this as XP versioning and not application versioning.

  • DR 010 - Support well-defined mechanism for passing status information.

    Issue (i.010.01):

    Is it "passing" or "returning"? Define "status information"--at the envelope level or application level? Is this acknowledgment? "Support" should be "provide".

  • DR 011 - Support well-defined mechanism for passing error information.

    Issue (i.011.01):

    Is it "passing" or "returning"? Define "status information"--at the envelope level or application level? Is this acknowledgment? "Support" should be "provide".

  • DR 012 - Both of the above should be extensible to passing data from higher layers in the stack.

  • DR 035 - Should be able to support adding additional information within a message in a decentralized manner.

  • DR 036 - The message should be able to segregate the message body from associated information which might be contained within headers.

    Issue (i.036.01):

    [Is this a] separation between core of the message and context information about the message? (proposed rewording) - sort out the use of metadata.

    Issue (i.036.02):

    Lots of discussion of what this requirement means. Reformulation: It is a requirement that it is possible to associate data that talks about data in a manner that keeps the data separate from the data that talks about that data. Large discussion on what metadata is. Glossary: add metadata as meant in the charter .

  • DR 038 - There should be a mechanism for extending the envelope. This could for example be done using schema extensibility mechanism.

    Issue (i.038.01):

    How does it relate to versioning? or just plain extensibility?

    Issue (i.038.02):

    There might also be the question of extending the envelope (open content model vs. closed content model for envelope).

  • DR 039 - There has to be a mechanism at the XP layer to identify what version it is and a rich enough mechanism that would indicate what other versions it can handle.

    Issue (i.039.01):

    Duplicate of DR 015 (maybe with the exception of a mechanism to figure out what versions are available).

  • DR 041 - Requirement that envelope is XML and is well-formed and that we have a schema for the envelope.

    Issue (i.041.01):

    Preferred Duplicate.

    Issue (i.041.02):

    ...more specific but consistent with "using xml tools".

  • DR 042 - Requirement that envelope is the unit of communication.

    Issue (i.042.01):

    Different level of abstraction may lead to conventions that put things outside of the envelope. Should we transfer the unit of comm or the unit and potentially linked objects related? [This] should be reworded in protocol unit (and then should the envelope be that unit). This is a discussion point.

    Issue (i.042.02):

    Discussion point: we must clearly define the protocol construct a protocol in such that we have a central control point.

  • DR 043 - There should be a mechanism for supporting applications to extend themselves.

  • DR 045 - Don't want to deal with entity expansions within the envelope.

    Issue (i.045.01):

    entity -> external entity. SOAP disallows DTD hence entities. (i.e.: SOAP uses a subset of XML) entities are slowly subsumed by more web like entities (XLink, even PI's).

    Issue (i.045.02):

    (envelope). [This is] related to XML schema and other XML parts. Discussion issue.

  • Vocabularies

    • DR 054 - Weak: As far as possible, there should be one vocabulary for the concrete XML representation of the envelope containing the metadata and message content.

    • DR 055 - Strong: There will be one vocabulary for the concrete XML representation of the envelope containing the metadata and message content.

  • DR 061 - Must be evolvable.

  • DR 062 - Must be extensible.

  • DR 063 - Must use XML schema datatypes if a schema language is mandatory.

  • DR 074 - Must be able to encapsulate data in an XML-based envelope.

3.4 Intermediaries

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

    • DR 115 - 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 composition both in the vertical (within a peer) as well as in the horizontal (between peers).

  • DR 013 - Support intermediaries (issue : how does this work - routing, etc.?)

    Issue (i.013.01):

    Supporting intermediaries should be separated from the rest of the requirements:

    • "Support intermediaries."

    • "Support routing, etc."

    Issue (i.013.02):

    Define "Intermediaries".

    Issue (i.013.03):

    The use of the term "support" must be defined.

  • DR 014 - Support correctly propagating status/error information involving intermediaries.

    Issue (i.014.01):

    "involving" -> "involving and through".

    Issue (i.014.02):

    Change the use of the term "entity" to something else.

  • DR 020 - Support tracking a message through intermediaries.

  • DR 034 - Should be able to determine what to do with a message without necessarily reading the whole message.

  • DR 037 - Should be able to talk to any intermediary along the message-path.

  • DR 052 - Messages may be sent to a number of parties; either a single party or multiple parties.

  • DR 075 - Must support intermediaries (e.g. proxies).

    • DR 076 - Must support proxies.

    • DR 077 - Must support caches.

    • DR 078 - Must support store-and-forward.

    • DR 079 - Must support gateways.

3.5 Data Representation

  • DR 104 - Data Serialization: A mechanism for serializing data representing non-syntactic data models such as object graphs and directed labeled graphs, based on the data types of XML Schema.

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

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

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

  • DR 009 - Support passing (multiple) XML documents or fragments as data (issues: namespaces, ids, XPointer).

    Issue (i.009.01):

    Is there a standard way to embed XML within XML? This requirement brings the issue of the processing model--essentially about how to get a document in and then out and XP communications.

  • DR 018 - Support data encoding in XML schema.

    Issue (i.018.01):

    Needs discussion on the strength and necessity of the support for XML Schema constructs.

    Issue (i.018.02):

    XP processors must support XML Schema. We need to define what an XP processor is.

  • DR 059 - Shall enable a mechanism to support multiple entities/docs/attachments in request OR Shall specify how a mechanism to support multiple entities/docs/attachments in request.

  • DR 081 - Must be able to represent abstract data models (e.g. graphs).

  • DR 101 - Must be able to serialize data representing non-syntactic data models .

    Issue (i.101.01):

    What does this mean?

3.6 Protocol Bindings

  • DR 105 - 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 002 - 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.

    Issue (i.002.01):

    The list of protocols needs to be defined.

  • DR 007 - Support browser clients.

    Issue (i.007.01):

    Need to expand the requirement to detail the use case and issues. It was also stated that this should be stated as "we shouldn't do anything to preclude and web browser as an XP client." This needs discussion.

  • DR 017 - Support messages where multiple transports along a message path are allowed.

  • DR 021 - XP should be able to run on top of various transport/transfer bindings.

    Issue (i.021.01):

    This is a duplicate.

  • DR 049 - 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 - 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 056 - Enable bindings to be created to multiple protocols, especially http/s (may consider requirements for bindings to smtp tcp file messaging).

  • DR 057 - Shall not preclude binding to protocols other than HTTP.

  • DR 070 - Must be layered on standard Web transport protocols.

    • DR 071 - Must support HTTP .

      • DR 072 - Must support a subset of HTTP that can be effectively generated by a browser.

      • DR 073 - Must support a full HTTP implementation.

  • DR 091 - Must be implementable on existing web servers and browsers.

  • DR 099 - Must support transport of data conforming to a syntactic schema.

    • DR 100 - Does this mean that XP must be able to encapsulate a given XML stream?

      Issue (i.100.01):

      Does this mean that XP must be able to encapsulate a given XML stream?

  • DR 060 - Shall support existing web infrastructure by permitting use of XP by web browsers including intermediaries (depends on your definition of "web infrastructure".

3.7 Convention for RPC

  • DR 103 - RPC Conventions: 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, see below for details.

  • DR 004 - The RPC architecture will support straightforward mappings to a variety of widely deployed programming environments.

  • DR 024 - Verifiable set of rules for RPC interaction

    Issue (i.024.01):

    This requirement addresses interoperability in terms of verification. The use of the term "RPC" caused some disagreement. What is being verified? This needs discussion.

  • DR 026 - There should be more than RPC and we should [include?] them .

    Issue (i.026.01):

    rewording, the intent was that more than RPC should be supported This is a duplicate.

    Issue (i.026.02):

    Duplicate but better wording.

  • DR 064 - Shall not preclude binding messages to programming languages.

  • DR 080 - Must be usable for RPC applications.

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

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

  • DR 008 - 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].

  • DR 040 - 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

  • DR 120 - 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

  • DR 121 - 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 122 - 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 - 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.

  • DR 025 - Is multicast a requirement?

    Issue (i.025.01):

    This is a duplicate.

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

  • DR 028 - Multicast should be supported (not inventing multicast solutions)

    Issue (i.028.01):


4.4 Application Semantics

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

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

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

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

  • DR 027 - There must be a way to deal with audit trails of the protocol flow.

    Issue (i.027.01):

    Dominant duplicate.

  • DR 031 - Requirement for support for routing information to be carried.

    Issue (i.031.01):


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

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

  • DR 051 - A message must have a globally unique identifier.

  • DR 058 - Shall support multiple interaction patterns (e.g. request/response, RPC, point-to-point, publish/subscribe).

  • DR 065 - Must not preclude transaction support, discovery of service definitions and security.

  • DR 069 - Develop an XML-based messaging and remote procedure call system.

4.5 Metadata Descriptions of Services

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

    • DR 127 - 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 Other Requirements


These requirements have been placed here because it was not certain where they fit within the structure of this document.

6 Glossary


Issue (g.001):

Need Definition.


Issue (g.002):

Need Definition.

binary data

Issue (g.003):

Need Definition.


Issue (g.004):

Need Definition.


Issue (g.005):

Need Definition.

connection oriented

Issue (g.006):

Need Definition.


Issue (g.007):

Need Definition.

envelope process model

Issue (g.008):

Need Definition.


Issue (g.009):

Need Definition.


Issue (g.010):

Need Definition.


Issue (g.011):

Need Definition.


Issue (g.012):

Need Definition.


Issue (g.013):

Need Definition.

message path

Issue (g.014):

Need Definition.

message pattern

Issue (g.015):

Need Definition.


Issue (g.016):

Need Definition.

non-syntactic data

Issue (g.017):

Need Definition.


Issue (g.018):

Need Definition.


Issue (g.019):

Need Definition.

protocol binding

Issue (g.020):

Need Definition.


Issue (g.021):

Need Definition.

references (uris)

Issue (g.022):

Need Definition.


Issue (g.023):

Need Definition.


Issue (g.024):

Need Definition.

resource and resource manifestation

Issue (g.025):

Need Definition.

rpc convention (programming model)

Issue (g.026):

Need Definition.


Issue (g.027):

Need Definition.


Issue (g.028):

Need Definition.

session oriented

Issue (g.029):

Need Definition.


Issue (g.030):

Need Definition.


Issue (g.031):

Need Definition.


Issue (g.032):

Need Definition.

ultimate receiver

Issue (g.033):

Need Definition.

wire format

Issue (g.034):

Need Definition.

A Acknowledgments

B References

  1. XML Protocol Working Group Charter