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]