Network Working Group J.S. Boyd Internet-Draft Medusa Development Environment Intended status: Experimental November 20, 2014 Expires: April 20, 2015 Extensible Text Transfer Protocol -- XTTP draft-boyd-xttp-00.txt Abstract The Extensible Text Transfer Protocol (XTTP) is intended to be a generalization of the Hypertext Transfer Protocol (HTTP) as the Extensible Markup Language (XML) is a generalization of the HyperText Markup Language (HTML). XTTP would be the basis for the derivation of purpose specific text protocols. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 20, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. This Informational Internet Draft is submitted as an RFC Editor Contribution and/or non-IETF Document (not as a Contribution, IETF Contribution, nor IETF Document) in accordance with BCP 78 and BCP 79. Table of Contents 1. Introduction 1.1 Purpose J.S. Boyd Expires April 20, 2015 [Page 1] Internet-Draft Extensible Text Transfer Protocol -- XTTP November 2014 1.2 Overall Operation 2. XTTP Message 2.1 Message Types 2.2 Message Headers 2.3 Message Body 2.4 Message Length 2.5 General Headers 3. Request 3.1 Request-Line 3.1.1 Method 3.1.2 Request Parameters 3.2 Request Header Fields 4. Response 4.1 Status-Line 4.1.1 Status Code and Reason Phrase 4.2 Response Header Fields 5. Entity 5.1 Entity Header Fields 5.2 Entity Body 6. Protocol Parameters 6.1 XTTP Version 6.2 Content Codings 6.3 Transfer Codings 7. Notational Conventions and Generic Grammar 7.1 Augmented BNF 7.1.1 Basic Rules 8. Acknowledgments 9. IANA Considerations 10. Security Considerations 11. References J.S. Boyd Expires April 20, 2015 [Page 2] Internet-Draft Extensible Text Transfer Protocol -- XTTP November 2014 1. Introduction 1.1 Purpose The Extensible Text Transfer Protocol (XTTP) is intended to be a generalization of HTTP [7] to be used as a baseis for application-level protocols for distributed, collaborative, hypermedia information systems. XTTP differs form HTTP in that it is not a prototcol itself, but a specification for prototcols in it's family. Thus HTTP would be a menber of the XTTP family of protocols. This document is intended to be an overview XTTP not a detailed specification of the protocol family. J.S. Boyd Expires April 20, 2015 [Page 3] Internet-Draft Extensible Text Transfer Protocol -- XTTP November 2014 1.2 Overall Operation Like HTTP [7], the XTTP protocol is a request/response protocol. A client sends a request to the server in the form of a request method, URI, and protocol version, followed by a message containing request modifiers, client information, and possible body content over a connection with a server. The server responds with a status line, including the message's protocol version and a success or error code, followed by a message containing server information, entity metainformation, and possible entity body content. Since XTTP is not a protocol itself, there are no predefined methods or responses in XTTP. The methods and responses are defined by the particular protocol in the XTTP family. Like HTTP [7], most XTTP communication would be initiated by a user agent, and it would consist of a request to be applied to a resource on some origin server. In the simplest case, this may be accomplished via a single connection (v) between the user agent (UA) and the origin server (O). request chain ------------------------> UA -------------------v------------------- O <----------------------- response chain Like HTTP [7], XTTP communication would usually takes place over TCP/IP connections, but unlike HTTP there would be no default port 80 [4]. This does not preclude XTTP from being implemented on top of any other protocol on the Internet, or on other networks. Like HTTP, XTTP only presumes a reliable transport; any protocol that provides such guarantees can be used; the mapping of the XHTTP request and response structures onto the transport data units of the protocol in question is outside the scope of this specification. Like HTTP [7], a XTTP connection may be used for one or more request/response exchanges, although connections may be closed for a variety of reasons (see HTTP [7] "persistent.connections" section). J.S. Boyd Expires April 20, 2015 [Page 4] Internet-Draft Extensible Text Transfer Protocol -- XTTP November 2014 2.1 Message Types Like HTTP [7], XTTP messages would consist of requests from client to server and responses from server to client. XTTP-message = Request | Response Request and Response messages use the generic message format of RFC 822 [2] for transferring entities (the payload of the message). Both types of message consist of a start-line, zero or more header fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields, and possibly a message-body. generic-message = start-line *(message-header CRLF) CRLF [ message-body ] start-line = Request-Line | Status-Line In the interest of robustness, servers should ignore any empty line(s) received where a Request-Line is expected. In other words, if the server is reading the protocol stream at the beginning of a message and receives a CRLF first, it should ignore the CRLF. J.S. Boyd Expires April 20, 2015 [Page 5] Internet-Draft Extensible Text Transfer Protocol -- XTTP November 2014 2.2 Message Headers Unlike HTTP [7], XTTP does not have any predefined request, response or entity header fields, and They all follow the same generic format as that given in Section 3.1 of RFC 822 [2]. Each header field consists of a name followed by a colon (":") and the field value. Unlike HTTP (analougous to XML [9] and HTML [8]), XTTP field names can be case-sensitive. The field value may be preceded by any amount of LWS, though a single SP is preferred. Header fields can be extended over multiple lines by preceding each extra line with at least one SP or HT. Applications ought to follow "common form", where one is known or indicated, when generating HTTP constructs, since there might exist some implementations that fail to accept anything beyond the common forms. message-header = field-name ":" [ field-value ] field-name = token field-value = *( field-content | LWS ) field-content = The field-content does not include any leading or trailing LWS: linear white space occurring before the first non-whitespace character of the field-value or after the last non-whitespace character of the field-value. Such leading or trailing LWS may be removed without changing the semantics of the field value. Any LWS that occurs between field-content may be replaced with a single SP before interpreting the field value or forwarding the message downstream. The order in which header fields with differing field names are received is not significant. However, it is "good practice" to send general-header fields first, followed by request-header or response-header fields, and ending with the entity-header fields. Like HTTP [7], multiple message-header fields with the same field-name may be present in a message. Unlike HTTP, the header field does not need to be defined as a comma-separated list [i.e., #(values)]. It must be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first. Unlike HTTP, each field does not need to be separated by a comma. The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy must not change the order of these field values when a message is forwarded. J.S. Boyd Expires April 20, 2015 [Page 6] Internet-Draft Extensible Text Transfer Protocol -- XTTP November 2014 2.3 Message Body Like HTTP [7], the message-body (if any) of an XTTP message is used to carry the entity-body associated with the request or response. The message-body differs from the entity-body only when a transfer coding has been applied, as indicated by derived protocol. message-body = entity-body | The rules for when a message-body is allowed in a message are defined by a derived protocol requests and responses. 2.4 Message Length The transfer length of a message is the length of the message-body as it appears in the message; that is, after any transfer encodings have been applied. When a message-body is included with a message, the transfer length of that body is determined by one of the following (in order of precedence): Any response message which must not include a message-body (as defined by a derived protocol) is always terminated by the first empty line after the header fields, regardless of the entity-header fields present in the message. If a transfer length header field (as defined by a derived protocol) is present, its value represents transfer length of the message-body. If the message uses a length determined media type (as defined by a derived protocol), and the transfer length is not otherwise specified, then this media type's content defines the transfer length. This media type must not be used unless the sender knows that the recipient can parse it. By the server closing the connection on a response. (Closing the connection cannot be used to indicate the end of a request body, since that would leave no possibility for the server to send back a response.) When a transfer length is given in a message where a message-body is allowed, its field value must exactly match the number of OCTETs in the message-body. XTTP user agents must notify the user when an invalid length is received and detected. 2.5 General Headers Unlike HTTP [7], there are no header fields which have general applicability for both request and response messages, but may be defined by a derived protocol. J.S. Boyd Expires April 20, 2015 [Page 7] Internet-Draft Extensible Text Transfer Protocol -- XTTP November 2014 3. Request A request message from a client to a server includes, within the first line of that message, the method to be applied to the resource, the identifier of the resource, and the protocol version in use. Request = Request-Line ; Section 3.1 *(request-header CRLF) ; Section 3.2 CRLF [ message-body ] ; Section 2.3 3.1 Request-Line Like HTTP [7], the Request-Line begins with a method token. Unlike HTTP, the XTTP method may or may NOT be followed by a request-parameters list (Request-URI in HTTP). Like HTTP, the Request-Line ends with the protocol version and a CRLF. The elements are separated by SP characters. No CR or LF is allowed except in the final CRLF sequence. Request-Line = Method SP [request-parameters SP] XTTP-Version CRLF 3.1.1 Method The Method token indicates the method to be performed using the Request-Parameters. The method is case-sensitive. Unlike HTTP [7], there would not be any predefined methods, and all methods would be extension-methods. Method = extension-method extension-method = token 3.1.2 Request Parameters The request-parameters allow the client to pass information about the request, and about the client itself, to the server. These fields act as request modifiers, with semantics equivalent to unnamed or positional parameters on a programming language method invocation. server.method(value, value, ...); 3.2 Request Header Fields The request-header fields allow the client to pass additional information about the request, and about the client itself, to the server. These fields act as request modifiers, with semantics equivalent to named parameters on a programming language method invocation. server.method(name=value, name=value, ...); Unlike, HTTP [7] XTTP would have no predefined request parameters. Thus, a request-header would be a general-header. request-header = general-header ; Section 2.5 J.S. Boyd Expires April 20, 2015 [Page 8] Internet-Draft Extensible Text Transfer Protocol -- XTTP November 2014 4. Response Like HTTP [7], after receiving and interpreting a request message, an XTTP server responds with an XTTP response message. Response = Status-Line ; Section 4.1 *(response-header CRLF) ; Section 4.2 CRLF [ message-body ] ; Section 5.2 4.1 Status-Line Like HTTP [7], the first line of an XTTP Response message is the Status-Line, consisting of the protocol version followed by a numeric status code and its associated textual phrase, with each element separated by SP characters. No CR or LF is allowed except in the final CRLF sequence. Status-Line = XTTP-Version SP Status-Code SP Reason-Phrase CRLF 4.1.1 Status Code and Reason Phrase Unlike the HTTP [7] Status-Code element which is a 3-digit integer result code of the attempt to understand and satisfy the request, XTTP status codes would not be limited to 3 digits. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata and the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason-Phrase. Like HTTP [7], XTTP status codes would be extensible. XTTP applications would not be required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications must understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x*(0) status code of that class, with the exception that an unrecognized response must NOT be cached. 4.2 Response Header Fields Like HTTP [7], the XTTP response-header fields would allow the server to pass additional information about the response which cannot be placed in the Status-Line. These header fields give information about the server and about further access to the results of the request. Unlike HTTP [7], there would not be just a standard set of predefined response-headers. J.S. Boyd Expires April 20, 2015 [Page 9] Internet-Draft Extensible Text Transfer Protocol -- XTTP November 2014 5. Entity Request and Response messages may transfer an entity if not otherwise restricted by the request method or response defined by a derived protocol. An entity consists of entity-header fields and an entity-body, although some responses will only include the entity-headers. In this section, both sender and recipient refer to either the client or the server, depending on who sends and who receives the entity. 5.1 Entity Header Fields Unlike HTTP [7] XTTP has no predefined entity-header fields used to define metainformation about the entity-body, and they would be defined as message-headers by a derived protocol. entity-header = message-header 5.2 Entity Body If an entity-body is sent with an XHTTP request or response, it is in a format and encoding defined by entity-header fields defined by a derived protocol. entity-body = *OCTET An entity-body is only present in a message when a message-body is present, as described in Section 2.3. The entity-body is obtained from the message-body by decoding any transfer encoding that might have been applied to ensure safe and proper transfer of the message. J.S. Boyd Expires April 20, 2015 [Page 10] Internet-Draft Extensible Text Transfer Protocol -- XTTP November 2014 6. Protocol Parameters 6.1 XTTP Version Like HTTP [7] XTTP uses a "." numbering scheme to indicate versions of the protocol. The protocol versioning policy is intended to allow the sender to indicate the format of a message and its capacity for understanding further XTTP communication, rather than the features obtained via that communication. No change is made to the version number for the addition of message components which do not affect communication behavior or which only add to extensible field values. The number is incremented when the changes made to the protocol add features which do not change the general message parsing algorithm, but which may add to the message semantics and imply additional capabilities of the sender. Like HTTP the number would be incremented when the format of a message within the protocol is changed. See HTTP related RFC 2145 [6] for a fuller explanation. 6.2 Content Codings Unlike HTTP [7], XTTP content coding values would be defined by the derived protocol. Unlike HTTP [7], XTTP content coding values case sensitivity would be defined by the derived protocol. 6.3 Transfer Codings As in HTTP [7] transfer coding values would be used to indicate an encoding transformation that has been, can be, or may need to be applied to an entity-body in order to ensure "safe transport" through the network. This differs from a content coding in that the transfer coding is a property of the message, not of the original entity. Unlike HTTP [7], XTTP transfer coding values case sensitivity would be defined by the derived protocol. J.S. Boyd Expires April 20, 2015 [Page 11] Internet-Draft Extensible Text Transfer Protocol -- XTTP November 2014 7. Notational Conventions and Generic Grammar 7.1 Augmented BNF All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) similar to that used by RFC 822 [2]. Implementors will need to be familiar with the notation in order to understand this specification. The augmented BNF includes the following constructs: 7.1.1 Basic Rules The following rules are used throughout this specification to describe basic parsing constructs. The US-ASCII coded character set is defined by ANSI X3.4-1986 [11]. OCTET = CHAR = UPALPHA = LOALPHA = ALPHA = UPALPHA | LOALPHA DIGIT = CTL = CR = LF = SP = HT = <"> = XHTTP defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body. CRLF = CR LF XTTP header field values can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. All linear white space, including folding, has the same semantics as SP. A recipient may replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream. LWS = [CRLF] 1*( SP | HT ) The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. TEXT = A CRLF is allowed in the definition of TEXT only as part of a header field continuation. It is expected that the folding LWS will be replaced with a single SP before interpretation of the TEXT value. XTTP header field values consist of words separated by LWS or special characters. These special characters must be in a quoted string to be used within a parameter value. token = 1* separators = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT A string of text is parsed as a single word if it is quoted using double-quote marks. quoted-string = ( <"> *(qdtext | quoted-pair ) <"> ) qdtext = > The backslash character ("\") may be used as a single-character quoting mechanism only within quoted-string and comment constructs. quoted-pair = "\" CHAR J.S. Boyd Expires April 20, 2015 [Page 12] Internet-Draft Extensible Text Transfer Protocol -- XTTP November 2014 8. Acknowledgments This specification is was derived from and is a reductuion of the HTTP [7] specification (RFC 2616 [7]). The intent was to make use of the specific HTTP [7] protocol specification to create the generic XTTP specification. 9. IANA Considerations none 10. Security Considerations Since the protocol is a generalization of HTTP, most of the same security considerations apply. See section 15 of RFC 2616 [7]. 11. References 11.1. Normative References [1] Postel, J., Transmission Control Protocol, STD 7, RFC 793, September 1981. [2] Crocker, D.H., Standard for the format of ARPA Internet text messages, STD 11, RFC 822, August 1982. [3] Postel, J., Media Type Registration Procedure, RFC 1590, March 1994. [4] Reynolds, J. and J. Postel, Assigned Numbers, RFC 1700, October 1994. [5] Freed, N. and N.S. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, RFC 2045, November 1996. [6] Mogul, J.C., Fielding, R.T., Gettys, J., and H.F. Nielsen, Use and Interpretation of HTTP Version Numbers, RFC 2145, May 1997. [7] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, Hypertext Transfer Protocol -- HTTP/1.1, RFC 2616, June 1999. [8] Jacobs, I., Hors, A., and D. Raggett, HTML 4.01 Specification, World Wide Web Consortium Recommendation REC-html401-19991224, December 1999, . [9] Paoli, J., Bray, T., Maler, E., Yergeau, F., and C. Sperberg-McQueen, Extensible Markup Language (XML) 1.0 (Fifth Edition), World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, . [10] Pemberton, S., XHTML 1.0: The Extensible HyperText Markup Language - A Reformulation of HTML 4 in XML 1.0, World Wide Web Consortium FirstEdition REC-xhtml1-20000126, January 2000, . [11] American National Standards Institute, Coded Character Set -- 7-bit American Standard Code for Information Interchange, ANSI X3.4, 1986. Author's Address John Boyd Medusa Development Environment 28291 GlenbrookMission Viejo, California 92692 USA Phone: +1-949-241-5939 Fax: EMail: medusade@cox.net J.S. Boyd Expires April 20, 2015 [Page 13] Internet-Draft Extensible Text Transfer Protocol -- XTTP November 2014