Internet DRAFT - draft-boyd-xttp
draft-boyd-xttp
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 OCTETs making up the field-value
and consisting of either *TEXT or
combinations of token, separators, and
quoted-string>
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
| <entity-body encoded as per
transfer encoding>
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 "<major>.<minor>" 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 <minor> 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 <major> 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 = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
UPALPHA = <any US-ASCII uppercase letter "A".."Z">
LOALPHA = <any US-ASCII lowercase letter "a".."z">
ALPHA = UPALPHA | LOALPHA
DIGIT = <any US-ASCII digit "0".."9">
CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)>
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal-tab (9)>
<"> = <US-ASCII double-quote mark (34)>
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 = <any OCTET except CTLs,
but including LWS>
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*<any CHAR except CTLs or separators>
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 = <any TEXT except <">>
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, <http://www.w3.org/TR/1999/REC-html401-19991224>.
[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,
<http://www.w3.org/TR/2008/REC-xml-20081126>.
[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,
<http://www.w3.org/TR/2000/REC-xhtml1-20000126>.
[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
