summaryrefslogtreecommitdiffstats
path: root/tests/auto/q3urloperator
diff options
context:
space:
mode:
authoraxis <qt-info@nokia.com>2009-04-24 11:34:15 (GMT)
committeraxis <qt-info@nokia.com>2009-04-24 11:34:15 (GMT)
commit8f427b2b914d5b575a4a7c0ed65d2fb8f45acc76 (patch)
treea17e1a767a89542ab59907462206d7dcf2e504b2 /tests/auto/q3urloperator
downloadQt-8f427b2b914d5b575a4a7c0ed65d2fb8f45acc76.zip
Qt-8f427b2b914d5b575a4a7c0ed65d2fb8f45acc76.tar.gz
Qt-8f427b2b914d5b575a4a7c0ed65d2fb8f45acc76.tar.bz2
Long live Qt for S60!
Diffstat (limited to 'tests/auto/q3urloperator')
-rw-r--r--tests/auto/q3urloperator/.gitattributes3
-rw-r--r--tests/auto/q3urloperator/.gitignore2
-rw-r--r--tests/auto/q3urloperator/copy.res/.gitattributes1
-rw-r--r--tests/auto/q3urloperator/copy.res/rfc3252.txt899
-rwxr-xr-xtests/auto/q3urloperator/listData/executable.exe0
-rw-r--r--tests/auto/q3urloperator/listData/readOnly0
-rwxr-xr-xtests/auto/q3urloperator/listData/readWriteExec.exe0
-rw-r--r--tests/auto/q3urloperator/q3urloperator.pro9
-rw-r--r--tests/auto/q3urloperator/stop/bigfile17980
-rw-r--r--tests/auto/q3urloperator/tst_q3urloperator.cpp783
10 files changed, 19677 insertions, 0 deletions
diff --git a/tests/auto/q3urloperator/.gitattributes b/tests/auto/q3urloperator/.gitattributes
new file mode 100644
index 0000000..132ab08
--- /dev/null
+++ b/tests/auto/q3urloperator/.gitattributes
@@ -0,0 +1,3 @@
+copy.res/* -crlf Unset
+listData/* -crlf Unset
+stop/* -crlf Unset
diff --git a/tests/auto/q3urloperator/.gitignore b/tests/auto/q3urloperator/.gitignore
new file mode 100644
index 0000000..dbe8fd4
--- /dev/null
+++ b/tests/auto/q3urloperator/.gitignore
@@ -0,0 +1,2 @@
+tst_q3urloperator
+rfc3252.txt
diff --git a/tests/auto/q3urloperator/copy.res/.gitattributes b/tests/auto/q3urloperator/copy.res/.gitattributes
new file mode 100644
index 0000000..e04709a
--- /dev/null
+++ b/tests/auto/q3urloperator/copy.res/.gitattributes
@@ -0,0 +1 @@
+rfc3252.txt -crlf
diff --git a/tests/auto/q3urloperator/copy.res/rfc3252.txt b/tests/auto/q3urloperator/copy.res/rfc3252.txt
new file mode 100644
index 0000000..b80c61b
--- /dev/null
+++ b/tests/auto/q3urloperator/copy.res/rfc3252.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group H. Kennedy
+Request for Comments: 3252 Mimezine
+Category: Informational 1 April 2002
+
+
+ Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document defines a reformulation of IP and two transport layer
+ protocols (TCP and UDP) as XML applications.
+
+1. Introduction
+
+1.1. Overview
+
+ This document describes the Binary Lexical Octet Ad-hoc Transport
+ (BLOAT): a reformulation of a widely-deployed network-layer protocol
+ (IP [RFC791]), and two associated transport layer protocols (TCP
+ [RFC793] and UDP [RFC768]) as XML [XML] applications. It also
+ describes methods for transporting BLOAT over Ethernet and IEEE 802
+ networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+ across the public Internet.
+
+1.2. Motivation
+
+ The wild popularity of XML as a basis for application-level protocols
+ such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+ Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+ investigation into the possibility of extending the use of XML in the
+ protocol stack. Using XML at both the transport and network layer in
+ addition to the application layer would provide for an amazing amount
+ of power and flexibility while removing dependencies on proprietary
+ and hard-to-understand binary protocols. This protocol unification
+ would also allow applications to use a single XML parser for all
+ aspects of their operation, eliminating developer time spent figuring
+ out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy Informational [Page 1]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ parsing to the XML toolset. The use of XML also mitigates concerns
+ over "network vs. host" byte ordering which is at the root of many
+ network application bugs.
+
+1.3. Relation to Existing Protocols
+
+ The reformulations specified in this RFC follow as closely as
+ possible the spirit of the RFCs on which they are based, and so MAY
+ contain elements or attributes that would not be needed in a pure
+ reworking (e.g. length attributes, which are implicit in XML.)
+
+ The layering of network and transport protocols are maintained in
+ this RFC despite the optimizations that could be made if the line
+ were somewhat blurred (i.e. merging TCP and IP into a single, larger
+ element in the DTD) in order to foster future use of this protocol as
+ a basis for reformulating other protocols (such as ICMP.)
+
+ Other than the encoding, the behavioral aspects of each of the
+ existing protocols remain unchanged. Routing, address spaces, TCP
+ congestion control, etc. behave as specified in the extant standards.
+ Adapting to new standards and experimental algorithm heuristics for
+ improving performance will become much easier once the move to BLOAT
+ has been completed.
+
+1.4. Requirement Levels
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
+
+2. IPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC.
+ IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+ (section 3.) and higher-level application protocols.
+
+ The DTD for this document type can be found in section 7.1.
+
+ The routing of IPoXML can be easily implemented on hosts with an XML
+ parser, as the regular structure lends itself handily to parsing and
+ validation of the document/datagram and then processing the
+ destination address, TTL, and checksum before sending it on to its
+ next-hop.
+
+ The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+ wider deployment of IPv4 and the fact that implementing IPv6 as XML
+ would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy Informational [Page 2]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+ of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
+ formed and include the XMLDecl.
+
+2.1. IP Description
+
+ A number of items have changed (for the better) from the original IP
+ specification. Bit-masks, where present have been converted into
+ human-readable values. IP addresses are listed in their dotted-
+ decimal notation [RFC1123]. Length and checksum values are present
+ as decimal integers.
+
+ To calculate the length and checksum fields of the IP element, a
+ canonicalized form of the element MUST be used. The canonical form
+ SHALL have no whitespace (including newline characters) between
+ elements and only one space character between attributes. There
+ SHALL NOT be a space following the last attribute in an element.
+
+ An iterative method SHOULD be used to calculate checksums, as the
+ length field will vary based on the size of the checksum.
+
+ The payload element bears special attention. Due to the character
+ set restrictions of XML, the payload of IP datagrams (which MAY
+ contain arbitrary data) MUST be encoded for transport. This RFC
+ REQUIRES the contents of the payload to be encoded in the base-64
+ encoding of RFC 2045 [RFC2045], but removes the requirement that the
+ encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 3]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+2.2. Example Datagram
+
+ The following is an example IPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ <ip>
+ <header length="474">
+ <version value="4"/>
+ <tos precedence="Routine" delay="Normal" throughput="Normal"
+ relibility="Normal" reserved="0"/>
+ <total.length value="461"/>
+ <id value="1"/>
+ <flags reserved="0" df="dont" mf="last"/>
+ <offset value="0"/>
+ <ttl value="255"/>
+ <protocol value="6"/>
+ <checksum value="8707"/>
+ <source address="10.0.0.22"/>
+ <destination address="10.0.0.1"/>
+ <options>
+ <end copied="0" class="0" number="0"/>
+ </options>
+ <padding pad="0"/>
+ </header>
+ <payload>
+ </payload>
+ </ip>
+
+3. TCPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+ A number of items have changed from the original TCP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+ To calculate the length and checksum fields of the TCP element, a
+ canonicalized form of the element MUST be used as in section 2.1.
+
+ An iterative method SHOULD be used to calculate checksums as in
+ section 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy Informational [Page 4]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ The TCP offset element was expanded to a maximum of 255 from 16 to
+ allow for the increased size of the header in XML.
+
+ TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ <tcp>
+ <tcp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <sequence number="322622954"/>
+ <acknowledgement number="689715995"/>
+ <offset number=""/>
+ <reserved value="0"/>
+ <control syn="1" ack="1"/>
+ <window size="1"/>
+ <urgent pointer="0"/>
+ <checksum value="2988"/>
+ <tcp.options>
+ <tcp.end kind="0"/>
+ </tcp.options>
+ <padding pad="0"/>
+ </tcp.header>
+ <payload>
+ </payload>
+ </tcp>
+
+4. UDPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+ A number of items have changed from the original UDP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+
+
+
+
+
+
+Kennedy Informational [Page 5]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ To calculate the length and checksum fields of the UDP element, a
+ canonicalized form of the element MUST be used as in section 2.1. An
+ iterative method SHOULD be used to calculate checksums as in section
+ 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+ UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ <udp>
+ <udp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <udp.length value="143"/>
+ <checksum value="2988"/>
+ </udp.header>
+ <payload>
+ </payload>
+ </udp>
+
+5. Network Transport
+
+ This document provides for the transmission of BLOAT datagrams over
+ two common families of physical layer transport. Future RFCs will
+ address additional transports as routing vendors catch up to the
+ specification, and we begin to see BLOAT routed across the Internet
+ backbone.
+
+5.1. Ethernet
+
+ BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+ exception that the type field of the Ethernet frame MUST contain the
+ value 0xBEEF. The first 5 octets of the Ethernet frame payload will
+ be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+ BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+ that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy Informational [Page 6]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+6. Gatewaying over IP
+
+ In order to facilitate the gradual introduction of BLOAT into the
+ public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+ gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+ The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+ Network DTD (7.1.)
+
+ The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+ [XML]) although it is understood that most IPoXML implementations
+ will not need to pull down the DTD, as it will normally be embedded
+ in the implementation, and presents something of a catch-22 if you
+ need to load part of your network protocol over the network.
+
+7.1. IPoXML DTD
+
+ <!--
+ DTD for IP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ -->
+ <!--
+ DTD data types:
+
+ Digits [0..9]+
+
+ Precedence "NetworkControl | InternetworkControl |
+ CRITIC | FlashOverride | Flash | Immediate |
+ Priority | Routine"
+
+ IP4Addr "dotted-decimal" notation of [RFC1123]
+
+ Class [0..3]
+
+ Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
+ Restricted | Secret | Top Secret | Reserved"
+
+ Compartments [0..65535]
+
+ Handling [0..65535]
+
+ TCC [0..16777216]
+
+ -->
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ENTITY % Digits "CDATA">
+ <!ENTITY % Precedence "CDATA">
+ <!ENTITY % IP4Addr "CDATA">
+ <!ENTITY % Class "CDATA">
+ <!ENTITY % Sec "CDATA">
+ <!ENTITY % Compartments "CDATA">
+ <!ENTITY % Handling "CDATA">
+ <!ENTITY % TCC "CDATA">
+
+ <!ELEMENT ip (header, payload)>
+
+ <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+ protocol, checksum, source, destination, options,
+ padding)>
+ <!-- length of header in 32-bit words -->
+ <!ATTLIST header
+ length %Digits; #REQUIRED>
+
+ <!ELEMENT version EMPTY>
+ <!-- ip version. SHOULD be "4" -->
+ <!ATTLIST version
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT tos EMPTY>
+ <!ATTLIST tos
+ precedence %Precedence; #REQUIRED
+ delay (normal | low) #REQUIRED
+ throughput (normal | high) #REQUIRED
+ relibility (normal | high) #REQUIRED
+ reserved CDATA #FIXED "0">
+
+ <!ELEMENT total.length EMPTY>
+ <!--
+ total length of datagram (header and payload) in octets, MUST be
+ less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+ ethernets).
+ -->
+ <!ATTLIST total.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT id EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST id
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT flags EMPTY>
+ <!-- df = don't fragment, mf = more fragments -->
+ <!ATTLIST flags
+
+
+
+Kennedy Informational [Page 8]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ reserved CDATA #FIXED "0"
+ df (may|dont) #REQUIRED
+ mf (last|more) #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+ <!ATTLIST offset
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT ttl EMPTY>
+ <!-- 0 <= ttl <= 255 -->
+ <!ATTLIST ttl
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT protocol EMPTY>
+ <!-- 0 <= protocol <= 255 (per IANA) -->
+ <!ATTLIST protocol
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT checksum EMPTY>
+ <!-- 0 <= checksum <= 65535 (over header only) -->
+ <!ATTLIST checksum
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT source EMPTY>
+ <!ATTLIST source
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT destination EMPTY>
+ <!ATTLIST destination
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT options ( end | noop | security | loose | strict | record
+ | stream | timestamp )*>
+
+ <!ELEMENT end EMPTY>
+ <!ATTLIST end
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "0">
+
+ <!ELEMENT noop EMPTY>
+ <!ATTLIST noop
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "1">
+
+ <!ELEMENT security EMPTY>
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST security
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "2"
+ length CDATA #FIXED "11"
+ security %Sec; #REQUIRED
+ compartments %Compartments; #REQUIRED
+ handling %Handling; #REQUIRED
+ tcc %TCC; #REQUIRED>
+ <!ELEMENT loose (hop)+>
+ <!ATTLIST loose
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "3"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT hop EMPTY>
+ <!ATTLIST hop
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT strict (hop)+>
+ <!ATTLIST strict
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "9"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT record (hop)+>
+ <!ATTLIST record
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "7"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT stream EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST stream
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "8"
+ length CDATA #FIXED "4"
+ id %Digits; #REQUIRED>
+
+ <!ELEMENT timestamp (tstamp)+>
+ <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST timestamp
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "2"
+ number CDATA #FIXED "4"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED
+ oflw %Digits; #REQUIRED
+ flag (0 | 1 | 3) #REQUIRED>
+
+ <!ELEMENT tstamp EMPTY>
+ <!ATTLIST tstamp
+ time %Digits; #REQUIRED
+ address %IP4Addr; #IMPLIED>
+ <!--
+ padding to bring header to 32-bit boundary.
+ pad MUST be "0"*
+ -->
+ <!ELEMENT padding EMPTY>
+ <!ATTLIST padding
+ pad CDATA #REQUIRED>
+
+ <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+ by section 2.1 of this RFC -->
+ <!ELEMENT payload (CDATA)>
+
+7.2. TCPoXML DTD
+
+ <!--
+ DTD for TCP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ -->
+
+ <!-- the pseudoheader is only included for checksum calculations -->
+ <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+ <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+ reserved, control, window, checksum, urgent,
+ tcp.options, padding)>
+
+ <!ELEMENT src EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+ <!ATTLIST src
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT dest EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST dest
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT sequence EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST sequence
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT acknowledgement EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST acknowledgement
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= number <= 255 -->
+ <!ATTLIST offset
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT reserved EMPTY>
+ <!ATTLIST reserved
+ value CDATA #FIXED "0">
+
+ <!ELEMENT control EMPTY>
+ <!ATTLIST control
+ urg (0|1) #IMPLIED
+ ack (0|1) #IMPLIED
+ psh (0|1) #IMPLIED
+ rst (0|1) #IMPLIED
+ syn (0|1) #IMPLIED
+ fin (0|1) #IMPLIED>
+
+ <!ELEMENT window EMPTY>
+ <!-- 0 <= size <= 65,535 -->
+ <!ATTLIST window
+ size %Digits; #REQUIRED>
+
+ <!--
+ checksum as in ip, but with
+ the following pseudo-header added into the tcp element:
+ -->
+ <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+ tcp.length)>
+
+ <!--
+ tcp header + data length in octets. does not include the size of
+
+ the pseudoheader.
+ -->
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ELEMENT tcp.length EMPTY>
+ <!ATTLIST tcp.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT urgent EMPTY>
+ <!-- 0 <= pointer <= 65,535 -->
+ <!ATTLIST urgent
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+ <!ELEMENT tcp.end EMPTY>
+ <!ATTLIST tcp.end
+ kind CDATA #FIXED "0">
+
+ <!ELEMENT tcp.noop EMPTY>
+ <!ATTLIST tcp.noop
+ kind CDATA #FIXED "1">
+
+ <!ELEMENT tcp.mss EMPTY>
+ <!ATTLIST tcp.mss
+ kind CDATA #FIXED "2"
+ length CDATA #FIXED "4"
+ size %Digits; #REQUIRED>
+
+7.3. UDPoXML DTD
+
+ <!--
+ DTD for UDP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ -->
+
+ <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+ <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+ <!ELEMENT udp.pseudoheader (source, destination, protocol,
+ udp.length)>
+
+ <!--
+ udp header + data length in octets. does not include the size of
+ the pseudoheader.
+ -->
+ <!ELEMENT udp.length EMPTY>
+ <!ATTLIST udp.length
+ value %Digits; #REQUIRED>
+
+
+
+Kennedy Informational [Page 13]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+8. Security Considerations
+
+ XML, as a subset of SGML, has the same security considerations as
+ specified in SGML Media Types [RFC1874]. Security considerations
+ that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+ not attempt to correct for issues not related to message format.
+
+9. References
+
+ [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
+ February 2002. (Work in Progress)
+
+ [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
+ 793, September 1981.
+
+ [RFC894] Hornig, C., "Standard for the Transmission of IP
+ Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+ [RFC1042] Postel, J. and J. Reynolds, "Standard for the
+ Transmission of IP Datagrams Over IEEE 802 Networks", STD
+ 43, RFC 1042, February 1988.
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts -
+ Application and Support", RFC 1123, October 1989.
+
+ [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
+ 1995.
+
+ [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
+ October 1996.
+
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy Informational [Page 14]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
+ RFC 3080, March 2001.
+
+ [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+ Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+ "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+ Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+ Markup Language (XML)" World Wide Web Consortium
+ Recommendation REC- xml-19980210.
+ http://www.w3.org/TR/1998/REC-xml-19980210
+
+10. Author's Address
+
+ Hugh Kennedy
+ Mimezine
+ 1060 West Addison
+ Chicago, IL 60613
+ USA
+
+ EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 15]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 16]
+
diff --git a/tests/auto/q3urloperator/listData/executable.exe b/tests/auto/q3urloperator/listData/executable.exe
new file mode 100755
index 0000000..e69de29
--- /dev/null
+++ b/tests/auto/q3urloperator/listData/executable.exe
diff --git a/tests/auto/q3urloperator/listData/readOnly b/tests/auto/q3urloperator/listData/readOnly
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/tests/auto/q3urloperator/listData/readOnly
diff --git a/tests/auto/q3urloperator/listData/readWriteExec.exe b/tests/auto/q3urloperator/listData/readWriteExec.exe
new file mode 100755
index 0000000..e69de29
--- /dev/null
+++ b/tests/auto/q3urloperator/listData/readWriteExec.exe
diff --git a/tests/auto/q3urloperator/q3urloperator.pro b/tests/auto/q3urloperator/q3urloperator.pro
new file mode 100644
index 0000000..3364dac
--- /dev/null
+++ b/tests/auto/q3urloperator/q3urloperator.pro
@@ -0,0 +1,9 @@
+load(qttest_p4)
+SOURCES += tst_q3urloperator.cpp
+
+
+contains(QT_CONFIG, qt3support): QT += qt3support
+QT += network
+
+
+
diff --git a/tests/auto/q3urloperator/stop/bigfile b/tests/auto/q3urloperator/stop/bigfile
new file mode 100644
index 0000000..cb114a2
--- /dev/null
+++ b/tests/auto/q3urloperator/stop/bigfile
@@ -0,0 +1,17980 @@
+
+
+
+
+
+
+Network Working Group H. Kennedy
+Request for Comments: 3252 Mimezine
+Category: Informational 1 April 2002
+
+
+ Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document defines a reformulation of IP and two transport layer
+ protocols (TCP and UDP) as XML applications.
+
+1. Introduction
+
+1.1. Overview
+
+ This document describes the Binary Lexical Octet Ad-hoc Transport
+ (BLOAT): a reformulation of a widely-deployed network-layer protocol
+ (IP [RFC791]), and two associated transport layer protocols (TCP
+ [RFC793] and UDP [RFC768]) as XML [XML] applications. It also
+ describes methods for transporting BLOAT over Ethernet and IEEE 802
+ networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+ across the public Internet.
+
+1.2. Motivation
+
+ The wild popularity of XML as a basis for application-level protocols
+ such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+ Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+ investigation into the possibility of extending the use of XML in the
+ protocol stack. Using XML at both the transport and network layer in
+ addition to the application layer would provide for an amazing amount
+ of power and flexibility while removing dependencies on proprietary
+ and hard-to-understand binary protocols. This protocol unification
+ would also allow applications to use a single XML parser for all
+ aspects of their operation, eliminating developer time spent figuring
+ out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy Informational [Page 1]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ parsing to the XML toolset. The use of XML also mitigates concerns
+ over "network vs. host" byte ordering which is at the root of many
+ network application bugs.
+
+1.3. Relation to Existing Protocols
+
+ The reformulations specified in this RFC follow as closely as
+ possible the spirit of the RFCs on which they are based, and so MAY
+ contain elements or attributes that would not be needed in a pure
+ reworking (e.g. length attributes, which are implicit in XML.)
+
+ The layering of network and transport protocols are maintained in
+ this RFC despite the optimizations that could be made if the line
+ were somewhat blurred (i.e. merging TCP and IP into a single, larger
+ element in the DTD) in order to foster future use of this protocol as
+ a basis for reformulating other protocols (such as ICMP.)
+
+ Other than the encoding, the behavioral aspects of each of the
+ existing protocols remain unchanged. Routing, address spaces, TCP
+ congestion control, etc. behave as specified in the extant standards.
+ Adapting to new standards and experimental algorithm heuristics for
+ improving performance will become much easier once the move to BLOAT
+ has been completed.
+
+1.4. Requirement Levels
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
+
+2. IPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC.
+ IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+ (section 3.) and higher-level application protocols.
+
+ The DTD for this document type can be found in section 7.1.
+
+ The routing of IPoXML can be easily implemented on hosts with an XML
+ parser, as the regular structure lends itself handily to parsing and
+ validation of the document/datagram and then processing the
+ destination address, TTL, and checksum before sending it on to its
+ next-hop.
+
+ The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+ wider deployment of IPv4 and the fact that implementing IPv6 as XML
+ would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy Informational [Page 2]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+ of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
+ formed and include the XMLDecl.
+
+2.1. IP Description
+
+ A number of items have changed (for the better) from the original IP
+ specification. Bit-masks, where present have been converted into
+ human-readable values. IP addresses are listed in their dotted-
+ decimal notation [RFC1123]. Length and checksum values are present
+ as decimal integers.
+
+ To calculate the length and checksum fields of the IP element, a
+ canonicalized form of the element MUST be used. The canonical form
+ SHALL have no whitespace (including newline characters) between
+ elements and only one space character between attributes. There
+ SHALL NOT be a space following the last attribute in an element.
+
+ An iterative method SHOULD be used to calculate checksums, as the
+ length field will vary based on the size of the checksum.
+
+ The payload element bears special attention. Due to the character
+ set restrictions of XML, the payload of IP datagrams (which MAY
+ contain arbitrary data) MUST be encoded for transport. This RFC
+ REQUIRES the contents of the payload to be encoded in the base-64
+ encoding of RFC 2045 [RFC2045], but removes the requirement that the
+ encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 3]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+2.2. Example Datagram
+
+ The following is an example IPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ <ip>
+ <header length="474">
+ <version value="4"/>
+ <tos precedence="Routine" delay="Normal" throughput="Normal"
+ relibility="Normal" reserved="0"/>
+ <total.length value="461"/>
+ <id value="1"/>
+ <flags reserved="0" df="dont" mf="last"/>
+ <offset value="0"/>
+ <ttl value="255"/>
+ <protocol value="6"/>
+ <checksum value="8707"/>
+ <source address="10.0.0.22"/>
+ <destination address="10.0.0.1"/>
+ <options>
+ <end copied="0" class="0" number="0"/>
+ </options>
+ <padding pad="0"/>
+ </header>
+ <payload>
+ </payload>
+ </ip>
+
+3. TCPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+ A number of items have changed from the original TCP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+ To calculate the length and checksum fields of the TCP element, a
+ canonicalized form of the element MUST be used as in section 2.1.
+
+ An iterative method SHOULD be used to calculate checksums as in
+ section 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy Informational [Page 4]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ The TCP offset element was expanded to a maximum of 255 from 16 to
+ allow for the increased size of the header in XML.
+
+ TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ <tcp>
+ <tcp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <sequence number="322622954"/>
+ <acknowledgement number="689715995"/>
+ <offset number=""/>
+ <reserved value="0"/>
+ <control syn="1" ack="1"/>
+ <window size="1"/>
+ <urgent pointer="0"/>
+ <checksum value="2988"/>
+ <tcp.options>
+ <tcp.end kind="0"/>
+ </tcp.options>
+ <padding pad="0"/>
+ </tcp.header>
+ <payload>
+ </payload>
+ </tcp>
+
+4. UDPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+ A number of items have changed from the original UDP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+
+
+
+
+
+
+Kennedy Informational [Page 5]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ To calculate the length and checksum fields of the UDP element, a
+ canonicalized form of the element MUST be used as in section 2.1. An
+ iterative method SHOULD be used to calculate checksums as in section
+ 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+ UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ <udp>
+ <udp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <udp.length value="143"/>
+ <checksum value="2988"/>
+ </udp.header>
+ <payload>
+ </payload>
+ </udp>
+
+5. Network Transport
+
+ This document provides for the transmission of BLOAT datagrams over
+ two common families of physical layer transport. Future RFCs will
+ address additional transports as routing vendors catch up to the
+ specification, and we begin to see BLOAT routed across the Internet
+ backbone.
+
+5.1. Ethernet
+
+ BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+ exception that the type field of the Ethernet frame MUST contain the
+ value 0xBEEF. The first 5 octets of the Ethernet frame payload will
+ be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+ BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+ that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy Informational [Page 6]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+6. Gatewaying over IP
+
+ In order to facilitate the gradual introduction of BLOAT into the
+ public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+ gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+ The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+ Network DTD (7.1.)
+
+ The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+ [XML]) although it is understood that most IPoXML implementations
+ will not need to pull down the DTD, as it will normally be embedded
+ in the implementation, and presents something of a catch-22 if you
+ need to load part of your network protocol over the network.
+
+7.1. IPoXML DTD
+
+ <!--
+ DTD for IP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ -->
+ <!--
+ DTD data types:
+
+ Digits [0..9]+
+
+ Precedence "NetworkControl | InternetworkControl |
+ CRITIC | FlashOverride | Flash | Immediate |
+ Priority | Routine"
+
+ IP4Addr "dotted-decimal" notation of [RFC1123]
+
+ Class [0..3]
+
+ Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
+ Restricted | Secret | Top Secret | Reserved"
+
+ Compartments [0..65535]
+
+ Handling [0..65535]
+
+ TCC [0..16777216]
+
+ -->
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ENTITY % Digits "CDATA">
+ <!ENTITY % Precedence "CDATA">
+ <!ENTITY % IP4Addr "CDATA">
+ <!ENTITY % Class "CDATA">
+ <!ENTITY % Sec "CDATA">
+ <!ENTITY % Compartments "CDATA">
+ <!ENTITY % Handling "CDATA">
+ <!ENTITY % TCC "CDATA">
+
+ <!ELEMENT ip (header, payload)>
+
+ <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+ protocol, checksum, source, destination, options,
+ padding)>
+ <!-- length of header in 32-bit words -->
+ <!ATTLIST header
+ length %Digits; #REQUIRED>
+
+ <!ELEMENT version EMPTY>
+ <!-- ip version. SHOULD be "4" -->
+ <!ATTLIST version
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT tos EMPTY>
+ <!ATTLIST tos
+ precedence %Precedence; #REQUIRED
+ delay (normal | low) #REQUIRED
+ throughput (normal | high) #REQUIRED
+ relibility (normal | high) #REQUIRED
+ reserved CDATA #FIXED "0">
+
+ <!ELEMENT total.length EMPTY>
+ <!--
+ total length of datagram (header and payload) in octets, MUST be
+ less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+ ethernets).
+ -->
+ <!ATTLIST total.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT id EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST id
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT flags EMPTY>
+ <!-- df = don't fragment, mf = more fragments -->
+ <!ATTLIST flags
+
+
+
+Kennedy Informational [Page 8]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ reserved CDATA #FIXED "0"
+ df (may|dont) #REQUIRED
+ mf (last|more) #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+ <!ATTLIST offset
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT ttl EMPTY>
+ <!-- 0 <= ttl <= 255 -->
+ <!ATTLIST ttl
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT protocol EMPTY>
+ <!-- 0 <= protocol <= 255 (per IANA) -->
+ <!ATTLIST protocol
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT checksum EMPTY>
+ <!-- 0 <= checksum <= 65535 (over header only) -->
+ <!ATTLIST checksum
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT source EMPTY>
+ <!ATTLIST source
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT destination EMPTY>
+ <!ATTLIST destination
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT options ( end | noop | security | loose | strict | record
+ | stream | timestamp )*>
+
+ <!ELEMENT end EMPTY>
+ <!ATTLIST end
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "0">
+
+ <!ELEMENT noop EMPTY>
+ <!ATTLIST noop
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "1">
+
+ <!ELEMENT security EMPTY>
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST security
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "2"
+ length CDATA #FIXED "11"
+ security %Sec; #REQUIRED
+ compartments %Compartments; #REQUIRED
+ handling %Handling; #REQUIRED
+ tcc %TCC; #REQUIRED>
+ <!ELEMENT loose (hop)+>
+ <!ATTLIST loose
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "3"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT hop EMPTY>
+ <!ATTLIST hop
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT strict (hop)+>
+ <!ATTLIST strict
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "9"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT record (hop)+>
+ <!ATTLIST record
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "7"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT stream EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST stream
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "8"
+ length CDATA #FIXED "4"
+ id %Digits; #REQUIRED>
+
+ <!ELEMENT timestamp (tstamp)+>
+ <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST timestamp
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "2"
+ number CDATA #FIXED "4"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED
+ oflw %Digits; #REQUIRED
+ flag (0 | 1 | 3) #REQUIRED>
+
+ <!ELEMENT tstamp EMPTY>
+ <!ATTLIST tstamp
+ time %Digits; #REQUIRED
+ address %IP4Addr; #IMPLIED>
+ <!--
+ padding to bring header to 32-bit boundary.
+ pad MUST be "0"*
+ -->
+ <!ELEMENT padding EMPTY>
+ <!ATTLIST padding
+ pad CDATA #REQUIRED>
+
+ <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+ by section 2.1 of this RFC -->
+ <!ELEMENT payload (CDATA)>
+
+7.2. TCPoXML DTD
+
+ <!--
+ DTD for TCP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ -->
+
+ <!-- the pseudoheader is only included for checksum calculations -->
+ <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+ <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+ reserved, control, window, checksum, urgent,
+ tcp.options, padding)>
+
+ <!ELEMENT src EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+ <!ATTLIST src
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT dest EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST dest
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT sequence EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST sequence
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT acknowledgement EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST acknowledgement
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= number <= 255 -->
+ <!ATTLIST offset
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT reserved EMPTY>
+ <!ATTLIST reserved
+ value CDATA #FIXED "0">
+
+ <!ELEMENT control EMPTY>
+ <!ATTLIST control
+ urg (0|1) #IMPLIED
+ ack (0|1) #IMPLIED
+ psh (0|1) #IMPLIED
+ rst (0|1) #IMPLIED
+ syn (0|1) #IMPLIED
+ fin (0|1) #IMPLIED>
+
+ <!ELEMENT window EMPTY>
+ <!-- 0 <= size <= 65,535 -->
+ <!ATTLIST window
+ size %Digits; #REQUIRED>
+
+ <!--
+ checksum as in ip, but with
+ the following pseudo-header added into the tcp element:
+ -->
+ <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+ tcp.length)>
+
+ <!--
+ tcp header + data length in octets. does not include the size of
+
+ the pseudoheader.
+ -->
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ELEMENT tcp.length EMPTY>
+ <!ATTLIST tcp.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT urgent EMPTY>
+ <!-- 0 <= pointer <= 65,535 -->
+ <!ATTLIST urgent
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+ <!ELEMENT tcp.end EMPTY>
+ <!ATTLIST tcp.end
+ kind CDATA #FIXED "0">
+
+ <!ELEMENT tcp.noop EMPTY>
+ <!ATTLIST tcp.noop
+ kind CDATA #FIXED "1">
+
+ <!ELEMENT tcp.mss EMPTY>
+ <!ATTLIST tcp.mss
+ kind CDATA #FIXED "2"
+ length CDATA #FIXED "4"
+ size %Digits; #REQUIRED>
+
+7.3. UDPoXML DTD
+
+ <!--
+ DTD for UDP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ -->
+
+ <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+ <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+ <!ELEMENT udp.pseudoheader (source, destination, protocol,
+ udp.length)>
+
+ <!--
+ udp header + data length in octets. does not include the size of
+ the pseudoheader.
+ -->
+ <!ELEMENT udp.length EMPTY>
+ <!ATTLIST udp.length
+ value %Digits; #REQUIRED>
+
+
+
+Kennedy Informational [Page 13]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+8. Security Considerations
+
+ XML, as a subset of SGML, has the same security considerations as
+ specified in SGML Media Types [RFC1874]. Security considerations
+ that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+ not attempt to correct for issues not related to message format.
+
+9. References
+
+ [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
+ February 2002. (Work in Progress)
+
+ [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
+ 793, September 1981.
+
+ [RFC894] Hornig, C., "Standard for the Transmission of IP
+ Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+ [RFC1042] Postel, J. and J. Reynolds, "Standard for the
+ Transmission of IP Datagrams Over IEEE 802 Networks", STD
+ 43, RFC 1042, February 1988.
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts -
+ Application and Support", RFC 1123, October 1989.
+
+ [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
+ 1995.
+
+ [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
+ October 1996.
+
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy Informational [Page 14]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
+ RFC 3080, March 2001.
+
+ [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+ Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+ "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+ Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+ Markup Language (XML)" World Wide Web Consortium
+ Recommendation REC- xml-19980210.
+ http://www.w3.org/TR/1998/REC-xml-19980210
+
+10. Author's Address
+
+ Hugh Kennedy
+ Mimezine
+ 1060 West Addison
+ Chicago, IL 60613
+ USA
+
+ EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 15]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 16]
+
+
+
+
+
+
+
+Network Working Group H. Kennedy
+Request for Comments: 3252 Mimezine
+Category: Informational 1 April 2002
+
+
+ Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document defines a reformulation of IP and two transport layer
+ protocols (TCP and UDP) as XML applications.
+
+1. Introduction
+
+1.1. Overview
+
+ This document describes the Binary Lexical Octet Ad-hoc Transport
+ (BLOAT): a reformulation of a widely-deployed network-layer protocol
+ (IP [RFC791]), and two associated transport layer protocols (TCP
+ [RFC793] and UDP [RFC768]) as XML [XML] applications. It also
+ describes methods for transporting BLOAT over Ethernet and IEEE 802
+ networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+ across the public Internet.
+
+1.2. Motivation
+
+ The wild popularity of XML as a basis for application-level protocols
+ such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+ Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+ investigation into the possibility of extending the use of XML in the
+ protocol stack. Using XML at both the transport and network layer in
+ addition to the application layer would provide for an amazing amount
+ of power and flexibility while removing dependencies on proprietary
+ and hard-to-understand binary protocols. This protocol unification
+ would also allow applications to use a single XML parser for all
+ aspects of their operation, eliminating developer time spent figuring
+ out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy Informational [Page 1]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ parsing to the XML toolset. The use of XML also mitigates concerns
+ over "network vs. host" byte ordering which is at the root of many
+ network application bugs.
+
+1.3. Relation to Existing Protocols
+
+ The reformulations specified in this RFC follow as closely as
+ possible the spirit of the RFCs on which they are based, and so MAY
+ contain elements or attributes that would not be needed in a pure
+ reworking (e.g. length attributes, which are implicit in XML.)
+
+ The layering of network and transport protocols are maintained in
+ this RFC despite the optimizations that could be made if the line
+ were somewhat blurred (i.e. merging TCP and IP into a single, larger
+ element in the DTD) in order to foster future use of this protocol as
+ a basis for reformulating other protocols (such as ICMP.)
+
+ Other than the encoding, the behavioral aspects of each of the
+ existing protocols remain unchanged. Routing, address spaces, TCP
+ congestion control, etc. behave as specified in the extant standards.
+ Adapting to new standards and experimental algorithm heuristics for
+ improving performance will become much easier once the move to BLOAT
+ has been completed.
+
+1.4. Requirement Levels
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
+
+2. IPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC.
+ IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+ (section 3.) and higher-level application protocols.
+
+ The DTD for this document type can be found in section 7.1.
+
+ The routing of IPoXML can be easily implemented on hosts with an XML
+ parser, as the regular structure lends itself handily to parsing and
+ validation of the document/datagram and then processing the
+ destination address, TTL, and checksum before sending it on to its
+ next-hop.
+
+ The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+ wider deployment of IPv4 and the fact that implementing IPv6 as XML
+ would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy Informational [Page 2]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+ of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
+ formed and include the XMLDecl.
+
+2.1. IP Description
+
+ A number of items have changed (for the better) from the original IP
+ specification. Bit-masks, where present have been converted into
+ human-readable values. IP addresses are listed in their dotted-
+ decimal notation [RFC1123]. Length and checksum values are present
+ as decimal integers.
+
+ To calculate the length and checksum fields of the IP element, a
+ canonicalized form of the element MUST be used. The canonical form
+ SHALL have no whitespace (including newline characters) between
+ elements and only one space character between attributes. There
+ SHALL NOT be a space following the last attribute in an element.
+
+ An iterative method SHOULD be used to calculate checksums, as the
+ length field will vary based on the size of the checksum.
+
+ The payload element bears special attention. Due to the character
+ set restrictions of XML, the payload of IP datagrams (which MAY
+ contain arbitrary data) MUST be encoded for transport. This RFC
+ REQUIRES the contents of the payload to be encoded in the base-64
+ encoding of RFC 2045 [RFC2045], but removes the requirement that the
+ encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 3]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+2.2. Example Datagram
+
+ The following is an example IPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ <ip>
+ <header length="474">
+ <version value="4"/>
+ <tos precedence="Routine" delay="Normal" throughput="Normal"
+ relibility="Normal" reserved="0"/>
+ <total.length value="461"/>
+ <id value="1"/>
+ <flags reserved="0" df="dont" mf="last"/>
+ <offset value="0"/>
+ <ttl value="255"/>
+ <protocol value="6"/>
+ <checksum value="8707"/>
+ <source address="10.0.0.22"/>
+ <destination address="10.0.0.1"/>
+ <options>
+ <end copied="0" class="0" number="0"/>
+ </options>
+ <padding pad="0"/>
+ </header>
+ <payload>
+ </payload>
+ </ip>
+
+3. TCPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+ A number of items have changed from the original TCP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+ To calculate the length and checksum fields of the TCP element, a
+ canonicalized form of the element MUST be used as in section 2.1.
+
+ An iterative method SHOULD be used to calculate checksums as in
+ section 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy Informational [Page 4]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ The TCP offset element was expanded to a maximum of 255 from 16 to
+ allow for the increased size of the header in XML.
+
+ TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ <tcp>
+ <tcp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <sequence number="322622954"/>
+ <acknowledgement number="689715995"/>
+ <offset number=""/>
+ <reserved value="0"/>
+ <control syn="1" ack="1"/>
+ <window size="1"/>
+ <urgent pointer="0"/>
+ <checksum value="2988"/>
+ <tcp.options>
+ <tcp.end kind="0"/>
+ </tcp.options>
+ <padding pad="0"/>
+ </tcp.header>
+ <payload>
+ </payload>
+ </tcp>
+
+4. UDPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+ A number of items have changed from the original UDP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+
+
+
+
+
+
+Kennedy Informational [Page 5]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ To calculate the length and checksum fields of the UDP element, a
+ canonicalized form of the element MUST be used as in section 2.1. An
+ iterative method SHOULD be used to calculate checksums as in section
+ 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+ UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ <udp>
+ <udp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <udp.length value="143"/>
+ <checksum value="2988"/>
+ </udp.header>
+ <payload>
+ </payload>
+ </udp>
+
+5. Network Transport
+
+ This document provides for the transmission of BLOAT datagrams over
+ two common families of physical layer transport. Future RFCs will
+ address additional transports as routing vendors catch up to the
+ specification, and we begin to see BLOAT routed across the Internet
+ backbone.
+
+5.1. Ethernet
+
+ BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+ exception that the type field of the Ethernet frame MUST contain the
+ value 0xBEEF. The first 5 octets of the Ethernet frame payload will
+ be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+ BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+ that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy Informational [Page 6]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+6. Gatewaying over IP
+
+ In order to facilitate the gradual introduction of BLOAT into the
+ public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+ gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+ The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+ Network DTD (7.1.)
+
+ The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+ [XML]) although it is understood that most IPoXML implementations
+ will not need to pull down the DTD, as it will normally be embedded
+ in the implementation, and presents something of a catch-22 if you
+ need to load part of your network protocol over the network.
+
+7.1. IPoXML DTD
+
+ <!--
+ DTD for IP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ -->
+ <!--
+ DTD data types:
+
+ Digits [0..9]+
+
+ Precedence "NetworkControl | InternetworkControl |
+ CRITIC | FlashOverride | Flash | Immediate |
+ Priority | Routine"
+
+ IP4Addr "dotted-decimal" notation of [RFC1123]
+
+ Class [0..3]
+
+ Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
+ Restricted | Secret | Top Secret | Reserved"
+
+ Compartments [0..65535]
+
+ Handling [0..65535]
+
+ TCC [0..16777216]
+
+ -->
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ENTITY % Digits "CDATA">
+ <!ENTITY % Precedence "CDATA">
+ <!ENTITY % IP4Addr "CDATA">
+ <!ENTITY % Class "CDATA">
+ <!ENTITY % Sec "CDATA">
+ <!ENTITY % Compartments "CDATA">
+ <!ENTITY % Handling "CDATA">
+ <!ENTITY % TCC "CDATA">
+
+ <!ELEMENT ip (header, payload)>
+
+ <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+ protocol, checksum, source, destination, options,
+ padding)>
+ <!-- length of header in 32-bit words -->
+ <!ATTLIST header
+ length %Digits; #REQUIRED>
+
+ <!ELEMENT version EMPTY>
+ <!-- ip version. SHOULD be "4" -->
+ <!ATTLIST version
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT tos EMPTY>
+ <!ATTLIST tos
+ precedence %Precedence; #REQUIRED
+ delay (normal | low) #REQUIRED
+ throughput (normal | high) #REQUIRED
+ relibility (normal | high) #REQUIRED
+ reserved CDATA #FIXED "0">
+
+ <!ELEMENT total.length EMPTY>
+ <!--
+ total length of datagram (header and payload) in octets, MUST be
+ less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+ ethernets).
+ -->
+ <!ATTLIST total.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT id EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST id
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT flags EMPTY>
+ <!-- df = don't fragment, mf = more fragments -->
+ <!ATTLIST flags
+
+
+
+Kennedy Informational [Page 8]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ reserved CDATA #FIXED "0"
+ df (may|dont) #REQUIRED
+ mf (last|more) #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+ <!ATTLIST offset
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT ttl EMPTY>
+ <!-- 0 <= ttl <= 255 -->
+ <!ATTLIST ttl
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT protocol EMPTY>
+ <!-- 0 <= protocol <= 255 (per IANA) -->
+ <!ATTLIST protocol
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT checksum EMPTY>
+ <!-- 0 <= checksum <= 65535 (over header only) -->
+ <!ATTLIST checksum
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT source EMPTY>
+ <!ATTLIST source
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT destination EMPTY>
+ <!ATTLIST destination
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT options ( end | noop | security | loose | strict | record
+ | stream | timestamp )*>
+
+ <!ELEMENT end EMPTY>
+ <!ATTLIST end
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "0">
+
+ <!ELEMENT noop EMPTY>
+ <!ATTLIST noop
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "1">
+
+ <!ELEMENT security EMPTY>
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST security
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "2"
+ length CDATA #FIXED "11"
+ security %Sec; #REQUIRED
+ compartments %Compartments; #REQUIRED
+ handling %Handling; #REQUIRED
+ tcc %TCC; #REQUIRED>
+ <!ELEMENT loose (hop)+>
+ <!ATTLIST loose
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "3"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT hop EMPTY>
+ <!ATTLIST hop
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT strict (hop)+>
+ <!ATTLIST strict
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "9"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT record (hop)+>
+ <!ATTLIST record
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "7"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT stream EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST stream
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "8"
+ length CDATA #FIXED "4"
+ id %Digits; #REQUIRED>
+
+ <!ELEMENT timestamp (tstamp)+>
+ <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST timestamp
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "2"
+ number CDATA #FIXED "4"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED
+ oflw %Digits; #REQUIRED
+ flag (0 | 1 | 3) #REQUIRED>
+
+ <!ELEMENT tstamp EMPTY>
+ <!ATTLIST tstamp
+ time %Digits; #REQUIRED
+ address %IP4Addr; #IMPLIED>
+ <!--
+ padding to bring header to 32-bit boundary.
+ pad MUST be "0"*
+ -->
+ <!ELEMENT padding EMPTY>
+ <!ATTLIST padding
+ pad CDATA #REQUIRED>
+
+ <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+ by section 2.1 of this RFC -->
+ <!ELEMENT payload (CDATA)>
+
+7.2. TCPoXML DTD
+
+ <!--
+ DTD for TCP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ -->
+
+ <!-- the pseudoheader is only included for checksum calculations -->
+ <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+ <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+ reserved, control, window, checksum, urgent,
+ tcp.options, padding)>
+
+ <!ELEMENT src EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+ <!ATTLIST src
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT dest EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST dest
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT sequence EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST sequence
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT acknowledgement EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST acknowledgement
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= number <= 255 -->
+ <!ATTLIST offset
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT reserved EMPTY>
+ <!ATTLIST reserved
+ value CDATA #FIXED "0">
+
+ <!ELEMENT control EMPTY>
+ <!ATTLIST control
+ urg (0|1) #IMPLIED
+ ack (0|1) #IMPLIED
+ psh (0|1) #IMPLIED
+ rst (0|1) #IMPLIED
+ syn (0|1) #IMPLIED
+ fin (0|1) #IMPLIED>
+
+ <!ELEMENT window EMPTY>
+ <!-- 0 <= size <= 65,535 -->
+ <!ATTLIST window
+ size %Digits; #REQUIRED>
+
+ <!--
+ checksum as in ip, but with
+ the following pseudo-header added into the tcp element:
+ -->
+ <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+ tcp.length)>
+
+ <!--
+ tcp header + data length in octets. does not include the size of
+
+ the pseudoheader.
+ -->
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ELEMENT tcp.length EMPTY>
+ <!ATTLIST tcp.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT urgent EMPTY>
+ <!-- 0 <= pointer <= 65,535 -->
+ <!ATTLIST urgent
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+ <!ELEMENT tcp.end EMPTY>
+ <!ATTLIST tcp.end
+ kind CDATA #FIXED "0">
+
+ <!ELEMENT tcp.noop EMPTY>
+ <!ATTLIST tcp.noop
+ kind CDATA #FIXED "1">
+
+ <!ELEMENT tcp.mss EMPTY>
+ <!ATTLIST tcp.mss
+ kind CDATA #FIXED "2"
+ length CDATA #FIXED "4"
+ size %Digits; #REQUIRED>
+
+7.3. UDPoXML DTD
+
+ <!--
+ DTD for UDP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ -->
+
+ <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+ <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+ <!ELEMENT udp.pseudoheader (source, destination, protocol,
+ udp.length)>
+
+ <!--
+ udp header + data length in octets. does not include the size of
+ the pseudoheader.
+ -->
+ <!ELEMENT udp.length EMPTY>
+ <!ATTLIST udp.length
+ value %Digits; #REQUIRED>
+
+
+
+Kennedy Informational [Page 13]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+8. Security Considerations
+
+ XML, as a subset of SGML, has the same security considerations as
+ specified in SGML Media Types [RFC1874]. Security considerations
+ that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+ not attempt to correct for issues not related to message format.
+
+9. References
+
+ [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
+ February 2002. (Work in Progress)
+
+ [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
+ 793, September 1981.
+
+ [RFC894] Hornig, C., "Standard for the Transmission of IP
+ Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+ [RFC1042] Postel, J. and J. Reynolds, "Standard for the
+ Transmission of IP Datagrams Over IEEE 802 Networks", STD
+ 43, RFC 1042, February 1988.
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts -
+ Application and Support", RFC 1123, October 1989.
+
+ [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
+ 1995.
+
+ [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
+ October 1996.
+
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy Informational [Page 14]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
+ RFC 3080, March 2001.
+
+ [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+ Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+ "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+ Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+ Markup Language (XML)" World Wide Web Consortium
+ Recommendation REC- xml-19980210.
+ http://www.w3.org/TR/1998/REC-xml-19980210
+
+10. Author's Address
+
+ Hugh Kennedy
+ Mimezine
+ 1060 West Addison
+ Chicago, IL 60613
+ USA
+
+ EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 15]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 16]
+
+
+
+
+
+
+
+Network Working Group H. Kennedy
+Request for Comments: 3252 Mimezine
+Category: Informational 1 April 2002
+
+
+ Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document defines a reformulation of IP and two transport layer
+ protocols (TCP and UDP) as XML applications.
+
+1. Introduction
+
+1.1. Overview
+
+ This document describes the Binary Lexical Octet Ad-hoc Transport
+ (BLOAT): a reformulation of a widely-deployed network-layer protocol
+ (IP [RFC791]), and two associated transport layer protocols (TCP
+ [RFC793] and UDP [RFC768]) as XML [XML] applications. It also
+ describes methods for transporting BLOAT over Ethernet and IEEE 802
+ networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+ across the public Internet.
+
+1.2. Motivation
+
+ The wild popularity of XML as a basis for application-level protocols
+ such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+ Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+ investigation into the possibility of extending the use of XML in the
+ protocol stack. Using XML at both the transport and network layer in
+ addition to the application layer would provide for an amazing amount
+ of power and flexibility while removing dependencies on proprietary
+ and hard-to-understand binary protocols. This protocol unification
+ would also allow applications to use a single XML parser for all
+ aspects of their operation, eliminating developer time spent figuring
+ out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy Informational [Page 1]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ parsing to the XML toolset. The use of XML also mitigates concerns
+ over "network vs. host" byte ordering which is at the root of many
+ network application bugs.
+
+1.3. Relation to Existing Protocols
+
+ The reformulations specified in this RFC follow as closely as
+ possible the spirit of the RFCs on which they are based, and so MAY
+ contain elements or attributes that would not be needed in a pure
+ reworking (e.g. length attributes, which are implicit in XML.)
+
+ The layering of network and transport protocols are maintained in
+ this RFC despite the optimizations that could be made if the line
+ were somewhat blurred (i.e. merging TCP and IP into a single, larger
+ element in the DTD) in order to foster future use of this protocol as
+ a basis for reformulating other protocols (such as ICMP.)
+
+ Other than the encoding, the behavioral aspects of each of the
+ existing protocols remain unchanged. Routing, address spaces, TCP
+ congestion control, etc. behave as specified in the extant standards.
+ Adapting to new standards and experimental algorithm heuristics for
+ improving performance will become much easier once the move to BLOAT
+ has been completed.
+
+1.4. Requirement Levels
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
+
+2. IPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC.
+ IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+ (section 3.) and higher-level application protocols.
+
+ The DTD for this document type can be found in section 7.1.
+
+ The routing of IPoXML can be easily implemented on hosts with an XML
+ parser, as the regular structure lends itself handily to parsing and
+ validation of the document/datagram and then processing the
+ destination address, TTL, and checksum before sending it on to its
+ next-hop.
+
+ The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+ wider deployment of IPv4 and the fact that implementing IPv6 as XML
+ would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy Informational [Page 2]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+ of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
+ formed and include the XMLDecl.
+
+2.1. IP Description
+
+ A number of items have changed (for the better) from the original IP
+ specification. Bit-masks, where present have been converted into
+ human-readable values. IP addresses are listed in their dotted-
+ decimal notation [RFC1123]. Length and checksum values are present
+ as decimal integers.
+
+ To calculate the length and checksum fields of the IP element, a
+ canonicalized form of the element MUST be used. The canonical form
+ SHALL have no whitespace (including newline characters) between
+ elements and only one space character between attributes. There
+ SHALL NOT be a space following the last attribute in an element.
+
+ An iterative method SHOULD be used to calculate checksums, as the
+ length field will vary based on the size of the checksum.
+
+ The payload element bears special attention. Due to the character
+ set restrictions of XML, the payload of IP datagrams (which MAY
+ contain arbitrary data) MUST be encoded for transport. This RFC
+ REQUIRES the contents of the payload to be encoded in the base-64
+ encoding of RFC 2045 [RFC2045], but removes the requirement that the
+ encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 3]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+2.2. Example Datagram
+
+ The following is an example IPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ <ip>
+ <header length="474">
+ <version value="4"/>
+ <tos precedence="Routine" delay="Normal" throughput="Normal"
+ relibility="Normal" reserved="0"/>
+ <total.length value="461"/>
+ <id value="1"/>
+ <flags reserved="0" df="dont" mf="last"/>
+ <offset value="0"/>
+ <ttl value="255"/>
+ <protocol value="6"/>
+ <checksum value="8707"/>
+ <source address="10.0.0.22"/>
+ <destination address="10.0.0.1"/>
+ <options>
+ <end copied="0" class="0" number="0"/>
+ </options>
+ <padding pad="0"/>
+ </header>
+ <payload>
+ </payload>
+ </ip>
+
+3. TCPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+ A number of items have changed from the original TCP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+ To calculate the length and checksum fields of the TCP element, a
+ canonicalized form of the element MUST be used as in section 2.1.
+
+ An iterative method SHOULD be used to calculate checksums as in
+ section 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy Informational [Page 4]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ The TCP offset element was expanded to a maximum of 255 from 16 to
+ allow for the increased size of the header in XML.
+
+ TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ <tcp>
+ <tcp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <sequence number="322622954"/>
+ <acknowledgement number="689715995"/>
+ <offset number=""/>
+ <reserved value="0"/>
+ <control syn="1" ack="1"/>
+ <window size="1"/>
+ <urgent pointer="0"/>
+ <checksum value="2988"/>
+ <tcp.options>
+ <tcp.end kind="0"/>
+ </tcp.options>
+ <padding pad="0"/>
+ </tcp.header>
+ <payload>
+ </payload>
+ </tcp>
+
+4. UDPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+ A number of items have changed from the original UDP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+
+
+
+
+
+
+Kennedy Informational [Page 5]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ To calculate the length and checksum fields of the UDP element, a
+ canonicalized form of the element MUST be used as in section 2.1. An
+ iterative method SHOULD be used to calculate checksums as in section
+ 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+ UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ <udp>
+ <udp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <udp.length value="143"/>
+ <checksum value="2988"/>
+ </udp.header>
+ <payload>
+ </payload>
+ </udp>
+
+5. Network Transport
+
+ This document provides for the transmission of BLOAT datagrams over
+ two common families of physical layer transport. Future RFCs will
+ address additional transports as routing vendors catch up to the
+ specification, and we begin to see BLOAT routed across the Internet
+ backbone.
+
+5.1. Ethernet
+
+ BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+ exception that the type field of the Ethernet frame MUST contain the
+ value 0xBEEF. The first 5 octets of the Ethernet frame payload will
+ be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+ BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+ that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy Informational [Page 6]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+6. Gatewaying over IP
+
+ In order to facilitate the gradual introduction of BLOAT into the
+ public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+ gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+ The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+ Network DTD (7.1.)
+
+ The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+ [XML]) although it is understood that most IPoXML implementations
+ will not need to pull down the DTD, as it will normally be embedded
+ in the implementation, and presents something of a catch-22 if you
+ need to load part of your network protocol over the network.
+
+7.1. IPoXML DTD
+
+ <!--
+ DTD for IP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ -->
+ <!--
+ DTD data types:
+
+ Digits [0..9]+
+
+ Precedence "NetworkControl | InternetworkControl |
+ CRITIC | FlashOverride | Flash | Immediate |
+ Priority | Routine"
+
+ IP4Addr "dotted-decimal" notation of [RFC1123]
+
+ Class [0..3]
+
+ Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
+ Restricted | Secret | Top Secret | Reserved"
+
+ Compartments [0..65535]
+
+ Handling [0..65535]
+
+ TCC [0..16777216]
+
+ -->
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ENTITY % Digits "CDATA">
+ <!ENTITY % Precedence "CDATA">
+ <!ENTITY % IP4Addr "CDATA">
+ <!ENTITY % Class "CDATA">
+ <!ENTITY % Sec "CDATA">
+ <!ENTITY % Compartments "CDATA">
+ <!ENTITY % Handling "CDATA">
+ <!ENTITY % TCC "CDATA">
+
+ <!ELEMENT ip (header, payload)>
+
+ <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+ protocol, checksum, source, destination, options,
+ padding)>
+ <!-- length of header in 32-bit words -->
+ <!ATTLIST header
+ length %Digits; #REQUIRED>
+
+ <!ELEMENT version EMPTY>
+ <!-- ip version. SHOULD be "4" -->
+ <!ATTLIST version
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT tos EMPTY>
+ <!ATTLIST tos
+ precedence %Precedence; #REQUIRED
+ delay (normal | low) #REQUIRED
+ throughput (normal | high) #REQUIRED
+ relibility (normal | high) #REQUIRED
+ reserved CDATA #FIXED "0">
+
+ <!ELEMENT total.length EMPTY>
+ <!--
+ total length of datagram (header and payload) in octets, MUST be
+ less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+ ethernets).
+ -->
+ <!ATTLIST total.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT id EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST id
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT flags EMPTY>
+ <!-- df = don't fragment, mf = more fragments -->
+ <!ATTLIST flags
+
+
+
+Kennedy Informational [Page 8]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ reserved CDATA #FIXED "0"
+ df (may|dont) #REQUIRED
+ mf (last|more) #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+ <!ATTLIST offset
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT ttl EMPTY>
+ <!-- 0 <= ttl <= 255 -->
+ <!ATTLIST ttl
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT protocol EMPTY>
+ <!-- 0 <= protocol <= 255 (per IANA) -->
+ <!ATTLIST protocol
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT checksum EMPTY>
+ <!-- 0 <= checksum <= 65535 (over header only) -->
+ <!ATTLIST checksum
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT source EMPTY>
+ <!ATTLIST source
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT destination EMPTY>
+ <!ATTLIST destination
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT options ( end | noop | security | loose | strict | record
+ | stream | timestamp )*>
+
+ <!ELEMENT end EMPTY>
+ <!ATTLIST end
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "0">
+
+ <!ELEMENT noop EMPTY>
+ <!ATTLIST noop
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "1">
+
+ <!ELEMENT security EMPTY>
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST security
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "2"
+ length CDATA #FIXED "11"
+ security %Sec; #REQUIRED
+ compartments %Compartments; #REQUIRED
+ handling %Handling; #REQUIRED
+ tcc %TCC; #REQUIRED>
+ <!ELEMENT loose (hop)+>
+ <!ATTLIST loose
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "3"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT hop EMPTY>
+ <!ATTLIST hop
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT strict (hop)+>
+ <!ATTLIST strict
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "9"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT record (hop)+>
+ <!ATTLIST record
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "7"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT stream EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST stream
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "8"
+ length CDATA #FIXED "4"
+ id %Digits; #REQUIRED>
+
+ <!ELEMENT timestamp (tstamp)+>
+ <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST timestamp
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "2"
+ number CDATA #FIXED "4"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED
+ oflw %Digits; #REQUIRED
+ flag (0 | 1 | 3) #REQUIRED>
+
+ <!ELEMENT tstamp EMPTY>
+ <!ATTLIST tstamp
+ time %Digits; #REQUIRED
+ address %IP4Addr; #IMPLIED>
+ <!--
+ padding to bring header to 32-bit boundary.
+ pad MUST be "0"*
+ -->
+ <!ELEMENT padding EMPTY>
+ <!ATTLIST padding
+ pad CDATA #REQUIRED>
+
+ <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+ by section 2.1 of this RFC -->
+ <!ELEMENT payload (CDATA)>
+
+7.2. TCPoXML DTD
+
+ <!--
+ DTD for TCP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ -->
+
+ <!-- the pseudoheader is only included for checksum calculations -->
+ <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+ <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+ reserved, control, window, checksum, urgent,
+ tcp.options, padding)>
+
+ <!ELEMENT src EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+ <!ATTLIST src
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT dest EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST dest
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT sequence EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST sequence
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT acknowledgement EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST acknowledgement
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= number <= 255 -->
+ <!ATTLIST offset
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT reserved EMPTY>
+ <!ATTLIST reserved
+ value CDATA #FIXED "0">
+
+ <!ELEMENT control EMPTY>
+ <!ATTLIST control
+ urg (0|1) #IMPLIED
+ ack (0|1) #IMPLIED
+ psh (0|1) #IMPLIED
+ rst (0|1) #IMPLIED
+ syn (0|1) #IMPLIED
+ fin (0|1) #IMPLIED>
+
+ <!ELEMENT window EMPTY>
+ <!-- 0 <= size <= 65,535 -->
+ <!ATTLIST window
+ size %Digits; #REQUIRED>
+
+ <!--
+ checksum as in ip, but with
+ the following pseudo-header added into the tcp element:
+ -->
+ <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+ tcp.length)>
+
+ <!--
+ tcp header + data length in octets. does not include the size of
+
+ the pseudoheader.
+ -->
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ELEMENT tcp.length EMPTY>
+ <!ATTLIST tcp.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT urgent EMPTY>
+ <!-- 0 <= pointer <= 65,535 -->
+ <!ATTLIST urgent
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+ <!ELEMENT tcp.end EMPTY>
+ <!ATTLIST tcp.end
+ kind CDATA #FIXED "0">
+
+ <!ELEMENT tcp.noop EMPTY>
+ <!ATTLIST tcp.noop
+ kind CDATA #FIXED "1">
+
+ <!ELEMENT tcp.mss EMPTY>
+ <!ATTLIST tcp.mss
+ kind CDATA #FIXED "2"
+ length CDATA #FIXED "4"
+ size %Digits; #REQUIRED>
+
+7.3. UDPoXML DTD
+
+ <!--
+ DTD for UDP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ -->
+
+ <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+ <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+ <!ELEMENT udp.pseudoheader (source, destination, protocol,
+ udp.length)>
+
+ <!--
+ udp header + data length in octets. does not include the size of
+ the pseudoheader.
+ -->
+ <!ELEMENT udp.length EMPTY>
+ <!ATTLIST udp.length
+ value %Digits; #REQUIRED>
+
+
+
+Kennedy Informational [Page 13]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+8. Security Considerations
+
+ XML, as a subset of SGML, has the same security considerations as
+ specified in SGML Media Types [RFC1874]. Security considerations
+ that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+ not attempt to correct for issues not related to message format.
+
+9. References
+
+ [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
+ February 2002. (Work in Progress)
+
+ [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
+ 793, September 1981.
+
+ [RFC894] Hornig, C., "Standard for the Transmission of IP
+ Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+ [RFC1042] Postel, J. and J. Reynolds, "Standard for the
+ Transmission of IP Datagrams Over IEEE 802 Networks", STD
+ 43, RFC 1042, February 1988.
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts -
+ Application and Support", RFC 1123, October 1989.
+
+ [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
+ 1995.
+
+ [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
+ October 1996.
+
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy Informational [Page 14]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
+ RFC 3080, March 2001.
+
+ [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+ Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+ "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+ Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+ Markup Language (XML)" World Wide Web Consortium
+ Recommendation REC- xml-19980210.
+ http://www.w3.org/TR/1998/REC-xml-19980210
+
+10. Author's Address
+
+ Hugh Kennedy
+ Mimezine
+ 1060 West Addison
+ Chicago, IL 60613
+ USA
+
+ EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 15]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 16]
+
+
+
+
+
+
+
+Network Working Group H. Kennedy
+Request for Comments: 3252 Mimezine
+Category: Informational 1 April 2002
+
+
+ Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document defines a reformulation of IP and two transport layer
+ protocols (TCP and UDP) as XML applications.
+
+1. Introduction
+
+1.1. Overview
+
+ This document describes the Binary Lexical Octet Ad-hoc Transport
+ (BLOAT): a reformulation of a widely-deployed network-layer protocol
+ (IP [RFC791]), and two associated transport layer protocols (TCP
+ [RFC793] and UDP [RFC768]) as XML [XML] applications. It also
+ describes methods for transporting BLOAT over Ethernet and IEEE 802
+ networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+ across the public Internet.
+
+1.2. Motivation
+
+ The wild popularity of XML as a basis for application-level protocols
+ such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+ Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+ investigation into the possibility of extending the use of XML in the
+ protocol stack. Using XML at both the transport and network layer in
+ addition to the application layer would provide for an amazing amount
+ of power and flexibility while removing dependencies on proprietary
+ and hard-to-understand binary protocols. This protocol unification
+ would also allow applications to use a single XML parser for all
+ aspects of their operation, eliminating developer time spent figuring
+ out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy Informational [Page 1]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ parsing to the XML toolset. The use of XML also mitigates concerns
+ over "network vs. host" byte ordering which is at the root of many
+ network application bugs.
+
+1.3. Relation to Existing Protocols
+
+ The reformulations specified in this RFC follow as closely as
+ possible the spirit of the RFCs on which they are based, and so MAY
+ contain elements or attributes that would not be needed in a pure
+ reworking (e.g. length attributes, which are implicit in XML.)
+
+ The layering of network and transport protocols are maintained in
+ this RFC despite the optimizations that could be made if the line
+ were somewhat blurred (i.e. merging TCP and IP into a single, larger
+ element in the DTD) in order to foster future use of this protocol as
+ a basis for reformulating other protocols (such as ICMP.)
+
+ Other than the encoding, the behavioral aspects of each of the
+ existing protocols remain unchanged. Routing, address spaces, TCP
+ congestion control, etc. behave as specified in the extant standards.
+ Adapting to new standards and experimental algorithm heuristics for
+ improving performance will become much easier once the move to BLOAT
+ has been completed.
+
+1.4. Requirement Levels
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
+
+2. IPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC.
+ IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+ (section 3.) and higher-level application protocols.
+
+ The DTD for this document type can be found in section 7.1.
+
+ The routing of IPoXML can be easily implemented on hosts with an XML
+ parser, as the regular structure lends itself handily to parsing and
+ validation of the document/datagram and then processing the
+ destination address, TTL, and checksum before sending it on to its
+ next-hop.
+
+ The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+ wider deployment of IPv4 and the fact that implementing IPv6 as XML
+ would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy Informational [Page 2]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+ of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
+ formed and include the XMLDecl.
+
+2.1. IP Description
+
+ A number of items have changed (for the better) from the original IP
+ specification. Bit-masks, where present have been converted into
+ human-readable values. IP addresses are listed in their dotted-
+ decimal notation [RFC1123]. Length and checksum values are present
+ as decimal integers.
+
+ To calculate the length and checksum fields of the IP element, a
+ canonicalized form of the element MUST be used. The canonical form
+ SHALL have no whitespace (including newline characters) between
+ elements and only one space character between attributes. There
+ SHALL NOT be a space following the last attribute in an element.
+
+ An iterative method SHOULD be used to calculate checksums, as the
+ length field will vary based on the size of the checksum.
+
+ The payload element bears special attention. Due to the character
+ set restrictions of XML, the payload of IP datagrams (which MAY
+ contain arbitrary data) MUST be encoded for transport. This RFC
+ REQUIRES the contents of the payload to be encoded in the base-64
+ encoding of RFC 2045 [RFC2045], but removes the requirement that the
+ encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 3]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+2.2. Example Datagram
+
+ The following is an example IPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ <ip>
+ <header length="474">
+ <version value="4"/>
+ <tos precedence="Routine" delay="Normal" throughput="Normal"
+ relibility="Normal" reserved="0"/>
+ <total.length value="461"/>
+ <id value="1"/>
+ <flags reserved="0" df="dont" mf="last"/>
+ <offset value="0"/>
+ <ttl value="255"/>
+ <protocol value="6"/>
+ <checksum value="8707"/>
+ <source address="10.0.0.22"/>
+ <destination address="10.0.0.1"/>
+ <options>
+ <end copied="0" class="0" number="0"/>
+ </options>
+ <padding pad="0"/>
+ </header>
+ <payload>
+ </payload>
+ </ip>
+
+3. TCPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+ A number of items have changed from the original TCP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+ To calculate the length and checksum fields of the TCP element, a
+ canonicalized form of the element MUST be used as in section 2.1.
+
+ An iterative method SHOULD be used to calculate checksums as in
+ section 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy Informational [Page 4]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ The TCP offset element was expanded to a maximum of 255 from 16 to
+ allow for the increased size of the header in XML.
+
+ TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ <tcp>
+ <tcp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <sequence number="322622954"/>
+ <acknowledgement number="689715995"/>
+ <offset number=""/>
+ <reserved value="0"/>
+ <control syn="1" ack="1"/>
+ <window size="1"/>
+ <urgent pointer="0"/>
+ <checksum value="2988"/>
+ <tcp.options>
+ <tcp.end kind="0"/>
+ </tcp.options>
+ <padding pad="0"/>
+ </tcp.header>
+ <payload>
+ </payload>
+ </tcp>
+
+4. UDPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+ A number of items have changed from the original UDP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+
+
+
+
+
+
+Kennedy Informational [Page 5]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ To calculate the length and checksum fields of the UDP element, a
+ canonicalized form of the element MUST be used as in section 2.1. An
+ iterative method SHOULD be used to calculate checksums as in section
+ 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+ UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ <udp>
+ <udp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <udp.length value="143"/>
+ <checksum value="2988"/>
+ </udp.header>
+ <payload>
+ </payload>
+ </udp>
+
+5. Network Transport
+
+ This document provides for the transmission of BLOAT datagrams over
+ two common families of physical layer transport. Future RFCs will
+ address additional transports as routing vendors catch up to the
+ specification, and we begin to see BLOAT routed across the Internet
+ backbone.
+
+5.1. Ethernet
+
+ BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+ exception that the type field of the Ethernet frame MUST contain the
+ value 0xBEEF. The first 5 octets of the Ethernet frame payload will
+ be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+ BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+ that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy Informational [Page 6]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+6. Gatewaying over IP
+
+ In order to facilitate the gradual introduction of BLOAT into the
+ public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+ gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+ The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+ Network DTD (7.1.)
+
+ The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+ [XML]) although it is understood that most IPoXML implementations
+ will not need to pull down the DTD, as it will normally be embedded
+ in the implementation, and presents something of a catch-22 if you
+ need to load part of your network protocol over the network.
+
+7.1. IPoXML DTD
+
+ <!--
+ DTD for IP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ -->
+ <!--
+ DTD data types:
+
+ Digits [0..9]+
+
+ Precedence "NetworkControl | InternetworkControl |
+ CRITIC | FlashOverride | Flash | Immediate |
+ Priority | Routine"
+
+ IP4Addr "dotted-decimal" notation of [RFC1123]
+
+ Class [0..3]
+
+ Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
+ Restricted | Secret | Top Secret | Reserved"
+
+ Compartments [0..65535]
+
+ Handling [0..65535]
+
+ TCC [0..16777216]
+
+ -->
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ENTITY % Digits "CDATA">
+ <!ENTITY % Precedence "CDATA">
+ <!ENTITY % IP4Addr "CDATA">
+ <!ENTITY % Class "CDATA">
+ <!ENTITY % Sec "CDATA">
+ <!ENTITY % Compartments "CDATA">
+ <!ENTITY % Handling "CDATA">
+ <!ENTITY % TCC "CDATA">
+
+ <!ELEMENT ip (header, payload)>
+
+ <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+ protocol, checksum, source, destination, options,
+ padding)>
+ <!-- length of header in 32-bit words -->
+ <!ATTLIST header
+ length %Digits; #REQUIRED>
+
+ <!ELEMENT version EMPTY>
+ <!-- ip version. SHOULD be "4" -->
+ <!ATTLIST version
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT tos EMPTY>
+ <!ATTLIST tos
+ precedence %Precedence; #REQUIRED
+ delay (normal | low) #REQUIRED
+ throughput (normal | high) #REQUIRED
+ relibility (normal | high) #REQUIRED
+ reserved CDATA #FIXED "0">
+
+ <!ELEMENT total.length EMPTY>
+ <!--
+ total length of datagram (header and payload) in octets, MUST be
+ less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+ ethernets).
+ -->
+ <!ATTLIST total.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT id EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST id
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT flags EMPTY>
+ <!-- df = don't fragment, mf = more fragments -->
+ <!ATTLIST flags
+
+
+
+Kennedy Informational [Page 8]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ reserved CDATA #FIXED "0"
+ df (may|dont) #REQUIRED
+ mf (last|more) #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+ <!ATTLIST offset
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT ttl EMPTY>
+ <!-- 0 <= ttl <= 255 -->
+ <!ATTLIST ttl
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT protocol EMPTY>
+ <!-- 0 <= protocol <= 255 (per IANA) -->
+ <!ATTLIST protocol
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT checksum EMPTY>
+ <!-- 0 <= checksum <= 65535 (over header only) -->
+ <!ATTLIST checksum
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT source EMPTY>
+ <!ATTLIST source
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT destination EMPTY>
+ <!ATTLIST destination
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT options ( end | noop | security | loose | strict | record
+ | stream | timestamp )*>
+
+ <!ELEMENT end EMPTY>
+ <!ATTLIST end
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "0">
+
+ <!ELEMENT noop EMPTY>
+ <!ATTLIST noop
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "1">
+
+ <!ELEMENT security EMPTY>
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST security
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "2"
+ length CDATA #FIXED "11"
+ security %Sec; #REQUIRED
+ compartments %Compartments; #REQUIRED
+ handling %Handling; #REQUIRED
+ tcc %TCC; #REQUIRED>
+ <!ELEMENT loose (hop)+>
+ <!ATTLIST loose
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "3"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT hop EMPTY>
+ <!ATTLIST hop
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT strict (hop)+>
+ <!ATTLIST strict
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "9"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT record (hop)+>
+ <!ATTLIST record
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "7"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT stream EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST stream
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "8"
+ length CDATA #FIXED "4"
+ id %Digits; #REQUIRED>
+
+ <!ELEMENT timestamp (tstamp)+>
+ <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST timestamp
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "2"
+ number CDATA #FIXED "4"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED
+ oflw %Digits; #REQUIRED
+ flag (0 | 1 | 3) #REQUIRED>
+
+ <!ELEMENT tstamp EMPTY>
+ <!ATTLIST tstamp
+ time %Digits; #REQUIRED
+ address %IP4Addr; #IMPLIED>
+ <!--
+ padding to bring header to 32-bit boundary.
+ pad MUST be "0"*
+ -->
+ <!ELEMENT padding EMPTY>
+ <!ATTLIST padding
+ pad CDATA #REQUIRED>
+
+ <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+ by section 2.1 of this RFC -->
+ <!ELEMENT payload (CDATA)>
+
+7.2. TCPoXML DTD
+
+ <!--
+ DTD for TCP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ -->
+
+ <!-- the pseudoheader is only included for checksum calculations -->
+ <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+ <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+ reserved, control, window, checksum, urgent,
+ tcp.options, padding)>
+
+ <!ELEMENT src EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+ <!ATTLIST src
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT dest EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST dest
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT sequence EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST sequence
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT acknowledgement EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST acknowledgement
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= number <= 255 -->
+ <!ATTLIST offset
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT reserved EMPTY>
+ <!ATTLIST reserved
+ value CDATA #FIXED "0">
+
+ <!ELEMENT control EMPTY>
+ <!ATTLIST control
+ urg (0|1) #IMPLIED
+ ack (0|1) #IMPLIED
+ psh (0|1) #IMPLIED
+ rst (0|1) #IMPLIED
+ syn (0|1) #IMPLIED
+ fin (0|1) #IMPLIED>
+
+ <!ELEMENT window EMPTY>
+ <!-- 0 <= size <= 65,535 -->
+ <!ATTLIST window
+ size %Digits; #REQUIRED>
+
+ <!--
+ checksum as in ip, but with
+ the following pseudo-header added into the tcp element:
+ -->
+ <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+ tcp.length)>
+
+ <!--
+ tcp header + data length in octets. does not include the size of
+
+ the pseudoheader.
+ -->
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ELEMENT tcp.length EMPTY>
+ <!ATTLIST tcp.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT urgent EMPTY>
+ <!-- 0 <= pointer <= 65,535 -->
+ <!ATTLIST urgent
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+ <!ELEMENT tcp.end EMPTY>
+ <!ATTLIST tcp.end
+ kind CDATA #FIXED "0">
+
+ <!ELEMENT tcp.noop EMPTY>
+ <!ATTLIST tcp.noop
+ kind CDATA #FIXED "1">
+
+ <!ELEMENT tcp.mss EMPTY>
+ <!ATTLIST tcp.mss
+ kind CDATA #FIXED "2"
+ length CDATA #FIXED "4"
+ size %Digits; #REQUIRED>
+
+7.3. UDPoXML DTD
+
+ <!--
+ DTD for UDP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ -->
+
+ <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+ <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+ <!ELEMENT udp.pseudoheader (source, destination, protocol,
+ udp.length)>
+
+ <!--
+ udp header + data length in octets. does not include the size of
+ the pseudoheader.
+ -->
+ <!ELEMENT udp.length EMPTY>
+ <!ATTLIST udp.length
+ value %Digits; #REQUIRED>
+
+
+
+Kennedy Informational [Page 13]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+8. Security Considerations
+
+ XML, as a subset of SGML, has the same security considerations as
+ specified in SGML Media Types [RFC1874]. Security considerations
+ that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+ not attempt to correct for issues not related to message format.
+
+9. References
+
+ [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
+ February 2002. (Work in Progress)
+
+ [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
+ 793, September 1981.
+
+ [RFC894] Hornig, C., "Standard for the Transmission of IP
+ Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+ [RFC1042] Postel, J. and J. Reynolds, "Standard for the
+ Transmission of IP Datagrams Over IEEE 802 Networks", STD
+ 43, RFC 1042, February 1988.
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts -
+ Application and Support", RFC 1123, October 1989.
+
+ [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
+ 1995.
+
+ [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
+ October 1996.
+
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy Informational [Page 14]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
+ RFC 3080, March 2001.
+
+ [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+ Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+ "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+ Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+ Markup Language (XML)" World Wide Web Consortium
+ Recommendation REC- xml-19980210.
+ http://www.w3.org/TR/1998/REC-xml-19980210
+
+10. Author's Address
+
+ Hugh Kennedy
+ Mimezine
+ 1060 West Addison
+ Chicago, IL 60613
+ USA
+
+ EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 15]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 16]
+
+
+
+
+
+
+
+Network Working Group H. Kennedy
+Request for Comments: 3252 Mimezine
+Category: Informational 1 April 2002
+
+
+ Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document defines a reformulation of IP and two transport layer
+ protocols (TCP and UDP) as XML applications.
+
+1. Introduction
+
+1.1. Overview
+
+ This document describes the Binary Lexical Octet Ad-hoc Transport
+ (BLOAT): a reformulation of a widely-deployed network-layer protocol
+ (IP [RFC791]), and two associated transport layer protocols (TCP
+ [RFC793] and UDP [RFC768]) as XML [XML] applications. It also
+ describes methods for transporting BLOAT over Ethernet and IEEE 802
+ networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+ across the public Internet.
+
+1.2. Motivation
+
+ The wild popularity of XML as a basis for application-level protocols
+ such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+ Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+ investigation into the possibility of extending the use of XML in the
+ protocol stack. Using XML at both the transport and network layer in
+ addition to the application layer would provide for an amazing amount
+ of power and flexibility while removing dependencies on proprietary
+ and hard-to-understand binary protocols. This protocol unification
+ would also allow applications to use a single XML parser for all
+ aspects of their operation, eliminating developer time spent figuring
+ out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy Informational [Page 1]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ parsing to the XML toolset. The use of XML also mitigates concerns
+ over "network vs. host" byte ordering which is at the root of many
+ network application bugs.
+
+1.3. Relation to Existing Protocols
+
+ The reformulations specified in this RFC follow as closely as
+ possible the spirit of the RFCs on which they are based, and so MAY
+ contain elements or attributes that would not be needed in a pure
+ reworking (e.g. length attributes, which are implicit in XML.)
+
+ The layering of network and transport protocols are maintained in
+ this RFC despite the optimizations that could be made if the line
+ were somewhat blurred (i.e. merging TCP and IP into a single, larger
+ element in the DTD) in order to foster future use of this protocol as
+ a basis for reformulating other protocols (such as ICMP.)
+
+ Other than the encoding, the behavioral aspects of each of the
+ existing protocols remain unchanged. Routing, address spaces, TCP
+ congestion control, etc. behave as specified in the extant standards.
+ Adapting to new standards and experimental algorithm heuristics for
+ improving performance will become much easier once the move to BLOAT
+ has been completed.
+
+1.4. Requirement Levels
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
+
+2. IPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC.
+ IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+ (section 3.) and higher-level application protocols.
+
+ The DTD for this document type can be found in section 7.1.
+
+ The routing of IPoXML can be easily implemented on hosts with an XML
+ parser, as the regular structure lends itself handily to parsing and
+ validation of the document/datagram and then processing the
+ destination address, TTL, and checksum before sending it on to its
+ next-hop.
+
+ The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+ wider deployment of IPv4 and the fact that implementing IPv6 as XML
+ would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy Informational [Page 2]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+ of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
+ formed and include the XMLDecl.
+
+2.1. IP Description
+
+ A number of items have changed (for the better) from the original IP
+ specification. Bit-masks, where present have been converted into
+ human-readable values. IP addresses are listed in their dotted-
+ decimal notation [RFC1123]. Length and checksum values are present
+ as decimal integers.
+
+ To calculate the length and checksum fields of the IP element, a
+ canonicalized form of the element MUST be used. The canonical form
+ SHALL have no whitespace (including newline characters) between
+ elements and only one space character between attributes. There
+ SHALL NOT be a space following the last attribute in an element.
+
+ An iterative method SHOULD be used to calculate checksums, as the
+ length field will vary based on the size of the checksum.
+
+ The payload element bears special attention. Due to the character
+ set restrictions of XML, the payload of IP datagrams (which MAY
+ contain arbitrary data) MUST be encoded for transport. This RFC
+ REQUIRES the contents of the payload to be encoded in the base-64
+ encoding of RFC 2045 [RFC2045], but removes the requirement that the
+ encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 3]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+2.2. Example Datagram
+
+ The following is an example IPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ <ip>
+ <header length="474">
+ <version value="4"/>
+ <tos precedence="Routine" delay="Normal" throughput="Normal"
+ relibility="Normal" reserved="0"/>
+ <total.length value="461"/>
+ <id value="1"/>
+ <flags reserved="0" df="dont" mf="last"/>
+ <offset value="0"/>
+ <ttl value="255"/>
+ <protocol value="6"/>
+ <checksum value="8707"/>
+ <source address="10.0.0.22"/>
+ <destination address="10.0.0.1"/>
+ <options>
+ <end copied="0" class="0" number="0"/>
+ </options>
+ <padding pad="0"/>
+ </header>
+ <payload>
+ </payload>
+ </ip>
+
+3. TCPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+ A number of items have changed from the original TCP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+ To calculate the length and checksum fields of the TCP element, a
+ canonicalized form of the element MUST be used as in section 2.1.
+
+ An iterative method SHOULD be used to calculate checksums as in
+ section 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy Informational [Page 4]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ The TCP offset element was expanded to a maximum of 255 from 16 to
+ allow for the increased size of the header in XML.
+
+ TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ <tcp>
+ <tcp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <sequence number="322622954"/>
+ <acknowledgement number="689715995"/>
+ <offset number=""/>
+ <reserved value="0"/>
+ <control syn="1" ack="1"/>
+ <window size="1"/>
+ <urgent pointer="0"/>
+ <checksum value="2988"/>
+ <tcp.options>
+ <tcp.end kind="0"/>
+ </tcp.options>
+ <padding pad="0"/>
+ </tcp.header>
+ <payload>
+ </payload>
+ </tcp>
+
+4. UDPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+ A number of items have changed from the original UDP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+
+
+
+
+
+
+Kennedy Informational [Page 5]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ To calculate the length and checksum fields of the UDP element, a
+ canonicalized form of the element MUST be used as in section 2.1. An
+ iterative method SHOULD be used to calculate checksums as in section
+ 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+ UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ <udp>
+ <udp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <udp.length value="143"/>
+ <checksum value="2988"/>
+ </udp.header>
+ <payload>
+ </payload>
+ </udp>
+
+5. Network Transport
+
+ This document provides for the transmission of BLOAT datagrams over
+ two common families of physical layer transport. Future RFCs will
+ address additional transports as routing vendors catch up to the
+ specification, and we begin to see BLOAT routed across the Internet
+ backbone.
+
+5.1. Ethernet
+
+ BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+ exception that the type field of the Ethernet frame MUST contain the
+ value 0xBEEF. The first 5 octets of the Ethernet frame payload will
+ be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+ BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+ that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy Informational [Page 6]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+6. Gatewaying over IP
+
+ In order to facilitate the gradual introduction of BLOAT into the
+ public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+ gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+ The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+ Network DTD (7.1.)
+
+ The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+ [XML]) although it is understood that most IPoXML implementations
+ will not need to pull down the DTD, as it will normally be embedded
+ in the implementation, and presents something of a catch-22 if you
+ need to load part of your network protocol over the network.
+
+7.1. IPoXML DTD
+
+ <!--
+ DTD for IP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ -->
+ <!--
+ DTD data types:
+
+ Digits [0..9]+
+
+ Precedence "NetworkControl | InternetworkControl |
+ CRITIC | FlashOverride | Flash | Immediate |
+ Priority | Routine"
+
+ IP4Addr "dotted-decimal" notation of [RFC1123]
+
+ Class [0..3]
+
+ Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
+ Restricted | Secret | Top Secret | Reserved"
+
+ Compartments [0..65535]
+
+ Handling [0..65535]
+
+ TCC [0..16777216]
+
+ -->
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ENTITY % Digits "CDATA">
+ <!ENTITY % Precedence "CDATA">
+ <!ENTITY % IP4Addr "CDATA">
+ <!ENTITY % Class "CDATA">
+ <!ENTITY % Sec "CDATA">
+ <!ENTITY % Compartments "CDATA">
+ <!ENTITY % Handling "CDATA">
+ <!ENTITY % TCC "CDATA">
+
+ <!ELEMENT ip (header, payload)>
+
+ <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+ protocol, checksum, source, destination, options,
+ padding)>
+ <!-- length of header in 32-bit words -->
+ <!ATTLIST header
+ length %Digits; #REQUIRED>
+
+ <!ELEMENT version EMPTY>
+ <!-- ip version. SHOULD be "4" -->
+ <!ATTLIST version
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT tos EMPTY>
+ <!ATTLIST tos
+ precedence %Precedence; #REQUIRED
+ delay (normal | low) #REQUIRED
+ throughput (normal | high) #REQUIRED
+ relibility (normal | high) #REQUIRED
+ reserved CDATA #FIXED "0">
+
+ <!ELEMENT total.length EMPTY>
+ <!--
+ total length of datagram (header and payload) in octets, MUST be
+ less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+ ethernets).
+ -->
+ <!ATTLIST total.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT id EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST id
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT flags EMPTY>
+ <!-- df = don't fragment, mf = more fragments -->
+ <!ATTLIST flags
+
+
+
+Kennedy Informational [Page 8]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ reserved CDATA #FIXED "0"
+ df (may|dont) #REQUIRED
+ mf (last|more) #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+ <!ATTLIST offset
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT ttl EMPTY>
+ <!-- 0 <= ttl <= 255 -->
+ <!ATTLIST ttl
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT protocol EMPTY>
+ <!-- 0 <= protocol <= 255 (per IANA) -->
+ <!ATTLIST protocol
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT checksum EMPTY>
+ <!-- 0 <= checksum <= 65535 (over header only) -->
+ <!ATTLIST checksum
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT source EMPTY>
+ <!ATTLIST source
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT destination EMPTY>
+ <!ATTLIST destination
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT options ( end | noop | security | loose | strict | record
+ | stream | timestamp )*>
+
+ <!ELEMENT end EMPTY>
+ <!ATTLIST end
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "0">
+
+ <!ELEMENT noop EMPTY>
+ <!ATTLIST noop
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "1">
+
+ <!ELEMENT security EMPTY>
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST security
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "2"
+ length CDATA #FIXED "11"
+ security %Sec; #REQUIRED
+ compartments %Compartments; #REQUIRED
+ handling %Handling; #REQUIRED
+ tcc %TCC; #REQUIRED>
+ <!ELEMENT loose (hop)+>
+ <!ATTLIST loose
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "3"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT hop EMPTY>
+ <!ATTLIST hop
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT strict (hop)+>
+ <!ATTLIST strict
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "9"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT record (hop)+>
+ <!ATTLIST record
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "7"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT stream EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST stream
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "8"
+ length CDATA #FIXED "4"
+ id %Digits; #REQUIRED>
+
+ <!ELEMENT timestamp (tstamp)+>
+ <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST timestamp
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "2"
+ number CDATA #FIXED "4"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED
+ oflw %Digits; #REQUIRED
+ flag (0 | 1 | 3) #REQUIRED>
+
+ <!ELEMENT tstamp EMPTY>
+ <!ATTLIST tstamp
+ time %Digits; #REQUIRED
+ address %IP4Addr; #IMPLIED>
+ <!--
+ padding to bring header to 32-bit boundary.
+ pad MUST be "0"*
+ -->
+ <!ELEMENT padding EMPTY>
+ <!ATTLIST padding
+ pad CDATA #REQUIRED>
+
+ <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+ by section 2.1 of this RFC -->
+ <!ELEMENT payload (CDATA)>
+
+7.2. TCPoXML DTD
+
+ <!--
+ DTD for TCP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ -->
+
+ <!-- the pseudoheader is only included for checksum calculations -->
+ <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+ <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+ reserved, control, window, checksum, urgent,
+ tcp.options, padding)>
+
+ <!ELEMENT src EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+ <!ATTLIST src
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT dest EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST dest
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT sequence EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST sequence
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT acknowledgement EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST acknowledgement
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= number <= 255 -->
+ <!ATTLIST offset
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT reserved EMPTY>
+ <!ATTLIST reserved
+ value CDATA #FIXED "0">
+
+ <!ELEMENT control EMPTY>
+ <!ATTLIST control
+ urg (0|1) #IMPLIED
+ ack (0|1) #IMPLIED
+ psh (0|1) #IMPLIED
+ rst (0|1) #IMPLIED
+ syn (0|1) #IMPLIED
+ fin (0|1) #IMPLIED>
+
+ <!ELEMENT window EMPTY>
+ <!-- 0 <= size <= 65,535 -->
+ <!ATTLIST window
+ size %Digits; #REQUIRED>
+
+ <!--
+ checksum as in ip, but with
+ the following pseudo-header added into the tcp element:
+ -->
+ <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+ tcp.length)>
+
+ <!--
+ tcp header + data length in octets. does not include the size of
+
+ the pseudoheader.
+ -->
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ELEMENT tcp.length EMPTY>
+ <!ATTLIST tcp.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT urgent EMPTY>
+ <!-- 0 <= pointer <= 65,535 -->
+ <!ATTLIST urgent
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+ <!ELEMENT tcp.end EMPTY>
+ <!ATTLIST tcp.end
+ kind CDATA #FIXED "0">
+
+ <!ELEMENT tcp.noop EMPTY>
+ <!ATTLIST tcp.noop
+ kind CDATA #FIXED "1">
+
+ <!ELEMENT tcp.mss EMPTY>
+ <!ATTLIST tcp.mss
+ kind CDATA #FIXED "2"
+ length CDATA #FIXED "4"
+ size %Digits; #REQUIRED>
+
+7.3. UDPoXML DTD
+
+ <!--
+ DTD for UDP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ -->
+
+ <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+ <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+ <!ELEMENT udp.pseudoheader (source, destination, protocol,
+ udp.length)>
+
+ <!--
+ udp header + data length in octets. does not include the size of
+ the pseudoheader.
+ -->
+ <!ELEMENT udp.length EMPTY>
+ <!ATTLIST udp.length
+ value %Digits; #REQUIRED>
+
+
+
+Kennedy Informational [Page 13]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+8. Security Considerations
+
+ XML, as a subset of SGML, has the same security considerations as
+ specified in SGML Media Types [RFC1874]. Security considerations
+ that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+ not attempt to correct for issues not related to message format.
+
+9. References
+
+ [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
+ February 2002. (Work in Progress)
+
+ [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
+ 793, September 1981.
+
+ [RFC894] Hornig, C., "Standard for the Transmission of IP
+ Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+ [RFC1042] Postel, J. and J. Reynolds, "Standard for the
+ Transmission of IP Datagrams Over IEEE 802 Networks", STD
+ 43, RFC 1042, February 1988.
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts -
+ Application and Support", RFC 1123, October 1989.
+
+ [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
+ 1995.
+
+ [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
+ October 1996.
+
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy Informational [Page 14]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
+ RFC 3080, March 2001.
+
+ [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+ Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+ "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+ Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+ Markup Language (XML)" World Wide Web Consortium
+ Recommendation REC- xml-19980210.
+ http://www.w3.org/TR/1998/REC-xml-19980210
+
+10. Author's Address
+
+ Hugh Kennedy
+ Mimezine
+ 1060 West Addison
+ Chicago, IL 60613
+ USA
+
+ EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 15]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 16]
+
+
+
+
+
+
+
+Network Working Group H. Kennedy
+Request for Comments: 3252 Mimezine
+Category: Informational 1 April 2002
+
+
+ Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document defines a reformulation of IP and two transport layer
+ protocols (TCP and UDP) as XML applications.
+
+1. Introduction
+
+1.1. Overview
+
+ This document describes the Binary Lexical Octet Ad-hoc Transport
+ (BLOAT): a reformulation of a widely-deployed network-layer protocol
+ (IP [RFC791]), and two associated transport layer protocols (TCP
+ [RFC793] and UDP [RFC768]) as XML [XML] applications. It also
+ describes methods for transporting BLOAT over Ethernet and IEEE 802
+ networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+ across the public Internet.
+
+1.2. Motivation
+
+ The wild popularity of XML as a basis for application-level protocols
+ such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+ Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+ investigation into the possibility of extending the use of XML in the
+ protocol stack. Using XML at both the transport and network layer in
+ addition to the application layer would provide for an amazing amount
+ of power and flexibility while removing dependencies on proprietary
+ and hard-to-understand binary protocols. This protocol unification
+ would also allow applications to use a single XML parser for all
+ aspects of their operation, eliminating developer time spent figuring
+ out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy Informational [Page 1]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ parsing to the XML toolset. The use of XML also mitigates concerns
+ over "network vs. host" byte ordering which is at the root of many
+ network application bugs.
+
+1.3. Relation to Existing Protocols
+
+ The reformulations specified in this RFC follow as closely as
+ possible the spirit of the RFCs on which they are based, and so MAY
+ contain elements or attributes that would not be needed in a pure
+ reworking (e.g. length attributes, which are implicit in XML.)
+
+ The layering of network and transport protocols are maintained in
+ this RFC despite the optimizations that could be made if the line
+ were somewhat blurred (i.e. merging TCP and IP into a single, larger
+ element in the DTD) in order to foster future use of this protocol as
+ a basis for reformulating other protocols (such as ICMP.)
+
+ Other than the encoding, the behavioral aspects of each of the
+ existing protocols remain unchanged. Routing, address spaces, TCP
+ congestion control, etc. behave as specified in the extant standards.
+ Adapting to new standards and experimental algorithm heuristics for
+ improving performance will become much easier once the move to BLOAT
+ has been completed.
+
+1.4. Requirement Levels
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
+
+2. IPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC.
+ IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+ (section 3.) and higher-level application protocols.
+
+ The DTD for this document type can be found in section 7.1.
+
+ The routing of IPoXML can be easily implemented on hosts with an XML
+ parser, as the regular structure lends itself handily to parsing and
+ validation of the document/datagram and then processing the
+ destination address, TTL, and checksum before sending it on to its
+ next-hop.
+
+ The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+ wider deployment of IPv4 and the fact that implementing IPv6 as XML
+ would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy Informational [Page 2]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+ of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
+ formed and include the XMLDecl.
+
+2.1. IP Description
+
+ A number of items have changed (for the better) from the original IP
+ specification. Bit-masks, where present have been converted into
+ human-readable values. IP addresses are listed in their dotted-
+ decimal notation [RFC1123]. Length and checksum values are present
+ as decimal integers.
+
+ To calculate the length and checksum fields of the IP element, a
+ canonicalized form of the element MUST be used. The canonical form
+ SHALL have no whitespace (including newline characters) between
+ elements and only one space character between attributes. There
+ SHALL NOT be a space following the last attribute in an element.
+
+ An iterative method SHOULD be used to calculate checksums, as the
+ length field will vary based on the size of the checksum.
+
+ The payload element bears special attention. Due to the character
+ set restrictions of XML, the payload of IP datagrams (which MAY
+ contain arbitrary data) MUST be encoded for transport. This RFC
+ REQUIRES the contents of the payload to be encoded in the base-64
+ encoding of RFC 2045 [RFC2045], but removes the requirement that the
+ encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 3]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+2.2. Example Datagram
+
+ The following is an example IPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ <ip>
+ <header length="474">
+ <version value="4"/>
+ <tos precedence="Routine" delay="Normal" throughput="Normal"
+ relibility="Normal" reserved="0"/>
+ <total.length value="461"/>
+ <id value="1"/>
+ <flags reserved="0" df="dont" mf="last"/>
+ <offset value="0"/>
+ <ttl value="255"/>
+ <protocol value="6"/>
+ <checksum value="8707"/>
+ <source address="10.0.0.22"/>
+ <destination address="10.0.0.1"/>
+ <options>
+ <end copied="0" class="0" number="0"/>
+ </options>
+ <padding pad="0"/>
+ </header>
+ <payload>
+ </payload>
+ </ip>
+
+3. TCPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+ A number of items have changed from the original TCP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+ To calculate the length and checksum fields of the TCP element, a
+ canonicalized form of the element MUST be used as in section 2.1.
+
+ An iterative method SHOULD be used to calculate checksums as in
+ section 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy Informational [Page 4]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ The TCP offset element was expanded to a maximum of 255 from 16 to
+ allow for the increased size of the header in XML.
+
+ TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ <tcp>
+ <tcp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <sequence number="322622954"/>
+ <acknowledgement number="689715995"/>
+ <offset number=""/>
+ <reserved value="0"/>
+ <control syn="1" ack="1"/>
+ <window size="1"/>
+ <urgent pointer="0"/>
+ <checksum value="2988"/>
+ <tcp.options>
+ <tcp.end kind="0"/>
+ </tcp.options>
+ <padding pad="0"/>
+ </tcp.header>
+ <payload>
+ </payload>
+ </tcp>
+
+4. UDPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+ A number of items have changed from the original UDP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+
+
+
+
+
+
+Kennedy Informational [Page 5]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ To calculate the length and checksum fields of the UDP element, a
+ canonicalized form of the element MUST be used as in section 2.1. An
+ iterative method SHOULD be used to calculate checksums as in section
+ 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+ UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ <udp>
+ <udp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <udp.length value="143"/>
+ <checksum value="2988"/>
+ </udp.header>
+ <payload>
+ </payload>
+ </udp>
+
+5. Network Transport
+
+ This document provides for the transmission of BLOAT datagrams over
+ two common families of physical layer transport. Future RFCs will
+ address additional transports as routing vendors catch up to the
+ specification, and we begin to see BLOAT routed across the Internet
+ backbone.
+
+5.1. Ethernet
+
+ BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+ exception that the type field of the Ethernet frame MUST contain the
+ value 0xBEEF. The first 5 octets of the Ethernet frame payload will
+ be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+ BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+ that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy Informational [Page 6]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+6. Gatewaying over IP
+
+ In order to facilitate the gradual introduction of BLOAT into the
+ public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+ gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+ The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+ Network DTD (7.1.)
+
+ The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+ [XML]) although it is understood that most IPoXML implementations
+ will not need to pull down the DTD, as it will normally be embedded
+ in the implementation, and presents something of a catch-22 if you
+ need to load part of your network protocol over the network.
+
+7.1. IPoXML DTD
+
+ <!--
+ DTD for IP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ -->
+ <!--
+ DTD data types:
+
+ Digits [0..9]+
+
+ Precedence "NetworkControl | InternetworkControl |
+ CRITIC | FlashOverride | Flash | Immediate |
+ Priority | Routine"
+
+ IP4Addr "dotted-decimal" notation of [RFC1123]
+
+ Class [0..3]
+
+ Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
+ Restricted | Secret | Top Secret | Reserved"
+
+ Compartments [0..65535]
+
+ Handling [0..65535]
+
+ TCC [0..16777216]
+
+ -->
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ENTITY % Digits "CDATA">
+ <!ENTITY % Precedence "CDATA">
+ <!ENTITY % IP4Addr "CDATA">
+ <!ENTITY % Class "CDATA">
+ <!ENTITY % Sec "CDATA">
+ <!ENTITY % Compartments "CDATA">
+ <!ENTITY % Handling "CDATA">
+ <!ENTITY % TCC "CDATA">
+
+ <!ELEMENT ip (header, payload)>
+
+ <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+ protocol, checksum, source, destination, options,
+ padding)>
+ <!-- length of header in 32-bit words -->
+ <!ATTLIST header
+ length %Digits; #REQUIRED>
+
+ <!ELEMENT version EMPTY>
+ <!-- ip version. SHOULD be "4" -->
+ <!ATTLIST version
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT tos EMPTY>
+ <!ATTLIST tos
+ precedence %Precedence; #REQUIRED
+ delay (normal | low) #REQUIRED
+ throughput (normal | high) #REQUIRED
+ relibility (normal | high) #REQUIRED
+ reserved CDATA #FIXED "0">
+
+ <!ELEMENT total.length EMPTY>
+ <!--
+ total length of datagram (header and payload) in octets, MUST be
+ less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+ ethernets).
+ -->
+ <!ATTLIST total.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT id EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST id
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT flags EMPTY>
+ <!-- df = don't fragment, mf = more fragments -->
+ <!ATTLIST flags
+
+
+
+Kennedy Informational [Page 8]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ reserved CDATA #FIXED "0"
+ df (may|dont) #REQUIRED
+ mf (last|more) #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+ <!ATTLIST offset
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT ttl EMPTY>
+ <!-- 0 <= ttl <= 255 -->
+ <!ATTLIST ttl
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT protocol EMPTY>
+ <!-- 0 <= protocol <= 255 (per IANA) -->
+ <!ATTLIST protocol
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT checksum EMPTY>
+ <!-- 0 <= checksum <= 65535 (over header only) -->
+ <!ATTLIST checksum
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT source EMPTY>
+ <!ATTLIST source
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT destination EMPTY>
+ <!ATTLIST destination
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT options ( end | noop | security | loose | strict | record
+ | stream | timestamp )*>
+
+ <!ELEMENT end EMPTY>
+ <!ATTLIST end
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "0">
+
+ <!ELEMENT noop EMPTY>
+ <!ATTLIST noop
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "1">
+
+ <!ELEMENT security EMPTY>
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST security
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "2"
+ length CDATA #FIXED "11"
+ security %Sec; #REQUIRED
+ compartments %Compartments; #REQUIRED
+ handling %Handling; #REQUIRED
+ tcc %TCC; #REQUIRED>
+ <!ELEMENT loose (hop)+>
+ <!ATTLIST loose
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "3"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT hop EMPTY>
+ <!ATTLIST hop
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT strict (hop)+>
+ <!ATTLIST strict
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "9"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT record (hop)+>
+ <!ATTLIST record
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "7"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT stream EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST stream
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "8"
+ length CDATA #FIXED "4"
+ id %Digits; #REQUIRED>
+
+ <!ELEMENT timestamp (tstamp)+>
+ <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST timestamp
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "2"
+ number CDATA #FIXED "4"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED
+ oflw %Digits; #REQUIRED
+ flag (0 | 1 | 3) #REQUIRED>
+
+ <!ELEMENT tstamp EMPTY>
+ <!ATTLIST tstamp
+ time %Digits; #REQUIRED
+ address %IP4Addr; #IMPLIED>
+ <!--
+ padding to bring header to 32-bit boundary.
+ pad MUST be "0"*
+ -->
+ <!ELEMENT padding EMPTY>
+ <!ATTLIST padding
+ pad CDATA #REQUIRED>
+
+ <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+ by section 2.1 of this RFC -->
+ <!ELEMENT payload (CDATA)>
+
+7.2. TCPoXML DTD
+
+ <!--
+ DTD for TCP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ -->
+
+ <!-- the pseudoheader is only included for checksum calculations -->
+ <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+ <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+ reserved, control, window, checksum, urgent,
+ tcp.options, padding)>
+
+ <!ELEMENT src EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+ <!ATTLIST src
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT dest EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST dest
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT sequence EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST sequence
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT acknowledgement EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST acknowledgement
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= number <= 255 -->
+ <!ATTLIST offset
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT reserved EMPTY>
+ <!ATTLIST reserved
+ value CDATA #FIXED "0">
+
+ <!ELEMENT control EMPTY>
+ <!ATTLIST control
+ urg (0|1) #IMPLIED
+ ack (0|1) #IMPLIED
+ psh (0|1) #IMPLIED
+ rst (0|1) #IMPLIED
+ syn (0|1) #IMPLIED
+ fin (0|1) #IMPLIED>
+
+ <!ELEMENT window EMPTY>
+ <!-- 0 <= size <= 65,535 -->
+ <!ATTLIST window
+ size %Digits; #REQUIRED>
+
+ <!--
+ checksum as in ip, but with
+ the following pseudo-header added into the tcp element:
+ -->
+ <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+ tcp.length)>
+
+ <!--
+ tcp header + data length in octets. does not include the size of
+
+ the pseudoheader.
+ -->
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ELEMENT tcp.length EMPTY>
+ <!ATTLIST tcp.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT urgent EMPTY>
+ <!-- 0 <= pointer <= 65,535 -->
+ <!ATTLIST urgent
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+ <!ELEMENT tcp.end EMPTY>
+ <!ATTLIST tcp.end
+ kind CDATA #FIXED "0">
+
+ <!ELEMENT tcp.noop EMPTY>
+ <!ATTLIST tcp.noop
+ kind CDATA #FIXED "1">
+
+ <!ELEMENT tcp.mss EMPTY>
+ <!ATTLIST tcp.mss
+ kind CDATA #FIXED "2"
+ length CDATA #FIXED "4"
+ size %Digits; #REQUIRED>
+
+7.3. UDPoXML DTD
+
+ <!--
+ DTD for UDP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ -->
+
+ <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+ <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+ <!ELEMENT udp.pseudoheader (source, destination, protocol,
+ udp.length)>
+
+ <!--
+ udp header + data length in octets. does not include the size of
+ the pseudoheader.
+ -->
+ <!ELEMENT udp.length EMPTY>
+ <!ATTLIST udp.length
+ value %Digits; #REQUIRED>
+
+
+
+Kennedy Informational [Page 13]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+8. Security Considerations
+
+ XML, as a subset of SGML, has the same security considerations as
+ specified in SGML Media Types [RFC1874]. Security considerations
+ that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+ not attempt to correct for issues not related to message format.
+
+9. References
+
+ [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
+ February 2002. (Work in Progress)
+
+ [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
+ 793, September 1981.
+
+ [RFC894] Hornig, C., "Standard for the Transmission of IP
+ Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+ [RFC1042] Postel, J. and J. Reynolds, "Standard for the
+ Transmission of IP Datagrams Over IEEE 802 Networks", STD
+ 43, RFC 1042, February 1988.
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts -
+ Application and Support", RFC 1123, October 1989.
+
+ [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
+ 1995.
+
+ [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
+ October 1996.
+
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy Informational [Page 14]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
+ RFC 3080, March 2001.
+
+ [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+ Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+ "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+ Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+ Markup Language (XML)" World Wide Web Consortium
+ Recommendation REC- xml-19980210.
+ http://www.w3.org/TR/1998/REC-xml-19980210
+
+10. Author's Address
+
+ Hugh Kennedy
+ Mimezine
+ 1060 West Addison
+ Chicago, IL 60613
+ USA
+
+ EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 15]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 16]
+
+
+
+
+
+
+
+Network Working Group H. Kennedy
+Request for Comments: 3252 Mimezine
+Category: Informational 1 April 2002
+
+
+ Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document defines a reformulation of IP and two transport layer
+ protocols (TCP and UDP) as XML applications.
+
+1. Introduction
+
+1.1. Overview
+
+ This document describes the Binary Lexical Octet Ad-hoc Transport
+ (BLOAT): a reformulation of a widely-deployed network-layer protocol
+ (IP [RFC791]), and two associated transport layer protocols (TCP
+ [RFC793] and UDP [RFC768]) as XML [XML] applications. It also
+ describes methods for transporting BLOAT over Ethernet and IEEE 802
+ networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+ across the public Internet.
+
+1.2. Motivation
+
+ The wild popularity of XML as a basis for application-level protocols
+ such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+ Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+ investigation into the possibility of extending the use of XML in the
+ protocol stack. Using XML at both the transport and network layer in
+ addition to the application layer would provide for an amazing amount
+ of power and flexibility while removing dependencies on proprietary
+ and hard-to-understand binary protocols. This protocol unification
+ would also allow applications to use a single XML parser for all
+ aspects of their operation, eliminating developer time spent figuring
+ out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy Informational [Page 1]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ parsing to the XML toolset. The use of XML also mitigates concerns
+ over "network vs. host" byte ordering which is at the root of many
+ network application bugs.
+
+1.3. Relation to Existing Protocols
+
+ The reformulations specified in this RFC follow as closely as
+ possible the spirit of the RFCs on which they are based, and so MAY
+ contain elements or attributes that would not be needed in a pure
+ reworking (e.g. length attributes, which are implicit in XML.)
+
+ The layering of network and transport protocols are maintained in
+ this RFC despite the optimizations that could be made if the line
+ were somewhat blurred (i.e. merging TCP and IP into a single, larger
+ element in the DTD) in order to foster future use of this protocol as
+ a basis for reformulating other protocols (such as ICMP.)
+
+ Other than the encoding, the behavioral aspects of each of the
+ existing protocols remain unchanged. Routing, address spaces, TCP
+ congestion control, etc. behave as specified in the extant standards.
+ Adapting to new standards and experimental algorithm heuristics for
+ improving performance will become much easier once the move to BLOAT
+ has been completed.
+
+1.4. Requirement Levels
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
+
+2. IPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC.
+ IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+ (section 3.) and higher-level application protocols.
+
+ The DTD for this document type can be found in section 7.1.
+
+ The routing of IPoXML can be easily implemented on hosts with an XML
+ parser, as the regular structure lends itself handily to parsing and
+ validation of the document/datagram and then processing the
+ destination address, TTL, and checksum before sending it on to its
+ next-hop.
+
+ The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+ wider deployment of IPv4 and the fact that implementing IPv6 as XML
+ would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy Informational [Page 2]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+ of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
+ formed and include the XMLDecl.
+
+2.1. IP Description
+
+ A number of items have changed (for the better) from the original IP
+ specification. Bit-masks, where present have been converted into
+ human-readable values. IP addresses are listed in their dotted-
+ decimal notation [RFC1123]. Length and checksum values are present
+ as decimal integers.
+
+ To calculate the length and checksum fields of the IP element, a
+ canonicalized form of the element MUST be used. The canonical form
+ SHALL have no whitespace (including newline characters) between
+ elements and only one space character between attributes. There
+ SHALL NOT be a space following the last attribute in an element.
+
+ An iterative method SHOULD be used to calculate checksums, as the
+ length field will vary based on the size of the checksum.
+
+ The payload element bears special attention. Due to the character
+ set restrictions of XML, the payload of IP datagrams (which MAY
+ contain arbitrary data) MUST be encoded for transport. This RFC
+ REQUIRES the contents of the payload to be encoded in the base-64
+ encoding of RFC 2045 [RFC2045], but removes the requirement that the
+ encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 3]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+2.2. Example Datagram
+
+ The following is an example IPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ <ip>
+ <header length="474">
+ <version value="4"/>
+ <tos precedence="Routine" delay="Normal" throughput="Normal"
+ relibility="Normal" reserved="0"/>
+ <total.length value="461"/>
+ <id value="1"/>
+ <flags reserved="0" df="dont" mf="last"/>
+ <offset value="0"/>
+ <ttl value="255"/>
+ <protocol value="6"/>
+ <checksum value="8707"/>
+ <source address="10.0.0.22"/>
+ <destination address="10.0.0.1"/>
+ <options>
+ <end copied="0" class="0" number="0"/>
+ </options>
+ <padding pad="0"/>
+ </header>
+ <payload>
+ </payload>
+ </ip>
+
+3. TCPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+ A number of items have changed from the original TCP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+ To calculate the length and checksum fields of the TCP element, a
+ canonicalized form of the element MUST be used as in section 2.1.
+
+ An iterative method SHOULD be used to calculate checksums as in
+ section 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy Informational [Page 4]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ The TCP offset element was expanded to a maximum of 255 from 16 to
+ allow for the increased size of the header in XML.
+
+ TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ <tcp>
+ <tcp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <sequence number="322622954"/>
+ <acknowledgement number="689715995"/>
+ <offset number=""/>
+ <reserved value="0"/>
+ <control syn="1" ack="1"/>
+ <window size="1"/>
+ <urgent pointer="0"/>
+ <checksum value="2988"/>
+ <tcp.options>
+ <tcp.end kind="0"/>
+ </tcp.options>
+ <padding pad="0"/>
+ </tcp.header>
+ <payload>
+ </payload>
+ </tcp>
+
+4. UDPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+ A number of items have changed from the original UDP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+
+
+
+
+
+
+Kennedy Informational [Page 5]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ To calculate the length and checksum fields of the UDP element, a
+ canonicalized form of the element MUST be used as in section 2.1. An
+ iterative method SHOULD be used to calculate checksums as in section
+ 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+ UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ <udp>
+ <udp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <udp.length value="143"/>
+ <checksum value="2988"/>
+ </udp.header>
+ <payload>
+ </payload>
+ </udp>
+
+5. Network Transport
+
+ This document provides for the transmission of BLOAT datagrams over
+ two common families of physical layer transport. Future RFCs will
+ address additional transports as routing vendors catch up to the
+ specification, and we begin to see BLOAT routed across the Internet
+ backbone.
+
+5.1. Ethernet
+
+ BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+ exception that the type field of the Ethernet frame MUST contain the
+ value 0xBEEF. The first 5 octets of the Ethernet frame payload will
+ be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+ BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+ that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy Informational [Page 6]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+6. Gatewaying over IP
+
+ In order to facilitate the gradual introduction of BLOAT into the
+ public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+ gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+ The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+ Network DTD (7.1.)
+
+ The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+ [XML]) although it is understood that most IPoXML implementations
+ will not need to pull down the DTD, as it will normally be embedded
+ in the implementation, and presents something of a catch-22 if you
+ need to load part of your network protocol over the network.
+
+7.1. IPoXML DTD
+
+ <!--
+ DTD for IP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ -->
+ <!--
+ DTD data types:
+
+ Digits [0..9]+
+
+ Precedence "NetworkControl | InternetworkControl |
+ CRITIC | FlashOverride | Flash | Immediate |
+ Priority | Routine"
+
+ IP4Addr "dotted-decimal" notation of [RFC1123]
+
+ Class [0..3]
+
+ Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
+ Restricted | Secret | Top Secret | Reserved"
+
+ Compartments [0..65535]
+
+ Handling [0..65535]
+
+ TCC [0..16777216]
+
+ -->
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ENTITY % Digits "CDATA">
+ <!ENTITY % Precedence "CDATA">
+ <!ENTITY % IP4Addr "CDATA">
+ <!ENTITY % Class "CDATA">
+ <!ENTITY % Sec "CDATA">
+ <!ENTITY % Compartments "CDATA">
+ <!ENTITY % Handling "CDATA">
+ <!ENTITY % TCC "CDATA">
+
+ <!ELEMENT ip (header, payload)>
+
+ <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+ protocol, checksum, source, destination, options,
+ padding)>
+ <!-- length of header in 32-bit words -->
+ <!ATTLIST header
+ length %Digits; #REQUIRED>
+
+ <!ELEMENT version EMPTY>
+ <!-- ip version. SHOULD be "4" -->
+ <!ATTLIST version
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT tos EMPTY>
+ <!ATTLIST tos
+ precedence %Precedence; #REQUIRED
+ delay (normal | low) #REQUIRED
+ throughput (normal | high) #REQUIRED
+ relibility (normal | high) #REQUIRED
+ reserved CDATA #FIXED "0">
+
+ <!ELEMENT total.length EMPTY>
+ <!--
+ total length of datagram (header and payload) in octets, MUST be
+ less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+ ethernets).
+ -->
+ <!ATTLIST total.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT id EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST id
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT flags EMPTY>
+ <!-- df = don't fragment, mf = more fragments -->
+ <!ATTLIST flags
+
+
+
+Kennedy Informational [Page 8]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ reserved CDATA #FIXED "0"
+ df (may|dont) #REQUIRED
+ mf (last|more) #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+ <!ATTLIST offset
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT ttl EMPTY>
+ <!-- 0 <= ttl <= 255 -->
+ <!ATTLIST ttl
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT protocol EMPTY>
+ <!-- 0 <= protocol <= 255 (per IANA) -->
+ <!ATTLIST protocol
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT checksum EMPTY>
+ <!-- 0 <= checksum <= 65535 (over header only) -->
+ <!ATTLIST checksum
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT source EMPTY>
+ <!ATTLIST source
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT destination EMPTY>
+ <!ATTLIST destination
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT options ( end | noop | security | loose | strict | record
+ | stream | timestamp )*>
+
+ <!ELEMENT end EMPTY>
+ <!ATTLIST end
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "0">
+
+ <!ELEMENT noop EMPTY>
+ <!ATTLIST noop
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "1">
+
+ <!ELEMENT security EMPTY>
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST security
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "2"
+ length CDATA #FIXED "11"
+ security %Sec; #REQUIRED
+ compartments %Compartments; #REQUIRED
+ handling %Handling; #REQUIRED
+ tcc %TCC; #REQUIRED>
+ <!ELEMENT loose (hop)+>
+ <!ATTLIST loose
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "3"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT hop EMPTY>
+ <!ATTLIST hop
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT strict (hop)+>
+ <!ATTLIST strict
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "9"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT record (hop)+>
+ <!ATTLIST record
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "7"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT stream EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST stream
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "8"
+ length CDATA #FIXED "4"
+ id %Digits; #REQUIRED>
+
+ <!ELEMENT timestamp (tstamp)+>
+ <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST timestamp
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "2"
+ number CDATA #FIXED "4"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED
+ oflw %Digits; #REQUIRED
+ flag (0 | 1 | 3) #REQUIRED>
+
+ <!ELEMENT tstamp EMPTY>
+ <!ATTLIST tstamp
+ time %Digits; #REQUIRED
+ address %IP4Addr; #IMPLIED>
+ <!--
+ padding to bring header to 32-bit boundary.
+ pad MUST be "0"*
+ -->
+ <!ELEMENT padding EMPTY>
+ <!ATTLIST padding
+ pad CDATA #REQUIRED>
+
+ <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+ by section 2.1 of this RFC -->
+ <!ELEMENT payload (CDATA)>
+
+7.2. TCPoXML DTD
+
+ <!--
+ DTD for TCP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ -->
+
+ <!-- the pseudoheader is only included for checksum calculations -->
+ <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+ <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+ reserved, control, window, checksum, urgent,
+ tcp.options, padding)>
+
+ <!ELEMENT src EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+ <!ATTLIST src
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT dest EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST dest
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT sequence EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST sequence
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT acknowledgement EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST acknowledgement
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= number <= 255 -->
+ <!ATTLIST offset
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT reserved EMPTY>
+ <!ATTLIST reserved
+ value CDATA #FIXED "0">
+
+ <!ELEMENT control EMPTY>
+ <!ATTLIST control
+ urg (0|1) #IMPLIED
+ ack (0|1) #IMPLIED
+ psh (0|1) #IMPLIED
+ rst (0|1) #IMPLIED
+ syn (0|1) #IMPLIED
+ fin (0|1) #IMPLIED>
+
+ <!ELEMENT window EMPTY>
+ <!-- 0 <= size <= 65,535 -->
+ <!ATTLIST window
+ size %Digits; #REQUIRED>
+
+ <!--
+ checksum as in ip, but with
+ the following pseudo-header added into the tcp element:
+ -->
+ <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+ tcp.length)>
+
+ <!--
+ tcp header + data length in octets. does not include the size of
+
+ the pseudoheader.
+ -->
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ELEMENT tcp.length EMPTY>
+ <!ATTLIST tcp.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT urgent EMPTY>
+ <!-- 0 <= pointer <= 65,535 -->
+ <!ATTLIST urgent
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+ <!ELEMENT tcp.end EMPTY>
+ <!ATTLIST tcp.end
+ kind CDATA #FIXED "0">
+
+ <!ELEMENT tcp.noop EMPTY>
+ <!ATTLIST tcp.noop
+ kind CDATA #FIXED "1">
+
+ <!ELEMENT tcp.mss EMPTY>
+ <!ATTLIST tcp.mss
+ kind CDATA #FIXED "2"
+ length CDATA #FIXED "4"
+ size %Digits; #REQUIRED>
+
+7.3. UDPoXML DTD
+
+ <!--
+ DTD for UDP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ -->
+
+ <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+ <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+ <!ELEMENT udp.pseudoheader (source, destination, protocol,
+ udp.length)>
+
+ <!--
+ udp header + data length in octets. does not include the size of
+ the pseudoheader.
+ -->
+ <!ELEMENT udp.length EMPTY>
+ <!ATTLIST udp.length
+ value %Digits; #REQUIRED>
+
+
+
+Kennedy Informational [Page 13]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+8. Security Considerations
+
+ XML, as a subset of SGML, has the same security considerations as
+ specified in SGML Media Types [RFC1874]. Security considerations
+ that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+ not attempt to correct for issues not related to message format.
+
+9. References
+
+ [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
+ February 2002. (Work in Progress)
+
+ [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
+ 793, September 1981.
+
+ [RFC894] Hornig, C., "Standard for the Transmission of IP
+ Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+ [RFC1042] Postel, J. and J. Reynolds, "Standard for the
+ Transmission of IP Datagrams Over IEEE 802 Networks", STD
+ 43, RFC 1042, February 1988.
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts -
+ Application and Support", RFC 1123, October 1989.
+
+ [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
+ 1995.
+
+ [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
+ October 1996.
+
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy Informational [Page 14]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
+ RFC 3080, March 2001.
+
+ [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+ Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+ "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+ Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+ Markup Language (XML)" World Wide Web Consortium
+ Recommendation REC- xml-19980210.
+ http://www.w3.org/TR/1998/REC-xml-19980210
+
+10. Author's Address
+
+ Hugh Kennedy
+ Mimezine
+ 1060 West Addison
+ Chicago, IL 60613
+ USA
+
+ EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 15]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 16]
+
+
+
+
+
+
+
+Network Working Group H. Kennedy
+Request for Comments: 3252 Mimezine
+Category: Informational 1 April 2002
+
+
+ Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document defines a reformulation of IP and two transport layer
+ protocols (TCP and UDP) as XML applications.
+
+1. Introduction
+
+1.1. Overview
+
+ This document describes the Binary Lexical Octet Ad-hoc Transport
+ (BLOAT): a reformulation of a widely-deployed network-layer protocol
+ (IP [RFC791]), and two associated transport layer protocols (TCP
+ [RFC793] and UDP [RFC768]) as XML [XML] applications. It also
+ describes methods for transporting BLOAT over Ethernet and IEEE 802
+ networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+ across the public Internet.
+
+1.2. Motivation
+
+ The wild popularity of XML as a basis for application-level protocols
+ such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+ Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+ investigation into the possibility of extending the use of XML in the
+ protocol stack. Using XML at both the transport and network layer in
+ addition to the application layer would provide for an amazing amount
+ of power and flexibility while removing dependencies on proprietary
+ and hard-to-understand binary protocols. This protocol unification
+ would also allow applications to use a single XML parser for all
+ aspects of their operation, eliminating developer time spent figuring
+ out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy Informational [Page 1]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ parsing to the XML toolset. The use of XML also mitigates concerns
+ over "network vs. host" byte ordering which is at the root of many
+ network application bugs.
+
+1.3. Relation to Existing Protocols
+
+ The reformulations specified in this RFC follow as closely as
+ possible the spirit of the RFCs on which they are based, and so MAY
+ contain elements or attributes that would not be needed in a pure
+ reworking (e.g. length attributes, which are implicit in XML.)
+
+ The layering of network and transport protocols are maintained in
+ this RFC despite the optimizations that could be made if the line
+ were somewhat blurred (i.e. merging TCP and IP into a single, larger
+ element in the DTD) in order to foster future use of this protocol as
+ a basis for reformulating other protocols (such as ICMP.)
+
+ Other than the encoding, the behavioral aspects of each of the
+ existing protocols remain unchanged. Routing, address spaces, TCP
+ congestion control, etc. behave as specified in the extant standards.
+ Adapting to new standards and experimental algorithm heuristics for
+ improving performance will become much easier once the move to BLOAT
+ has been completed.
+
+1.4. Requirement Levels
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
+
+2. IPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC.
+ IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+ (section 3.) and higher-level application protocols.
+
+ The DTD for this document type can be found in section 7.1.
+
+ The routing of IPoXML can be easily implemented on hosts with an XML
+ parser, as the regular structure lends itself handily to parsing and
+ validation of the document/datagram and then processing the
+ destination address, TTL, and checksum before sending it on to its
+ next-hop.
+
+ The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+ wider deployment of IPv4 and the fact that implementing IPv6 as XML
+ would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy Informational [Page 2]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+ of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
+ formed and include the XMLDecl.
+
+2.1. IP Description
+
+ A number of items have changed (for the better) from the original IP
+ specification. Bit-masks, where present have been converted into
+ human-readable values. IP addresses are listed in their dotted-
+ decimal notation [RFC1123]. Length and checksum values are present
+ as decimal integers.
+
+ To calculate the length and checksum fields of the IP element, a
+ canonicalized form of the element MUST be used. The canonical form
+ SHALL have no whitespace (including newline characters) between
+ elements and only one space character between attributes. There
+ SHALL NOT be a space following the last attribute in an element.
+
+ An iterative method SHOULD be used to calculate checksums, as the
+ length field will vary based on the size of the checksum.
+
+ The payload element bears special attention. Due to the character
+ set restrictions of XML, the payload of IP datagrams (which MAY
+ contain arbitrary data) MUST be encoded for transport. This RFC
+ REQUIRES the contents of the payload to be encoded in the base-64
+ encoding of RFC 2045 [RFC2045], but removes the requirement that the
+ encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 3]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+2.2. Example Datagram
+
+ The following is an example IPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ <ip>
+ <header length="474">
+ <version value="4"/>
+ <tos precedence="Routine" delay="Normal" throughput="Normal"
+ relibility="Normal" reserved="0"/>
+ <total.length value="461"/>
+ <id value="1"/>
+ <flags reserved="0" df="dont" mf="last"/>
+ <offset value="0"/>
+ <ttl value="255"/>
+ <protocol value="6"/>
+ <checksum value="8707"/>
+ <source address="10.0.0.22"/>
+ <destination address="10.0.0.1"/>
+ <options>
+ <end copied="0" class="0" number="0"/>
+ </options>
+ <padding pad="0"/>
+ </header>
+ <payload>
+ </payload>
+ </ip>
+
+3. TCPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+ A number of items have changed from the original TCP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+ To calculate the length and checksum fields of the TCP element, a
+ canonicalized form of the element MUST be used as in section 2.1.
+
+ An iterative method SHOULD be used to calculate checksums as in
+ section 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy Informational [Page 4]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ The TCP offset element was expanded to a maximum of 255 from 16 to
+ allow for the increased size of the header in XML.
+
+ TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ <tcp>
+ <tcp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <sequence number="322622954"/>
+ <acknowledgement number="689715995"/>
+ <offset number=""/>
+ <reserved value="0"/>
+ <control syn="1" ack="1"/>
+ <window size="1"/>
+ <urgent pointer="0"/>
+ <checksum value="2988"/>
+ <tcp.options>
+ <tcp.end kind="0"/>
+ </tcp.options>
+ <padding pad="0"/>
+ </tcp.header>
+ <payload>
+ </payload>
+ </tcp>
+
+4. UDPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+ A number of items have changed from the original UDP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+
+
+
+
+
+
+Kennedy Informational [Page 5]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ To calculate the length and checksum fields of the UDP element, a
+ canonicalized form of the element MUST be used as in section 2.1. An
+ iterative method SHOULD be used to calculate checksums as in section
+ 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+ UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ <udp>
+ <udp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <udp.length value="143"/>
+ <checksum value="2988"/>
+ </udp.header>
+ <payload>
+ </payload>
+ </udp>
+
+5. Network Transport
+
+ This document provides for the transmission of BLOAT datagrams over
+ two common families of physical layer transport. Future RFCs will
+ address additional transports as routing vendors catch up to the
+ specification, and we begin to see BLOAT routed across the Internet
+ backbone.
+
+5.1. Ethernet
+
+ BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+ exception that the type field of the Ethernet frame MUST contain the
+ value 0xBEEF. The first 5 octets of the Ethernet frame payload will
+ be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+ BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+ that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy Informational [Page 6]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+6. Gatewaying over IP
+
+ In order to facilitate the gradual introduction of BLOAT into the
+ public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+ gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+ The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+ Network DTD (7.1.)
+
+ The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+ [XML]) although it is understood that most IPoXML implementations
+ will not need to pull down the DTD, as it will normally be embedded
+ in the implementation, and presents something of a catch-22 if you
+ need to load part of your network protocol over the network.
+
+7.1. IPoXML DTD
+
+ <!--
+ DTD for IP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ -->
+ <!--
+ DTD data types:
+
+ Digits [0..9]+
+
+ Precedence "NetworkControl | InternetworkControl |
+ CRITIC | FlashOverride | Flash | Immediate |
+ Priority | Routine"
+
+ IP4Addr "dotted-decimal" notation of [RFC1123]
+
+ Class [0..3]
+
+ Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
+ Restricted | Secret | Top Secret | Reserved"
+
+ Compartments [0..65535]
+
+ Handling [0..65535]
+
+ TCC [0..16777216]
+
+ -->
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ENTITY % Digits "CDATA">
+ <!ENTITY % Precedence "CDATA">
+ <!ENTITY % IP4Addr "CDATA">
+ <!ENTITY % Class "CDATA">
+ <!ENTITY % Sec "CDATA">
+ <!ENTITY % Compartments "CDATA">
+ <!ENTITY % Handling "CDATA">
+ <!ENTITY % TCC "CDATA">
+
+ <!ELEMENT ip (header, payload)>
+
+ <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+ protocol, checksum, source, destination, options,
+ padding)>
+ <!-- length of header in 32-bit words -->
+ <!ATTLIST header
+ length %Digits; #REQUIRED>
+
+ <!ELEMENT version EMPTY>
+ <!-- ip version. SHOULD be "4" -->
+ <!ATTLIST version
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT tos EMPTY>
+ <!ATTLIST tos
+ precedence %Precedence; #REQUIRED
+ delay (normal | low) #REQUIRED
+ throughput (normal | high) #REQUIRED
+ relibility (normal | high) #REQUIRED
+ reserved CDATA #FIXED "0">
+
+ <!ELEMENT total.length EMPTY>
+ <!--
+ total length of datagram (header and payload) in octets, MUST be
+ less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+ ethernets).
+ -->
+ <!ATTLIST total.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT id EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST id
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT flags EMPTY>
+ <!-- df = don't fragment, mf = more fragments -->
+ <!ATTLIST flags
+
+
+
+Kennedy Informational [Page 8]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ reserved CDATA #FIXED "0"
+ df (may|dont) #REQUIRED
+ mf (last|more) #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+ <!ATTLIST offset
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT ttl EMPTY>
+ <!-- 0 <= ttl <= 255 -->
+ <!ATTLIST ttl
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT protocol EMPTY>
+ <!-- 0 <= protocol <= 255 (per IANA) -->
+ <!ATTLIST protocol
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT checksum EMPTY>
+ <!-- 0 <= checksum <= 65535 (over header only) -->
+ <!ATTLIST checksum
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT source EMPTY>
+ <!ATTLIST source
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT destination EMPTY>
+ <!ATTLIST destination
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT options ( end | noop | security | loose | strict | record
+ | stream | timestamp )*>
+
+ <!ELEMENT end EMPTY>
+ <!ATTLIST end
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "0">
+
+ <!ELEMENT noop EMPTY>
+ <!ATTLIST noop
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "1">
+
+ <!ELEMENT security EMPTY>
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST security
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "2"
+ length CDATA #FIXED "11"
+ security %Sec; #REQUIRED
+ compartments %Compartments; #REQUIRED
+ handling %Handling; #REQUIRED
+ tcc %TCC; #REQUIRED>
+ <!ELEMENT loose (hop)+>
+ <!ATTLIST loose
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "3"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT hop EMPTY>
+ <!ATTLIST hop
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT strict (hop)+>
+ <!ATTLIST strict
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "9"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT record (hop)+>
+ <!ATTLIST record
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "7"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT stream EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST stream
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "8"
+ length CDATA #FIXED "4"
+ id %Digits; #REQUIRED>
+
+ <!ELEMENT timestamp (tstamp)+>
+ <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST timestamp
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "2"
+ number CDATA #FIXED "4"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED
+ oflw %Digits; #REQUIRED
+ flag (0 | 1 | 3) #REQUIRED>
+
+ <!ELEMENT tstamp EMPTY>
+ <!ATTLIST tstamp
+ time %Digits; #REQUIRED
+ address %IP4Addr; #IMPLIED>
+ <!--
+ padding to bring header to 32-bit boundary.
+ pad MUST be "0"*
+ -->
+ <!ELEMENT padding EMPTY>
+ <!ATTLIST padding
+ pad CDATA #REQUIRED>
+
+ <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+ by section 2.1 of this RFC -->
+ <!ELEMENT payload (CDATA)>
+
+7.2. TCPoXML DTD
+
+ <!--
+ DTD for TCP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ -->
+
+ <!-- the pseudoheader is only included for checksum calculations -->
+ <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+ <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+ reserved, control, window, checksum, urgent,
+ tcp.options, padding)>
+
+ <!ELEMENT src EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+ <!ATTLIST src
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT dest EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST dest
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT sequence EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST sequence
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT acknowledgement EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST acknowledgement
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= number <= 255 -->
+ <!ATTLIST offset
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT reserved EMPTY>
+ <!ATTLIST reserved
+ value CDATA #FIXED "0">
+
+ <!ELEMENT control EMPTY>
+ <!ATTLIST control
+ urg (0|1) #IMPLIED
+ ack (0|1) #IMPLIED
+ psh (0|1) #IMPLIED
+ rst (0|1) #IMPLIED
+ syn (0|1) #IMPLIED
+ fin (0|1) #IMPLIED>
+
+ <!ELEMENT window EMPTY>
+ <!-- 0 <= size <= 65,535 -->
+ <!ATTLIST window
+ size %Digits; #REQUIRED>
+
+ <!--
+ checksum as in ip, but with
+ the following pseudo-header added into the tcp element:
+ -->
+ <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+ tcp.length)>
+
+ <!--
+ tcp header + data length in octets. does not include the size of
+
+ the pseudoheader.
+ -->
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ELEMENT tcp.length EMPTY>
+ <!ATTLIST tcp.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT urgent EMPTY>
+ <!-- 0 <= pointer <= 65,535 -->
+ <!ATTLIST urgent
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+ <!ELEMENT tcp.end EMPTY>
+ <!ATTLIST tcp.end
+ kind CDATA #FIXED "0">
+
+ <!ELEMENT tcp.noop EMPTY>
+ <!ATTLIST tcp.noop
+ kind CDATA #FIXED "1">
+
+ <!ELEMENT tcp.mss EMPTY>
+ <!ATTLIST tcp.mss
+ kind CDATA #FIXED "2"
+ length CDATA #FIXED "4"
+ size %Digits; #REQUIRED>
+
+7.3. UDPoXML DTD
+
+ <!--
+ DTD for UDP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ -->
+
+ <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+ <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+ <!ELEMENT udp.pseudoheader (source, destination, protocol,
+ udp.length)>
+
+ <!--
+ udp header + data length in octets. does not include the size of
+ the pseudoheader.
+ -->
+ <!ELEMENT udp.length EMPTY>
+ <!ATTLIST udp.length
+ value %Digits; #REQUIRED>
+
+
+
+Kennedy Informational [Page 13]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+8. Security Considerations
+
+ XML, as a subset of SGML, has the same security considerations as
+ specified in SGML Media Types [RFC1874]. Security considerations
+ that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+ not attempt to correct for issues not related to message format.
+
+9. References
+
+ [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
+ February 2002. (Work in Progress)
+
+ [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
+ 793, September 1981.
+
+ [RFC894] Hornig, C., "Standard for the Transmission of IP
+ Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+ [RFC1042] Postel, J. and J. Reynolds, "Standard for the
+ Transmission of IP Datagrams Over IEEE 802 Networks", STD
+ 43, RFC 1042, February 1988.
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts -
+ Application and Support", RFC 1123, October 1989.
+
+ [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
+ 1995.
+
+ [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
+ October 1996.
+
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy Informational [Page 14]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
+ RFC 3080, March 2001.
+
+ [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+ Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+ "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+ Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+ Markup Language (XML)" World Wide Web Consortium
+ Recommendation REC- xml-19980210.
+ http://www.w3.org/TR/1998/REC-xml-19980210
+
+10. Author's Address
+
+ Hugh Kennedy
+ Mimezine
+ 1060 West Addison
+ Chicago, IL 60613
+ USA
+
+ EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 15]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 16]
+
+
+
+
+
+
+
+Network Working Group H. Kennedy
+Request for Comments: 3252 Mimezine
+Category: Informational 1 April 2002
+
+
+ Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document defines a reformulation of IP and two transport layer
+ protocols (TCP and UDP) as XML applications.
+
+1. Introduction
+
+1.1. Overview
+
+ This document describes the Binary Lexical Octet Ad-hoc Transport
+ (BLOAT): a reformulation of a widely-deployed network-layer protocol
+ (IP [RFC791]), and two associated transport layer protocols (TCP
+ [RFC793] and UDP [RFC768]) as XML [XML] applications. It also
+ describes methods for transporting BLOAT over Ethernet and IEEE 802
+ networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+ across the public Internet.
+
+1.2. Motivation
+
+ The wild popularity of XML as a basis for application-level protocols
+ such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+ Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+ investigation into the possibility of extending the use of XML in the
+ protocol stack. Using XML at both the transport and network layer in
+ addition to the application layer would provide for an amazing amount
+ of power and flexibility while removing dependencies on proprietary
+ and hard-to-understand binary protocols. This protocol unification
+ would also allow applications to use a single XML parser for all
+ aspects of their operation, eliminating developer time spent figuring
+ out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy Informational [Page 1]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ parsing to the XML toolset. The use of XML also mitigates concerns
+ over "network vs. host" byte ordering which is at the root of many
+ network application bugs.
+
+1.3. Relation to Existing Protocols
+
+ The reformulations specified in this RFC follow as closely as
+ possible the spirit of the RFCs on which they are based, and so MAY
+ contain elements or attributes that would not be needed in a pure
+ reworking (e.g. length attributes, which are implicit in XML.)
+
+ The layering of network and transport protocols are maintained in
+ this RFC despite the optimizations that could be made if the line
+ were somewhat blurred (i.e. merging TCP and IP into a single, larger
+ element in the DTD) in order to foster future use of this protocol as
+ a basis for reformulating other protocols (such as ICMP.)
+
+ Other than the encoding, the behavioral aspects of each of the
+ existing protocols remain unchanged. Routing, address spaces, TCP
+ congestion control, etc. behave as specified in the extant standards.
+ Adapting to new standards and experimental algorithm heuristics for
+ improving performance will become much easier once the move to BLOAT
+ has been completed.
+
+1.4. Requirement Levels
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
+
+2. IPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC.
+ IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+ (section 3.) and higher-level application protocols.
+
+ The DTD for this document type can be found in section 7.1.
+
+ The routing of IPoXML can be easily implemented on hosts with an XML
+ parser, as the regular structure lends itself handily to parsing and
+ validation of the document/datagram and then processing the
+ destination address, TTL, and checksum before sending it on to its
+ next-hop.
+
+ The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+ wider deployment of IPv4 and the fact that implementing IPv6 as XML
+ would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy Informational [Page 2]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+ of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
+ formed and include the XMLDecl.
+
+2.1. IP Description
+
+ A number of items have changed (for the better) from the original IP
+ specification. Bit-masks, where present have been converted into
+ human-readable values. IP addresses are listed in their dotted-
+ decimal notation [RFC1123]. Length and checksum values are present
+ as decimal integers.
+
+ To calculate the length and checksum fields of the IP element, a
+ canonicalized form of the element MUST be used. The canonical form
+ SHALL have no whitespace (including newline characters) between
+ elements and only one space character between attributes. There
+ SHALL NOT be a space following the last attribute in an element.
+
+ An iterative method SHOULD be used to calculate checksums, as the
+ length field will vary based on the size of the checksum.
+
+ The payload element bears special attention. Due to the character
+ set restrictions of XML, the payload of IP datagrams (which MAY
+ contain arbitrary data) MUST be encoded for transport. This RFC
+ REQUIRES the contents of the payload to be encoded in the base-64
+ encoding of RFC 2045 [RFC2045], but removes the requirement that the
+ encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 3]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+2.2. Example Datagram
+
+ The following is an example IPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ <ip>
+ <header length="474">
+ <version value="4"/>
+ <tos precedence="Routine" delay="Normal" throughput="Normal"
+ relibility="Normal" reserved="0"/>
+ <total.length value="461"/>
+ <id value="1"/>
+ <flags reserved="0" df="dont" mf="last"/>
+ <offset value="0"/>
+ <ttl value="255"/>
+ <protocol value="6"/>
+ <checksum value="8707"/>
+ <source address="10.0.0.22"/>
+ <destination address="10.0.0.1"/>
+ <options>
+ <end copied="0" class="0" number="0"/>
+ </options>
+ <padding pad="0"/>
+ </header>
+ <payload>
+ </payload>
+ </ip>
+
+3. TCPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+ A number of items have changed from the original TCP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+ To calculate the length and checksum fields of the TCP element, a
+ canonicalized form of the element MUST be used as in section 2.1.
+
+ An iterative method SHOULD be used to calculate checksums as in
+ section 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy Informational [Page 4]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ The TCP offset element was expanded to a maximum of 255 from 16 to
+ allow for the increased size of the header in XML.
+
+ TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ <tcp>
+ <tcp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <sequence number="322622954"/>
+ <acknowledgement number="689715995"/>
+ <offset number=""/>
+ <reserved value="0"/>
+ <control syn="1" ack="1"/>
+ <window size="1"/>
+ <urgent pointer="0"/>
+ <checksum value="2988"/>
+ <tcp.options>
+ <tcp.end kind="0"/>
+ </tcp.options>
+ <padding pad="0"/>
+ </tcp.header>
+ <payload>
+ </payload>
+ </tcp>
+
+4. UDPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+ A number of items have changed from the original UDP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+
+
+
+
+
+
+Kennedy Informational [Page 5]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ To calculate the length and checksum fields of the UDP element, a
+ canonicalized form of the element MUST be used as in section 2.1. An
+ iterative method SHOULD be used to calculate checksums as in section
+ 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+ UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ <udp>
+ <udp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <udp.length value="143"/>
+ <checksum value="2988"/>
+ </udp.header>
+ <payload>
+ </payload>
+ </udp>
+
+5. Network Transport
+
+ This document provides for the transmission of BLOAT datagrams over
+ two common families of physical layer transport. Future RFCs will
+ address additional transports as routing vendors catch up to the
+ specification, and we begin to see BLOAT routed across the Internet
+ backbone.
+
+5.1. Ethernet
+
+ BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+ exception that the type field of the Ethernet frame MUST contain the
+ value 0xBEEF. The first 5 octets of the Ethernet frame payload will
+ be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+ BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+ that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy Informational [Page 6]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+6. Gatewaying over IP
+
+ In order to facilitate the gradual introduction of BLOAT into the
+ public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+ gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+ The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+ Network DTD (7.1.)
+
+ The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+ [XML]) although it is understood that most IPoXML implementations
+ will not need to pull down the DTD, as it will normally be embedded
+ in the implementation, and presents something of a catch-22 if you
+ need to load part of your network protocol over the network.
+
+7.1. IPoXML DTD
+
+ <!--
+ DTD for IP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ -->
+ <!--
+ DTD data types:
+
+ Digits [0..9]+
+
+ Precedence "NetworkControl | InternetworkControl |
+ CRITIC | FlashOverride | Flash | Immediate |
+ Priority | Routine"
+
+ IP4Addr "dotted-decimal" notation of [RFC1123]
+
+ Class [0..3]
+
+ Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
+ Restricted | Secret | Top Secret | Reserved"
+
+ Compartments [0..65535]
+
+ Handling [0..65535]
+
+ TCC [0..16777216]
+
+ -->
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ENTITY % Digits "CDATA">
+ <!ENTITY % Precedence "CDATA">
+ <!ENTITY % IP4Addr "CDATA">
+ <!ENTITY % Class "CDATA">
+ <!ENTITY % Sec "CDATA">
+ <!ENTITY % Compartments "CDATA">
+ <!ENTITY % Handling "CDATA">
+ <!ENTITY % TCC "CDATA">
+
+ <!ELEMENT ip (header, payload)>
+
+ <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+ protocol, checksum, source, destination, options,
+ padding)>
+ <!-- length of header in 32-bit words -->
+ <!ATTLIST header
+ length %Digits; #REQUIRED>
+
+ <!ELEMENT version EMPTY>
+ <!-- ip version. SHOULD be "4" -->
+ <!ATTLIST version
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT tos EMPTY>
+ <!ATTLIST tos
+ precedence %Precedence; #REQUIRED
+ delay (normal | low) #REQUIRED
+ throughput (normal | high) #REQUIRED
+ relibility (normal | high) #REQUIRED
+ reserved CDATA #FIXED "0">
+
+ <!ELEMENT total.length EMPTY>
+ <!--
+ total length of datagram (header and payload) in octets, MUST be
+ less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+ ethernets).
+ -->
+ <!ATTLIST total.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT id EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST id
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT flags EMPTY>
+ <!-- df = don't fragment, mf = more fragments -->
+ <!ATTLIST flags
+
+
+
+Kennedy Informational [Page 8]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ reserved CDATA #FIXED "0"
+ df (may|dont) #REQUIRED
+ mf (last|more) #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+ <!ATTLIST offset
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT ttl EMPTY>
+ <!-- 0 <= ttl <= 255 -->
+ <!ATTLIST ttl
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT protocol EMPTY>
+ <!-- 0 <= protocol <= 255 (per IANA) -->
+ <!ATTLIST protocol
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT checksum EMPTY>
+ <!-- 0 <= checksum <= 65535 (over header only) -->
+ <!ATTLIST checksum
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT source EMPTY>
+ <!ATTLIST source
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT destination EMPTY>
+ <!ATTLIST destination
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT options ( end | noop | security | loose | strict | record
+ | stream | timestamp )*>
+
+ <!ELEMENT end EMPTY>
+ <!ATTLIST end
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "0">
+
+ <!ELEMENT noop EMPTY>
+ <!ATTLIST noop
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "1">
+
+ <!ELEMENT security EMPTY>
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST security
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "2"
+ length CDATA #FIXED "11"
+ security %Sec; #REQUIRED
+ compartments %Compartments; #REQUIRED
+ handling %Handling; #REQUIRED
+ tcc %TCC; #REQUIRED>
+ <!ELEMENT loose (hop)+>
+ <!ATTLIST loose
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "3"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT hop EMPTY>
+ <!ATTLIST hop
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT strict (hop)+>
+ <!ATTLIST strict
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "9"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT record (hop)+>
+ <!ATTLIST record
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "7"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT stream EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST stream
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "8"
+ length CDATA #FIXED "4"
+ id %Digits; #REQUIRED>
+
+ <!ELEMENT timestamp (tstamp)+>
+ <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST timestamp
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "2"
+ number CDATA #FIXED "4"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED
+ oflw %Digits; #REQUIRED
+ flag (0 | 1 | 3) #REQUIRED>
+
+ <!ELEMENT tstamp EMPTY>
+ <!ATTLIST tstamp
+ time %Digits; #REQUIRED
+ address %IP4Addr; #IMPLIED>
+ <!--
+ padding to bring header to 32-bit boundary.
+ pad MUST be "0"*
+ -->
+ <!ELEMENT padding EMPTY>
+ <!ATTLIST padding
+ pad CDATA #REQUIRED>
+
+ <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+ by section 2.1 of this RFC -->
+ <!ELEMENT payload (CDATA)>
+
+7.2. TCPoXML DTD
+
+ <!--
+ DTD for TCP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ -->
+
+ <!-- the pseudoheader is only included for checksum calculations -->
+ <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+ <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+ reserved, control, window, checksum, urgent,
+ tcp.options, padding)>
+
+ <!ELEMENT src EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+ <!ATTLIST src
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT dest EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST dest
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT sequence EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST sequence
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT acknowledgement EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST acknowledgement
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= number <= 255 -->
+ <!ATTLIST offset
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT reserved EMPTY>
+ <!ATTLIST reserved
+ value CDATA #FIXED "0">
+
+ <!ELEMENT control EMPTY>
+ <!ATTLIST control
+ urg (0|1) #IMPLIED
+ ack (0|1) #IMPLIED
+ psh (0|1) #IMPLIED
+ rst (0|1) #IMPLIED
+ syn (0|1) #IMPLIED
+ fin (0|1) #IMPLIED>
+
+ <!ELEMENT window EMPTY>
+ <!-- 0 <= size <= 65,535 -->
+ <!ATTLIST window
+ size %Digits; #REQUIRED>
+
+ <!--
+ checksum as in ip, but with
+ the following pseudo-header added into the tcp element:
+ -->
+ <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+ tcp.length)>
+
+ <!--
+ tcp header + data length in octets. does not include the size of
+
+ the pseudoheader.
+ -->
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ELEMENT tcp.length EMPTY>
+ <!ATTLIST tcp.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT urgent EMPTY>
+ <!-- 0 <= pointer <= 65,535 -->
+ <!ATTLIST urgent
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+ <!ELEMENT tcp.end EMPTY>
+ <!ATTLIST tcp.end
+ kind CDATA #FIXED "0">
+
+ <!ELEMENT tcp.noop EMPTY>
+ <!ATTLIST tcp.noop
+ kind CDATA #FIXED "1">
+
+ <!ELEMENT tcp.mss EMPTY>
+ <!ATTLIST tcp.mss
+ kind CDATA #FIXED "2"
+ length CDATA #FIXED "4"
+ size %Digits; #REQUIRED>
+
+7.3. UDPoXML DTD
+
+ <!--
+ DTD for UDP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ -->
+
+ <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+ <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+ <!ELEMENT udp.pseudoheader (source, destination, protocol,
+ udp.length)>
+
+ <!--
+ udp header + data length in octets. does not include the size of
+ the pseudoheader.
+ -->
+ <!ELEMENT udp.length EMPTY>
+ <!ATTLIST udp.length
+ value %Digits; #REQUIRED>
+
+
+
+Kennedy Informational [Page 13]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+8. Security Considerations
+
+ XML, as a subset of SGML, has the same security considerations as
+ specified in SGML Media Types [RFC1874]. Security considerations
+ that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+ not attempt to correct for issues not related to message format.
+
+9. References
+
+ [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
+ February 2002. (Work in Progress)
+
+ [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
+ 793, September 1981.
+
+ [RFC894] Hornig, C., "Standard for the Transmission of IP
+ Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+ [RFC1042] Postel, J. and J. Reynolds, "Standard for the
+ Transmission of IP Datagrams Over IEEE 802 Networks", STD
+ 43, RFC 1042, February 1988.
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts -
+ Application and Support", RFC 1123, October 1989.
+
+ [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
+ 1995.
+
+ [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
+ October 1996.
+
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy Informational [Page 14]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
+ RFC 3080, March 2001.
+
+ [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+ Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+ "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+ Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+ Markup Language (XML)" World Wide Web Consortium
+ Recommendation REC- xml-19980210.
+ http://www.w3.org/TR/1998/REC-xml-19980210
+
+10. Author's Address
+
+ Hugh Kennedy
+ Mimezine
+ 1060 West Addison
+ Chicago, IL 60613
+ USA
+
+ EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 15]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 16]
+
+
+
+
+
+
+
+Network Working Group H. Kennedy
+Request for Comments: 3252 Mimezine
+Category: Informational 1 April 2002
+
+
+ Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document defines a reformulation of IP and two transport layer
+ protocols (TCP and UDP) as XML applications.
+
+1. Introduction
+
+1.1. Overview
+
+ This document describes the Binary Lexical Octet Ad-hoc Transport
+ (BLOAT): a reformulation of a widely-deployed network-layer protocol
+ (IP [RFC791]), and two associated transport layer protocols (TCP
+ [RFC793] and UDP [RFC768]) as XML [XML] applications. It also
+ describes methods for transporting BLOAT over Ethernet and IEEE 802
+ networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+ across the public Internet.
+
+1.2. Motivation
+
+ The wild popularity of XML as a basis for application-level protocols
+ such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+ Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+ investigation into the possibility of extending the use of XML in the
+ protocol stack. Using XML at both the transport and network layer in
+ addition to the application layer would provide for an amazing amount
+ of power and flexibility while removing dependencies on proprietary
+ and hard-to-understand binary protocols. This protocol unification
+ would also allow applications to use a single XML parser for all
+ aspects of their operation, eliminating developer time spent figuring
+ out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy Informational [Page 1]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ parsing to the XML toolset. The use of XML also mitigates concerns
+ over "network vs. host" byte ordering which is at the root of many
+ network application bugs.
+
+1.3. Relation to Existing Protocols
+
+ The reformulations specified in this RFC follow as closely as
+ possible the spirit of the RFCs on which they are based, and so MAY
+ contain elements or attributes that would not be needed in a pure
+ reworking (e.g. length attributes, which are implicit in XML.)
+
+ The layering of network and transport protocols are maintained in
+ this RFC despite the optimizations that could be made if the line
+ were somewhat blurred (i.e. merging TCP and IP into a single, larger
+ element in the DTD) in order to foster future use of this protocol as
+ a basis for reformulating other protocols (such as ICMP.)
+
+ Other than the encoding, the behavioral aspects of each of the
+ existing protocols remain unchanged. Routing, address spaces, TCP
+ congestion control, etc. behave as specified in the extant standards.
+ Adapting to new standards and experimental algorithm heuristics for
+ improving performance will become much easier once the move to BLOAT
+ has been completed.
+
+1.4. Requirement Levels
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
+
+2. IPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC.
+ IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+ (section 3.) and higher-level application protocols.
+
+ The DTD for this document type can be found in section 7.1.
+
+ The routing of IPoXML can be easily implemented on hosts with an XML
+ parser, as the regular structure lends itself handily to parsing and
+ validation of the document/datagram and then processing the
+ destination address, TTL, and checksum before sending it on to its
+ next-hop.
+
+ The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+ wider deployment of IPv4 and the fact that implementing IPv6 as XML
+ would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy Informational [Page 2]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+ of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
+ formed and include the XMLDecl.
+
+2.1. IP Description
+
+ A number of items have changed (for the better) from the original IP
+ specification. Bit-masks, where present have been converted into
+ human-readable values. IP addresses are listed in their dotted-
+ decimal notation [RFC1123]. Length and checksum values are present
+ as decimal integers.
+
+ To calculate the length and checksum fields of the IP element, a
+ canonicalized form of the element MUST be used. The canonical form
+ SHALL have no whitespace (including newline characters) between
+ elements and only one space character between attributes. There
+ SHALL NOT be a space following the last attribute in an element.
+
+ An iterative method SHOULD be used to calculate checksums, as the
+ length field will vary based on the size of the checksum.
+
+ The payload element bears special attention. Due to the character
+ set restrictions of XML, the payload of IP datagrams (which MAY
+ contain arbitrary data) MUST be encoded for transport. This RFC
+ REQUIRES the contents of the payload to be encoded in the base-64
+ encoding of RFC 2045 [RFC2045], but removes the requirement that the
+ encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 3]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+2.2. Example Datagram
+
+ The following is an example IPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ <ip>
+ <header length="474">
+ <version value="4"/>
+ <tos precedence="Routine" delay="Normal" throughput="Normal"
+ relibility="Normal" reserved="0"/>
+ <total.length value="461"/>
+ <id value="1"/>
+ <flags reserved="0" df="dont" mf="last"/>
+ <offset value="0"/>
+ <ttl value="255"/>
+ <protocol value="6"/>
+ <checksum value="8707"/>
+ <source address="10.0.0.22"/>
+ <destination address="10.0.0.1"/>
+ <options>
+ <end copied="0" class="0" number="0"/>
+ </options>
+ <padding pad="0"/>
+ </header>
+ <payload>
+ </payload>
+ </ip>
+
+3. TCPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+ A number of items have changed from the original TCP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+ To calculate the length and checksum fields of the TCP element, a
+ canonicalized form of the element MUST be used as in section 2.1.
+
+ An iterative method SHOULD be used to calculate checksums as in
+ section 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy Informational [Page 4]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ The TCP offset element was expanded to a maximum of 255 from 16 to
+ allow for the increased size of the header in XML.
+
+ TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ <tcp>
+ <tcp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <sequence number="322622954"/>
+ <acknowledgement number="689715995"/>
+ <offset number=""/>
+ <reserved value="0"/>
+ <control syn="1" ack="1"/>
+ <window size="1"/>
+ <urgent pointer="0"/>
+ <checksum value="2988"/>
+ <tcp.options>
+ <tcp.end kind="0"/>
+ </tcp.options>
+ <padding pad="0"/>
+ </tcp.header>
+ <payload>
+ </payload>
+ </tcp>
+
+4. UDPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+ A number of items have changed from the original UDP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+
+
+
+
+
+
+Kennedy Informational [Page 5]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ To calculate the length and checksum fields of the UDP element, a
+ canonicalized form of the element MUST be used as in section 2.1. An
+ iterative method SHOULD be used to calculate checksums as in section
+ 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+ UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ <udp>
+ <udp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <udp.length value="143"/>
+ <checksum value="2988"/>
+ </udp.header>
+ <payload>
+ </payload>
+ </udp>
+
+5. Network Transport
+
+ This document provides for the transmission of BLOAT datagrams over
+ two common families of physical layer transport. Future RFCs will
+ address additional transports as routing vendors catch up to the
+ specification, and we begin to see BLOAT routed across the Internet
+ backbone.
+
+5.1. Ethernet
+
+ BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+ exception that the type field of the Ethernet frame MUST contain the
+ value 0xBEEF. The first 5 octets of the Ethernet frame payload will
+ be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+ BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+ that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy Informational [Page 6]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+6. Gatewaying over IP
+
+ In order to facilitate the gradual introduction of BLOAT into the
+ public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+ gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+ The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+ Network DTD (7.1.)
+
+ The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+ [XML]) although it is understood that most IPoXML implementations
+ will not need to pull down the DTD, as it will normally be embedded
+ in the implementation, and presents something of a catch-22 if you
+ need to load part of your network protocol over the network.
+
+7.1. IPoXML DTD
+
+ <!--
+ DTD for IP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ -->
+ <!--
+ DTD data types:
+
+ Digits [0..9]+
+
+ Precedence "NetworkControl | InternetworkControl |
+ CRITIC | FlashOverride | Flash | Immediate |
+ Priority | Routine"
+
+ IP4Addr "dotted-decimal" notation of [RFC1123]
+
+ Class [0..3]
+
+ Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
+ Restricted | Secret | Top Secret | Reserved"
+
+ Compartments [0..65535]
+
+ Handling [0..65535]
+
+ TCC [0..16777216]
+
+ -->
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ENTITY % Digits "CDATA">
+ <!ENTITY % Precedence "CDATA">
+ <!ENTITY % IP4Addr "CDATA">
+ <!ENTITY % Class "CDATA">
+ <!ENTITY % Sec "CDATA">
+ <!ENTITY % Compartments "CDATA">
+ <!ENTITY % Handling "CDATA">
+ <!ENTITY % TCC "CDATA">
+
+ <!ELEMENT ip (header, payload)>
+
+ <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+ protocol, checksum, source, destination, options,
+ padding)>
+ <!-- length of header in 32-bit words -->
+ <!ATTLIST header
+ length %Digits; #REQUIRED>
+
+ <!ELEMENT version EMPTY>
+ <!-- ip version. SHOULD be "4" -->
+ <!ATTLIST version
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT tos EMPTY>
+ <!ATTLIST tos
+ precedence %Precedence; #REQUIRED
+ delay (normal | low) #REQUIRED
+ throughput (normal | high) #REQUIRED
+ relibility (normal | high) #REQUIRED
+ reserved CDATA #FIXED "0">
+
+ <!ELEMENT total.length EMPTY>
+ <!--
+ total length of datagram (header and payload) in octets, MUST be
+ less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+ ethernets).
+ -->
+ <!ATTLIST total.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT id EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST id
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT flags EMPTY>
+ <!-- df = don't fragment, mf = more fragments -->
+ <!ATTLIST flags
+
+
+
+Kennedy Informational [Page 8]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ reserved CDATA #FIXED "0"
+ df (may|dont) #REQUIRED
+ mf (last|more) #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+ <!ATTLIST offset
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT ttl EMPTY>
+ <!-- 0 <= ttl <= 255 -->
+ <!ATTLIST ttl
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT protocol EMPTY>
+ <!-- 0 <= protocol <= 255 (per IANA) -->
+ <!ATTLIST protocol
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT checksum EMPTY>
+ <!-- 0 <= checksum <= 65535 (over header only) -->
+ <!ATTLIST checksum
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT source EMPTY>
+ <!ATTLIST source
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT destination EMPTY>
+ <!ATTLIST destination
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT options ( end | noop | security | loose | strict | record
+ | stream | timestamp )*>
+
+ <!ELEMENT end EMPTY>
+ <!ATTLIST end
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "0">
+
+ <!ELEMENT noop EMPTY>
+ <!ATTLIST noop
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "1">
+
+ <!ELEMENT security EMPTY>
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST security
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "2"
+ length CDATA #FIXED "11"
+ security %Sec; #REQUIRED
+ compartments %Compartments; #REQUIRED
+ handling %Handling; #REQUIRED
+ tcc %TCC; #REQUIRED>
+ <!ELEMENT loose (hop)+>
+ <!ATTLIST loose
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "3"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT hop EMPTY>
+ <!ATTLIST hop
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT strict (hop)+>
+ <!ATTLIST strict
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "9"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT record (hop)+>
+ <!ATTLIST record
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "7"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT stream EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST stream
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "8"
+ length CDATA #FIXED "4"
+ id %Digits; #REQUIRED>
+
+ <!ELEMENT timestamp (tstamp)+>
+ <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST timestamp
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "2"
+ number CDATA #FIXED "4"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED
+ oflw %Digits; #REQUIRED
+ flag (0 | 1 | 3) #REQUIRED>
+
+ <!ELEMENT tstamp EMPTY>
+ <!ATTLIST tstamp
+ time %Digits; #REQUIRED
+ address %IP4Addr; #IMPLIED>
+ <!--
+ padding to bring header to 32-bit boundary.
+ pad MUST be "0"*
+ -->
+ <!ELEMENT padding EMPTY>
+ <!ATTLIST padding
+ pad CDATA #REQUIRED>
+
+ <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+ by section 2.1 of this RFC -->
+ <!ELEMENT payload (CDATA)>
+
+7.2. TCPoXML DTD
+
+ <!--
+ DTD for TCP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ -->
+
+ <!-- the pseudoheader is only included for checksum calculations -->
+ <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+ <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+ reserved, control, window, checksum, urgent,
+ tcp.options, padding)>
+
+ <!ELEMENT src EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+ <!ATTLIST src
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT dest EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST dest
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT sequence EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST sequence
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT acknowledgement EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST acknowledgement
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= number <= 255 -->
+ <!ATTLIST offset
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT reserved EMPTY>
+ <!ATTLIST reserved
+ value CDATA #FIXED "0">
+
+ <!ELEMENT control EMPTY>
+ <!ATTLIST control
+ urg (0|1) #IMPLIED
+ ack (0|1) #IMPLIED
+ psh (0|1) #IMPLIED
+ rst (0|1) #IMPLIED
+ syn (0|1) #IMPLIED
+ fin (0|1) #IMPLIED>
+
+ <!ELEMENT window EMPTY>
+ <!-- 0 <= size <= 65,535 -->
+ <!ATTLIST window
+ size %Digits; #REQUIRED>
+
+ <!--
+ checksum as in ip, but with
+ the following pseudo-header added into the tcp element:
+ -->
+ <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+ tcp.length)>
+
+ <!--
+ tcp header + data length in octets. does not include the size of
+
+ the pseudoheader.
+ -->
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ELEMENT tcp.length EMPTY>
+ <!ATTLIST tcp.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT urgent EMPTY>
+ <!-- 0 <= pointer <= 65,535 -->
+ <!ATTLIST urgent
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+ <!ELEMENT tcp.end EMPTY>
+ <!ATTLIST tcp.end
+ kind CDATA #FIXED "0">
+
+ <!ELEMENT tcp.noop EMPTY>
+ <!ATTLIST tcp.noop
+ kind CDATA #FIXED "1">
+
+ <!ELEMENT tcp.mss EMPTY>
+ <!ATTLIST tcp.mss
+ kind CDATA #FIXED "2"
+ length CDATA #FIXED "4"
+ size %Digits; #REQUIRED>
+
+7.3. UDPoXML DTD
+
+ <!--
+ DTD for UDP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ -->
+
+ <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+ <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+ <!ELEMENT udp.pseudoheader (source, destination, protocol,
+ udp.length)>
+
+ <!--
+ udp header + data length in octets. does not include the size of
+ the pseudoheader.
+ -->
+ <!ELEMENT udp.length EMPTY>
+ <!ATTLIST udp.length
+ value %Digits; #REQUIRED>
+
+
+
+Kennedy Informational [Page 13]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+8. Security Considerations
+
+ XML, as a subset of SGML, has the same security considerations as
+ specified in SGML Media Types [RFC1874]. Security considerations
+ that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+ not attempt to correct for issues not related to message format.
+
+9. References
+
+ [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
+ February 2002. (Work in Progress)
+
+ [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
+ 793, September 1981.
+
+ [RFC894] Hornig, C., "Standard for the Transmission of IP
+ Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+ [RFC1042] Postel, J. and J. Reynolds, "Standard for the
+ Transmission of IP Datagrams Over IEEE 802 Networks", STD
+ 43, RFC 1042, February 1988.
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts -
+ Application and Support", RFC 1123, October 1989.
+
+ [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
+ 1995.
+
+ [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
+ October 1996.
+
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy Informational [Page 14]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
+ RFC 3080, March 2001.
+
+ [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+ Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+ "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+ Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+ Markup Language (XML)" World Wide Web Consortium
+ Recommendation REC- xml-19980210.
+ http://www.w3.org/TR/1998/REC-xml-19980210
+
+10. Author's Address
+
+ Hugh Kennedy
+ Mimezine
+ 1060 West Addison
+ Chicago, IL 60613
+ USA
+
+ EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 15]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 16]
+
+
+
+
+
+
+
+Network Working Group H. Kennedy
+Request for Comments: 3252 Mimezine
+Category: Informational 1 April 2002
+
+
+ Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document defines a reformulation of IP and two transport layer
+ protocols (TCP and UDP) as XML applications.
+
+1. Introduction
+
+1.1. Overview
+
+ This document describes the Binary Lexical Octet Ad-hoc Transport
+ (BLOAT): a reformulation of a widely-deployed network-layer protocol
+ (IP [RFC791]), and two associated transport layer protocols (TCP
+ [RFC793] and UDP [RFC768]) as XML [XML] applications. It also
+ describes methods for transporting BLOAT over Ethernet and IEEE 802
+ networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+ across the public Internet.
+
+1.2. Motivation
+
+ The wild popularity of XML as a basis for application-level protocols
+ such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+ Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+ investigation into the possibility of extending the use of XML in the
+ protocol stack. Using XML at both the transport and network layer in
+ addition to the application layer would provide for an amazing amount
+ of power and flexibility while removing dependencies on proprietary
+ and hard-to-understand binary protocols. This protocol unification
+ would also allow applications to use a single XML parser for all
+ aspects of their operation, eliminating developer time spent figuring
+ out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy Informational [Page 1]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ parsing to the XML toolset. The use of XML also mitigates concerns
+ over "network vs. host" byte ordering which is at the root of many
+ network application bugs.
+
+1.3. Relation to Existing Protocols
+
+ The reformulations specified in this RFC follow as closely as
+ possible the spirit of the RFCs on which they are based, and so MAY
+ contain elements or attributes that would not be needed in a pure
+ reworking (e.g. length attributes, which are implicit in XML.)
+
+ The layering of network and transport protocols are maintained in
+ this RFC despite the optimizations that could be made if the line
+ were somewhat blurred (i.e. merging TCP and IP into a single, larger
+ element in the DTD) in order to foster future use of this protocol as
+ a basis for reformulating other protocols (such as ICMP.)
+
+ Other than the encoding, the behavioral aspects of each of the
+ existing protocols remain unchanged. Routing, address spaces, TCP
+ congestion control, etc. behave as specified in the extant standards.
+ Adapting to new standards and experimental algorithm heuristics for
+ improving performance will become much easier once the move to BLOAT
+ has been completed.
+
+1.4. Requirement Levels
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
+
+2. IPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC.
+ IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+ (section 3.) and higher-level application protocols.
+
+ The DTD for this document type can be found in section 7.1.
+
+ The routing of IPoXML can be easily implemented on hosts with an XML
+ parser, as the regular structure lends itself handily to parsing and
+ validation of the document/datagram and then processing the
+ destination address, TTL, and checksum before sending it on to its
+ next-hop.
+
+ The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+ wider deployment of IPv4 and the fact that implementing IPv6 as XML
+ would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy Informational [Page 2]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+ of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
+ formed and include the XMLDecl.
+
+2.1. IP Description
+
+ A number of items have changed (for the better) from the original IP
+ specification. Bit-masks, where present have been converted into
+ human-readable values. IP addresses are listed in their dotted-
+ decimal notation [RFC1123]. Length and checksum values are present
+ as decimal integers.
+
+ To calculate the length and checksum fields of the IP element, a
+ canonicalized form of the element MUST be used. The canonical form
+ SHALL have no whitespace (including newline characters) between
+ elements and only one space character between attributes. There
+ SHALL NOT be a space following the last attribute in an element.
+
+ An iterative method SHOULD be used to calculate checksums, as the
+ length field will vary based on the size of the checksum.
+
+ The payload element bears special attention. Due to the character
+ set restrictions of XML, the payload of IP datagrams (which MAY
+ contain arbitrary data) MUST be encoded for transport. This RFC
+ REQUIRES the contents of the payload to be encoded in the base-64
+ encoding of RFC 2045 [RFC2045], but removes the requirement that the
+ encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 3]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+2.2. Example Datagram
+
+ The following is an example IPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ <ip>
+ <header length="474">
+ <version value="4"/>
+ <tos precedence="Routine" delay="Normal" throughput="Normal"
+ relibility="Normal" reserved="0"/>
+ <total.length value="461"/>
+ <id value="1"/>
+ <flags reserved="0" df="dont" mf="last"/>
+ <offset value="0"/>
+ <ttl value="255"/>
+ <protocol value="6"/>
+ <checksum value="8707"/>
+ <source address="10.0.0.22"/>
+ <destination address="10.0.0.1"/>
+ <options>
+ <end copied="0" class="0" number="0"/>
+ </options>
+ <padding pad="0"/>
+ </header>
+ <payload>
+ </payload>
+ </ip>
+
+3. TCPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+ A number of items have changed from the original TCP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+ To calculate the length and checksum fields of the TCP element, a
+ canonicalized form of the element MUST be used as in section 2.1.
+
+ An iterative method SHOULD be used to calculate checksums as in
+ section 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy Informational [Page 4]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ The TCP offset element was expanded to a maximum of 255 from 16 to
+ allow for the increased size of the header in XML.
+
+ TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ <tcp>
+ <tcp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <sequence number="322622954"/>
+ <acknowledgement number="689715995"/>
+ <offset number=""/>
+ <reserved value="0"/>
+ <control syn="1" ack="1"/>
+ <window size="1"/>
+ <urgent pointer="0"/>
+ <checksum value="2988"/>
+ <tcp.options>
+ <tcp.end kind="0"/>
+ </tcp.options>
+ <padding pad="0"/>
+ </tcp.header>
+ <payload>
+ </payload>
+ </tcp>
+
+4. UDPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+ A number of items have changed from the original UDP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+
+
+
+
+
+
+Kennedy Informational [Page 5]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ To calculate the length and checksum fields of the UDP element, a
+ canonicalized form of the element MUST be used as in section 2.1. An
+ iterative method SHOULD be used to calculate checksums as in section
+ 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+ UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ <udp>
+ <udp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <udp.length value="143"/>
+ <checksum value="2988"/>
+ </udp.header>
+ <payload>
+ </payload>
+ </udp>
+
+5. Network Transport
+
+ This document provides for the transmission of BLOAT datagrams over
+ two common families of physical layer transport. Future RFCs will
+ address additional transports as routing vendors catch up to the
+ specification, and we begin to see BLOAT routed across the Internet
+ backbone.
+
+5.1. Ethernet
+
+ BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+ exception that the type field of the Ethernet frame MUST contain the
+ value 0xBEEF. The first 5 octets of the Ethernet frame payload will
+ be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+ BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+ that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy Informational [Page 6]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+6. Gatewaying over IP
+
+ In order to facilitate the gradual introduction of BLOAT into the
+ public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+ gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+ The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+ Network DTD (7.1.)
+
+ The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+ [XML]) although it is understood that most IPoXML implementations
+ will not need to pull down the DTD, as it will normally be embedded
+ in the implementation, and presents something of a catch-22 if you
+ need to load part of your network protocol over the network.
+
+7.1. IPoXML DTD
+
+ <!--
+ DTD for IP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ -->
+ <!--
+ DTD data types:
+
+ Digits [0..9]+
+
+ Precedence "NetworkControl | InternetworkControl |
+ CRITIC | FlashOverride | Flash | Immediate |
+ Priority | Routine"
+
+ IP4Addr "dotted-decimal" notation of [RFC1123]
+
+ Class [0..3]
+
+ Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
+ Restricted | Secret | Top Secret | Reserved"
+
+ Compartments [0..65535]
+
+ Handling [0..65535]
+
+ TCC [0..16777216]
+
+ -->
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ENTITY % Digits "CDATA">
+ <!ENTITY % Precedence "CDATA">
+ <!ENTITY % IP4Addr "CDATA">
+ <!ENTITY % Class "CDATA">
+ <!ENTITY % Sec "CDATA">
+ <!ENTITY % Compartments "CDATA">
+ <!ENTITY % Handling "CDATA">
+ <!ENTITY % TCC "CDATA">
+
+ <!ELEMENT ip (header, payload)>
+
+ <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+ protocol, checksum, source, destination, options,
+ padding)>
+ <!-- length of header in 32-bit words -->
+ <!ATTLIST header
+ length %Digits; #REQUIRED>
+
+ <!ELEMENT version EMPTY>
+ <!-- ip version. SHOULD be "4" -->
+ <!ATTLIST version
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT tos EMPTY>
+ <!ATTLIST tos
+ precedence %Precedence; #REQUIRED
+ delay (normal | low) #REQUIRED
+ throughput (normal | high) #REQUIRED
+ relibility (normal | high) #REQUIRED
+ reserved CDATA #FIXED "0">
+
+ <!ELEMENT total.length EMPTY>
+ <!--
+ total length of datagram (header and payload) in octets, MUST be
+ less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+ ethernets).
+ -->
+ <!ATTLIST total.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT id EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST id
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT flags EMPTY>
+ <!-- df = don't fragment, mf = more fragments -->
+ <!ATTLIST flags
+
+
+
+Kennedy Informational [Page 8]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ reserved CDATA #FIXED "0"
+ df (may|dont) #REQUIRED
+ mf (last|more) #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+ <!ATTLIST offset
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT ttl EMPTY>
+ <!-- 0 <= ttl <= 255 -->
+ <!ATTLIST ttl
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT protocol EMPTY>
+ <!-- 0 <= protocol <= 255 (per IANA) -->
+ <!ATTLIST protocol
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT checksum EMPTY>
+ <!-- 0 <= checksum <= 65535 (over header only) -->
+ <!ATTLIST checksum
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT source EMPTY>
+ <!ATTLIST source
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT destination EMPTY>
+ <!ATTLIST destination
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT options ( end | noop | security | loose | strict | record
+ | stream | timestamp )*>
+
+ <!ELEMENT end EMPTY>
+ <!ATTLIST end
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "0">
+
+ <!ELEMENT noop EMPTY>
+ <!ATTLIST noop
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "1">
+
+ <!ELEMENT security EMPTY>
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST security
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "2"
+ length CDATA #FIXED "11"
+ security %Sec; #REQUIRED
+ compartments %Compartments; #REQUIRED
+ handling %Handling; #REQUIRED
+ tcc %TCC; #REQUIRED>
+ <!ELEMENT loose (hop)+>
+ <!ATTLIST loose
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "3"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT hop EMPTY>
+ <!ATTLIST hop
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT strict (hop)+>
+ <!ATTLIST strict
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "9"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT record (hop)+>
+ <!ATTLIST record
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "7"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT stream EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST stream
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "8"
+ length CDATA #FIXED "4"
+ id %Digits; #REQUIRED>
+
+ <!ELEMENT timestamp (tstamp)+>
+ <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST timestamp
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "2"
+ number CDATA #FIXED "4"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED
+ oflw %Digits; #REQUIRED
+ flag (0 | 1 | 3) #REQUIRED>
+
+ <!ELEMENT tstamp EMPTY>
+ <!ATTLIST tstamp
+ time %Digits; #REQUIRED
+ address %IP4Addr; #IMPLIED>
+ <!--
+ padding to bring header to 32-bit boundary.
+ pad MUST be "0"*
+ -->
+ <!ELEMENT padding EMPTY>
+ <!ATTLIST padding
+ pad CDATA #REQUIRED>
+
+ <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+ by section 2.1 of this RFC -->
+ <!ELEMENT payload (CDATA)>
+
+7.2. TCPoXML DTD
+
+ <!--
+ DTD for TCP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ -->
+
+ <!-- the pseudoheader is only included for checksum calculations -->
+ <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+ <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+ reserved, control, window, checksum, urgent,
+ tcp.options, padding)>
+
+ <!ELEMENT src EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+ <!ATTLIST src
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT dest EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST dest
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT sequence EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST sequence
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT acknowledgement EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST acknowledgement
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= number <= 255 -->
+ <!ATTLIST offset
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT reserved EMPTY>
+ <!ATTLIST reserved
+ value CDATA #FIXED "0">
+
+ <!ELEMENT control EMPTY>
+ <!ATTLIST control
+ urg (0|1) #IMPLIED
+ ack (0|1) #IMPLIED
+ psh (0|1) #IMPLIED
+ rst (0|1) #IMPLIED
+ syn (0|1) #IMPLIED
+ fin (0|1) #IMPLIED>
+
+ <!ELEMENT window EMPTY>
+ <!-- 0 <= size <= 65,535 -->
+ <!ATTLIST window
+ size %Digits; #REQUIRED>
+
+ <!--
+ checksum as in ip, but with
+ the following pseudo-header added into the tcp element:
+ -->
+ <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+ tcp.length)>
+
+ <!--
+ tcp header + data length in octets. does not include the size of
+
+ the pseudoheader.
+ -->
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ELEMENT tcp.length EMPTY>
+ <!ATTLIST tcp.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT urgent EMPTY>
+ <!-- 0 <= pointer <= 65,535 -->
+ <!ATTLIST urgent
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+ <!ELEMENT tcp.end EMPTY>
+ <!ATTLIST tcp.end
+ kind CDATA #FIXED "0">
+
+ <!ELEMENT tcp.noop EMPTY>
+ <!ATTLIST tcp.noop
+ kind CDATA #FIXED "1">
+
+ <!ELEMENT tcp.mss EMPTY>
+ <!ATTLIST tcp.mss
+ kind CDATA #FIXED "2"
+ length CDATA #FIXED "4"
+ size %Digits; #REQUIRED>
+
+7.3. UDPoXML DTD
+
+ <!--
+ DTD for UDP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ -->
+
+ <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+ <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+ <!ELEMENT udp.pseudoheader (source, destination, protocol,
+ udp.length)>
+
+ <!--
+ udp header + data length in octets. does not include the size of
+ the pseudoheader.
+ -->
+ <!ELEMENT udp.length EMPTY>
+ <!ATTLIST udp.length
+ value %Digits; #REQUIRED>
+
+
+
+Kennedy Informational [Page 13]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+8. Security Considerations
+
+ XML, as a subset of SGML, has the same security considerations as
+ specified in SGML Media Types [RFC1874]. Security considerations
+ that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+ not attempt to correct for issues not related to message format.
+
+9. References
+
+ [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
+ February 2002. (Work in Progress)
+
+ [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
+ 793, September 1981.
+
+ [RFC894] Hornig, C., "Standard for the Transmission of IP
+ Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+ [RFC1042] Postel, J. and J. Reynolds, "Standard for the
+ Transmission of IP Datagrams Over IEEE 802 Networks", STD
+ 43, RFC 1042, February 1988.
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts -
+ Application and Support", RFC 1123, October 1989.
+
+ [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
+ 1995.
+
+ [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
+ October 1996.
+
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy Informational [Page 14]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
+ RFC 3080, March 2001.
+
+ [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+ Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+ "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+ Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+ Markup Language (XML)" World Wide Web Consortium
+ Recommendation REC- xml-19980210.
+ http://www.w3.org/TR/1998/REC-xml-19980210
+
+10. Author's Address
+
+ Hugh Kennedy
+ Mimezine
+ 1060 West Addison
+ Chicago, IL 60613
+ USA
+
+ EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 15]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 16]
+
+
+
+
+
+
+
+Network Working Group H. Kennedy
+Request for Comments: 3252 Mimezine
+Category: Informational 1 April 2002
+
+
+ Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document defines a reformulation of IP and two transport layer
+ protocols (TCP and UDP) as XML applications.
+
+1. Introduction
+
+1.1. Overview
+
+ This document describes the Binary Lexical Octet Ad-hoc Transport
+ (BLOAT): a reformulation of a widely-deployed network-layer protocol
+ (IP [RFC791]), and two associated transport layer protocols (TCP
+ [RFC793] and UDP [RFC768]) as XML [XML] applications. It also
+ describes methods for transporting BLOAT over Ethernet and IEEE 802
+ networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+ across the public Internet.
+
+1.2. Motivation
+
+ The wild popularity of XML as a basis for application-level protocols
+ such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+ Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+ investigation into the possibility of extending the use of XML in the
+ protocol stack. Using XML at both the transport and network layer in
+ addition to the application layer would provide for an amazing amount
+ of power and flexibility while removing dependencies on proprietary
+ and hard-to-understand binary protocols. This protocol unification
+ would also allow applications to use a single XML parser for all
+ aspects of their operation, eliminating developer time spent figuring
+ out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy Informational [Page 1]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ parsing to the XML toolset. The use of XML also mitigates concerns
+ over "network vs. host" byte ordering which is at the root of many
+ network application bugs.
+
+1.3. Relation to Existing Protocols
+
+ The reformulations specified in this RFC follow as closely as
+ possible the spirit of the RFCs on which they are based, and so MAY
+ contain elements or attributes that would not be needed in a pure
+ reworking (e.g. length attributes, which are implicit in XML.)
+
+ The layering of network and transport protocols are maintained in
+ this RFC despite the optimizations that could be made if the line
+ were somewhat blurred (i.e. merging TCP and IP into a single, larger
+ element in the DTD) in order to foster future use of this protocol as
+ a basis for reformulating other protocols (such as ICMP.)
+
+ Other than the encoding, the behavioral aspects of each of the
+ existing protocols remain unchanged. Routing, address spaces, TCP
+ congestion control, etc. behave as specified in the extant standards.
+ Adapting to new standards and experimental algorithm heuristics for
+ improving performance will become much easier once the move to BLOAT
+ has been completed.
+
+1.4. Requirement Levels
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
+
+2. IPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC.
+ IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+ (section 3.) and higher-level application protocols.
+
+ The DTD for this document type can be found in section 7.1.
+
+ The routing of IPoXML can be easily implemented on hosts with an XML
+ parser, as the regular structure lends itself handily to parsing and
+ validation of the document/datagram and then processing the
+ destination address, TTL, and checksum before sending it on to its
+ next-hop.
+
+ The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+ wider deployment of IPv4 and the fact that implementing IPv6 as XML
+ would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy Informational [Page 2]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+ of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
+ formed and include the XMLDecl.
+
+2.1. IP Description
+
+ A number of items have changed (for the better) from the original IP
+ specification. Bit-masks, where present have been converted into
+ human-readable values. IP addresses are listed in their dotted-
+ decimal notation [RFC1123]. Length and checksum values are present
+ as decimal integers.
+
+ To calculate the length and checksum fields of the IP element, a
+ canonicalized form of the element MUST be used. The canonical form
+ SHALL have no whitespace (including newline characters) between
+ elements and only one space character between attributes. There
+ SHALL NOT be a space following the last attribute in an element.
+
+ An iterative method SHOULD be used to calculate checksums, as the
+ length field will vary based on the size of the checksum.
+
+ The payload element bears special attention. Due to the character
+ set restrictions of XML, the payload of IP datagrams (which MAY
+ contain arbitrary data) MUST be encoded for transport. This RFC
+ REQUIRES the contents of the payload to be encoded in the base-64
+ encoding of RFC 2045 [RFC2045], but removes the requirement that the
+ encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 3]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+2.2. Example Datagram
+
+ The following is an example IPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ <ip>
+ <header length="474">
+ <version value="4"/>
+ <tos precedence="Routine" delay="Normal" throughput="Normal"
+ relibility="Normal" reserved="0"/>
+ <total.length value="461"/>
+ <id value="1"/>
+ <flags reserved="0" df="dont" mf="last"/>
+ <offset value="0"/>
+ <ttl value="255"/>
+ <protocol value="6"/>
+ <checksum value="8707"/>
+ <source address="10.0.0.22"/>
+ <destination address="10.0.0.1"/>
+ <options>
+ <end copied="0" class="0" number="0"/>
+ </options>
+ <padding pad="0"/>
+ </header>
+ <payload>
+ </payload>
+ </ip>
+
+3. TCPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+ A number of items have changed from the original TCP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+ To calculate the length and checksum fields of the TCP element, a
+ canonicalized form of the element MUST be used as in section 2.1.
+
+ An iterative method SHOULD be used to calculate checksums as in
+ section 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy Informational [Page 4]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ The TCP offset element was expanded to a maximum of 255 from 16 to
+ allow for the increased size of the header in XML.
+
+ TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ <tcp>
+ <tcp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <sequence number="322622954"/>
+ <acknowledgement number="689715995"/>
+ <offset number=""/>
+ <reserved value="0"/>
+ <control syn="1" ack="1"/>
+ <window size="1"/>
+ <urgent pointer="0"/>
+ <checksum value="2988"/>
+ <tcp.options>
+ <tcp.end kind="0"/>
+ </tcp.options>
+ <padding pad="0"/>
+ </tcp.header>
+ <payload>
+ </payload>
+ </tcp>
+
+4. UDPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+ A number of items have changed from the original UDP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+
+
+
+
+
+
+Kennedy Informational [Page 5]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ To calculate the length and checksum fields of the UDP element, a
+ canonicalized form of the element MUST be used as in section 2.1. An
+ iterative method SHOULD be used to calculate checksums as in section
+ 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+ UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ <udp>
+ <udp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <udp.length value="143"/>
+ <checksum value="2988"/>
+ </udp.header>
+ <payload>
+ </payload>
+ </udp>
+
+5. Network Transport
+
+ This document provides for the transmission of BLOAT datagrams over
+ two common families of physical layer transport. Future RFCs will
+ address additional transports as routing vendors catch up to the
+ specification, and we begin to see BLOAT routed across the Internet
+ backbone.
+
+5.1. Ethernet
+
+ BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+ exception that the type field of the Ethernet frame MUST contain the
+ value 0xBEEF. The first 5 octets of the Ethernet frame payload will
+ be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+ BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+ that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy Informational [Page 6]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+6. Gatewaying over IP
+
+ In order to facilitate the gradual introduction of BLOAT into the
+ public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+ gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+ The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+ Network DTD (7.1.)
+
+ The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+ [XML]) although it is understood that most IPoXML implementations
+ will not need to pull down the DTD, as it will normally be embedded
+ in the implementation, and presents something of a catch-22 if you
+ need to load part of your network protocol over the network.
+
+7.1. IPoXML DTD
+
+ <!--
+ DTD for IP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ -->
+ <!--
+ DTD data types:
+
+ Digits [0..9]+
+
+ Precedence "NetworkControl | InternetworkControl |
+ CRITIC | FlashOverride | Flash | Immediate |
+ Priority | Routine"
+
+ IP4Addr "dotted-decimal" notation of [RFC1123]
+
+ Class [0..3]
+
+ Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
+ Restricted | Secret | Top Secret | Reserved"
+
+ Compartments [0..65535]
+
+ Handling [0..65535]
+
+ TCC [0..16777216]
+
+ -->
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ENTITY % Digits "CDATA">
+ <!ENTITY % Precedence "CDATA">
+ <!ENTITY % IP4Addr "CDATA">
+ <!ENTITY % Class "CDATA">
+ <!ENTITY % Sec "CDATA">
+ <!ENTITY % Compartments "CDATA">
+ <!ENTITY % Handling "CDATA">
+ <!ENTITY % TCC "CDATA">
+
+ <!ELEMENT ip (header, payload)>
+
+ <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+ protocol, checksum, source, destination, options,
+ padding)>
+ <!-- length of header in 32-bit words -->
+ <!ATTLIST header
+ length %Digits; #REQUIRED>
+
+ <!ELEMENT version EMPTY>
+ <!-- ip version. SHOULD be "4" -->
+ <!ATTLIST version
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT tos EMPTY>
+ <!ATTLIST tos
+ precedence %Precedence; #REQUIRED
+ delay (normal | low) #REQUIRED
+ throughput (normal | high) #REQUIRED
+ relibility (normal | high) #REQUIRED
+ reserved CDATA #FIXED "0">
+
+ <!ELEMENT total.length EMPTY>
+ <!--
+ total length of datagram (header and payload) in octets, MUST be
+ less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+ ethernets).
+ -->
+ <!ATTLIST total.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT id EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST id
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT flags EMPTY>
+ <!-- df = don't fragment, mf = more fragments -->
+ <!ATTLIST flags
+
+
+
+Kennedy Informational [Page 8]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ reserved CDATA #FIXED "0"
+ df (may|dont) #REQUIRED
+ mf (last|more) #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+ <!ATTLIST offset
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT ttl EMPTY>
+ <!-- 0 <= ttl <= 255 -->
+ <!ATTLIST ttl
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT protocol EMPTY>
+ <!-- 0 <= protocol <= 255 (per IANA) -->
+ <!ATTLIST protocol
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT checksum EMPTY>
+ <!-- 0 <= checksum <= 65535 (over header only) -->
+ <!ATTLIST checksum
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT source EMPTY>
+ <!ATTLIST source
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT destination EMPTY>
+ <!ATTLIST destination
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT options ( end | noop | security | loose | strict | record
+ | stream | timestamp )*>
+
+ <!ELEMENT end EMPTY>
+ <!ATTLIST end
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "0">
+
+ <!ELEMENT noop EMPTY>
+ <!ATTLIST noop
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "1">
+
+ <!ELEMENT security EMPTY>
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST security
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "2"
+ length CDATA #FIXED "11"
+ security %Sec; #REQUIRED
+ compartments %Compartments; #REQUIRED
+ handling %Handling; #REQUIRED
+ tcc %TCC; #REQUIRED>
+ <!ELEMENT loose (hop)+>
+ <!ATTLIST loose
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "3"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT hop EMPTY>
+ <!ATTLIST hop
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT strict (hop)+>
+ <!ATTLIST strict
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "9"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT record (hop)+>
+ <!ATTLIST record
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "7"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT stream EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST stream
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "8"
+ length CDATA #FIXED "4"
+ id %Digits; #REQUIRED>
+
+ <!ELEMENT timestamp (tstamp)+>
+ <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST timestamp
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "2"
+ number CDATA #FIXED "4"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED
+ oflw %Digits; #REQUIRED
+ flag (0 | 1 | 3) #REQUIRED>
+
+ <!ELEMENT tstamp EMPTY>
+ <!ATTLIST tstamp
+ time %Digits; #REQUIRED
+ address %IP4Addr; #IMPLIED>
+ <!--
+ padding to bring header to 32-bit boundary.
+ pad MUST be "0"*
+ -->
+ <!ELEMENT padding EMPTY>
+ <!ATTLIST padding
+ pad CDATA #REQUIRED>
+
+ <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+ by section 2.1 of this RFC -->
+ <!ELEMENT payload (CDATA)>
+
+7.2. TCPoXML DTD
+
+ <!--
+ DTD for TCP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ -->
+
+ <!-- the pseudoheader is only included for checksum calculations -->
+ <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+ <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+ reserved, control, window, checksum, urgent,
+ tcp.options, padding)>
+
+ <!ELEMENT src EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+ <!ATTLIST src
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT dest EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST dest
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT sequence EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST sequence
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT acknowledgement EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST acknowledgement
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= number <= 255 -->
+ <!ATTLIST offset
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT reserved EMPTY>
+ <!ATTLIST reserved
+ value CDATA #FIXED "0">
+
+ <!ELEMENT control EMPTY>
+ <!ATTLIST control
+ urg (0|1) #IMPLIED
+ ack (0|1) #IMPLIED
+ psh (0|1) #IMPLIED
+ rst (0|1) #IMPLIED
+ syn (0|1) #IMPLIED
+ fin (0|1) #IMPLIED>
+
+ <!ELEMENT window EMPTY>
+ <!-- 0 <= size <= 65,535 -->
+ <!ATTLIST window
+ size %Digits; #REQUIRED>
+
+ <!--
+ checksum as in ip, but with
+ the following pseudo-header added into the tcp element:
+ -->
+ <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+ tcp.length)>
+
+ <!--
+ tcp header + data length in octets. does not include the size of
+
+ the pseudoheader.
+ -->
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ELEMENT tcp.length EMPTY>
+ <!ATTLIST tcp.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT urgent EMPTY>
+ <!-- 0 <= pointer <= 65,535 -->
+ <!ATTLIST urgent
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+ <!ELEMENT tcp.end EMPTY>
+ <!ATTLIST tcp.end
+ kind CDATA #FIXED "0">
+
+ <!ELEMENT tcp.noop EMPTY>
+ <!ATTLIST tcp.noop
+ kind CDATA #FIXED "1">
+
+ <!ELEMENT tcp.mss EMPTY>
+ <!ATTLIST tcp.mss
+ kind CDATA #FIXED "2"
+ length CDATA #FIXED "4"
+ size %Digits; #REQUIRED>
+
+7.3. UDPoXML DTD
+
+ <!--
+ DTD for UDP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ -->
+
+ <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+ <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+ <!ELEMENT udp.pseudoheader (source, destination, protocol,
+ udp.length)>
+
+ <!--
+ udp header + data length in octets. does not include the size of
+ the pseudoheader.
+ -->
+ <!ELEMENT udp.length EMPTY>
+ <!ATTLIST udp.length
+ value %Digits; #REQUIRED>
+
+
+
+Kennedy Informational [Page 13]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+8. Security Considerations
+
+ XML, as a subset of SGML, has the same security considerations as
+ specified in SGML Media Types [RFC1874]. Security considerations
+ that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+ not attempt to correct for issues not related to message format.
+
+9. References
+
+ [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
+ February 2002. (Work in Progress)
+
+ [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
+ 793, September 1981.
+
+ [RFC894] Hornig, C., "Standard for the Transmission of IP
+ Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+ [RFC1042] Postel, J. and J. Reynolds, "Standard for the
+ Transmission of IP Datagrams Over IEEE 802 Networks", STD
+ 43, RFC 1042, February 1988.
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts -
+ Application and Support", RFC 1123, October 1989.
+
+ [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
+ 1995.
+
+ [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
+ October 1996.
+
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy Informational [Page 14]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
+ RFC 3080, March 2001.
+
+ [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+ Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+ "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+ Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+ Markup Language (XML)" World Wide Web Consortium
+ Recommendation REC- xml-19980210.
+ http://www.w3.org/TR/1998/REC-xml-19980210
+
+10. Author's Address
+
+ Hugh Kennedy
+ Mimezine
+ 1060 West Addison
+ Chicago, IL 60613
+ USA
+
+ EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 15]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 16]
+
+
+
+
+
+
+
+Network Working Group H. Kennedy
+Request for Comments: 3252 Mimezine
+Category: Informational 1 April 2002
+
+
+ Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document defines a reformulation of IP and two transport layer
+ protocols (TCP and UDP) as XML applications.
+
+1. Introduction
+
+1.1. Overview
+
+ This document describes the Binary Lexical Octet Ad-hoc Transport
+ (BLOAT): a reformulation of a widely-deployed network-layer protocol
+ (IP [RFC791]), and two associated transport layer protocols (TCP
+ [RFC793] and UDP [RFC768]) as XML [XML] applications. It also
+ describes methods for transporting BLOAT over Ethernet and IEEE 802
+ networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+ across the public Internet.
+
+1.2. Motivation
+
+ The wild popularity of XML as a basis for application-level protocols
+ such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+ Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+ investigation into the possibility of extending the use of XML in the
+ protocol stack. Using XML at both the transport and network layer in
+ addition to the application layer would provide for an amazing amount
+ of power and flexibility while removing dependencies on proprietary
+ and hard-to-understand binary protocols. This protocol unification
+ would also allow applications to use a single XML parser for all
+ aspects of their operation, eliminating developer time spent figuring
+ out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy Informational [Page 1]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ parsing to the XML toolset. The use of XML also mitigates concerns
+ over "network vs. host" byte ordering which is at the root of many
+ network application bugs.
+
+1.3. Relation to Existing Protocols
+
+ The reformulations specified in this RFC follow as closely as
+ possible the spirit of the RFCs on which they are based, and so MAY
+ contain elements or attributes that would not be needed in a pure
+ reworking (e.g. length attributes, which are implicit in XML.)
+
+ The layering of network and transport protocols are maintained in
+ this RFC despite the optimizations that could be made if the line
+ were somewhat blurred (i.e. merging TCP and IP into a single, larger
+ element in the DTD) in order to foster future use of this protocol as
+ a basis for reformulating other protocols (such as ICMP.)
+
+ Other than the encoding, the behavioral aspects of each of the
+ existing protocols remain unchanged. Routing, address spaces, TCP
+ congestion control, etc. behave as specified in the extant standards.
+ Adapting to new standards and experimental algorithm heuristics for
+ improving performance will become much easier once the move to BLOAT
+ has been completed.
+
+1.4. Requirement Levels
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
+
+2. IPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC.
+ IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+ (section 3.) and higher-level application protocols.
+
+ The DTD for this document type can be found in section 7.1.
+
+ The routing of IPoXML can be easily implemented on hosts with an XML
+ parser, as the regular structure lends itself handily to parsing and
+ validation of the document/datagram and then processing the
+ destination address, TTL, and checksum before sending it on to its
+ next-hop.
+
+ The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+ wider deployment of IPv4 and the fact that implementing IPv6 as XML
+ would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy Informational [Page 2]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+ of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
+ formed and include the XMLDecl.
+
+2.1. IP Description
+
+ A number of items have changed (for the better) from the original IP
+ specification. Bit-masks, where present have been converted into
+ human-readable values. IP addresses are listed in their dotted-
+ decimal notation [RFC1123]. Length and checksum values are present
+ as decimal integers.
+
+ To calculate the length and checksum fields of the IP element, a
+ canonicalized form of the element MUST be used. The canonical form
+ SHALL have no whitespace (including newline characters) between
+ elements and only one space character between attributes. There
+ SHALL NOT be a space following the last attribute in an element.
+
+ An iterative method SHOULD be used to calculate checksums, as the
+ length field will vary based on the size of the checksum.
+
+ The payload element bears special attention. Due to the character
+ set restrictions of XML, the payload of IP datagrams (which MAY
+ contain arbitrary data) MUST be encoded for transport. This RFC
+ REQUIRES the contents of the payload to be encoded in the base-64
+ encoding of RFC 2045 [RFC2045], but removes the requirement that the
+ encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 3]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+2.2. Example Datagram
+
+ The following is an example IPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ <ip>
+ <header length="474">
+ <version value="4"/>
+ <tos precedence="Routine" delay="Normal" throughput="Normal"
+ relibility="Normal" reserved="0"/>
+ <total.length value="461"/>
+ <id value="1"/>
+ <flags reserved="0" df="dont" mf="last"/>
+ <offset value="0"/>
+ <ttl value="255"/>
+ <protocol value="6"/>
+ <checksum value="8707"/>
+ <source address="10.0.0.22"/>
+ <destination address="10.0.0.1"/>
+ <options>
+ <end copied="0" class="0" number="0"/>
+ </options>
+ <padding pad="0"/>
+ </header>
+ <payload>
+ </payload>
+ </ip>
+
+3. TCPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+ A number of items have changed from the original TCP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+ To calculate the length and checksum fields of the TCP element, a
+ canonicalized form of the element MUST be used as in section 2.1.
+
+ An iterative method SHOULD be used to calculate checksums as in
+ section 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy Informational [Page 4]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ The TCP offset element was expanded to a maximum of 255 from 16 to
+ allow for the increased size of the header in XML.
+
+ TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ <tcp>
+ <tcp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <sequence number="322622954"/>
+ <acknowledgement number="689715995"/>
+ <offset number=""/>
+ <reserved value="0"/>
+ <control syn="1" ack="1"/>
+ <window size="1"/>
+ <urgent pointer="0"/>
+ <checksum value="2988"/>
+ <tcp.options>
+ <tcp.end kind="0"/>
+ </tcp.options>
+ <padding pad="0"/>
+ </tcp.header>
+ <payload>
+ </payload>
+ </tcp>
+
+4. UDPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+ A number of items have changed from the original UDP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+
+
+
+
+
+
+Kennedy Informational [Page 5]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ To calculate the length and checksum fields of the UDP element, a
+ canonicalized form of the element MUST be used as in section 2.1. An
+ iterative method SHOULD be used to calculate checksums as in section
+ 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+ UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ <udp>
+ <udp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <udp.length value="143"/>
+ <checksum value="2988"/>
+ </udp.header>
+ <payload>
+ </payload>
+ </udp>
+
+5. Network Transport
+
+ This document provides for the transmission of BLOAT datagrams over
+ two common families of physical layer transport. Future RFCs will
+ address additional transports as routing vendors catch up to the
+ specification, and we begin to see BLOAT routed across the Internet
+ backbone.
+
+5.1. Ethernet
+
+ BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+ exception that the type field of the Ethernet frame MUST contain the
+ value 0xBEEF. The first 5 octets of the Ethernet frame payload will
+ be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+ BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+ that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy Informational [Page 6]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+6. Gatewaying over IP
+
+ In order to facilitate the gradual introduction of BLOAT into the
+ public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+ gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+ The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+ Network DTD (7.1.)
+
+ The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+ [XML]) although it is understood that most IPoXML implementations
+ will not need to pull down the DTD, as it will normally be embedded
+ in the implementation, and presents something of a catch-22 if you
+ need to load part of your network protocol over the network.
+
+7.1. IPoXML DTD
+
+ <!--
+ DTD for IP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ -->
+ <!--
+ DTD data types:
+
+ Digits [0..9]+
+
+ Precedence "NetworkControl | InternetworkControl |
+ CRITIC | FlashOverride | Flash | Immediate |
+ Priority | Routine"
+
+ IP4Addr "dotted-decimal" notation of [RFC1123]
+
+ Class [0..3]
+
+ Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
+ Restricted | Secret | Top Secret | Reserved"
+
+ Compartments [0..65535]
+
+ Handling [0..65535]
+
+ TCC [0..16777216]
+
+ -->
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ENTITY % Digits "CDATA">
+ <!ENTITY % Precedence "CDATA">
+ <!ENTITY % IP4Addr "CDATA">
+ <!ENTITY % Class "CDATA">
+ <!ENTITY % Sec "CDATA">
+ <!ENTITY % Compartments "CDATA">
+ <!ENTITY % Handling "CDATA">
+ <!ENTITY % TCC "CDATA">
+
+ <!ELEMENT ip (header, payload)>
+
+ <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+ protocol, checksum, source, destination, options,
+ padding)>
+ <!-- length of header in 32-bit words -->
+ <!ATTLIST header
+ length %Digits; #REQUIRED>
+
+ <!ELEMENT version EMPTY>
+ <!-- ip version. SHOULD be "4" -->
+ <!ATTLIST version
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT tos EMPTY>
+ <!ATTLIST tos
+ precedence %Precedence; #REQUIRED
+ delay (normal | low) #REQUIRED
+ throughput (normal | high) #REQUIRED
+ relibility (normal | high) #REQUIRED
+ reserved CDATA #FIXED "0">
+
+ <!ELEMENT total.length EMPTY>
+ <!--
+ total length of datagram (header and payload) in octets, MUST be
+ less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+ ethernets).
+ -->
+ <!ATTLIST total.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT id EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST id
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT flags EMPTY>
+ <!-- df = don't fragment, mf = more fragments -->
+ <!ATTLIST flags
+
+
+
+Kennedy Informational [Page 8]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ reserved CDATA #FIXED "0"
+ df (may|dont) #REQUIRED
+ mf (last|more) #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+ <!ATTLIST offset
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT ttl EMPTY>
+ <!-- 0 <= ttl <= 255 -->
+ <!ATTLIST ttl
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT protocol EMPTY>
+ <!-- 0 <= protocol <= 255 (per IANA) -->
+ <!ATTLIST protocol
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT checksum EMPTY>
+ <!-- 0 <= checksum <= 65535 (over header only) -->
+ <!ATTLIST checksum
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT source EMPTY>
+ <!ATTLIST source
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT destination EMPTY>
+ <!ATTLIST destination
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT options ( end | noop | security | loose | strict | record
+ | stream | timestamp )*>
+
+ <!ELEMENT end EMPTY>
+ <!ATTLIST end
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "0">
+
+ <!ELEMENT noop EMPTY>
+ <!ATTLIST noop
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "1">
+
+ <!ELEMENT security EMPTY>
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST security
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "2"
+ length CDATA #FIXED "11"
+ security %Sec; #REQUIRED
+ compartments %Compartments; #REQUIRED
+ handling %Handling; #REQUIRED
+ tcc %TCC; #REQUIRED>
+ <!ELEMENT loose (hop)+>
+ <!ATTLIST loose
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "3"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT hop EMPTY>
+ <!ATTLIST hop
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT strict (hop)+>
+ <!ATTLIST strict
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "9"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT record (hop)+>
+ <!ATTLIST record
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "7"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT stream EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST stream
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "8"
+ length CDATA #FIXED "4"
+ id %Digits; #REQUIRED>
+
+ <!ELEMENT timestamp (tstamp)+>
+ <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST timestamp
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "2"
+ number CDATA #FIXED "4"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED
+ oflw %Digits; #REQUIRED
+ flag (0 | 1 | 3) #REQUIRED>
+
+ <!ELEMENT tstamp EMPTY>
+ <!ATTLIST tstamp
+ time %Digits; #REQUIRED
+ address %IP4Addr; #IMPLIED>
+ <!--
+ padding to bring header to 32-bit boundary.
+ pad MUST be "0"*
+ -->
+ <!ELEMENT padding EMPTY>
+ <!ATTLIST padding
+ pad CDATA #REQUIRED>
+
+ <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+ by section 2.1 of this RFC -->
+ <!ELEMENT payload (CDATA)>
+
+7.2. TCPoXML DTD
+
+ <!--
+ DTD for TCP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ -->
+
+ <!-- the pseudoheader is only included for checksum calculations -->
+ <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+ <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+ reserved, control, window, checksum, urgent,
+ tcp.options, padding)>
+
+ <!ELEMENT src EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+ <!ATTLIST src
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT dest EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST dest
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT sequence EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST sequence
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT acknowledgement EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST acknowledgement
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= number <= 255 -->
+ <!ATTLIST offset
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT reserved EMPTY>
+ <!ATTLIST reserved
+ value CDATA #FIXED "0">
+
+ <!ELEMENT control EMPTY>
+ <!ATTLIST control
+ urg (0|1) #IMPLIED
+ ack (0|1) #IMPLIED
+ psh (0|1) #IMPLIED
+ rst (0|1) #IMPLIED
+ syn (0|1) #IMPLIED
+ fin (0|1) #IMPLIED>
+
+ <!ELEMENT window EMPTY>
+ <!-- 0 <= size <= 65,535 -->
+ <!ATTLIST window
+ size %Digits; #REQUIRED>
+
+ <!--
+ checksum as in ip, but with
+ the following pseudo-header added into the tcp element:
+ -->
+ <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+ tcp.length)>
+
+ <!--
+ tcp header + data length in octets. does not include the size of
+
+ the pseudoheader.
+ -->
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ELEMENT tcp.length EMPTY>
+ <!ATTLIST tcp.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT urgent EMPTY>
+ <!-- 0 <= pointer <= 65,535 -->
+ <!ATTLIST urgent
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+ <!ELEMENT tcp.end EMPTY>
+ <!ATTLIST tcp.end
+ kind CDATA #FIXED "0">
+
+ <!ELEMENT tcp.noop EMPTY>
+ <!ATTLIST tcp.noop
+ kind CDATA #FIXED "1">
+
+ <!ELEMENT tcp.mss EMPTY>
+ <!ATTLIST tcp.mss
+ kind CDATA #FIXED "2"
+ length CDATA #FIXED "4"
+ size %Digits; #REQUIRED>
+
+7.3. UDPoXML DTD
+
+ <!--
+ DTD for UDP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ -->
+
+ <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+ <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+ <!ELEMENT udp.pseudoheader (source, destination, protocol,
+ udp.length)>
+
+ <!--
+ udp header + data length in octets. does not include the size of
+ the pseudoheader.
+ -->
+ <!ELEMENT udp.length EMPTY>
+ <!ATTLIST udp.length
+ value %Digits; #REQUIRED>
+
+
+
+Kennedy Informational [Page 13]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+8. Security Considerations
+
+ XML, as a subset of SGML, has the same security considerations as
+ specified in SGML Media Types [RFC1874]. Security considerations
+ that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+ not attempt to correct for issues not related to message format.
+
+9. References
+
+ [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
+ February 2002. (Work in Progress)
+
+ [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
+ 793, September 1981.
+
+ [RFC894] Hornig, C., "Standard for the Transmission of IP
+ Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+ [RFC1042] Postel, J. and J. Reynolds, "Standard for the
+ Transmission of IP Datagrams Over IEEE 802 Networks", STD
+ 43, RFC 1042, February 1988.
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts -
+ Application and Support", RFC 1123, October 1989.
+
+ [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
+ 1995.
+
+ [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
+ October 1996.
+
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy Informational [Page 14]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
+ RFC 3080, March 2001.
+
+ [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+ Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+ "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+ Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+ Markup Language (XML)" World Wide Web Consortium
+ Recommendation REC- xml-19980210.
+ http://www.w3.org/TR/1998/REC-xml-19980210
+
+10. Author's Address
+
+ Hugh Kennedy
+ Mimezine
+ 1060 West Addison
+ Chicago, IL 60613
+ USA
+
+ EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 15]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 16]
+
+
+
+
+
+
+
+Network Working Group H. Kennedy
+Request for Comments: 3252 Mimezine
+Category: Informational 1 April 2002
+
+
+ Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document defines a reformulation of IP and two transport layer
+ protocols (TCP and UDP) as XML applications.
+
+1. Introduction
+
+1.1. Overview
+
+ This document describes the Binary Lexical Octet Ad-hoc Transport
+ (BLOAT): a reformulation of a widely-deployed network-layer protocol
+ (IP [RFC791]), and two associated transport layer protocols (TCP
+ [RFC793] and UDP [RFC768]) as XML [XML] applications. It also
+ describes methods for transporting BLOAT over Ethernet and IEEE 802
+ networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+ across the public Internet.
+
+1.2. Motivation
+
+ The wild popularity of XML as a basis for application-level protocols
+ such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+ Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+ investigation into the possibility of extending the use of XML in the
+ protocol stack. Using XML at both the transport and network layer in
+ addition to the application layer would provide for an amazing amount
+ of power and flexibility while removing dependencies on proprietary
+ and hard-to-understand binary protocols. This protocol unification
+ would also allow applications to use a single XML parser for all
+ aspects of their operation, eliminating developer time spent figuring
+ out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy Informational [Page 1]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ parsing to the XML toolset. The use of XML also mitigates concerns
+ over "network vs. host" byte ordering which is at the root of many
+ network application bugs.
+
+1.3. Relation to Existing Protocols
+
+ The reformulations specified in this RFC follow as closely as
+ possible the spirit of the RFCs on which they are based, and so MAY
+ contain elements or attributes that would not be needed in a pure
+ reworking (e.g. length attributes, which are implicit in XML.)
+
+ The layering of network and transport protocols are maintained in
+ this RFC despite the optimizations that could be made if the line
+ were somewhat blurred (i.e. merging TCP and IP into a single, larger
+ element in the DTD) in order to foster future use of this protocol as
+ a basis for reformulating other protocols (such as ICMP.)
+
+ Other than the encoding, the behavioral aspects of each of the
+ existing protocols remain unchanged. Routing, address spaces, TCP
+ congestion control, etc. behave as specified in the extant standards.
+ Adapting to new standards and experimental algorithm heuristics for
+ improving performance will become much easier once the move to BLOAT
+ has been completed.
+
+1.4. Requirement Levels
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
+
+2. IPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC.
+ IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+ (section 3.) and higher-level application protocols.
+
+ The DTD for this document type can be found in section 7.1.
+
+ The routing of IPoXML can be easily implemented on hosts with an XML
+ parser, as the regular structure lends itself handily to parsing and
+ validation of the document/datagram and then processing the
+ destination address, TTL, and checksum before sending it on to its
+ next-hop.
+
+ The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+ wider deployment of IPv4 and the fact that implementing IPv6 as XML
+ would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy Informational [Page 2]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+ of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
+ formed and include the XMLDecl.
+
+2.1. IP Description
+
+ A number of items have changed (for the better) from the original IP
+ specification. Bit-masks, where present have been converted into
+ human-readable values. IP addresses are listed in their dotted-
+ decimal notation [RFC1123]. Length and checksum values are present
+ as decimal integers.
+
+ To calculate the length and checksum fields of the IP element, a
+ canonicalized form of the element MUST be used. The canonical form
+ SHALL have no whitespace (including newline characters) between
+ elements and only one space character between attributes. There
+ SHALL NOT be a space following the last attribute in an element.
+
+ An iterative method SHOULD be used to calculate checksums, as the
+ length field will vary based on the size of the checksum.
+
+ The payload element bears special attention. Due to the character
+ set restrictions of XML, the payload of IP datagrams (which MAY
+ contain arbitrary data) MUST be encoded for transport. This RFC
+ REQUIRES the contents of the payload to be encoded in the base-64
+ encoding of RFC 2045 [RFC2045], but removes the requirement that the
+ encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 3]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+2.2. Example Datagram
+
+ The following is an example IPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ <ip>
+ <header length="474">
+ <version value="4"/>
+ <tos precedence="Routine" delay="Normal" throughput="Normal"
+ relibility="Normal" reserved="0"/>
+ <total.length value="461"/>
+ <id value="1"/>
+ <flags reserved="0" df="dont" mf="last"/>
+ <offset value="0"/>
+ <ttl value="255"/>
+ <protocol value="6"/>
+ <checksum value="8707"/>
+ <source address="10.0.0.22"/>
+ <destination address="10.0.0.1"/>
+ <options>
+ <end copied="0" class="0" number="0"/>
+ </options>
+ <padding pad="0"/>
+ </header>
+ <payload>
+ </payload>
+ </ip>
+
+3. TCPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+ A number of items have changed from the original TCP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+ To calculate the length and checksum fields of the TCP element, a
+ canonicalized form of the element MUST be used as in section 2.1.
+
+ An iterative method SHOULD be used to calculate checksums as in
+ section 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy Informational [Page 4]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ The TCP offset element was expanded to a maximum of 255 from 16 to
+ allow for the increased size of the header in XML.
+
+ TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ <tcp>
+ <tcp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <sequence number="322622954"/>
+ <acknowledgement number="689715995"/>
+ <offset number=""/>
+ <reserved value="0"/>
+ <control syn="1" ack="1"/>
+ <window size="1"/>
+ <urgent pointer="0"/>
+ <checksum value="2988"/>
+ <tcp.options>
+ <tcp.end kind="0"/>
+ </tcp.options>
+ <padding pad="0"/>
+ </tcp.header>
+ <payload>
+ </payload>
+ </tcp>
+
+4. UDPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+ A number of items have changed from the original UDP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+
+
+
+
+
+
+Kennedy Informational [Page 5]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ To calculate the length and checksum fields of the UDP element, a
+ canonicalized form of the element MUST be used as in section 2.1. An
+ iterative method SHOULD be used to calculate checksums as in section
+ 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+ UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ <udp>
+ <udp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <udp.length value="143"/>
+ <checksum value="2988"/>
+ </udp.header>
+ <payload>
+ </payload>
+ </udp>
+
+5. Network Transport
+
+ This document provides for the transmission of BLOAT datagrams over
+ two common families of physical layer transport. Future RFCs will
+ address additional transports as routing vendors catch up to the
+ specification, and we begin to see BLOAT routed across the Internet
+ backbone.
+
+5.1. Ethernet
+
+ BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+ exception that the type field of the Ethernet frame MUST contain the
+ value 0xBEEF. The first 5 octets of the Ethernet frame payload will
+ be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+ BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+ that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy Informational [Page 6]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+6. Gatewaying over IP
+
+ In order to facilitate the gradual introduction of BLOAT into the
+ public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+ gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+ The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+ Network DTD (7.1.)
+
+ The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+ [XML]) although it is understood that most IPoXML implementations
+ will not need to pull down the DTD, as it will normally be embedded
+ in the implementation, and presents something of a catch-22 if you
+ need to load part of your network protocol over the network.
+
+7.1. IPoXML DTD
+
+ <!--
+ DTD for IP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ -->
+ <!--
+ DTD data types:
+
+ Digits [0..9]+
+
+ Precedence "NetworkControl | InternetworkControl |
+ CRITIC | FlashOverride | Flash | Immediate |
+ Priority | Routine"
+
+ IP4Addr "dotted-decimal" notation of [RFC1123]
+
+ Class [0..3]
+
+ Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
+ Restricted | Secret | Top Secret | Reserved"
+
+ Compartments [0..65535]
+
+ Handling [0..65535]
+
+ TCC [0..16777216]
+
+ -->
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ENTITY % Digits "CDATA">
+ <!ENTITY % Precedence "CDATA">
+ <!ENTITY % IP4Addr "CDATA">
+ <!ENTITY % Class "CDATA">
+ <!ENTITY % Sec "CDATA">
+ <!ENTITY % Compartments "CDATA">
+ <!ENTITY % Handling "CDATA">
+ <!ENTITY % TCC "CDATA">
+
+ <!ELEMENT ip (header, payload)>
+
+ <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+ protocol, checksum, source, destination, options,
+ padding)>
+ <!-- length of header in 32-bit words -->
+ <!ATTLIST header
+ length %Digits; #REQUIRED>
+
+ <!ELEMENT version EMPTY>
+ <!-- ip version. SHOULD be "4" -->
+ <!ATTLIST version
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT tos EMPTY>
+ <!ATTLIST tos
+ precedence %Precedence; #REQUIRED
+ delay (normal | low) #REQUIRED
+ throughput (normal | high) #REQUIRED
+ relibility (normal | high) #REQUIRED
+ reserved CDATA #FIXED "0">
+
+ <!ELEMENT total.length EMPTY>
+ <!--
+ total length of datagram (header and payload) in octets, MUST be
+ less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+ ethernets).
+ -->
+ <!ATTLIST total.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT id EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST id
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT flags EMPTY>
+ <!-- df = don't fragment, mf = more fragments -->
+ <!ATTLIST flags
+
+
+
+Kennedy Informational [Page 8]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ reserved CDATA #FIXED "0"
+ df (may|dont) #REQUIRED
+ mf (last|more) #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+ <!ATTLIST offset
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT ttl EMPTY>
+ <!-- 0 <= ttl <= 255 -->
+ <!ATTLIST ttl
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT protocol EMPTY>
+ <!-- 0 <= protocol <= 255 (per IANA) -->
+ <!ATTLIST protocol
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT checksum EMPTY>
+ <!-- 0 <= checksum <= 65535 (over header only) -->
+ <!ATTLIST checksum
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT source EMPTY>
+ <!ATTLIST source
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT destination EMPTY>
+ <!ATTLIST destination
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT options ( end | noop | security | loose | strict | record
+ | stream | timestamp )*>
+
+ <!ELEMENT end EMPTY>
+ <!ATTLIST end
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "0">
+
+ <!ELEMENT noop EMPTY>
+ <!ATTLIST noop
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "1">
+
+ <!ELEMENT security EMPTY>
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST security
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "2"
+ length CDATA #FIXED "11"
+ security %Sec; #REQUIRED
+ compartments %Compartments; #REQUIRED
+ handling %Handling; #REQUIRED
+ tcc %TCC; #REQUIRED>
+ <!ELEMENT loose (hop)+>
+ <!ATTLIST loose
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "3"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT hop EMPTY>
+ <!ATTLIST hop
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT strict (hop)+>
+ <!ATTLIST strict
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "9"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT record (hop)+>
+ <!ATTLIST record
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "7"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT stream EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST stream
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "8"
+ length CDATA #FIXED "4"
+ id %Digits; #REQUIRED>
+
+ <!ELEMENT timestamp (tstamp)+>
+ <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST timestamp
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "2"
+ number CDATA #FIXED "4"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED
+ oflw %Digits; #REQUIRED
+ flag (0 | 1 | 3) #REQUIRED>
+
+ <!ELEMENT tstamp EMPTY>
+ <!ATTLIST tstamp
+ time %Digits; #REQUIRED
+ address %IP4Addr; #IMPLIED>
+ <!--
+ padding to bring header to 32-bit boundary.
+ pad MUST be "0"*
+ -->
+ <!ELEMENT padding EMPTY>
+ <!ATTLIST padding
+ pad CDATA #REQUIRED>
+
+ <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+ by section 2.1 of this RFC -->
+ <!ELEMENT payload (CDATA)>
+
+7.2. TCPoXML DTD
+
+ <!--
+ DTD for TCP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ -->
+
+ <!-- the pseudoheader is only included for checksum calculations -->
+ <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+ <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+ reserved, control, window, checksum, urgent,
+ tcp.options, padding)>
+
+ <!ELEMENT src EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+ <!ATTLIST src
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT dest EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST dest
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT sequence EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST sequence
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT acknowledgement EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST acknowledgement
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= number <= 255 -->
+ <!ATTLIST offset
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT reserved EMPTY>
+ <!ATTLIST reserved
+ value CDATA #FIXED "0">
+
+ <!ELEMENT control EMPTY>
+ <!ATTLIST control
+ urg (0|1) #IMPLIED
+ ack (0|1) #IMPLIED
+ psh (0|1) #IMPLIED
+ rst (0|1) #IMPLIED
+ syn (0|1) #IMPLIED
+ fin (0|1) #IMPLIED>
+
+ <!ELEMENT window EMPTY>
+ <!-- 0 <= size <= 65,535 -->
+ <!ATTLIST window
+ size %Digits; #REQUIRED>
+
+ <!--
+ checksum as in ip, but with
+ the following pseudo-header added into the tcp element:
+ -->
+ <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+ tcp.length)>
+
+ <!--
+ tcp header + data length in octets. does not include the size of
+
+ the pseudoheader.
+ -->
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ELEMENT tcp.length EMPTY>
+ <!ATTLIST tcp.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT urgent EMPTY>
+ <!-- 0 <= pointer <= 65,535 -->
+ <!ATTLIST urgent
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+ <!ELEMENT tcp.end EMPTY>
+ <!ATTLIST tcp.end
+ kind CDATA #FIXED "0">
+
+ <!ELEMENT tcp.noop EMPTY>
+ <!ATTLIST tcp.noop
+ kind CDATA #FIXED "1">
+
+ <!ELEMENT tcp.mss EMPTY>
+ <!ATTLIST tcp.mss
+ kind CDATA #FIXED "2"
+ length CDATA #FIXED "4"
+ size %Digits; #REQUIRED>
+
+7.3. UDPoXML DTD
+
+ <!--
+ DTD for UDP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ -->
+
+ <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+ <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+ <!ELEMENT udp.pseudoheader (source, destination, protocol,
+ udp.length)>
+
+ <!--
+ udp header + data length in octets. does not include the size of
+ the pseudoheader.
+ -->
+ <!ELEMENT udp.length EMPTY>
+ <!ATTLIST udp.length
+ value %Digits; #REQUIRED>
+
+
+
+Kennedy Informational [Page 13]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+8. Security Considerations
+
+ XML, as a subset of SGML, has the same security considerations as
+ specified in SGML Media Types [RFC1874]. Security considerations
+ that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+ not attempt to correct for issues not related to message format.
+
+9. References
+
+ [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
+ February 2002. (Work in Progress)
+
+ [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
+ 793, September 1981.
+
+ [RFC894] Hornig, C., "Standard for the Transmission of IP
+ Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+ [RFC1042] Postel, J. and J. Reynolds, "Standard for the
+ Transmission of IP Datagrams Over IEEE 802 Networks", STD
+ 43, RFC 1042, February 1988.
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts -
+ Application and Support", RFC 1123, October 1989.
+
+ [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
+ 1995.
+
+ [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
+ October 1996.
+
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy Informational [Page 14]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
+ RFC 3080, March 2001.
+
+ [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+ Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+ "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+ Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+ Markup Language (XML)" World Wide Web Consortium
+ Recommendation REC- xml-19980210.
+ http://www.w3.org/TR/1998/REC-xml-19980210
+
+10. Author's Address
+
+ Hugh Kennedy
+ Mimezine
+ 1060 West Addison
+ Chicago, IL 60613
+ USA
+
+ EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 15]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 16]
+
+
+
+
+
+
+
+Network Working Group H. Kennedy
+Request for Comments: 3252 Mimezine
+Category: Informational 1 April 2002
+
+
+ Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document defines a reformulation of IP and two transport layer
+ protocols (TCP and UDP) as XML applications.
+
+1. Introduction
+
+1.1. Overview
+
+ This document describes the Binary Lexical Octet Ad-hoc Transport
+ (BLOAT): a reformulation of a widely-deployed network-layer protocol
+ (IP [RFC791]), and two associated transport layer protocols (TCP
+ [RFC793] and UDP [RFC768]) as XML [XML] applications. It also
+ describes methods for transporting BLOAT over Ethernet and IEEE 802
+ networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+ across the public Internet.
+
+1.2. Motivation
+
+ The wild popularity of XML as a basis for application-level protocols
+ such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+ Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+ investigation into the possibility of extending the use of XML in the
+ protocol stack. Using XML at both the transport and network layer in
+ addition to the application layer would provide for an amazing amount
+ of power and flexibility while removing dependencies on proprietary
+ and hard-to-understand binary protocols. This protocol unification
+ would also allow applications to use a single XML parser for all
+ aspects of their operation, eliminating developer time spent figuring
+ out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy Informational [Page 1]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ parsing to the XML toolset. The use of XML also mitigates concerns
+ over "network vs. host" byte ordering which is at the root of many
+ network application bugs.
+
+1.3. Relation to Existing Protocols
+
+ The reformulations specified in this RFC follow as closely as
+ possible the spirit of the RFCs on which they are based, and so MAY
+ contain elements or attributes that would not be needed in a pure
+ reworking (e.g. length attributes, which are implicit in XML.)
+
+ The layering of network and transport protocols are maintained in
+ this RFC despite the optimizations that could be made if the line
+ were somewhat blurred (i.e. merging TCP and IP into a single, larger
+ element in the DTD) in order to foster future use of this protocol as
+ a basis for reformulating other protocols (such as ICMP.)
+
+ Other than the encoding, the behavioral aspects of each of the
+ existing protocols remain unchanged. Routing, address spaces, TCP
+ congestion control, etc. behave as specified in the extant standards.
+ Adapting to new standards and experimental algorithm heuristics for
+ improving performance will become much easier once the move to BLOAT
+ has been completed.
+
+1.4. Requirement Levels
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
+
+2. IPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC.
+ IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+ (section 3.) and higher-level application protocols.
+
+ The DTD for this document type can be found in section 7.1.
+
+ The routing of IPoXML can be easily implemented on hosts with an XML
+ parser, as the regular structure lends itself handily to parsing and
+ validation of the document/datagram and then processing the
+ destination address, TTL, and checksum before sending it on to its
+ next-hop.
+
+ The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+ wider deployment of IPv4 and the fact that implementing IPv6 as XML
+ would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy Informational [Page 2]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+ of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
+ formed and include the XMLDecl.
+
+2.1. IP Description
+
+ A number of items have changed (for the better) from the original IP
+ specification. Bit-masks, where present have been converted into
+ human-readable values. IP addresses are listed in their dotted-
+ decimal notation [RFC1123]. Length and checksum values are present
+ as decimal integers.
+
+ To calculate the length and checksum fields of the IP element, a
+ canonicalized form of the element MUST be used. The canonical form
+ SHALL have no whitespace (including newline characters) between
+ elements and only one space character between attributes. There
+ SHALL NOT be a space following the last attribute in an element.
+
+ An iterative method SHOULD be used to calculate checksums, as the
+ length field will vary based on the size of the checksum.
+
+ The payload element bears special attention. Due to the character
+ set restrictions of XML, the payload of IP datagrams (which MAY
+ contain arbitrary data) MUST be encoded for transport. This RFC
+ REQUIRES the contents of the payload to be encoded in the base-64
+ encoding of RFC 2045 [RFC2045], but removes the requirement that the
+ encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 3]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+2.2. Example Datagram
+
+ The following is an example IPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ <ip>
+ <header length="474">
+ <version value="4"/>
+ <tos precedence="Routine" delay="Normal" throughput="Normal"
+ relibility="Normal" reserved="0"/>
+ <total.length value="461"/>
+ <id value="1"/>
+ <flags reserved="0" df="dont" mf="last"/>
+ <offset value="0"/>
+ <ttl value="255"/>
+ <protocol value="6"/>
+ <checksum value="8707"/>
+ <source address="10.0.0.22"/>
+ <destination address="10.0.0.1"/>
+ <options>
+ <end copied="0" class="0" number="0"/>
+ </options>
+ <padding pad="0"/>
+ </header>
+ <payload>
+ </payload>
+ </ip>
+
+3. TCPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+ A number of items have changed from the original TCP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+ To calculate the length and checksum fields of the TCP element, a
+ canonicalized form of the element MUST be used as in section 2.1.
+
+ An iterative method SHOULD be used to calculate checksums as in
+ section 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy Informational [Page 4]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ The TCP offset element was expanded to a maximum of 255 from 16 to
+ allow for the increased size of the header in XML.
+
+ TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ <tcp>
+ <tcp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <sequence number="322622954"/>
+ <acknowledgement number="689715995"/>
+ <offset number=""/>
+ <reserved value="0"/>
+ <control syn="1" ack="1"/>
+ <window size="1"/>
+ <urgent pointer="0"/>
+ <checksum value="2988"/>
+ <tcp.options>
+ <tcp.end kind="0"/>
+ </tcp.options>
+ <padding pad="0"/>
+ </tcp.header>
+ <payload>
+ </payload>
+ </tcp>
+
+4. UDPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+ A number of items have changed from the original UDP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+
+
+
+
+
+
+Kennedy Informational [Page 5]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ To calculate the length and checksum fields of the UDP element, a
+ canonicalized form of the element MUST be used as in section 2.1. An
+ iterative method SHOULD be used to calculate checksums as in section
+ 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+ UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ <udp>
+ <udp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <udp.length value="143"/>
+ <checksum value="2988"/>
+ </udp.header>
+ <payload>
+ </payload>
+ </udp>
+
+5. Network Transport
+
+ This document provides for the transmission of BLOAT datagrams over
+ two common families of physical layer transport. Future RFCs will
+ address additional transports as routing vendors catch up to the
+ specification, and we begin to see BLOAT routed across the Internet
+ backbone.
+
+5.1. Ethernet
+
+ BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+ exception that the type field of the Ethernet frame MUST contain the
+ value 0xBEEF. The first 5 octets of the Ethernet frame payload will
+ be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+ BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+ that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy Informational [Page 6]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+6. Gatewaying over IP
+
+ In order to facilitate the gradual introduction of BLOAT into the
+ public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+ gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+ The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+ Network DTD (7.1.)
+
+ The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+ [XML]) although it is understood that most IPoXML implementations
+ will not need to pull down the DTD, as it will normally be embedded
+ in the implementation, and presents something of a catch-22 if you
+ need to load part of your network protocol over the network.
+
+7.1. IPoXML DTD
+
+ <!--
+ DTD for IP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ -->
+ <!--
+ DTD data types:
+
+ Digits [0..9]+
+
+ Precedence "NetworkControl | InternetworkControl |
+ CRITIC | FlashOverride | Flash | Immediate |
+ Priority | Routine"
+
+ IP4Addr "dotted-decimal" notation of [RFC1123]
+
+ Class [0..3]
+
+ Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
+ Restricted | Secret | Top Secret | Reserved"
+
+ Compartments [0..65535]
+
+ Handling [0..65535]
+
+ TCC [0..16777216]
+
+ -->
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ENTITY % Digits "CDATA">
+ <!ENTITY % Precedence "CDATA">
+ <!ENTITY % IP4Addr "CDATA">
+ <!ENTITY % Class "CDATA">
+ <!ENTITY % Sec "CDATA">
+ <!ENTITY % Compartments "CDATA">
+ <!ENTITY % Handling "CDATA">
+ <!ENTITY % TCC "CDATA">
+
+ <!ELEMENT ip (header, payload)>
+
+ <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+ protocol, checksum, source, destination, options,
+ padding)>
+ <!-- length of header in 32-bit words -->
+ <!ATTLIST header
+ length %Digits; #REQUIRED>
+
+ <!ELEMENT version EMPTY>
+ <!-- ip version. SHOULD be "4" -->
+ <!ATTLIST version
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT tos EMPTY>
+ <!ATTLIST tos
+ precedence %Precedence; #REQUIRED
+ delay (normal | low) #REQUIRED
+ throughput (normal | high) #REQUIRED
+ relibility (normal | high) #REQUIRED
+ reserved CDATA #FIXED "0">
+
+ <!ELEMENT total.length EMPTY>
+ <!--
+ total length of datagram (header and payload) in octets, MUST be
+ less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+ ethernets).
+ -->
+ <!ATTLIST total.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT id EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST id
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT flags EMPTY>
+ <!-- df = don't fragment, mf = more fragments -->
+ <!ATTLIST flags
+
+
+
+Kennedy Informational [Page 8]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ reserved CDATA #FIXED "0"
+ df (may|dont) #REQUIRED
+ mf (last|more) #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+ <!ATTLIST offset
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT ttl EMPTY>
+ <!-- 0 <= ttl <= 255 -->
+ <!ATTLIST ttl
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT protocol EMPTY>
+ <!-- 0 <= protocol <= 255 (per IANA) -->
+ <!ATTLIST protocol
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT checksum EMPTY>
+ <!-- 0 <= checksum <= 65535 (over header only) -->
+ <!ATTLIST checksum
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT source EMPTY>
+ <!ATTLIST source
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT destination EMPTY>
+ <!ATTLIST destination
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT options ( end | noop | security | loose | strict | record
+ | stream | timestamp )*>
+
+ <!ELEMENT end EMPTY>
+ <!ATTLIST end
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "0">
+
+ <!ELEMENT noop EMPTY>
+ <!ATTLIST noop
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "1">
+
+ <!ELEMENT security EMPTY>
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST security
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "2"
+ length CDATA #FIXED "11"
+ security %Sec; #REQUIRED
+ compartments %Compartments; #REQUIRED
+ handling %Handling; #REQUIRED
+ tcc %TCC; #REQUIRED>
+ <!ELEMENT loose (hop)+>
+ <!ATTLIST loose
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "3"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT hop EMPTY>
+ <!ATTLIST hop
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT strict (hop)+>
+ <!ATTLIST strict
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "9"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT record (hop)+>
+ <!ATTLIST record
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "7"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT stream EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST stream
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "8"
+ length CDATA #FIXED "4"
+ id %Digits; #REQUIRED>
+
+ <!ELEMENT timestamp (tstamp)+>
+ <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST timestamp
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "2"
+ number CDATA #FIXED "4"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED
+ oflw %Digits; #REQUIRED
+ flag (0 | 1 | 3) #REQUIRED>
+
+ <!ELEMENT tstamp EMPTY>
+ <!ATTLIST tstamp
+ time %Digits; #REQUIRED
+ address %IP4Addr; #IMPLIED>
+ <!--
+ padding to bring header to 32-bit boundary.
+ pad MUST be "0"*
+ -->
+ <!ELEMENT padding EMPTY>
+ <!ATTLIST padding
+ pad CDATA #REQUIRED>
+
+ <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+ by section 2.1 of this RFC -->
+ <!ELEMENT payload (CDATA)>
+
+7.2. TCPoXML DTD
+
+ <!--
+ DTD for TCP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ -->
+
+ <!-- the pseudoheader is only included for checksum calculations -->
+ <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+ <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+ reserved, control, window, checksum, urgent,
+ tcp.options, padding)>
+
+ <!ELEMENT src EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+ <!ATTLIST src
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT dest EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST dest
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT sequence EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST sequence
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT acknowledgement EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST acknowledgement
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= number <= 255 -->
+ <!ATTLIST offset
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT reserved EMPTY>
+ <!ATTLIST reserved
+ value CDATA #FIXED "0">
+
+ <!ELEMENT control EMPTY>
+ <!ATTLIST control
+ urg (0|1) #IMPLIED
+ ack (0|1) #IMPLIED
+ psh (0|1) #IMPLIED
+ rst (0|1) #IMPLIED
+ syn (0|1) #IMPLIED
+ fin (0|1) #IMPLIED>
+
+ <!ELEMENT window EMPTY>
+ <!-- 0 <= size <= 65,535 -->
+ <!ATTLIST window
+ size %Digits; #REQUIRED>
+
+ <!--
+ checksum as in ip, but with
+ the following pseudo-header added into the tcp element:
+ -->
+ <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+ tcp.length)>
+
+ <!--
+ tcp header + data length in octets. does not include the size of
+
+ the pseudoheader.
+ -->
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ELEMENT tcp.length EMPTY>
+ <!ATTLIST tcp.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT urgent EMPTY>
+ <!-- 0 <= pointer <= 65,535 -->
+ <!ATTLIST urgent
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+ <!ELEMENT tcp.end EMPTY>
+ <!ATTLIST tcp.end
+ kind CDATA #FIXED "0">
+
+ <!ELEMENT tcp.noop EMPTY>
+ <!ATTLIST tcp.noop
+ kind CDATA #FIXED "1">
+
+ <!ELEMENT tcp.mss EMPTY>
+ <!ATTLIST tcp.mss
+ kind CDATA #FIXED "2"
+ length CDATA #FIXED "4"
+ size %Digits; #REQUIRED>
+
+7.3. UDPoXML DTD
+
+ <!--
+ DTD for UDP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ -->
+
+ <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+ <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+ <!ELEMENT udp.pseudoheader (source, destination, protocol,
+ udp.length)>
+
+ <!--
+ udp header + data length in octets. does not include the size of
+ the pseudoheader.
+ -->
+ <!ELEMENT udp.length EMPTY>
+ <!ATTLIST udp.length
+ value %Digits; #REQUIRED>
+
+
+
+Kennedy Informational [Page 13]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+8. Security Considerations
+
+ XML, as a subset of SGML, has the same security considerations as
+ specified in SGML Media Types [RFC1874]. Security considerations
+ that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+ not attempt to correct for issues not related to message format.
+
+9. References
+
+ [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
+ February 2002. (Work in Progress)
+
+ [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
+ 793, September 1981.
+
+ [RFC894] Hornig, C., "Standard for the Transmission of IP
+ Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+ [RFC1042] Postel, J. and J. Reynolds, "Standard for the
+ Transmission of IP Datagrams Over IEEE 802 Networks", STD
+ 43, RFC 1042, February 1988.
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts -
+ Application and Support", RFC 1123, October 1989.
+
+ [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
+ 1995.
+
+ [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
+ October 1996.
+
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy Informational [Page 14]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
+ RFC 3080, March 2001.
+
+ [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+ Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+ "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+ Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+ Markup Language (XML)" World Wide Web Consortium
+ Recommendation REC- xml-19980210.
+ http://www.w3.org/TR/1998/REC-xml-19980210
+
+10. Author's Address
+
+ Hugh Kennedy
+ Mimezine
+ 1060 West Addison
+ Chicago, IL 60613
+ USA
+
+ EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 15]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 16]
+
+
+
+
+
+
+
+Network Working Group H. Kennedy
+Request for Comments: 3252 Mimezine
+Category: Informational 1 April 2002
+
+
+ Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document defines a reformulation of IP and two transport layer
+ protocols (TCP and UDP) as XML applications.
+
+1. Introduction
+
+1.1. Overview
+
+ This document describes the Binary Lexical Octet Ad-hoc Transport
+ (BLOAT): a reformulation of a widely-deployed network-layer protocol
+ (IP [RFC791]), and two associated transport layer protocols (TCP
+ [RFC793] and UDP [RFC768]) as XML [XML] applications. It also
+ describes methods for transporting BLOAT over Ethernet and IEEE 802
+ networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+ across the public Internet.
+
+1.2. Motivation
+
+ The wild popularity of XML as a basis for application-level protocols
+ such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+ Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+ investigation into the possibility of extending the use of XML in the
+ protocol stack. Using XML at both the transport and network layer in
+ addition to the application layer would provide for an amazing amount
+ of power and flexibility while removing dependencies on proprietary
+ and hard-to-understand binary protocols. This protocol unification
+ would also allow applications to use a single XML parser for all
+ aspects of their operation, eliminating developer time spent figuring
+ out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy Informational [Page 1]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ parsing to the XML toolset. The use of XML also mitigates concerns
+ over "network vs. host" byte ordering which is at the root of many
+ network application bugs.
+
+1.3. Relation to Existing Protocols
+
+ The reformulations specified in this RFC follow as closely as
+ possible the spirit of the RFCs on which they are based, and so MAY
+ contain elements or attributes that would not be needed in a pure
+ reworking (e.g. length attributes, which are implicit in XML.)
+
+ The layering of network and transport protocols are maintained in
+ this RFC despite the optimizations that could be made if the line
+ were somewhat blurred (i.e. merging TCP and IP into a single, larger
+ element in the DTD) in order to foster future use of this protocol as
+ a basis for reformulating other protocols (such as ICMP.)
+
+ Other than the encoding, the behavioral aspects of each of the
+ existing protocols remain unchanged. Routing, address spaces, TCP
+ congestion control, etc. behave as specified in the extant standards.
+ Adapting to new standards and experimental algorithm heuristics for
+ improving performance will become much easier once the move to BLOAT
+ has been completed.
+
+1.4. Requirement Levels
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
+
+2. IPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC.
+ IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+ (section 3.) and higher-level application protocols.
+
+ The DTD for this document type can be found in section 7.1.
+
+ The routing of IPoXML can be easily implemented on hosts with an XML
+ parser, as the regular structure lends itself handily to parsing and
+ validation of the document/datagram and then processing the
+ destination address, TTL, and checksum before sending it on to its
+ next-hop.
+
+ The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+ wider deployment of IPv4 and the fact that implementing IPv6 as XML
+ would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy Informational [Page 2]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+ of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
+ formed and include the XMLDecl.
+
+2.1. IP Description
+
+ A number of items have changed (for the better) from the original IP
+ specification. Bit-masks, where present have been converted into
+ human-readable values. IP addresses are listed in their dotted-
+ decimal notation [RFC1123]. Length and checksum values are present
+ as decimal integers.
+
+ To calculate the length and checksum fields of the IP element, a
+ canonicalized form of the element MUST be used. The canonical form
+ SHALL have no whitespace (including newline characters) between
+ elements and only one space character between attributes. There
+ SHALL NOT be a space following the last attribute in an element.
+
+ An iterative method SHOULD be used to calculate checksums, as the
+ length field will vary based on the size of the checksum.
+
+ The payload element bears special attention. Due to the character
+ set restrictions of XML, the payload of IP datagrams (which MAY
+ contain arbitrary data) MUST be encoded for transport. This RFC
+ REQUIRES the contents of the payload to be encoded in the base-64
+ encoding of RFC 2045 [RFC2045], but removes the requirement that the
+ encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 3]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+2.2. Example Datagram
+
+ The following is an example IPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ <ip>
+ <header length="474">
+ <version value="4"/>
+ <tos precedence="Routine" delay="Normal" throughput="Normal"
+ relibility="Normal" reserved="0"/>
+ <total.length value="461"/>
+ <id value="1"/>
+ <flags reserved="0" df="dont" mf="last"/>
+ <offset value="0"/>
+ <ttl value="255"/>
+ <protocol value="6"/>
+ <checksum value="8707"/>
+ <source address="10.0.0.22"/>
+ <destination address="10.0.0.1"/>
+ <options>
+ <end copied="0" class="0" number="0"/>
+ </options>
+ <padding pad="0"/>
+ </header>
+ <payload>
+ </payload>
+ </ip>
+
+3. TCPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+ A number of items have changed from the original TCP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+ To calculate the length and checksum fields of the TCP element, a
+ canonicalized form of the element MUST be used as in section 2.1.
+
+ An iterative method SHOULD be used to calculate checksums as in
+ section 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy Informational [Page 4]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ The TCP offset element was expanded to a maximum of 255 from 16 to
+ allow for the increased size of the header in XML.
+
+ TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ <tcp>
+ <tcp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <sequence number="322622954"/>
+ <acknowledgement number="689715995"/>
+ <offset number=""/>
+ <reserved value="0"/>
+ <control syn="1" ack="1"/>
+ <window size="1"/>
+ <urgent pointer="0"/>
+ <checksum value="2988"/>
+ <tcp.options>
+ <tcp.end kind="0"/>
+ </tcp.options>
+ <padding pad="0"/>
+ </tcp.header>
+ <payload>
+ </payload>
+ </tcp>
+
+4. UDPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+ A number of items have changed from the original UDP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+
+
+
+
+
+
+Kennedy Informational [Page 5]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ To calculate the length and checksum fields of the UDP element, a
+ canonicalized form of the element MUST be used as in section 2.1. An
+ iterative method SHOULD be used to calculate checksums as in section
+ 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+ UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ <udp>
+ <udp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <udp.length value="143"/>
+ <checksum value="2988"/>
+ </udp.header>
+ <payload>
+ </payload>
+ </udp>
+
+5. Network Transport
+
+ This document provides for the transmission of BLOAT datagrams over
+ two common families of physical layer transport. Future RFCs will
+ address additional transports as routing vendors catch up to the
+ specification, and we begin to see BLOAT routed across the Internet
+ backbone.
+
+5.1. Ethernet
+
+ BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+ exception that the type field of the Ethernet frame MUST contain the
+ value 0xBEEF. The first 5 octets of the Ethernet frame payload will
+ be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+ BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+ that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy Informational [Page 6]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+6. Gatewaying over IP
+
+ In order to facilitate the gradual introduction of BLOAT into the
+ public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+ gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+ The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+ Network DTD (7.1.)
+
+ The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+ [XML]) although it is understood that most IPoXML implementations
+ will not need to pull down the DTD, as it will normally be embedded
+ in the implementation, and presents something of a catch-22 if you
+ need to load part of your network protocol over the network.
+
+7.1. IPoXML DTD
+
+ <!--
+ DTD for IP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ -->
+ <!--
+ DTD data types:
+
+ Digits [0..9]+
+
+ Precedence "NetworkControl | InternetworkControl |
+ CRITIC | FlashOverride | Flash | Immediate |
+ Priority | Routine"
+
+ IP4Addr "dotted-decimal" notation of [RFC1123]
+
+ Class [0..3]
+
+ Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
+ Restricted | Secret | Top Secret | Reserved"
+
+ Compartments [0..65535]
+
+ Handling [0..65535]
+
+ TCC [0..16777216]
+
+ -->
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ENTITY % Digits "CDATA">
+ <!ENTITY % Precedence "CDATA">
+ <!ENTITY % IP4Addr "CDATA">
+ <!ENTITY % Class "CDATA">
+ <!ENTITY % Sec "CDATA">
+ <!ENTITY % Compartments "CDATA">
+ <!ENTITY % Handling "CDATA">
+ <!ENTITY % TCC "CDATA">
+
+ <!ELEMENT ip (header, payload)>
+
+ <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+ protocol, checksum, source, destination, options,
+ padding)>
+ <!-- length of header in 32-bit words -->
+ <!ATTLIST header
+ length %Digits; #REQUIRED>
+
+ <!ELEMENT version EMPTY>
+ <!-- ip version. SHOULD be "4" -->
+ <!ATTLIST version
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT tos EMPTY>
+ <!ATTLIST tos
+ precedence %Precedence; #REQUIRED
+ delay (normal | low) #REQUIRED
+ throughput (normal | high) #REQUIRED
+ relibility (normal | high) #REQUIRED
+ reserved CDATA #FIXED "0">
+
+ <!ELEMENT total.length EMPTY>
+ <!--
+ total length of datagram (header and payload) in octets, MUST be
+ less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+ ethernets).
+ -->
+ <!ATTLIST total.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT id EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST id
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT flags EMPTY>
+ <!-- df = don't fragment, mf = more fragments -->
+ <!ATTLIST flags
+
+
+
+Kennedy Informational [Page 8]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ reserved CDATA #FIXED "0"
+ df (may|dont) #REQUIRED
+ mf (last|more) #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+ <!ATTLIST offset
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT ttl EMPTY>
+ <!-- 0 <= ttl <= 255 -->
+ <!ATTLIST ttl
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT protocol EMPTY>
+ <!-- 0 <= protocol <= 255 (per IANA) -->
+ <!ATTLIST protocol
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT checksum EMPTY>
+ <!-- 0 <= checksum <= 65535 (over header only) -->
+ <!ATTLIST checksum
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT source EMPTY>
+ <!ATTLIST source
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT destination EMPTY>
+ <!ATTLIST destination
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT options ( end | noop | security | loose | strict | record
+ | stream | timestamp )*>
+
+ <!ELEMENT end EMPTY>
+ <!ATTLIST end
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "0">
+
+ <!ELEMENT noop EMPTY>
+ <!ATTLIST noop
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "1">
+
+ <!ELEMENT security EMPTY>
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST security
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "2"
+ length CDATA #FIXED "11"
+ security %Sec; #REQUIRED
+ compartments %Compartments; #REQUIRED
+ handling %Handling; #REQUIRED
+ tcc %TCC; #REQUIRED>
+ <!ELEMENT loose (hop)+>
+ <!ATTLIST loose
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "3"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT hop EMPTY>
+ <!ATTLIST hop
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT strict (hop)+>
+ <!ATTLIST strict
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "9"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT record (hop)+>
+ <!ATTLIST record
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "7"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT stream EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST stream
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "8"
+ length CDATA #FIXED "4"
+ id %Digits; #REQUIRED>
+
+ <!ELEMENT timestamp (tstamp)+>
+ <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST timestamp
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "2"
+ number CDATA #FIXED "4"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED
+ oflw %Digits; #REQUIRED
+ flag (0 | 1 | 3) #REQUIRED>
+
+ <!ELEMENT tstamp EMPTY>
+ <!ATTLIST tstamp
+ time %Digits; #REQUIRED
+ address %IP4Addr; #IMPLIED>
+ <!--
+ padding to bring header to 32-bit boundary.
+ pad MUST be "0"*
+ -->
+ <!ELEMENT padding EMPTY>
+ <!ATTLIST padding
+ pad CDATA #REQUIRED>
+
+ <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+ by section 2.1 of this RFC -->
+ <!ELEMENT payload (CDATA)>
+
+7.2. TCPoXML DTD
+
+ <!--
+ DTD for TCP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ -->
+
+ <!-- the pseudoheader is only included for checksum calculations -->
+ <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+ <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+ reserved, control, window, checksum, urgent,
+ tcp.options, padding)>
+
+ <!ELEMENT src EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+ <!ATTLIST src
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT dest EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST dest
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT sequence EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST sequence
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT acknowledgement EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST acknowledgement
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= number <= 255 -->
+ <!ATTLIST offset
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT reserved EMPTY>
+ <!ATTLIST reserved
+ value CDATA #FIXED "0">
+
+ <!ELEMENT control EMPTY>
+ <!ATTLIST control
+ urg (0|1) #IMPLIED
+ ack (0|1) #IMPLIED
+ psh (0|1) #IMPLIED
+ rst (0|1) #IMPLIED
+ syn (0|1) #IMPLIED
+ fin (0|1) #IMPLIED>
+
+ <!ELEMENT window EMPTY>
+ <!-- 0 <= size <= 65,535 -->
+ <!ATTLIST window
+ size %Digits; #REQUIRED>
+
+ <!--
+ checksum as in ip, but with
+ the following pseudo-header added into the tcp element:
+ -->
+ <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+ tcp.length)>
+
+ <!--
+ tcp header + data length in octets. does not include the size of
+
+ the pseudoheader.
+ -->
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ELEMENT tcp.length EMPTY>
+ <!ATTLIST tcp.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT urgent EMPTY>
+ <!-- 0 <= pointer <= 65,535 -->
+ <!ATTLIST urgent
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+ <!ELEMENT tcp.end EMPTY>
+ <!ATTLIST tcp.end
+ kind CDATA #FIXED "0">
+
+ <!ELEMENT tcp.noop EMPTY>
+ <!ATTLIST tcp.noop
+ kind CDATA #FIXED "1">
+
+ <!ELEMENT tcp.mss EMPTY>
+ <!ATTLIST tcp.mss
+ kind CDATA #FIXED "2"
+ length CDATA #FIXED "4"
+ size %Digits; #REQUIRED>
+
+7.3. UDPoXML DTD
+
+ <!--
+ DTD for UDP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ -->
+
+ <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+ <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+ <!ELEMENT udp.pseudoheader (source, destination, protocol,
+ udp.length)>
+
+ <!--
+ udp header + data length in octets. does not include the size of
+ the pseudoheader.
+ -->
+ <!ELEMENT udp.length EMPTY>
+ <!ATTLIST udp.length
+ value %Digits; #REQUIRED>
+
+
+
+Kennedy Informational [Page 13]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+8. Security Considerations
+
+ XML, as a subset of SGML, has the same security considerations as
+ specified in SGML Media Types [RFC1874]. Security considerations
+ that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+ not attempt to correct for issues not related to message format.
+
+9. References
+
+ [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
+ February 2002. (Work in Progress)
+
+ [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
+ 793, September 1981.
+
+ [RFC894] Hornig, C., "Standard for the Transmission of IP
+ Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+ [RFC1042] Postel, J. and J. Reynolds, "Standard for the
+ Transmission of IP Datagrams Over IEEE 802 Networks", STD
+ 43, RFC 1042, February 1988.
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts -
+ Application and Support", RFC 1123, October 1989.
+
+ [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
+ 1995.
+
+ [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
+ October 1996.
+
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy Informational [Page 14]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
+ RFC 3080, March 2001.
+
+ [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+ Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+ "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+ Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+ Markup Language (XML)" World Wide Web Consortium
+ Recommendation REC- xml-19980210.
+ http://www.w3.org/TR/1998/REC-xml-19980210
+
+10. Author's Address
+
+ Hugh Kennedy
+ Mimezine
+ 1060 West Addison
+ Chicago, IL 60613
+ USA
+
+ EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 15]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 16]
+
+
+
+
+
+
+
+Network Working Group H. Kennedy
+Request for Comments: 3252 Mimezine
+Category: Informational 1 April 2002
+
+
+ Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document defines a reformulation of IP and two transport layer
+ protocols (TCP and UDP) as XML applications.
+
+1. Introduction
+
+1.1. Overview
+
+ This document describes the Binary Lexical Octet Ad-hoc Transport
+ (BLOAT): a reformulation of a widely-deployed network-layer protocol
+ (IP [RFC791]), and two associated transport layer protocols (TCP
+ [RFC793] and UDP [RFC768]) as XML [XML] applications. It also
+ describes methods for transporting BLOAT over Ethernet and IEEE 802
+ networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+ across the public Internet.
+
+1.2. Motivation
+
+ The wild popularity of XML as a basis for application-level protocols
+ such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+ Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+ investigation into the possibility of extending the use of XML in the
+ protocol stack. Using XML at both the transport and network layer in
+ addition to the application layer would provide for an amazing amount
+ of power and flexibility while removing dependencies on proprietary
+ and hard-to-understand binary protocols. This protocol unification
+ would also allow applications to use a single XML parser for all
+ aspects of their operation, eliminating developer time spent figuring
+ out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy Informational [Page 1]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ parsing to the XML toolset. The use of XML also mitigates concerns
+ over "network vs. host" byte ordering which is at the root of many
+ network application bugs.
+
+1.3. Relation to Existing Protocols
+
+ The reformulations specified in this RFC follow as closely as
+ possible the spirit of the RFCs on which they are based, and so MAY
+ contain elements or attributes that would not be needed in a pure
+ reworking (e.g. length attributes, which are implicit in XML.)
+
+ The layering of network and transport protocols are maintained in
+ this RFC despite the optimizations that could be made if the line
+ were somewhat blurred (i.e. merging TCP and IP into a single, larger
+ element in the DTD) in order to foster future use of this protocol as
+ a basis for reformulating other protocols (such as ICMP.)
+
+ Other than the encoding, the behavioral aspects of each of the
+ existing protocols remain unchanged. Routing, address spaces, TCP
+ congestion control, etc. behave as specified in the extant standards.
+ Adapting to new standards and experimental algorithm heuristics for
+ improving performance will become much easier once the move to BLOAT
+ has been completed.
+
+1.4. Requirement Levels
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
+
+2. IPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC.
+ IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+ (section 3.) and higher-level application protocols.
+
+ The DTD for this document type can be found in section 7.1.
+
+ The routing of IPoXML can be easily implemented on hosts with an XML
+ parser, as the regular structure lends itself handily to parsing and
+ validation of the document/datagram and then processing the
+ destination address, TTL, and checksum before sending it on to its
+ next-hop.
+
+ The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+ wider deployment of IPv4 and the fact that implementing IPv6 as XML
+ would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy Informational [Page 2]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+ of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
+ formed and include the XMLDecl.
+
+2.1. IP Description
+
+ A number of items have changed (for the better) from the original IP
+ specification. Bit-masks, where present have been converted into
+ human-readable values. IP addresses are listed in their dotted-
+ decimal notation [RFC1123]. Length and checksum values are present
+ as decimal integers.
+
+ To calculate the length and checksum fields of the IP element, a
+ canonicalized form of the element MUST be used. The canonical form
+ SHALL have no whitespace (including newline characters) between
+ elements and only one space character between attributes. There
+ SHALL NOT be a space following the last attribute in an element.
+
+ An iterative method SHOULD be used to calculate checksums, as the
+ length field will vary based on the size of the checksum.
+
+ The payload element bears special attention. Due to the character
+ set restrictions of XML, the payload of IP datagrams (which MAY
+ contain arbitrary data) MUST be encoded for transport. This RFC
+ REQUIRES the contents of the payload to be encoded in the base-64
+ encoding of RFC 2045 [RFC2045], but removes the requirement that the
+ encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 3]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+2.2. Example Datagram
+
+ The following is an example IPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ <ip>
+ <header length="474">
+ <version value="4"/>
+ <tos precedence="Routine" delay="Normal" throughput="Normal"
+ relibility="Normal" reserved="0"/>
+ <total.length value="461"/>
+ <id value="1"/>
+ <flags reserved="0" df="dont" mf="last"/>
+ <offset value="0"/>
+ <ttl value="255"/>
+ <protocol value="6"/>
+ <checksum value="8707"/>
+ <source address="10.0.0.22"/>
+ <destination address="10.0.0.1"/>
+ <options>
+ <end copied="0" class="0" number="0"/>
+ </options>
+ <padding pad="0"/>
+ </header>
+ <payload>
+ </payload>
+ </ip>
+
+3. TCPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+ A number of items have changed from the original TCP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+ To calculate the length and checksum fields of the TCP element, a
+ canonicalized form of the element MUST be used as in section 2.1.
+
+ An iterative method SHOULD be used to calculate checksums as in
+ section 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy Informational [Page 4]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ The TCP offset element was expanded to a maximum of 255 from 16 to
+ allow for the increased size of the header in XML.
+
+ TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ <tcp>
+ <tcp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <sequence number="322622954"/>
+ <acknowledgement number="689715995"/>
+ <offset number=""/>
+ <reserved value="0"/>
+ <control syn="1" ack="1"/>
+ <window size="1"/>
+ <urgent pointer="0"/>
+ <checksum value="2988"/>
+ <tcp.options>
+ <tcp.end kind="0"/>
+ </tcp.options>
+ <padding pad="0"/>
+ </tcp.header>
+ <payload>
+ </payload>
+ </tcp>
+
+4. UDPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+ A number of items have changed from the original UDP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+
+
+
+
+
+
+Kennedy Informational [Page 5]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ To calculate the length and checksum fields of the UDP element, a
+ canonicalized form of the element MUST be used as in section 2.1. An
+ iterative method SHOULD be used to calculate checksums as in section
+ 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+ UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ <udp>
+ <udp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <udp.length value="143"/>
+ <checksum value="2988"/>
+ </udp.header>
+ <payload>
+ </payload>
+ </udp>
+
+5. Network Transport
+
+ This document provides for the transmission of BLOAT datagrams over
+ two common families of physical layer transport. Future RFCs will
+ address additional transports as routing vendors catch up to the
+ specification, and we begin to see BLOAT routed across the Internet
+ backbone.
+
+5.1. Ethernet
+
+ BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+ exception that the type field of the Ethernet frame MUST contain the
+ value 0xBEEF. The first 5 octets of the Ethernet frame payload will
+ be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+ BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+ that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy Informational [Page 6]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+6. Gatewaying over IP
+
+ In order to facilitate the gradual introduction of BLOAT into the
+ public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+ gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+ The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+ Network DTD (7.1.)
+
+ The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+ [XML]) although it is understood that most IPoXML implementations
+ will not need to pull down the DTD, as it will normally be embedded
+ in the implementation, and presents something of a catch-22 if you
+ need to load part of your network protocol over the network.
+
+7.1. IPoXML DTD
+
+ <!--
+ DTD for IP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ -->
+ <!--
+ DTD data types:
+
+ Digits [0..9]+
+
+ Precedence "NetworkControl | InternetworkControl |
+ CRITIC | FlashOverride | Flash | Immediate |
+ Priority | Routine"
+
+ IP4Addr "dotted-decimal" notation of [RFC1123]
+
+ Class [0..3]
+
+ Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
+ Restricted | Secret | Top Secret | Reserved"
+
+ Compartments [0..65535]
+
+ Handling [0..65535]
+
+ TCC [0..16777216]
+
+ -->
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ENTITY % Digits "CDATA">
+ <!ENTITY % Precedence "CDATA">
+ <!ENTITY % IP4Addr "CDATA">
+ <!ENTITY % Class "CDATA">
+ <!ENTITY % Sec "CDATA">
+ <!ENTITY % Compartments "CDATA">
+ <!ENTITY % Handling "CDATA">
+ <!ENTITY % TCC "CDATA">
+
+ <!ELEMENT ip (header, payload)>
+
+ <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+ protocol, checksum, source, destination, options,
+ padding)>
+ <!-- length of header in 32-bit words -->
+ <!ATTLIST header
+ length %Digits; #REQUIRED>
+
+ <!ELEMENT version EMPTY>
+ <!-- ip version. SHOULD be "4" -->
+ <!ATTLIST version
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT tos EMPTY>
+ <!ATTLIST tos
+ precedence %Precedence; #REQUIRED
+ delay (normal | low) #REQUIRED
+ throughput (normal | high) #REQUIRED
+ relibility (normal | high) #REQUIRED
+ reserved CDATA #FIXED "0">
+
+ <!ELEMENT total.length EMPTY>
+ <!--
+ total length of datagram (header and payload) in octets, MUST be
+ less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+ ethernets).
+ -->
+ <!ATTLIST total.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT id EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST id
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT flags EMPTY>
+ <!-- df = don't fragment, mf = more fragments -->
+ <!ATTLIST flags
+
+
+
+Kennedy Informational [Page 8]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ reserved CDATA #FIXED "0"
+ df (may|dont) #REQUIRED
+ mf (last|more) #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+ <!ATTLIST offset
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT ttl EMPTY>
+ <!-- 0 <= ttl <= 255 -->
+ <!ATTLIST ttl
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT protocol EMPTY>
+ <!-- 0 <= protocol <= 255 (per IANA) -->
+ <!ATTLIST protocol
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT checksum EMPTY>
+ <!-- 0 <= checksum <= 65535 (over header only) -->
+ <!ATTLIST checksum
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT source EMPTY>
+ <!ATTLIST source
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT destination EMPTY>
+ <!ATTLIST destination
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT options ( end | noop | security | loose | strict | record
+ | stream | timestamp )*>
+
+ <!ELEMENT end EMPTY>
+ <!ATTLIST end
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "0">
+
+ <!ELEMENT noop EMPTY>
+ <!ATTLIST noop
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "1">
+
+ <!ELEMENT security EMPTY>
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST security
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "2"
+ length CDATA #FIXED "11"
+ security %Sec; #REQUIRED
+ compartments %Compartments; #REQUIRED
+ handling %Handling; #REQUIRED
+ tcc %TCC; #REQUIRED>
+ <!ELEMENT loose (hop)+>
+ <!ATTLIST loose
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "3"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT hop EMPTY>
+ <!ATTLIST hop
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT strict (hop)+>
+ <!ATTLIST strict
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "9"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT record (hop)+>
+ <!ATTLIST record
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "7"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT stream EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST stream
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "8"
+ length CDATA #FIXED "4"
+ id %Digits; #REQUIRED>
+
+ <!ELEMENT timestamp (tstamp)+>
+ <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST timestamp
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "2"
+ number CDATA #FIXED "4"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED
+ oflw %Digits; #REQUIRED
+ flag (0 | 1 | 3) #REQUIRED>
+
+ <!ELEMENT tstamp EMPTY>
+ <!ATTLIST tstamp
+ time %Digits; #REQUIRED
+ address %IP4Addr; #IMPLIED>
+ <!--
+ padding to bring header to 32-bit boundary.
+ pad MUST be "0"*
+ -->
+ <!ELEMENT padding EMPTY>
+ <!ATTLIST padding
+ pad CDATA #REQUIRED>
+
+ <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+ by section 2.1 of this RFC -->
+ <!ELEMENT payload (CDATA)>
+
+7.2. TCPoXML DTD
+
+ <!--
+ DTD for TCP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ -->
+
+ <!-- the pseudoheader is only included for checksum calculations -->
+ <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+ <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+ reserved, control, window, checksum, urgent,
+ tcp.options, padding)>
+
+ <!ELEMENT src EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+ <!ATTLIST src
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT dest EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST dest
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT sequence EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST sequence
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT acknowledgement EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST acknowledgement
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= number <= 255 -->
+ <!ATTLIST offset
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT reserved EMPTY>
+ <!ATTLIST reserved
+ value CDATA #FIXED "0">
+
+ <!ELEMENT control EMPTY>
+ <!ATTLIST control
+ urg (0|1) #IMPLIED
+ ack (0|1) #IMPLIED
+ psh (0|1) #IMPLIED
+ rst (0|1) #IMPLIED
+ syn (0|1) #IMPLIED
+ fin (0|1) #IMPLIED>
+
+ <!ELEMENT window EMPTY>
+ <!-- 0 <= size <= 65,535 -->
+ <!ATTLIST window
+ size %Digits; #REQUIRED>
+
+ <!--
+ checksum as in ip, but with
+ the following pseudo-header added into the tcp element:
+ -->
+ <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+ tcp.length)>
+
+ <!--
+ tcp header + data length in octets. does not include the size of
+
+ the pseudoheader.
+ -->
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ELEMENT tcp.length EMPTY>
+ <!ATTLIST tcp.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT urgent EMPTY>
+ <!-- 0 <= pointer <= 65,535 -->
+ <!ATTLIST urgent
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+ <!ELEMENT tcp.end EMPTY>
+ <!ATTLIST tcp.end
+ kind CDATA #FIXED "0">
+
+ <!ELEMENT tcp.noop EMPTY>
+ <!ATTLIST tcp.noop
+ kind CDATA #FIXED "1">
+
+ <!ELEMENT tcp.mss EMPTY>
+ <!ATTLIST tcp.mss
+ kind CDATA #FIXED "2"
+ length CDATA #FIXED "4"
+ size %Digits; #REQUIRED>
+
+7.3. UDPoXML DTD
+
+ <!--
+ DTD for UDP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ -->
+
+ <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+ <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+ <!ELEMENT udp.pseudoheader (source, destination, protocol,
+ udp.length)>
+
+ <!--
+ udp header + data length in octets. does not include the size of
+ the pseudoheader.
+ -->
+ <!ELEMENT udp.length EMPTY>
+ <!ATTLIST udp.length
+ value %Digits; #REQUIRED>
+
+
+
+Kennedy Informational [Page 13]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+8. Security Considerations
+
+ XML, as a subset of SGML, has the same security considerations as
+ specified in SGML Media Types [RFC1874]. Security considerations
+ that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+ not attempt to correct for issues not related to message format.
+
+9. References
+
+ [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
+ February 2002. (Work in Progress)
+
+ [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
+ 793, September 1981.
+
+ [RFC894] Hornig, C., "Standard for the Transmission of IP
+ Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+ [RFC1042] Postel, J. and J. Reynolds, "Standard for the
+ Transmission of IP Datagrams Over IEEE 802 Networks", STD
+ 43, RFC 1042, February 1988.
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts -
+ Application and Support", RFC 1123, October 1989.
+
+ [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
+ 1995.
+
+ [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
+ October 1996.
+
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy Informational [Page 14]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
+ RFC 3080, March 2001.
+
+ [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+ Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+ "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+ Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+ Markup Language (XML)" World Wide Web Consortium
+ Recommendation REC- xml-19980210.
+ http://www.w3.org/TR/1998/REC-xml-19980210
+
+10. Author's Address
+
+ Hugh Kennedy
+ Mimezine
+ 1060 West Addison
+ Chicago, IL 60613
+ USA
+
+ EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 15]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 16]
+
+
+
+
+
+
+
+Network Working Group H. Kennedy
+Request for Comments: 3252 Mimezine
+Category: Informational 1 April 2002
+
+
+ Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document defines a reformulation of IP and two transport layer
+ protocols (TCP and UDP) as XML applications.
+
+1. Introduction
+
+1.1. Overview
+
+ This document describes the Binary Lexical Octet Ad-hoc Transport
+ (BLOAT): a reformulation of a widely-deployed network-layer protocol
+ (IP [RFC791]), and two associated transport layer protocols (TCP
+ [RFC793] and UDP [RFC768]) as XML [XML] applications. It also
+ describes methods for transporting BLOAT over Ethernet and IEEE 802
+ networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+ across the public Internet.
+
+1.2. Motivation
+
+ The wild popularity of XML as a basis for application-level protocols
+ such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+ Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+ investigation into the possibility of extending the use of XML in the
+ protocol stack. Using XML at both the transport and network layer in
+ addition to the application layer would provide for an amazing amount
+ of power and flexibility while removing dependencies on proprietary
+ and hard-to-understand binary protocols. This protocol unification
+ would also allow applications to use a single XML parser for all
+ aspects of their operation, eliminating developer time spent figuring
+ out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy Informational [Page 1]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ parsing to the XML toolset. The use of XML also mitigates concerns
+ over "network vs. host" byte ordering which is at the root of many
+ network application bugs.
+
+1.3. Relation to Existing Protocols
+
+ The reformulations specified in this RFC follow as closely as
+ possible the spirit of the RFCs on which they are based, and so MAY
+ contain elements or attributes that would not be needed in a pure
+ reworking (e.g. length attributes, which are implicit in XML.)
+
+ The layering of network and transport protocols are maintained in
+ this RFC despite the optimizations that could be made if the line
+ were somewhat blurred (i.e. merging TCP and IP into a single, larger
+ element in the DTD) in order to foster future use of this protocol as
+ a basis for reformulating other protocols (such as ICMP.)
+
+ Other than the encoding, the behavioral aspects of each of the
+ existing protocols remain unchanged. Routing, address spaces, TCP
+ congestion control, etc. behave as specified in the extant standards.
+ Adapting to new standards and experimental algorithm heuristics for
+ improving performance will become much easier once the move to BLOAT
+ has been completed.
+
+1.4. Requirement Levels
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
+
+2. IPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC.
+ IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+ (section 3.) and higher-level application protocols.
+
+ The DTD for this document type can be found in section 7.1.
+
+ The routing of IPoXML can be easily implemented on hosts with an XML
+ parser, as the regular structure lends itself handily to parsing and
+ validation of the document/datagram and then processing the
+ destination address, TTL, and checksum before sending it on to its
+ next-hop.
+
+ The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+ wider deployment of IPv4 and the fact that implementing IPv6 as XML
+ would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy Informational [Page 2]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+ of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
+ formed and include the XMLDecl.
+
+2.1. IP Description
+
+ A number of items have changed (for the better) from the original IP
+ specification. Bit-masks, where present have been converted into
+ human-readable values. IP addresses are listed in their dotted-
+ decimal notation [RFC1123]. Length and checksum values are present
+ as decimal integers.
+
+ To calculate the length and checksum fields of the IP element, a
+ canonicalized form of the element MUST be used. The canonical form
+ SHALL have no whitespace (including newline characters) between
+ elements and only one space character between attributes. There
+ SHALL NOT be a space following the last attribute in an element.
+
+ An iterative method SHOULD be used to calculate checksums, as the
+ length field will vary based on the size of the checksum.
+
+ The payload element bears special attention. Due to the character
+ set restrictions of XML, the payload of IP datagrams (which MAY
+ contain arbitrary data) MUST be encoded for transport. This RFC
+ REQUIRES the contents of the payload to be encoded in the base-64
+ encoding of RFC 2045 [RFC2045], but removes the requirement that the
+ encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 3]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+2.2. Example Datagram
+
+ The following is an example IPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ <ip>
+ <header length="474">
+ <version value="4"/>
+ <tos precedence="Routine" delay="Normal" throughput="Normal"
+ relibility="Normal" reserved="0"/>
+ <total.length value="461"/>
+ <id value="1"/>
+ <flags reserved="0" df="dont" mf="last"/>
+ <offset value="0"/>
+ <ttl value="255"/>
+ <protocol value="6"/>
+ <checksum value="8707"/>
+ <source address="10.0.0.22"/>
+ <destination address="10.0.0.1"/>
+ <options>
+ <end copied="0" class="0" number="0"/>
+ </options>
+ <padding pad="0"/>
+ </header>
+ <payload>
+ </payload>
+ </ip>
+
+3. TCPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+ A number of items have changed from the original TCP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+ To calculate the length and checksum fields of the TCP element, a
+ canonicalized form of the element MUST be used as in section 2.1.
+
+ An iterative method SHOULD be used to calculate checksums as in
+ section 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy Informational [Page 4]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ The TCP offset element was expanded to a maximum of 255 from 16 to
+ allow for the increased size of the header in XML.
+
+ TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ <tcp>
+ <tcp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <sequence number="322622954"/>
+ <acknowledgement number="689715995"/>
+ <offset number=""/>
+ <reserved value="0"/>
+ <control syn="1" ack="1"/>
+ <window size="1"/>
+ <urgent pointer="0"/>
+ <checksum value="2988"/>
+ <tcp.options>
+ <tcp.end kind="0"/>
+ </tcp.options>
+ <padding pad="0"/>
+ </tcp.header>
+ <payload>
+ </payload>
+ </tcp>
+
+4. UDPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+ A number of items have changed from the original UDP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+
+
+
+
+
+
+Kennedy Informational [Page 5]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ To calculate the length and checksum fields of the UDP element, a
+ canonicalized form of the element MUST be used as in section 2.1. An
+ iterative method SHOULD be used to calculate checksums as in section
+ 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+ UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ <udp>
+ <udp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <udp.length value="143"/>
+ <checksum value="2988"/>
+ </udp.header>
+ <payload>
+ </payload>
+ </udp>
+
+5. Network Transport
+
+ This document provides for the transmission of BLOAT datagrams over
+ two common families of physical layer transport. Future RFCs will
+ address additional transports as routing vendors catch up to the
+ specification, and we begin to see BLOAT routed across the Internet
+ backbone.
+
+5.1. Ethernet
+
+ BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+ exception that the type field of the Ethernet frame MUST contain the
+ value 0xBEEF. The first 5 octets of the Ethernet frame payload will
+ be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+ BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+ that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy Informational [Page 6]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+6. Gatewaying over IP
+
+ In order to facilitate the gradual introduction of BLOAT into the
+ public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+ gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+ The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+ Network DTD (7.1.)
+
+ The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+ [XML]) although it is understood that most IPoXML implementations
+ will not need to pull down the DTD, as it will normally be embedded
+ in the implementation, and presents something of a catch-22 if you
+ need to load part of your network protocol over the network.
+
+7.1. IPoXML DTD
+
+ <!--
+ DTD for IP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ -->
+ <!--
+ DTD data types:
+
+ Digits [0..9]+
+
+ Precedence "NetworkControl | InternetworkControl |
+ CRITIC | FlashOverride | Flash | Immediate |
+ Priority | Routine"
+
+ IP4Addr "dotted-decimal" notation of [RFC1123]
+
+ Class [0..3]
+
+ Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
+ Restricted | Secret | Top Secret | Reserved"
+
+ Compartments [0..65535]
+
+ Handling [0..65535]
+
+ TCC [0..16777216]
+
+ -->
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ENTITY % Digits "CDATA">
+ <!ENTITY % Precedence "CDATA">
+ <!ENTITY % IP4Addr "CDATA">
+ <!ENTITY % Class "CDATA">
+ <!ENTITY % Sec "CDATA">
+ <!ENTITY % Compartments "CDATA">
+ <!ENTITY % Handling "CDATA">
+ <!ENTITY % TCC "CDATA">
+
+ <!ELEMENT ip (header, payload)>
+
+ <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+ protocol, checksum, source, destination, options,
+ padding)>
+ <!-- length of header in 32-bit words -->
+ <!ATTLIST header
+ length %Digits; #REQUIRED>
+
+ <!ELEMENT version EMPTY>
+ <!-- ip version. SHOULD be "4" -->
+ <!ATTLIST version
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT tos EMPTY>
+ <!ATTLIST tos
+ precedence %Precedence; #REQUIRED
+ delay (normal | low) #REQUIRED
+ throughput (normal | high) #REQUIRED
+ relibility (normal | high) #REQUIRED
+ reserved CDATA #FIXED "0">
+
+ <!ELEMENT total.length EMPTY>
+ <!--
+ total length of datagram (header and payload) in octets, MUST be
+ less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+ ethernets).
+ -->
+ <!ATTLIST total.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT id EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST id
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT flags EMPTY>
+ <!-- df = don't fragment, mf = more fragments -->
+ <!ATTLIST flags
+
+
+
+Kennedy Informational [Page 8]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ reserved CDATA #FIXED "0"
+ df (may|dont) #REQUIRED
+ mf (last|more) #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+ <!ATTLIST offset
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT ttl EMPTY>
+ <!-- 0 <= ttl <= 255 -->
+ <!ATTLIST ttl
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT protocol EMPTY>
+ <!-- 0 <= protocol <= 255 (per IANA) -->
+ <!ATTLIST protocol
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT checksum EMPTY>
+ <!-- 0 <= checksum <= 65535 (over header only) -->
+ <!ATTLIST checksum
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT source EMPTY>
+ <!ATTLIST source
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT destination EMPTY>
+ <!ATTLIST destination
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT options ( end | noop | security | loose | strict | record
+ | stream | timestamp )*>
+
+ <!ELEMENT end EMPTY>
+ <!ATTLIST end
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "0">
+
+ <!ELEMENT noop EMPTY>
+ <!ATTLIST noop
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "1">
+
+ <!ELEMENT security EMPTY>
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST security
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "2"
+ length CDATA #FIXED "11"
+ security %Sec; #REQUIRED
+ compartments %Compartments; #REQUIRED
+ handling %Handling; #REQUIRED
+ tcc %TCC; #REQUIRED>
+ <!ELEMENT loose (hop)+>
+ <!ATTLIST loose
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "3"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT hop EMPTY>
+ <!ATTLIST hop
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT strict (hop)+>
+ <!ATTLIST strict
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "9"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT record (hop)+>
+ <!ATTLIST record
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "7"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT stream EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST stream
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "8"
+ length CDATA #FIXED "4"
+ id %Digits; #REQUIRED>
+
+ <!ELEMENT timestamp (tstamp)+>
+ <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST timestamp
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "2"
+ number CDATA #FIXED "4"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED
+ oflw %Digits; #REQUIRED
+ flag (0 | 1 | 3) #REQUIRED>
+
+ <!ELEMENT tstamp EMPTY>
+ <!ATTLIST tstamp
+ time %Digits; #REQUIRED
+ address %IP4Addr; #IMPLIED>
+ <!--
+ padding to bring header to 32-bit boundary.
+ pad MUST be "0"*
+ -->
+ <!ELEMENT padding EMPTY>
+ <!ATTLIST padding
+ pad CDATA #REQUIRED>
+
+ <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+ by section 2.1 of this RFC -->
+ <!ELEMENT payload (CDATA)>
+
+7.2. TCPoXML DTD
+
+ <!--
+ DTD for TCP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ -->
+
+ <!-- the pseudoheader is only included for checksum calculations -->
+ <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+ <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+ reserved, control, window, checksum, urgent,
+ tcp.options, padding)>
+
+ <!ELEMENT src EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+ <!ATTLIST src
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT dest EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST dest
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT sequence EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST sequence
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT acknowledgement EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST acknowledgement
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= number <= 255 -->
+ <!ATTLIST offset
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT reserved EMPTY>
+ <!ATTLIST reserved
+ value CDATA #FIXED "0">
+
+ <!ELEMENT control EMPTY>
+ <!ATTLIST control
+ urg (0|1) #IMPLIED
+ ack (0|1) #IMPLIED
+ psh (0|1) #IMPLIED
+ rst (0|1) #IMPLIED
+ syn (0|1) #IMPLIED
+ fin (0|1) #IMPLIED>
+
+ <!ELEMENT window EMPTY>
+ <!-- 0 <= size <= 65,535 -->
+ <!ATTLIST window
+ size %Digits; #REQUIRED>
+
+ <!--
+ checksum as in ip, but with
+ the following pseudo-header added into the tcp element:
+ -->
+ <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+ tcp.length)>
+
+ <!--
+ tcp header + data length in octets. does not include the size of
+
+ the pseudoheader.
+ -->
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ELEMENT tcp.length EMPTY>
+ <!ATTLIST tcp.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT urgent EMPTY>
+ <!-- 0 <= pointer <= 65,535 -->
+ <!ATTLIST urgent
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+ <!ELEMENT tcp.end EMPTY>
+ <!ATTLIST tcp.end
+ kind CDATA #FIXED "0">
+
+ <!ELEMENT tcp.noop EMPTY>
+ <!ATTLIST tcp.noop
+ kind CDATA #FIXED "1">
+
+ <!ELEMENT tcp.mss EMPTY>
+ <!ATTLIST tcp.mss
+ kind CDATA #FIXED "2"
+ length CDATA #FIXED "4"
+ size %Digits; #REQUIRED>
+
+7.3. UDPoXML DTD
+
+ <!--
+ DTD for UDP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ -->
+
+ <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+ <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+ <!ELEMENT udp.pseudoheader (source, destination, protocol,
+ udp.length)>
+
+ <!--
+ udp header + data length in octets. does not include the size of
+ the pseudoheader.
+ -->
+ <!ELEMENT udp.length EMPTY>
+ <!ATTLIST udp.length
+ value %Digits; #REQUIRED>
+
+
+
+Kennedy Informational [Page 13]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+8. Security Considerations
+
+ XML, as a subset of SGML, has the same security considerations as
+ specified in SGML Media Types [RFC1874]. Security considerations
+ that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+ not attempt to correct for issues not related to message format.
+
+9. References
+
+ [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
+ February 2002. (Work in Progress)
+
+ [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
+ 793, September 1981.
+
+ [RFC894] Hornig, C., "Standard for the Transmission of IP
+ Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+ [RFC1042] Postel, J. and J. Reynolds, "Standard for the
+ Transmission of IP Datagrams Over IEEE 802 Networks", STD
+ 43, RFC 1042, February 1988.
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts -
+ Application and Support", RFC 1123, October 1989.
+
+ [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
+ 1995.
+
+ [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
+ October 1996.
+
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy Informational [Page 14]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
+ RFC 3080, March 2001.
+
+ [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+ Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+ "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+ Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+ Markup Language (XML)" World Wide Web Consortium
+ Recommendation REC- xml-19980210.
+ http://www.w3.org/TR/1998/REC-xml-19980210
+
+10. Author's Address
+
+ Hugh Kennedy
+ Mimezine
+ 1060 West Addison
+ Chicago, IL 60613
+ USA
+
+ EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 15]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 16]
+
+
+
+
+
+
+
+Network Working Group H. Kennedy
+Request for Comments: 3252 Mimezine
+Category: Informational 1 April 2002
+
+
+ Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document defines a reformulation of IP and two transport layer
+ protocols (TCP and UDP) as XML applications.
+
+1. Introduction
+
+1.1. Overview
+
+ This document describes the Binary Lexical Octet Ad-hoc Transport
+ (BLOAT): a reformulation of a widely-deployed network-layer protocol
+ (IP [RFC791]), and two associated transport layer protocols (TCP
+ [RFC793] and UDP [RFC768]) as XML [XML] applications. It also
+ describes methods for transporting BLOAT over Ethernet and IEEE 802
+ networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+ across the public Internet.
+
+1.2. Motivation
+
+ The wild popularity of XML as a basis for application-level protocols
+ such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+ Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+ investigation into the possibility of extending the use of XML in the
+ protocol stack. Using XML at both the transport and network layer in
+ addition to the application layer would provide for an amazing amount
+ of power and flexibility while removing dependencies on proprietary
+ and hard-to-understand binary protocols. This protocol unification
+ would also allow applications to use a single XML parser for all
+ aspects of their operation, eliminating developer time spent figuring
+ out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy Informational [Page 1]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ parsing to the XML toolset. The use of XML also mitigates concerns
+ over "network vs. host" byte ordering which is at the root of many
+ network application bugs.
+
+1.3. Relation to Existing Protocols
+
+ The reformulations specified in this RFC follow as closely as
+ possible the spirit of the RFCs on which they are based, and so MAY
+ contain elements or attributes that would not be needed in a pure
+ reworking (e.g. length attributes, which are implicit in XML.)
+
+ The layering of network and transport protocols are maintained in
+ this RFC despite the optimizations that could be made if the line
+ were somewhat blurred (i.e. merging TCP and IP into a single, larger
+ element in the DTD) in order to foster future use of this protocol as
+ a basis for reformulating other protocols (such as ICMP.)
+
+ Other than the encoding, the behavioral aspects of each of the
+ existing protocols remain unchanged. Routing, address spaces, TCP
+ congestion control, etc. behave as specified in the extant standards.
+ Adapting to new standards and experimental algorithm heuristics for
+ improving performance will become much easier once the move to BLOAT
+ has been completed.
+
+1.4. Requirement Levels
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
+
+2. IPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC.
+ IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+ (section 3.) and higher-level application protocols.
+
+ The DTD for this document type can be found in section 7.1.
+
+ The routing of IPoXML can be easily implemented on hosts with an XML
+ parser, as the regular structure lends itself handily to parsing and
+ validation of the document/datagram and then processing the
+ destination address, TTL, and checksum before sending it on to its
+ next-hop.
+
+ The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+ wider deployment of IPv4 and the fact that implementing IPv6 as XML
+ would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy Informational [Page 2]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+ of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
+ formed and include the XMLDecl.
+
+2.1. IP Description
+
+ A number of items have changed (for the better) from the original IP
+ specification. Bit-masks, where present have been converted into
+ human-readable values. IP addresses are listed in their dotted-
+ decimal notation [RFC1123]. Length and checksum values are present
+ as decimal integers.
+
+ To calculate the length and checksum fields of the IP element, a
+ canonicalized form of the element MUST be used. The canonical form
+ SHALL have no whitespace (including newline characters) between
+ elements and only one space character between attributes. There
+ SHALL NOT be a space following the last attribute in an element.
+
+ An iterative method SHOULD be used to calculate checksums, as the
+ length field will vary based on the size of the checksum.
+
+ The payload element bears special attention. Due to the character
+ set restrictions of XML, the payload of IP datagrams (which MAY
+ contain arbitrary data) MUST be encoded for transport. This RFC
+ REQUIRES the contents of the payload to be encoded in the base-64
+ encoding of RFC 2045 [RFC2045], but removes the requirement that the
+ encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 3]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+2.2. Example Datagram
+
+ The following is an example IPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ <ip>
+ <header length="474">
+ <version value="4"/>
+ <tos precedence="Routine" delay="Normal" throughput="Normal"
+ relibility="Normal" reserved="0"/>
+ <total.length value="461"/>
+ <id value="1"/>
+ <flags reserved="0" df="dont" mf="last"/>
+ <offset value="0"/>
+ <ttl value="255"/>
+ <protocol value="6"/>
+ <checksum value="8707"/>
+ <source address="10.0.0.22"/>
+ <destination address="10.0.0.1"/>
+ <options>
+ <end copied="0" class="0" number="0"/>
+ </options>
+ <padding pad="0"/>
+ </header>
+ <payload>
+ </payload>
+ </ip>
+
+3. TCPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+ A number of items have changed from the original TCP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+ To calculate the length and checksum fields of the TCP element, a
+ canonicalized form of the element MUST be used as in section 2.1.
+
+ An iterative method SHOULD be used to calculate checksums as in
+ section 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy Informational [Page 4]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ The TCP offset element was expanded to a maximum of 255 from 16 to
+ allow for the increased size of the header in XML.
+
+ TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ <tcp>
+ <tcp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <sequence number="322622954"/>
+ <acknowledgement number="689715995"/>
+ <offset number=""/>
+ <reserved value="0"/>
+ <control syn="1" ack="1"/>
+ <window size="1"/>
+ <urgent pointer="0"/>
+ <checksum value="2988"/>
+ <tcp.options>
+ <tcp.end kind="0"/>
+ </tcp.options>
+ <padding pad="0"/>
+ </tcp.header>
+ <payload>
+ </payload>
+ </tcp>
+
+4. UDPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+ A number of items have changed from the original UDP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+
+
+
+
+
+
+Kennedy Informational [Page 5]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ To calculate the length and checksum fields of the UDP element, a
+ canonicalized form of the element MUST be used as in section 2.1. An
+ iterative method SHOULD be used to calculate checksums as in section
+ 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+ UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ <udp>
+ <udp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <udp.length value="143"/>
+ <checksum value="2988"/>
+ </udp.header>
+ <payload>
+ </payload>
+ </udp>
+
+5. Network Transport
+
+ This document provides for the transmission of BLOAT datagrams over
+ two common families of physical layer transport. Future RFCs will
+ address additional transports as routing vendors catch up to the
+ specification, and we begin to see BLOAT routed across the Internet
+ backbone.
+
+5.1. Ethernet
+
+ BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+ exception that the type field of the Ethernet frame MUST contain the
+ value 0xBEEF. The first 5 octets of the Ethernet frame payload will
+ be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+ BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+ that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy Informational [Page 6]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+6. Gatewaying over IP
+
+ In order to facilitate the gradual introduction of BLOAT into the
+ public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+ gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+ The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+ Network DTD (7.1.)
+
+ The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+ [XML]) although it is understood that most IPoXML implementations
+ will not need to pull down the DTD, as it will normally be embedded
+ in the implementation, and presents something of a catch-22 if you
+ need to load part of your network protocol over the network.
+
+7.1. IPoXML DTD
+
+ <!--
+ DTD for IP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ -->
+ <!--
+ DTD data types:
+
+ Digits [0..9]+
+
+ Precedence "NetworkControl | InternetworkControl |
+ CRITIC | FlashOverride | Flash | Immediate |
+ Priority | Routine"
+
+ IP4Addr "dotted-decimal" notation of [RFC1123]
+
+ Class [0..3]
+
+ Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
+ Restricted | Secret | Top Secret | Reserved"
+
+ Compartments [0..65535]
+
+ Handling [0..65535]
+
+ TCC [0..16777216]
+
+ -->
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ENTITY % Digits "CDATA">
+ <!ENTITY % Precedence "CDATA">
+ <!ENTITY % IP4Addr "CDATA">
+ <!ENTITY % Class "CDATA">
+ <!ENTITY % Sec "CDATA">
+ <!ENTITY % Compartments "CDATA">
+ <!ENTITY % Handling "CDATA">
+ <!ENTITY % TCC "CDATA">
+
+ <!ELEMENT ip (header, payload)>
+
+ <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+ protocol, checksum, source, destination, options,
+ padding)>
+ <!-- length of header in 32-bit words -->
+ <!ATTLIST header
+ length %Digits; #REQUIRED>
+
+ <!ELEMENT version EMPTY>
+ <!-- ip version. SHOULD be "4" -->
+ <!ATTLIST version
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT tos EMPTY>
+ <!ATTLIST tos
+ precedence %Precedence; #REQUIRED
+ delay (normal | low) #REQUIRED
+ throughput (normal | high) #REQUIRED
+ relibility (normal | high) #REQUIRED
+ reserved CDATA #FIXED "0">
+
+ <!ELEMENT total.length EMPTY>
+ <!--
+ total length of datagram (header and payload) in octets, MUST be
+ less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+ ethernets).
+ -->
+ <!ATTLIST total.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT id EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST id
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT flags EMPTY>
+ <!-- df = don't fragment, mf = more fragments -->
+ <!ATTLIST flags
+
+
+
+Kennedy Informational [Page 8]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ reserved CDATA #FIXED "0"
+ df (may|dont) #REQUIRED
+ mf (last|more) #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+ <!ATTLIST offset
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT ttl EMPTY>
+ <!-- 0 <= ttl <= 255 -->
+ <!ATTLIST ttl
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT protocol EMPTY>
+ <!-- 0 <= protocol <= 255 (per IANA) -->
+ <!ATTLIST protocol
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT checksum EMPTY>
+ <!-- 0 <= checksum <= 65535 (over header only) -->
+ <!ATTLIST checksum
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT source EMPTY>
+ <!ATTLIST source
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT destination EMPTY>
+ <!ATTLIST destination
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT options ( end | noop | security | loose | strict | record
+ | stream | timestamp )*>
+
+ <!ELEMENT end EMPTY>
+ <!ATTLIST end
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "0">
+
+ <!ELEMENT noop EMPTY>
+ <!ATTLIST noop
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "1">
+
+ <!ELEMENT security EMPTY>
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST security
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "2"
+ length CDATA #FIXED "11"
+ security %Sec; #REQUIRED
+ compartments %Compartments; #REQUIRED
+ handling %Handling; #REQUIRED
+ tcc %TCC; #REQUIRED>
+ <!ELEMENT loose (hop)+>
+ <!ATTLIST loose
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "3"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT hop EMPTY>
+ <!ATTLIST hop
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT strict (hop)+>
+ <!ATTLIST strict
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "9"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT record (hop)+>
+ <!ATTLIST record
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "7"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT stream EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST stream
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "8"
+ length CDATA #FIXED "4"
+ id %Digits; #REQUIRED>
+
+ <!ELEMENT timestamp (tstamp)+>
+ <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST timestamp
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "2"
+ number CDATA #FIXED "4"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED
+ oflw %Digits; #REQUIRED
+ flag (0 | 1 | 3) #REQUIRED>
+
+ <!ELEMENT tstamp EMPTY>
+ <!ATTLIST tstamp
+ time %Digits; #REQUIRED
+ address %IP4Addr; #IMPLIED>
+ <!--
+ padding to bring header to 32-bit boundary.
+ pad MUST be "0"*
+ -->
+ <!ELEMENT padding EMPTY>
+ <!ATTLIST padding
+ pad CDATA #REQUIRED>
+
+ <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+ by section 2.1 of this RFC -->
+ <!ELEMENT payload (CDATA)>
+
+7.2. TCPoXML DTD
+
+ <!--
+ DTD for TCP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ -->
+
+ <!-- the pseudoheader is only included for checksum calculations -->
+ <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+ <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+ reserved, control, window, checksum, urgent,
+ tcp.options, padding)>
+
+ <!ELEMENT src EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+ <!ATTLIST src
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT dest EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST dest
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT sequence EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST sequence
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT acknowledgement EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST acknowledgement
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= number <= 255 -->
+ <!ATTLIST offset
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT reserved EMPTY>
+ <!ATTLIST reserved
+ value CDATA #FIXED "0">
+
+ <!ELEMENT control EMPTY>
+ <!ATTLIST control
+ urg (0|1) #IMPLIED
+ ack (0|1) #IMPLIED
+ psh (0|1) #IMPLIED
+ rst (0|1) #IMPLIED
+ syn (0|1) #IMPLIED
+ fin (0|1) #IMPLIED>
+
+ <!ELEMENT window EMPTY>
+ <!-- 0 <= size <= 65,535 -->
+ <!ATTLIST window
+ size %Digits; #REQUIRED>
+
+ <!--
+ checksum as in ip, but with
+ the following pseudo-header added into the tcp element:
+ -->
+ <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+ tcp.length)>
+
+ <!--
+ tcp header + data length in octets. does not include the size of
+
+ the pseudoheader.
+ -->
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ELEMENT tcp.length EMPTY>
+ <!ATTLIST tcp.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT urgent EMPTY>
+ <!-- 0 <= pointer <= 65,535 -->
+ <!ATTLIST urgent
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+ <!ELEMENT tcp.end EMPTY>
+ <!ATTLIST tcp.end
+ kind CDATA #FIXED "0">
+
+ <!ELEMENT tcp.noop EMPTY>
+ <!ATTLIST tcp.noop
+ kind CDATA #FIXED "1">
+
+ <!ELEMENT tcp.mss EMPTY>
+ <!ATTLIST tcp.mss
+ kind CDATA #FIXED "2"
+ length CDATA #FIXED "4"
+ size %Digits; #REQUIRED>
+
+7.3. UDPoXML DTD
+
+ <!--
+ DTD for UDP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ -->
+
+ <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+ <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+ <!ELEMENT udp.pseudoheader (source, destination, protocol,
+ udp.length)>
+
+ <!--
+ udp header + data length in octets. does not include the size of
+ the pseudoheader.
+ -->
+ <!ELEMENT udp.length EMPTY>
+ <!ATTLIST udp.length
+ value %Digits; #REQUIRED>
+
+
+
+Kennedy Informational [Page 13]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+8. Security Considerations
+
+ XML, as a subset of SGML, has the same security considerations as
+ specified in SGML Media Types [RFC1874]. Security considerations
+ that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+ not attempt to correct for issues not related to message format.
+
+9. References
+
+ [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
+ February 2002. (Work in Progress)
+
+ [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
+ 793, September 1981.
+
+ [RFC894] Hornig, C., "Standard for the Transmission of IP
+ Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+ [RFC1042] Postel, J. and J. Reynolds, "Standard for the
+ Transmission of IP Datagrams Over IEEE 802 Networks", STD
+ 43, RFC 1042, February 1988.
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts -
+ Application and Support", RFC 1123, October 1989.
+
+ [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
+ 1995.
+
+ [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
+ October 1996.
+
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy Informational [Page 14]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
+ RFC 3080, March 2001.
+
+ [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+ Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+ "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+ Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+ Markup Language (XML)" World Wide Web Consortium
+ Recommendation REC- xml-19980210.
+ http://www.w3.org/TR/1998/REC-xml-19980210
+
+10. Author's Address
+
+ Hugh Kennedy
+ Mimezine
+ 1060 West Addison
+ Chicago, IL 60613
+ USA
+
+ EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 15]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 16]
+
+
+
+
+
+
+
+Network Working Group H. Kennedy
+Request for Comments: 3252 Mimezine
+Category: Informational 1 April 2002
+
+
+ Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document defines a reformulation of IP and two transport layer
+ protocols (TCP and UDP) as XML applications.
+
+1. Introduction
+
+1.1. Overview
+
+ This document describes the Binary Lexical Octet Ad-hoc Transport
+ (BLOAT): a reformulation of a widely-deployed network-layer protocol
+ (IP [RFC791]), and two associated transport layer protocols (TCP
+ [RFC793] and UDP [RFC768]) as XML [XML] applications. It also
+ describes methods for transporting BLOAT over Ethernet and IEEE 802
+ networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+ across the public Internet.
+
+1.2. Motivation
+
+ The wild popularity of XML as a basis for application-level protocols
+ such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+ Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+ investigation into the possibility of extending the use of XML in the
+ protocol stack. Using XML at both the transport and network layer in
+ addition to the application layer would provide for an amazing amount
+ of power and flexibility while removing dependencies on proprietary
+ and hard-to-understand binary protocols. This protocol unification
+ would also allow applications to use a single XML parser for all
+ aspects of their operation, eliminating developer time spent figuring
+ out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy Informational [Page 1]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ parsing to the XML toolset. The use of XML also mitigates concerns
+ over "network vs. host" byte ordering which is at the root of many
+ network application bugs.
+
+1.3. Relation to Existing Protocols
+
+ The reformulations specified in this RFC follow as closely as
+ possible the spirit of the RFCs on which they are based, and so MAY
+ contain elements or attributes that would not be needed in a pure
+ reworking (e.g. length attributes, which are implicit in XML.)
+
+ The layering of network and transport protocols are maintained in
+ this RFC despite the optimizations that could be made if the line
+ were somewhat blurred (i.e. merging TCP and IP into a single, larger
+ element in the DTD) in order to foster future use of this protocol as
+ a basis for reformulating other protocols (such as ICMP.)
+
+ Other than the encoding, the behavioral aspects of each of the
+ existing protocols remain unchanged. Routing, address spaces, TCP
+ congestion control, etc. behave as specified in the extant standards.
+ Adapting to new standards and experimental algorithm heuristics for
+ improving performance will become much easier once the move to BLOAT
+ has been completed.
+
+1.4. Requirement Levels
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
+
+2. IPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC.
+ IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+ (section 3.) and higher-level application protocols.
+
+ The DTD for this document type can be found in section 7.1.
+
+ The routing of IPoXML can be easily implemented on hosts with an XML
+ parser, as the regular structure lends itself handily to parsing and
+ validation of the document/datagram and then processing the
+ destination address, TTL, and checksum before sending it on to its
+ next-hop.
+
+ The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+ wider deployment of IPv4 and the fact that implementing IPv6 as XML
+ would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy Informational [Page 2]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+ of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well-
+ formed and include the XMLDecl.
+
+2.1. IP Description
+
+ A number of items have changed (for the better) from the original IP
+ specification. Bit-masks, where present have been converted into
+ human-readable values. IP addresses are listed in their dotted-
+ decimal notation [RFC1123]. Length and checksum values are present
+ as decimal integers.
+
+ To calculate the length and checksum fields of the IP element, a
+ canonicalized form of the element MUST be used. The canonical form
+ SHALL have no whitespace (including newline characters) between
+ elements and only one space character between attributes. There
+ SHALL NOT be a space following the last attribute in an element.
+
+ An iterative method SHOULD be used to calculate checksums, as the
+ length field will vary based on the size of the checksum.
+
+ The payload element bears special attention. Due to the character
+ set restrictions of XML, the payload of IP datagrams (which MAY
+ contain arbitrary data) MUST be encoded for transport. This RFC
+ REQUIRES the contents of the payload to be encoded in the base-64
+ encoding of RFC 2045 [RFC2045], but removes the requirement that the
+ encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 3]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+2.2. Example Datagram
+
+ The following is an example IPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ <ip>
+ <header length="474">
+ <version value="4"/>
+ <tos precedence="Routine" delay="Normal" throughput="Normal"
+ relibility="Normal" reserved="0"/>
+ <total.length value="461"/>
+ <id value="1"/>
+ <flags reserved="0" df="dont" mf="last"/>
+ <offset value="0"/>
+ <ttl value="255"/>
+ <protocol value="6"/>
+ <checksum value="8707"/>
+ <source address="10.0.0.22"/>
+ <destination address="10.0.0.1"/>
+ <options>
+ <end copied="0" class="0" number="0"/>
+ </options>
+ <padding pad="0"/>
+ </header>
+ <payload>
+ </payload>
+ </ip>
+
+3. TCPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+ A number of items have changed from the original TCP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+ To calculate the length and checksum fields of the TCP element, a
+ canonicalized form of the element MUST be used as in section 2.1.
+
+ An iterative method SHOULD be used to calculate checksums as in
+ section 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy Informational [Page 4]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ The TCP offset element was expanded to a maximum of 255 from 16 to
+ allow for the increased size of the header in XML.
+
+ TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ <tcp>
+ <tcp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <sequence number="322622954"/>
+ <acknowledgement number="689715995"/>
+ <offset number=""/>
+ <reserved value="0"/>
+ <control syn="1" ack="1"/>
+ <window size="1"/>
+ <urgent pointer="0"/>
+ <checksum value="2988"/>
+ <tcp.options>
+ <tcp.end kind="0"/>
+ </tcp.options>
+ <padding pad="0"/>
+ </tcp.header>
+ <payload>
+ </payload>
+ </tcp>
+
+4. UDPoXML
+
+ This protocol MUST be implemented to be compliant with this RFC. The
+ DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+ A number of items have changed from the original UDP specification.
+ Bit-masks, where present have been converted into human-readable
+ values. Length and checksum and port values are present as decimal
+ integers.
+
+
+
+
+
+
+
+Kennedy Informational [Page 5]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ To calculate the length and checksum fields of the UDP element, a
+ canonicalized form of the element MUST be used as in section 2.1. An
+ iterative method SHOULD be used to calculate checksums as in section
+ 2.1.
+
+ The payload element MUST be encoded as in section 2.1.
+
+ UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+ as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ <udp>
+ <udp.header>
+ <src port="31415"/>
+ <dest port="42424"/>
+ <udp.length value="143"/>
+ <checksum value="2988"/>
+ </udp.header>
+ <payload>
+ </payload>
+ </udp>
+
+5. Network Transport
+
+ This document provides for the transmission of BLOAT datagrams over
+ two common families of physical layer transport. Future RFCs will
+ address additional transports as routing vendors catch up to the
+ specification, and we begin to see BLOAT routed across the Internet
+ backbone.
+
+5.1. Ethernet
+
+ BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+ exception that the type field of the Ethernet frame MUST contain the
+ value 0xBEEF. The first 5 octets of the Ethernet frame payload will
+ be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+ BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+ that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy Informational [Page 6]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+6. Gatewaying over IP
+
+ In order to facilitate the gradual introduction of BLOAT into the
+ public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+ gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+ The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+ Network DTD (7.1.)
+
+ The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+ [XML]) although it is understood that most IPoXML implementations
+ will not need to pull down the DTD, as it will normally be embedded
+ in the implementation, and presents something of a catch-22 if you
+ need to load part of your network protocol over the network.
+
+7.1. IPoXML DTD
+
+ <!--
+ DTD for IP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+ -->
+ <!--
+ DTD data types:
+
+ Digits [0..9]+
+
+ Precedence "NetworkControl | InternetworkControl |
+ CRITIC | FlashOverride | Flash | Immediate |
+ Priority | Routine"
+
+ IP4Addr "dotted-decimal" notation of [RFC1123]
+
+ Class [0..3]
+
+ Sec "Unclassified | Confidential | EFTO | MMMM | PROG |
+ Restricted | Secret | Top Secret | Reserved"
+
+ Compartments [0..65535]
+
+ Handling [0..65535]
+
+ TCC [0..16777216]
+
+ -->
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ENTITY % Digits "CDATA">
+ <!ENTITY % Precedence "CDATA">
+ <!ENTITY % IP4Addr "CDATA">
+ <!ENTITY % Class "CDATA">
+ <!ENTITY % Sec "CDATA">
+ <!ENTITY % Compartments "CDATA">
+ <!ENTITY % Handling "CDATA">
+ <!ENTITY % TCC "CDATA">
+
+ <!ELEMENT ip (header, payload)>
+
+ <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+ protocol, checksum, source, destination, options,
+ padding)>
+ <!-- length of header in 32-bit words -->
+ <!ATTLIST header
+ length %Digits; #REQUIRED>
+
+ <!ELEMENT version EMPTY>
+ <!-- ip version. SHOULD be "4" -->
+ <!ATTLIST version
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT tos EMPTY>
+ <!ATTLIST tos
+ precedence %Precedence; #REQUIRED
+ delay (normal | low) #REQUIRED
+ throughput (normal | high) #REQUIRED
+ relibility (normal | high) #REQUIRED
+ reserved CDATA #FIXED "0">
+
+ <!ELEMENT total.length EMPTY>
+ <!--
+ total length of datagram (header and payload) in octets, MUST be
+ less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+ ethernets).
+ -->
+ <!ATTLIST total.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT id EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST id
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT flags EMPTY>
+ <!-- df = don't fragment, mf = more fragments -->
+ <!ATTLIST flags
+
+
+
+Kennedy Informational [Page 8]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ reserved CDATA #FIXED "0"
+ df (may|dont) #REQUIRED
+ mf (last|more) #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+ <!ATTLIST offset
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT ttl EMPTY>
+ <!-- 0 <= ttl <= 255 -->
+ <!ATTLIST ttl
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT protocol EMPTY>
+ <!-- 0 <= protocol <= 255 (per IANA) -->
+ <!ATTLIST protocol
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT checksum EMPTY>
+ <!-- 0 <= checksum <= 65535 (over header only) -->
+ <!ATTLIST checksum
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT source EMPTY>
+ <!ATTLIST source
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT destination EMPTY>
+ <!ATTLIST destination
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT options ( end | noop | security | loose | strict | record
+ | stream | timestamp )*>
+
+ <!ELEMENT end EMPTY>
+ <!ATTLIST end
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "0">
+
+ <!ELEMENT noop EMPTY>
+ <!ATTLIST noop
+ copied (0|1) #REQUIRED
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "1">
+
+ <!ELEMENT security EMPTY>
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST security
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "2"
+ length CDATA #FIXED "11"
+ security %Sec; #REQUIRED
+ compartments %Compartments; #REQUIRED
+ handling %Handling; #REQUIRED
+ tcc %TCC; #REQUIRED>
+ <!ELEMENT loose (hop)+>
+ <!ATTLIST loose
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "3"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT hop EMPTY>
+ <!ATTLIST hop
+ address %IP4Addr; #REQUIRED>
+
+ <!ELEMENT strict (hop)+>
+ <!ATTLIST strict
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "9"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT record (hop)+>
+ <!ATTLIST record
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "7"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT stream EMPTY>
+ <!-- 0 <= id <= 65,535 -->
+ <!ATTLIST stream
+ copied CDATA #FIXED "1"
+ class CDATA #FIXED "0"
+ number CDATA #FIXED "8"
+ length CDATA #FIXED "4"
+ id %Digits; #REQUIRED>
+
+ <!ELEMENT timestamp (tstamp)+>
+ <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST timestamp
+ copied CDATA #FIXED "0"
+ class CDATA #FIXED "2"
+ number CDATA #FIXED "4"
+ length %Digits; #REQUIRED
+ pointer %Digits; #REQUIRED
+ oflw %Digits; #REQUIRED
+ flag (0 | 1 | 3) #REQUIRED>
+
+ <!ELEMENT tstamp EMPTY>
+ <!ATTLIST tstamp
+ time %Digits; #REQUIRED
+ address %IP4Addr; #IMPLIED>
+ <!--
+ padding to bring header to 32-bit boundary.
+ pad MUST be "0"*
+ -->
+ <!ELEMENT padding EMPTY>
+ <!ATTLIST padding
+ pad CDATA #REQUIRED>
+
+ <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+ by section 2.1 of this RFC -->
+ <!ELEMENT payload (CDATA)>
+
+7.2. TCPoXML DTD
+
+ <!--
+ DTD for TCP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+ -->
+
+ <!-- the pseudoheader is only included for checksum calculations -->
+ <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+ <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+ reserved, control, window, checksum, urgent,
+ tcp.options, padding)>
+
+ <!ELEMENT src EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+ <!ATTLIST src
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT dest EMPTY>
+ <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ATTLIST dest
+ port %Digits; #REQUIRED>
+
+ <!ELEMENT sequence EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST sequence
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT acknowledgement EMPTY>
+ <!-- 0 <= number <= 4294967295 -->
+ <!ATTLIST acknowledgement
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT offset EMPTY>
+ <!-- 0 <= number <= 255 -->
+ <!ATTLIST offset
+ number %Digits; #REQUIRED>
+
+ <!ELEMENT reserved EMPTY>
+ <!ATTLIST reserved
+ value CDATA #FIXED "0">
+
+ <!ELEMENT control EMPTY>
+ <!ATTLIST control
+ urg (0|1) #IMPLIED
+ ack (0|1) #IMPLIED
+ psh (0|1) #IMPLIED
+ rst (0|1) #IMPLIED
+ syn (0|1) #IMPLIED
+ fin (0|1) #IMPLIED>
+
+ <!ELEMENT window EMPTY>
+ <!-- 0 <= size <= 65,535 -->
+ <!ATTLIST window
+ size %Digits; #REQUIRED>
+
+ <!--
+ checksum as in ip, but with
+ the following pseudo-header added into the tcp element:
+ -->
+ <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+ tcp.length)>
+
+ <!--
+ tcp header + data length in octets. does not include the size of
+
+ the pseudoheader.
+ -->
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ <!ELEMENT tcp.length EMPTY>
+ <!ATTLIST tcp.length
+ value %Digits; #REQUIRED>
+
+ <!ELEMENT urgent EMPTY>
+ <!-- 0 <= pointer <= 65,535 -->
+ <!ATTLIST urgent
+ pointer %Digits; #REQUIRED>
+
+ <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+ <!ELEMENT tcp.end EMPTY>
+ <!ATTLIST tcp.end
+ kind CDATA #FIXED "0">
+
+ <!ELEMENT tcp.noop EMPTY>
+ <!ATTLIST tcp.noop
+ kind CDATA #FIXED "1">
+
+ <!ELEMENT tcp.mss EMPTY>
+ <!ATTLIST tcp.mss
+ kind CDATA #FIXED "2"
+ length CDATA #FIXED "4"
+ size %Digits; #REQUIRED>
+
+7.3. UDPoXML DTD
+
+ <!--
+ DTD for UDP over XML.
+ Refer to this DTD as:
+
+ <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+ -->
+
+ <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+ <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+ <!ELEMENT udp.pseudoheader (source, destination, protocol,
+ udp.length)>
+
+ <!--
+ udp header + data length in octets. does not include the size of
+ the pseudoheader.
+ -->
+ <!ELEMENT udp.length EMPTY>
+ <!ATTLIST udp.length
+ value %Digits; #REQUIRED>
+
+
+
+Kennedy Informational [Page 13]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+8. Security Considerations
+
+ XML, as a subset of SGML, has the same security considerations as
+ specified in SGML Media Types [RFC1874]. Security considerations
+ that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+ not attempt to correct for issues not related to message format.
+
+9. References
+
+ [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt,
+ February 2002. (Work in Progress)
+
+ [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
+ 793, September 1981.
+
+ [RFC894] Hornig, C., "Standard for the Transmission of IP
+ Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+ [RFC1042] Postel, J. and J. Reynolds, "Standard for the
+ Transmission of IP Datagrams Over IEEE 802 Networks", STD
+ 43, RFC 1042, February 1988.
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts -
+ Application and Support", RFC 1123, October 1989.
+
+ [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December
+ 1995.
+
+ [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
+ October 1996.
+
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy Informational [Page 14]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
+ RFC 3080, March 2001.
+
+ [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+ Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+ "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+ Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+ Markup Language (XML)" World Wide Web Consortium
+ Recommendation REC- xml-19980210.
+ http://www.w3.org/TR/1998/REC-xml-19980210
+
+10. Author's Address
+
+ Hugh Kennedy
+ Mimezine
+ 1060 West Addison
+ Chicago, IL 60613
+ USA
+
+ EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 15]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 16]
+
diff --git a/tests/auto/q3urloperator/tst_q3urloperator.cpp b/tests/auto/q3urloperator/tst_q3urloperator.cpp
new file mode 100644
index 0000000..d8711fa
--- /dev/null
+++ b/tests/auto/q3urloperator/tst_q3urloperator.cpp
@@ -0,0 +1,783 @@
+/****************************************************************************
+**
+** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
+** Contact: Qt Software Information (qt-info@nokia.com)
+**
+** This file is part of the test suite of the Qt Toolkit.
+**
+** $QT_BEGIN_LICENSE:LGPL$
+** No Commercial Usage
+** This file contains pre-release code and may not be distributed.
+** You may use this file in accordance with the terms and conditions
+** contained in the either Technology Preview License Agreement or the
+** Beta Release License Agreement.
+**
+** GNU Lesser General Public License Usage
+** Alternatively, this file may be used under the terms of the GNU Lesser
+** General Public License version 2.1 as published by the Free Software
+** Foundation and appearing in the file LICENSE.LGPL included in the
+** packaging of this file. Please review the following information to
+** ensure the GNU Lesser General Public License version 2.1 requirements
+** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
+**
+** In addition, as a special exception, Nokia gives you certain
+** additional rights. These rights are described in the Nokia Qt LGPL
+** Exception version 1.0, included in the file LGPL_EXCEPTION.txt in this
+** package.
+**
+** GNU General Public License Usage
+** Alternatively, this file may be used under the terms of the GNU
+** General Public License version 3.0 as published by the Free Software
+** Foundation and appearing in the file LICENSE.GPL included in the
+** packaging of this file. Please review the following information to
+** ensure the GNU General Public License version 3.0 requirements will be
+** met: http://www.gnu.org/copyleft/gpl.html.
+**
+** If you are unsure which license is appropriate for your use, please
+** contact the sales department at qt-sales@nokia.com.
+** $QT_END_LICENSE$
+**
+****************************************************************************/
+
+
+#include <QtTest/QtTest>
+
+#include <q3urloperator.h>
+#include <qtimer.h>
+#include <qapplication.h>
+#include <qfile.h>
+#include <qfileinfo.h>
+#include <qurlinfo.h>
+#include <q3network.h>
+#include <q3networkprotocol.h>
+#include <qtimer.h>
+#include <q3ptrlist.h>
+#include <q3valuelist.h>
+#include <qlist.h>
+
+//TESTED_CLASS=
+//TESTED_FILES=
+
+QT_FORWARD_DECLARE_CLASS(Q3NetworkOperation)
+
+class tst_Q3UrlOperator : public QObject
+{
+ Q_OBJECT
+
+public:
+ tst_Q3UrlOperator();
+ virtual ~tst_Q3UrlOperator();
+
+
+
+public slots:
+ void initTestCase();
+ void cleanupTestCase();
+ void init();
+ void cleanup();
+private slots:
+ void copy_data();
+ void copy();
+ void put_data();
+ void put();
+ void rename_data();
+ void rename();
+ void stop_data();
+ void stop();
+ void listChildren_data();
+ void listChildren();
+
+protected slots:
+ void slotFinished_init( Q3NetworkOperation* );
+ void slotFinished_cleanup( Q3NetworkOperation* );
+
+ void slotFinished_copy( Q3NetworkOperation* );
+
+ void slotFinished_put( Q3NetworkOperation* );
+ void slotData_put( const QByteArray&, Q3NetworkOperation* );
+
+ void slotFinished_rename( Q3NetworkOperation* );
+ void slotItemChanged_rename( Q3NetworkOperation* );
+
+ void slotFinished_stop( Q3NetworkOperation* );
+ void slotDataTransferProgress_stop( int, int, Q3NetworkOperation* );
+
+ void slotFinished_listChildren( Q3NetworkOperation* );
+ void slotNewChildren_listChildren( const Q3ValueList<QUrlInfo> &, Q3NetworkOperation * );
+
+ void stopOperation();
+
+private:
+ Q3UrlOperator *urlOp;
+ QString ftpQtestUpload;
+ bool doStop;
+ bool finished;
+
+ Q3PtrList<Q3NetworkOperation> pendingOperations;
+ Q3NetworkProtocol::State finishedState;
+ int finishedErrorCode;
+ QString finishedProtocolDetail;
+ Q3ValueList<QUrlInfo> listChildrenInfo;
+ QByteArray baData;
+ uint timeout_count;
+};
+
+//#define DUMP_SIGNALS
+
+tst_Q3UrlOperator::tst_Q3UrlOperator()
+{
+ q3InitNetworkProtocols();
+ timeout_count = 0;
+
+}
+
+tst_Q3UrlOperator::~tst_Q3UrlOperator()
+{
+}
+
+void tst_Q3UrlOperator::initTestCase()
+{
+ // create files for checking permissions
+ QFile textFile("listData/readOnly");
+ textFile.open(QIODevice::WriteOnly);
+ textFile.close();
+ textFile.setPermissions(QFile::ReadOwner | QFile::ReadUser | QFile::ReadGroup | QFile::ReadOther);
+ QFile exe("listData/executable.exe");
+ exe.open(QIODevice::WriteOnly);
+ exe.close();
+ exe.setPermissions(QFile::ReadOwner | QFile::ReadUser | QFile::ReadGroup | QFile::ReadOther |
+ QFile::ExeOwner | QFile::ExeUser | QFile::ExeGroup | QFile::ExeOther);
+
+ // prepare: make sure that there is a unique directory for FTP upload
+ // testing (to avoid parallel executed tests interfere with each other)
+ ftpQtestUpload = "ftp://qt-test-server.troll.no/";
+ QString dir = QString( "qtest/upload/%1" ).arg( (ulong)this );
+
+ Q3UrlOperator opMkdir( ftpQtestUpload );
+
+ connect( &opMkdir, SIGNAL(finished(Q3NetworkOperation*)), SLOT(slotFinished_init(Q3NetworkOperation*)) );
+ if ( opMkdir.mkdir( dir ) != 0 ) {
+ QTestEventLoop::instance().enterLoop( 30 );
+ if ( QTestEventLoop::instance().timeout() )
+ qWarning( "Prepare: Network operation timed out for create directory" );
+ }
+ ftpQtestUpload += dir;
+}
+
+void tst_Q3UrlOperator::slotFinished_init( Q3NetworkOperation *op )
+{
+ if ( op->state() == Q3NetworkProtocol::StFailed )
+ qWarning( QString( "Prepare: Can't create directory: network operation failed ('%1'). " ).arg(op->protocolDetail()) );
+ QTestEventLoop::instance().exitLoop();
+}
+
+void tst_Q3UrlOperator::cleanupTestCase()
+{
+ // remove the files created before
+ QFile textFile("listData/readOnly");
+ textFile.setPermissions(textFile.permissions() | QFile::WriteOwner);
+ if (! textFile.remove())
+ qWarning() << "could not remove file:" << textFile.error();
+ QFile exe("listData/executable.exe");
+ exe.setPermissions(textFile.permissions() | QFile::WriteOwner);
+ if (! exe.remove())
+ qWarning() << "could not remove file:" << exe.error();
+
+ // cleanup: delete the unique directory for FTP upload testing
+ QStringList tmp = QStringList::split( '/', ftpQtestUpload, TRUE );
+ QString dir = tmp.last();
+ tmp.pop_back();
+ QString url = tmp.join( "/" );
+
+ Q3UrlOperator opRemove( url );
+ connect( &opRemove, SIGNAL(finished(Q3NetworkOperation*)), SLOT(slotFinished_cleanup(Q3NetworkOperation*)) );
+ if ( opRemove.remove( dir ) != 0 ) {
+ QTestEventLoop::instance().enterLoop( 30 );
+ if ( QTestEventLoop::instance().timeout() )
+ qWarning( "Cleanup: Network operation timed out for removing directory" );
+ }
+}
+
+void tst_Q3UrlOperator::slotFinished_cleanup( Q3NetworkOperation *op )
+{
+ if ( op->state() == Q3NetworkProtocol::StFailed )
+ qWarning( QString( "Cleanup: Can't remove directory: network operation failed ('%1'). " ).arg(op->protocolDetail()) );
+ QTestEventLoop::instance().exitLoop();
+}
+
+void tst_Q3UrlOperator::init()
+{
+ doStop = FALSE;
+ finished = FALSE;
+ pendingOperations.clear();
+}
+
+void tst_Q3UrlOperator::cleanup()
+{
+}
+
+void tst_Q3UrlOperator::copy_data()
+{
+ const QString ftpQtest( "ftp://qt-test-server.troll.no/qtest" );
+ const QString httpQtest( "http://qt-test-server.troll.no/qtest" );
+
+ // argument for the constructor
+ QTest::addColumn<QString>("url");
+ // arguments for the copy()
+ QTest::addColumn<QString>("from");
+ QTest::addColumn<QString>("to");
+ QTest::addColumn<bool>("move");
+ QTest::addColumn<bool>("toPath");
+
+ // FTP data
+ // QTest::newRow( "ftp00" ) << QString() << QString("%1/rfc3252.txt").arg(ftpQtest) << QString(".") << (bool)FALSE << (bool)TRUE;
+ QTest::newRow( "ftp01" ) << QString() << QString("%1/rfc3252").arg(ftpQtest) << QString("rfc3252.txt") << (bool)FALSE << (bool)FALSE;
+
+ QTest::newRow( "ftp02" ) << QString("%1/").arg(ftpQtest) << QString("rfc3252.txt") << QString(".") << (bool)FALSE << (bool)TRUE;
+ QTest::newRow( "ftp03" ) << QString("%1/").arg(ftpQtest) << QString("rfc3252") << QString("rfc3252.txt") << (bool)FALSE << (bool)FALSE;
+
+ QTest::newRow( "ftp04" ) << QString("%1").arg(ftpQtest) << QString("rfc3252.txt") << QString(".") << (bool)FALSE << (bool)TRUE;
+ QTest::newRow( "ftp05" ) << QString("%1").arg(ftpQtest) << QString("rfc3252") << QString("rfc3252.txt") << (bool)FALSE << (bool)FALSE;
+
+ // the ftp.faqs.org host is down that often, that it does not make sense to
+ // use it for automated tests
+ // QTest::newRow( "ftp06" ) << QString() << QString("ftp://ftp.faqs.org/rfc/rfc3252.txt") << QString(".") << (bool)FALSE << (bool)TRUE;
+
+ // HTTP data
+ QTest::newRow( "http00" ) << QString() << QString("%1/rfc3252.txt").arg(httpQtest) << QString(".") << (bool)FALSE << (bool)TRUE;
+ QTest::newRow( "http01" ) << QString() << QString("%1/rfc3252").arg(httpQtest) << QString("rfc3252.txt") << (bool)FALSE << (bool)FALSE;
+ QTest::newRow( "http02" ) << QString() << QString("%1/").arg(httpQtest) << QString("rfc3252.txt") << (bool)FALSE << (bool)FALSE;
+
+ QTest::newRow( "http03" ) << QString("%1/").arg(httpQtest) << QString("rfc3252.txt") << QString(".") << (bool)FALSE << (bool)TRUE;
+ QTest::newRow( "http04" ) << QString("%1/").arg(httpQtest) << QString("rfc3252") << QString("rfc3252.txt") << (bool)FALSE << (bool)FALSE;
+ QTest::newRow( "http05" ) << QString("%1/").arg(httpQtest) << QString("") << QString("rfc3252.txt") << (bool)FALSE << (bool)FALSE;
+ QTest::newRow( "http06" ) << QString("%1/").arg(httpQtest) << QString() << QString("rfc3252.txt") << (bool)FALSE << (bool)FALSE;
+
+ QTest::newRow( "http07" ) << QString("%1").arg(httpQtest) << QString("rfc3252.txt") << QString(".") << (bool)FALSE << (bool)TRUE;
+ QTest::newRow( "http08" ) << QString("%1").arg(httpQtest) << QString("rfc3252") << QString("rfc3252.txt") << (bool)FALSE << (bool)FALSE;
+ QTest::newRow( "http09" ) << QString("%1").arg(httpQtest) << QString("") << QString("rfc3252.txt") << (bool)FALSE << (bool)FALSE;
+ QTest::newRow( "http10" ) << QString("%1").arg(httpQtest) << QString() << QString("rfc3252.txt") << (bool)FALSE << (bool)FALSE;
+
+ // Unstable host:
+ // QTest::newRow( "http11" ) << QString() << QString("http://www.ietf.org/rfc/rfc3252.txt") << QString(".") << (bool)FALSE << (bool)TRUE;
+}
+
+void tst_Q3UrlOperator::copy()
+{
+ if (timeout_count >= 3) {
+ QFAIL( "Too many timeout's. Aborting test prematurely." );
+ }
+
+ QFETCH( QString, url );
+ QFETCH( QString, from );
+ QFETCH( QString, to );
+ QFETCH( bool, move );
+ QFETCH( bool, toPath );
+
+ if ( url.isNull() ) {
+ urlOp = new Q3UrlOperator();
+ } else {
+ urlOp = new Q3UrlOperator( url );
+ }
+ pendingOperations = urlOp->copy( from, to, move, toPath );
+
+ connect( urlOp, SIGNAL(finished(Q3NetworkOperation*)), SLOT(slotFinished_copy(Q3NetworkOperation*)) );
+
+ QTestEventLoop::instance().enterLoop( 60 );
+ delete urlOp;
+ if ( QTestEventLoop::instance().timeout() )
+ QFAIL( "Network operation timed out" );
+
+ // test the results of the operation
+ if ( finished ) {
+ QVERIFY( finishedState==Q3NetworkProtocol::StDone || finishedState==Q3NetworkProtocol::StFailed );
+ if ( finishedState == Q3NetworkProtocol::StDone ) {
+ QFile file( "rfc3252.txt" );
+ if ( !file.open( QIODevice::ReadOnly ) )
+ QFAIL( "Could not open downloaded file" );
+
+ // ### this should move in the tesdata
+ QFile fileRes( "copy.res/rfc3252.txt" );
+ if ( !fileRes.open( QIODevice::ReadOnly ) )
+ QFAIL( "Could not open result file" );
+
+ QCOMPARE(file.readAll(), fileRes.readAll());
+
+ // delete the downloaded file
+ if ( !file.remove() )
+ QFAIL( QString("Cleanup failed: could not remove the downloaded file '%1'").arg(file.name()) );
+ timeout_count = 0;
+ } else {
+ QFAIL( QString( "Network operation failed ('%1'). "
+ "This could be due to a temporary network failure. "
+ "If this test continues to fail, take a closer look").arg(finishedProtocolDetail) );
+ timeout_count++;
+ }
+ }
+}
+
+void tst_Q3UrlOperator::slotFinished_copy( Q3NetworkOperation *op )
+{
+#if defined( DUMP_SIGNALS )
+ qDebug( "finished( %p )", op );
+#endif
+ QVERIFY( op != 0 );
+ pendingOperations.remove( op );
+ // We are finished if either of this happens:
+ // - both, the get and the put of the copy are finished
+ // - we are in an error case (for the case that the get fails, no
+ // finished() signal for the put is emitted since it is never executed)
+ if ( pendingOperations.isEmpty() || op->state()==Q3NetworkProtocol::StFailed ) {
+ finished = TRUE;
+ finishedState = op->state();
+ finishedErrorCode = op->errorCode();
+ finishedProtocolDetail = op->protocolDetail();
+
+ QTestEventLoop::instance().exitLoop();
+ }
+}
+
+void tst_Q3UrlOperator::put_data()
+{
+ const QString httpQtest( "http://qt-test-server.troll.no/qtest/cgi-bin" );
+ const QString httpQtestGet( "http://qt-test-server.troll.no/qtest/cgi-bin/retrieve_testfile.cgi" );
+
+ QByteArray putData_1( 5 );
+ putData_1[0] = 'a';
+ putData_1[1] = 'b';
+ putData_1[2] = '\n';
+ putData_1[3] = 'c';
+ putData_1[4] = 'd';
+
+ QTest::addColumn<QString>("url");
+ QTest::addColumn<QString>("to");
+ QTest::addColumn<QByteArray>("putData");
+ QTest::addColumn<QString>("getUrl");
+ QTest::addColumn<QString>("rmUrl");
+ QTest::addColumn<QString>("rmFile");
+
+ // FTP data
+ QTest::newRow( "ftp00" )
+ << ftpQtestUpload << "put_ftp00" << putData_1
+ << QString("%1/put_ftp00").arg(ftpQtestUpload)
+ << ftpQtestUpload << "put_ftp00";
+ QTest::newRow( "ftp01" )
+ << QString() << QString("%1/put_ftp01").arg(ftpQtestUpload) << putData_1
+ << QString("%1/put_ftp01").arg(ftpQtestUpload)
+ << ftpQtestUpload << "put_ftp01";
+
+ QTest::newRow( "ftp02" )
+ << ftpQtestUpload << "put_ftp02" << QByteArray(0)
+ << QString("%1/put_ftp02").arg(ftpQtestUpload)
+ << ftpQtestUpload << "put_ftp02";
+ QTest::newRow( "ftp03" )
+ << QString() << QString("%1/put_ftp03").arg(ftpQtestUpload) << QByteArray(0)
+ << QString("%1/put_ftp03").arg(ftpQtestUpload)
+ << ftpQtestUpload << "put_ftp03";
+ // HTTP data
+ QTest::newRow( "http00" )
+ << httpQtest << "store_testfile.cgi" << putData_1
+ << httpQtestGet
+ << httpQtest << QString();
+ QTest::newRow( "http01" )
+ << QString() << QString("%1/store_testfile.cgi").arg(httpQtest) << putData_1
+ << httpQtestGet
+ << httpQtest << QString();
+ QTest::newRow( "http02" )
+ << httpQtest << "store_testfile.cgi" << QByteArray(0)
+ << httpQtestGet
+ << httpQtest << QString();
+ QTest::newRow( "http03" ) << QString() << QString("%1/store_testfile.cgi").arg(httpQtest) << QByteArray(0)
+ << httpQtestGet
+ << httpQtest << QString();
+}
+
+void tst_Q3UrlOperator::put()
+{
+ {
+ // do the put
+ QFETCH( QString, url );
+ QFETCH( QString, to );
+ QFETCH( QByteArray, putData );
+
+ if ( url.isNull() ) {
+ urlOp = new Q3UrlOperator();
+ } else {
+ urlOp = new Q3UrlOperator( url );
+ }
+
+ pendingOperations.append( urlOp->put( putData, to) );
+
+ connect( urlOp, SIGNAL(finished(Q3NetworkOperation*)), SLOT(slotFinished_put(Q3NetworkOperation*)) );
+
+ QTestEventLoop::instance().enterLoop( 30 );
+ delete urlOp;
+ if ( QTestEventLoop::instance().timeout() )
+ QFAIL( "Network operation timed out" );
+ }
+ {
+ // In order to test that the put was really successful, we have to get the
+ // file from the server.
+ QFETCH( QString, getUrl );
+ baData.resize( 0 );
+ Q3UrlOperator opGet( getUrl );
+ opGet.get();
+ connect( &opGet, SIGNAL(finished(Q3NetworkOperation*)), SLOT(slotFinished_put(Q3NetworkOperation*)) );
+ connect( &opGet, SIGNAL(data(const QByteArray&,Q3NetworkOperation*)), SLOT(slotData_put(const QByteArray&,Q3NetworkOperation*)) );
+ QTestEventLoop::instance().enterLoop( 30 );
+ if ( QTestEventLoop::instance().timeout() )
+ QFAIL( "Network operation timed out" );
+
+ QTEST( baData, "putData" );
+ }
+ {
+ // cleanup: delete file (if possible)
+ QFETCH( QString, rmUrl );
+ QFETCH( QString, rmFile );
+ Q3UrlOperator opRemove( rmUrl );
+ connect( &opRemove, SIGNAL(finished(Q3NetworkOperation*)), SLOT(slotFinished_put(Q3NetworkOperation*)) );
+ if ( opRemove.remove( rmFile ) != 0 ) {
+ QTestEventLoop::instance().enterLoop( 30 );
+ if ( QTestEventLoop::instance().timeout() )
+ QFAIL( "Network operation timed out" );
+ QVERIFY( finishedState==Q3NetworkProtocol::StDone || finishedState==Q3NetworkProtocol::StFailed );
+ if ( finishedState != Q3NetworkProtocol::StDone ) {
+ QFAIL( QString( "Can't remove file: network operation failed ('%1'). " ).arg(finishedProtocolDetail) );
+ }
+ }
+ }
+}
+
+void tst_Q3UrlOperator::slotFinished_put( Q3NetworkOperation *op )
+{
+#if defined( DUMP_SIGNALS )
+ qDebug( "finished( %p )", op );
+#endif
+ QVERIFY( op != 0 );
+ pendingOperations.remove( op );
+ QVERIFY( pendingOperations.isEmpty() );
+
+ finished = TRUE;
+ finishedState = op->state();
+ finishedErrorCode = op->errorCode();
+ finishedProtocolDetail = op->protocolDetail();
+
+ if (op->state() != Q3NetworkProtocol::StFailed)
+ QTestEventLoop::instance().exitLoop();
+}
+
+void tst_Q3UrlOperator::slotData_put( const QByteArray& ba, Q3NetworkOperation *op )
+{
+#if defined( DUMP_SIGNALS )
+ qDebug( "data( %d, %p )", ba.size(), op );
+#endif
+ QVERIFY( op != 0 );
+ int oldSize = baData.size();
+ baData.resize( ba.size() + oldSize );
+ memcpy( baData.data()+oldSize, ba.data(), ba.size() );
+}
+
+void tst_Q3UrlOperator::rename_data()
+{
+ QTest::addColumn<QString>("url");
+ QTest::addColumn<QString>("oldname");
+ QTest::addColumn<QString>("newname");
+
+ QTest::newRow( "local00" ) << QString(".") << QString("foo") << QString("bar");
+}
+
+void tst_Q3UrlOperator::rename()
+{
+ {
+ // create direcotry first
+ QFETCH( QString, url );
+ QFETCH( QString, oldname );
+
+ if ( url.isNull() ) {
+ urlOp = new Q3UrlOperator();
+ } else {
+ urlOp = new Q3UrlOperator( url );
+ }
+
+ pendingOperations.append( urlOp->mkdir( oldname ) );
+
+ connect( urlOp, SIGNAL(finished(Q3NetworkOperation*)), SLOT(slotFinished_rename(Q3NetworkOperation*)) );
+
+ QTestEventLoop::instance().enterLoop( 30 );
+ delete urlOp;
+ if ( QTestEventLoop::instance().timeout() )
+ QFAIL( "Network operation timed out" );
+
+ QVERIFY( finishedState == Q3NetworkProtocol::StDone );
+ }
+ {
+ // rename directory
+ QFETCH( QString, url );
+ QFETCH( QString, oldname );
+ QFETCH( QString, newname );
+
+ if ( url.isNull() ) {
+ urlOp = new Q3UrlOperator();
+ } else {
+ urlOp = new Q3UrlOperator( url );
+ }
+
+ pendingOperations.append( urlOp->rename( oldname, newname ) );
+
+ connect( urlOp, SIGNAL(finished(Q3NetworkOperation*)), SLOT(slotFinished_rename(Q3NetworkOperation*)) );
+ connect( urlOp, SIGNAL(itemChanged(Q3NetworkOperation*)), SLOT(slotItemChanged_rename(Q3NetworkOperation*)) );
+
+ QTestEventLoop::instance().enterLoop( 30 );
+ delete urlOp;
+ if ( QTestEventLoop::instance().timeout() )
+ QFAIL( "Network operation timed out" );
+
+ QVERIFY( finishedState == Q3NetworkProtocol::StDone );
+ }
+ {
+ // delete direcotry
+ QFETCH( QString, url );
+ QFETCH( QString, newname );
+
+ if ( url.isNull() ) {
+ urlOp = new Q3UrlOperator();
+ } else {
+ urlOp = new Q3UrlOperator( url );
+ }
+
+ pendingOperations.append( urlOp->remove( newname ) );
+
+ connect( urlOp, SIGNAL(finished(Q3NetworkOperation*)), SLOT(slotFinished_rename(Q3NetworkOperation*)) );
+
+ QTestEventLoop::instance().enterLoop( 30 );
+ delete urlOp;
+ if ( QTestEventLoop::instance().timeout() )
+ QFAIL( "Network operation timed out" );
+
+ QVERIFY( finishedState == Q3NetworkProtocol::StDone );
+ }
+}
+
+void tst_Q3UrlOperator::slotFinished_rename( Q3NetworkOperation *op )
+{
+#if defined( DUMP_SIGNALS )
+ qDebug( "finished( %p )", op );
+#endif
+ QVERIFY( op != 0 );
+ pendingOperations.remove( op );
+ QVERIFY( pendingOperations.isEmpty() );
+
+ finished = TRUE;
+ finishedState = op->state();
+ finishedErrorCode = op->errorCode();
+ finishedProtocolDetail = op->protocolDetail();
+
+ QTestEventLoop::instance().exitLoop();
+}
+
+void tst_Q3UrlOperator::slotItemChanged_rename( Q3NetworkOperation *op )
+{
+#if defined( DUMP_SIGNALS )
+ qDebug( "itemChanged( %p )", op );
+#endif
+ QVERIFY( op != 0 );
+ // ### what to do here?
+}
+
+void tst_Q3UrlOperator::stop_data()
+{
+ QTest::addColumn<QString>("from");
+ QTest::addColumn<QString>("to");
+ QTest::addColumn<QString>("rmUrl");
+ QTest::addColumn<QString>("rmFile");
+
+ // FTP data
+ QTest::newRow( "ftp01" )
+ << "stop/bigfile" << ftpQtestUpload
+ << ftpQtestUpload << "bigfile";
+}
+
+void tst_Q3UrlOperator::stop()
+{
+ doStop = TRUE;
+ urlOp = new Q3UrlOperator();
+ connect( urlOp, SIGNAL(finished(Q3NetworkOperation*)),
+ SLOT(slotFinished_stop(Q3NetworkOperation*)) );
+ connect( urlOp, SIGNAL(dataTransferProgress(int,int,Q3NetworkOperation*)),
+ SLOT(slotDataTransferProgress_stop(int,int,Q3NetworkOperation*)) );
+ {
+ // do the upload
+ QFETCH( QString, from );
+ QFETCH( QString, to );
+ pendingOperations = urlOp->copy( from, to );
+
+ QTestEventLoop::instance().enterLoop( 30 );
+ if ( QTestEventLoop::instance().timeout() )
+ QFAIL( "Network operation timed out" );
+ }
+ doStop = FALSE;
+ {
+ // do the upload again (this time without stop) -- this used to fail
+ // until change 71380
+ QFETCH( QString, from );
+ QFETCH( QString, to );
+ pendingOperations = urlOp->copy( from, to );
+
+ QTestEventLoop::instance().enterLoop( 30 );
+ if ( QTestEventLoop::instance().timeout() )
+ QFAIL( "Network operation timed out" );
+ }
+ delete urlOp;
+
+ {
+ // cleanup: delete file (if possible)
+ QFETCH( QString, rmUrl );
+ QFETCH( QString, rmFile );
+ Q3UrlOperator opRemove( rmUrl );
+ connect( &opRemove, SIGNAL(finished(Q3NetworkOperation*)), SLOT(slotFinished_stop(Q3NetworkOperation*)) );
+ if ( opRemove.remove( rmFile ) != 0 ) {
+ QTestEventLoop::instance().enterLoop( 30 );
+ if ( QTestEventLoop::instance().timeout() )
+ QFAIL( "Network operation timed out" );
+ QVERIFY( finishedState==Q3NetworkProtocol::StDone || finishedState==Q3NetworkProtocol::StFailed );
+ if ( finishedState != Q3NetworkProtocol::StDone )
+ QFAIL( QString( "Can't remove file: network operation failed ('%1'). " ).arg(finishedProtocolDetail) );
+ }
+ }
+}
+
+void tst_Q3UrlOperator::slotFinished_stop( Q3NetworkOperation *op )
+{
+#if defined( DUMP_SIGNALS )
+ qDebug( "finished( %p )", op );
+#endif
+ QVERIFY( op != 0 );
+
+ pendingOperations.remove( op );
+ // We are finished if either of this happens:
+ // - both, the get and the put of the copy are finished
+ // - we are in an error case (for the case that the get fails, no
+ // finished() signal for the put is emitted since it is never executed)
+ if ( pendingOperations.isEmpty() || op->state()==Q3NetworkProtocol::StFailed ) {
+ finished = TRUE;
+ finishedState = op->state();
+ finishedErrorCode = op->errorCode();
+ finishedProtocolDetail = op->protocolDetail();
+
+ QTestEventLoop::instance().exitLoop();
+ }
+}
+
+void tst_Q3UrlOperator::slotDataTransferProgress_stop( int done, int total, Q3NetworkOperation *op )
+{
+#if defined( DUMP_SIGNALS )
+ qDebug( "dataTransferProgress( %d, %d, %p )", done, total, op );
+#endif
+ QVERIFY( op != 0 );
+ QVERIFY( done <= total );
+
+ if ( QTest::currentTestFunction() == QLatin1String("stop") ) {
+ // ### it would be nice if we could specify in our testdata when to do
+ // the stop
+ if ( doStop && pendingOperations.count()==1 ) {
+ if ( done > 0 && done >= total/100000 ) {
+ // it is not safe to call stop() in a slot connected to the
+ // dataTransferProgress() signal (and it is not trivial to make
+ // it work)
+ QTimer::singleShot( 0, this, SLOT(stopOperation()) );
+ doStop = FALSE;
+ }
+ }
+ }
+}
+
+void tst_Q3UrlOperator::stopOperation()
+{
+ if ( urlOp )
+ urlOp->stop();
+}
+
+void tst_Q3UrlOperator::listChildren_data()
+{
+ QTest::addColumn<QString>("url");
+ QTest::addColumn<QString>("nameFilter");
+ QTest::addColumn<bool>("readable");
+ QTest::addColumn<bool>("writable");
+ QTest::addColumn<bool>("executable");
+ QTest::addColumn<int>("permissions");
+
+ QTest::newRow( "localfs00" )
+ << QString("listData") << QString("readOnly")
+ << (bool)TRUE << (bool)FALSE << (bool)FALSE << 0444;
+ QTest::newRow( "localfs01" )
+ << QString("listData") << QString("executable.exe")
+ << (bool)TRUE << (bool)FALSE << (bool)TRUE << 0555;
+ int permissions = 0755;
+#ifdef Q_OS_WIN
+ permissions = 0777;
+#endif
+ QTest::newRow( "localfs02" )
+ << QString("listData") << QString("readWriteExec.exe")
+ << (bool)TRUE << (bool)TRUE << (bool)TRUE << permissions;
+}
+
+void tst_Q3UrlOperator::listChildren()
+{
+ QFETCH( QString, url );
+ QFETCH( QString, nameFilter );
+ urlOp = new Q3UrlOperator( "listData" );
+ urlOp->setNameFilter( nameFilter );
+
+ pendingOperations.append( urlOp->listChildren() );
+
+ connect( urlOp, SIGNAL(finished(Q3NetworkOperation*)),
+ SLOT(slotFinished_listChildren(Q3NetworkOperation*)) );
+ connect( urlOp, SIGNAL(newChildren(const Q3ValueList<QUrlInfo>&, Q3NetworkOperation*)),
+ SLOT(slotNewChildren_listChildren(const Q3ValueList<QUrlInfo>&, Q3NetworkOperation*)) );
+
+ QTestEventLoop::instance().enterLoop( 30 );
+ delete urlOp;
+ if ( QTestEventLoop::instance().timeout() )
+ QFAIL( "Network operation timed out" );
+
+ QVERIFY( finishedState == Q3NetworkProtocol::StDone );
+ for ( int i=0; i<(int)listChildrenInfo.count(); i++ ) {
+ if ( listChildrenInfo[i].name() == "." || listChildrenInfo[i].name() == ".." )
+ continue;
+
+ QFETCH( bool, readable );
+ QFETCH( bool, writable );
+ QFETCH( bool, executable );
+ QFETCH( int, permissions );
+ QCOMPARE( listChildrenInfo[i].isReadable(), readable );
+ QCOMPARE( listChildrenInfo[i].isWritable(), writable );
+
+ QCOMPARE( listChildrenInfo[i].isExecutable(), executable);
+ QCOMPARE( listChildrenInfo[i].permissions(), permissions );
+ }
+}
+
+void tst_Q3UrlOperator::slotFinished_listChildren( Q3NetworkOperation *op )
+{
+#if defined( DUMP_SIGNALS )
+ qDebug( "finished( %p )", op );
+#endif
+ QVERIFY( op != 0 );
+ pendingOperations.remove( op );
+ QVERIFY( pendingOperations.isEmpty() );
+
+ finished = TRUE;
+ finishedState = op->state();
+ finishedErrorCode = op->errorCode();
+ finishedProtocolDetail = op->protocolDetail();
+
+ QTestEventLoop::instance().exitLoop();
+}
+
+void tst_Q3UrlOperator::slotNewChildren_listChildren( const Q3ValueList<QUrlInfo> &i, Q3NetworkOperation * )
+{
+ listChildrenInfo = i;
+}
+
+QTEST_MAIN(tst_Q3UrlOperator)
+#include "tst_q3urloperator.moc"