HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 00:17:33 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Mon, 01 Feb 1999 21:58:37 GMT ETag: "2e6c93-20e9-36b6238d" Accept-Ranges: bytes Content-Length: 8425 Connection: close Content-Type: text/plain INTERNET-DRAFT Tom Harding Expires: 1 August 1999 ThinLink Solutions 1 February 1999 Extensible Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This memo defines the Extensible Protocol (XP). XP is a generic application-level protocol meant to serve as the foundation for specific protocols, in a manner analogous to the way in which the Extensible Markup Language (XML) recommendation of the World Wide Web Consortium serves as the foundation for specific markup languages. XP is a bidirectional protocol on which XML documents are exchanged between two endpoints. Terminology may Conforming data exchanges are permitted to but need not behave as described. must Conforming data exchanges are required to behave as described; otherwise they are in error, as defined below. error Harding [Page 1] INTERNET-DRAFT Extensible Protocol 1 February 1999 A violation of the rules of this specification; results are undefined. Conforming software may detect and report an error and may recover from it. The notation used in this specification is the same as that used in the XML Recommendation at http://www.w3.org/TR/REC-xml. The following terms are used as in the XML Recommendation: document Eq match Nmtoken processing instruction prolog S well-formed We refer to a protocol conforming to this specification as a derived protocol. Design Goals Two major design goals guide this specification. First, to preserve the utmost flexibility for designers of derived protocols, XP strives to specify as little as possible about the content or structure of the documents exchanged. Second, to maximize the reusability of exiting tools, XP does not introduce into the data streams any content which would not be recognized by an XML processor. Specification XP specifies the data exchanged on a session-layer connection between two endpoints. The session-layer connection will often be a TCP connection. It may also be a degenerate connection built on a connectionless protocol such as UDP. The data on the session-layer connection must be an uninterrupted stream of complete XML documents in each direction. Well-formedness may and should be ensured before data is sent. If anything other than well-formed XML is received, the receiving endpoint must interpret it as a network error and immediately close the session- level connection. All error reporting which involves additional document transmission is left to derived protocols. To extend XML from a class of data objects into a protocol is to Harding [Page 2] INTERNET-DRAFT Extensible Protocol 1 February 1999 extend the rules for constructing a single document into rules for constructing two interrelated streams of documents. Accordingly, we introduce mechanisms for handling both the sequential and interrelated aspects of the document streams. XP introduces three constructs into the document streams. All of these constructs are XML processing instructions. All are optional. Requests Requests, defined as documents not solicited by a request from the opposite endpoint or documents with which responses may be associated, may be sent at any time, by either endpoint. A request processing instruction may appear in the prolog of an XML document. It identifies the document as a request and assigns a request handle by which future responses to the request may be associated with it. For each endpoint, the request handle must be unique among the requests sent from that endpoint during the session- level connection. Request Processing Instruction RequestPI ::= '' Responses Responses are defined as documents associated with a request previously sent by the opposite endpoint. The ResponseTo processing instruction may appear in a document prolog. It identifies the document as a response and provides the request handle of a request, previously sent by the now-receiving endpoint, with which it is associated. ResponseTo Processing Instruction ResponseToPI ::= '' Behavior in the case where an endpoint receives a response whose request handle does not match that of any previously sent request, and indeed in the case where it does match, is not part of this specification. Protocol Considerations Harding [Page 3] INTERNET-DRAFT Extensible Protocol 1 February 1999 An endpoint must determine whether a document is a request or a response based on the first conforming Request or ResponseTo processing instruction that appears in the prolog. A document containing neither a Request nor a ResponseTo processing instruction is a request with no request handle, therefore no responses can be associated with it. This is the only type of document that should be sent when the session-layer connection is degenerate. The possibility that a response could also be a request, which would be treated in a context specific to the original request by the original requesting endpoint, and that more deeply-nested request/response chains could thus be created, is left open. In this case, the ResponseTo processing instruction must precede the Request processing instruction. Terminator Processing Instruction Successive XML documents sent from either side of a session-level connection must be delimited from each other by the XP Terminator, which is an XML processing instruction placed at the end of a document. Terminator Processing Instruction TerminatorPI ::= '' The first octet after a Terminator is the first octet of a new document. Because XML itself defines no document termination mechanism, a document without a Terminator will be the only document sent on a session-level connection. Example The following data exchange conforms to this specification (the arrows show direction of travel and are not data; the order of trasnmission of characters is left-to-right): ------------------------> <----- Applications By specifying only well-formedness and the request/response association and termination mechanisms, the protocol issues of Harding [Page 4] INTERNET-DRAFT Extensible Protocol 1 February 1999 sequencing, validity, and dependency, to name a few, are left up to derived protocols. Many derived protocols might themselves be extensible. Future Directions Formal way of declaring derived protocols Open-source reference implementation Dynamic way of associating request and response document types with application code Obtain assigned port number for XP Author's Address Tom Harding ThinLink Solutions 1267 Lakeside Dr 3079 Sunnyvale, CA 94086 tomh@thinlink.com Expires: 1 August 1999 Harding [Page 5]