diff -r 000000000000 -r 1918ee327afb tests/auto/qnetworkreply/bigfile
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/tests/auto/qnetworkreply/bigfile Mon Jan 11 14:00:40 2010 +0000
@@ -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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 ("
+ -->
+
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.2. TCPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.3. UDPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 ("
+ -->
+
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.2. TCPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.3. UDPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 ("
+ -->
+
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.2. TCPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.3. UDPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 ("
+ -->
+
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.2. TCPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.3. UDPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 ("
+ -->
+
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.2. TCPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.3. UDPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 ("
+ -->
+
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.2. TCPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.3. UDPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 ("
+ -->
+
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.2. TCPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.3. UDPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 ("
+ -->
+
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.2. TCPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.3. UDPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 ("
+ -->
+
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.2. TCPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.3. UDPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 ("
+ -->
+
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.2. TCPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.3. UDPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 ("
+ -->
+
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.2. TCPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.3. UDPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 ("
+ -->
+
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.2. TCPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.3. UDPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 ("
+ -->
+
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.2. TCPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.3. UDPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 ("
+ -->
+
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.2. TCPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.3. UDPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 ("
+ -->
+
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.2. TCPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.3. UDPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 ("
+ -->
+
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.2. TCPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.3. UDPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 ("
+ -->
+
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.2. TCPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.3. UDPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 ("
+ -->
+
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.2. TCPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.3. UDPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 ("
+ -->
+
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.2. TCPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.3. UDPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+3.2. Example Datagram
+
+ The following is an example TCPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 header
+ as well as the declaration.
+
+4.2. Example Datagram
+
+ The following is an example UDPoXML datagram with an empty payload:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 ("
+ -->
+
+
+
+
+Kennedy Informational [Page 7]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 9]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 10]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.2. TCPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 11]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy Informational [Page 12]
+
+RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+7.3. UDPoXML DTD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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]
+