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 defines an encapsulation language that allows for applications to independently introduce extensions and new features. 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.

The Extensible Protocol (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 to 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 to ultimate destinations of an XP envelope.

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,

• extending the message by extension of the XP envelope itself.

To manage the mechanisms, the XP specification must define a set of directives that unambiguously indicate to an XP processor which extensions are optional and which are mandatory so that it can

• process all the extensions in an XP envelope or fail,

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

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

DATA ENCAPSULATION AND EVOLVABILITY 83

The XP specification must define the concept of protocol evolution and define a mech- anism 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.

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 resorting to the use of XP fault messages or without depending on any particular interaction model.

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

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.

With the introduction of XML and RDF schema languages, and the existing capabili- ties 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 prop- agate 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 nonsyntactic 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 rela- tionships 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 URIs. The XML Protocol data representation must be able to encode arrays, which may be nested.

A mechanism for using HTTP transport is needed in the context of an XML Pro- tocol. 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 manda- tory. This component merely addresses the fact that HTTP transport is expected to be widely used.

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.

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.

The XP specification must not mandate any dependency on specific features or mech- anisms 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 unit. This requirement does not preclude a mapping or binding to a transport protocol taking advan- tages of such features. It is intended to ensure that the basic XP specification will be transport neutral.

The XP specification must consider the scenario in which 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 message. The XP specification should not preclude the use of XP messaging over popular security mechanisms.

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 Transmission Control Protocol/Internet Protocol (TCP/IP), User Datagram Protocol (UDP), and Simple Message Transfer Protocol (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.

Given below is the convention for the content of the envelope when used for RPC applications. The protocol aspects of this should be coordinated closely with the IETF.

The XML Protocol contains a convention for representing calls and replies between RPC applications. The conventions include the following:

• Unique specification of the program or object and procedure or method to be called on

the basis of the URI syntax.

• The ability to specify the parameters to a call in a request message and the results of

a call in the reply messages.

• Provisions for specifying errors in a reply message. Where possible, an attempt will be

WIRELESS APPLICATION PROTOCOL (WAP) 85

The RPC conventions within the XML Protocol use the Data Representation model to represent parameters to a call in the request message and results of the call in the reply message. There is straightforward mapping of the data types used in a wide variety of widely deployed programming languages and object systems.

The XML Protocol allows 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 are not 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. The subsections contained within are the same as the subsections of the out-of-scope section of the charter.

Direct handling of binary data

XML name spaces 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 such as Portable Network Graphics (PNG), Joint Photographic Experts Group (JPEG), and so on.

Transport services are extremely important in order to actually deliver packages in an efficient and scalable manner. XML messaging proposals use existing application layer protocols such as SMTP and HTTP. The XML Protocol Working Group focuses on providing a (nonexclusive) mapping to HTTP.

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.