Internet DRAFT - draft-harding-extensible-protocol
draft-harding-extensible-protocol
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
<draft-harding-extensible-protocol-00.txt> 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 ::= '<?xp' S 'Request' Eq Nmtoken '?>'
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 ::= '<?xp' S 'ResponseTo' Eq Nmtoken '?>'
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 ::= '<?xp' S '/?>'
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):
<?xp Request=1?> <GetCPUUsage/> <?xp /?> ------------------------>
<----- <?xp ResponseTo=1?> <SystemStatus CPUUsage="1.2"/> <?xp /?>
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]
