diff options
Diffstat (limited to 'tests/auto/qnetworkreply')
22 files changed, 25625 insertions, 0 deletions
diff --git a/tests/auto/qnetworkreply/.gitattributes b/tests/auto/qnetworkreply/.gitattributes new file mode 100644 index 0000000000..80252cfd34 --- /dev/null +++ b/tests/auto/qnetworkreply/.gitattributes @@ -0,0 +1,3 @@ +rfc3252.txt -crlf +bigfile -crlf +resource -crlf diff --git a/tests/auto/qnetworkreply/.gitignore b/tests/auto/qnetworkreply/.gitignore new file mode 100644 index 0000000000..2797fcd809 --- /dev/null +++ b/tests/auto/qnetworkreply/.gitignore @@ -0,0 +1,3 @@ +tst_qnetworkreply +echo/echo +echo/echo.exe diff --git a/tests/auto/qnetworkreply/bigfile b/tests/auto/qnetworkreply/bigfile new file mode 100644 index 0000000000..cb114a2b0e --- /dev/null +++ b/tests/auto/qnetworkreply/bigfile @@ -0,0 +1,17980 @@ + + + + + + +Network Working Group H. Kennedy +Request for Comments: 3252 Mimezine +Category: Informational 1 April 2002 + + + Binary Lexical Octet Ad-hoc Transport + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document defines a reformulation of IP and two transport layer + protocols (TCP and UDP) as XML applications. + +1. Introduction + +1.1. Overview + + This document describes the Binary Lexical Octet Ad-hoc Transport + (BLOAT): a reformulation of a widely-deployed network-layer protocol + (IP [RFC791]), and two associated transport layer protocols (TCP + [RFC793] and UDP [RFC768]) as XML [XML] applications. It also + describes methods for transporting BLOAT over Ethernet and IEEE 802 + networks as well as encapsulating BLOAT in IP for gatewaying BLOAT + across the public Internet. + +1.2. Motivation + + The wild popularity of XML as a basis for application-level protocols + such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple + Object Access Protocol [SOAP], and Jabber [JABBER] prompted + investigation into the possibility of extending the use of XML in the + protocol stack. Using XML at both the transport and network layer in + addition to the application layer would provide for an amazing amount + of power and flexibility while removing dependencies on proprietary + and hard-to-understand binary protocols. This protocol unification + would also allow applications to use a single XML parser for all + aspects of their operation, eliminating developer time spent figuring + out the intricacies of each new protocol, and moving the hard work of + + + + +Kennedy Informational [Page 1] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + parsing to the XML toolset. The use of XML also mitigates concerns + over "network vs. host" byte ordering which is at the root of many + network application bugs. + +1.3. Relation to Existing Protocols + + The reformulations specified in this RFC follow as closely as + possible the spirit of the RFCs on which they are based, and so MAY + contain elements or attributes that would not be needed in a pure + reworking (e.g. length attributes, which are implicit in XML.) + + The layering of network and transport protocols are maintained in + this RFC despite the optimizations that could be made if the line + were somewhat blurred (i.e. merging TCP and IP into a single, larger + element in the DTD) in order to foster future use of this protocol as + a basis for reformulating other protocols (such as ICMP.) + + Other than the encoding, the behavioral aspects of each of the + existing protocols remain unchanged. Routing, address spaces, TCP + congestion control, etc. behave as specified in the extant standards. + Adapting to new standards and experimental algorithm heuristics for + improving performance will become much easier once the move to BLOAT + has been completed. + +1.4. Requirement Levels + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 + [RFC2119]. + +2. IPoXML + + This protocol MUST be implemented to be compliant with this RFC. + IPoXML is the root protocol REQUIRED for effective use of TCPoXML + (section 3.) and higher-level application protocols. + + The DTD for this document type can be found in section 7.1. + + The routing of IPoXML can be easily implemented on hosts with an XML + parser, as the regular structure lends itself handily to parsing and + validation of the document/datagram and then processing the + destination address, TTL, and checksum before sending it on to its + next-hop. + + The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the + wider deployment of IPv4 and the fact that implementing IPv6 as XML + would have exceeded the 1500 byte Ethernet MTU. + + + +Kennedy Informational [Page 2] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + All BLOAT implementations MUST use - and specify - the UTF-8 encoding + of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well- + formed and include the XMLDecl. + +2.1. IP Description + + A number of items have changed (for the better) from the original IP + specification. Bit-masks, where present have been converted into + human-readable values. IP addresses are listed in their dotted- + decimal notation [RFC1123]. Length and checksum values are present + as decimal integers. + + To calculate the length and checksum fields of the IP element, a + canonicalized form of the element MUST be used. The canonical form + SHALL have no whitespace (including newline characters) between + elements and only one space character between attributes. There + SHALL NOT be a space following the last attribute in an element. + + An iterative method SHOULD be used to calculate checksums, as the + length field will vary based on the size of the checksum. + + The payload element bears special attention. Due to the character + set restrictions of XML, the payload of IP datagrams (which MAY + contain arbitrary data) MUST be encoded for transport. This RFC + REQUIRES the contents of the payload to be encoded in the base-64 + encoding of RFC 2045 [RFC2045], but removes the requirement that the + encoded output MUST be wrapped on 76-character lines. + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 3] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +2.2. Example Datagram + + The following is an example IPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + <ip> + <header length="474"> + <version value="4"/> + <tos precedence="Routine" delay="Normal" throughput="Normal" + relibility="Normal" reserved="0"/> + <total.length value="461"/> + <id value="1"/> + <flags reserved="0" df="dont" mf="last"/> + <offset value="0"/> + <ttl value="255"/> + <protocol value="6"/> + <checksum value="8707"/> + <source address="10.0.0.22"/> + <destination address="10.0.0.1"/> + <options> + <end copied="0" class="0" number="0"/> + </options> + <padding pad="0"/> + </header> + <payload> + </payload> + </ip> + +3. TCPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.2. + +3.1. TCP Description + + A number of items have changed from the original TCP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + To calculate the length and checksum fields of the TCP element, a + canonicalized form of the element MUST be used as in section 2.1. + + An iterative method SHOULD be used to calculate checksums as in + section 2.1. + + The payload element MUST be encoded as in section 2.1. + + + +Kennedy Informational [Page 4] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + The TCP offset element was expanded to a maximum of 255 from 16 to + allow for the increased size of the header in XML. + + TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + <tcp> + <tcp.header> + <src port="31415"/> + <dest port="42424"/> + <sequence number="322622954"/> + <acknowledgement number="689715995"/> + <offset number=""/> + <reserved value="0"/> + <control syn="1" ack="1"/> + <window size="1"/> + <urgent pointer="0"/> + <checksum value="2988"/> + <tcp.options> + <tcp.end kind="0"/> + </tcp.options> + <padding pad="0"/> + </tcp.header> + <payload> + </payload> + </tcp> + +4. UDPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.3. + +4.1. UDP Description + + A number of items have changed from the original UDP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + + + + + + +Kennedy Informational [Page 5] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + To calculate the length and checksum fields of the UDP element, a + canonicalized form of the element MUST be used as in section 2.1. An + iterative method SHOULD be used to calculate checksums as in section + 2.1. + + The payload element MUST be encoded as in section 2.1. + + UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + <udp> + <udp.header> + <src port="31415"/> + <dest port="42424"/> + <udp.length value="143"/> + <checksum value="2988"/> + </udp.header> + <payload> + </payload> + </udp> + +5. Network Transport + + This document provides for the transmission of BLOAT datagrams over + two common families of physical layer transport. Future RFCs will + address additional transports as routing vendors catch up to the + specification, and we begin to see BLOAT routed across the Internet + backbone. + +5.1. Ethernet + + BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the + exception that the type field of the Ethernet frame MUST contain the + value 0xBEEF. The first 5 octets of the Ethernet frame payload will + be 0x3c 3f 78 6d 6c ("<?xml".) + +5.2. IEEE 802 + + BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except + that the protocol type code for IPoXML is 0xBEEF. + + + + + +Kennedy Informational [Page 6] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +6. Gatewaying over IP + + In order to facilitate the gradual introduction of BLOAT into the + public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to + gateway between networks that run BLOAT natively on their LANs. + +7. DTDs + + The Transport DTDs (7.2. and 7.3.) build on the definitions in the + Network DTD (7.1.) + + The DTDs are referenced by their PubidLiteral and SystemLiteral (from + [XML]) although it is understood that most IPoXML implementations + will not need to pull down the DTD, as it will normally be embedded + in the implementation, and presents something of a catch-22 if you + need to load part of your network protocol over the network. + +7.1. IPoXML DTD + + <!-- + DTD for IP over XML. + Refer to this DTD as: + + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + --> + <!-- + DTD data types: + + Digits [0..9]+ + + Precedence "NetworkControl | InternetworkControl | + CRITIC | FlashOverride | Flash | Immediate | + Priority | Routine" + + IP4Addr "dotted-decimal" notation of [RFC1123] + + Class [0..3] + + Sec "Unclassified | Confidential | EFTO | MMMM | PROG | + Restricted | Secret | Top Secret | Reserved" + + Compartments [0..65535] + + Handling [0..65535] + + TCC [0..16777216] + + --> + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ENTITY % Digits "CDATA"> + <!ENTITY % Precedence "CDATA"> + <!ENTITY % IP4Addr "CDATA"> + <!ENTITY % Class "CDATA"> + <!ENTITY % Sec "CDATA"> + <!ENTITY % Compartments "CDATA"> + <!ENTITY % Handling "CDATA"> + <!ENTITY % TCC "CDATA"> + + <!ELEMENT ip (header, payload)> + + <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl, + protocol, checksum, source, destination, options, + padding)> + <!-- length of header in 32-bit words --> + <!ATTLIST header + length %Digits; #REQUIRED> + + <!ELEMENT version EMPTY> + <!-- ip version. SHOULD be "4" --> + <!ATTLIST version + value %Digits; #REQUIRED> + + <!ELEMENT tos EMPTY> + <!ATTLIST tos + precedence %Precedence; #REQUIRED + delay (normal | low) #REQUIRED + throughput (normal | high) #REQUIRED + relibility (normal | high) #REQUIRED + reserved CDATA #FIXED "0"> + + <!ELEMENT total.length EMPTY> + <!-- + total length of datagram (header and payload) in octets, MUST be + less than 65,535 (and SHOULD be less than 1024 for IPoXML on local + ethernets). + --> + <!ATTLIST total.length + value %Digits; #REQUIRED> + + <!ELEMENT id EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST id + value %Digits; #REQUIRED> + + <!ELEMENT flags EMPTY> + <!-- df = don't fragment, mf = more fragments --> + <!ATTLIST flags + + + +Kennedy Informational [Page 8] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + reserved CDATA #FIXED "0" + df (may|dont) #REQUIRED + mf (last|more) #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks --> + <!ATTLIST offset + value %Digits; #REQUIRED> + + <!ELEMENT ttl EMPTY> + <!-- 0 <= ttl <= 255 --> + <!ATTLIST ttl + value %Digits; #REQUIRED> + + <!ELEMENT protocol EMPTY> + <!-- 0 <= protocol <= 255 (per IANA) --> + <!ATTLIST protocol + value %Digits; #REQUIRED> + + <!ELEMENT checksum EMPTY> + <!-- 0 <= checksum <= 65535 (over header only) --> + <!ATTLIST checksum + value %Digits; #REQUIRED> + + <!ELEMENT source EMPTY> + <!ATTLIST source + address %IP4Addr; #REQUIRED> + + <!ELEMENT destination EMPTY> + <!ATTLIST destination + address %IP4Addr; #REQUIRED> + + <!ELEMENT options ( end | noop | security | loose | strict | record + | stream | timestamp )*> + + <!ELEMENT end EMPTY> + <!ATTLIST end + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "0"> + + <!ELEMENT noop EMPTY> + <!ATTLIST noop + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "1"> + + <!ELEMENT security EMPTY> + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST security + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "2" + length CDATA #FIXED "11" + security %Sec; #REQUIRED + compartments %Compartments; #REQUIRED + handling %Handling; #REQUIRED + tcc %TCC; #REQUIRED> + <!ELEMENT loose (hop)+> + <!ATTLIST loose + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "3" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT hop EMPTY> + <!ATTLIST hop + address %IP4Addr; #REQUIRED> + + <!ELEMENT strict (hop)+> + <!ATTLIST strict + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "9" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT record (hop)+> + <!ATTLIST record + copied CDATA #FIXED "0" + class CDATA #FIXED "0" + number CDATA #FIXED "7" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT stream EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST stream + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "8" + length CDATA #FIXED "4" + id %Digits; #REQUIRED> + + <!ELEMENT timestamp (tstamp)+> + <!-- 0 <= oflw <=15 --> + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST timestamp + copied CDATA #FIXED "0" + class CDATA #FIXED "2" + number CDATA #FIXED "4" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED + oflw %Digits; #REQUIRED + flag (0 | 1 | 3) #REQUIRED> + + <!ELEMENT tstamp EMPTY> + <!ATTLIST tstamp + time %Digits; #REQUIRED + address %IP4Addr; #IMPLIED> + <!-- + padding to bring header to 32-bit boundary. + pad MUST be "0"* + --> + <!ELEMENT padding EMPTY> + <!ATTLIST padding + pad CDATA #REQUIRED> + + <!-- payload MUST be encoded as base-64 [RFC2045], as modified + by section 2.1 of this RFC --> + <!ELEMENT payload (CDATA)> + +7.2. TCPoXML DTD + + <!-- + DTD for TCP over XML. + Refer to this DTD as: + + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + --> + + <!-- the pseudoheader is only included for checksum calculations --> + <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)> + + <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset, + reserved, control, window, checksum, urgent, + tcp.options, padding)> + + <!ELEMENT src EMPTY> + <!-- 0 <= port <= 65,535 --> + <!ATTLIST src + port %Digits; #REQUIRED> + + <!ELEMENT dest EMPTY> + <!-- 0 <= port <= 65,535 --> + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST dest + port %Digits; #REQUIRED> + + <!ELEMENT sequence EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST sequence + number %Digits; #REQUIRED> + + <!ELEMENT acknowledgement EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST acknowledgement + number %Digits; #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= number <= 255 --> + <!ATTLIST offset + number %Digits; #REQUIRED> + + <!ELEMENT reserved EMPTY> + <!ATTLIST reserved + value CDATA #FIXED "0"> + + <!ELEMENT control EMPTY> + <!ATTLIST control + urg (0|1) #IMPLIED + ack (0|1) #IMPLIED + psh (0|1) #IMPLIED + rst (0|1) #IMPLIED + syn (0|1) #IMPLIED + fin (0|1) #IMPLIED> + + <!ELEMENT window EMPTY> + <!-- 0 <= size <= 65,535 --> + <!ATTLIST window + size %Digits; #REQUIRED> + + <!-- + checksum as in ip, but with + the following pseudo-header added into the tcp element: + --> + <!ELEMENT tcp.pseudoheader (source, destination, protocol, + tcp.length)> + + <!-- + tcp header + data length in octets. does not include the size of + + the pseudoheader. + --> + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ELEMENT tcp.length EMPTY> + <!ATTLIST tcp.length + value %Digits; #REQUIRED> + + <!ELEMENT urgent EMPTY> + <!-- 0 <= pointer <= 65,535 --> + <!ATTLIST urgent + pointer %Digits; #REQUIRED> + + <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+> + + <!ELEMENT tcp.end EMPTY> + <!ATTLIST tcp.end + kind CDATA #FIXED "0"> + + <!ELEMENT tcp.noop EMPTY> + <!ATTLIST tcp.noop + kind CDATA #FIXED "1"> + + <!ELEMENT tcp.mss EMPTY> + <!ATTLIST tcp.mss + kind CDATA #FIXED "2" + length CDATA #FIXED "4" + size %Digits; #REQUIRED> + +7.3. UDPoXML DTD + + <!-- + DTD for UDP over XML. + Refer to this DTD as: + + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + --> + + <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)> + + <!ELEMENT udp.header (src, dest, udp.length, checksum)> + + <!ELEMENT udp.pseudoheader (source, destination, protocol, + udp.length)> + + <!-- + udp header + data length in octets. does not include the size of + the pseudoheader. + --> + <!ELEMENT udp.length EMPTY> + <!ATTLIST udp.length + value %Digits; #REQUIRED> + + + +Kennedy Informational [Page 13] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +8. Security Considerations + + XML, as a subset of SGML, has the same security considerations as + specified in SGML Media Types [RFC1874]. Security considerations + that apply to IP, TCP and UDP also likely apply to BLOAT as it does + not attempt to correct for issues not related to message format. + +9. References + + [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt, + February 2002. (Work in Progress) + + [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC894] Hornig, C., "Standard for the Transmission of IP + Datagrams over Ethernet Networks.", RFC 894, April 1984. + + [RFC1042] Postel, J. and J. Reynolds, "Standard for the + Transmission of IP Datagrams Over IEEE 802 Networks", STD + 43, RFC 1042, February 1988. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", RFC 1123, October 1989. + + [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December + 1995. + + [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, + October 1996. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + + + + +Kennedy Informational [Page 14] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", + RFC 3080, March 2001. + + [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., + Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D., + "Simple Object Access Protocol (SOAP) 1.1" World Wide Web + Consortium Note, May 2000 http://www.w3.org/TR/SOAP/ + + [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible + Markup Language (XML)" World Wide Web Consortium + Recommendation REC- xml-19980210. + http://www.w3.org/TR/1998/REC-xml-19980210 + +10. Author's Address + + Hugh Kennedy + Mimezine + 1060 West Addison + Chicago, IL 60613 + USA + + EMail: kennedyh@engin.umich.edu + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 15] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 16] + + + + + + + +Network Working Group H. Kennedy +Request for Comments: 3252 Mimezine +Category: Informational 1 April 2002 + + + Binary Lexical Octet Ad-hoc Transport + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document defines a reformulation of IP and two transport layer + protocols (TCP and UDP) as XML applications. + +1. Introduction + +1.1. Overview + + This document describes the Binary Lexical Octet Ad-hoc Transport + (BLOAT): a reformulation of a widely-deployed network-layer protocol + (IP [RFC791]), and two associated transport layer protocols (TCP + [RFC793] and UDP [RFC768]) as XML [XML] applications. It also + describes methods for transporting BLOAT over Ethernet and IEEE 802 + networks as well as encapsulating BLOAT in IP for gatewaying BLOAT + across the public Internet. + +1.2. Motivation + + The wild popularity of XML as a basis for application-level protocols + such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple + Object Access Protocol [SOAP], and Jabber [JABBER] prompted + investigation into the possibility of extending the use of XML in the + protocol stack. Using XML at both the transport and network layer in + addition to the application layer would provide for an amazing amount + of power and flexibility while removing dependencies on proprietary + and hard-to-understand binary protocols. This protocol unification + would also allow applications to use a single XML parser for all + aspects of their operation, eliminating developer time spent figuring + out the intricacies of each new protocol, and moving the hard work of + + + + +Kennedy Informational [Page 1] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + parsing to the XML toolset. The use of XML also mitigates concerns + over "network vs. host" byte ordering which is at the root of many + network application bugs. + +1.3. Relation to Existing Protocols + + The reformulations specified in this RFC follow as closely as + possible the spirit of the RFCs on which they are based, and so MAY + contain elements or attributes that would not be needed in a pure + reworking (e.g. length attributes, which are implicit in XML.) + + The layering of network and transport protocols are maintained in + this RFC despite the optimizations that could be made if the line + were somewhat blurred (i.e. merging TCP and IP into a single, larger + element in the DTD) in order to foster future use of this protocol as + a basis for reformulating other protocols (such as ICMP.) + + Other than the encoding, the behavioral aspects of each of the + existing protocols remain unchanged. Routing, address spaces, TCP + congestion control, etc. behave as specified in the extant standards. + Adapting to new standards and experimental algorithm heuristics for + improving performance will become much easier once the move to BLOAT + has been completed. + +1.4. Requirement Levels + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 + [RFC2119]. + +2. IPoXML + + This protocol MUST be implemented to be compliant with this RFC. + IPoXML is the root protocol REQUIRED for effective use of TCPoXML + (section 3.) and higher-level application protocols. + + The DTD for this document type can be found in section 7.1. + + The routing of IPoXML can be easily implemented on hosts with an XML + parser, as the regular structure lends itself handily to parsing and + validation of the document/datagram and then processing the + destination address, TTL, and checksum before sending it on to its + next-hop. + + The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the + wider deployment of IPv4 and the fact that implementing IPv6 as XML + would have exceeded the 1500 byte Ethernet MTU. + + + +Kennedy Informational [Page 2] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + All BLOAT implementations MUST use - and specify - the UTF-8 encoding + of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well- + formed and include the XMLDecl. + +2.1. IP Description + + A number of items have changed (for the better) from the original IP + specification. Bit-masks, where present have been converted into + human-readable values. IP addresses are listed in their dotted- + decimal notation [RFC1123]. Length and checksum values are present + as decimal integers. + + To calculate the length and checksum fields of the IP element, a + canonicalized form of the element MUST be used. The canonical form + SHALL have no whitespace (including newline characters) between + elements and only one space character between attributes. There + SHALL NOT be a space following the last attribute in an element. + + An iterative method SHOULD be used to calculate checksums, as the + length field will vary based on the size of the checksum. + + The payload element bears special attention. Due to the character + set restrictions of XML, the payload of IP datagrams (which MAY + contain arbitrary data) MUST be encoded for transport. This RFC + REQUIRES the contents of the payload to be encoded in the base-64 + encoding of RFC 2045 [RFC2045], but removes the requirement that the + encoded output MUST be wrapped on 76-character lines. + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 3] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +2.2. Example Datagram + + The following is an example IPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + <ip> + <header length="474"> + <version value="4"/> + <tos precedence="Routine" delay="Normal" throughput="Normal" + relibility="Normal" reserved="0"/> + <total.length value="461"/> + <id value="1"/> + <flags reserved="0" df="dont" mf="last"/> + <offset value="0"/> + <ttl value="255"/> + <protocol value="6"/> + <checksum value="8707"/> + <source address="10.0.0.22"/> + <destination address="10.0.0.1"/> + <options> + <end copied="0" class="0" number="0"/> + </options> + <padding pad="0"/> + </header> + <payload> + </payload> + </ip> + +3. TCPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.2. + +3.1. TCP Description + + A number of items have changed from the original TCP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + To calculate the length and checksum fields of the TCP element, a + canonicalized form of the element MUST be used as in section 2.1. + + An iterative method SHOULD be used to calculate checksums as in + section 2.1. + + The payload element MUST be encoded as in section 2.1. + + + +Kennedy Informational [Page 4] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + The TCP offset element was expanded to a maximum of 255 from 16 to + allow for the increased size of the header in XML. + + TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + <tcp> + <tcp.header> + <src port="31415"/> + <dest port="42424"/> + <sequence number="322622954"/> + <acknowledgement number="689715995"/> + <offset number=""/> + <reserved value="0"/> + <control syn="1" ack="1"/> + <window size="1"/> + <urgent pointer="0"/> + <checksum value="2988"/> + <tcp.options> + <tcp.end kind="0"/> + </tcp.options> + <padding pad="0"/> + </tcp.header> + <payload> + </payload> + </tcp> + +4. UDPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.3. + +4.1. UDP Description + + A number of items have changed from the original UDP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + + + + + + +Kennedy Informational [Page 5] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + To calculate the length and checksum fields of the UDP element, a + canonicalized form of the element MUST be used as in section 2.1. An + iterative method SHOULD be used to calculate checksums as in section + 2.1. + + The payload element MUST be encoded as in section 2.1. + + UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + <udp> + <udp.header> + <src port="31415"/> + <dest port="42424"/> + <udp.length value="143"/> + <checksum value="2988"/> + </udp.header> + <payload> + </payload> + </udp> + +5. Network Transport + + This document provides for the transmission of BLOAT datagrams over + two common families of physical layer transport. Future RFCs will + address additional transports as routing vendors catch up to the + specification, and we begin to see BLOAT routed across the Internet + backbone. + +5.1. Ethernet + + BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the + exception that the type field of the Ethernet frame MUST contain the + value 0xBEEF. The first 5 octets of the Ethernet frame payload will + be 0x3c 3f 78 6d 6c ("<?xml".) + +5.2. IEEE 802 + + BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except + that the protocol type code for IPoXML is 0xBEEF. + + + + + +Kennedy Informational [Page 6] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +6. Gatewaying over IP + + In order to facilitate the gradual introduction of BLOAT into the + public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to + gateway between networks that run BLOAT natively on their LANs. + +7. DTDs + + The Transport DTDs (7.2. and 7.3.) build on the definitions in the + Network DTD (7.1.) + + The DTDs are referenced by their PubidLiteral and SystemLiteral (from + [XML]) although it is understood that most IPoXML implementations + will not need to pull down the DTD, as it will normally be embedded + in the implementation, and presents something of a catch-22 if you + need to load part of your network protocol over the network. + +7.1. IPoXML DTD + + <!-- + DTD for IP over XML. + Refer to this DTD as: + + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + --> + <!-- + DTD data types: + + Digits [0..9]+ + + Precedence "NetworkControl | InternetworkControl | + CRITIC | FlashOverride | Flash | Immediate | + Priority | Routine" + + IP4Addr "dotted-decimal" notation of [RFC1123] + + Class [0..3] + + Sec "Unclassified | Confidential | EFTO | MMMM | PROG | + Restricted | Secret | Top Secret | Reserved" + + Compartments [0..65535] + + Handling [0..65535] + + TCC [0..16777216] + + --> + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ENTITY % Digits "CDATA"> + <!ENTITY % Precedence "CDATA"> + <!ENTITY % IP4Addr "CDATA"> + <!ENTITY % Class "CDATA"> + <!ENTITY % Sec "CDATA"> + <!ENTITY % Compartments "CDATA"> + <!ENTITY % Handling "CDATA"> + <!ENTITY % TCC "CDATA"> + + <!ELEMENT ip (header, payload)> + + <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl, + protocol, checksum, source, destination, options, + padding)> + <!-- length of header in 32-bit words --> + <!ATTLIST header + length %Digits; #REQUIRED> + + <!ELEMENT version EMPTY> + <!-- ip version. SHOULD be "4" --> + <!ATTLIST version + value %Digits; #REQUIRED> + + <!ELEMENT tos EMPTY> + <!ATTLIST tos + precedence %Precedence; #REQUIRED + delay (normal | low) #REQUIRED + throughput (normal | high) #REQUIRED + relibility (normal | high) #REQUIRED + reserved CDATA #FIXED "0"> + + <!ELEMENT total.length EMPTY> + <!-- + total length of datagram (header and payload) in octets, MUST be + less than 65,535 (and SHOULD be less than 1024 for IPoXML on local + ethernets). + --> + <!ATTLIST total.length + value %Digits; #REQUIRED> + + <!ELEMENT id EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST id + value %Digits; #REQUIRED> + + <!ELEMENT flags EMPTY> + <!-- df = don't fragment, mf = more fragments --> + <!ATTLIST flags + + + +Kennedy Informational [Page 8] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + reserved CDATA #FIXED "0" + df (may|dont) #REQUIRED + mf (last|more) #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks --> + <!ATTLIST offset + value %Digits; #REQUIRED> + + <!ELEMENT ttl EMPTY> + <!-- 0 <= ttl <= 255 --> + <!ATTLIST ttl + value %Digits; #REQUIRED> + + <!ELEMENT protocol EMPTY> + <!-- 0 <= protocol <= 255 (per IANA) --> + <!ATTLIST protocol + value %Digits; #REQUIRED> + + <!ELEMENT checksum EMPTY> + <!-- 0 <= checksum <= 65535 (over header only) --> + <!ATTLIST checksum + value %Digits; #REQUIRED> + + <!ELEMENT source EMPTY> + <!ATTLIST source + address %IP4Addr; #REQUIRED> + + <!ELEMENT destination EMPTY> + <!ATTLIST destination + address %IP4Addr; #REQUIRED> + + <!ELEMENT options ( end | noop | security | loose | strict | record + | stream | timestamp )*> + + <!ELEMENT end EMPTY> + <!ATTLIST end + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "0"> + + <!ELEMENT noop EMPTY> + <!ATTLIST noop + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "1"> + + <!ELEMENT security EMPTY> + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST security + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "2" + length CDATA #FIXED "11" + security %Sec; #REQUIRED + compartments %Compartments; #REQUIRED + handling %Handling; #REQUIRED + tcc %TCC; #REQUIRED> + <!ELEMENT loose (hop)+> + <!ATTLIST loose + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "3" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT hop EMPTY> + <!ATTLIST hop + address %IP4Addr; #REQUIRED> + + <!ELEMENT strict (hop)+> + <!ATTLIST strict + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "9" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT record (hop)+> + <!ATTLIST record + copied CDATA #FIXED "0" + class CDATA #FIXED "0" + number CDATA #FIXED "7" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT stream EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST stream + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "8" + length CDATA #FIXED "4" + id %Digits; #REQUIRED> + + <!ELEMENT timestamp (tstamp)+> + <!-- 0 <= oflw <=15 --> + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST timestamp + copied CDATA #FIXED "0" + class CDATA #FIXED "2" + number CDATA #FIXED "4" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED + oflw %Digits; #REQUIRED + flag (0 | 1 | 3) #REQUIRED> + + <!ELEMENT tstamp EMPTY> + <!ATTLIST tstamp + time %Digits; #REQUIRED + address %IP4Addr; #IMPLIED> + <!-- + padding to bring header to 32-bit boundary. + pad MUST be "0"* + --> + <!ELEMENT padding EMPTY> + <!ATTLIST padding + pad CDATA #REQUIRED> + + <!-- payload MUST be encoded as base-64 [RFC2045], as modified + by section 2.1 of this RFC --> + <!ELEMENT payload (CDATA)> + +7.2. TCPoXML DTD + + <!-- + DTD for TCP over XML. + Refer to this DTD as: + + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + --> + + <!-- the pseudoheader is only included for checksum calculations --> + <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)> + + <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset, + reserved, control, window, checksum, urgent, + tcp.options, padding)> + + <!ELEMENT src EMPTY> + <!-- 0 <= port <= 65,535 --> + <!ATTLIST src + port %Digits; #REQUIRED> + + <!ELEMENT dest EMPTY> + <!-- 0 <= port <= 65,535 --> + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST dest + port %Digits; #REQUIRED> + + <!ELEMENT sequence EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST sequence + number %Digits; #REQUIRED> + + <!ELEMENT acknowledgement EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST acknowledgement + number %Digits; #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= number <= 255 --> + <!ATTLIST offset + number %Digits; #REQUIRED> + + <!ELEMENT reserved EMPTY> + <!ATTLIST reserved + value CDATA #FIXED "0"> + + <!ELEMENT control EMPTY> + <!ATTLIST control + urg (0|1) #IMPLIED + ack (0|1) #IMPLIED + psh (0|1) #IMPLIED + rst (0|1) #IMPLIED + syn (0|1) #IMPLIED + fin (0|1) #IMPLIED> + + <!ELEMENT window EMPTY> + <!-- 0 <= size <= 65,535 --> + <!ATTLIST window + size %Digits; #REQUIRED> + + <!-- + checksum as in ip, but with + the following pseudo-header added into the tcp element: + --> + <!ELEMENT tcp.pseudoheader (source, destination, protocol, + tcp.length)> + + <!-- + tcp header + data length in octets. does not include the size of + + the pseudoheader. + --> + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ELEMENT tcp.length EMPTY> + <!ATTLIST tcp.length + value %Digits; #REQUIRED> + + <!ELEMENT urgent EMPTY> + <!-- 0 <= pointer <= 65,535 --> + <!ATTLIST urgent + pointer %Digits; #REQUIRED> + + <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+> + + <!ELEMENT tcp.end EMPTY> + <!ATTLIST tcp.end + kind CDATA #FIXED "0"> + + <!ELEMENT tcp.noop EMPTY> + <!ATTLIST tcp.noop + kind CDATA #FIXED "1"> + + <!ELEMENT tcp.mss EMPTY> + <!ATTLIST tcp.mss + kind CDATA #FIXED "2" + length CDATA #FIXED "4" + size %Digits; #REQUIRED> + +7.3. UDPoXML DTD + + <!-- + DTD for UDP over XML. + Refer to this DTD as: + + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + --> + + <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)> + + <!ELEMENT udp.header (src, dest, udp.length, checksum)> + + <!ELEMENT udp.pseudoheader (source, destination, protocol, + udp.length)> + + <!-- + udp header + data length in octets. does not include the size of + the pseudoheader. + --> + <!ELEMENT udp.length EMPTY> + <!ATTLIST udp.length + value %Digits; #REQUIRED> + + + +Kennedy Informational [Page 13] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +8. Security Considerations + + XML, as a subset of SGML, has the same security considerations as + specified in SGML Media Types [RFC1874]. Security considerations + that apply to IP, TCP and UDP also likely apply to BLOAT as it does + not attempt to correct for issues not related to message format. + +9. References + + [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt, + February 2002. (Work in Progress) + + [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC894] Hornig, C., "Standard for the Transmission of IP + Datagrams over Ethernet Networks.", RFC 894, April 1984. + + [RFC1042] Postel, J. and J. Reynolds, "Standard for the + Transmission of IP Datagrams Over IEEE 802 Networks", STD + 43, RFC 1042, February 1988. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", RFC 1123, October 1989. + + [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December + 1995. + + [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, + October 1996. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + + + + +Kennedy Informational [Page 14] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", + RFC 3080, March 2001. + + [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., + Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D., + "Simple Object Access Protocol (SOAP) 1.1" World Wide Web + Consortium Note, May 2000 http://www.w3.org/TR/SOAP/ + + [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible + Markup Language (XML)" World Wide Web Consortium + Recommendation REC- xml-19980210. + http://www.w3.org/TR/1998/REC-xml-19980210 + +10. Author's Address + + Hugh Kennedy + Mimezine + 1060 West Addison + Chicago, IL 60613 + USA + + EMail: kennedyh@engin.umich.edu + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 15] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 16] + + + + + + + +Network Working Group H. Kennedy +Request for Comments: 3252 Mimezine +Category: Informational 1 April 2002 + + + Binary Lexical Octet Ad-hoc Transport + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document defines a reformulation of IP and two transport layer + protocols (TCP and UDP) as XML applications. + +1. Introduction + +1.1. Overview + + This document describes the Binary Lexical Octet Ad-hoc Transport + (BLOAT): a reformulation of a widely-deployed network-layer protocol + (IP [RFC791]), and two associated transport layer protocols (TCP + [RFC793] and UDP [RFC768]) as XML [XML] applications. It also + describes methods for transporting BLOAT over Ethernet and IEEE 802 + networks as well as encapsulating BLOAT in IP for gatewaying BLOAT + across the public Internet. + +1.2. Motivation + + The wild popularity of XML as a basis for application-level protocols + such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple + Object Access Protocol [SOAP], and Jabber [JABBER] prompted + investigation into the possibility of extending the use of XML in the + protocol stack. Using XML at both the transport and network layer in + addition to the application layer would provide for an amazing amount + of power and flexibility while removing dependencies on proprietary + and hard-to-understand binary protocols. This protocol unification + would also allow applications to use a single XML parser for all + aspects of their operation, eliminating developer time spent figuring + out the intricacies of each new protocol, and moving the hard work of + + + + +Kennedy Informational [Page 1] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + parsing to the XML toolset. The use of XML also mitigates concerns + over "network vs. host" byte ordering which is at the root of many + network application bugs. + +1.3. Relation to Existing Protocols + + The reformulations specified in this RFC follow as closely as + possible the spirit of the RFCs on which they are based, and so MAY + contain elements or attributes that would not be needed in a pure + reworking (e.g. length attributes, which are implicit in XML.) + + The layering of network and transport protocols are maintained in + this RFC despite the optimizations that could be made if the line + were somewhat blurred (i.e. merging TCP and IP into a single, larger + element in the DTD) in order to foster future use of this protocol as + a basis for reformulating other protocols (such as ICMP.) + + Other than the encoding, the behavioral aspects of each of the + existing protocols remain unchanged. Routing, address spaces, TCP + congestion control, etc. behave as specified in the extant standards. + Adapting to new standards and experimental algorithm heuristics for + improving performance will become much easier once the move to BLOAT + has been completed. + +1.4. Requirement Levels + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 + [RFC2119]. + +2. IPoXML + + This protocol MUST be implemented to be compliant with this RFC. + IPoXML is the root protocol REQUIRED for effective use of TCPoXML + (section 3.) and higher-level application protocols. + + The DTD for this document type can be found in section 7.1. + + The routing of IPoXML can be easily implemented on hosts with an XML + parser, as the regular structure lends itself handily to parsing and + validation of the document/datagram and then processing the + destination address, TTL, and checksum before sending it on to its + next-hop. + + The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the + wider deployment of IPv4 and the fact that implementing IPv6 as XML + would have exceeded the 1500 byte Ethernet MTU. + + + +Kennedy Informational [Page 2] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + All BLOAT implementations MUST use - and specify - the UTF-8 encoding + of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well- + formed and include the XMLDecl. + +2.1. IP Description + + A number of items have changed (for the better) from the original IP + specification. Bit-masks, where present have been converted into + human-readable values. IP addresses are listed in their dotted- + decimal notation [RFC1123]. Length and checksum values are present + as decimal integers. + + To calculate the length and checksum fields of the IP element, a + canonicalized form of the element MUST be used. The canonical form + SHALL have no whitespace (including newline characters) between + elements and only one space character between attributes. There + SHALL NOT be a space following the last attribute in an element. + + An iterative method SHOULD be used to calculate checksums, as the + length field will vary based on the size of the checksum. + + The payload element bears special attention. Due to the character + set restrictions of XML, the payload of IP datagrams (which MAY + contain arbitrary data) MUST be encoded for transport. This RFC + REQUIRES the contents of the payload to be encoded in the base-64 + encoding of RFC 2045 [RFC2045], but removes the requirement that the + encoded output MUST be wrapped on 76-character lines. + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 3] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +2.2. Example Datagram + + The following is an example IPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + <ip> + <header length="474"> + <version value="4"/> + <tos precedence="Routine" delay="Normal" throughput="Normal" + relibility="Normal" reserved="0"/> + <total.length value="461"/> + <id value="1"/> + <flags reserved="0" df="dont" mf="last"/> + <offset value="0"/> + <ttl value="255"/> + <protocol value="6"/> + <checksum value="8707"/> + <source address="10.0.0.22"/> + <destination address="10.0.0.1"/> + <options> + <end copied="0" class="0" number="0"/> + </options> + <padding pad="0"/> + </header> + <payload> + </payload> + </ip> + +3. TCPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.2. + +3.1. TCP Description + + A number of items have changed from the original TCP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + To calculate the length and checksum fields of the TCP element, a + canonicalized form of the element MUST be used as in section 2.1. + + An iterative method SHOULD be used to calculate checksums as in + section 2.1. + + The payload element MUST be encoded as in section 2.1. + + + +Kennedy Informational [Page 4] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + The TCP offset element was expanded to a maximum of 255 from 16 to + allow for the increased size of the header in XML. + + TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + <tcp> + <tcp.header> + <src port="31415"/> + <dest port="42424"/> + <sequence number="322622954"/> + <acknowledgement number="689715995"/> + <offset number=""/> + <reserved value="0"/> + <control syn="1" ack="1"/> + <window size="1"/> + <urgent pointer="0"/> + <checksum value="2988"/> + <tcp.options> + <tcp.end kind="0"/> + </tcp.options> + <padding pad="0"/> + </tcp.header> + <payload> + </payload> + </tcp> + +4. UDPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.3. + +4.1. UDP Description + + A number of items have changed from the original UDP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + + + + + + +Kennedy Informational [Page 5] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + To calculate the length and checksum fields of the UDP element, a + canonicalized form of the element MUST be used as in section 2.1. An + iterative method SHOULD be used to calculate checksums as in section + 2.1. + + The payload element MUST be encoded as in section 2.1. + + UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + <udp> + <udp.header> + <src port="31415"/> + <dest port="42424"/> + <udp.length value="143"/> + <checksum value="2988"/> + </udp.header> + <payload> + </payload> + </udp> + +5. Network Transport + + This document provides for the transmission of BLOAT datagrams over + two common families of physical layer transport. Future RFCs will + address additional transports as routing vendors catch up to the + specification, and we begin to see BLOAT routed across the Internet + backbone. + +5.1. Ethernet + + BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the + exception that the type field of the Ethernet frame MUST contain the + value 0xBEEF. The first 5 octets of the Ethernet frame payload will + be 0x3c 3f 78 6d 6c ("<?xml".) + +5.2. IEEE 802 + + BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except + that the protocol type code for IPoXML is 0xBEEF. + + + + + +Kennedy Informational [Page 6] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +6. Gatewaying over IP + + In order to facilitate the gradual introduction of BLOAT into the + public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to + gateway between networks that run BLOAT natively on their LANs. + +7. DTDs + + The Transport DTDs (7.2. and 7.3.) build on the definitions in the + Network DTD (7.1.) + + The DTDs are referenced by their PubidLiteral and SystemLiteral (from + [XML]) although it is understood that most IPoXML implementations + will not need to pull down the DTD, as it will normally be embedded + in the implementation, and presents something of a catch-22 if you + need to load part of your network protocol over the network. + +7.1. IPoXML DTD + + <!-- + DTD for IP over XML. + Refer to this DTD as: + + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + --> + <!-- + DTD data types: + + Digits [0..9]+ + + Precedence "NetworkControl | InternetworkControl | + CRITIC | FlashOverride | Flash | Immediate | + Priority | Routine" + + IP4Addr "dotted-decimal" notation of [RFC1123] + + Class [0..3] + + Sec "Unclassified | Confidential | EFTO | MMMM | PROG | + Restricted | Secret | Top Secret | Reserved" + + Compartments [0..65535] + + Handling [0..65535] + + TCC [0..16777216] + + --> + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ENTITY % Digits "CDATA"> + <!ENTITY % Precedence "CDATA"> + <!ENTITY % IP4Addr "CDATA"> + <!ENTITY % Class "CDATA"> + <!ENTITY % Sec "CDATA"> + <!ENTITY % Compartments "CDATA"> + <!ENTITY % Handling "CDATA"> + <!ENTITY % TCC "CDATA"> + + <!ELEMENT ip (header, payload)> + + <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl, + protocol, checksum, source, destination, options, + padding)> + <!-- length of header in 32-bit words --> + <!ATTLIST header + length %Digits; #REQUIRED> + + <!ELEMENT version EMPTY> + <!-- ip version. SHOULD be "4" --> + <!ATTLIST version + value %Digits; #REQUIRED> + + <!ELEMENT tos EMPTY> + <!ATTLIST tos + precedence %Precedence; #REQUIRED + delay (normal | low) #REQUIRED + throughput (normal | high) #REQUIRED + relibility (normal | high) #REQUIRED + reserved CDATA #FIXED "0"> + + <!ELEMENT total.length EMPTY> + <!-- + total length of datagram (header and payload) in octets, MUST be + less than 65,535 (and SHOULD be less than 1024 for IPoXML on local + ethernets). + --> + <!ATTLIST total.length + value %Digits; #REQUIRED> + + <!ELEMENT id EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST id + value %Digits; #REQUIRED> + + <!ELEMENT flags EMPTY> + <!-- df = don't fragment, mf = more fragments --> + <!ATTLIST flags + + + +Kennedy Informational [Page 8] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + reserved CDATA #FIXED "0" + df (may|dont) #REQUIRED + mf (last|more) #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks --> + <!ATTLIST offset + value %Digits; #REQUIRED> + + <!ELEMENT ttl EMPTY> + <!-- 0 <= ttl <= 255 --> + <!ATTLIST ttl + value %Digits; #REQUIRED> + + <!ELEMENT protocol EMPTY> + <!-- 0 <= protocol <= 255 (per IANA) --> + <!ATTLIST protocol + value %Digits; #REQUIRED> + + <!ELEMENT checksum EMPTY> + <!-- 0 <= checksum <= 65535 (over header only) --> + <!ATTLIST checksum + value %Digits; #REQUIRED> + + <!ELEMENT source EMPTY> + <!ATTLIST source + address %IP4Addr; #REQUIRED> + + <!ELEMENT destination EMPTY> + <!ATTLIST destination + address %IP4Addr; #REQUIRED> + + <!ELEMENT options ( end | noop | security | loose | strict | record + | stream | timestamp )*> + + <!ELEMENT end EMPTY> + <!ATTLIST end + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "0"> + + <!ELEMENT noop EMPTY> + <!ATTLIST noop + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "1"> + + <!ELEMENT security EMPTY> + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST security + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "2" + length CDATA #FIXED "11" + security %Sec; #REQUIRED + compartments %Compartments; #REQUIRED + handling %Handling; #REQUIRED + tcc %TCC; #REQUIRED> + <!ELEMENT loose (hop)+> + <!ATTLIST loose + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "3" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT hop EMPTY> + <!ATTLIST hop + address %IP4Addr; #REQUIRED> + + <!ELEMENT strict (hop)+> + <!ATTLIST strict + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "9" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT record (hop)+> + <!ATTLIST record + copied CDATA #FIXED "0" + class CDATA #FIXED "0" + number CDATA #FIXED "7" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT stream EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST stream + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "8" + length CDATA #FIXED "4" + id %Digits; #REQUIRED> + + <!ELEMENT timestamp (tstamp)+> + <!-- 0 <= oflw <=15 --> + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST timestamp + copied CDATA #FIXED "0" + class CDATA #FIXED "2" + number CDATA #FIXED "4" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED + oflw %Digits; #REQUIRED + flag (0 | 1 | 3) #REQUIRED> + + <!ELEMENT tstamp EMPTY> + <!ATTLIST tstamp + time %Digits; #REQUIRED + address %IP4Addr; #IMPLIED> + <!-- + padding to bring header to 32-bit boundary. + pad MUST be "0"* + --> + <!ELEMENT padding EMPTY> + <!ATTLIST padding + pad CDATA #REQUIRED> + + <!-- payload MUST be encoded as base-64 [RFC2045], as modified + by section 2.1 of this RFC --> + <!ELEMENT payload (CDATA)> + +7.2. TCPoXML DTD + + <!-- + DTD for TCP over XML. + Refer to this DTD as: + + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + --> + + <!-- the pseudoheader is only included for checksum calculations --> + <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)> + + <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset, + reserved, control, window, checksum, urgent, + tcp.options, padding)> + + <!ELEMENT src EMPTY> + <!-- 0 <= port <= 65,535 --> + <!ATTLIST src + port %Digits; #REQUIRED> + + <!ELEMENT dest EMPTY> + <!-- 0 <= port <= 65,535 --> + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST dest + port %Digits; #REQUIRED> + + <!ELEMENT sequence EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST sequence + number %Digits; #REQUIRED> + + <!ELEMENT acknowledgement EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST acknowledgement + number %Digits; #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= number <= 255 --> + <!ATTLIST offset + number %Digits; #REQUIRED> + + <!ELEMENT reserved EMPTY> + <!ATTLIST reserved + value CDATA #FIXED "0"> + + <!ELEMENT control EMPTY> + <!ATTLIST control + urg (0|1) #IMPLIED + ack (0|1) #IMPLIED + psh (0|1) #IMPLIED + rst (0|1) #IMPLIED + syn (0|1) #IMPLIED + fin (0|1) #IMPLIED> + + <!ELEMENT window EMPTY> + <!-- 0 <= size <= 65,535 --> + <!ATTLIST window + size %Digits; #REQUIRED> + + <!-- + checksum as in ip, but with + the following pseudo-header added into the tcp element: + --> + <!ELEMENT tcp.pseudoheader (source, destination, protocol, + tcp.length)> + + <!-- + tcp header + data length in octets. does not include the size of + + the pseudoheader. + --> + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ELEMENT tcp.length EMPTY> + <!ATTLIST tcp.length + value %Digits; #REQUIRED> + + <!ELEMENT urgent EMPTY> + <!-- 0 <= pointer <= 65,535 --> + <!ATTLIST urgent + pointer %Digits; #REQUIRED> + + <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+> + + <!ELEMENT tcp.end EMPTY> + <!ATTLIST tcp.end + kind CDATA #FIXED "0"> + + <!ELEMENT tcp.noop EMPTY> + <!ATTLIST tcp.noop + kind CDATA #FIXED "1"> + + <!ELEMENT tcp.mss EMPTY> + <!ATTLIST tcp.mss + kind CDATA #FIXED "2" + length CDATA #FIXED "4" + size %Digits; #REQUIRED> + +7.3. UDPoXML DTD + + <!-- + DTD for UDP over XML. + Refer to this DTD as: + + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + --> + + <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)> + + <!ELEMENT udp.header (src, dest, udp.length, checksum)> + + <!ELEMENT udp.pseudoheader (source, destination, protocol, + udp.length)> + + <!-- + udp header + data length in octets. does not include the size of + the pseudoheader. + --> + <!ELEMENT udp.length EMPTY> + <!ATTLIST udp.length + value %Digits; #REQUIRED> + + + +Kennedy Informational [Page 13] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +8. Security Considerations + + XML, as a subset of SGML, has the same security considerations as + specified in SGML Media Types [RFC1874]. Security considerations + that apply to IP, TCP and UDP also likely apply to BLOAT as it does + not attempt to correct for issues not related to message format. + +9. References + + [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt, + February 2002. (Work in Progress) + + [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC894] Hornig, C., "Standard for the Transmission of IP + Datagrams over Ethernet Networks.", RFC 894, April 1984. + + [RFC1042] Postel, J. and J. Reynolds, "Standard for the + Transmission of IP Datagrams Over IEEE 802 Networks", STD + 43, RFC 1042, February 1988. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", RFC 1123, October 1989. + + [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December + 1995. + + [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, + October 1996. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + + + + +Kennedy Informational [Page 14] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", + RFC 3080, March 2001. + + [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., + Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D., + "Simple Object Access Protocol (SOAP) 1.1" World Wide Web + Consortium Note, May 2000 http://www.w3.org/TR/SOAP/ + + [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible + Markup Language (XML)" World Wide Web Consortium + Recommendation REC- xml-19980210. + http://www.w3.org/TR/1998/REC-xml-19980210 + +10. Author's Address + + Hugh Kennedy + Mimezine + 1060 West Addison + Chicago, IL 60613 + USA + + EMail: kennedyh@engin.umich.edu + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 15] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 16] + + + + + + + +Network Working Group H. Kennedy +Request for Comments: 3252 Mimezine +Category: Informational 1 April 2002 + + + Binary Lexical Octet Ad-hoc Transport + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document defines a reformulation of IP and two transport layer + protocols (TCP and UDP) as XML applications. + +1. Introduction + +1.1. Overview + + This document describes the Binary Lexical Octet Ad-hoc Transport + (BLOAT): a reformulation of a widely-deployed network-layer protocol + (IP [RFC791]), and two associated transport layer protocols (TCP + [RFC793] and UDP [RFC768]) as XML [XML] applications. It also + describes methods for transporting BLOAT over Ethernet and IEEE 802 + networks as well as encapsulating BLOAT in IP for gatewaying BLOAT + across the public Internet. + +1.2. Motivation + + The wild popularity of XML as a basis for application-level protocols + such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple + Object Access Protocol [SOAP], and Jabber [JABBER] prompted + investigation into the possibility of extending the use of XML in the + protocol stack. Using XML at both the transport and network layer in + addition to the application layer would provide for an amazing amount + of power and flexibility while removing dependencies on proprietary + and hard-to-understand binary protocols. This protocol unification + would also allow applications to use a single XML parser for all + aspects of their operation, eliminating developer time spent figuring + out the intricacies of each new protocol, and moving the hard work of + + + + +Kennedy Informational [Page 1] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + parsing to the XML toolset. The use of XML also mitigates concerns + over "network vs. host" byte ordering which is at the root of many + network application bugs. + +1.3. Relation to Existing Protocols + + The reformulations specified in this RFC follow as closely as + possible the spirit of the RFCs on which they are based, and so MAY + contain elements or attributes that would not be needed in a pure + reworking (e.g. length attributes, which are implicit in XML.) + + The layering of network and transport protocols are maintained in + this RFC despite the optimizations that could be made if the line + were somewhat blurred (i.e. merging TCP and IP into a single, larger + element in the DTD) in order to foster future use of this protocol as + a basis for reformulating other protocols (such as ICMP.) + + Other than the encoding, the behavioral aspects of each of the + existing protocols remain unchanged. Routing, address spaces, TCP + congestion control, etc. behave as specified in the extant standards. + Adapting to new standards and experimental algorithm heuristics for + improving performance will become much easier once the move to BLOAT + has been completed. + +1.4. Requirement Levels + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 + [RFC2119]. + +2. IPoXML + + This protocol MUST be implemented to be compliant with this RFC. + IPoXML is the root protocol REQUIRED for effective use of TCPoXML + (section 3.) and higher-level application protocols. + + The DTD for this document type can be found in section 7.1. + + The routing of IPoXML can be easily implemented on hosts with an XML + parser, as the regular structure lends itself handily to parsing and + validation of the document/datagram and then processing the + destination address, TTL, and checksum before sending it on to its + next-hop. + + The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the + wider deployment of IPv4 and the fact that implementing IPv6 as XML + would have exceeded the 1500 byte Ethernet MTU. + + + +Kennedy Informational [Page 2] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + All BLOAT implementations MUST use - and specify - the UTF-8 encoding + of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well- + formed and include the XMLDecl. + +2.1. IP Description + + A number of items have changed (for the better) from the original IP + specification. Bit-masks, where present have been converted into + human-readable values. IP addresses are listed in their dotted- + decimal notation [RFC1123]. Length and checksum values are present + as decimal integers. + + To calculate the length and checksum fields of the IP element, a + canonicalized form of the element MUST be used. The canonical form + SHALL have no whitespace (including newline characters) between + elements and only one space character between attributes. There + SHALL NOT be a space following the last attribute in an element. + + An iterative method SHOULD be used to calculate checksums, as the + length field will vary based on the size of the checksum. + + The payload element bears special attention. Due to the character + set restrictions of XML, the payload of IP datagrams (which MAY + contain arbitrary data) MUST be encoded for transport. This RFC + REQUIRES the contents of the payload to be encoded in the base-64 + encoding of RFC 2045 [RFC2045], but removes the requirement that the + encoded output MUST be wrapped on 76-character lines. + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 3] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +2.2. Example Datagram + + The following is an example IPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + <ip> + <header length="474"> + <version value="4"/> + <tos precedence="Routine" delay="Normal" throughput="Normal" + relibility="Normal" reserved="0"/> + <total.length value="461"/> + <id value="1"/> + <flags reserved="0" df="dont" mf="last"/> + <offset value="0"/> + <ttl value="255"/> + <protocol value="6"/> + <checksum value="8707"/> + <source address="10.0.0.22"/> + <destination address="10.0.0.1"/> + <options> + <end copied="0" class="0" number="0"/> + </options> + <padding pad="0"/> + </header> + <payload> + </payload> + </ip> + +3. TCPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.2. + +3.1. TCP Description + + A number of items have changed from the original TCP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + To calculate the length and checksum fields of the TCP element, a + canonicalized form of the element MUST be used as in section 2.1. + + An iterative method SHOULD be used to calculate checksums as in + section 2.1. + + The payload element MUST be encoded as in section 2.1. + + + +Kennedy Informational [Page 4] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + The TCP offset element was expanded to a maximum of 255 from 16 to + allow for the increased size of the header in XML. + + TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + <tcp> + <tcp.header> + <src port="31415"/> + <dest port="42424"/> + <sequence number="322622954"/> + <acknowledgement number="689715995"/> + <offset number=""/> + <reserved value="0"/> + <control syn="1" ack="1"/> + <window size="1"/> + <urgent pointer="0"/> + <checksum value="2988"/> + <tcp.options> + <tcp.end kind="0"/> + </tcp.options> + <padding pad="0"/> + </tcp.header> + <payload> + </payload> + </tcp> + +4. UDPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.3. + +4.1. UDP Description + + A number of items have changed from the original UDP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + + + + + + +Kennedy Informational [Page 5] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + To calculate the length and checksum fields of the UDP element, a + canonicalized form of the element MUST be used as in section 2.1. An + iterative method SHOULD be used to calculate checksums as in section + 2.1. + + The payload element MUST be encoded as in section 2.1. + + UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + <udp> + <udp.header> + <src port="31415"/> + <dest port="42424"/> + <udp.length value="143"/> + <checksum value="2988"/> + </udp.header> + <payload> + </payload> + </udp> + +5. Network Transport + + This document provides for the transmission of BLOAT datagrams over + two common families of physical layer transport. Future RFCs will + address additional transports as routing vendors catch up to the + specification, and we begin to see BLOAT routed across the Internet + backbone. + +5.1. Ethernet + + BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the + exception that the type field of the Ethernet frame MUST contain the + value 0xBEEF. The first 5 octets of the Ethernet frame payload will + be 0x3c 3f 78 6d 6c ("<?xml".) + +5.2. IEEE 802 + + BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except + that the protocol type code for IPoXML is 0xBEEF. + + + + + +Kennedy Informational [Page 6] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +6. Gatewaying over IP + + In order to facilitate the gradual introduction of BLOAT into the + public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to + gateway between networks that run BLOAT natively on their LANs. + +7. DTDs + + The Transport DTDs (7.2. and 7.3.) build on the definitions in the + Network DTD (7.1.) + + The DTDs are referenced by their PubidLiteral and SystemLiteral (from + [XML]) although it is understood that most IPoXML implementations + will not need to pull down the DTD, as it will normally be embedded + in the implementation, and presents something of a catch-22 if you + need to load part of your network protocol over the network. + +7.1. IPoXML DTD + + <!-- + DTD for IP over XML. + Refer to this DTD as: + + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + --> + <!-- + DTD data types: + + Digits [0..9]+ + + Precedence "NetworkControl | InternetworkControl | + CRITIC | FlashOverride | Flash | Immediate | + Priority | Routine" + + IP4Addr "dotted-decimal" notation of [RFC1123] + + Class [0..3] + + Sec "Unclassified | Confidential | EFTO | MMMM | PROG | + Restricted | Secret | Top Secret | Reserved" + + Compartments [0..65535] + + Handling [0..65535] + + TCC [0..16777216] + + --> + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ENTITY % Digits "CDATA"> + <!ENTITY % Precedence "CDATA"> + <!ENTITY % IP4Addr "CDATA"> + <!ENTITY % Class "CDATA"> + <!ENTITY % Sec "CDATA"> + <!ENTITY % Compartments "CDATA"> + <!ENTITY % Handling "CDATA"> + <!ENTITY % TCC "CDATA"> + + <!ELEMENT ip (header, payload)> + + <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl, + protocol, checksum, source, destination, options, + padding)> + <!-- length of header in 32-bit words --> + <!ATTLIST header + length %Digits; #REQUIRED> + + <!ELEMENT version EMPTY> + <!-- ip version. SHOULD be "4" --> + <!ATTLIST version + value %Digits; #REQUIRED> + + <!ELEMENT tos EMPTY> + <!ATTLIST tos + precedence %Precedence; #REQUIRED + delay (normal | low) #REQUIRED + throughput (normal | high) #REQUIRED + relibility (normal | high) #REQUIRED + reserved CDATA #FIXED "0"> + + <!ELEMENT total.length EMPTY> + <!-- + total length of datagram (header and payload) in octets, MUST be + less than 65,535 (and SHOULD be less than 1024 for IPoXML on local + ethernets). + --> + <!ATTLIST total.length + value %Digits; #REQUIRED> + + <!ELEMENT id EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST id + value %Digits; #REQUIRED> + + <!ELEMENT flags EMPTY> + <!-- df = don't fragment, mf = more fragments --> + <!ATTLIST flags + + + +Kennedy Informational [Page 8] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + reserved CDATA #FIXED "0" + df (may|dont) #REQUIRED + mf (last|more) #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks --> + <!ATTLIST offset + value %Digits; #REQUIRED> + + <!ELEMENT ttl EMPTY> + <!-- 0 <= ttl <= 255 --> + <!ATTLIST ttl + value %Digits; #REQUIRED> + + <!ELEMENT protocol EMPTY> + <!-- 0 <= protocol <= 255 (per IANA) --> + <!ATTLIST protocol + value %Digits; #REQUIRED> + + <!ELEMENT checksum EMPTY> + <!-- 0 <= checksum <= 65535 (over header only) --> + <!ATTLIST checksum + value %Digits; #REQUIRED> + + <!ELEMENT source EMPTY> + <!ATTLIST source + address %IP4Addr; #REQUIRED> + + <!ELEMENT destination EMPTY> + <!ATTLIST destination + address %IP4Addr; #REQUIRED> + + <!ELEMENT options ( end | noop | security | loose | strict | record + | stream | timestamp )*> + + <!ELEMENT end EMPTY> + <!ATTLIST end + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "0"> + + <!ELEMENT noop EMPTY> + <!ATTLIST noop + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "1"> + + <!ELEMENT security EMPTY> + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST security + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "2" + length CDATA #FIXED "11" + security %Sec; #REQUIRED + compartments %Compartments; #REQUIRED + handling %Handling; #REQUIRED + tcc %TCC; #REQUIRED> + <!ELEMENT loose (hop)+> + <!ATTLIST loose + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "3" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT hop EMPTY> + <!ATTLIST hop + address %IP4Addr; #REQUIRED> + + <!ELEMENT strict (hop)+> + <!ATTLIST strict + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "9" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT record (hop)+> + <!ATTLIST record + copied CDATA #FIXED "0" + class CDATA #FIXED "0" + number CDATA #FIXED "7" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT stream EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST stream + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "8" + length CDATA #FIXED "4" + id %Digits; #REQUIRED> + + <!ELEMENT timestamp (tstamp)+> + <!-- 0 <= oflw <=15 --> + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST timestamp + copied CDATA #FIXED "0" + class CDATA #FIXED "2" + number CDATA #FIXED "4" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED + oflw %Digits; #REQUIRED + flag (0 | 1 | 3) #REQUIRED> + + <!ELEMENT tstamp EMPTY> + <!ATTLIST tstamp + time %Digits; #REQUIRED + address %IP4Addr; #IMPLIED> + <!-- + padding to bring header to 32-bit boundary. + pad MUST be "0"* + --> + <!ELEMENT padding EMPTY> + <!ATTLIST padding + pad CDATA #REQUIRED> + + <!-- payload MUST be encoded as base-64 [RFC2045], as modified + by section 2.1 of this RFC --> + <!ELEMENT payload (CDATA)> + +7.2. TCPoXML DTD + + <!-- + DTD for TCP over XML. + Refer to this DTD as: + + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + --> + + <!-- the pseudoheader is only included for checksum calculations --> + <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)> + + <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset, + reserved, control, window, checksum, urgent, + tcp.options, padding)> + + <!ELEMENT src EMPTY> + <!-- 0 <= port <= 65,535 --> + <!ATTLIST src + port %Digits; #REQUIRED> + + <!ELEMENT dest EMPTY> + <!-- 0 <= port <= 65,535 --> + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST dest + port %Digits; #REQUIRED> + + <!ELEMENT sequence EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST sequence + number %Digits; #REQUIRED> + + <!ELEMENT acknowledgement EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST acknowledgement + number %Digits; #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= number <= 255 --> + <!ATTLIST offset + number %Digits; #REQUIRED> + + <!ELEMENT reserved EMPTY> + <!ATTLIST reserved + value CDATA #FIXED "0"> + + <!ELEMENT control EMPTY> + <!ATTLIST control + urg (0|1) #IMPLIED + ack (0|1) #IMPLIED + psh (0|1) #IMPLIED + rst (0|1) #IMPLIED + syn (0|1) #IMPLIED + fin (0|1) #IMPLIED> + + <!ELEMENT window EMPTY> + <!-- 0 <= size <= 65,535 --> + <!ATTLIST window + size %Digits; #REQUIRED> + + <!-- + checksum as in ip, but with + the following pseudo-header added into the tcp element: + --> + <!ELEMENT tcp.pseudoheader (source, destination, protocol, + tcp.length)> + + <!-- + tcp header + data length in octets. does not include the size of + + the pseudoheader. + --> + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ELEMENT tcp.length EMPTY> + <!ATTLIST tcp.length + value %Digits; #REQUIRED> + + <!ELEMENT urgent EMPTY> + <!-- 0 <= pointer <= 65,535 --> + <!ATTLIST urgent + pointer %Digits; #REQUIRED> + + <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+> + + <!ELEMENT tcp.end EMPTY> + <!ATTLIST tcp.end + kind CDATA #FIXED "0"> + + <!ELEMENT tcp.noop EMPTY> + <!ATTLIST tcp.noop + kind CDATA #FIXED "1"> + + <!ELEMENT tcp.mss EMPTY> + <!ATTLIST tcp.mss + kind CDATA #FIXED "2" + length CDATA #FIXED "4" + size %Digits; #REQUIRED> + +7.3. UDPoXML DTD + + <!-- + DTD for UDP over XML. + Refer to this DTD as: + + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + --> + + <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)> + + <!ELEMENT udp.header (src, dest, udp.length, checksum)> + + <!ELEMENT udp.pseudoheader (source, destination, protocol, + udp.length)> + + <!-- + udp header + data length in octets. does not include the size of + the pseudoheader. + --> + <!ELEMENT udp.length EMPTY> + <!ATTLIST udp.length + value %Digits; #REQUIRED> + + + +Kennedy Informational [Page 13] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +8. Security Considerations + + XML, as a subset of SGML, has the same security considerations as + specified in SGML Media Types [RFC1874]. Security considerations + that apply to IP, TCP and UDP also likely apply to BLOAT as it does + not attempt to correct for issues not related to message format. + +9. References + + [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt, + February 2002. (Work in Progress) + + [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC894] Hornig, C., "Standard for the Transmission of IP + Datagrams over Ethernet Networks.", RFC 894, April 1984. + + [RFC1042] Postel, J. and J. Reynolds, "Standard for the + Transmission of IP Datagrams Over IEEE 802 Networks", STD + 43, RFC 1042, February 1988. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", RFC 1123, October 1989. + + [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December + 1995. + + [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, + October 1996. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + + + + +Kennedy Informational [Page 14] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", + RFC 3080, March 2001. + + [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., + Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D., + "Simple Object Access Protocol (SOAP) 1.1" World Wide Web + Consortium Note, May 2000 http://www.w3.org/TR/SOAP/ + + [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible + Markup Language (XML)" World Wide Web Consortium + Recommendation REC- xml-19980210. + http://www.w3.org/TR/1998/REC-xml-19980210 + +10. Author's Address + + Hugh Kennedy + Mimezine + 1060 West Addison + Chicago, IL 60613 + USA + + EMail: kennedyh@engin.umich.edu + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 15] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 16] + + + + + + + +Network Working Group H. Kennedy +Request for Comments: 3252 Mimezine +Category: Informational 1 April 2002 + + + Binary Lexical Octet Ad-hoc Transport + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document defines a reformulation of IP and two transport layer + protocols (TCP and UDP) as XML applications. + +1. Introduction + +1.1. Overview + + This document describes the Binary Lexical Octet Ad-hoc Transport + (BLOAT): a reformulation of a widely-deployed network-layer protocol + (IP [RFC791]), and two associated transport layer protocols (TCP + [RFC793] and UDP [RFC768]) as XML [XML] applications. It also + describes methods for transporting BLOAT over Ethernet and IEEE 802 + networks as well as encapsulating BLOAT in IP for gatewaying BLOAT + across the public Internet. + +1.2. Motivation + + The wild popularity of XML as a basis for application-level protocols + such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple + Object Access Protocol [SOAP], and Jabber [JABBER] prompted + investigation into the possibility of extending the use of XML in the + protocol stack. Using XML at both the transport and network layer in + addition to the application layer would provide for an amazing amount + of power and flexibility while removing dependencies on proprietary + and hard-to-understand binary protocols. This protocol unification + would also allow applications to use a single XML parser for all + aspects of their operation, eliminating developer time spent figuring + out the intricacies of each new protocol, and moving the hard work of + + + + +Kennedy Informational [Page 1] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + parsing to the XML toolset. The use of XML also mitigates concerns + over "network vs. host" byte ordering which is at the root of many + network application bugs. + +1.3. Relation to Existing Protocols + + The reformulations specified in this RFC follow as closely as + possible the spirit of the RFCs on which they are based, and so MAY + contain elements or attributes that would not be needed in a pure + reworking (e.g. length attributes, which are implicit in XML.) + + The layering of network and transport protocols are maintained in + this RFC despite the optimizations that could be made if the line + were somewhat blurred (i.e. merging TCP and IP into a single, larger + element in the DTD) in order to foster future use of this protocol as + a basis for reformulating other protocols (such as ICMP.) + + Other than the encoding, the behavioral aspects of each of the + existing protocols remain unchanged. Routing, address spaces, TCP + congestion control, etc. behave as specified in the extant standards. + Adapting to new standards and experimental algorithm heuristics for + improving performance will become much easier once the move to BLOAT + has been completed. + +1.4. Requirement Levels + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 + [RFC2119]. + +2. IPoXML + + This protocol MUST be implemented to be compliant with this RFC. + IPoXML is the root protocol REQUIRED for effective use of TCPoXML + (section 3.) and higher-level application protocols. + + The DTD for this document type can be found in section 7.1. + + The routing of IPoXML can be easily implemented on hosts with an XML + parser, as the regular structure lends itself handily to parsing and + validation of the document/datagram and then processing the + destination address, TTL, and checksum before sending it on to its + next-hop. + + The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the + wider deployment of IPv4 and the fact that implementing IPv6 as XML + would have exceeded the 1500 byte Ethernet MTU. + + + +Kennedy Informational [Page 2] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + All BLOAT implementations MUST use - and specify - the UTF-8 encoding + of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well- + formed and include the XMLDecl. + +2.1. IP Description + + A number of items have changed (for the better) from the original IP + specification. Bit-masks, where present have been converted into + human-readable values. IP addresses are listed in their dotted- + decimal notation [RFC1123]. Length and checksum values are present + as decimal integers. + + To calculate the length and checksum fields of the IP element, a + canonicalized form of the element MUST be used. The canonical form + SHALL have no whitespace (including newline characters) between + elements and only one space character between attributes. There + SHALL NOT be a space following the last attribute in an element. + + An iterative method SHOULD be used to calculate checksums, as the + length field will vary based on the size of the checksum. + + The payload element bears special attention. Due to the character + set restrictions of XML, the payload of IP datagrams (which MAY + contain arbitrary data) MUST be encoded for transport. This RFC + REQUIRES the contents of the payload to be encoded in the base-64 + encoding of RFC 2045 [RFC2045], but removes the requirement that the + encoded output MUST be wrapped on 76-character lines. + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 3] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +2.2. Example Datagram + + The following is an example IPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + <ip> + <header length="474"> + <version value="4"/> + <tos precedence="Routine" delay="Normal" throughput="Normal" + relibility="Normal" reserved="0"/> + <total.length value="461"/> + <id value="1"/> + <flags reserved="0" df="dont" mf="last"/> + <offset value="0"/> + <ttl value="255"/> + <protocol value="6"/> + <checksum value="8707"/> + <source address="10.0.0.22"/> + <destination address="10.0.0.1"/> + <options> + <end copied="0" class="0" number="0"/> + </options> + <padding pad="0"/> + </header> + <payload> + </payload> + </ip> + +3. TCPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.2. + +3.1. TCP Description + + A number of items have changed from the original TCP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + To calculate the length and checksum fields of the TCP element, a + canonicalized form of the element MUST be used as in section 2.1. + + An iterative method SHOULD be used to calculate checksums as in + section 2.1. + + The payload element MUST be encoded as in section 2.1. + + + +Kennedy Informational [Page 4] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + The TCP offset element was expanded to a maximum of 255 from 16 to + allow for the increased size of the header in XML. + + TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + <tcp> + <tcp.header> + <src port="31415"/> + <dest port="42424"/> + <sequence number="322622954"/> + <acknowledgement number="689715995"/> + <offset number=""/> + <reserved value="0"/> + <control syn="1" ack="1"/> + <window size="1"/> + <urgent pointer="0"/> + <checksum value="2988"/> + <tcp.options> + <tcp.end kind="0"/> + </tcp.options> + <padding pad="0"/> + </tcp.header> + <payload> + </payload> + </tcp> + +4. UDPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.3. + +4.1. UDP Description + + A number of items have changed from the original UDP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + + + + + + +Kennedy Informational [Page 5] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + To calculate the length and checksum fields of the UDP element, a + canonicalized form of the element MUST be used as in section 2.1. An + iterative method SHOULD be used to calculate checksums as in section + 2.1. + + The payload element MUST be encoded as in section 2.1. + + UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + <udp> + <udp.header> + <src port="31415"/> + <dest port="42424"/> + <udp.length value="143"/> + <checksum value="2988"/> + </udp.header> + <payload> + </payload> + </udp> + +5. Network Transport + + This document provides for the transmission of BLOAT datagrams over + two common families of physical layer transport. Future RFCs will + address additional transports as routing vendors catch up to the + specification, and we begin to see BLOAT routed across the Internet + backbone. + +5.1. Ethernet + + BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the + exception that the type field of the Ethernet frame MUST contain the + value 0xBEEF. The first 5 octets of the Ethernet frame payload will + be 0x3c 3f 78 6d 6c ("<?xml".) + +5.2. IEEE 802 + + BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except + that the protocol type code for IPoXML is 0xBEEF. + + + + + +Kennedy Informational [Page 6] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +6. Gatewaying over IP + + In order to facilitate the gradual introduction of BLOAT into the + public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to + gateway between networks that run BLOAT natively on their LANs. + +7. DTDs + + The Transport DTDs (7.2. and 7.3.) build on the definitions in the + Network DTD (7.1.) + + The DTDs are referenced by their PubidLiteral and SystemLiteral (from + [XML]) although it is understood that most IPoXML implementations + will not need to pull down the DTD, as it will normally be embedded + in the implementation, and presents something of a catch-22 if you + need to load part of your network protocol over the network. + +7.1. IPoXML DTD + + <!-- + DTD for IP over XML. + Refer to this DTD as: + + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + --> + <!-- + DTD data types: + + Digits [0..9]+ + + Precedence "NetworkControl | InternetworkControl | + CRITIC | FlashOverride | Flash | Immediate | + Priority | Routine" + + IP4Addr "dotted-decimal" notation of [RFC1123] + + Class [0..3] + + Sec "Unclassified | Confidential | EFTO | MMMM | PROG | + Restricted | Secret | Top Secret | Reserved" + + Compartments [0..65535] + + Handling [0..65535] + + TCC [0..16777216] + + --> + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ENTITY % Digits "CDATA"> + <!ENTITY % Precedence "CDATA"> + <!ENTITY % IP4Addr "CDATA"> + <!ENTITY % Class "CDATA"> + <!ENTITY % Sec "CDATA"> + <!ENTITY % Compartments "CDATA"> + <!ENTITY % Handling "CDATA"> + <!ENTITY % TCC "CDATA"> + + <!ELEMENT ip (header, payload)> + + <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl, + protocol, checksum, source, destination, options, + padding)> + <!-- length of header in 32-bit words --> + <!ATTLIST header + length %Digits; #REQUIRED> + + <!ELEMENT version EMPTY> + <!-- ip version. SHOULD be "4" --> + <!ATTLIST version + value %Digits; #REQUIRED> + + <!ELEMENT tos EMPTY> + <!ATTLIST tos + precedence %Precedence; #REQUIRED + delay (normal | low) #REQUIRED + throughput (normal | high) #REQUIRED + relibility (normal | high) #REQUIRED + reserved CDATA #FIXED "0"> + + <!ELEMENT total.length EMPTY> + <!-- + total length of datagram (header and payload) in octets, MUST be + less than 65,535 (and SHOULD be less than 1024 for IPoXML on local + ethernets). + --> + <!ATTLIST total.length + value %Digits; #REQUIRED> + + <!ELEMENT id EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST id + value %Digits; #REQUIRED> + + <!ELEMENT flags EMPTY> + <!-- df = don't fragment, mf = more fragments --> + <!ATTLIST flags + + + +Kennedy Informational [Page 8] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + reserved CDATA #FIXED "0" + df (may|dont) #REQUIRED + mf (last|more) #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks --> + <!ATTLIST offset + value %Digits; #REQUIRED> + + <!ELEMENT ttl EMPTY> + <!-- 0 <= ttl <= 255 --> + <!ATTLIST ttl + value %Digits; #REQUIRED> + + <!ELEMENT protocol EMPTY> + <!-- 0 <= protocol <= 255 (per IANA) --> + <!ATTLIST protocol + value %Digits; #REQUIRED> + + <!ELEMENT checksum EMPTY> + <!-- 0 <= checksum <= 65535 (over header only) --> + <!ATTLIST checksum + value %Digits; #REQUIRED> + + <!ELEMENT source EMPTY> + <!ATTLIST source + address %IP4Addr; #REQUIRED> + + <!ELEMENT destination EMPTY> + <!ATTLIST destination + address %IP4Addr; #REQUIRED> + + <!ELEMENT options ( end | noop | security | loose | strict | record + | stream | timestamp )*> + + <!ELEMENT end EMPTY> + <!ATTLIST end + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "0"> + + <!ELEMENT noop EMPTY> + <!ATTLIST noop + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "1"> + + <!ELEMENT security EMPTY> + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST security + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "2" + length CDATA #FIXED "11" + security %Sec; #REQUIRED + compartments %Compartments; #REQUIRED + handling %Handling; #REQUIRED + tcc %TCC; #REQUIRED> + <!ELEMENT loose (hop)+> + <!ATTLIST loose + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "3" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT hop EMPTY> + <!ATTLIST hop + address %IP4Addr; #REQUIRED> + + <!ELEMENT strict (hop)+> + <!ATTLIST strict + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "9" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT record (hop)+> + <!ATTLIST record + copied CDATA #FIXED "0" + class CDATA #FIXED "0" + number CDATA #FIXED "7" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT stream EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST stream + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "8" + length CDATA #FIXED "4" + id %Digits; #REQUIRED> + + <!ELEMENT timestamp (tstamp)+> + <!-- 0 <= oflw <=15 --> + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST timestamp + copied CDATA #FIXED "0" + class CDATA #FIXED "2" + number CDATA #FIXED "4" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED + oflw %Digits; #REQUIRED + flag (0 | 1 | 3) #REQUIRED> + + <!ELEMENT tstamp EMPTY> + <!ATTLIST tstamp + time %Digits; #REQUIRED + address %IP4Addr; #IMPLIED> + <!-- + padding to bring header to 32-bit boundary. + pad MUST be "0"* + --> + <!ELEMENT padding EMPTY> + <!ATTLIST padding + pad CDATA #REQUIRED> + + <!-- payload MUST be encoded as base-64 [RFC2045], as modified + by section 2.1 of this RFC --> + <!ELEMENT payload (CDATA)> + +7.2. TCPoXML DTD + + <!-- + DTD for TCP over XML. + Refer to this DTD as: + + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + --> + + <!-- the pseudoheader is only included for checksum calculations --> + <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)> + + <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset, + reserved, control, window, checksum, urgent, + tcp.options, padding)> + + <!ELEMENT src EMPTY> + <!-- 0 <= port <= 65,535 --> + <!ATTLIST src + port %Digits; #REQUIRED> + + <!ELEMENT dest EMPTY> + <!-- 0 <= port <= 65,535 --> + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST dest + port %Digits; #REQUIRED> + + <!ELEMENT sequence EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST sequence + number %Digits; #REQUIRED> + + <!ELEMENT acknowledgement EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST acknowledgement + number %Digits; #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= number <= 255 --> + <!ATTLIST offset + number %Digits; #REQUIRED> + + <!ELEMENT reserved EMPTY> + <!ATTLIST reserved + value CDATA #FIXED "0"> + + <!ELEMENT control EMPTY> + <!ATTLIST control + urg (0|1) #IMPLIED + ack (0|1) #IMPLIED + psh (0|1) #IMPLIED + rst (0|1) #IMPLIED + syn (0|1) #IMPLIED + fin (0|1) #IMPLIED> + + <!ELEMENT window EMPTY> + <!-- 0 <= size <= 65,535 --> + <!ATTLIST window + size %Digits; #REQUIRED> + + <!-- + checksum as in ip, but with + the following pseudo-header added into the tcp element: + --> + <!ELEMENT tcp.pseudoheader (source, destination, protocol, + tcp.length)> + + <!-- + tcp header + data length in octets. does not include the size of + + the pseudoheader. + --> + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ELEMENT tcp.length EMPTY> + <!ATTLIST tcp.length + value %Digits; #REQUIRED> + + <!ELEMENT urgent EMPTY> + <!-- 0 <= pointer <= 65,535 --> + <!ATTLIST urgent + pointer %Digits; #REQUIRED> + + <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+> + + <!ELEMENT tcp.end EMPTY> + <!ATTLIST tcp.end + kind CDATA #FIXED "0"> + + <!ELEMENT tcp.noop EMPTY> + <!ATTLIST tcp.noop + kind CDATA #FIXED "1"> + + <!ELEMENT tcp.mss EMPTY> + <!ATTLIST tcp.mss + kind CDATA #FIXED "2" + length CDATA #FIXED "4" + size %Digits; #REQUIRED> + +7.3. UDPoXML DTD + + <!-- + DTD for UDP over XML. + Refer to this DTD as: + + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + --> + + <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)> + + <!ELEMENT udp.header (src, dest, udp.length, checksum)> + + <!ELEMENT udp.pseudoheader (source, destination, protocol, + udp.length)> + + <!-- + udp header + data length in octets. does not include the size of + the pseudoheader. + --> + <!ELEMENT udp.length EMPTY> + <!ATTLIST udp.length + value %Digits; #REQUIRED> + + + +Kennedy Informational [Page 13] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +8. Security Considerations + + XML, as a subset of SGML, has the same security considerations as + specified in SGML Media Types [RFC1874]. Security considerations + that apply to IP, TCP and UDP also likely apply to BLOAT as it does + not attempt to correct for issues not related to message format. + +9. References + + [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt, + February 2002. (Work in Progress) + + [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC894] Hornig, C., "Standard for the Transmission of IP + Datagrams over Ethernet Networks.", RFC 894, April 1984. + + [RFC1042] Postel, J. and J. Reynolds, "Standard for the + Transmission of IP Datagrams Over IEEE 802 Networks", STD + 43, RFC 1042, February 1988. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", RFC 1123, October 1989. + + [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December + 1995. + + [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, + October 1996. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + + + + +Kennedy Informational [Page 14] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", + RFC 3080, March 2001. + + [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., + Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D., + "Simple Object Access Protocol (SOAP) 1.1" World Wide Web + Consortium Note, May 2000 http://www.w3.org/TR/SOAP/ + + [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible + Markup Language (XML)" World Wide Web Consortium + Recommendation REC- xml-19980210. + http://www.w3.org/TR/1998/REC-xml-19980210 + +10. Author's Address + + Hugh Kennedy + Mimezine + 1060 West Addison + Chicago, IL 60613 + USA + + EMail: kennedyh@engin.umich.edu + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 15] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 16] + + + + + + + +Network Working Group H. Kennedy +Request for Comments: 3252 Mimezine +Category: Informational 1 April 2002 + + + Binary Lexical Octet Ad-hoc Transport + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document defines a reformulation of IP and two transport layer + protocols (TCP and UDP) as XML applications. + +1. Introduction + +1.1. Overview + + This document describes the Binary Lexical Octet Ad-hoc Transport + (BLOAT): a reformulation of a widely-deployed network-layer protocol + (IP [RFC791]), and two associated transport layer protocols (TCP + [RFC793] and UDP [RFC768]) as XML [XML] applications. It also + describes methods for transporting BLOAT over Ethernet and IEEE 802 + networks as well as encapsulating BLOAT in IP for gatewaying BLOAT + across the public Internet. + +1.2. Motivation + + The wild popularity of XML as a basis for application-level protocols + such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple + Object Access Protocol [SOAP], and Jabber [JABBER] prompted + investigation into the possibility of extending the use of XML in the + protocol stack. Using XML at both the transport and network layer in + addition to the application layer would provide for an amazing amount + of power and flexibility while removing dependencies on proprietary + and hard-to-understand binary protocols. This protocol unification + would also allow applications to use a single XML parser for all + aspects of their operation, eliminating developer time spent figuring + out the intricacies of each new protocol, and moving the hard work of + + + + +Kennedy Informational [Page 1] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + parsing to the XML toolset. The use of XML also mitigates concerns + over "network vs. host" byte ordering which is at the root of many + network application bugs. + +1.3. Relation to Existing Protocols + + The reformulations specified in this RFC follow as closely as + possible the spirit of the RFCs on which they are based, and so MAY + contain elements or attributes that would not be needed in a pure + reworking (e.g. length attributes, which are implicit in XML.) + + The layering of network and transport protocols are maintained in + this RFC despite the optimizations that could be made if the line + were somewhat blurred (i.e. merging TCP and IP into a single, larger + element in the DTD) in order to foster future use of this protocol as + a basis for reformulating other protocols (such as ICMP.) + + Other than the encoding, the behavioral aspects of each of the + existing protocols remain unchanged. Routing, address spaces, TCP + congestion control, etc. behave as specified in the extant standards. + Adapting to new standards and experimental algorithm heuristics for + improving performance will become much easier once the move to BLOAT + has been completed. + +1.4. Requirement Levels + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 + [RFC2119]. + +2. IPoXML + + This protocol MUST be implemented to be compliant with this RFC. + IPoXML is the root protocol REQUIRED for effective use of TCPoXML + (section 3.) and higher-level application protocols. + + The DTD for this document type can be found in section 7.1. + + The routing of IPoXML can be easily implemented on hosts with an XML + parser, as the regular structure lends itself handily to parsing and + validation of the document/datagram and then processing the + destination address, TTL, and checksum before sending it on to its + next-hop. + + The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the + wider deployment of IPv4 and the fact that implementing IPv6 as XML + would have exceeded the 1500 byte Ethernet MTU. + + + +Kennedy Informational [Page 2] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + All BLOAT implementations MUST use - and specify - the UTF-8 encoding + of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well- + formed and include the XMLDecl. + +2.1. IP Description + + A number of items have changed (for the better) from the original IP + specification. Bit-masks, where present have been converted into + human-readable values. IP addresses are listed in their dotted- + decimal notation [RFC1123]. Length and checksum values are present + as decimal integers. + + To calculate the length and checksum fields of the IP element, a + canonicalized form of the element MUST be used. The canonical form + SHALL have no whitespace (including newline characters) between + elements and only one space character between attributes. There + SHALL NOT be a space following the last attribute in an element. + + An iterative method SHOULD be used to calculate checksums, as the + length field will vary based on the size of the checksum. + + The payload element bears special attention. Due to the character + set restrictions of XML, the payload of IP datagrams (which MAY + contain arbitrary data) MUST be encoded for transport. This RFC + REQUIRES the contents of the payload to be encoded in the base-64 + encoding of RFC 2045 [RFC2045], but removes the requirement that the + encoded output MUST be wrapped on 76-character lines. + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 3] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +2.2. Example Datagram + + The following is an example IPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + <ip> + <header length="474"> + <version value="4"/> + <tos precedence="Routine" delay="Normal" throughput="Normal" + relibility="Normal" reserved="0"/> + <total.length value="461"/> + <id value="1"/> + <flags reserved="0" df="dont" mf="last"/> + <offset value="0"/> + <ttl value="255"/> + <protocol value="6"/> + <checksum value="8707"/> + <source address="10.0.0.22"/> + <destination address="10.0.0.1"/> + <options> + <end copied="0" class="0" number="0"/> + </options> + <padding pad="0"/> + </header> + <payload> + </payload> + </ip> + +3. TCPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.2. + +3.1. TCP Description + + A number of items have changed from the original TCP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + To calculate the length and checksum fields of the TCP element, a + canonicalized form of the element MUST be used as in section 2.1. + + An iterative method SHOULD be used to calculate checksums as in + section 2.1. + + The payload element MUST be encoded as in section 2.1. + + + +Kennedy Informational [Page 4] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + The TCP offset element was expanded to a maximum of 255 from 16 to + allow for the increased size of the header in XML. + + TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + <tcp> + <tcp.header> + <src port="31415"/> + <dest port="42424"/> + <sequence number="322622954"/> + <acknowledgement number="689715995"/> + <offset number=""/> + <reserved value="0"/> + <control syn="1" ack="1"/> + <window size="1"/> + <urgent pointer="0"/> + <checksum value="2988"/> + <tcp.options> + <tcp.end kind="0"/> + </tcp.options> + <padding pad="0"/> + </tcp.header> + <payload> + </payload> + </tcp> + +4. UDPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.3. + +4.1. UDP Description + + A number of items have changed from the original UDP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + + + + + + +Kennedy Informational [Page 5] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + To calculate the length and checksum fields of the UDP element, a + canonicalized form of the element MUST be used as in section 2.1. An + iterative method SHOULD be used to calculate checksums as in section + 2.1. + + The payload element MUST be encoded as in section 2.1. + + UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + <udp> + <udp.header> + <src port="31415"/> + <dest port="42424"/> + <udp.length value="143"/> + <checksum value="2988"/> + </udp.header> + <payload> + </payload> + </udp> + +5. Network Transport + + This document provides for the transmission of BLOAT datagrams over + two common families of physical layer transport. Future RFCs will + address additional transports as routing vendors catch up to the + specification, and we begin to see BLOAT routed across the Internet + backbone. + +5.1. Ethernet + + BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the + exception that the type field of the Ethernet frame MUST contain the + value 0xBEEF. The first 5 octets of the Ethernet frame payload will + be 0x3c 3f 78 6d 6c ("<?xml".) + +5.2. IEEE 802 + + BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except + that the protocol type code for IPoXML is 0xBEEF. + + + + + +Kennedy Informational [Page 6] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +6. Gatewaying over IP + + In order to facilitate the gradual introduction of BLOAT into the + public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to + gateway between networks that run BLOAT natively on their LANs. + +7. DTDs + + The Transport DTDs (7.2. and 7.3.) build on the definitions in the + Network DTD (7.1.) + + The DTDs are referenced by their PubidLiteral and SystemLiteral (from + [XML]) although it is understood that most IPoXML implementations + will not need to pull down the DTD, as it will normally be embedded + in the implementation, and presents something of a catch-22 if you + need to load part of your network protocol over the network. + +7.1. IPoXML DTD + + <!-- + DTD for IP over XML. + Refer to this DTD as: + + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + --> + <!-- + DTD data types: + + Digits [0..9]+ + + Precedence "NetworkControl | InternetworkControl | + CRITIC | FlashOverride | Flash | Immediate | + Priority | Routine" + + IP4Addr "dotted-decimal" notation of [RFC1123] + + Class [0..3] + + Sec "Unclassified | Confidential | EFTO | MMMM | PROG | + Restricted | Secret | Top Secret | Reserved" + + Compartments [0..65535] + + Handling [0..65535] + + TCC [0..16777216] + + --> + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ENTITY % Digits "CDATA"> + <!ENTITY % Precedence "CDATA"> + <!ENTITY % IP4Addr "CDATA"> + <!ENTITY % Class "CDATA"> + <!ENTITY % Sec "CDATA"> + <!ENTITY % Compartments "CDATA"> + <!ENTITY % Handling "CDATA"> + <!ENTITY % TCC "CDATA"> + + <!ELEMENT ip (header, payload)> + + <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl, + protocol, checksum, source, destination, options, + padding)> + <!-- length of header in 32-bit words --> + <!ATTLIST header + length %Digits; #REQUIRED> + + <!ELEMENT version EMPTY> + <!-- ip version. SHOULD be "4" --> + <!ATTLIST version + value %Digits; #REQUIRED> + + <!ELEMENT tos EMPTY> + <!ATTLIST tos + precedence %Precedence; #REQUIRED + delay (normal | low) #REQUIRED + throughput (normal | high) #REQUIRED + relibility (normal | high) #REQUIRED + reserved CDATA #FIXED "0"> + + <!ELEMENT total.length EMPTY> + <!-- + total length of datagram (header and payload) in octets, MUST be + less than 65,535 (and SHOULD be less than 1024 for IPoXML on local + ethernets). + --> + <!ATTLIST total.length + value %Digits; #REQUIRED> + + <!ELEMENT id EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST id + value %Digits; #REQUIRED> + + <!ELEMENT flags EMPTY> + <!-- df = don't fragment, mf = more fragments --> + <!ATTLIST flags + + + +Kennedy Informational [Page 8] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + reserved CDATA #FIXED "0" + df (may|dont) #REQUIRED + mf (last|more) #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks --> + <!ATTLIST offset + value %Digits; #REQUIRED> + + <!ELEMENT ttl EMPTY> + <!-- 0 <= ttl <= 255 --> + <!ATTLIST ttl + value %Digits; #REQUIRED> + + <!ELEMENT protocol EMPTY> + <!-- 0 <= protocol <= 255 (per IANA) --> + <!ATTLIST protocol + value %Digits; #REQUIRED> + + <!ELEMENT checksum EMPTY> + <!-- 0 <= checksum <= 65535 (over header only) --> + <!ATTLIST checksum + value %Digits; #REQUIRED> + + <!ELEMENT source EMPTY> + <!ATTLIST source + address %IP4Addr; #REQUIRED> + + <!ELEMENT destination EMPTY> + <!ATTLIST destination + address %IP4Addr; #REQUIRED> + + <!ELEMENT options ( end | noop | security | loose | strict | record + | stream | timestamp )*> + + <!ELEMENT end EMPTY> + <!ATTLIST end + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "0"> + + <!ELEMENT noop EMPTY> + <!ATTLIST noop + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "1"> + + <!ELEMENT security EMPTY> + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST security + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "2" + length CDATA #FIXED "11" + security %Sec; #REQUIRED + compartments %Compartments; #REQUIRED + handling %Handling; #REQUIRED + tcc %TCC; #REQUIRED> + <!ELEMENT loose (hop)+> + <!ATTLIST loose + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "3" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT hop EMPTY> + <!ATTLIST hop + address %IP4Addr; #REQUIRED> + + <!ELEMENT strict (hop)+> + <!ATTLIST strict + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "9" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT record (hop)+> + <!ATTLIST record + copied CDATA #FIXED "0" + class CDATA #FIXED "0" + number CDATA #FIXED "7" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT stream EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST stream + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "8" + length CDATA #FIXED "4" + id %Digits; #REQUIRED> + + <!ELEMENT timestamp (tstamp)+> + <!-- 0 <= oflw <=15 --> + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST timestamp + copied CDATA #FIXED "0" + class CDATA #FIXED "2" + number CDATA #FIXED "4" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED + oflw %Digits; #REQUIRED + flag (0 | 1 | 3) #REQUIRED> + + <!ELEMENT tstamp EMPTY> + <!ATTLIST tstamp + time %Digits; #REQUIRED + address %IP4Addr; #IMPLIED> + <!-- + padding to bring header to 32-bit boundary. + pad MUST be "0"* + --> + <!ELEMENT padding EMPTY> + <!ATTLIST padding + pad CDATA #REQUIRED> + + <!-- payload MUST be encoded as base-64 [RFC2045], as modified + by section 2.1 of this RFC --> + <!ELEMENT payload (CDATA)> + +7.2. TCPoXML DTD + + <!-- + DTD for TCP over XML. + Refer to this DTD as: + + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + --> + + <!-- the pseudoheader is only included for checksum calculations --> + <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)> + + <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset, + reserved, control, window, checksum, urgent, + tcp.options, padding)> + + <!ELEMENT src EMPTY> + <!-- 0 <= port <= 65,535 --> + <!ATTLIST src + port %Digits; #REQUIRED> + + <!ELEMENT dest EMPTY> + <!-- 0 <= port <= 65,535 --> + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST dest + port %Digits; #REQUIRED> + + <!ELEMENT sequence EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST sequence + number %Digits; #REQUIRED> + + <!ELEMENT acknowledgement EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST acknowledgement + number %Digits; #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= number <= 255 --> + <!ATTLIST offset + number %Digits; #REQUIRED> + + <!ELEMENT reserved EMPTY> + <!ATTLIST reserved + value CDATA #FIXED "0"> + + <!ELEMENT control EMPTY> + <!ATTLIST control + urg (0|1) #IMPLIED + ack (0|1) #IMPLIED + psh (0|1) #IMPLIED + rst (0|1) #IMPLIED + syn (0|1) #IMPLIED + fin (0|1) #IMPLIED> + + <!ELEMENT window EMPTY> + <!-- 0 <= size <= 65,535 --> + <!ATTLIST window + size %Digits; #REQUIRED> + + <!-- + checksum as in ip, but with + the following pseudo-header added into the tcp element: + --> + <!ELEMENT tcp.pseudoheader (source, destination, protocol, + tcp.length)> + + <!-- + tcp header + data length in octets. does not include the size of + + the pseudoheader. + --> + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ELEMENT tcp.length EMPTY> + <!ATTLIST tcp.length + value %Digits; #REQUIRED> + + <!ELEMENT urgent EMPTY> + <!-- 0 <= pointer <= 65,535 --> + <!ATTLIST urgent + pointer %Digits; #REQUIRED> + + <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+> + + <!ELEMENT tcp.end EMPTY> + <!ATTLIST tcp.end + kind CDATA #FIXED "0"> + + <!ELEMENT tcp.noop EMPTY> + <!ATTLIST tcp.noop + kind CDATA #FIXED "1"> + + <!ELEMENT tcp.mss EMPTY> + <!ATTLIST tcp.mss + kind CDATA #FIXED "2" + length CDATA #FIXED "4" + size %Digits; #REQUIRED> + +7.3. UDPoXML DTD + + <!-- + DTD for UDP over XML. + Refer to this DTD as: + + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + --> + + <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)> + + <!ELEMENT udp.header (src, dest, udp.length, checksum)> + + <!ELEMENT udp.pseudoheader (source, destination, protocol, + udp.length)> + + <!-- + udp header + data length in octets. does not include the size of + the pseudoheader. + --> + <!ELEMENT udp.length EMPTY> + <!ATTLIST udp.length + value %Digits; #REQUIRED> + + + +Kennedy Informational [Page 13] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +8. Security Considerations + + XML, as a subset of SGML, has the same security considerations as + specified in SGML Media Types [RFC1874]. Security considerations + that apply to IP, TCP and UDP also likely apply to BLOAT as it does + not attempt to correct for issues not related to message format. + +9. References + + [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt, + February 2002. (Work in Progress) + + [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC894] Hornig, C., "Standard for the Transmission of IP + Datagrams over Ethernet Networks.", RFC 894, April 1984. + + [RFC1042] Postel, J. and J. Reynolds, "Standard for the + Transmission of IP Datagrams Over IEEE 802 Networks", STD + 43, RFC 1042, February 1988. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", RFC 1123, October 1989. + + [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December + 1995. + + [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, + October 1996. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + + + + +Kennedy Informational [Page 14] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", + RFC 3080, March 2001. + + [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., + Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D., + "Simple Object Access Protocol (SOAP) 1.1" World Wide Web + Consortium Note, May 2000 http://www.w3.org/TR/SOAP/ + + [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible + Markup Language (XML)" World Wide Web Consortium + Recommendation REC- xml-19980210. + http://www.w3.org/TR/1998/REC-xml-19980210 + +10. Author's Address + + Hugh Kennedy + Mimezine + 1060 West Addison + Chicago, IL 60613 + USA + + EMail: kennedyh@engin.umich.edu + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 15] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 16] + + + + + + + +Network Working Group H. Kennedy +Request for Comments: 3252 Mimezine +Category: Informational 1 April 2002 + + + Binary Lexical Octet Ad-hoc Transport + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document defines a reformulation of IP and two transport layer + protocols (TCP and UDP) as XML applications. + +1. Introduction + +1.1. Overview + + This document describes the Binary Lexical Octet Ad-hoc Transport + (BLOAT): a reformulation of a widely-deployed network-layer protocol + (IP [RFC791]), and two associated transport layer protocols (TCP + [RFC793] and UDP [RFC768]) as XML [XML] applications. It also + describes methods for transporting BLOAT over Ethernet and IEEE 802 + networks as well as encapsulating BLOAT in IP for gatewaying BLOAT + across the public Internet. + +1.2. Motivation + + The wild popularity of XML as a basis for application-level protocols + such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple + Object Access Protocol [SOAP], and Jabber [JABBER] prompted + investigation into the possibility of extending the use of XML in the + protocol stack. Using XML at both the transport and network layer in + addition to the application layer would provide for an amazing amount + of power and flexibility while removing dependencies on proprietary + and hard-to-understand binary protocols. This protocol unification + would also allow applications to use a single XML parser for all + aspects of their operation, eliminating developer time spent figuring + out the intricacies of each new protocol, and moving the hard work of + + + + +Kennedy Informational [Page 1] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + parsing to the XML toolset. The use of XML also mitigates concerns + over "network vs. host" byte ordering which is at the root of many + network application bugs. + +1.3. Relation to Existing Protocols + + The reformulations specified in this RFC follow as closely as + possible the spirit of the RFCs on which they are based, and so MAY + contain elements or attributes that would not be needed in a pure + reworking (e.g. length attributes, which are implicit in XML.) + + The layering of network and transport protocols are maintained in + this RFC despite the optimizations that could be made if the line + were somewhat blurred (i.e. merging TCP and IP into a single, larger + element in the DTD) in order to foster future use of this protocol as + a basis for reformulating other protocols (such as ICMP.) + + Other than the encoding, the behavioral aspects of each of the + existing protocols remain unchanged. Routing, address spaces, TCP + congestion control, etc. behave as specified in the extant standards. + Adapting to new standards and experimental algorithm heuristics for + improving performance will become much easier once the move to BLOAT + has been completed. + +1.4. Requirement Levels + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 + [RFC2119]. + +2. IPoXML + + This protocol MUST be implemented to be compliant with this RFC. + IPoXML is the root protocol REQUIRED for effective use of TCPoXML + (section 3.) and higher-level application protocols. + + The DTD for this document type can be found in section 7.1. + + The routing of IPoXML can be easily implemented on hosts with an XML + parser, as the regular structure lends itself handily to parsing and + validation of the document/datagram and then processing the + destination address, TTL, and checksum before sending it on to its + next-hop. + + The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the + wider deployment of IPv4 and the fact that implementing IPv6 as XML + would have exceeded the 1500 byte Ethernet MTU. + + + +Kennedy Informational [Page 2] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + All BLOAT implementations MUST use - and specify - the UTF-8 encoding + of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well- + formed and include the XMLDecl. + +2.1. IP Description + + A number of items have changed (for the better) from the original IP + specification. Bit-masks, where present have been converted into + human-readable values. IP addresses are listed in their dotted- + decimal notation [RFC1123]. Length and checksum values are present + as decimal integers. + + To calculate the length and checksum fields of the IP element, a + canonicalized form of the element MUST be used. The canonical form + SHALL have no whitespace (including newline characters) between + elements and only one space character between attributes. There + SHALL NOT be a space following the last attribute in an element. + + An iterative method SHOULD be used to calculate checksums, as the + length field will vary based on the size of the checksum. + + The payload element bears special attention. Due to the character + set restrictions of XML, the payload of IP datagrams (which MAY + contain arbitrary data) MUST be encoded for transport. This RFC + REQUIRES the contents of the payload to be encoded in the base-64 + encoding of RFC 2045 [RFC2045], but removes the requirement that the + encoded output MUST be wrapped on 76-character lines. + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 3] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +2.2. Example Datagram + + The following is an example IPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + <ip> + <header length="474"> + <version value="4"/> + <tos precedence="Routine" delay="Normal" throughput="Normal" + relibility="Normal" reserved="0"/> + <total.length value="461"/> + <id value="1"/> + <flags reserved="0" df="dont" mf="last"/> + <offset value="0"/> + <ttl value="255"/> + <protocol value="6"/> + <checksum value="8707"/> + <source address="10.0.0.22"/> + <destination address="10.0.0.1"/> + <options> + <end copied="0" class="0" number="0"/> + </options> + <padding pad="0"/> + </header> + <payload> + </payload> + </ip> + +3. TCPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.2. + +3.1. TCP Description + + A number of items have changed from the original TCP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + To calculate the length and checksum fields of the TCP element, a + canonicalized form of the element MUST be used as in section 2.1. + + An iterative method SHOULD be used to calculate checksums as in + section 2.1. + + The payload element MUST be encoded as in section 2.1. + + + +Kennedy Informational [Page 4] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + The TCP offset element was expanded to a maximum of 255 from 16 to + allow for the increased size of the header in XML. + + TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + <tcp> + <tcp.header> + <src port="31415"/> + <dest port="42424"/> + <sequence number="322622954"/> + <acknowledgement number="689715995"/> + <offset number=""/> + <reserved value="0"/> + <control syn="1" ack="1"/> + <window size="1"/> + <urgent pointer="0"/> + <checksum value="2988"/> + <tcp.options> + <tcp.end kind="0"/> + </tcp.options> + <padding pad="0"/> + </tcp.header> + <payload> + </payload> + </tcp> + +4. UDPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.3. + +4.1. UDP Description + + A number of items have changed from the original UDP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + + + + + + +Kennedy Informational [Page 5] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + To calculate the length and checksum fields of the UDP element, a + canonicalized form of the element MUST be used as in section 2.1. An + iterative method SHOULD be used to calculate checksums as in section + 2.1. + + The payload element MUST be encoded as in section 2.1. + + UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + <udp> + <udp.header> + <src port="31415"/> + <dest port="42424"/> + <udp.length value="143"/> + <checksum value="2988"/> + </udp.header> + <payload> + </payload> + </udp> + +5. Network Transport + + This document provides for the transmission of BLOAT datagrams over + two common families of physical layer transport. Future RFCs will + address additional transports as routing vendors catch up to the + specification, and we begin to see BLOAT routed across the Internet + backbone. + +5.1. Ethernet + + BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the + exception that the type field of the Ethernet frame MUST contain the + value 0xBEEF. The first 5 octets of the Ethernet frame payload will + be 0x3c 3f 78 6d 6c ("<?xml".) + +5.2. IEEE 802 + + BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except + that the protocol type code for IPoXML is 0xBEEF. + + + + + +Kennedy Informational [Page 6] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +6. Gatewaying over IP + + In order to facilitate the gradual introduction of BLOAT into the + public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to + gateway between networks that run BLOAT natively on their LANs. + +7. DTDs + + The Transport DTDs (7.2. and 7.3.) build on the definitions in the + Network DTD (7.1.) + + The DTDs are referenced by their PubidLiteral and SystemLiteral (from + [XML]) although it is understood that most IPoXML implementations + will not need to pull down the DTD, as it will normally be embedded + in the implementation, and presents something of a catch-22 if you + need to load part of your network protocol over the network. + +7.1. IPoXML DTD + + <!-- + DTD for IP over XML. + Refer to this DTD as: + + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + --> + <!-- + DTD data types: + + Digits [0..9]+ + + Precedence "NetworkControl | InternetworkControl | + CRITIC | FlashOverride | Flash | Immediate | + Priority | Routine" + + IP4Addr "dotted-decimal" notation of [RFC1123] + + Class [0..3] + + Sec "Unclassified | Confidential | EFTO | MMMM | PROG | + Restricted | Secret | Top Secret | Reserved" + + Compartments [0..65535] + + Handling [0..65535] + + TCC [0..16777216] + + --> + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ENTITY % Digits "CDATA"> + <!ENTITY % Precedence "CDATA"> + <!ENTITY % IP4Addr "CDATA"> + <!ENTITY % Class "CDATA"> + <!ENTITY % Sec "CDATA"> + <!ENTITY % Compartments "CDATA"> + <!ENTITY % Handling "CDATA"> + <!ENTITY % TCC "CDATA"> + + <!ELEMENT ip (header, payload)> + + <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl, + protocol, checksum, source, destination, options, + padding)> + <!-- length of header in 32-bit words --> + <!ATTLIST header + length %Digits; #REQUIRED> + + <!ELEMENT version EMPTY> + <!-- ip version. SHOULD be "4" --> + <!ATTLIST version + value %Digits; #REQUIRED> + + <!ELEMENT tos EMPTY> + <!ATTLIST tos + precedence %Precedence; #REQUIRED + delay (normal | low) #REQUIRED + throughput (normal | high) #REQUIRED + relibility (normal | high) #REQUIRED + reserved CDATA #FIXED "0"> + + <!ELEMENT total.length EMPTY> + <!-- + total length of datagram (header and payload) in octets, MUST be + less than 65,535 (and SHOULD be less than 1024 for IPoXML on local + ethernets). + --> + <!ATTLIST total.length + value %Digits; #REQUIRED> + + <!ELEMENT id EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST id + value %Digits; #REQUIRED> + + <!ELEMENT flags EMPTY> + <!-- df = don't fragment, mf = more fragments --> + <!ATTLIST flags + + + +Kennedy Informational [Page 8] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + reserved CDATA #FIXED "0" + df (may|dont) #REQUIRED + mf (last|more) #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks --> + <!ATTLIST offset + value %Digits; #REQUIRED> + + <!ELEMENT ttl EMPTY> + <!-- 0 <= ttl <= 255 --> + <!ATTLIST ttl + value %Digits; #REQUIRED> + + <!ELEMENT protocol EMPTY> + <!-- 0 <= protocol <= 255 (per IANA) --> + <!ATTLIST protocol + value %Digits; #REQUIRED> + + <!ELEMENT checksum EMPTY> + <!-- 0 <= checksum <= 65535 (over header only) --> + <!ATTLIST checksum + value %Digits; #REQUIRED> + + <!ELEMENT source EMPTY> + <!ATTLIST source + address %IP4Addr; #REQUIRED> + + <!ELEMENT destination EMPTY> + <!ATTLIST destination + address %IP4Addr; #REQUIRED> + + <!ELEMENT options ( end | noop | security | loose | strict | record + | stream | timestamp )*> + + <!ELEMENT end EMPTY> + <!ATTLIST end + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "0"> + + <!ELEMENT noop EMPTY> + <!ATTLIST noop + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "1"> + + <!ELEMENT security EMPTY> + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST security + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "2" + length CDATA #FIXED "11" + security %Sec; #REQUIRED + compartments %Compartments; #REQUIRED + handling %Handling; #REQUIRED + tcc %TCC; #REQUIRED> + <!ELEMENT loose (hop)+> + <!ATTLIST loose + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "3" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT hop EMPTY> + <!ATTLIST hop + address %IP4Addr; #REQUIRED> + + <!ELEMENT strict (hop)+> + <!ATTLIST strict + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "9" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT record (hop)+> + <!ATTLIST record + copied CDATA #FIXED "0" + class CDATA #FIXED "0" + number CDATA #FIXED "7" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT stream EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST stream + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "8" + length CDATA #FIXED "4" + id %Digits; #REQUIRED> + + <!ELEMENT timestamp (tstamp)+> + <!-- 0 <= oflw <=15 --> + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST timestamp + copied CDATA #FIXED "0" + class CDATA #FIXED "2" + number CDATA #FIXED "4" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED + oflw %Digits; #REQUIRED + flag (0 | 1 | 3) #REQUIRED> + + <!ELEMENT tstamp EMPTY> + <!ATTLIST tstamp + time %Digits; #REQUIRED + address %IP4Addr; #IMPLIED> + <!-- + padding to bring header to 32-bit boundary. + pad MUST be "0"* + --> + <!ELEMENT padding EMPTY> + <!ATTLIST padding + pad CDATA #REQUIRED> + + <!-- payload MUST be encoded as base-64 [RFC2045], as modified + by section 2.1 of this RFC --> + <!ELEMENT payload (CDATA)> + +7.2. TCPoXML DTD + + <!-- + DTD for TCP over XML. + Refer to this DTD as: + + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + --> + + <!-- the pseudoheader is only included for checksum calculations --> + <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)> + + <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset, + reserved, control, window, checksum, urgent, + tcp.options, padding)> + + <!ELEMENT src EMPTY> + <!-- 0 <= port <= 65,535 --> + <!ATTLIST src + port %Digits; #REQUIRED> + + <!ELEMENT dest EMPTY> + <!-- 0 <= port <= 65,535 --> + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST dest + port %Digits; #REQUIRED> + + <!ELEMENT sequence EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST sequence + number %Digits; #REQUIRED> + + <!ELEMENT acknowledgement EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST acknowledgement + number %Digits; #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= number <= 255 --> + <!ATTLIST offset + number %Digits; #REQUIRED> + + <!ELEMENT reserved EMPTY> + <!ATTLIST reserved + value CDATA #FIXED "0"> + + <!ELEMENT control EMPTY> + <!ATTLIST control + urg (0|1) #IMPLIED + ack (0|1) #IMPLIED + psh (0|1) #IMPLIED + rst (0|1) #IMPLIED + syn (0|1) #IMPLIED + fin (0|1) #IMPLIED> + + <!ELEMENT window EMPTY> + <!-- 0 <= size <= 65,535 --> + <!ATTLIST window + size %Digits; #REQUIRED> + + <!-- + checksum as in ip, but with + the following pseudo-header added into the tcp element: + --> + <!ELEMENT tcp.pseudoheader (source, destination, protocol, + tcp.length)> + + <!-- + tcp header + data length in octets. does not include the size of + + the pseudoheader. + --> + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ELEMENT tcp.length EMPTY> + <!ATTLIST tcp.length + value %Digits; #REQUIRED> + + <!ELEMENT urgent EMPTY> + <!-- 0 <= pointer <= 65,535 --> + <!ATTLIST urgent + pointer %Digits; #REQUIRED> + + <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+> + + <!ELEMENT tcp.end EMPTY> + <!ATTLIST tcp.end + kind CDATA #FIXED "0"> + + <!ELEMENT tcp.noop EMPTY> + <!ATTLIST tcp.noop + kind CDATA #FIXED "1"> + + <!ELEMENT tcp.mss EMPTY> + <!ATTLIST tcp.mss + kind CDATA #FIXED "2" + length CDATA #FIXED "4" + size %Digits; #REQUIRED> + +7.3. UDPoXML DTD + + <!-- + DTD for UDP over XML. + Refer to this DTD as: + + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + --> + + <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)> + + <!ELEMENT udp.header (src, dest, udp.length, checksum)> + + <!ELEMENT udp.pseudoheader (source, destination, protocol, + udp.length)> + + <!-- + udp header + data length in octets. does not include the size of + the pseudoheader. + --> + <!ELEMENT udp.length EMPTY> + <!ATTLIST udp.length + value %Digits; #REQUIRED> + + + +Kennedy Informational [Page 13] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +8. Security Considerations + + XML, as a subset of SGML, has the same security considerations as + specified in SGML Media Types [RFC1874]. Security considerations + that apply to IP, TCP and UDP also likely apply to BLOAT as it does + not attempt to correct for issues not related to message format. + +9. References + + [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt, + February 2002. (Work in Progress) + + [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC894] Hornig, C., "Standard for the Transmission of IP + Datagrams over Ethernet Networks.", RFC 894, April 1984. + + [RFC1042] Postel, J. and J. Reynolds, "Standard for the + Transmission of IP Datagrams Over IEEE 802 Networks", STD + 43, RFC 1042, February 1988. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", RFC 1123, October 1989. + + [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December + 1995. + + [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, + October 1996. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + + + + +Kennedy Informational [Page 14] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", + RFC 3080, March 2001. + + [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., + Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D., + "Simple Object Access Protocol (SOAP) 1.1" World Wide Web + Consortium Note, May 2000 http://www.w3.org/TR/SOAP/ + + [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible + Markup Language (XML)" World Wide Web Consortium + Recommendation REC- xml-19980210. + http://www.w3.org/TR/1998/REC-xml-19980210 + +10. Author's Address + + Hugh Kennedy + Mimezine + 1060 West Addison + Chicago, IL 60613 + USA + + EMail: kennedyh@engin.umich.edu + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 15] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 16] + + + + + + + +Network Working Group H. Kennedy +Request for Comments: 3252 Mimezine +Category: Informational 1 April 2002 + + + Binary Lexical Octet Ad-hoc Transport + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document defines a reformulation of IP and two transport layer + protocols (TCP and UDP) as XML applications. + +1. Introduction + +1.1. Overview + + This document describes the Binary Lexical Octet Ad-hoc Transport + (BLOAT): a reformulation of a widely-deployed network-layer protocol + (IP [RFC791]), and two associated transport layer protocols (TCP + [RFC793] and UDP [RFC768]) as XML [XML] applications. It also + describes methods for transporting BLOAT over Ethernet and IEEE 802 + networks as well as encapsulating BLOAT in IP for gatewaying BLOAT + across the public Internet. + +1.2. Motivation + + The wild popularity of XML as a basis for application-level protocols + such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple + Object Access Protocol [SOAP], and Jabber [JABBER] prompted + investigation into the possibility of extending the use of XML in the + protocol stack. Using XML at both the transport and network layer in + addition to the application layer would provide for an amazing amount + of power and flexibility while removing dependencies on proprietary + and hard-to-understand binary protocols. This protocol unification + would also allow applications to use a single XML parser for all + aspects of their operation, eliminating developer time spent figuring + out the intricacies of each new protocol, and moving the hard work of + + + + +Kennedy Informational [Page 1] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + parsing to the XML toolset. The use of XML also mitigates concerns + over "network vs. host" byte ordering which is at the root of many + network application bugs. + +1.3. Relation to Existing Protocols + + The reformulations specified in this RFC follow as closely as + possible the spirit of the RFCs on which they are based, and so MAY + contain elements or attributes that would not be needed in a pure + reworking (e.g. length attributes, which are implicit in XML.) + + The layering of network and transport protocols are maintained in + this RFC despite the optimizations that could be made if the line + were somewhat blurred (i.e. merging TCP and IP into a single, larger + element in the DTD) in order to foster future use of this protocol as + a basis for reformulating other protocols (such as ICMP.) + + Other than the encoding, the behavioral aspects of each of the + existing protocols remain unchanged. Routing, address spaces, TCP + congestion control, etc. behave as specified in the extant standards. + Adapting to new standards and experimental algorithm heuristics for + improving performance will become much easier once the move to BLOAT + has been completed. + +1.4. Requirement Levels + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 + [RFC2119]. + +2. IPoXML + + This protocol MUST be implemented to be compliant with this RFC. + IPoXML is the root protocol REQUIRED for effective use of TCPoXML + (section 3.) and higher-level application protocols. + + The DTD for this document type can be found in section 7.1. + + The routing of IPoXML can be easily implemented on hosts with an XML + parser, as the regular structure lends itself handily to parsing and + validation of the document/datagram and then processing the + destination address, TTL, and checksum before sending it on to its + next-hop. + + The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the + wider deployment of IPv4 and the fact that implementing IPv6 as XML + would have exceeded the 1500 byte Ethernet MTU. + + + +Kennedy Informational [Page 2] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + All BLOAT implementations MUST use - and specify - the UTF-8 encoding + of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well- + formed and include the XMLDecl. + +2.1. IP Description + + A number of items have changed (for the better) from the original IP + specification. Bit-masks, where present have been converted into + human-readable values. IP addresses are listed in their dotted- + decimal notation [RFC1123]. Length and checksum values are present + as decimal integers. + + To calculate the length and checksum fields of the IP element, a + canonicalized form of the element MUST be used. The canonical form + SHALL have no whitespace (including newline characters) between + elements and only one space character between attributes. There + SHALL NOT be a space following the last attribute in an element. + + An iterative method SHOULD be used to calculate checksums, as the + length field will vary based on the size of the checksum. + + The payload element bears special attention. Due to the character + set restrictions of XML, the payload of IP datagrams (which MAY + contain arbitrary data) MUST be encoded for transport. This RFC + REQUIRES the contents of the payload to be encoded in the base-64 + encoding of RFC 2045 [RFC2045], but removes the requirement that the + encoded output MUST be wrapped on 76-character lines. + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 3] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +2.2. Example Datagram + + The following is an example IPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + <ip> + <header length="474"> + <version value="4"/> + <tos precedence="Routine" delay="Normal" throughput="Normal" + relibility="Normal" reserved="0"/> + <total.length value="461"/> + <id value="1"/> + <flags reserved="0" df="dont" mf="last"/> + <offset value="0"/> + <ttl value="255"/> + <protocol value="6"/> + <checksum value="8707"/> + <source address="10.0.0.22"/> + <destination address="10.0.0.1"/> + <options> + <end copied="0" class="0" number="0"/> + </options> + <padding pad="0"/> + </header> + <payload> + </payload> + </ip> + +3. TCPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.2. + +3.1. TCP Description + + A number of items have changed from the original TCP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + To calculate the length and checksum fields of the TCP element, a + canonicalized form of the element MUST be used as in section 2.1. + + An iterative method SHOULD be used to calculate checksums as in + section 2.1. + + The payload element MUST be encoded as in section 2.1. + + + +Kennedy Informational [Page 4] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + The TCP offset element was expanded to a maximum of 255 from 16 to + allow for the increased size of the header in XML. + + TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + <tcp> + <tcp.header> + <src port="31415"/> + <dest port="42424"/> + <sequence number="322622954"/> + <acknowledgement number="689715995"/> + <offset number=""/> + <reserved value="0"/> + <control syn="1" ack="1"/> + <window size="1"/> + <urgent pointer="0"/> + <checksum value="2988"/> + <tcp.options> + <tcp.end kind="0"/> + </tcp.options> + <padding pad="0"/> + </tcp.header> + <payload> + </payload> + </tcp> + +4. UDPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.3. + +4.1. UDP Description + + A number of items have changed from the original UDP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + + + + + + +Kennedy Informational [Page 5] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + To calculate the length and checksum fields of the UDP element, a + canonicalized form of the element MUST be used as in section 2.1. An + iterative method SHOULD be used to calculate checksums as in section + 2.1. + + The payload element MUST be encoded as in section 2.1. + + UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + <udp> + <udp.header> + <src port="31415"/> + <dest port="42424"/> + <udp.length value="143"/> + <checksum value="2988"/> + </udp.header> + <payload> + </payload> + </udp> + +5. Network Transport + + This document provides for the transmission of BLOAT datagrams over + two common families of physical layer transport. Future RFCs will + address additional transports as routing vendors catch up to the + specification, and we begin to see BLOAT routed across the Internet + backbone. + +5.1. Ethernet + + BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the + exception that the type field of the Ethernet frame MUST contain the + value 0xBEEF. The first 5 octets of the Ethernet frame payload will + be 0x3c 3f 78 6d 6c ("<?xml".) + +5.2. IEEE 802 + + BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except + that the protocol type code for IPoXML is 0xBEEF. + + + + + +Kennedy Informational [Page 6] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +6. Gatewaying over IP + + In order to facilitate the gradual introduction of BLOAT into the + public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to + gateway between networks that run BLOAT natively on their LANs. + +7. DTDs + + The Transport DTDs (7.2. and 7.3.) build on the definitions in the + Network DTD (7.1.) + + The DTDs are referenced by their PubidLiteral and SystemLiteral (from + [XML]) although it is understood that most IPoXML implementations + will not need to pull down the DTD, as it will normally be embedded + in the implementation, and presents something of a catch-22 if you + need to load part of your network protocol over the network. + +7.1. IPoXML DTD + + <!-- + DTD for IP over XML. + Refer to this DTD as: + + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + --> + <!-- + DTD data types: + + Digits [0..9]+ + + Precedence "NetworkControl | InternetworkControl | + CRITIC | FlashOverride | Flash | Immediate | + Priority | Routine" + + IP4Addr "dotted-decimal" notation of [RFC1123] + + Class [0..3] + + Sec "Unclassified | Confidential | EFTO | MMMM | PROG | + Restricted | Secret | Top Secret | Reserved" + + Compartments [0..65535] + + Handling [0..65535] + + TCC [0..16777216] + + --> + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ENTITY % Digits "CDATA"> + <!ENTITY % Precedence "CDATA"> + <!ENTITY % IP4Addr "CDATA"> + <!ENTITY % Class "CDATA"> + <!ENTITY % Sec "CDATA"> + <!ENTITY % Compartments "CDATA"> + <!ENTITY % Handling "CDATA"> + <!ENTITY % TCC "CDATA"> + + <!ELEMENT ip (header, payload)> + + <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl, + protocol, checksum, source, destination, options, + padding)> + <!-- length of header in 32-bit words --> + <!ATTLIST header + length %Digits; #REQUIRED> + + <!ELEMENT version EMPTY> + <!-- ip version. SHOULD be "4" --> + <!ATTLIST version + value %Digits; #REQUIRED> + + <!ELEMENT tos EMPTY> + <!ATTLIST tos + precedence %Precedence; #REQUIRED + delay (normal | low) #REQUIRED + throughput (normal | high) #REQUIRED + relibility (normal | high) #REQUIRED + reserved CDATA #FIXED "0"> + + <!ELEMENT total.length EMPTY> + <!-- + total length of datagram (header and payload) in octets, MUST be + less than 65,535 (and SHOULD be less than 1024 for IPoXML on local + ethernets). + --> + <!ATTLIST total.length + value %Digits; #REQUIRED> + + <!ELEMENT id EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST id + value %Digits; #REQUIRED> + + <!ELEMENT flags EMPTY> + <!-- df = don't fragment, mf = more fragments --> + <!ATTLIST flags + + + +Kennedy Informational [Page 8] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + reserved CDATA #FIXED "0" + df (may|dont) #REQUIRED + mf (last|more) #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks --> + <!ATTLIST offset + value %Digits; #REQUIRED> + + <!ELEMENT ttl EMPTY> + <!-- 0 <= ttl <= 255 --> + <!ATTLIST ttl + value %Digits; #REQUIRED> + + <!ELEMENT protocol EMPTY> + <!-- 0 <= protocol <= 255 (per IANA) --> + <!ATTLIST protocol + value %Digits; #REQUIRED> + + <!ELEMENT checksum EMPTY> + <!-- 0 <= checksum <= 65535 (over header only) --> + <!ATTLIST checksum + value %Digits; #REQUIRED> + + <!ELEMENT source EMPTY> + <!ATTLIST source + address %IP4Addr; #REQUIRED> + + <!ELEMENT destination EMPTY> + <!ATTLIST destination + address %IP4Addr; #REQUIRED> + + <!ELEMENT options ( end | noop | security | loose | strict | record + | stream | timestamp )*> + + <!ELEMENT end EMPTY> + <!ATTLIST end + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "0"> + + <!ELEMENT noop EMPTY> + <!ATTLIST noop + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "1"> + + <!ELEMENT security EMPTY> + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST security + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "2" + length CDATA #FIXED "11" + security %Sec; #REQUIRED + compartments %Compartments; #REQUIRED + handling %Handling; #REQUIRED + tcc %TCC; #REQUIRED> + <!ELEMENT loose (hop)+> + <!ATTLIST loose + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "3" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT hop EMPTY> + <!ATTLIST hop + address %IP4Addr; #REQUIRED> + + <!ELEMENT strict (hop)+> + <!ATTLIST strict + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "9" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT record (hop)+> + <!ATTLIST record + copied CDATA #FIXED "0" + class CDATA #FIXED "0" + number CDATA #FIXED "7" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT stream EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST stream + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "8" + length CDATA #FIXED "4" + id %Digits; #REQUIRED> + + <!ELEMENT timestamp (tstamp)+> + <!-- 0 <= oflw <=15 --> + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST timestamp + copied CDATA #FIXED "0" + class CDATA #FIXED "2" + number CDATA #FIXED "4" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED + oflw %Digits; #REQUIRED + flag (0 | 1 | 3) #REQUIRED> + + <!ELEMENT tstamp EMPTY> + <!ATTLIST tstamp + time %Digits; #REQUIRED + address %IP4Addr; #IMPLIED> + <!-- + padding to bring header to 32-bit boundary. + pad MUST be "0"* + --> + <!ELEMENT padding EMPTY> + <!ATTLIST padding + pad CDATA #REQUIRED> + + <!-- payload MUST be encoded as base-64 [RFC2045], as modified + by section 2.1 of this RFC --> + <!ELEMENT payload (CDATA)> + +7.2. TCPoXML DTD + + <!-- + DTD for TCP over XML. + Refer to this DTD as: + + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + --> + + <!-- the pseudoheader is only included for checksum calculations --> + <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)> + + <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset, + reserved, control, window, checksum, urgent, + tcp.options, padding)> + + <!ELEMENT src EMPTY> + <!-- 0 <= port <= 65,535 --> + <!ATTLIST src + port %Digits; #REQUIRED> + + <!ELEMENT dest EMPTY> + <!-- 0 <= port <= 65,535 --> + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST dest + port %Digits; #REQUIRED> + + <!ELEMENT sequence EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST sequence + number %Digits; #REQUIRED> + + <!ELEMENT acknowledgement EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST acknowledgement + number %Digits; #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= number <= 255 --> + <!ATTLIST offset + number %Digits; #REQUIRED> + + <!ELEMENT reserved EMPTY> + <!ATTLIST reserved + value CDATA #FIXED "0"> + + <!ELEMENT control EMPTY> + <!ATTLIST control + urg (0|1) #IMPLIED + ack (0|1) #IMPLIED + psh (0|1) #IMPLIED + rst (0|1) #IMPLIED + syn (0|1) #IMPLIED + fin (0|1) #IMPLIED> + + <!ELEMENT window EMPTY> + <!-- 0 <= size <= 65,535 --> + <!ATTLIST window + size %Digits; #REQUIRED> + + <!-- + checksum as in ip, but with + the following pseudo-header added into the tcp element: + --> + <!ELEMENT tcp.pseudoheader (source, destination, protocol, + tcp.length)> + + <!-- + tcp header + data length in octets. does not include the size of + + the pseudoheader. + --> + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ELEMENT tcp.length EMPTY> + <!ATTLIST tcp.length + value %Digits; #REQUIRED> + + <!ELEMENT urgent EMPTY> + <!-- 0 <= pointer <= 65,535 --> + <!ATTLIST urgent + pointer %Digits; #REQUIRED> + + <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+> + + <!ELEMENT tcp.end EMPTY> + <!ATTLIST tcp.end + kind CDATA #FIXED "0"> + + <!ELEMENT tcp.noop EMPTY> + <!ATTLIST tcp.noop + kind CDATA #FIXED "1"> + + <!ELEMENT tcp.mss EMPTY> + <!ATTLIST tcp.mss + kind CDATA #FIXED "2" + length CDATA #FIXED "4" + size %Digits; #REQUIRED> + +7.3. UDPoXML DTD + + <!-- + DTD for UDP over XML. + Refer to this DTD as: + + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + --> + + <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)> + + <!ELEMENT udp.header (src, dest, udp.length, checksum)> + + <!ELEMENT udp.pseudoheader (source, destination, protocol, + udp.length)> + + <!-- + udp header + data length in octets. does not include the size of + the pseudoheader. + --> + <!ELEMENT udp.length EMPTY> + <!ATTLIST udp.length + value %Digits; #REQUIRED> + + + +Kennedy Informational [Page 13] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +8. Security Considerations + + XML, as a subset of SGML, has the same security considerations as + specified in SGML Media Types [RFC1874]. Security considerations + that apply to IP, TCP and UDP also likely apply to BLOAT as it does + not attempt to correct for issues not related to message format. + +9. References + + [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt, + February 2002. (Work in Progress) + + [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC894] Hornig, C., "Standard for the Transmission of IP + Datagrams over Ethernet Networks.", RFC 894, April 1984. + + [RFC1042] Postel, J. and J. Reynolds, "Standard for the + Transmission of IP Datagrams Over IEEE 802 Networks", STD + 43, RFC 1042, February 1988. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", RFC 1123, October 1989. + + [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December + 1995. + + [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, + October 1996. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + + + + +Kennedy Informational [Page 14] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", + RFC 3080, March 2001. + + [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., + Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D., + "Simple Object Access Protocol (SOAP) 1.1" World Wide Web + Consortium Note, May 2000 http://www.w3.org/TR/SOAP/ + + [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible + Markup Language (XML)" World Wide Web Consortium + Recommendation REC- xml-19980210. + http://www.w3.org/TR/1998/REC-xml-19980210 + +10. Author's Address + + Hugh Kennedy + Mimezine + 1060 West Addison + Chicago, IL 60613 + USA + + EMail: kennedyh@engin.umich.edu + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 15] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 16] + + + + + + + +Network Working Group H. Kennedy +Request for Comments: 3252 Mimezine +Category: Informational 1 April 2002 + + + Binary Lexical Octet Ad-hoc Transport + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document defines a reformulation of IP and two transport layer + protocols (TCP and UDP) as XML applications. + +1. Introduction + +1.1. Overview + + This document describes the Binary Lexical Octet Ad-hoc Transport + (BLOAT): a reformulation of a widely-deployed network-layer protocol + (IP [RFC791]), and two associated transport layer protocols (TCP + [RFC793] and UDP [RFC768]) as XML [XML] applications. It also + describes methods for transporting BLOAT over Ethernet and IEEE 802 + networks as well as encapsulating BLOAT in IP for gatewaying BLOAT + across the public Internet. + +1.2. Motivation + + The wild popularity of XML as a basis for application-level protocols + such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple + Object Access Protocol [SOAP], and Jabber [JABBER] prompted + investigation into the possibility of extending the use of XML in the + protocol stack. Using XML at both the transport and network layer in + addition to the application layer would provide for an amazing amount + of power and flexibility while removing dependencies on proprietary + and hard-to-understand binary protocols. This protocol unification + would also allow applications to use a single XML parser for all + aspects of their operation, eliminating developer time spent figuring + out the intricacies of each new protocol, and moving the hard work of + + + + +Kennedy Informational [Page 1] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + parsing to the XML toolset. The use of XML also mitigates concerns + over "network vs. host" byte ordering which is at the root of many + network application bugs. + +1.3. Relation to Existing Protocols + + The reformulations specified in this RFC follow as closely as + possible the spirit of the RFCs on which they are based, and so MAY + contain elements or attributes that would not be needed in a pure + reworking (e.g. length attributes, which are implicit in XML.) + + The layering of network and transport protocols are maintained in + this RFC despite the optimizations that could be made if the line + were somewhat blurred (i.e. merging TCP and IP into a single, larger + element in the DTD) in order to foster future use of this protocol as + a basis for reformulating other protocols (such as ICMP.) + + Other than the encoding, the behavioral aspects of each of the + existing protocols remain unchanged. Routing, address spaces, TCP + congestion control, etc. behave as specified in the extant standards. + Adapting to new standards and experimental algorithm heuristics for + improving performance will become much easier once the move to BLOAT + has been completed. + +1.4. Requirement Levels + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 + [RFC2119]. + +2. IPoXML + + This protocol MUST be implemented to be compliant with this RFC. + IPoXML is the root protocol REQUIRED for effective use of TCPoXML + (section 3.) and higher-level application protocols. + + The DTD for this document type can be found in section 7.1. + + The routing of IPoXML can be easily implemented on hosts with an XML + parser, as the regular structure lends itself handily to parsing and + validation of the document/datagram and then processing the + destination address, TTL, and checksum before sending it on to its + next-hop. + + The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the + wider deployment of IPv4 and the fact that implementing IPv6 as XML + would have exceeded the 1500 byte Ethernet MTU. + + + +Kennedy Informational [Page 2] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + All BLOAT implementations MUST use - and specify - the UTF-8 encoding + of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well- + formed and include the XMLDecl. + +2.1. IP Description + + A number of items have changed (for the better) from the original IP + specification. Bit-masks, where present have been converted into + human-readable values. IP addresses are listed in their dotted- + decimal notation [RFC1123]. Length and checksum values are present + as decimal integers. + + To calculate the length and checksum fields of the IP element, a + canonicalized form of the element MUST be used. The canonical form + SHALL have no whitespace (including newline characters) between + elements and only one space character between attributes. There + SHALL NOT be a space following the last attribute in an element. + + An iterative method SHOULD be used to calculate checksums, as the + length field will vary based on the size of the checksum. + + The payload element bears special attention. Due to the character + set restrictions of XML, the payload of IP datagrams (which MAY + contain arbitrary data) MUST be encoded for transport. This RFC + REQUIRES the contents of the payload to be encoded in the base-64 + encoding of RFC 2045 [RFC2045], but removes the requirement that the + encoded output MUST be wrapped on 76-character lines. + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 3] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +2.2. Example Datagram + + The following is an example IPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + <ip> + <header length="474"> + <version value="4"/> + <tos precedence="Routine" delay="Normal" throughput="Normal" + relibility="Normal" reserved="0"/> + <total.length value="461"/> + <id value="1"/> + <flags reserved="0" df="dont" mf="last"/> + <offset value="0"/> + <ttl value="255"/> + <protocol value="6"/> + <checksum value="8707"/> + <source address="10.0.0.22"/> + <destination address="10.0.0.1"/> + <options> + <end copied="0" class="0" number="0"/> + </options> + <padding pad="0"/> + </header> + <payload> + </payload> + </ip> + +3. TCPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.2. + +3.1. TCP Description + + A number of items have changed from the original TCP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + To calculate the length and checksum fields of the TCP element, a + canonicalized form of the element MUST be used as in section 2.1. + + An iterative method SHOULD be used to calculate checksums as in + section 2.1. + + The payload element MUST be encoded as in section 2.1. + + + +Kennedy Informational [Page 4] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + The TCP offset element was expanded to a maximum of 255 from 16 to + allow for the increased size of the header in XML. + + TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + <tcp> + <tcp.header> + <src port="31415"/> + <dest port="42424"/> + <sequence number="322622954"/> + <acknowledgement number="689715995"/> + <offset number=""/> + <reserved value="0"/> + <control syn="1" ack="1"/> + <window size="1"/> + <urgent pointer="0"/> + <checksum value="2988"/> + <tcp.options> + <tcp.end kind="0"/> + </tcp.options> + <padding pad="0"/> + </tcp.header> + <payload> + </payload> + </tcp> + +4. UDPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.3. + +4.1. UDP Description + + A number of items have changed from the original UDP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + + + + + + +Kennedy Informational [Page 5] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + To calculate the length and checksum fields of the UDP element, a + canonicalized form of the element MUST be used as in section 2.1. An + iterative method SHOULD be used to calculate checksums as in section + 2.1. + + The payload element MUST be encoded as in section 2.1. + + UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + <udp> + <udp.header> + <src port="31415"/> + <dest port="42424"/> + <udp.length value="143"/> + <checksum value="2988"/> + </udp.header> + <payload> + </payload> + </udp> + +5. Network Transport + + This document provides for the transmission of BLOAT datagrams over + two common families of physical layer transport. Future RFCs will + address additional transports as routing vendors catch up to the + specification, and we begin to see BLOAT routed across the Internet + backbone. + +5.1. Ethernet + + BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the + exception that the type field of the Ethernet frame MUST contain the + value 0xBEEF. The first 5 octets of the Ethernet frame payload will + be 0x3c 3f 78 6d 6c ("<?xml".) + +5.2. IEEE 802 + + BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except + that the protocol type code for IPoXML is 0xBEEF. + + + + + +Kennedy Informational [Page 6] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +6. Gatewaying over IP + + In order to facilitate the gradual introduction of BLOAT into the + public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to + gateway between networks that run BLOAT natively on their LANs. + +7. DTDs + + The Transport DTDs (7.2. and 7.3.) build on the definitions in the + Network DTD (7.1.) + + The DTDs are referenced by their PubidLiteral and SystemLiteral (from + [XML]) although it is understood that most IPoXML implementations + will not need to pull down the DTD, as it will normally be embedded + in the implementation, and presents something of a catch-22 if you + need to load part of your network protocol over the network. + +7.1. IPoXML DTD + + <!-- + DTD for IP over XML. + Refer to this DTD as: + + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + --> + <!-- + DTD data types: + + Digits [0..9]+ + + Precedence "NetworkControl | InternetworkControl | + CRITIC | FlashOverride | Flash | Immediate | + Priority | Routine" + + IP4Addr "dotted-decimal" notation of [RFC1123] + + Class [0..3] + + Sec "Unclassified | Confidential | EFTO | MMMM | PROG | + Restricted | Secret | Top Secret | Reserved" + + Compartments [0..65535] + + Handling [0..65535] + + TCC [0..16777216] + + --> + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ENTITY % Digits "CDATA"> + <!ENTITY % Precedence "CDATA"> + <!ENTITY % IP4Addr "CDATA"> + <!ENTITY % Class "CDATA"> + <!ENTITY % Sec "CDATA"> + <!ENTITY % Compartments "CDATA"> + <!ENTITY % Handling "CDATA"> + <!ENTITY % TCC "CDATA"> + + <!ELEMENT ip (header, payload)> + + <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl, + protocol, checksum, source, destination, options, + padding)> + <!-- length of header in 32-bit words --> + <!ATTLIST header + length %Digits; #REQUIRED> + + <!ELEMENT version EMPTY> + <!-- ip version. SHOULD be "4" --> + <!ATTLIST version + value %Digits; #REQUIRED> + + <!ELEMENT tos EMPTY> + <!ATTLIST tos + precedence %Precedence; #REQUIRED + delay (normal | low) #REQUIRED + throughput (normal | high) #REQUIRED + relibility (normal | high) #REQUIRED + reserved CDATA #FIXED "0"> + + <!ELEMENT total.length EMPTY> + <!-- + total length of datagram (header and payload) in octets, MUST be + less than 65,535 (and SHOULD be less than 1024 for IPoXML on local + ethernets). + --> + <!ATTLIST total.length + value %Digits; #REQUIRED> + + <!ELEMENT id EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST id + value %Digits; #REQUIRED> + + <!ELEMENT flags EMPTY> + <!-- df = don't fragment, mf = more fragments --> + <!ATTLIST flags + + + +Kennedy Informational [Page 8] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + reserved CDATA #FIXED "0" + df (may|dont) #REQUIRED + mf (last|more) #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks --> + <!ATTLIST offset + value %Digits; #REQUIRED> + + <!ELEMENT ttl EMPTY> + <!-- 0 <= ttl <= 255 --> + <!ATTLIST ttl + value %Digits; #REQUIRED> + + <!ELEMENT protocol EMPTY> + <!-- 0 <= protocol <= 255 (per IANA) --> + <!ATTLIST protocol + value %Digits; #REQUIRED> + + <!ELEMENT checksum EMPTY> + <!-- 0 <= checksum <= 65535 (over header only) --> + <!ATTLIST checksum + value %Digits; #REQUIRED> + + <!ELEMENT source EMPTY> + <!ATTLIST source + address %IP4Addr; #REQUIRED> + + <!ELEMENT destination EMPTY> + <!ATTLIST destination + address %IP4Addr; #REQUIRED> + + <!ELEMENT options ( end | noop | security | loose | strict | record + | stream | timestamp )*> + + <!ELEMENT end EMPTY> + <!ATTLIST end + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "0"> + + <!ELEMENT noop EMPTY> + <!ATTLIST noop + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "1"> + + <!ELEMENT security EMPTY> + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST security + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "2" + length CDATA #FIXED "11" + security %Sec; #REQUIRED + compartments %Compartments; #REQUIRED + handling %Handling; #REQUIRED + tcc %TCC; #REQUIRED> + <!ELEMENT loose (hop)+> + <!ATTLIST loose + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "3" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT hop EMPTY> + <!ATTLIST hop + address %IP4Addr; #REQUIRED> + + <!ELEMENT strict (hop)+> + <!ATTLIST strict + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "9" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT record (hop)+> + <!ATTLIST record + copied CDATA #FIXED "0" + class CDATA #FIXED "0" + number CDATA #FIXED "7" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT stream EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST stream + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "8" + length CDATA #FIXED "4" + id %Digits; #REQUIRED> + + <!ELEMENT timestamp (tstamp)+> + <!-- 0 <= oflw <=15 --> + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST timestamp + copied CDATA #FIXED "0" + class CDATA #FIXED "2" + number CDATA #FIXED "4" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED + oflw %Digits; #REQUIRED + flag (0 | 1 | 3) #REQUIRED> + + <!ELEMENT tstamp EMPTY> + <!ATTLIST tstamp + time %Digits; #REQUIRED + address %IP4Addr; #IMPLIED> + <!-- + padding to bring header to 32-bit boundary. + pad MUST be "0"* + --> + <!ELEMENT padding EMPTY> + <!ATTLIST padding + pad CDATA #REQUIRED> + + <!-- payload MUST be encoded as base-64 [RFC2045], as modified + by section 2.1 of this RFC --> + <!ELEMENT payload (CDATA)> + +7.2. TCPoXML DTD + + <!-- + DTD for TCP over XML. + Refer to this DTD as: + + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + --> + + <!-- the pseudoheader is only included for checksum calculations --> + <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)> + + <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset, + reserved, control, window, checksum, urgent, + tcp.options, padding)> + + <!ELEMENT src EMPTY> + <!-- 0 <= port <= 65,535 --> + <!ATTLIST src + port %Digits; #REQUIRED> + + <!ELEMENT dest EMPTY> + <!-- 0 <= port <= 65,535 --> + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST dest + port %Digits; #REQUIRED> + + <!ELEMENT sequence EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST sequence + number %Digits; #REQUIRED> + + <!ELEMENT acknowledgement EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST acknowledgement + number %Digits; #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= number <= 255 --> + <!ATTLIST offset + number %Digits; #REQUIRED> + + <!ELEMENT reserved EMPTY> + <!ATTLIST reserved + value CDATA #FIXED "0"> + + <!ELEMENT control EMPTY> + <!ATTLIST control + urg (0|1) #IMPLIED + ack (0|1) #IMPLIED + psh (0|1) #IMPLIED + rst (0|1) #IMPLIED + syn (0|1) #IMPLIED + fin (0|1) #IMPLIED> + + <!ELEMENT window EMPTY> + <!-- 0 <= size <= 65,535 --> + <!ATTLIST window + size %Digits; #REQUIRED> + + <!-- + checksum as in ip, but with + the following pseudo-header added into the tcp element: + --> + <!ELEMENT tcp.pseudoheader (source, destination, protocol, + tcp.length)> + + <!-- + tcp header + data length in octets. does not include the size of + + the pseudoheader. + --> + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ELEMENT tcp.length EMPTY> + <!ATTLIST tcp.length + value %Digits; #REQUIRED> + + <!ELEMENT urgent EMPTY> + <!-- 0 <= pointer <= 65,535 --> + <!ATTLIST urgent + pointer %Digits; #REQUIRED> + + <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+> + + <!ELEMENT tcp.end EMPTY> + <!ATTLIST tcp.end + kind CDATA #FIXED "0"> + + <!ELEMENT tcp.noop EMPTY> + <!ATTLIST tcp.noop + kind CDATA #FIXED "1"> + + <!ELEMENT tcp.mss EMPTY> + <!ATTLIST tcp.mss + kind CDATA #FIXED "2" + length CDATA #FIXED "4" + size %Digits; #REQUIRED> + +7.3. UDPoXML DTD + + <!-- + DTD for UDP over XML. + Refer to this DTD as: + + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + --> + + <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)> + + <!ELEMENT udp.header (src, dest, udp.length, checksum)> + + <!ELEMENT udp.pseudoheader (source, destination, protocol, + udp.length)> + + <!-- + udp header + data length in octets. does not include the size of + the pseudoheader. + --> + <!ELEMENT udp.length EMPTY> + <!ATTLIST udp.length + value %Digits; #REQUIRED> + + + +Kennedy Informational [Page 13] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +8. Security Considerations + + XML, as a subset of SGML, has the same security considerations as + specified in SGML Media Types [RFC1874]. Security considerations + that apply to IP, TCP and UDP also likely apply to BLOAT as it does + not attempt to correct for issues not related to message format. + +9. References + + [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt, + February 2002. (Work in Progress) + + [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC894] Hornig, C., "Standard for the Transmission of IP + Datagrams over Ethernet Networks.", RFC 894, April 1984. + + [RFC1042] Postel, J. and J. Reynolds, "Standard for the + Transmission of IP Datagrams Over IEEE 802 Networks", STD + 43, RFC 1042, February 1988. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", RFC 1123, October 1989. + + [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December + 1995. + + [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, + October 1996. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + + + + +Kennedy Informational [Page 14] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", + RFC 3080, March 2001. + + [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., + Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D., + "Simple Object Access Protocol (SOAP) 1.1" World Wide Web + Consortium Note, May 2000 http://www.w3.org/TR/SOAP/ + + [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible + Markup Language (XML)" World Wide Web Consortium + Recommendation REC- xml-19980210. + http://www.w3.org/TR/1998/REC-xml-19980210 + +10. Author's Address + + Hugh Kennedy + Mimezine + 1060 West Addison + Chicago, IL 60613 + USA + + EMail: kennedyh@engin.umich.edu + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 15] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 16] + + + + + + + +Network Working Group H. Kennedy +Request for Comments: 3252 Mimezine +Category: Informational 1 April 2002 + + + Binary Lexical Octet Ad-hoc Transport + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document defines a reformulation of IP and two transport layer + protocols (TCP and UDP) as XML applications. + +1. Introduction + +1.1. Overview + + This document describes the Binary Lexical Octet Ad-hoc Transport + (BLOAT): a reformulation of a widely-deployed network-layer protocol + (IP [RFC791]), and two associated transport layer protocols (TCP + [RFC793] and UDP [RFC768]) as XML [XML] applications. It also + describes methods for transporting BLOAT over Ethernet and IEEE 802 + networks as well as encapsulating BLOAT in IP for gatewaying BLOAT + across the public Internet. + +1.2. Motivation + + The wild popularity of XML as a basis for application-level protocols + such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple + Object Access Protocol [SOAP], and Jabber [JABBER] prompted + investigation into the possibility of extending the use of XML in the + protocol stack. Using XML at both the transport and network layer in + addition to the application layer would provide for an amazing amount + of power and flexibility while removing dependencies on proprietary + and hard-to-understand binary protocols. This protocol unification + would also allow applications to use a single XML parser for all + aspects of their operation, eliminating developer time spent figuring + out the intricacies of each new protocol, and moving the hard work of + + + + +Kennedy Informational [Page 1] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + parsing to the XML toolset. The use of XML also mitigates concerns + over "network vs. host" byte ordering which is at the root of many + network application bugs. + +1.3. Relation to Existing Protocols + + The reformulations specified in this RFC follow as closely as + possible the spirit of the RFCs on which they are based, and so MAY + contain elements or attributes that would not be needed in a pure + reworking (e.g. length attributes, which are implicit in XML.) + + The layering of network and transport protocols are maintained in + this RFC despite the optimizations that could be made if the line + were somewhat blurred (i.e. merging TCP and IP into a single, larger + element in the DTD) in order to foster future use of this protocol as + a basis for reformulating other protocols (such as ICMP.) + + Other than the encoding, the behavioral aspects of each of the + existing protocols remain unchanged. Routing, address spaces, TCP + congestion control, etc. behave as specified in the extant standards. + Adapting to new standards and experimental algorithm heuristics for + improving performance will become much easier once the move to BLOAT + has been completed. + +1.4. Requirement Levels + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 + [RFC2119]. + +2. IPoXML + + This protocol MUST be implemented to be compliant with this RFC. + IPoXML is the root protocol REQUIRED for effective use of TCPoXML + (section 3.) and higher-level application protocols. + + The DTD for this document type can be found in section 7.1. + + The routing of IPoXML can be easily implemented on hosts with an XML + parser, as the regular structure lends itself handily to parsing and + validation of the document/datagram and then processing the + destination address, TTL, and checksum before sending it on to its + next-hop. + + The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the + wider deployment of IPv4 and the fact that implementing IPv6 as XML + would have exceeded the 1500 byte Ethernet MTU. + + + +Kennedy Informational [Page 2] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + All BLOAT implementations MUST use - and specify - the UTF-8 encoding + of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well- + formed and include the XMLDecl. + +2.1. IP Description + + A number of items have changed (for the better) from the original IP + specification. Bit-masks, where present have been converted into + human-readable values. IP addresses are listed in their dotted- + decimal notation [RFC1123]. Length and checksum values are present + as decimal integers. + + To calculate the length and checksum fields of the IP element, a + canonicalized form of the element MUST be used. The canonical form + SHALL have no whitespace (including newline characters) between + elements and only one space character between attributes. There + SHALL NOT be a space following the last attribute in an element. + + An iterative method SHOULD be used to calculate checksums, as the + length field will vary based on the size of the checksum. + + The payload element bears special attention. Due to the character + set restrictions of XML, the payload of IP datagrams (which MAY + contain arbitrary data) MUST be encoded for transport. This RFC + REQUIRES the contents of the payload to be encoded in the base-64 + encoding of RFC 2045 [RFC2045], but removes the requirement that the + encoded output MUST be wrapped on 76-character lines. + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 3] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +2.2. Example Datagram + + The following is an example IPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + <ip> + <header length="474"> + <version value="4"/> + <tos precedence="Routine" delay="Normal" throughput="Normal" + relibility="Normal" reserved="0"/> + <total.length value="461"/> + <id value="1"/> + <flags reserved="0" df="dont" mf="last"/> + <offset value="0"/> + <ttl value="255"/> + <protocol value="6"/> + <checksum value="8707"/> + <source address="10.0.0.22"/> + <destination address="10.0.0.1"/> + <options> + <end copied="0" class="0" number="0"/> + </options> + <padding pad="0"/> + </header> + <payload> + </payload> + </ip> + +3. TCPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.2. + +3.1. TCP Description + + A number of items have changed from the original TCP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + To calculate the length and checksum fields of the TCP element, a + canonicalized form of the element MUST be used as in section 2.1. + + An iterative method SHOULD be used to calculate checksums as in + section 2.1. + + The payload element MUST be encoded as in section 2.1. + + + +Kennedy Informational [Page 4] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + The TCP offset element was expanded to a maximum of 255 from 16 to + allow for the increased size of the header in XML. + + TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + <tcp> + <tcp.header> + <src port="31415"/> + <dest port="42424"/> + <sequence number="322622954"/> + <acknowledgement number="689715995"/> + <offset number=""/> + <reserved value="0"/> + <control syn="1" ack="1"/> + <window size="1"/> + <urgent pointer="0"/> + <checksum value="2988"/> + <tcp.options> + <tcp.end kind="0"/> + </tcp.options> + <padding pad="0"/> + </tcp.header> + <payload> + </payload> + </tcp> + +4. UDPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.3. + +4.1. UDP Description + + A number of items have changed from the original UDP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + + + + + + +Kennedy Informational [Page 5] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + To calculate the length and checksum fields of the UDP element, a + canonicalized form of the element MUST be used as in section 2.1. An + iterative method SHOULD be used to calculate checksums as in section + 2.1. + + The payload element MUST be encoded as in section 2.1. + + UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + <udp> + <udp.header> + <src port="31415"/> + <dest port="42424"/> + <udp.length value="143"/> + <checksum value="2988"/> + </udp.header> + <payload> + </payload> + </udp> + +5. Network Transport + + This document provides for the transmission of BLOAT datagrams over + two common families of physical layer transport. Future RFCs will + address additional transports as routing vendors catch up to the + specification, and we begin to see BLOAT routed across the Internet + backbone. + +5.1. Ethernet + + BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the + exception that the type field of the Ethernet frame MUST contain the + value 0xBEEF. The first 5 octets of the Ethernet frame payload will + be 0x3c 3f 78 6d 6c ("<?xml".) + +5.2. IEEE 802 + + BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except + that the protocol type code for IPoXML is 0xBEEF. + + + + + +Kennedy Informational [Page 6] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +6. Gatewaying over IP + + In order to facilitate the gradual introduction of BLOAT into the + public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to + gateway between networks that run BLOAT natively on their LANs. + +7. DTDs + + The Transport DTDs (7.2. and 7.3.) build on the definitions in the + Network DTD (7.1.) + + The DTDs are referenced by their PubidLiteral and SystemLiteral (from + [XML]) although it is understood that most IPoXML implementations + will not need to pull down the DTD, as it will normally be embedded + in the implementation, and presents something of a catch-22 if you + need to load part of your network protocol over the network. + +7.1. IPoXML DTD + + <!-- + DTD for IP over XML. + Refer to this DTD as: + + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + --> + <!-- + DTD data types: + + Digits [0..9]+ + + Precedence "NetworkControl | InternetworkControl | + CRITIC | FlashOverride | Flash | Immediate | + Priority | Routine" + + IP4Addr "dotted-decimal" notation of [RFC1123] + + Class [0..3] + + Sec "Unclassified | Confidential | EFTO | MMMM | PROG | + Restricted | Secret | Top Secret | Reserved" + + Compartments [0..65535] + + Handling [0..65535] + + TCC [0..16777216] + + --> + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ENTITY % Digits "CDATA"> + <!ENTITY % Precedence "CDATA"> + <!ENTITY % IP4Addr "CDATA"> + <!ENTITY % Class "CDATA"> + <!ENTITY % Sec "CDATA"> + <!ENTITY % Compartments "CDATA"> + <!ENTITY % Handling "CDATA"> + <!ENTITY % TCC "CDATA"> + + <!ELEMENT ip (header, payload)> + + <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl, + protocol, checksum, source, destination, options, + padding)> + <!-- length of header in 32-bit words --> + <!ATTLIST header + length %Digits; #REQUIRED> + + <!ELEMENT version EMPTY> + <!-- ip version. SHOULD be "4" --> + <!ATTLIST version + value %Digits; #REQUIRED> + + <!ELEMENT tos EMPTY> + <!ATTLIST tos + precedence %Precedence; #REQUIRED + delay (normal | low) #REQUIRED + throughput (normal | high) #REQUIRED + relibility (normal | high) #REQUIRED + reserved CDATA #FIXED "0"> + + <!ELEMENT total.length EMPTY> + <!-- + total length of datagram (header and payload) in octets, MUST be + less than 65,535 (and SHOULD be less than 1024 for IPoXML on local + ethernets). + --> + <!ATTLIST total.length + value %Digits; #REQUIRED> + + <!ELEMENT id EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST id + value %Digits; #REQUIRED> + + <!ELEMENT flags EMPTY> + <!-- df = don't fragment, mf = more fragments --> + <!ATTLIST flags + + + +Kennedy Informational [Page 8] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + reserved CDATA #FIXED "0" + df (may|dont) #REQUIRED + mf (last|more) #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks --> + <!ATTLIST offset + value %Digits; #REQUIRED> + + <!ELEMENT ttl EMPTY> + <!-- 0 <= ttl <= 255 --> + <!ATTLIST ttl + value %Digits; #REQUIRED> + + <!ELEMENT protocol EMPTY> + <!-- 0 <= protocol <= 255 (per IANA) --> + <!ATTLIST protocol + value %Digits; #REQUIRED> + + <!ELEMENT checksum EMPTY> + <!-- 0 <= checksum <= 65535 (over header only) --> + <!ATTLIST checksum + value %Digits; #REQUIRED> + + <!ELEMENT source EMPTY> + <!ATTLIST source + address %IP4Addr; #REQUIRED> + + <!ELEMENT destination EMPTY> + <!ATTLIST destination + address %IP4Addr; #REQUIRED> + + <!ELEMENT options ( end | noop | security | loose | strict | record + | stream | timestamp )*> + + <!ELEMENT end EMPTY> + <!ATTLIST end + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "0"> + + <!ELEMENT noop EMPTY> + <!ATTLIST noop + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "1"> + + <!ELEMENT security EMPTY> + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST security + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "2" + length CDATA #FIXED "11" + security %Sec; #REQUIRED + compartments %Compartments; #REQUIRED + handling %Handling; #REQUIRED + tcc %TCC; #REQUIRED> + <!ELEMENT loose (hop)+> + <!ATTLIST loose + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "3" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT hop EMPTY> + <!ATTLIST hop + address %IP4Addr; #REQUIRED> + + <!ELEMENT strict (hop)+> + <!ATTLIST strict + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "9" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT record (hop)+> + <!ATTLIST record + copied CDATA #FIXED "0" + class CDATA #FIXED "0" + number CDATA #FIXED "7" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT stream EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST stream + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "8" + length CDATA #FIXED "4" + id %Digits; #REQUIRED> + + <!ELEMENT timestamp (tstamp)+> + <!-- 0 <= oflw <=15 --> + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST timestamp + copied CDATA #FIXED "0" + class CDATA #FIXED "2" + number CDATA #FIXED "4" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED + oflw %Digits; #REQUIRED + flag (0 | 1 | 3) #REQUIRED> + + <!ELEMENT tstamp EMPTY> + <!ATTLIST tstamp + time %Digits; #REQUIRED + address %IP4Addr; #IMPLIED> + <!-- + padding to bring header to 32-bit boundary. + pad MUST be "0"* + --> + <!ELEMENT padding EMPTY> + <!ATTLIST padding + pad CDATA #REQUIRED> + + <!-- payload MUST be encoded as base-64 [RFC2045], as modified + by section 2.1 of this RFC --> + <!ELEMENT payload (CDATA)> + +7.2. TCPoXML DTD + + <!-- + DTD for TCP over XML. + Refer to this DTD as: + + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + --> + + <!-- the pseudoheader is only included for checksum calculations --> + <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)> + + <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset, + reserved, control, window, checksum, urgent, + tcp.options, padding)> + + <!ELEMENT src EMPTY> + <!-- 0 <= port <= 65,535 --> + <!ATTLIST src + port %Digits; #REQUIRED> + + <!ELEMENT dest EMPTY> + <!-- 0 <= port <= 65,535 --> + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST dest + port %Digits; #REQUIRED> + + <!ELEMENT sequence EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST sequence + number %Digits; #REQUIRED> + + <!ELEMENT acknowledgement EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST acknowledgement + number %Digits; #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= number <= 255 --> + <!ATTLIST offset + number %Digits; #REQUIRED> + + <!ELEMENT reserved EMPTY> + <!ATTLIST reserved + value CDATA #FIXED "0"> + + <!ELEMENT control EMPTY> + <!ATTLIST control + urg (0|1) #IMPLIED + ack (0|1) #IMPLIED + psh (0|1) #IMPLIED + rst (0|1) #IMPLIED + syn (0|1) #IMPLIED + fin (0|1) #IMPLIED> + + <!ELEMENT window EMPTY> + <!-- 0 <= size <= 65,535 --> + <!ATTLIST window + size %Digits; #REQUIRED> + + <!-- + checksum as in ip, but with + the following pseudo-header added into the tcp element: + --> + <!ELEMENT tcp.pseudoheader (source, destination, protocol, + tcp.length)> + + <!-- + tcp header + data length in octets. does not include the size of + + the pseudoheader. + --> + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ELEMENT tcp.length EMPTY> + <!ATTLIST tcp.length + value %Digits; #REQUIRED> + + <!ELEMENT urgent EMPTY> + <!-- 0 <= pointer <= 65,535 --> + <!ATTLIST urgent + pointer %Digits; #REQUIRED> + + <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+> + + <!ELEMENT tcp.end EMPTY> + <!ATTLIST tcp.end + kind CDATA #FIXED "0"> + + <!ELEMENT tcp.noop EMPTY> + <!ATTLIST tcp.noop + kind CDATA #FIXED "1"> + + <!ELEMENT tcp.mss EMPTY> + <!ATTLIST tcp.mss + kind CDATA #FIXED "2" + length CDATA #FIXED "4" + size %Digits; #REQUIRED> + +7.3. UDPoXML DTD + + <!-- + DTD for UDP over XML. + Refer to this DTD as: + + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + --> + + <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)> + + <!ELEMENT udp.header (src, dest, udp.length, checksum)> + + <!ELEMENT udp.pseudoheader (source, destination, protocol, + udp.length)> + + <!-- + udp header + data length in octets. does not include the size of + the pseudoheader. + --> + <!ELEMENT udp.length EMPTY> + <!ATTLIST udp.length + value %Digits; #REQUIRED> + + + +Kennedy Informational [Page 13] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +8. Security Considerations + + XML, as a subset of SGML, has the same security considerations as + specified in SGML Media Types [RFC1874]. Security considerations + that apply to IP, TCP and UDP also likely apply to BLOAT as it does + not attempt to correct for issues not related to message format. + +9. References + + [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt, + February 2002. (Work in Progress) + + [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC894] Hornig, C., "Standard for the Transmission of IP + Datagrams over Ethernet Networks.", RFC 894, April 1984. + + [RFC1042] Postel, J. and J. Reynolds, "Standard for the + Transmission of IP Datagrams Over IEEE 802 Networks", STD + 43, RFC 1042, February 1988. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", RFC 1123, October 1989. + + [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December + 1995. + + [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, + October 1996. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + + + + +Kennedy Informational [Page 14] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", + RFC 3080, March 2001. + + [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., + Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D., + "Simple Object Access Protocol (SOAP) 1.1" World Wide Web + Consortium Note, May 2000 http://www.w3.org/TR/SOAP/ + + [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible + Markup Language (XML)" World Wide Web Consortium + Recommendation REC- xml-19980210. + http://www.w3.org/TR/1998/REC-xml-19980210 + +10. Author's Address + + Hugh Kennedy + Mimezine + 1060 West Addison + Chicago, IL 60613 + USA + + EMail: kennedyh@engin.umich.edu + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 15] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 16] + + + + + + + +Network Working Group H. Kennedy +Request for Comments: 3252 Mimezine +Category: Informational 1 April 2002 + + + Binary Lexical Octet Ad-hoc Transport + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document defines a reformulation of IP and two transport layer + protocols (TCP and UDP) as XML applications. + +1. Introduction + +1.1. Overview + + This document describes the Binary Lexical Octet Ad-hoc Transport + (BLOAT): a reformulation of a widely-deployed network-layer protocol + (IP [RFC791]), and two associated transport layer protocols (TCP + [RFC793] and UDP [RFC768]) as XML [XML] applications. It also + describes methods for transporting BLOAT over Ethernet and IEEE 802 + networks as well as encapsulating BLOAT in IP for gatewaying BLOAT + across the public Internet. + +1.2. Motivation + + The wild popularity of XML as a basis for application-level protocols + such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple + Object Access Protocol [SOAP], and Jabber [JABBER] prompted + investigation into the possibility of extending the use of XML in the + protocol stack. Using XML at both the transport and network layer in + addition to the application layer would provide for an amazing amount + of power and flexibility while removing dependencies on proprietary + and hard-to-understand binary protocols. This protocol unification + would also allow applications to use a single XML parser for all + aspects of their operation, eliminating developer time spent figuring + out the intricacies of each new protocol, and moving the hard work of + + + + +Kennedy Informational [Page 1] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + parsing to the XML toolset. The use of XML also mitigates concerns + over "network vs. host" byte ordering which is at the root of many + network application bugs. + +1.3. Relation to Existing Protocols + + The reformulations specified in this RFC follow as closely as + possible the spirit of the RFCs on which they are based, and so MAY + contain elements or attributes that would not be needed in a pure + reworking (e.g. length attributes, which are implicit in XML.) + + The layering of network and transport protocols are maintained in + this RFC despite the optimizations that could be made if the line + were somewhat blurred (i.e. merging TCP and IP into a single, larger + element in the DTD) in order to foster future use of this protocol as + a basis for reformulating other protocols (such as ICMP.) + + Other than the encoding, the behavioral aspects of each of the + existing protocols remain unchanged. Routing, address spaces, TCP + congestion control, etc. behave as specified in the extant standards. + Adapting to new standards and experimental algorithm heuristics for + improving performance will become much easier once the move to BLOAT + has been completed. + +1.4. Requirement Levels + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 + [RFC2119]. + +2. IPoXML + + This protocol MUST be implemented to be compliant with this RFC. + IPoXML is the root protocol REQUIRED for effective use of TCPoXML + (section 3.) and higher-level application protocols. + + The DTD for this document type can be found in section 7.1. + + The routing of IPoXML can be easily implemented on hosts with an XML + parser, as the regular structure lends itself handily to parsing and + validation of the document/datagram and then processing the + destination address, TTL, and checksum before sending it on to its + next-hop. + + The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the + wider deployment of IPv4 and the fact that implementing IPv6 as XML + would have exceeded the 1500 byte Ethernet MTU. + + + +Kennedy Informational [Page 2] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + All BLOAT implementations MUST use - and specify - the UTF-8 encoding + of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well- + formed and include the XMLDecl. + +2.1. IP Description + + A number of items have changed (for the better) from the original IP + specification. Bit-masks, where present have been converted into + human-readable values. IP addresses are listed in their dotted- + decimal notation [RFC1123]. Length and checksum values are present + as decimal integers. + + To calculate the length and checksum fields of the IP element, a + canonicalized form of the element MUST be used. The canonical form + SHALL have no whitespace (including newline characters) between + elements and only one space character between attributes. There + SHALL NOT be a space following the last attribute in an element. + + An iterative method SHOULD be used to calculate checksums, as the + length field will vary based on the size of the checksum. + + The payload element bears special attention. Due to the character + set restrictions of XML, the payload of IP datagrams (which MAY + contain arbitrary data) MUST be encoded for transport. This RFC + REQUIRES the contents of the payload to be encoded in the base-64 + encoding of RFC 2045 [RFC2045], but removes the requirement that the + encoded output MUST be wrapped on 76-character lines. + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 3] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +2.2. Example Datagram + + The following is an example IPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + <ip> + <header length="474"> + <version value="4"/> + <tos precedence="Routine" delay="Normal" throughput="Normal" + relibility="Normal" reserved="0"/> + <total.length value="461"/> + <id value="1"/> + <flags reserved="0" df="dont" mf="last"/> + <offset value="0"/> + <ttl value="255"/> + <protocol value="6"/> + <checksum value="8707"/> + <source address="10.0.0.22"/> + <destination address="10.0.0.1"/> + <options> + <end copied="0" class="0" number="0"/> + </options> + <padding pad="0"/> + </header> + <payload> + </payload> + </ip> + +3. TCPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.2. + +3.1. TCP Description + + A number of items have changed from the original TCP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + To calculate the length and checksum fields of the TCP element, a + canonicalized form of the element MUST be used as in section 2.1. + + An iterative method SHOULD be used to calculate checksums as in + section 2.1. + + The payload element MUST be encoded as in section 2.1. + + + +Kennedy Informational [Page 4] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + The TCP offset element was expanded to a maximum of 255 from 16 to + allow for the increased size of the header in XML. + + TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + <tcp> + <tcp.header> + <src port="31415"/> + <dest port="42424"/> + <sequence number="322622954"/> + <acknowledgement number="689715995"/> + <offset number=""/> + <reserved value="0"/> + <control syn="1" ack="1"/> + <window size="1"/> + <urgent pointer="0"/> + <checksum value="2988"/> + <tcp.options> + <tcp.end kind="0"/> + </tcp.options> + <padding pad="0"/> + </tcp.header> + <payload> + </payload> + </tcp> + +4. UDPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.3. + +4.1. UDP Description + + A number of items have changed from the original UDP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + + + + + + +Kennedy Informational [Page 5] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + To calculate the length and checksum fields of the UDP element, a + canonicalized form of the element MUST be used as in section 2.1. An + iterative method SHOULD be used to calculate checksums as in section + 2.1. + + The payload element MUST be encoded as in section 2.1. + + UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + <udp> + <udp.header> + <src port="31415"/> + <dest port="42424"/> + <udp.length value="143"/> + <checksum value="2988"/> + </udp.header> + <payload> + </payload> + </udp> + +5. Network Transport + + This document provides for the transmission of BLOAT datagrams over + two common families of physical layer transport. Future RFCs will + address additional transports as routing vendors catch up to the + specification, and we begin to see BLOAT routed across the Internet + backbone. + +5.1. Ethernet + + BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the + exception that the type field of the Ethernet frame MUST contain the + value 0xBEEF. The first 5 octets of the Ethernet frame payload will + be 0x3c 3f 78 6d 6c ("<?xml".) + +5.2. IEEE 802 + + BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except + that the protocol type code for IPoXML is 0xBEEF. + + + + + +Kennedy Informational [Page 6] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +6. Gatewaying over IP + + In order to facilitate the gradual introduction of BLOAT into the + public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to + gateway between networks that run BLOAT natively on their LANs. + +7. DTDs + + The Transport DTDs (7.2. and 7.3.) build on the definitions in the + Network DTD (7.1.) + + The DTDs are referenced by their PubidLiteral and SystemLiteral (from + [XML]) although it is understood that most IPoXML implementations + will not need to pull down the DTD, as it will normally be embedded + in the implementation, and presents something of a catch-22 if you + need to load part of your network protocol over the network. + +7.1. IPoXML DTD + + <!-- + DTD for IP over XML. + Refer to this DTD as: + + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + --> + <!-- + DTD data types: + + Digits [0..9]+ + + Precedence "NetworkControl | InternetworkControl | + CRITIC | FlashOverride | Flash | Immediate | + Priority | Routine" + + IP4Addr "dotted-decimal" notation of [RFC1123] + + Class [0..3] + + Sec "Unclassified | Confidential | EFTO | MMMM | PROG | + Restricted | Secret | Top Secret | Reserved" + + Compartments [0..65535] + + Handling [0..65535] + + TCC [0..16777216] + + --> + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ENTITY % Digits "CDATA"> + <!ENTITY % Precedence "CDATA"> + <!ENTITY % IP4Addr "CDATA"> + <!ENTITY % Class "CDATA"> + <!ENTITY % Sec "CDATA"> + <!ENTITY % Compartments "CDATA"> + <!ENTITY % Handling "CDATA"> + <!ENTITY % TCC "CDATA"> + + <!ELEMENT ip (header, payload)> + + <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl, + protocol, checksum, source, destination, options, + padding)> + <!-- length of header in 32-bit words --> + <!ATTLIST header + length %Digits; #REQUIRED> + + <!ELEMENT version EMPTY> + <!-- ip version. SHOULD be "4" --> + <!ATTLIST version + value %Digits; #REQUIRED> + + <!ELEMENT tos EMPTY> + <!ATTLIST tos + precedence %Precedence; #REQUIRED + delay (normal | low) #REQUIRED + throughput (normal | high) #REQUIRED + relibility (normal | high) #REQUIRED + reserved CDATA #FIXED "0"> + + <!ELEMENT total.length EMPTY> + <!-- + total length of datagram (header and payload) in octets, MUST be + less than 65,535 (and SHOULD be less than 1024 for IPoXML on local + ethernets). + --> + <!ATTLIST total.length + value %Digits; #REQUIRED> + + <!ELEMENT id EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST id + value %Digits; #REQUIRED> + + <!ELEMENT flags EMPTY> + <!-- df = don't fragment, mf = more fragments --> + <!ATTLIST flags + + + +Kennedy Informational [Page 8] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + reserved CDATA #FIXED "0" + df (may|dont) #REQUIRED + mf (last|more) #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks --> + <!ATTLIST offset + value %Digits; #REQUIRED> + + <!ELEMENT ttl EMPTY> + <!-- 0 <= ttl <= 255 --> + <!ATTLIST ttl + value %Digits; #REQUIRED> + + <!ELEMENT protocol EMPTY> + <!-- 0 <= protocol <= 255 (per IANA) --> + <!ATTLIST protocol + value %Digits; #REQUIRED> + + <!ELEMENT checksum EMPTY> + <!-- 0 <= checksum <= 65535 (over header only) --> + <!ATTLIST checksum + value %Digits; #REQUIRED> + + <!ELEMENT source EMPTY> + <!ATTLIST source + address %IP4Addr; #REQUIRED> + + <!ELEMENT destination EMPTY> + <!ATTLIST destination + address %IP4Addr; #REQUIRED> + + <!ELEMENT options ( end | noop | security | loose | strict | record + | stream | timestamp )*> + + <!ELEMENT end EMPTY> + <!ATTLIST end + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "0"> + + <!ELEMENT noop EMPTY> + <!ATTLIST noop + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "1"> + + <!ELEMENT security EMPTY> + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST security + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "2" + length CDATA #FIXED "11" + security %Sec; #REQUIRED + compartments %Compartments; #REQUIRED + handling %Handling; #REQUIRED + tcc %TCC; #REQUIRED> + <!ELEMENT loose (hop)+> + <!ATTLIST loose + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "3" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT hop EMPTY> + <!ATTLIST hop + address %IP4Addr; #REQUIRED> + + <!ELEMENT strict (hop)+> + <!ATTLIST strict + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "9" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT record (hop)+> + <!ATTLIST record + copied CDATA #FIXED "0" + class CDATA #FIXED "0" + number CDATA #FIXED "7" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT stream EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST stream + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "8" + length CDATA #FIXED "4" + id %Digits; #REQUIRED> + + <!ELEMENT timestamp (tstamp)+> + <!-- 0 <= oflw <=15 --> + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST timestamp + copied CDATA #FIXED "0" + class CDATA #FIXED "2" + number CDATA #FIXED "4" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED + oflw %Digits; #REQUIRED + flag (0 | 1 | 3) #REQUIRED> + + <!ELEMENT tstamp EMPTY> + <!ATTLIST tstamp + time %Digits; #REQUIRED + address %IP4Addr; #IMPLIED> + <!-- + padding to bring header to 32-bit boundary. + pad MUST be "0"* + --> + <!ELEMENT padding EMPTY> + <!ATTLIST padding + pad CDATA #REQUIRED> + + <!-- payload MUST be encoded as base-64 [RFC2045], as modified + by section 2.1 of this RFC --> + <!ELEMENT payload (CDATA)> + +7.2. TCPoXML DTD + + <!-- + DTD for TCP over XML. + Refer to this DTD as: + + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + --> + + <!-- the pseudoheader is only included for checksum calculations --> + <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)> + + <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset, + reserved, control, window, checksum, urgent, + tcp.options, padding)> + + <!ELEMENT src EMPTY> + <!-- 0 <= port <= 65,535 --> + <!ATTLIST src + port %Digits; #REQUIRED> + + <!ELEMENT dest EMPTY> + <!-- 0 <= port <= 65,535 --> + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST dest + port %Digits; #REQUIRED> + + <!ELEMENT sequence EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST sequence + number %Digits; #REQUIRED> + + <!ELEMENT acknowledgement EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST acknowledgement + number %Digits; #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= number <= 255 --> + <!ATTLIST offset + number %Digits; #REQUIRED> + + <!ELEMENT reserved EMPTY> + <!ATTLIST reserved + value CDATA #FIXED "0"> + + <!ELEMENT control EMPTY> + <!ATTLIST control + urg (0|1) #IMPLIED + ack (0|1) #IMPLIED + psh (0|1) #IMPLIED + rst (0|1) #IMPLIED + syn (0|1) #IMPLIED + fin (0|1) #IMPLIED> + + <!ELEMENT window EMPTY> + <!-- 0 <= size <= 65,535 --> + <!ATTLIST window + size %Digits; #REQUIRED> + + <!-- + checksum as in ip, but with + the following pseudo-header added into the tcp element: + --> + <!ELEMENT tcp.pseudoheader (source, destination, protocol, + tcp.length)> + + <!-- + tcp header + data length in octets. does not include the size of + + the pseudoheader. + --> + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ELEMENT tcp.length EMPTY> + <!ATTLIST tcp.length + value %Digits; #REQUIRED> + + <!ELEMENT urgent EMPTY> + <!-- 0 <= pointer <= 65,535 --> + <!ATTLIST urgent + pointer %Digits; #REQUIRED> + + <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+> + + <!ELEMENT tcp.end EMPTY> + <!ATTLIST tcp.end + kind CDATA #FIXED "0"> + + <!ELEMENT tcp.noop EMPTY> + <!ATTLIST tcp.noop + kind CDATA #FIXED "1"> + + <!ELEMENT tcp.mss EMPTY> + <!ATTLIST tcp.mss + kind CDATA #FIXED "2" + length CDATA #FIXED "4" + size %Digits; #REQUIRED> + +7.3. UDPoXML DTD + + <!-- + DTD for UDP over XML. + Refer to this DTD as: + + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + --> + + <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)> + + <!ELEMENT udp.header (src, dest, udp.length, checksum)> + + <!ELEMENT udp.pseudoheader (source, destination, protocol, + udp.length)> + + <!-- + udp header + data length in octets. does not include the size of + the pseudoheader. + --> + <!ELEMENT udp.length EMPTY> + <!ATTLIST udp.length + value %Digits; #REQUIRED> + + + +Kennedy Informational [Page 13] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +8. Security Considerations + + XML, as a subset of SGML, has the same security considerations as + specified in SGML Media Types [RFC1874]. Security considerations + that apply to IP, TCP and UDP also likely apply to BLOAT as it does + not attempt to correct for issues not related to message format. + +9. References + + [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt, + February 2002. (Work in Progress) + + [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC894] Hornig, C., "Standard for the Transmission of IP + Datagrams over Ethernet Networks.", RFC 894, April 1984. + + [RFC1042] Postel, J. and J. Reynolds, "Standard for the + Transmission of IP Datagrams Over IEEE 802 Networks", STD + 43, RFC 1042, February 1988. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", RFC 1123, October 1989. + + [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December + 1995. + + [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, + October 1996. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + + + + +Kennedy Informational [Page 14] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", + RFC 3080, March 2001. + + [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., + Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D., + "Simple Object Access Protocol (SOAP) 1.1" World Wide Web + Consortium Note, May 2000 http://www.w3.org/TR/SOAP/ + + [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible + Markup Language (XML)" World Wide Web Consortium + Recommendation REC- xml-19980210. + http://www.w3.org/TR/1998/REC-xml-19980210 + +10. Author's Address + + Hugh Kennedy + Mimezine + 1060 West Addison + Chicago, IL 60613 + USA + + EMail: kennedyh@engin.umich.edu + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 15] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 16] + + + + + + + +Network Working Group H. Kennedy +Request for Comments: 3252 Mimezine +Category: Informational 1 April 2002 + + + Binary Lexical Octet Ad-hoc Transport + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document defines a reformulation of IP and two transport layer + protocols (TCP and UDP) as XML applications. + +1. Introduction + +1.1. Overview + + This document describes the Binary Lexical Octet Ad-hoc Transport + (BLOAT): a reformulation of a widely-deployed network-layer protocol + (IP [RFC791]), and two associated transport layer protocols (TCP + [RFC793] and UDP [RFC768]) as XML [XML] applications. It also + describes methods for transporting BLOAT over Ethernet and IEEE 802 + networks as well as encapsulating BLOAT in IP for gatewaying BLOAT + across the public Internet. + +1.2. Motivation + + The wild popularity of XML as a basis for application-level protocols + such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple + Object Access Protocol [SOAP], and Jabber [JABBER] prompted + investigation into the possibility of extending the use of XML in the + protocol stack. Using XML at both the transport and network layer in + addition to the application layer would provide for an amazing amount + of power and flexibility while removing dependencies on proprietary + and hard-to-understand binary protocols. This protocol unification + would also allow applications to use a single XML parser for all + aspects of their operation, eliminating developer time spent figuring + out the intricacies of each new protocol, and moving the hard work of + + + + +Kennedy Informational [Page 1] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + parsing to the XML toolset. The use of XML also mitigates concerns + over "network vs. host" byte ordering which is at the root of many + network application bugs. + +1.3. Relation to Existing Protocols + + The reformulations specified in this RFC follow as closely as + possible the spirit of the RFCs on which they are based, and so MAY + contain elements or attributes that would not be needed in a pure + reworking (e.g. length attributes, which are implicit in XML.) + + The layering of network and transport protocols are maintained in + this RFC despite the optimizations that could be made if the line + were somewhat blurred (i.e. merging TCP and IP into a single, larger + element in the DTD) in order to foster future use of this protocol as + a basis for reformulating other protocols (such as ICMP.) + + Other than the encoding, the behavioral aspects of each of the + existing protocols remain unchanged. Routing, address spaces, TCP + congestion control, etc. behave as specified in the extant standards. + Adapting to new standards and experimental algorithm heuristics for + improving performance will become much easier once the move to BLOAT + has been completed. + +1.4. Requirement Levels + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 + [RFC2119]. + +2. IPoXML + + This protocol MUST be implemented to be compliant with this RFC. + IPoXML is the root protocol REQUIRED for effective use of TCPoXML + (section 3.) and higher-level application protocols. + + The DTD for this document type can be found in section 7.1. + + The routing of IPoXML can be easily implemented on hosts with an XML + parser, as the regular structure lends itself handily to parsing and + validation of the document/datagram and then processing the + destination address, TTL, and checksum before sending it on to its + next-hop. + + The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the + wider deployment of IPv4 and the fact that implementing IPv6 as XML + would have exceeded the 1500 byte Ethernet MTU. + + + +Kennedy Informational [Page 2] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + All BLOAT implementations MUST use - and specify - the UTF-8 encoding + of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well- + formed and include the XMLDecl. + +2.1. IP Description + + A number of items have changed (for the better) from the original IP + specification. Bit-masks, where present have been converted into + human-readable values. IP addresses are listed in their dotted- + decimal notation [RFC1123]. Length and checksum values are present + as decimal integers. + + To calculate the length and checksum fields of the IP element, a + canonicalized form of the element MUST be used. The canonical form + SHALL have no whitespace (including newline characters) between + elements and only one space character between attributes. There + SHALL NOT be a space following the last attribute in an element. + + An iterative method SHOULD be used to calculate checksums, as the + length field will vary based on the size of the checksum. + + The payload element bears special attention. Due to the character + set restrictions of XML, the payload of IP datagrams (which MAY + contain arbitrary data) MUST be encoded for transport. This RFC + REQUIRES the contents of the payload to be encoded in the base-64 + encoding of RFC 2045 [RFC2045], but removes the requirement that the + encoded output MUST be wrapped on 76-character lines. + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 3] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +2.2. Example Datagram + + The following is an example IPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + <ip> + <header length="474"> + <version value="4"/> + <tos precedence="Routine" delay="Normal" throughput="Normal" + relibility="Normal" reserved="0"/> + <total.length value="461"/> + <id value="1"/> + <flags reserved="0" df="dont" mf="last"/> + <offset value="0"/> + <ttl value="255"/> + <protocol value="6"/> + <checksum value="8707"/> + <source address="10.0.0.22"/> + <destination address="10.0.0.1"/> + <options> + <end copied="0" class="0" number="0"/> + </options> + <padding pad="0"/> + </header> + <payload> + </payload> + </ip> + +3. TCPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.2. + +3.1. TCP Description + + A number of items have changed from the original TCP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + To calculate the length and checksum fields of the TCP element, a + canonicalized form of the element MUST be used as in section 2.1. + + An iterative method SHOULD be used to calculate checksums as in + section 2.1. + + The payload element MUST be encoded as in section 2.1. + + + +Kennedy Informational [Page 4] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + The TCP offset element was expanded to a maximum of 255 from 16 to + allow for the increased size of the header in XML. + + TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + <tcp> + <tcp.header> + <src port="31415"/> + <dest port="42424"/> + <sequence number="322622954"/> + <acknowledgement number="689715995"/> + <offset number=""/> + <reserved value="0"/> + <control syn="1" ack="1"/> + <window size="1"/> + <urgent pointer="0"/> + <checksum value="2988"/> + <tcp.options> + <tcp.end kind="0"/> + </tcp.options> + <padding pad="0"/> + </tcp.header> + <payload> + </payload> + </tcp> + +4. UDPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.3. + +4.1. UDP Description + + A number of items have changed from the original UDP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + + + + + + +Kennedy Informational [Page 5] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + To calculate the length and checksum fields of the UDP element, a + canonicalized form of the element MUST be used as in section 2.1. An + iterative method SHOULD be used to calculate checksums as in section + 2.1. + + The payload element MUST be encoded as in section 2.1. + + UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + <udp> + <udp.header> + <src port="31415"/> + <dest port="42424"/> + <udp.length value="143"/> + <checksum value="2988"/> + </udp.header> + <payload> + </payload> + </udp> + +5. Network Transport + + This document provides for the transmission of BLOAT datagrams over + two common families of physical layer transport. Future RFCs will + address additional transports as routing vendors catch up to the + specification, and we begin to see BLOAT routed across the Internet + backbone. + +5.1. Ethernet + + BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the + exception that the type field of the Ethernet frame MUST contain the + value 0xBEEF. The first 5 octets of the Ethernet frame payload will + be 0x3c 3f 78 6d 6c ("<?xml".) + +5.2. IEEE 802 + + BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except + that the protocol type code for IPoXML is 0xBEEF. + + + + + +Kennedy Informational [Page 6] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +6. Gatewaying over IP + + In order to facilitate the gradual introduction of BLOAT into the + public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to + gateway between networks that run BLOAT natively on their LANs. + +7. DTDs + + The Transport DTDs (7.2. and 7.3.) build on the definitions in the + Network DTD (7.1.) + + The DTDs are referenced by their PubidLiteral and SystemLiteral (from + [XML]) although it is understood that most IPoXML implementations + will not need to pull down the DTD, as it will normally be embedded + in the implementation, and presents something of a catch-22 if you + need to load part of your network protocol over the network. + +7.1. IPoXML DTD + + <!-- + DTD for IP over XML. + Refer to this DTD as: + + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + --> + <!-- + DTD data types: + + Digits [0..9]+ + + Precedence "NetworkControl | InternetworkControl | + CRITIC | FlashOverride | Flash | Immediate | + Priority | Routine" + + IP4Addr "dotted-decimal" notation of [RFC1123] + + Class [0..3] + + Sec "Unclassified | Confidential | EFTO | MMMM | PROG | + Restricted | Secret | Top Secret | Reserved" + + Compartments [0..65535] + + Handling [0..65535] + + TCC [0..16777216] + + --> + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ENTITY % Digits "CDATA"> + <!ENTITY % Precedence "CDATA"> + <!ENTITY % IP4Addr "CDATA"> + <!ENTITY % Class "CDATA"> + <!ENTITY % Sec "CDATA"> + <!ENTITY % Compartments "CDATA"> + <!ENTITY % Handling "CDATA"> + <!ENTITY % TCC "CDATA"> + + <!ELEMENT ip (header, payload)> + + <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl, + protocol, checksum, source, destination, options, + padding)> + <!-- length of header in 32-bit words --> + <!ATTLIST header + length %Digits; #REQUIRED> + + <!ELEMENT version EMPTY> + <!-- ip version. SHOULD be "4" --> + <!ATTLIST version + value %Digits; #REQUIRED> + + <!ELEMENT tos EMPTY> + <!ATTLIST tos + precedence %Precedence; #REQUIRED + delay (normal | low) #REQUIRED + throughput (normal | high) #REQUIRED + relibility (normal | high) #REQUIRED + reserved CDATA #FIXED "0"> + + <!ELEMENT total.length EMPTY> + <!-- + total length of datagram (header and payload) in octets, MUST be + less than 65,535 (and SHOULD be less than 1024 for IPoXML on local + ethernets). + --> + <!ATTLIST total.length + value %Digits; #REQUIRED> + + <!ELEMENT id EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST id + value %Digits; #REQUIRED> + + <!ELEMENT flags EMPTY> + <!-- df = don't fragment, mf = more fragments --> + <!ATTLIST flags + + + +Kennedy Informational [Page 8] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + reserved CDATA #FIXED "0" + df (may|dont) #REQUIRED + mf (last|more) #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks --> + <!ATTLIST offset + value %Digits; #REQUIRED> + + <!ELEMENT ttl EMPTY> + <!-- 0 <= ttl <= 255 --> + <!ATTLIST ttl + value %Digits; #REQUIRED> + + <!ELEMENT protocol EMPTY> + <!-- 0 <= protocol <= 255 (per IANA) --> + <!ATTLIST protocol + value %Digits; #REQUIRED> + + <!ELEMENT checksum EMPTY> + <!-- 0 <= checksum <= 65535 (over header only) --> + <!ATTLIST checksum + value %Digits; #REQUIRED> + + <!ELEMENT source EMPTY> + <!ATTLIST source + address %IP4Addr; #REQUIRED> + + <!ELEMENT destination EMPTY> + <!ATTLIST destination + address %IP4Addr; #REQUIRED> + + <!ELEMENT options ( end | noop | security | loose | strict | record + | stream | timestamp )*> + + <!ELEMENT end EMPTY> + <!ATTLIST end + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "0"> + + <!ELEMENT noop EMPTY> + <!ATTLIST noop + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "1"> + + <!ELEMENT security EMPTY> + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST security + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "2" + length CDATA #FIXED "11" + security %Sec; #REQUIRED + compartments %Compartments; #REQUIRED + handling %Handling; #REQUIRED + tcc %TCC; #REQUIRED> + <!ELEMENT loose (hop)+> + <!ATTLIST loose + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "3" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT hop EMPTY> + <!ATTLIST hop + address %IP4Addr; #REQUIRED> + + <!ELEMENT strict (hop)+> + <!ATTLIST strict + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "9" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT record (hop)+> + <!ATTLIST record + copied CDATA #FIXED "0" + class CDATA #FIXED "0" + number CDATA #FIXED "7" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT stream EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST stream + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "8" + length CDATA #FIXED "4" + id %Digits; #REQUIRED> + + <!ELEMENT timestamp (tstamp)+> + <!-- 0 <= oflw <=15 --> + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST timestamp + copied CDATA #FIXED "0" + class CDATA #FIXED "2" + number CDATA #FIXED "4" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED + oflw %Digits; #REQUIRED + flag (0 | 1 | 3) #REQUIRED> + + <!ELEMENT tstamp EMPTY> + <!ATTLIST tstamp + time %Digits; #REQUIRED + address %IP4Addr; #IMPLIED> + <!-- + padding to bring header to 32-bit boundary. + pad MUST be "0"* + --> + <!ELEMENT padding EMPTY> + <!ATTLIST padding + pad CDATA #REQUIRED> + + <!-- payload MUST be encoded as base-64 [RFC2045], as modified + by section 2.1 of this RFC --> + <!ELEMENT payload (CDATA)> + +7.2. TCPoXML DTD + + <!-- + DTD for TCP over XML. + Refer to this DTD as: + + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + --> + + <!-- the pseudoheader is only included for checksum calculations --> + <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)> + + <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset, + reserved, control, window, checksum, urgent, + tcp.options, padding)> + + <!ELEMENT src EMPTY> + <!-- 0 <= port <= 65,535 --> + <!ATTLIST src + port %Digits; #REQUIRED> + + <!ELEMENT dest EMPTY> + <!-- 0 <= port <= 65,535 --> + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST dest + port %Digits; #REQUIRED> + + <!ELEMENT sequence EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST sequence + number %Digits; #REQUIRED> + + <!ELEMENT acknowledgement EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST acknowledgement + number %Digits; #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= number <= 255 --> + <!ATTLIST offset + number %Digits; #REQUIRED> + + <!ELEMENT reserved EMPTY> + <!ATTLIST reserved + value CDATA #FIXED "0"> + + <!ELEMENT control EMPTY> + <!ATTLIST control + urg (0|1) #IMPLIED + ack (0|1) #IMPLIED + psh (0|1) #IMPLIED + rst (0|1) #IMPLIED + syn (0|1) #IMPLIED + fin (0|1) #IMPLIED> + + <!ELEMENT window EMPTY> + <!-- 0 <= size <= 65,535 --> + <!ATTLIST window + size %Digits; #REQUIRED> + + <!-- + checksum as in ip, but with + the following pseudo-header added into the tcp element: + --> + <!ELEMENT tcp.pseudoheader (source, destination, protocol, + tcp.length)> + + <!-- + tcp header + data length in octets. does not include the size of + + the pseudoheader. + --> + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ELEMENT tcp.length EMPTY> + <!ATTLIST tcp.length + value %Digits; #REQUIRED> + + <!ELEMENT urgent EMPTY> + <!-- 0 <= pointer <= 65,535 --> + <!ATTLIST urgent + pointer %Digits; #REQUIRED> + + <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+> + + <!ELEMENT tcp.end EMPTY> + <!ATTLIST tcp.end + kind CDATA #FIXED "0"> + + <!ELEMENT tcp.noop EMPTY> + <!ATTLIST tcp.noop + kind CDATA #FIXED "1"> + + <!ELEMENT tcp.mss EMPTY> + <!ATTLIST tcp.mss + kind CDATA #FIXED "2" + length CDATA #FIXED "4" + size %Digits; #REQUIRED> + +7.3. UDPoXML DTD + + <!-- + DTD for UDP over XML. + Refer to this DTD as: + + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + --> + + <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)> + + <!ELEMENT udp.header (src, dest, udp.length, checksum)> + + <!ELEMENT udp.pseudoheader (source, destination, protocol, + udp.length)> + + <!-- + udp header + data length in octets. does not include the size of + the pseudoheader. + --> + <!ELEMENT udp.length EMPTY> + <!ATTLIST udp.length + value %Digits; #REQUIRED> + + + +Kennedy Informational [Page 13] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +8. Security Considerations + + XML, as a subset of SGML, has the same security considerations as + specified in SGML Media Types [RFC1874]. Security considerations + that apply to IP, TCP and UDP also likely apply to BLOAT as it does + not attempt to correct for issues not related to message format. + +9. References + + [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt, + February 2002. (Work in Progress) + + [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC894] Hornig, C., "Standard for the Transmission of IP + Datagrams over Ethernet Networks.", RFC 894, April 1984. + + [RFC1042] Postel, J. and J. Reynolds, "Standard for the + Transmission of IP Datagrams Over IEEE 802 Networks", STD + 43, RFC 1042, February 1988. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", RFC 1123, October 1989. + + [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December + 1995. + + [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, + October 1996. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + + + + +Kennedy Informational [Page 14] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", + RFC 3080, March 2001. + + [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., + Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D., + "Simple Object Access Protocol (SOAP) 1.1" World Wide Web + Consortium Note, May 2000 http://www.w3.org/TR/SOAP/ + + [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible + Markup Language (XML)" World Wide Web Consortium + Recommendation REC- xml-19980210. + http://www.w3.org/TR/1998/REC-xml-19980210 + +10. Author's Address + + Hugh Kennedy + Mimezine + 1060 West Addison + Chicago, IL 60613 + USA + + EMail: kennedyh@engin.umich.edu + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 15] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 16] + + + + + + + +Network Working Group H. Kennedy +Request for Comments: 3252 Mimezine +Category: Informational 1 April 2002 + + + Binary Lexical Octet Ad-hoc Transport + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document defines a reformulation of IP and two transport layer + protocols (TCP and UDP) as XML applications. + +1. Introduction + +1.1. Overview + + This document describes the Binary Lexical Octet Ad-hoc Transport + (BLOAT): a reformulation of a widely-deployed network-layer protocol + (IP [RFC791]), and two associated transport layer protocols (TCP + [RFC793] and UDP [RFC768]) as XML [XML] applications. It also + describes methods for transporting BLOAT over Ethernet and IEEE 802 + networks as well as encapsulating BLOAT in IP for gatewaying BLOAT + across the public Internet. + +1.2. Motivation + + The wild popularity of XML as a basis for application-level protocols + such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple + Object Access Protocol [SOAP], and Jabber [JABBER] prompted + investigation into the possibility of extending the use of XML in the + protocol stack. Using XML at both the transport and network layer in + addition to the application layer would provide for an amazing amount + of power and flexibility while removing dependencies on proprietary + and hard-to-understand binary protocols. This protocol unification + would also allow applications to use a single XML parser for all + aspects of their operation, eliminating developer time spent figuring + out the intricacies of each new protocol, and moving the hard work of + + + + +Kennedy Informational [Page 1] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + parsing to the XML toolset. The use of XML also mitigates concerns + over "network vs. host" byte ordering which is at the root of many + network application bugs. + +1.3. Relation to Existing Protocols + + The reformulations specified in this RFC follow as closely as + possible the spirit of the RFCs on which they are based, and so MAY + contain elements or attributes that would not be needed in a pure + reworking (e.g. length attributes, which are implicit in XML.) + + The layering of network and transport protocols are maintained in + this RFC despite the optimizations that could be made if the line + were somewhat blurred (i.e. merging TCP and IP into a single, larger + element in the DTD) in order to foster future use of this protocol as + a basis for reformulating other protocols (such as ICMP.) + + Other than the encoding, the behavioral aspects of each of the + existing protocols remain unchanged. Routing, address spaces, TCP + congestion control, etc. behave as specified in the extant standards. + Adapting to new standards and experimental algorithm heuristics for + improving performance will become much easier once the move to BLOAT + has been completed. + +1.4. Requirement Levels + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 + [RFC2119]. + +2. IPoXML + + This protocol MUST be implemented to be compliant with this RFC. + IPoXML is the root protocol REQUIRED for effective use of TCPoXML + (section 3.) and higher-level application protocols. + + The DTD for this document type can be found in section 7.1. + + The routing of IPoXML can be easily implemented on hosts with an XML + parser, as the regular structure lends itself handily to parsing and + validation of the document/datagram and then processing the + destination address, TTL, and checksum before sending it on to its + next-hop. + + The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the + wider deployment of IPv4 and the fact that implementing IPv6 as XML + would have exceeded the 1500 byte Ethernet MTU. + + + +Kennedy Informational [Page 2] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + All BLOAT implementations MUST use - and specify - the UTF-8 encoding + of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well- + formed and include the XMLDecl. + +2.1. IP Description + + A number of items have changed (for the better) from the original IP + specification. Bit-masks, where present have been converted into + human-readable values. IP addresses are listed in their dotted- + decimal notation [RFC1123]. Length and checksum values are present + as decimal integers. + + To calculate the length and checksum fields of the IP element, a + canonicalized form of the element MUST be used. The canonical form + SHALL have no whitespace (including newline characters) between + elements and only one space character between attributes. There + SHALL NOT be a space following the last attribute in an element. + + An iterative method SHOULD be used to calculate checksums, as the + length field will vary based on the size of the checksum. + + The payload element bears special attention. Due to the character + set restrictions of XML, the payload of IP datagrams (which MAY + contain arbitrary data) MUST be encoded for transport. This RFC + REQUIRES the contents of the payload to be encoded in the base-64 + encoding of RFC 2045 [RFC2045], but removes the requirement that the + encoded output MUST be wrapped on 76-character lines. + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 3] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +2.2. Example Datagram + + The following is an example IPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + <ip> + <header length="474"> + <version value="4"/> + <tos precedence="Routine" delay="Normal" throughput="Normal" + relibility="Normal" reserved="0"/> + <total.length value="461"/> + <id value="1"/> + <flags reserved="0" df="dont" mf="last"/> + <offset value="0"/> + <ttl value="255"/> + <protocol value="6"/> + <checksum value="8707"/> + <source address="10.0.0.22"/> + <destination address="10.0.0.1"/> + <options> + <end copied="0" class="0" number="0"/> + </options> + <padding pad="0"/> + </header> + <payload> + </payload> + </ip> + +3. TCPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.2. + +3.1. TCP Description + + A number of items have changed from the original TCP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + To calculate the length and checksum fields of the TCP element, a + canonicalized form of the element MUST be used as in section 2.1. + + An iterative method SHOULD be used to calculate checksums as in + section 2.1. + + The payload element MUST be encoded as in section 2.1. + + + +Kennedy Informational [Page 4] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + The TCP offset element was expanded to a maximum of 255 from 16 to + allow for the increased size of the header in XML. + + TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + <tcp> + <tcp.header> + <src port="31415"/> + <dest port="42424"/> + <sequence number="322622954"/> + <acknowledgement number="689715995"/> + <offset number=""/> + <reserved value="0"/> + <control syn="1" ack="1"/> + <window size="1"/> + <urgent pointer="0"/> + <checksum value="2988"/> + <tcp.options> + <tcp.end kind="0"/> + </tcp.options> + <padding pad="0"/> + </tcp.header> + <payload> + </payload> + </tcp> + +4. UDPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.3. + +4.1. UDP Description + + A number of items have changed from the original UDP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + + + + + + +Kennedy Informational [Page 5] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + To calculate the length and checksum fields of the UDP element, a + canonicalized form of the element MUST be used as in section 2.1. An + iterative method SHOULD be used to calculate checksums as in section + 2.1. + + The payload element MUST be encoded as in section 2.1. + + UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + <udp> + <udp.header> + <src port="31415"/> + <dest port="42424"/> + <udp.length value="143"/> + <checksum value="2988"/> + </udp.header> + <payload> + </payload> + </udp> + +5. Network Transport + + This document provides for the transmission of BLOAT datagrams over + two common families of physical layer transport. Future RFCs will + address additional transports as routing vendors catch up to the + specification, and we begin to see BLOAT routed across the Internet + backbone. + +5.1. Ethernet + + BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the + exception that the type field of the Ethernet frame MUST contain the + value 0xBEEF. The first 5 octets of the Ethernet frame payload will + be 0x3c 3f 78 6d 6c ("<?xml".) + +5.2. IEEE 802 + + BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except + that the protocol type code for IPoXML is 0xBEEF. + + + + + +Kennedy Informational [Page 6] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +6. Gatewaying over IP + + In order to facilitate the gradual introduction of BLOAT into the + public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to + gateway between networks that run BLOAT natively on their LANs. + +7. DTDs + + The Transport DTDs (7.2. and 7.3.) build on the definitions in the + Network DTD (7.1.) + + The DTDs are referenced by their PubidLiteral and SystemLiteral (from + [XML]) although it is understood that most IPoXML implementations + will not need to pull down the DTD, as it will normally be embedded + in the implementation, and presents something of a catch-22 if you + need to load part of your network protocol over the network. + +7.1. IPoXML DTD + + <!-- + DTD for IP over XML. + Refer to this DTD as: + + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + --> + <!-- + DTD data types: + + Digits [0..9]+ + + Precedence "NetworkControl | InternetworkControl | + CRITIC | FlashOverride | Flash | Immediate | + Priority | Routine" + + IP4Addr "dotted-decimal" notation of [RFC1123] + + Class [0..3] + + Sec "Unclassified | Confidential | EFTO | MMMM | PROG | + Restricted | Secret | Top Secret | Reserved" + + Compartments [0..65535] + + Handling [0..65535] + + TCC [0..16777216] + + --> + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ENTITY % Digits "CDATA"> + <!ENTITY % Precedence "CDATA"> + <!ENTITY % IP4Addr "CDATA"> + <!ENTITY % Class "CDATA"> + <!ENTITY % Sec "CDATA"> + <!ENTITY % Compartments "CDATA"> + <!ENTITY % Handling "CDATA"> + <!ENTITY % TCC "CDATA"> + + <!ELEMENT ip (header, payload)> + + <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl, + protocol, checksum, source, destination, options, + padding)> + <!-- length of header in 32-bit words --> + <!ATTLIST header + length %Digits; #REQUIRED> + + <!ELEMENT version EMPTY> + <!-- ip version. SHOULD be "4" --> + <!ATTLIST version + value %Digits; #REQUIRED> + + <!ELEMENT tos EMPTY> + <!ATTLIST tos + precedence %Precedence; #REQUIRED + delay (normal | low) #REQUIRED + throughput (normal | high) #REQUIRED + relibility (normal | high) #REQUIRED + reserved CDATA #FIXED "0"> + + <!ELEMENT total.length EMPTY> + <!-- + total length of datagram (header and payload) in octets, MUST be + less than 65,535 (and SHOULD be less than 1024 for IPoXML on local + ethernets). + --> + <!ATTLIST total.length + value %Digits; #REQUIRED> + + <!ELEMENT id EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST id + value %Digits; #REQUIRED> + + <!ELEMENT flags EMPTY> + <!-- df = don't fragment, mf = more fragments --> + <!ATTLIST flags + + + +Kennedy Informational [Page 8] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + reserved CDATA #FIXED "0" + df (may|dont) #REQUIRED + mf (last|more) #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks --> + <!ATTLIST offset + value %Digits; #REQUIRED> + + <!ELEMENT ttl EMPTY> + <!-- 0 <= ttl <= 255 --> + <!ATTLIST ttl + value %Digits; #REQUIRED> + + <!ELEMENT protocol EMPTY> + <!-- 0 <= protocol <= 255 (per IANA) --> + <!ATTLIST protocol + value %Digits; #REQUIRED> + + <!ELEMENT checksum EMPTY> + <!-- 0 <= checksum <= 65535 (over header only) --> + <!ATTLIST checksum + value %Digits; #REQUIRED> + + <!ELEMENT source EMPTY> + <!ATTLIST source + address %IP4Addr; #REQUIRED> + + <!ELEMENT destination EMPTY> + <!ATTLIST destination + address %IP4Addr; #REQUIRED> + + <!ELEMENT options ( end | noop | security | loose | strict | record + | stream | timestamp )*> + + <!ELEMENT end EMPTY> + <!ATTLIST end + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "0"> + + <!ELEMENT noop EMPTY> + <!ATTLIST noop + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "1"> + + <!ELEMENT security EMPTY> + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST security + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "2" + length CDATA #FIXED "11" + security %Sec; #REQUIRED + compartments %Compartments; #REQUIRED + handling %Handling; #REQUIRED + tcc %TCC; #REQUIRED> + <!ELEMENT loose (hop)+> + <!ATTLIST loose + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "3" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT hop EMPTY> + <!ATTLIST hop + address %IP4Addr; #REQUIRED> + + <!ELEMENT strict (hop)+> + <!ATTLIST strict + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "9" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT record (hop)+> + <!ATTLIST record + copied CDATA #FIXED "0" + class CDATA #FIXED "0" + number CDATA #FIXED "7" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT stream EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST stream + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "8" + length CDATA #FIXED "4" + id %Digits; #REQUIRED> + + <!ELEMENT timestamp (tstamp)+> + <!-- 0 <= oflw <=15 --> + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST timestamp + copied CDATA #FIXED "0" + class CDATA #FIXED "2" + number CDATA #FIXED "4" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED + oflw %Digits; #REQUIRED + flag (0 | 1 | 3) #REQUIRED> + + <!ELEMENT tstamp EMPTY> + <!ATTLIST tstamp + time %Digits; #REQUIRED + address %IP4Addr; #IMPLIED> + <!-- + padding to bring header to 32-bit boundary. + pad MUST be "0"* + --> + <!ELEMENT padding EMPTY> + <!ATTLIST padding + pad CDATA #REQUIRED> + + <!-- payload MUST be encoded as base-64 [RFC2045], as modified + by section 2.1 of this RFC --> + <!ELEMENT payload (CDATA)> + +7.2. TCPoXML DTD + + <!-- + DTD for TCP over XML. + Refer to this DTD as: + + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + --> + + <!-- the pseudoheader is only included for checksum calculations --> + <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)> + + <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset, + reserved, control, window, checksum, urgent, + tcp.options, padding)> + + <!ELEMENT src EMPTY> + <!-- 0 <= port <= 65,535 --> + <!ATTLIST src + port %Digits; #REQUIRED> + + <!ELEMENT dest EMPTY> + <!-- 0 <= port <= 65,535 --> + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST dest + port %Digits; #REQUIRED> + + <!ELEMENT sequence EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST sequence + number %Digits; #REQUIRED> + + <!ELEMENT acknowledgement EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST acknowledgement + number %Digits; #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= number <= 255 --> + <!ATTLIST offset + number %Digits; #REQUIRED> + + <!ELEMENT reserved EMPTY> + <!ATTLIST reserved + value CDATA #FIXED "0"> + + <!ELEMENT control EMPTY> + <!ATTLIST control + urg (0|1) #IMPLIED + ack (0|1) #IMPLIED + psh (0|1) #IMPLIED + rst (0|1) #IMPLIED + syn (0|1) #IMPLIED + fin (0|1) #IMPLIED> + + <!ELEMENT window EMPTY> + <!-- 0 <= size <= 65,535 --> + <!ATTLIST window + size %Digits; #REQUIRED> + + <!-- + checksum as in ip, but with + the following pseudo-header added into the tcp element: + --> + <!ELEMENT tcp.pseudoheader (source, destination, protocol, + tcp.length)> + + <!-- + tcp header + data length in octets. does not include the size of + + the pseudoheader. + --> + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ELEMENT tcp.length EMPTY> + <!ATTLIST tcp.length + value %Digits; #REQUIRED> + + <!ELEMENT urgent EMPTY> + <!-- 0 <= pointer <= 65,535 --> + <!ATTLIST urgent + pointer %Digits; #REQUIRED> + + <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+> + + <!ELEMENT tcp.end EMPTY> + <!ATTLIST tcp.end + kind CDATA #FIXED "0"> + + <!ELEMENT tcp.noop EMPTY> + <!ATTLIST tcp.noop + kind CDATA #FIXED "1"> + + <!ELEMENT tcp.mss EMPTY> + <!ATTLIST tcp.mss + kind CDATA #FIXED "2" + length CDATA #FIXED "4" + size %Digits; #REQUIRED> + +7.3. UDPoXML DTD + + <!-- + DTD for UDP over XML. + Refer to this DTD as: + + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + --> + + <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)> + + <!ELEMENT udp.header (src, dest, udp.length, checksum)> + + <!ELEMENT udp.pseudoheader (source, destination, protocol, + udp.length)> + + <!-- + udp header + data length in octets. does not include the size of + the pseudoheader. + --> + <!ELEMENT udp.length EMPTY> + <!ATTLIST udp.length + value %Digits; #REQUIRED> + + + +Kennedy Informational [Page 13] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +8. Security Considerations + + XML, as a subset of SGML, has the same security considerations as + specified in SGML Media Types [RFC1874]. Security considerations + that apply to IP, TCP and UDP also likely apply to BLOAT as it does + not attempt to correct for issues not related to message format. + +9. References + + [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt, + February 2002. (Work in Progress) + + [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC894] Hornig, C., "Standard for the Transmission of IP + Datagrams over Ethernet Networks.", RFC 894, April 1984. + + [RFC1042] Postel, J. and J. Reynolds, "Standard for the + Transmission of IP Datagrams Over IEEE 802 Networks", STD + 43, RFC 1042, February 1988. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", RFC 1123, October 1989. + + [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December + 1995. + + [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, + October 1996. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + + + + +Kennedy Informational [Page 14] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", + RFC 3080, March 2001. + + [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., + Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D., + "Simple Object Access Protocol (SOAP) 1.1" World Wide Web + Consortium Note, May 2000 http://www.w3.org/TR/SOAP/ + + [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible + Markup Language (XML)" World Wide Web Consortium + Recommendation REC- xml-19980210. + http://www.w3.org/TR/1998/REC-xml-19980210 + +10. Author's Address + + Hugh Kennedy + Mimezine + 1060 West Addison + Chicago, IL 60613 + USA + + EMail: kennedyh@engin.umich.edu + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 15] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 16] + + + + + + + +Network Working Group H. Kennedy +Request for Comments: 3252 Mimezine +Category: Informational 1 April 2002 + + + Binary Lexical Octet Ad-hoc Transport + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document defines a reformulation of IP and two transport layer + protocols (TCP and UDP) as XML applications. + +1. Introduction + +1.1. Overview + + This document describes the Binary Lexical Octet Ad-hoc Transport + (BLOAT): a reformulation of a widely-deployed network-layer protocol + (IP [RFC791]), and two associated transport layer protocols (TCP + [RFC793] and UDP [RFC768]) as XML [XML] applications. It also + describes methods for transporting BLOAT over Ethernet and IEEE 802 + networks as well as encapsulating BLOAT in IP for gatewaying BLOAT + across the public Internet. + +1.2. Motivation + + The wild popularity of XML as a basis for application-level protocols + such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple + Object Access Protocol [SOAP], and Jabber [JABBER] prompted + investigation into the possibility of extending the use of XML in the + protocol stack. Using XML at both the transport and network layer in + addition to the application layer would provide for an amazing amount + of power and flexibility while removing dependencies on proprietary + and hard-to-understand binary protocols. This protocol unification + would also allow applications to use a single XML parser for all + aspects of their operation, eliminating developer time spent figuring + out the intricacies of each new protocol, and moving the hard work of + + + + +Kennedy Informational [Page 1] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + parsing to the XML toolset. The use of XML also mitigates concerns + over "network vs. host" byte ordering which is at the root of many + network application bugs. + +1.3. Relation to Existing Protocols + + The reformulations specified in this RFC follow as closely as + possible the spirit of the RFCs on which they are based, and so MAY + contain elements or attributes that would not be needed in a pure + reworking (e.g. length attributes, which are implicit in XML.) + + The layering of network and transport protocols are maintained in + this RFC despite the optimizations that could be made if the line + were somewhat blurred (i.e. merging TCP and IP into a single, larger + element in the DTD) in order to foster future use of this protocol as + a basis for reformulating other protocols (such as ICMP.) + + Other than the encoding, the behavioral aspects of each of the + existing protocols remain unchanged. Routing, address spaces, TCP + congestion control, etc. behave as specified in the extant standards. + Adapting to new standards and experimental algorithm heuristics for + improving performance will become much easier once the move to BLOAT + has been completed. + +1.4. Requirement Levels + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 + [RFC2119]. + +2. IPoXML + + This protocol MUST be implemented to be compliant with this RFC. + IPoXML is the root protocol REQUIRED for effective use of TCPoXML + (section 3.) and higher-level application protocols. + + The DTD for this document type can be found in section 7.1. + + The routing of IPoXML can be easily implemented on hosts with an XML + parser, as the regular structure lends itself handily to parsing and + validation of the document/datagram and then processing the + destination address, TTL, and checksum before sending it on to its + next-hop. + + The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the + wider deployment of IPv4 and the fact that implementing IPv6 as XML + would have exceeded the 1500 byte Ethernet MTU. + + + +Kennedy Informational [Page 2] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + All BLOAT implementations MUST use - and specify - the UTF-8 encoding + of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well- + formed and include the XMLDecl. + +2.1. IP Description + + A number of items have changed (for the better) from the original IP + specification. Bit-masks, where present have been converted into + human-readable values. IP addresses are listed in their dotted- + decimal notation [RFC1123]. Length and checksum values are present + as decimal integers. + + To calculate the length and checksum fields of the IP element, a + canonicalized form of the element MUST be used. The canonical form + SHALL have no whitespace (including newline characters) between + elements and only one space character between attributes. There + SHALL NOT be a space following the last attribute in an element. + + An iterative method SHOULD be used to calculate checksums, as the + length field will vary based on the size of the checksum. + + The payload element bears special attention. Due to the character + set restrictions of XML, the payload of IP datagrams (which MAY + contain arbitrary data) MUST be encoded for transport. This RFC + REQUIRES the contents of the payload to be encoded in the base-64 + encoding of RFC 2045 [RFC2045], but removes the requirement that the + encoded output MUST be wrapped on 76-character lines. + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 3] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +2.2. Example Datagram + + The following is an example IPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + <ip> + <header length="474"> + <version value="4"/> + <tos precedence="Routine" delay="Normal" throughput="Normal" + relibility="Normal" reserved="0"/> + <total.length value="461"/> + <id value="1"/> + <flags reserved="0" df="dont" mf="last"/> + <offset value="0"/> + <ttl value="255"/> + <protocol value="6"/> + <checksum value="8707"/> + <source address="10.0.0.22"/> + <destination address="10.0.0.1"/> + <options> + <end copied="0" class="0" number="0"/> + </options> + <padding pad="0"/> + </header> + <payload> + </payload> + </ip> + +3. TCPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.2. + +3.1. TCP Description + + A number of items have changed from the original TCP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + To calculate the length and checksum fields of the TCP element, a + canonicalized form of the element MUST be used as in section 2.1. + + An iterative method SHOULD be used to calculate checksums as in + section 2.1. + + The payload element MUST be encoded as in section 2.1. + + + +Kennedy Informational [Page 4] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + The TCP offset element was expanded to a maximum of 255 from 16 to + allow for the increased size of the header in XML. + + TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + <tcp> + <tcp.header> + <src port="31415"/> + <dest port="42424"/> + <sequence number="322622954"/> + <acknowledgement number="689715995"/> + <offset number=""/> + <reserved value="0"/> + <control syn="1" ack="1"/> + <window size="1"/> + <urgent pointer="0"/> + <checksum value="2988"/> + <tcp.options> + <tcp.end kind="0"/> + </tcp.options> + <padding pad="0"/> + </tcp.header> + <payload> + </payload> + </tcp> + +4. UDPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.3. + +4.1. UDP Description + + A number of items have changed from the original UDP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + + + + + + +Kennedy Informational [Page 5] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + To calculate the length and checksum fields of the UDP element, a + canonicalized form of the element MUST be used as in section 2.1. An + iterative method SHOULD be used to calculate checksums as in section + 2.1. + + The payload element MUST be encoded as in section 2.1. + + UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + <udp> + <udp.header> + <src port="31415"/> + <dest port="42424"/> + <udp.length value="143"/> + <checksum value="2988"/> + </udp.header> + <payload> + </payload> + </udp> + +5. Network Transport + + This document provides for the transmission of BLOAT datagrams over + two common families of physical layer transport. Future RFCs will + address additional transports as routing vendors catch up to the + specification, and we begin to see BLOAT routed across the Internet + backbone. + +5.1. Ethernet + + BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the + exception that the type field of the Ethernet frame MUST contain the + value 0xBEEF. The first 5 octets of the Ethernet frame payload will + be 0x3c 3f 78 6d 6c ("<?xml".) + +5.2. IEEE 802 + + BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except + that the protocol type code for IPoXML is 0xBEEF. + + + + + +Kennedy Informational [Page 6] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +6. Gatewaying over IP + + In order to facilitate the gradual introduction of BLOAT into the + public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to + gateway between networks that run BLOAT natively on their LANs. + +7. DTDs + + The Transport DTDs (7.2. and 7.3.) build on the definitions in the + Network DTD (7.1.) + + The DTDs are referenced by their PubidLiteral and SystemLiteral (from + [XML]) although it is understood that most IPoXML implementations + will not need to pull down the DTD, as it will normally be embedded + in the implementation, and presents something of a catch-22 if you + need to load part of your network protocol over the network. + +7.1. IPoXML DTD + + <!-- + DTD for IP over XML. + Refer to this DTD as: + + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + --> + <!-- + DTD data types: + + Digits [0..9]+ + + Precedence "NetworkControl | InternetworkControl | + CRITIC | FlashOverride | Flash | Immediate | + Priority | Routine" + + IP4Addr "dotted-decimal" notation of [RFC1123] + + Class [0..3] + + Sec "Unclassified | Confidential | EFTO | MMMM | PROG | + Restricted | Secret | Top Secret | Reserved" + + Compartments [0..65535] + + Handling [0..65535] + + TCC [0..16777216] + + --> + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ENTITY % Digits "CDATA"> + <!ENTITY % Precedence "CDATA"> + <!ENTITY % IP4Addr "CDATA"> + <!ENTITY % Class "CDATA"> + <!ENTITY % Sec "CDATA"> + <!ENTITY % Compartments "CDATA"> + <!ENTITY % Handling "CDATA"> + <!ENTITY % TCC "CDATA"> + + <!ELEMENT ip (header, payload)> + + <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl, + protocol, checksum, source, destination, options, + padding)> + <!-- length of header in 32-bit words --> + <!ATTLIST header + length %Digits; #REQUIRED> + + <!ELEMENT version EMPTY> + <!-- ip version. SHOULD be "4" --> + <!ATTLIST version + value %Digits; #REQUIRED> + + <!ELEMENT tos EMPTY> + <!ATTLIST tos + precedence %Precedence; #REQUIRED + delay (normal | low) #REQUIRED + throughput (normal | high) #REQUIRED + relibility (normal | high) #REQUIRED + reserved CDATA #FIXED "0"> + + <!ELEMENT total.length EMPTY> + <!-- + total length of datagram (header and payload) in octets, MUST be + less than 65,535 (and SHOULD be less than 1024 for IPoXML on local + ethernets). + --> + <!ATTLIST total.length + value %Digits; #REQUIRED> + + <!ELEMENT id EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST id + value %Digits; #REQUIRED> + + <!ELEMENT flags EMPTY> + <!-- df = don't fragment, mf = more fragments --> + <!ATTLIST flags + + + +Kennedy Informational [Page 8] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + reserved CDATA #FIXED "0" + df (may|dont) #REQUIRED + mf (last|more) #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks --> + <!ATTLIST offset + value %Digits; #REQUIRED> + + <!ELEMENT ttl EMPTY> + <!-- 0 <= ttl <= 255 --> + <!ATTLIST ttl + value %Digits; #REQUIRED> + + <!ELEMENT protocol EMPTY> + <!-- 0 <= protocol <= 255 (per IANA) --> + <!ATTLIST protocol + value %Digits; #REQUIRED> + + <!ELEMENT checksum EMPTY> + <!-- 0 <= checksum <= 65535 (over header only) --> + <!ATTLIST checksum + value %Digits; #REQUIRED> + + <!ELEMENT source EMPTY> + <!ATTLIST source + address %IP4Addr; #REQUIRED> + + <!ELEMENT destination EMPTY> + <!ATTLIST destination + address %IP4Addr; #REQUIRED> + + <!ELEMENT options ( end | noop | security | loose | strict | record + | stream | timestamp )*> + + <!ELEMENT end EMPTY> + <!ATTLIST end + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "0"> + + <!ELEMENT noop EMPTY> + <!ATTLIST noop + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "1"> + + <!ELEMENT security EMPTY> + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST security + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "2" + length CDATA #FIXED "11" + security %Sec; #REQUIRED + compartments %Compartments; #REQUIRED + handling %Handling; #REQUIRED + tcc %TCC; #REQUIRED> + <!ELEMENT loose (hop)+> + <!ATTLIST loose + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "3" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT hop EMPTY> + <!ATTLIST hop + address %IP4Addr; #REQUIRED> + + <!ELEMENT strict (hop)+> + <!ATTLIST strict + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "9" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT record (hop)+> + <!ATTLIST record + copied CDATA #FIXED "0" + class CDATA #FIXED "0" + number CDATA #FIXED "7" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT stream EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST stream + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "8" + length CDATA #FIXED "4" + id %Digits; #REQUIRED> + + <!ELEMENT timestamp (tstamp)+> + <!-- 0 <= oflw <=15 --> + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST timestamp + copied CDATA #FIXED "0" + class CDATA #FIXED "2" + number CDATA #FIXED "4" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED + oflw %Digits; #REQUIRED + flag (0 | 1 | 3) #REQUIRED> + + <!ELEMENT tstamp EMPTY> + <!ATTLIST tstamp + time %Digits; #REQUIRED + address %IP4Addr; #IMPLIED> + <!-- + padding to bring header to 32-bit boundary. + pad MUST be "0"* + --> + <!ELEMENT padding EMPTY> + <!ATTLIST padding + pad CDATA #REQUIRED> + + <!-- payload MUST be encoded as base-64 [RFC2045], as modified + by section 2.1 of this RFC --> + <!ELEMENT payload (CDATA)> + +7.2. TCPoXML DTD + + <!-- + DTD for TCP over XML. + Refer to this DTD as: + + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + --> + + <!-- the pseudoheader is only included for checksum calculations --> + <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)> + + <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset, + reserved, control, window, checksum, urgent, + tcp.options, padding)> + + <!ELEMENT src EMPTY> + <!-- 0 <= port <= 65,535 --> + <!ATTLIST src + port %Digits; #REQUIRED> + + <!ELEMENT dest EMPTY> + <!-- 0 <= port <= 65,535 --> + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST dest + port %Digits; #REQUIRED> + + <!ELEMENT sequence EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST sequence + number %Digits; #REQUIRED> + + <!ELEMENT acknowledgement EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST acknowledgement + number %Digits; #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= number <= 255 --> + <!ATTLIST offset + number %Digits; #REQUIRED> + + <!ELEMENT reserved EMPTY> + <!ATTLIST reserved + value CDATA #FIXED "0"> + + <!ELEMENT control EMPTY> + <!ATTLIST control + urg (0|1) #IMPLIED + ack (0|1) #IMPLIED + psh (0|1) #IMPLIED + rst (0|1) #IMPLIED + syn (0|1) #IMPLIED + fin (0|1) #IMPLIED> + + <!ELEMENT window EMPTY> + <!-- 0 <= size <= 65,535 --> + <!ATTLIST window + size %Digits; #REQUIRED> + + <!-- + checksum as in ip, but with + the following pseudo-header added into the tcp element: + --> + <!ELEMENT tcp.pseudoheader (source, destination, protocol, + tcp.length)> + + <!-- + tcp header + data length in octets. does not include the size of + + the pseudoheader. + --> + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ELEMENT tcp.length EMPTY> + <!ATTLIST tcp.length + value %Digits; #REQUIRED> + + <!ELEMENT urgent EMPTY> + <!-- 0 <= pointer <= 65,535 --> + <!ATTLIST urgent + pointer %Digits; #REQUIRED> + + <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+> + + <!ELEMENT tcp.end EMPTY> + <!ATTLIST tcp.end + kind CDATA #FIXED "0"> + + <!ELEMENT tcp.noop EMPTY> + <!ATTLIST tcp.noop + kind CDATA #FIXED "1"> + + <!ELEMENT tcp.mss EMPTY> + <!ATTLIST tcp.mss + kind CDATA #FIXED "2" + length CDATA #FIXED "4" + size %Digits; #REQUIRED> + +7.3. UDPoXML DTD + + <!-- + DTD for UDP over XML. + Refer to this DTD as: + + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + --> + + <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)> + + <!ELEMENT udp.header (src, dest, udp.length, checksum)> + + <!ELEMENT udp.pseudoheader (source, destination, protocol, + udp.length)> + + <!-- + udp header + data length in octets. does not include the size of + the pseudoheader. + --> + <!ELEMENT udp.length EMPTY> + <!ATTLIST udp.length + value %Digits; #REQUIRED> + + + +Kennedy Informational [Page 13] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +8. Security Considerations + + XML, as a subset of SGML, has the same security considerations as + specified in SGML Media Types [RFC1874]. Security considerations + that apply to IP, TCP and UDP also likely apply to BLOAT as it does + not attempt to correct for issues not related to message format. + +9. References + + [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt, + February 2002. (Work in Progress) + + [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC894] Hornig, C., "Standard for the Transmission of IP + Datagrams over Ethernet Networks.", RFC 894, April 1984. + + [RFC1042] Postel, J. and J. Reynolds, "Standard for the + Transmission of IP Datagrams Over IEEE 802 Networks", STD + 43, RFC 1042, February 1988. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", RFC 1123, October 1989. + + [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December + 1995. + + [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, + October 1996. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + + + + +Kennedy Informational [Page 14] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", + RFC 3080, March 2001. + + [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., + Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D., + "Simple Object Access Protocol (SOAP) 1.1" World Wide Web + Consortium Note, May 2000 http://www.w3.org/TR/SOAP/ + + [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible + Markup Language (XML)" World Wide Web Consortium + Recommendation REC- xml-19980210. + http://www.w3.org/TR/1998/REC-xml-19980210 + +10. Author's Address + + Hugh Kennedy + Mimezine + 1060 West Addison + Chicago, IL 60613 + USA + + EMail: kennedyh@engin.umich.edu + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 15] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 16] + + + + + + + +Network Working Group H. Kennedy +Request for Comments: 3252 Mimezine +Category: Informational 1 April 2002 + + + Binary Lexical Octet Ad-hoc Transport + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document defines a reformulation of IP and two transport layer + protocols (TCP and UDP) as XML applications. + +1. Introduction + +1.1. Overview + + This document describes the Binary Lexical Octet Ad-hoc Transport + (BLOAT): a reformulation of a widely-deployed network-layer protocol + (IP [RFC791]), and two associated transport layer protocols (TCP + [RFC793] and UDP [RFC768]) as XML [XML] applications. It also + describes methods for transporting BLOAT over Ethernet and IEEE 802 + networks as well as encapsulating BLOAT in IP for gatewaying BLOAT + across the public Internet. + +1.2. Motivation + + The wild popularity of XML as a basis for application-level protocols + such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple + Object Access Protocol [SOAP], and Jabber [JABBER] prompted + investigation into the possibility of extending the use of XML in the + protocol stack. Using XML at both the transport and network layer in + addition to the application layer would provide for an amazing amount + of power and flexibility while removing dependencies on proprietary + and hard-to-understand binary protocols. This protocol unification + would also allow applications to use a single XML parser for all + aspects of their operation, eliminating developer time spent figuring + out the intricacies of each new protocol, and moving the hard work of + + + + +Kennedy Informational [Page 1] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + parsing to the XML toolset. The use of XML also mitigates concerns + over "network vs. host" byte ordering which is at the root of many + network application bugs. + +1.3. Relation to Existing Protocols + + The reformulations specified in this RFC follow as closely as + possible the spirit of the RFCs on which they are based, and so MAY + contain elements or attributes that would not be needed in a pure + reworking (e.g. length attributes, which are implicit in XML.) + + The layering of network and transport protocols are maintained in + this RFC despite the optimizations that could be made if the line + were somewhat blurred (i.e. merging TCP and IP into a single, larger + element in the DTD) in order to foster future use of this protocol as + a basis for reformulating other protocols (such as ICMP.) + + Other than the encoding, the behavioral aspects of each of the + existing protocols remain unchanged. Routing, address spaces, TCP + congestion control, etc. behave as specified in the extant standards. + Adapting to new standards and experimental algorithm heuristics for + improving performance will become much easier once the move to BLOAT + has been completed. + +1.4. Requirement Levels + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 + [RFC2119]. + +2. IPoXML + + This protocol MUST be implemented to be compliant with this RFC. + IPoXML is the root protocol REQUIRED for effective use of TCPoXML + (section 3.) and higher-level application protocols. + + The DTD for this document type can be found in section 7.1. + + The routing of IPoXML can be easily implemented on hosts with an XML + parser, as the regular structure lends itself handily to parsing and + validation of the document/datagram and then processing the + destination address, TTL, and checksum before sending it on to its + next-hop. + + The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the + wider deployment of IPv4 and the fact that implementing IPv6 as XML + would have exceeded the 1500 byte Ethernet MTU. + + + +Kennedy Informational [Page 2] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + All BLOAT implementations MUST use - and specify - the UTF-8 encoding + of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well- + formed and include the XMLDecl. + +2.1. IP Description + + A number of items have changed (for the better) from the original IP + specification. Bit-masks, where present have been converted into + human-readable values. IP addresses are listed in their dotted- + decimal notation [RFC1123]. Length and checksum values are present + as decimal integers. + + To calculate the length and checksum fields of the IP element, a + canonicalized form of the element MUST be used. The canonical form + SHALL have no whitespace (including newline characters) between + elements and only one space character between attributes. There + SHALL NOT be a space following the last attribute in an element. + + An iterative method SHOULD be used to calculate checksums, as the + length field will vary based on the size of the checksum. + + The payload element bears special attention. Due to the character + set restrictions of XML, the payload of IP datagrams (which MAY + contain arbitrary data) MUST be encoded for transport. This RFC + REQUIRES the contents of the payload to be encoded in the base-64 + encoding of RFC 2045 [RFC2045], but removes the requirement that the + encoded output MUST be wrapped on 76-character lines. + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 3] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +2.2. Example Datagram + + The following is an example IPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + <ip> + <header length="474"> + <version value="4"/> + <tos precedence="Routine" delay="Normal" throughput="Normal" + relibility="Normal" reserved="0"/> + <total.length value="461"/> + <id value="1"/> + <flags reserved="0" df="dont" mf="last"/> + <offset value="0"/> + <ttl value="255"/> + <protocol value="6"/> + <checksum value="8707"/> + <source address="10.0.0.22"/> + <destination address="10.0.0.1"/> + <options> + <end copied="0" class="0" number="0"/> + </options> + <padding pad="0"/> + </header> + <payload> + </payload> + </ip> + +3. TCPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.2. + +3.1. TCP Description + + A number of items have changed from the original TCP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + To calculate the length and checksum fields of the TCP element, a + canonicalized form of the element MUST be used as in section 2.1. + + An iterative method SHOULD be used to calculate checksums as in + section 2.1. + + The payload element MUST be encoded as in section 2.1. + + + +Kennedy Informational [Page 4] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + The TCP offset element was expanded to a maximum of 255 from 16 to + allow for the increased size of the header in XML. + + TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + <tcp> + <tcp.header> + <src port="31415"/> + <dest port="42424"/> + <sequence number="322622954"/> + <acknowledgement number="689715995"/> + <offset number=""/> + <reserved value="0"/> + <control syn="1" ack="1"/> + <window size="1"/> + <urgent pointer="0"/> + <checksum value="2988"/> + <tcp.options> + <tcp.end kind="0"/> + </tcp.options> + <padding pad="0"/> + </tcp.header> + <payload> + </payload> + </tcp> + +4. UDPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.3. + +4.1. UDP Description + + A number of items have changed from the original UDP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + + + + + + +Kennedy Informational [Page 5] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + To calculate the length and checksum fields of the UDP element, a + canonicalized form of the element MUST be used as in section 2.1. An + iterative method SHOULD be used to calculate checksums as in section + 2.1. + + The payload element MUST be encoded as in section 2.1. + + UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + <udp> + <udp.header> + <src port="31415"/> + <dest port="42424"/> + <udp.length value="143"/> + <checksum value="2988"/> + </udp.header> + <payload> + </payload> + </udp> + +5. Network Transport + + This document provides for the transmission of BLOAT datagrams over + two common families of physical layer transport. Future RFCs will + address additional transports as routing vendors catch up to the + specification, and we begin to see BLOAT routed across the Internet + backbone. + +5.1. Ethernet + + BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the + exception that the type field of the Ethernet frame MUST contain the + value 0xBEEF. The first 5 octets of the Ethernet frame payload will + be 0x3c 3f 78 6d 6c ("<?xml".) + +5.2. IEEE 802 + + BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except + that the protocol type code for IPoXML is 0xBEEF. + + + + + +Kennedy Informational [Page 6] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +6. Gatewaying over IP + + In order to facilitate the gradual introduction of BLOAT into the + public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to + gateway between networks that run BLOAT natively on their LANs. + +7. DTDs + + The Transport DTDs (7.2. and 7.3.) build on the definitions in the + Network DTD (7.1.) + + The DTDs are referenced by their PubidLiteral and SystemLiteral (from + [XML]) although it is understood that most IPoXML implementations + will not need to pull down the DTD, as it will normally be embedded + in the implementation, and presents something of a catch-22 if you + need to load part of your network protocol over the network. + +7.1. IPoXML DTD + + <!-- + DTD for IP over XML. + Refer to this DTD as: + + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + --> + <!-- + DTD data types: + + Digits [0..9]+ + + Precedence "NetworkControl | InternetworkControl | + CRITIC | FlashOverride | Flash | Immediate | + Priority | Routine" + + IP4Addr "dotted-decimal" notation of [RFC1123] + + Class [0..3] + + Sec "Unclassified | Confidential | EFTO | MMMM | PROG | + Restricted | Secret | Top Secret | Reserved" + + Compartments [0..65535] + + Handling [0..65535] + + TCC [0..16777216] + + --> + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ENTITY % Digits "CDATA"> + <!ENTITY % Precedence "CDATA"> + <!ENTITY % IP4Addr "CDATA"> + <!ENTITY % Class "CDATA"> + <!ENTITY % Sec "CDATA"> + <!ENTITY % Compartments "CDATA"> + <!ENTITY % Handling "CDATA"> + <!ENTITY % TCC "CDATA"> + + <!ELEMENT ip (header, payload)> + + <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl, + protocol, checksum, source, destination, options, + padding)> + <!-- length of header in 32-bit words --> + <!ATTLIST header + length %Digits; #REQUIRED> + + <!ELEMENT version EMPTY> + <!-- ip version. SHOULD be "4" --> + <!ATTLIST version + value %Digits; #REQUIRED> + + <!ELEMENT tos EMPTY> + <!ATTLIST tos + precedence %Precedence; #REQUIRED + delay (normal | low) #REQUIRED + throughput (normal | high) #REQUIRED + relibility (normal | high) #REQUIRED + reserved CDATA #FIXED "0"> + + <!ELEMENT total.length EMPTY> + <!-- + total length of datagram (header and payload) in octets, MUST be + less than 65,535 (and SHOULD be less than 1024 for IPoXML on local + ethernets). + --> + <!ATTLIST total.length + value %Digits; #REQUIRED> + + <!ELEMENT id EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST id + value %Digits; #REQUIRED> + + <!ELEMENT flags EMPTY> + <!-- df = don't fragment, mf = more fragments --> + <!ATTLIST flags + + + +Kennedy Informational [Page 8] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + reserved CDATA #FIXED "0" + df (may|dont) #REQUIRED + mf (last|more) #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks --> + <!ATTLIST offset + value %Digits; #REQUIRED> + + <!ELEMENT ttl EMPTY> + <!-- 0 <= ttl <= 255 --> + <!ATTLIST ttl + value %Digits; #REQUIRED> + + <!ELEMENT protocol EMPTY> + <!-- 0 <= protocol <= 255 (per IANA) --> + <!ATTLIST protocol + value %Digits; #REQUIRED> + + <!ELEMENT checksum EMPTY> + <!-- 0 <= checksum <= 65535 (over header only) --> + <!ATTLIST checksum + value %Digits; #REQUIRED> + + <!ELEMENT source EMPTY> + <!ATTLIST source + address %IP4Addr; #REQUIRED> + + <!ELEMENT destination EMPTY> + <!ATTLIST destination + address %IP4Addr; #REQUIRED> + + <!ELEMENT options ( end | noop | security | loose | strict | record + | stream | timestamp )*> + + <!ELEMENT end EMPTY> + <!ATTLIST end + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "0"> + + <!ELEMENT noop EMPTY> + <!ATTLIST noop + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "1"> + + <!ELEMENT security EMPTY> + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST security + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "2" + length CDATA #FIXED "11" + security %Sec; #REQUIRED + compartments %Compartments; #REQUIRED + handling %Handling; #REQUIRED + tcc %TCC; #REQUIRED> + <!ELEMENT loose (hop)+> + <!ATTLIST loose + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "3" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT hop EMPTY> + <!ATTLIST hop + address %IP4Addr; #REQUIRED> + + <!ELEMENT strict (hop)+> + <!ATTLIST strict + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "9" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT record (hop)+> + <!ATTLIST record + copied CDATA #FIXED "0" + class CDATA #FIXED "0" + number CDATA #FIXED "7" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT stream EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST stream + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "8" + length CDATA #FIXED "4" + id %Digits; #REQUIRED> + + <!ELEMENT timestamp (tstamp)+> + <!-- 0 <= oflw <=15 --> + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST timestamp + copied CDATA #FIXED "0" + class CDATA #FIXED "2" + number CDATA #FIXED "4" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED + oflw %Digits; #REQUIRED + flag (0 | 1 | 3) #REQUIRED> + + <!ELEMENT tstamp EMPTY> + <!ATTLIST tstamp + time %Digits; #REQUIRED + address %IP4Addr; #IMPLIED> + <!-- + padding to bring header to 32-bit boundary. + pad MUST be "0"* + --> + <!ELEMENT padding EMPTY> + <!ATTLIST padding + pad CDATA #REQUIRED> + + <!-- payload MUST be encoded as base-64 [RFC2045], as modified + by section 2.1 of this RFC --> + <!ELEMENT payload (CDATA)> + +7.2. TCPoXML DTD + + <!-- + DTD for TCP over XML. + Refer to this DTD as: + + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + --> + + <!-- the pseudoheader is only included for checksum calculations --> + <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)> + + <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset, + reserved, control, window, checksum, urgent, + tcp.options, padding)> + + <!ELEMENT src EMPTY> + <!-- 0 <= port <= 65,535 --> + <!ATTLIST src + port %Digits; #REQUIRED> + + <!ELEMENT dest EMPTY> + <!-- 0 <= port <= 65,535 --> + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST dest + port %Digits; #REQUIRED> + + <!ELEMENT sequence EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST sequence + number %Digits; #REQUIRED> + + <!ELEMENT acknowledgement EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST acknowledgement + number %Digits; #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= number <= 255 --> + <!ATTLIST offset + number %Digits; #REQUIRED> + + <!ELEMENT reserved EMPTY> + <!ATTLIST reserved + value CDATA #FIXED "0"> + + <!ELEMENT control EMPTY> + <!ATTLIST control + urg (0|1) #IMPLIED + ack (0|1) #IMPLIED + psh (0|1) #IMPLIED + rst (0|1) #IMPLIED + syn (0|1) #IMPLIED + fin (0|1) #IMPLIED> + + <!ELEMENT window EMPTY> + <!-- 0 <= size <= 65,535 --> + <!ATTLIST window + size %Digits; #REQUIRED> + + <!-- + checksum as in ip, but with + the following pseudo-header added into the tcp element: + --> + <!ELEMENT tcp.pseudoheader (source, destination, protocol, + tcp.length)> + + <!-- + tcp header + data length in octets. does not include the size of + + the pseudoheader. + --> + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ELEMENT tcp.length EMPTY> + <!ATTLIST tcp.length + value %Digits; #REQUIRED> + + <!ELEMENT urgent EMPTY> + <!-- 0 <= pointer <= 65,535 --> + <!ATTLIST urgent + pointer %Digits; #REQUIRED> + + <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+> + + <!ELEMENT tcp.end EMPTY> + <!ATTLIST tcp.end + kind CDATA #FIXED "0"> + + <!ELEMENT tcp.noop EMPTY> + <!ATTLIST tcp.noop + kind CDATA #FIXED "1"> + + <!ELEMENT tcp.mss EMPTY> + <!ATTLIST tcp.mss + kind CDATA #FIXED "2" + length CDATA #FIXED "4" + size %Digits; #REQUIRED> + +7.3. UDPoXML DTD + + <!-- + DTD for UDP over XML. + Refer to this DTD as: + + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + --> + + <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)> + + <!ELEMENT udp.header (src, dest, udp.length, checksum)> + + <!ELEMENT udp.pseudoheader (source, destination, protocol, + udp.length)> + + <!-- + udp header + data length in octets. does not include the size of + the pseudoheader. + --> + <!ELEMENT udp.length EMPTY> + <!ATTLIST udp.length + value %Digits; #REQUIRED> + + + +Kennedy Informational [Page 13] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +8. Security Considerations + + XML, as a subset of SGML, has the same security considerations as + specified in SGML Media Types [RFC1874]. Security considerations + that apply to IP, TCP and UDP also likely apply to BLOAT as it does + not attempt to correct for issues not related to message format. + +9. References + + [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt, + February 2002. (Work in Progress) + + [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC894] Hornig, C., "Standard for the Transmission of IP + Datagrams over Ethernet Networks.", RFC 894, April 1984. + + [RFC1042] Postel, J. and J. Reynolds, "Standard for the + Transmission of IP Datagrams Over IEEE 802 Networks", STD + 43, RFC 1042, February 1988. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", RFC 1123, October 1989. + + [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December + 1995. + + [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, + October 1996. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + + + + +Kennedy Informational [Page 14] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", + RFC 3080, March 2001. + + [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., + Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D., + "Simple Object Access Protocol (SOAP) 1.1" World Wide Web + Consortium Note, May 2000 http://www.w3.org/TR/SOAP/ + + [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible + Markup Language (XML)" World Wide Web Consortium + Recommendation REC- xml-19980210. + http://www.w3.org/TR/1998/REC-xml-19980210 + +10. Author's Address + + Hugh Kennedy + Mimezine + 1060 West Addison + Chicago, IL 60613 + USA + + EMail: kennedyh@engin.umich.edu + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 15] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 16] + + + + + + + +Network Working Group H. Kennedy +Request for Comments: 3252 Mimezine +Category: Informational 1 April 2002 + + + Binary Lexical Octet Ad-hoc Transport + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document defines a reformulation of IP and two transport layer + protocols (TCP and UDP) as XML applications. + +1. Introduction + +1.1. Overview + + This document describes the Binary Lexical Octet Ad-hoc Transport + (BLOAT): a reformulation of a widely-deployed network-layer protocol + (IP [RFC791]), and two associated transport layer protocols (TCP + [RFC793] and UDP [RFC768]) as XML [XML] applications. It also + describes methods for transporting BLOAT over Ethernet and IEEE 802 + networks as well as encapsulating BLOAT in IP for gatewaying BLOAT + across the public Internet. + +1.2. Motivation + + The wild popularity of XML as a basis for application-level protocols + such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple + Object Access Protocol [SOAP], and Jabber [JABBER] prompted + investigation into the possibility of extending the use of XML in the + protocol stack. Using XML at both the transport and network layer in + addition to the application layer would provide for an amazing amount + of power and flexibility while removing dependencies on proprietary + and hard-to-understand binary protocols. This protocol unification + would also allow applications to use a single XML parser for all + aspects of their operation, eliminating developer time spent figuring + out the intricacies of each new protocol, and moving the hard work of + + + + +Kennedy Informational [Page 1] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + parsing to the XML toolset. The use of XML also mitigates concerns + over "network vs. host" byte ordering which is at the root of many + network application bugs. + +1.3. Relation to Existing Protocols + + The reformulations specified in this RFC follow as closely as + possible the spirit of the RFCs on which they are based, and so MAY + contain elements or attributes that would not be needed in a pure + reworking (e.g. length attributes, which are implicit in XML.) + + The layering of network and transport protocols are maintained in + this RFC despite the optimizations that could be made if the line + were somewhat blurred (i.e. merging TCP and IP into a single, larger + element in the DTD) in order to foster future use of this protocol as + a basis for reformulating other protocols (such as ICMP.) + + Other than the encoding, the behavioral aspects of each of the + existing protocols remain unchanged. Routing, address spaces, TCP + congestion control, etc. behave as specified in the extant standards. + Adapting to new standards and experimental algorithm heuristics for + improving performance will become much easier once the move to BLOAT + has been completed. + +1.4. Requirement Levels + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 + [RFC2119]. + +2. IPoXML + + This protocol MUST be implemented to be compliant with this RFC. + IPoXML is the root protocol REQUIRED for effective use of TCPoXML + (section 3.) and higher-level application protocols. + + The DTD for this document type can be found in section 7.1. + + The routing of IPoXML can be easily implemented on hosts with an XML + parser, as the regular structure lends itself handily to parsing and + validation of the document/datagram and then processing the + destination address, TTL, and checksum before sending it on to its + next-hop. + + The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the + wider deployment of IPv4 and the fact that implementing IPv6 as XML + would have exceeded the 1500 byte Ethernet MTU. + + + +Kennedy Informational [Page 2] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + All BLOAT implementations MUST use - and specify - the UTF-8 encoding + of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well- + formed and include the XMLDecl. + +2.1. IP Description + + A number of items have changed (for the better) from the original IP + specification. Bit-masks, where present have been converted into + human-readable values. IP addresses are listed in their dotted- + decimal notation [RFC1123]. Length and checksum values are present + as decimal integers. + + To calculate the length and checksum fields of the IP element, a + canonicalized form of the element MUST be used. The canonical form + SHALL have no whitespace (including newline characters) between + elements and only one space character between attributes. There + SHALL NOT be a space following the last attribute in an element. + + An iterative method SHOULD be used to calculate checksums, as the + length field will vary based on the size of the checksum. + + The payload element bears special attention. Due to the character + set restrictions of XML, the payload of IP datagrams (which MAY + contain arbitrary data) MUST be encoded for transport. This RFC + REQUIRES the contents of the payload to be encoded in the base-64 + encoding of RFC 2045 [RFC2045], but removes the requirement that the + encoded output MUST be wrapped on 76-character lines. + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 3] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +2.2. Example Datagram + + The following is an example IPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + <ip> + <header length="474"> + <version value="4"/> + <tos precedence="Routine" delay="Normal" throughput="Normal" + relibility="Normal" reserved="0"/> + <total.length value="461"/> + <id value="1"/> + <flags reserved="0" df="dont" mf="last"/> + <offset value="0"/> + <ttl value="255"/> + <protocol value="6"/> + <checksum value="8707"/> + <source address="10.0.0.22"/> + <destination address="10.0.0.1"/> + <options> + <end copied="0" class="0" number="0"/> + </options> + <padding pad="0"/> + </header> + <payload> + </payload> + </ip> + +3. TCPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.2. + +3.1. TCP Description + + A number of items have changed from the original TCP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + To calculate the length and checksum fields of the TCP element, a + canonicalized form of the element MUST be used as in section 2.1. + + An iterative method SHOULD be used to calculate checksums as in + section 2.1. + + The payload element MUST be encoded as in section 2.1. + + + +Kennedy Informational [Page 4] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + The TCP offset element was expanded to a maximum of 255 from 16 to + allow for the increased size of the header in XML. + + TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + <tcp> + <tcp.header> + <src port="31415"/> + <dest port="42424"/> + <sequence number="322622954"/> + <acknowledgement number="689715995"/> + <offset number=""/> + <reserved value="0"/> + <control syn="1" ack="1"/> + <window size="1"/> + <urgent pointer="0"/> + <checksum value="2988"/> + <tcp.options> + <tcp.end kind="0"/> + </tcp.options> + <padding pad="0"/> + </tcp.header> + <payload> + </payload> + </tcp> + +4. UDPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.3. + +4.1. UDP Description + + A number of items have changed from the original UDP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + + + + + + +Kennedy Informational [Page 5] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + To calculate the length and checksum fields of the UDP element, a + canonicalized form of the element MUST be used as in section 2.1. An + iterative method SHOULD be used to calculate checksums as in section + 2.1. + + The payload element MUST be encoded as in section 2.1. + + UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + <udp> + <udp.header> + <src port="31415"/> + <dest port="42424"/> + <udp.length value="143"/> + <checksum value="2988"/> + </udp.header> + <payload> + </payload> + </udp> + +5. Network Transport + + This document provides for the transmission of BLOAT datagrams over + two common families of physical layer transport. Future RFCs will + address additional transports as routing vendors catch up to the + specification, and we begin to see BLOAT routed across the Internet + backbone. + +5.1. Ethernet + + BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the + exception that the type field of the Ethernet frame MUST contain the + value 0xBEEF. The first 5 octets of the Ethernet frame payload will + be 0x3c 3f 78 6d 6c ("<?xml".) + +5.2. IEEE 802 + + BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except + that the protocol type code for IPoXML is 0xBEEF. + + + + + +Kennedy Informational [Page 6] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +6. Gatewaying over IP + + In order to facilitate the gradual introduction of BLOAT into the + public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to + gateway between networks that run BLOAT natively on their LANs. + +7. DTDs + + The Transport DTDs (7.2. and 7.3.) build on the definitions in the + Network DTD (7.1.) + + The DTDs are referenced by their PubidLiteral and SystemLiteral (from + [XML]) although it is understood that most IPoXML implementations + will not need to pull down the DTD, as it will normally be embedded + in the implementation, and presents something of a catch-22 if you + need to load part of your network protocol over the network. + +7.1. IPoXML DTD + + <!-- + DTD for IP over XML. + Refer to this DTD as: + + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + --> + <!-- + DTD data types: + + Digits [0..9]+ + + Precedence "NetworkControl | InternetworkControl | + CRITIC | FlashOverride | Flash | Immediate | + Priority | Routine" + + IP4Addr "dotted-decimal" notation of [RFC1123] + + Class [0..3] + + Sec "Unclassified | Confidential | EFTO | MMMM | PROG | + Restricted | Secret | Top Secret | Reserved" + + Compartments [0..65535] + + Handling [0..65535] + + TCC [0..16777216] + + --> + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ENTITY % Digits "CDATA"> + <!ENTITY % Precedence "CDATA"> + <!ENTITY % IP4Addr "CDATA"> + <!ENTITY % Class "CDATA"> + <!ENTITY % Sec "CDATA"> + <!ENTITY % Compartments "CDATA"> + <!ENTITY % Handling "CDATA"> + <!ENTITY % TCC "CDATA"> + + <!ELEMENT ip (header, payload)> + + <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl, + protocol, checksum, source, destination, options, + padding)> + <!-- length of header in 32-bit words --> + <!ATTLIST header + length %Digits; #REQUIRED> + + <!ELEMENT version EMPTY> + <!-- ip version. SHOULD be "4" --> + <!ATTLIST version + value %Digits; #REQUIRED> + + <!ELEMENT tos EMPTY> + <!ATTLIST tos + precedence %Precedence; #REQUIRED + delay (normal | low) #REQUIRED + throughput (normal | high) #REQUIRED + relibility (normal | high) #REQUIRED + reserved CDATA #FIXED "0"> + + <!ELEMENT total.length EMPTY> + <!-- + total length of datagram (header and payload) in octets, MUST be + less than 65,535 (and SHOULD be less than 1024 for IPoXML on local + ethernets). + --> + <!ATTLIST total.length + value %Digits; #REQUIRED> + + <!ELEMENT id EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST id + value %Digits; #REQUIRED> + + <!ELEMENT flags EMPTY> + <!-- df = don't fragment, mf = more fragments --> + <!ATTLIST flags + + + +Kennedy Informational [Page 8] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + reserved CDATA #FIXED "0" + df (may|dont) #REQUIRED + mf (last|more) #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks --> + <!ATTLIST offset + value %Digits; #REQUIRED> + + <!ELEMENT ttl EMPTY> + <!-- 0 <= ttl <= 255 --> + <!ATTLIST ttl + value %Digits; #REQUIRED> + + <!ELEMENT protocol EMPTY> + <!-- 0 <= protocol <= 255 (per IANA) --> + <!ATTLIST protocol + value %Digits; #REQUIRED> + + <!ELEMENT checksum EMPTY> + <!-- 0 <= checksum <= 65535 (over header only) --> + <!ATTLIST checksum + value %Digits; #REQUIRED> + + <!ELEMENT source EMPTY> + <!ATTLIST source + address %IP4Addr; #REQUIRED> + + <!ELEMENT destination EMPTY> + <!ATTLIST destination + address %IP4Addr; #REQUIRED> + + <!ELEMENT options ( end | noop | security | loose | strict | record + | stream | timestamp )*> + + <!ELEMENT end EMPTY> + <!ATTLIST end + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "0"> + + <!ELEMENT noop EMPTY> + <!ATTLIST noop + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "1"> + + <!ELEMENT security EMPTY> + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST security + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "2" + length CDATA #FIXED "11" + security %Sec; #REQUIRED + compartments %Compartments; #REQUIRED + handling %Handling; #REQUIRED + tcc %TCC; #REQUIRED> + <!ELEMENT loose (hop)+> + <!ATTLIST loose + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "3" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT hop EMPTY> + <!ATTLIST hop + address %IP4Addr; #REQUIRED> + + <!ELEMENT strict (hop)+> + <!ATTLIST strict + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "9" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT record (hop)+> + <!ATTLIST record + copied CDATA #FIXED "0" + class CDATA #FIXED "0" + number CDATA #FIXED "7" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT stream EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST stream + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "8" + length CDATA #FIXED "4" + id %Digits; #REQUIRED> + + <!ELEMENT timestamp (tstamp)+> + <!-- 0 <= oflw <=15 --> + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST timestamp + copied CDATA #FIXED "0" + class CDATA #FIXED "2" + number CDATA #FIXED "4" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED + oflw %Digits; #REQUIRED + flag (0 | 1 | 3) #REQUIRED> + + <!ELEMENT tstamp EMPTY> + <!ATTLIST tstamp + time %Digits; #REQUIRED + address %IP4Addr; #IMPLIED> + <!-- + padding to bring header to 32-bit boundary. + pad MUST be "0"* + --> + <!ELEMENT padding EMPTY> + <!ATTLIST padding + pad CDATA #REQUIRED> + + <!-- payload MUST be encoded as base-64 [RFC2045], as modified + by section 2.1 of this RFC --> + <!ELEMENT payload (CDATA)> + +7.2. TCPoXML DTD + + <!-- + DTD for TCP over XML. + Refer to this DTD as: + + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + --> + + <!-- the pseudoheader is only included for checksum calculations --> + <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)> + + <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset, + reserved, control, window, checksum, urgent, + tcp.options, padding)> + + <!ELEMENT src EMPTY> + <!-- 0 <= port <= 65,535 --> + <!ATTLIST src + port %Digits; #REQUIRED> + + <!ELEMENT dest EMPTY> + <!-- 0 <= port <= 65,535 --> + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST dest + port %Digits; #REQUIRED> + + <!ELEMENT sequence EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST sequence + number %Digits; #REQUIRED> + + <!ELEMENT acknowledgement EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST acknowledgement + number %Digits; #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= number <= 255 --> + <!ATTLIST offset + number %Digits; #REQUIRED> + + <!ELEMENT reserved EMPTY> + <!ATTLIST reserved + value CDATA #FIXED "0"> + + <!ELEMENT control EMPTY> + <!ATTLIST control + urg (0|1) #IMPLIED + ack (0|1) #IMPLIED + psh (0|1) #IMPLIED + rst (0|1) #IMPLIED + syn (0|1) #IMPLIED + fin (0|1) #IMPLIED> + + <!ELEMENT window EMPTY> + <!-- 0 <= size <= 65,535 --> + <!ATTLIST window + size %Digits; #REQUIRED> + + <!-- + checksum as in ip, but with + the following pseudo-header added into the tcp element: + --> + <!ELEMENT tcp.pseudoheader (source, destination, protocol, + tcp.length)> + + <!-- + tcp header + data length in octets. does not include the size of + + the pseudoheader. + --> + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ELEMENT tcp.length EMPTY> + <!ATTLIST tcp.length + value %Digits; #REQUIRED> + + <!ELEMENT urgent EMPTY> + <!-- 0 <= pointer <= 65,535 --> + <!ATTLIST urgent + pointer %Digits; #REQUIRED> + + <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+> + + <!ELEMENT tcp.end EMPTY> + <!ATTLIST tcp.end + kind CDATA #FIXED "0"> + + <!ELEMENT tcp.noop EMPTY> + <!ATTLIST tcp.noop + kind CDATA #FIXED "1"> + + <!ELEMENT tcp.mss EMPTY> + <!ATTLIST tcp.mss + kind CDATA #FIXED "2" + length CDATA #FIXED "4" + size %Digits; #REQUIRED> + +7.3. UDPoXML DTD + + <!-- + DTD for UDP over XML. + Refer to this DTD as: + + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + --> + + <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)> + + <!ELEMENT udp.header (src, dest, udp.length, checksum)> + + <!ELEMENT udp.pseudoheader (source, destination, protocol, + udp.length)> + + <!-- + udp header + data length in octets. does not include the size of + the pseudoheader. + --> + <!ELEMENT udp.length EMPTY> + <!ATTLIST udp.length + value %Digits; #REQUIRED> + + + +Kennedy Informational [Page 13] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +8. Security Considerations + + XML, as a subset of SGML, has the same security considerations as + specified in SGML Media Types [RFC1874]. Security considerations + that apply to IP, TCP and UDP also likely apply to BLOAT as it does + not attempt to correct for issues not related to message format. + +9. References + + [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt, + February 2002. (Work in Progress) + + [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC894] Hornig, C., "Standard for the Transmission of IP + Datagrams over Ethernet Networks.", RFC 894, April 1984. + + [RFC1042] Postel, J. and J. Reynolds, "Standard for the + Transmission of IP Datagrams Over IEEE 802 Networks", STD + 43, RFC 1042, February 1988. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", RFC 1123, October 1989. + + [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December + 1995. + + [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, + October 1996. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + + + + +Kennedy Informational [Page 14] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", + RFC 3080, March 2001. + + [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., + Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D., + "Simple Object Access Protocol (SOAP) 1.1" World Wide Web + Consortium Note, May 2000 http://www.w3.org/TR/SOAP/ + + [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible + Markup Language (XML)" World Wide Web Consortium + Recommendation REC- xml-19980210. + http://www.w3.org/TR/1998/REC-xml-19980210 + +10. Author's Address + + Hugh Kennedy + Mimezine + 1060 West Addison + Chicago, IL 60613 + USA + + EMail: kennedyh@engin.umich.edu + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 15] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 16] + + + + + + + +Network Working Group H. Kennedy +Request for Comments: 3252 Mimezine +Category: Informational 1 April 2002 + + + Binary Lexical Octet Ad-hoc Transport + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document defines a reformulation of IP and two transport layer + protocols (TCP and UDP) as XML applications. + +1. Introduction + +1.1. Overview + + This document describes the Binary Lexical Octet Ad-hoc Transport + (BLOAT): a reformulation of a widely-deployed network-layer protocol + (IP [RFC791]), and two associated transport layer protocols (TCP + [RFC793] and UDP [RFC768]) as XML [XML] applications. It also + describes methods for transporting BLOAT over Ethernet and IEEE 802 + networks as well as encapsulating BLOAT in IP for gatewaying BLOAT + across the public Internet. + +1.2. Motivation + + The wild popularity of XML as a basis for application-level protocols + such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple + Object Access Protocol [SOAP], and Jabber [JABBER] prompted + investigation into the possibility of extending the use of XML in the + protocol stack. Using XML at both the transport and network layer in + addition to the application layer would provide for an amazing amount + of power and flexibility while removing dependencies on proprietary + and hard-to-understand binary protocols. This protocol unification + would also allow applications to use a single XML parser for all + aspects of their operation, eliminating developer time spent figuring + out the intricacies of each new protocol, and moving the hard work of + + + + +Kennedy Informational [Page 1] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + parsing to the XML toolset. The use of XML also mitigates concerns + over "network vs. host" byte ordering which is at the root of many + network application bugs. + +1.3. Relation to Existing Protocols + + The reformulations specified in this RFC follow as closely as + possible the spirit of the RFCs on which they are based, and so MAY + contain elements or attributes that would not be needed in a pure + reworking (e.g. length attributes, which are implicit in XML.) + + The layering of network and transport protocols are maintained in + this RFC despite the optimizations that could be made if the line + were somewhat blurred (i.e. merging TCP and IP into a single, larger + element in the DTD) in order to foster future use of this protocol as + a basis for reformulating other protocols (such as ICMP.) + + Other than the encoding, the behavioral aspects of each of the + existing protocols remain unchanged. Routing, address spaces, TCP + congestion control, etc. behave as specified in the extant standards. + Adapting to new standards and experimental algorithm heuristics for + improving performance will become much easier once the move to BLOAT + has been completed. + +1.4. Requirement Levels + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 + [RFC2119]. + +2. IPoXML + + This protocol MUST be implemented to be compliant with this RFC. + IPoXML is the root protocol REQUIRED for effective use of TCPoXML + (section 3.) and higher-level application protocols. + + The DTD for this document type can be found in section 7.1. + + The routing of IPoXML can be easily implemented on hosts with an XML + parser, as the regular structure lends itself handily to parsing and + validation of the document/datagram and then processing the + destination address, TTL, and checksum before sending it on to its + next-hop. + + The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the + wider deployment of IPv4 and the fact that implementing IPv6 as XML + would have exceeded the 1500 byte Ethernet MTU. + + + +Kennedy Informational [Page 2] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + All BLOAT implementations MUST use - and specify - the UTF-8 encoding + of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well- + formed and include the XMLDecl. + +2.1. IP Description + + A number of items have changed (for the better) from the original IP + specification. Bit-masks, where present have been converted into + human-readable values. IP addresses are listed in their dotted- + decimal notation [RFC1123]. Length and checksum values are present + as decimal integers. + + To calculate the length and checksum fields of the IP element, a + canonicalized form of the element MUST be used. The canonical form + SHALL have no whitespace (including newline characters) between + elements and only one space character between attributes. There + SHALL NOT be a space following the last attribute in an element. + + An iterative method SHOULD be used to calculate checksums, as the + length field will vary based on the size of the checksum. + + The payload element bears special attention. Due to the character + set restrictions of XML, the payload of IP datagrams (which MAY + contain arbitrary data) MUST be encoded for transport. This RFC + REQUIRES the contents of the payload to be encoded in the base-64 + encoding of RFC 2045 [RFC2045], but removes the requirement that the + encoded output MUST be wrapped on 76-character lines. + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 3] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +2.2. Example Datagram + + The following is an example IPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + <ip> + <header length="474"> + <version value="4"/> + <tos precedence="Routine" delay="Normal" throughput="Normal" + relibility="Normal" reserved="0"/> + <total.length value="461"/> + <id value="1"/> + <flags reserved="0" df="dont" mf="last"/> + <offset value="0"/> + <ttl value="255"/> + <protocol value="6"/> + <checksum value="8707"/> + <source address="10.0.0.22"/> + <destination address="10.0.0.1"/> + <options> + <end copied="0" class="0" number="0"/> + </options> + <padding pad="0"/> + </header> + <payload> + </payload> + </ip> + +3. TCPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.2. + +3.1. TCP Description + + A number of items have changed from the original TCP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + To calculate the length and checksum fields of the TCP element, a + canonicalized form of the element MUST be used as in section 2.1. + + An iterative method SHOULD be used to calculate checksums as in + section 2.1. + + The payload element MUST be encoded as in section 2.1. + + + +Kennedy Informational [Page 4] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + The TCP offset element was expanded to a maximum of 255 from 16 to + allow for the increased size of the header in XML. + + TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + <tcp> + <tcp.header> + <src port="31415"/> + <dest port="42424"/> + <sequence number="322622954"/> + <acknowledgement number="689715995"/> + <offset number=""/> + <reserved value="0"/> + <control syn="1" ack="1"/> + <window size="1"/> + <urgent pointer="0"/> + <checksum value="2988"/> + <tcp.options> + <tcp.end kind="0"/> + </tcp.options> + <padding pad="0"/> + </tcp.header> + <payload> + </payload> + </tcp> + +4. UDPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.3. + +4.1. UDP Description + + A number of items have changed from the original UDP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + + + + + + +Kennedy Informational [Page 5] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + To calculate the length and checksum fields of the UDP element, a + canonicalized form of the element MUST be used as in section 2.1. An + iterative method SHOULD be used to calculate checksums as in section + 2.1. + + The payload element MUST be encoded as in section 2.1. + + UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + <udp> + <udp.header> + <src port="31415"/> + <dest port="42424"/> + <udp.length value="143"/> + <checksum value="2988"/> + </udp.header> + <payload> + </payload> + </udp> + +5. Network Transport + + This document provides for the transmission of BLOAT datagrams over + two common families of physical layer transport. Future RFCs will + address additional transports as routing vendors catch up to the + specification, and we begin to see BLOAT routed across the Internet + backbone. + +5.1. Ethernet + + BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the + exception that the type field of the Ethernet frame MUST contain the + value 0xBEEF. The first 5 octets of the Ethernet frame payload will + be 0x3c 3f 78 6d 6c ("<?xml".) + +5.2. IEEE 802 + + BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except + that the protocol type code for IPoXML is 0xBEEF. + + + + + +Kennedy Informational [Page 6] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +6. Gatewaying over IP + + In order to facilitate the gradual introduction of BLOAT into the + public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to + gateway between networks that run BLOAT natively on their LANs. + +7. DTDs + + The Transport DTDs (7.2. and 7.3.) build on the definitions in the + Network DTD (7.1.) + + The DTDs are referenced by their PubidLiteral and SystemLiteral (from + [XML]) although it is understood that most IPoXML implementations + will not need to pull down the DTD, as it will normally be embedded + in the implementation, and presents something of a catch-22 if you + need to load part of your network protocol over the network. + +7.1. IPoXML DTD + + <!-- + DTD for IP over XML. + Refer to this DTD as: + + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + --> + <!-- + DTD data types: + + Digits [0..9]+ + + Precedence "NetworkControl | InternetworkControl | + CRITIC | FlashOverride | Flash | Immediate | + Priority | Routine" + + IP4Addr "dotted-decimal" notation of [RFC1123] + + Class [0..3] + + Sec "Unclassified | Confidential | EFTO | MMMM | PROG | + Restricted | Secret | Top Secret | Reserved" + + Compartments [0..65535] + + Handling [0..65535] + + TCC [0..16777216] + + --> + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ENTITY % Digits "CDATA"> + <!ENTITY % Precedence "CDATA"> + <!ENTITY % IP4Addr "CDATA"> + <!ENTITY % Class "CDATA"> + <!ENTITY % Sec "CDATA"> + <!ENTITY % Compartments "CDATA"> + <!ENTITY % Handling "CDATA"> + <!ENTITY % TCC "CDATA"> + + <!ELEMENT ip (header, payload)> + + <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl, + protocol, checksum, source, destination, options, + padding)> + <!-- length of header in 32-bit words --> + <!ATTLIST header + length %Digits; #REQUIRED> + + <!ELEMENT version EMPTY> + <!-- ip version. SHOULD be "4" --> + <!ATTLIST version + value %Digits; #REQUIRED> + + <!ELEMENT tos EMPTY> + <!ATTLIST tos + precedence %Precedence; #REQUIRED + delay (normal | low) #REQUIRED + throughput (normal | high) #REQUIRED + relibility (normal | high) #REQUIRED + reserved CDATA #FIXED "0"> + + <!ELEMENT total.length EMPTY> + <!-- + total length of datagram (header and payload) in octets, MUST be + less than 65,535 (and SHOULD be less than 1024 for IPoXML on local + ethernets). + --> + <!ATTLIST total.length + value %Digits; #REQUIRED> + + <!ELEMENT id EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST id + value %Digits; #REQUIRED> + + <!ELEMENT flags EMPTY> + <!-- df = don't fragment, mf = more fragments --> + <!ATTLIST flags + + + +Kennedy Informational [Page 8] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + reserved CDATA #FIXED "0" + df (may|dont) #REQUIRED + mf (last|more) #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks --> + <!ATTLIST offset + value %Digits; #REQUIRED> + + <!ELEMENT ttl EMPTY> + <!-- 0 <= ttl <= 255 --> + <!ATTLIST ttl + value %Digits; #REQUIRED> + + <!ELEMENT protocol EMPTY> + <!-- 0 <= protocol <= 255 (per IANA) --> + <!ATTLIST protocol + value %Digits; #REQUIRED> + + <!ELEMENT checksum EMPTY> + <!-- 0 <= checksum <= 65535 (over header only) --> + <!ATTLIST checksum + value %Digits; #REQUIRED> + + <!ELEMENT source EMPTY> + <!ATTLIST source + address %IP4Addr; #REQUIRED> + + <!ELEMENT destination EMPTY> + <!ATTLIST destination + address %IP4Addr; #REQUIRED> + + <!ELEMENT options ( end | noop | security | loose | strict | record + | stream | timestamp )*> + + <!ELEMENT end EMPTY> + <!ATTLIST end + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "0"> + + <!ELEMENT noop EMPTY> + <!ATTLIST noop + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "1"> + + <!ELEMENT security EMPTY> + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST security + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "2" + length CDATA #FIXED "11" + security %Sec; #REQUIRED + compartments %Compartments; #REQUIRED + handling %Handling; #REQUIRED + tcc %TCC; #REQUIRED> + <!ELEMENT loose (hop)+> + <!ATTLIST loose + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "3" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT hop EMPTY> + <!ATTLIST hop + address %IP4Addr; #REQUIRED> + + <!ELEMENT strict (hop)+> + <!ATTLIST strict + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "9" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT record (hop)+> + <!ATTLIST record + copied CDATA #FIXED "0" + class CDATA #FIXED "0" + number CDATA #FIXED "7" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT stream EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST stream + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "8" + length CDATA #FIXED "4" + id %Digits; #REQUIRED> + + <!ELEMENT timestamp (tstamp)+> + <!-- 0 <= oflw <=15 --> + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST timestamp + copied CDATA #FIXED "0" + class CDATA #FIXED "2" + number CDATA #FIXED "4" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED + oflw %Digits; #REQUIRED + flag (0 | 1 | 3) #REQUIRED> + + <!ELEMENT tstamp EMPTY> + <!ATTLIST tstamp + time %Digits; #REQUIRED + address %IP4Addr; #IMPLIED> + <!-- + padding to bring header to 32-bit boundary. + pad MUST be "0"* + --> + <!ELEMENT padding EMPTY> + <!ATTLIST padding + pad CDATA #REQUIRED> + + <!-- payload MUST be encoded as base-64 [RFC2045], as modified + by section 2.1 of this RFC --> + <!ELEMENT payload (CDATA)> + +7.2. TCPoXML DTD + + <!-- + DTD for TCP over XML. + Refer to this DTD as: + + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + --> + + <!-- the pseudoheader is only included for checksum calculations --> + <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)> + + <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset, + reserved, control, window, checksum, urgent, + tcp.options, padding)> + + <!ELEMENT src EMPTY> + <!-- 0 <= port <= 65,535 --> + <!ATTLIST src + port %Digits; #REQUIRED> + + <!ELEMENT dest EMPTY> + <!-- 0 <= port <= 65,535 --> + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST dest + port %Digits; #REQUIRED> + + <!ELEMENT sequence EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST sequence + number %Digits; #REQUIRED> + + <!ELEMENT acknowledgement EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST acknowledgement + number %Digits; #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= number <= 255 --> + <!ATTLIST offset + number %Digits; #REQUIRED> + + <!ELEMENT reserved EMPTY> + <!ATTLIST reserved + value CDATA #FIXED "0"> + + <!ELEMENT control EMPTY> + <!ATTLIST control + urg (0|1) #IMPLIED + ack (0|1) #IMPLIED + psh (0|1) #IMPLIED + rst (0|1) #IMPLIED + syn (0|1) #IMPLIED + fin (0|1) #IMPLIED> + + <!ELEMENT window EMPTY> + <!-- 0 <= size <= 65,535 --> + <!ATTLIST window + size %Digits; #REQUIRED> + + <!-- + checksum as in ip, but with + the following pseudo-header added into the tcp element: + --> + <!ELEMENT tcp.pseudoheader (source, destination, protocol, + tcp.length)> + + <!-- + tcp header + data length in octets. does not include the size of + + the pseudoheader. + --> + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ELEMENT tcp.length EMPTY> + <!ATTLIST tcp.length + value %Digits; #REQUIRED> + + <!ELEMENT urgent EMPTY> + <!-- 0 <= pointer <= 65,535 --> + <!ATTLIST urgent + pointer %Digits; #REQUIRED> + + <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+> + + <!ELEMENT tcp.end EMPTY> + <!ATTLIST tcp.end + kind CDATA #FIXED "0"> + + <!ELEMENT tcp.noop EMPTY> + <!ATTLIST tcp.noop + kind CDATA #FIXED "1"> + + <!ELEMENT tcp.mss EMPTY> + <!ATTLIST tcp.mss + kind CDATA #FIXED "2" + length CDATA #FIXED "4" + size %Digits; #REQUIRED> + +7.3. UDPoXML DTD + + <!-- + DTD for UDP over XML. + Refer to this DTD as: + + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + --> + + <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)> + + <!ELEMENT udp.header (src, dest, udp.length, checksum)> + + <!ELEMENT udp.pseudoheader (source, destination, protocol, + udp.length)> + + <!-- + udp header + data length in octets. does not include the size of + the pseudoheader. + --> + <!ELEMENT udp.length EMPTY> + <!ATTLIST udp.length + value %Digits; #REQUIRED> + + + +Kennedy Informational [Page 13] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +8. Security Considerations + + XML, as a subset of SGML, has the same security considerations as + specified in SGML Media Types [RFC1874]. Security considerations + that apply to IP, TCP and UDP also likely apply to BLOAT as it does + not attempt to correct for issues not related to message format. + +9. References + + [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt, + February 2002. (Work in Progress) + + [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC894] Hornig, C., "Standard for the Transmission of IP + Datagrams over Ethernet Networks.", RFC 894, April 1984. + + [RFC1042] Postel, J. and J. Reynolds, "Standard for the + Transmission of IP Datagrams Over IEEE 802 Networks", STD + 43, RFC 1042, February 1988. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", RFC 1123, October 1989. + + [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December + 1995. + + [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, + October 1996. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + + + + +Kennedy Informational [Page 14] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", + RFC 3080, March 2001. + + [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., + Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D., + "Simple Object Access Protocol (SOAP) 1.1" World Wide Web + Consortium Note, May 2000 http://www.w3.org/TR/SOAP/ + + [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible + Markup Language (XML)" World Wide Web Consortium + Recommendation REC- xml-19980210. + http://www.w3.org/TR/1998/REC-xml-19980210 + +10. Author's Address + + Hugh Kennedy + Mimezine + 1060 West Addison + Chicago, IL 60613 + USA + + EMail: kennedyh@engin.umich.edu + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 15] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 16] + + + + + + + +Network Working Group H. Kennedy +Request for Comments: 3252 Mimezine +Category: Informational 1 April 2002 + + + Binary Lexical Octet Ad-hoc Transport + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document defines a reformulation of IP and two transport layer + protocols (TCP and UDP) as XML applications. + +1. Introduction + +1.1. Overview + + This document describes the Binary Lexical Octet Ad-hoc Transport + (BLOAT): a reformulation of a widely-deployed network-layer protocol + (IP [RFC791]), and two associated transport layer protocols (TCP + [RFC793] and UDP [RFC768]) as XML [XML] applications. It also + describes methods for transporting BLOAT over Ethernet and IEEE 802 + networks as well as encapsulating BLOAT in IP for gatewaying BLOAT + across the public Internet. + +1.2. Motivation + + The wild popularity of XML as a basis for application-level protocols + such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple + Object Access Protocol [SOAP], and Jabber [JABBER] prompted + investigation into the possibility of extending the use of XML in the + protocol stack. Using XML at both the transport and network layer in + addition to the application layer would provide for an amazing amount + of power and flexibility while removing dependencies on proprietary + and hard-to-understand binary protocols. This protocol unification + would also allow applications to use a single XML parser for all + aspects of their operation, eliminating developer time spent figuring + out the intricacies of each new protocol, and moving the hard work of + + + + +Kennedy Informational [Page 1] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + parsing to the XML toolset. The use of XML also mitigates concerns + over "network vs. host" byte ordering which is at the root of many + network application bugs. + +1.3. Relation to Existing Protocols + + The reformulations specified in this RFC follow as closely as + possible the spirit of the RFCs on which they are based, and so MAY + contain elements or attributes that would not be needed in a pure + reworking (e.g. length attributes, which are implicit in XML.) + + The layering of network and transport protocols are maintained in + this RFC despite the optimizations that could be made if the line + were somewhat blurred (i.e. merging TCP and IP into a single, larger + element in the DTD) in order to foster future use of this protocol as + a basis for reformulating other protocols (such as ICMP.) + + Other than the encoding, the behavioral aspects of each of the + existing protocols remain unchanged. Routing, address spaces, TCP + congestion control, etc. behave as specified in the extant standards. + Adapting to new standards and experimental algorithm heuristics for + improving performance will become much easier once the move to BLOAT + has been completed. + +1.4. Requirement Levels + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 + [RFC2119]. + +2. IPoXML + + This protocol MUST be implemented to be compliant with this RFC. + IPoXML is the root protocol REQUIRED for effective use of TCPoXML + (section 3.) and higher-level application protocols. + + The DTD for this document type can be found in section 7.1. + + The routing of IPoXML can be easily implemented on hosts with an XML + parser, as the regular structure lends itself handily to parsing and + validation of the document/datagram and then processing the + destination address, TTL, and checksum before sending it on to its + next-hop. + + The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the + wider deployment of IPv4 and the fact that implementing IPv6 as XML + would have exceeded the 1500 byte Ethernet MTU. + + + +Kennedy Informational [Page 2] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + All BLOAT implementations MUST use - and specify - the UTF-8 encoding + of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well- + formed and include the XMLDecl. + +2.1. IP Description + + A number of items have changed (for the better) from the original IP + specification. Bit-masks, where present have been converted into + human-readable values. IP addresses are listed in their dotted- + decimal notation [RFC1123]. Length and checksum values are present + as decimal integers. + + To calculate the length and checksum fields of the IP element, a + canonicalized form of the element MUST be used. The canonical form + SHALL have no whitespace (including newline characters) between + elements and only one space character between attributes. There + SHALL NOT be a space following the last attribute in an element. + + An iterative method SHOULD be used to calculate checksums, as the + length field will vary based on the size of the checksum. + + The payload element bears special attention. Due to the character + set restrictions of XML, the payload of IP datagrams (which MAY + contain arbitrary data) MUST be encoded for transport. This RFC + REQUIRES the contents of the payload to be encoded in the base-64 + encoding of RFC 2045 [RFC2045], but removes the requirement that the + encoded output MUST be wrapped on 76-character lines. + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 3] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +2.2. Example Datagram + + The following is an example IPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + <ip> + <header length="474"> + <version value="4"/> + <tos precedence="Routine" delay="Normal" throughput="Normal" + relibility="Normal" reserved="0"/> + <total.length value="461"/> + <id value="1"/> + <flags reserved="0" df="dont" mf="last"/> + <offset value="0"/> + <ttl value="255"/> + <protocol value="6"/> + <checksum value="8707"/> + <source address="10.0.0.22"/> + <destination address="10.0.0.1"/> + <options> + <end copied="0" class="0" number="0"/> + </options> + <padding pad="0"/> + </header> + <payload> + </payload> + </ip> + +3. TCPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.2. + +3.1. TCP Description + + A number of items have changed from the original TCP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + To calculate the length and checksum fields of the TCP element, a + canonicalized form of the element MUST be used as in section 2.1. + + An iterative method SHOULD be used to calculate checksums as in + section 2.1. + + The payload element MUST be encoded as in section 2.1. + + + +Kennedy Informational [Page 4] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + The TCP offset element was expanded to a maximum of 255 from 16 to + allow for the increased size of the header in XML. + + TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + <tcp> + <tcp.header> + <src port="31415"/> + <dest port="42424"/> + <sequence number="322622954"/> + <acknowledgement number="689715995"/> + <offset number=""/> + <reserved value="0"/> + <control syn="1" ack="1"/> + <window size="1"/> + <urgent pointer="0"/> + <checksum value="2988"/> + <tcp.options> + <tcp.end kind="0"/> + </tcp.options> + <padding pad="0"/> + </tcp.header> + <payload> + </payload> + </tcp> + +4. UDPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.3. + +4.1. UDP Description + + A number of items have changed from the original UDP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + + + + + + +Kennedy Informational [Page 5] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + To calculate the length and checksum fields of the UDP element, a + canonicalized form of the element MUST be used as in section 2.1. An + iterative method SHOULD be used to calculate checksums as in section + 2.1. + + The payload element MUST be encoded as in section 2.1. + + UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + <udp> + <udp.header> + <src port="31415"/> + <dest port="42424"/> + <udp.length value="143"/> + <checksum value="2988"/> + </udp.header> + <payload> + </payload> + </udp> + +5. Network Transport + + This document provides for the transmission of BLOAT datagrams over + two common families of physical layer transport. Future RFCs will + address additional transports as routing vendors catch up to the + specification, and we begin to see BLOAT routed across the Internet + backbone. + +5.1. Ethernet + + BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the + exception that the type field of the Ethernet frame MUST contain the + value 0xBEEF. The first 5 octets of the Ethernet frame payload will + be 0x3c 3f 78 6d 6c ("<?xml".) + +5.2. IEEE 802 + + BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except + that the protocol type code for IPoXML is 0xBEEF. + + + + + +Kennedy Informational [Page 6] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +6. Gatewaying over IP + + In order to facilitate the gradual introduction of BLOAT into the + public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to + gateway between networks that run BLOAT natively on their LANs. + +7. DTDs + + The Transport DTDs (7.2. and 7.3.) build on the definitions in the + Network DTD (7.1.) + + The DTDs are referenced by their PubidLiteral and SystemLiteral (from + [XML]) although it is understood that most IPoXML implementations + will not need to pull down the DTD, as it will normally be embedded + in the implementation, and presents something of a catch-22 if you + need to load part of your network protocol over the network. + +7.1. IPoXML DTD + + <!-- + DTD for IP over XML. + Refer to this DTD as: + + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + --> + <!-- + DTD data types: + + Digits [0..9]+ + + Precedence "NetworkControl | InternetworkControl | + CRITIC | FlashOverride | Flash | Immediate | + Priority | Routine" + + IP4Addr "dotted-decimal" notation of [RFC1123] + + Class [0..3] + + Sec "Unclassified | Confidential | EFTO | MMMM | PROG | + Restricted | Secret | Top Secret | Reserved" + + Compartments [0..65535] + + Handling [0..65535] + + TCC [0..16777216] + + --> + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ENTITY % Digits "CDATA"> + <!ENTITY % Precedence "CDATA"> + <!ENTITY % IP4Addr "CDATA"> + <!ENTITY % Class "CDATA"> + <!ENTITY % Sec "CDATA"> + <!ENTITY % Compartments "CDATA"> + <!ENTITY % Handling "CDATA"> + <!ENTITY % TCC "CDATA"> + + <!ELEMENT ip (header, payload)> + + <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl, + protocol, checksum, source, destination, options, + padding)> + <!-- length of header in 32-bit words --> + <!ATTLIST header + length %Digits; #REQUIRED> + + <!ELEMENT version EMPTY> + <!-- ip version. SHOULD be "4" --> + <!ATTLIST version + value %Digits; #REQUIRED> + + <!ELEMENT tos EMPTY> + <!ATTLIST tos + precedence %Precedence; #REQUIRED + delay (normal | low) #REQUIRED + throughput (normal | high) #REQUIRED + relibility (normal | high) #REQUIRED + reserved CDATA #FIXED "0"> + + <!ELEMENT total.length EMPTY> + <!-- + total length of datagram (header and payload) in octets, MUST be + less than 65,535 (and SHOULD be less than 1024 for IPoXML on local + ethernets). + --> + <!ATTLIST total.length + value %Digits; #REQUIRED> + + <!ELEMENT id EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST id + value %Digits; #REQUIRED> + + <!ELEMENT flags EMPTY> + <!-- df = don't fragment, mf = more fragments --> + <!ATTLIST flags + + + +Kennedy Informational [Page 8] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + reserved CDATA #FIXED "0" + df (may|dont) #REQUIRED + mf (last|more) #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks --> + <!ATTLIST offset + value %Digits; #REQUIRED> + + <!ELEMENT ttl EMPTY> + <!-- 0 <= ttl <= 255 --> + <!ATTLIST ttl + value %Digits; #REQUIRED> + + <!ELEMENT protocol EMPTY> + <!-- 0 <= protocol <= 255 (per IANA) --> + <!ATTLIST protocol + value %Digits; #REQUIRED> + + <!ELEMENT checksum EMPTY> + <!-- 0 <= checksum <= 65535 (over header only) --> + <!ATTLIST checksum + value %Digits; #REQUIRED> + + <!ELEMENT source EMPTY> + <!ATTLIST source + address %IP4Addr; #REQUIRED> + + <!ELEMENT destination EMPTY> + <!ATTLIST destination + address %IP4Addr; #REQUIRED> + + <!ELEMENT options ( end | noop | security | loose | strict | record + | stream | timestamp )*> + + <!ELEMENT end EMPTY> + <!ATTLIST end + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "0"> + + <!ELEMENT noop EMPTY> + <!ATTLIST noop + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "1"> + + <!ELEMENT security EMPTY> + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST security + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "2" + length CDATA #FIXED "11" + security %Sec; #REQUIRED + compartments %Compartments; #REQUIRED + handling %Handling; #REQUIRED + tcc %TCC; #REQUIRED> + <!ELEMENT loose (hop)+> + <!ATTLIST loose + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "3" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT hop EMPTY> + <!ATTLIST hop + address %IP4Addr; #REQUIRED> + + <!ELEMENT strict (hop)+> + <!ATTLIST strict + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "9" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT record (hop)+> + <!ATTLIST record + copied CDATA #FIXED "0" + class CDATA #FIXED "0" + number CDATA #FIXED "7" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT stream EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST stream + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "8" + length CDATA #FIXED "4" + id %Digits; #REQUIRED> + + <!ELEMENT timestamp (tstamp)+> + <!-- 0 <= oflw <=15 --> + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST timestamp + copied CDATA #FIXED "0" + class CDATA #FIXED "2" + number CDATA #FIXED "4" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED + oflw %Digits; #REQUIRED + flag (0 | 1 | 3) #REQUIRED> + + <!ELEMENT tstamp EMPTY> + <!ATTLIST tstamp + time %Digits; #REQUIRED + address %IP4Addr; #IMPLIED> + <!-- + padding to bring header to 32-bit boundary. + pad MUST be "0"* + --> + <!ELEMENT padding EMPTY> + <!ATTLIST padding + pad CDATA #REQUIRED> + + <!-- payload MUST be encoded as base-64 [RFC2045], as modified + by section 2.1 of this RFC --> + <!ELEMENT payload (CDATA)> + +7.2. TCPoXML DTD + + <!-- + DTD for TCP over XML. + Refer to this DTD as: + + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + --> + + <!-- the pseudoheader is only included for checksum calculations --> + <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)> + + <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset, + reserved, control, window, checksum, urgent, + tcp.options, padding)> + + <!ELEMENT src EMPTY> + <!-- 0 <= port <= 65,535 --> + <!ATTLIST src + port %Digits; #REQUIRED> + + <!ELEMENT dest EMPTY> + <!-- 0 <= port <= 65,535 --> + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST dest + port %Digits; #REQUIRED> + + <!ELEMENT sequence EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST sequence + number %Digits; #REQUIRED> + + <!ELEMENT acknowledgement EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST acknowledgement + number %Digits; #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= number <= 255 --> + <!ATTLIST offset + number %Digits; #REQUIRED> + + <!ELEMENT reserved EMPTY> + <!ATTLIST reserved + value CDATA #FIXED "0"> + + <!ELEMENT control EMPTY> + <!ATTLIST control + urg (0|1) #IMPLIED + ack (0|1) #IMPLIED + psh (0|1) #IMPLIED + rst (0|1) #IMPLIED + syn (0|1) #IMPLIED + fin (0|1) #IMPLIED> + + <!ELEMENT window EMPTY> + <!-- 0 <= size <= 65,535 --> + <!ATTLIST window + size %Digits; #REQUIRED> + + <!-- + checksum as in ip, but with + the following pseudo-header added into the tcp element: + --> + <!ELEMENT tcp.pseudoheader (source, destination, protocol, + tcp.length)> + + <!-- + tcp header + data length in octets. does not include the size of + + the pseudoheader. + --> + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ELEMENT tcp.length EMPTY> + <!ATTLIST tcp.length + value %Digits; #REQUIRED> + + <!ELEMENT urgent EMPTY> + <!-- 0 <= pointer <= 65,535 --> + <!ATTLIST urgent + pointer %Digits; #REQUIRED> + + <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+> + + <!ELEMENT tcp.end EMPTY> + <!ATTLIST tcp.end + kind CDATA #FIXED "0"> + + <!ELEMENT tcp.noop EMPTY> + <!ATTLIST tcp.noop + kind CDATA #FIXED "1"> + + <!ELEMENT tcp.mss EMPTY> + <!ATTLIST tcp.mss + kind CDATA #FIXED "2" + length CDATA #FIXED "4" + size %Digits; #REQUIRED> + +7.3. UDPoXML DTD + + <!-- + DTD for UDP over XML. + Refer to this DTD as: + + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + --> + + <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)> + + <!ELEMENT udp.header (src, dest, udp.length, checksum)> + + <!ELEMENT udp.pseudoheader (source, destination, protocol, + udp.length)> + + <!-- + udp header + data length in octets. does not include the size of + the pseudoheader. + --> + <!ELEMENT udp.length EMPTY> + <!ATTLIST udp.length + value %Digits; #REQUIRED> + + + +Kennedy Informational [Page 13] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +8. Security Considerations + + XML, as a subset of SGML, has the same security considerations as + specified in SGML Media Types [RFC1874]. Security considerations + that apply to IP, TCP and UDP also likely apply to BLOAT as it does + not attempt to correct for issues not related to message format. + +9. References + + [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt, + February 2002. (Work in Progress) + + [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC894] Hornig, C., "Standard for the Transmission of IP + Datagrams over Ethernet Networks.", RFC 894, April 1984. + + [RFC1042] Postel, J. and J. Reynolds, "Standard for the + Transmission of IP Datagrams Over IEEE 802 Networks", STD + 43, RFC 1042, February 1988. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", RFC 1123, October 1989. + + [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December + 1995. + + [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, + October 1996. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + + + + +Kennedy Informational [Page 14] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", + RFC 3080, March 2001. + + [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., + Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D., + "Simple Object Access Protocol (SOAP) 1.1" World Wide Web + Consortium Note, May 2000 http://www.w3.org/TR/SOAP/ + + [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible + Markup Language (XML)" World Wide Web Consortium + Recommendation REC- xml-19980210. + http://www.w3.org/TR/1998/REC-xml-19980210 + +10. Author's Address + + Hugh Kennedy + Mimezine + 1060 West Addison + Chicago, IL 60613 + USA + + EMail: kennedyh@engin.umich.edu + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 15] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 16] + + + + + + + +Network Working Group H. Kennedy +Request for Comments: 3252 Mimezine +Category: Informational 1 April 2002 + + + Binary Lexical Octet Ad-hoc Transport + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document defines a reformulation of IP and two transport layer + protocols (TCP and UDP) as XML applications. + +1. Introduction + +1.1. Overview + + This document describes the Binary Lexical Octet Ad-hoc Transport + (BLOAT): a reformulation of a widely-deployed network-layer protocol + (IP [RFC791]), and two associated transport layer protocols (TCP + [RFC793] and UDP [RFC768]) as XML [XML] applications. It also + describes methods for transporting BLOAT over Ethernet and IEEE 802 + networks as well as encapsulating BLOAT in IP for gatewaying BLOAT + across the public Internet. + +1.2. Motivation + + The wild popularity of XML as a basis for application-level protocols + such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple + Object Access Protocol [SOAP], and Jabber [JABBER] prompted + investigation into the possibility of extending the use of XML in the + protocol stack. Using XML at both the transport and network layer in + addition to the application layer would provide for an amazing amount + of power and flexibility while removing dependencies on proprietary + and hard-to-understand binary protocols. This protocol unification + would also allow applications to use a single XML parser for all + aspects of their operation, eliminating developer time spent figuring + out the intricacies of each new protocol, and moving the hard work of + + + + +Kennedy Informational [Page 1] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + parsing to the XML toolset. The use of XML also mitigates concerns + over "network vs. host" byte ordering which is at the root of many + network application bugs. + +1.3. Relation to Existing Protocols + + The reformulations specified in this RFC follow as closely as + possible the spirit of the RFCs on which they are based, and so MAY + contain elements or attributes that would not be needed in a pure + reworking (e.g. length attributes, which are implicit in XML.) + + The layering of network and transport protocols are maintained in + this RFC despite the optimizations that could be made if the line + were somewhat blurred (i.e. merging TCP and IP into a single, larger + element in the DTD) in order to foster future use of this protocol as + a basis for reformulating other protocols (such as ICMP.) + + Other than the encoding, the behavioral aspects of each of the + existing protocols remain unchanged. Routing, address spaces, TCP + congestion control, etc. behave as specified in the extant standards. + Adapting to new standards and experimental algorithm heuristics for + improving performance will become much easier once the move to BLOAT + has been completed. + +1.4. Requirement Levels + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 + [RFC2119]. + +2. IPoXML + + This protocol MUST be implemented to be compliant with this RFC. + IPoXML is the root protocol REQUIRED for effective use of TCPoXML + (section 3.) and higher-level application protocols. + + The DTD for this document type can be found in section 7.1. + + The routing of IPoXML can be easily implemented on hosts with an XML + parser, as the regular structure lends itself handily to parsing and + validation of the document/datagram and then processing the + destination address, TTL, and checksum before sending it on to its + next-hop. + + The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the + wider deployment of IPv4 and the fact that implementing IPv6 as XML + would have exceeded the 1500 byte Ethernet MTU. + + + +Kennedy Informational [Page 2] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + All BLOAT implementations MUST use - and specify - the UTF-8 encoding + of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well- + formed and include the XMLDecl. + +2.1. IP Description + + A number of items have changed (for the better) from the original IP + specification. Bit-masks, where present have been converted into + human-readable values. IP addresses are listed in their dotted- + decimal notation [RFC1123]. Length and checksum values are present + as decimal integers. + + To calculate the length and checksum fields of the IP element, a + canonicalized form of the element MUST be used. The canonical form + SHALL have no whitespace (including newline characters) between + elements and only one space character between attributes. There + SHALL NOT be a space following the last attribute in an element. + + An iterative method SHOULD be used to calculate checksums, as the + length field will vary based on the size of the checksum. + + The payload element bears special attention. Due to the character + set restrictions of XML, the payload of IP datagrams (which MAY + contain arbitrary data) MUST be encoded for transport. This RFC + REQUIRES the contents of the payload to be encoded in the base-64 + encoding of RFC 2045 [RFC2045], but removes the requirement that the + encoded output MUST be wrapped on 76-character lines. + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 3] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +2.2. Example Datagram + + The following is an example IPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + <ip> + <header length="474"> + <version value="4"/> + <tos precedence="Routine" delay="Normal" throughput="Normal" + relibility="Normal" reserved="0"/> + <total.length value="461"/> + <id value="1"/> + <flags reserved="0" df="dont" mf="last"/> + <offset value="0"/> + <ttl value="255"/> + <protocol value="6"/> + <checksum value="8707"/> + <source address="10.0.0.22"/> + <destination address="10.0.0.1"/> + <options> + <end copied="0" class="0" number="0"/> + </options> + <padding pad="0"/> + </header> + <payload> + </payload> + </ip> + +3. TCPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.2. + +3.1. TCP Description + + A number of items have changed from the original TCP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + To calculate the length and checksum fields of the TCP element, a + canonicalized form of the element MUST be used as in section 2.1. + + An iterative method SHOULD be used to calculate checksums as in + section 2.1. + + The payload element MUST be encoded as in section 2.1. + + + +Kennedy Informational [Page 4] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + The TCP offset element was expanded to a maximum of 255 from 16 to + allow for the increased size of the header in XML. + + TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + <tcp> + <tcp.header> + <src port="31415"/> + <dest port="42424"/> + <sequence number="322622954"/> + <acknowledgement number="689715995"/> + <offset number=""/> + <reserved value="0"/> + <control syn="1" ack="1"/> + <window size="1"/> + <urgent pointer="0"/> + <checksum value="2988"/> + <tcp.options> + <tcp.end kind="0"/> + </tcp.options> + <padding pad="0"/> + </tcp.header> + <payload> + </payload> + </tcp> + +4. UDPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.3. + +4.1. UDP Description + + A number of items have changed from the original UDP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + + + + + + +Kennedy Informational [Page 5] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + To calculate the length and checksum fields of the UDP element, a + canonicalized form of the element MUST be used as in section 2.1. An + iterative method SHOULD be used to calculate checksums as in section + 2.1. + + The payload element MUST be encoded as in section 2.1. + + UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + <udp> + <udp.header> + <src port="31415"/> + <dest port="42424"/> + <udp.length value="143"/> + <checksum value="2988"/> + </udp.header> + <payload> + </payload> + </udp> + +5. Network Transport + + This document provides for the transmission of BLOAT datagrams over + two common families of physical layer transport. Future RFCs will + address additional transports as routing vendors catch up to the + specification, and we begin to see BLOAT routed across the Internet + backbone. + +5.1. Ethernet + + BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the + exception that the type field of the Ethernet frame MUST contain the + value 0xBEEF. The first 5 octets of the Ethernet frame payload will + be 0x3c 3f 78 6d 6c ("<?xml".) + +5.2. IEEE 802 + + BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except + that the protocol type code for IPoXML is 0xBEEF. + + + + + +Kennedy Informational [Page 6] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +6. Gatewaying over IP + + In order to facilitate the gradual introduction of BLOAT into the + public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to + gateway between networks that run BLOAT natively on their LANs. + +7. DTDs + + The Transport DTDs (7.2. and 7.3.) build on the definitions in the + Network DTD (7.1.) + + The DTDs are referenced by their PubidLiteral and SystemLiteral (from + [XML]) although it is understood that most IPoXML implementations + will not need to pull down the DTD, as it will normally be embedded + in the implementation, and presents something of a catch-22 if you + need to load part of your network protocol over the network. + +7.1. IPoXML DTD + + <!-- + DTD for IP over XML. + Refer to this DTD as: + + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + --> + <!-- + DTD data types: + + Digits [0..9]+ + + Precedence "NetworkControl | InternetworkControl | + CRITIC | FlashOverride | Flash | Immediate | + Priority | Routine" + + IP4Addr "dotted-decimal" notation of [RFC1123] + + Class [0..3] + + Sec "Unclassified | Confidential | EFTO | MMMM | PROG | + Restricted | Secret | Top Secret | Reserved" + + Compartments [0..65535] + + Handling [0..65535] + + TCC [0..16777216] + + --> + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ENTITY % Digits "CDATA"> + <!ENTITY % Precedence "CDATA"> + <!ENTITY % IP4Addr "CDATA"> + <!ENTITY % Class "CDATA"> + <!ENTITY % Sec "CDATA"> + <!ENTITY % Compartments "CDATA"> + <!ENTITY % Handling "CDATA"> + <!ENTITY % TCC "CDATA"> + + <!ELEMENT ip (header, payload)> + + <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl, + protocol, checksum, source, destination, options, + padding)> + <!-- length of header in 32-bit words --> + <!ATTLIST header + length %Digits; #REQUIRED> + + <!ELEMENT version EMPTY> + <!-- ip version. SHOULD be "4" --> + <!ATTLIST version + value %Digits; #REQUIRED> + + <!ELEMENT tos EMPTY> + <!ATTLIST tos + precedence %Precedence; #REQUIRED + delay (normal | low) #REQUIRED + throughput (normal | high) #REQUIRED + relibility (normal | high) #REQUIRED + reserved CDATA #FIXED "0"> + + <!ELEMENT total.length EMPTY> + <!-- + total length of datagram (header and payload) in octets, MUST be + less than 65,535 (and SHOULD be less than 1024 for IPoXML on local + ethernets). + --> + <!ATTLIST total.length + value %Digits; #REQUIRED> + + <!ELEMENT id EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST id + value %Digits; #REQUIRED> + + <!ELEMENT flags EMPTY> + <!-- df = don't fragment, mf = more fragments --> + <!ATTLIST flags + + + +Kennedy Informational [Page 8] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + reserved CDATA #FIXED "0" + df (may|dont) #REQUIRED + mf (last|more) #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks --> + <!ATTLIST offset + value %Digits; #REQUIRED> + + <!ELEMENT ttl EMPTY> + <!-- 0 <= ttl <= 255 --> + <!ATTLIST ttl + value %Digits; #REQUIRED> + + <!ELEMENT protocol EMPTY> + <!-- 0 <= protocol <= 255 (per IANA) --> + <!ATTLIST protocol + value %Digits; #REQUIRED> + + <!ELEMENT checksum EMPTY> + <!-- 0 <= checksum <= 65535 (over header only) --> + <!ATTLIST checksum + value %Digits; #REQUIRED> + + <!ELEMENT source EMPTY> + <!ATTLIST source + address %IP4Addr; #REQUIRED> + + <!ELEMENT destination EMPTY> + <!ATTLIST destination + address %IP4Addr; #REQUIRED> + + <!ELEMENT options ( end | noop | security | loose | strict | record + | stream | timestamp )*> + + <!ELEMENT end EMPTY> + <!ATTLIST end + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "0"> + + <!ELEMENT noop EMPTY> + <!ATTLIST noop + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "1"> + + <!ELEMENT security EMPTY> + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST security + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "2" + length CDATA #FIXED "11" + security %Sec; #REQUIRED + compartments %Compartments; #REQUIRED + handling %Handling; #REQUIRED + tcc %TCC; #REQUIRED> + <!ELEMENT loose (hop)+> + <!ATTLIST loose + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "3" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT hop EMPTY> + <!ATTLIST hop + address %IP4Addr; #REQUIRED> + + <!ELEMENT strict (hop)+> + <!ATTLIST strict + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "9" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT record (hop)+> + <!ATTLIST record + copied CDATA #FIXED "0" + class CDATA #FIXED "0" + number CDATA #FIXED "7" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT stream EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST stream + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "8" + length CDATA #FIXED "4" + id %Digits; #REQUIRED> + + <!ELEMENT timestamp (tstamp)+> + <!-- 0 <= oflw <=15 --> + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST timestamp + copied CDATA #FIXED "0" + class CDATA #FIXED "2" + number CDATA #FIXED "4" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED + oflw %Digits; #REQUIRED + flag (0 | 1 | 3) #REQUIRED> + + <!ELEMENT tstamp EMPTY> + <!ATTLIST tstamp + time %Digits; #REQUIRED + address %IP4Addr; #IMPLIED> + <!-- + padding to bring header to 32-bit boundary. + pad MUST be "0"* + --> + <!ELEMENT padding EMPTY> + <!ATTLIST padding + pad CDATA #REQUIRED> + + <!-- payload MUST be encoded as base-64 [RFC2045], as modified + by section 2.1 of this RFC --> + <!ELEMENT payload (CDATA)> + +7.2. TCPoXML DTD + + <!-- + DTD for TCP over XML. + Refer to this DTD as: + + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + --> + + <!-- the pseudoheader is only included for checksum calculations --> + <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)> + + <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset, + reserved, control, window, checksum, urgent, + tcp.options, padding)> + + <!ELEMENT src EMPTY> + <!-- 0 <= port <= 65,535 --> + <!ATTLIST src + port %Digits; #REQUIRED> + + <!ELEMENT dest EMPTY> + <!-- 0 <= port <= 65,535 --> + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST dest + port %Digits; #REQUIRED> + + <!ELEMENT sequence EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST sequence + number %Digits; #REQUIRED> + + <!ELEMENT acknowledgement EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST acknowledgement + number %Digits; #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= number <= 255 --> + <!ATTLIST offset + number %Digits; #REQUIRED> + + <!ELEMENT reserved EMPTY> + <!ATTLIST reserved + value CDATA #FIXED "0"> + + <!ELEMENT control EMPTY> + <!ATTLIST control + urg (0|1) #IMPLIED + ack (0|1) #IMPLIED + psh (0|1) #IMPLIED + rst (0|1) #IMPLIED + syn (0|1) #IMPLIED + fin (0|1) #IMPLIED> + + <!ELEMENT window EMPTY> + <!-- 0 <= size <= 65,535 --> + <!ATTLIST window + size %Digits; #REQUIRED> + + <!-- + checksum as in ip, but with + the following pseudo-header added into the tcp element: + --> + <!ELEMENT tcp.pseudoheader (source, destination, protocol, + tcp.length)> + + <!-- + tcp header + data length in octets. does not include the size of + + the pseudoheader. + --> + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ELEMENT tcp.length EMPTY> + <!ATTLIST tcp.length + value %Digits; #REQUIRED> + + <!ELEMENT urgent EMPTY> + <!-- 0 <= pointer <= 65,535 --> + <!ATTLIST urgent + pointer %Digits; #REQUIRED> + + <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+> + + <!ELEMENT tcp.end EMPTY> + <!ATTLIST tcp.end + kind CDATA #FIXED "0"> + + <!ELEMENT tcp.noop EMPTY> + <!ATTLIST tcp.noop + kind CDATA #FIXED "1"> + + <!ELEMENT tcp.mss EMPTY> + <!ATTLIST tcp.mss + kind CDATA #FIXED "2" + length CDATA #FIXED "4" + size %Digits; #REQUIRED> + +7.3. UDPoXML DTD + + <!-- + DTD for UDP over XML. + Refer to this DTD as: + + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + --> + + <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)> + + <!ELEMENT udp.header (src, dest, udp.length, checksum)> + + <!ELEMENT udp.pseudoheader (source, destination, protocol, + udp.length)> + + <!-- + udp header + data length in octets. does not include the size of + the pseudoheader. + --> + <!ELEMENT udp.length EMPTY> + <!ATTLIST udp.length + value %Digits; #REQUIRED> + + + +Kennedy Informational [Page 13] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +8. Security Considerations + + XML, as a subset of SGML, has the same security considerations as + specified in SGML Media Types [RFC1874]. Security considerations + that apply to IP, TCP and UDP also likely apply to BLOAT as it does + not attempt to correct for issues not related to message format. + +9. References + + [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt, + February 2002. (Work in Progress) + + [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC894] Hornig, C., "Standard for the Transmission of IP + Datagrams over Ethernet Networks.", RFC 894, April 1984. + + [RFC1042] Postel, J. and J. Reynolds, "Standard for the + Transmission of IP Datagrams Over IEEE 802 Networks", STD + 43, RFC 1042, February 1988. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", RFC 1123, October 1989. + + [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December + 1995. + + [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, + October 1996. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + + + + +Kennedy Informational [Page 14] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", + RFC 3080, March 2001. + + [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., + Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D., + "Simple Object Access Protocol (SOAP) 1.1" World Wide Web + Consortium Note, May 2000 http://www.w3.org/TR/SOAP/ + + [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible + Markup Language (XML)" World Wide Web Consortium + Recommendation REC- xml-19980210. + http://www.w3.org/TR/1998/REC-xml-19980210 + +10. Author's Address + + Hugh Kennedy + Mimezine + 1060 West Addison + Chicago, IL 60613 + USA + + EMail: kennedyh@engin.umich.edu + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 15] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 16] + + + + + + + +Network Working Group H. Kennedy +Request for Comments: 3252 Mimezine +Category: Informational 1 April 2002 + + + Binary Lexical Octet Ad-hoc Transport + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document defines a reformulation of IP and two transport layer + protocols (TCP and UDP) as XML applications. + +1. Introduction + +1.1. Overview + + This document describes the Binary Lexical Octet Ad-hoc Transport + (BLOAT): a reformulation of a widely-deployed network-layer protocol + (IP [RFC791]), and two associated transport layer protocols (TCP + [RFC793] and UDP [RFC768]) as XML [XML] applications. It also + describes methods for transporting BLOAT over Ethernet and IEEE 802 + networks as well as encapsulating BLOAT in IP for gatewaying BLOAT + across the public Internet. + +1.2. Motivation + + The wild popularity of XML as a basis for application-level protocols + such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple + Object Access Protocol [SOAP], and Jabber [JABBER] prompted + investigation into the possibility of extending the use of XML in the + protocol stack. Using XML at both the transport and network layer in + addition to the application layer would provide for an amazing amount + of power and flexibility while removing dependencies on proprietary + and hard-to-understand binary protocols. This protocol unification + would also allow applications to use a single XML parser for all + aspects of their operation, eliminating developer time spent figuring + out the intricacies of each new protocol, and moving the hard work of + + + + +Kennedy Informational [Page 1] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + parsing to the XML toolset. The use of XML also mitigates concerns + over "network vs. host" byte ordering which is at the root of many + network application bugs. + +1.3. Relation to Existing Protocols + + The reformulations specified in this RFC follow as closely as + possible the spirit of the RFCs on which they are based, and so MAY + contain elements or attributes that would not be needed in a pure + reworking (e.g. length attributes, which are implicit in XML.) + + The layering of network and transport protocols are maintained in + this RFC despite the optimizations that could be made if the line + were somewhat blurred (i.e. merging TCP and IP into a single, larger + element in the DTD) in order to foster future use of this protocol as + a basis for reformulating other protocols (such as ICMP.) + + Other than the encoding, the behavioral aspects of each of the + existing protocols remain unchanged. Routing, address spaces, TCP + congestion control, etc. behave as specified in the extant standards. + Adapting to new standards and experimental algorithm heuristics for + improving performance will become much easier once the move to BLOAT + has been completed. + +1.4. Requirement Levels + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 + [RFC2119]. + +2. IPoXML + + This protocol MUST be implemented to be compliant with this RFC. + IPoXML is the root protocol REQUIRED for effective use of TCPoXML + (section 3.) and higher-level application protocols. + + The DTD for this document type can be found in section 7.1. + + The routing of IPoXML can be easily implemented on hosts with an XML + parser, as the regular structure lends itself handily to parsing and + validation of the document/datagram and then processing the + destination address, TTL, and checksum before sending it on to its + next-hop. + + The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the + wider deployment of IPv4 and the fact that implementing IPv6 as XML + would have exceeded the 1500 byte Ethernet MTU. + + + +Kennedy Informational [Page 2] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + All BLOAT implementations MUST use - and specify - the UTF-8 encoding + of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well- + formed and include the XMLDecl. + +2.1. IP Description + + A number of items have changed (for the better) from the original IP + specification. Bit-masks, where present have been converted into + human-readable values. IP addresses are listed in their dotted- + decimal notation [RFC1123]. Length and checksum values are present + as decimal integers. + + To calculate the length and checksum fields of the IP element, a + canonicalized form of the element MUST be used. The canonical form + SHALL have no whitespace (including newline characters) between + elements and only one space character between attributes. There + SHALL NOT be a space following the last attribute in an element. + + An iterative method SHOULD be used to calculate checksums, as the + length field will vary based on the size of the checksum. + + The payload element bears special attention. Due to the character + set restrictions of XML, the payload of IP datagrams (which MAY + contain arbitrary data) MUST be encoded for transport. This RFC + REQUIRES the contents of the payload to be encoded in the base-64 + encoding of RFC 2045 [RFC2045], but removes the requirement that the + encoded output MUST be wrapped on 76-character lines. + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 3] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +2.2. Example Datagram + + The following is an example IPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + <ip> + <header length="474"> + <version value="4"/> + <tos precedence="Routine" delay="Normal" throughput="Normal" + relibility="Normal" reserved="0"/> + <total.length value="461"/> + <id value="1"/> + <flags reserved="0" df="dont" mf="last"/> + <offset value="0"/> + <ttl value="255"/> + <protocol value="6"/> + <checksum value="8707"/> + <source address="10.0.0.22"/> + <destination address="10.0.0.1"/> + <options> + <end copied="0" class="0" number="0"/> + </options> + <padding pad="0"/> + </header> + <payload> + </payload> + </ip> + +3. TCPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.2. + +3.1. TCP Description + + A number of items have changed from the original TCP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + To calculate the length and checksum fields of the TCP element, a + canonicalized form of the element MUST be used as in section 2.1. + + An iterative method SHOULD be used to calculate checksums as in + section 2.1. + + The payload element MUST be encoded as in section 2.1. + + + +Kennedy Informational [Page 4] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + The TCP offset element was expanded to a maximum of 255 from 16 to + allow for the increased size of the header in XML. + + TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + <tcp> + <tcp.header> + <src port="31415"/> + <dest port="42424"/> + <sequence number="322622954"/> + <acknowledgement number="689715995"/> + <offset number=""/> + <reserved value="0"/> + <control syn="1" ack="1"/> + <window size="1"/> + <urgent pointer="0"/> + <checksum value="2988"/> + <tcp.options> + <tcp.end kind="0"/> + </tcp.options> + <padding pad="0"/> + </tcp.header> + <payload> + </payload> + </tcp> + +4. UDPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.3. + +4.1. UDP Description + + A number of items have changed from the original UDP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + + + + + + +Kennedy Informational [Page 5] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + To calculate the length and checksum fields of the UDP element, a + canonicalized form of the element MUST be used as in section 2.1. An + iterative method SHOULD be used to calculate checksums as in section + 2.1. + + The payload element MUST be encoded as in section 2.1. + + UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + <udp> + <udp.header> + <src port="31415"/> + <dest port="42424"/> + <udp.length value="143"/> + <checksum value="2988"/> + </udp.header> + <payload> + </payload> + </udp> + +5. Network Transport + + This document provides for the transmission of BLOAT datagrams over + two common families of physical layer transport. Future RFCs will + address additional transports as routing vendors catch up to the + specification, and we begin to see BLOAT routed across the Internet + backbone. + +5.1. Ethernet + + BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the + exception that the type field of the Ethernet frame MUST contain the + value 0xBEEF. The first 5 octets of the Ethernet frame payload will + be 0x3c 3f 78 6d 6c ("<?xml".) + +5.2. IEEE 802 + + BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except + that the protocol type code for IPoXML is 0xBEEF. + + + + + +Kennedy Informational [Page 6] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +6. Gatewaying over IP + + In order to facilitate the gradual introduction of BLOAT into the + public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to + gateway between networks that run BLOAT natively on their LANs. + +7. DTDs + + The Transport DTDs (7.2. and 7.3.) build on the definitions in the + Network DTD (7.1.) + + The DTDs are referenced by their PubidLiteral and SystemLiteral (from + [XML]) although it is understood that most IPoXML implementations + will not need to pull down the DTD, as it will normally be embedded + in the implementation, and presents something of a catch-22 if you + need to load part of your network protocol over the network. + +7.1. IPoXML DTD + + <!-- + DTD for IP over XML. + Refer to this DTD as: + + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + --> + <!-- + DTD data types: + + Digits [0..9]+ + + Precedence "NetworkControl | InternetworkControl | + CRITIC | FlashOverride | Flash | Immediate | + Priority | Routine" + + IP4Addr "dotted-decimal" notation of [RFC1123] + + Class [0..3] + + Sec "Unclassified | Confidential | EFTO | MMMM | PROG | + Restricted | Secret | Top Secret | Reserved" + + Compartments [0..65535] + + Handling [0..65535] + + TCC [0..16777216] + + --> + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ENTITY % Digits "CDATA"> + <!ENTITY % Precedence "CDATA"> + <!ENTITY % IP4Addr "CDATA"> + <!ENTITY % Class "CDATA"> + <!ENTITY % Sec "CDATA"> + <!ENTITY % Compartments "CDATA"> + <!ENTITY % Handling "CDATA"> + <!ENTITY % TCC "CDATA"> + + <!ELEMENT ip (header, payload)> + + <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl, + protocol, checksum, source, destination, options, + padding)> + <!-- length of header in 32-bit words --> + <!ATTLIST header + length %Digits; #REQUIRED> + + <!ELEMENT version EMPTY> + <!-- ip version. SHOULD be "4" --> + <!ATTLIST version + value %Digits; #REQUIRED> + + <!ELEMENT tos EMPTY> + <!ATTLIST tos + precedence %Precedence; #REQUIRED + delay (normal | low) #REQUIRED + throughput (normal | high) #REQUIRED + relibility (normal | high) #REQUIRED + reserved CDATA #FIXED "0"> + + <!ELEMENT total.length EMPTY> + <!-- + total length of datagram (header and payload) in octets, MUST be + less than 65,535 (and SHOULD be less than 1024 for IPoXML on local + ethernets). + --> + <!ATTLIST total.length + value %Digits; #REQUIRED> + + <!ELEMENT id EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST id + value %Digits; #REQUIRED> + + <!ELEMENT flags EMPTY> + <!-- df = don't fragment, mf = more fragments --> + <!ATTLIST flags + + + +Kennedy Informational [Page 8] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + reserved CDATA #FIXED "0" + df (may|dont) #REQUIRED + mf (last|more) #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks --> + <!ATTLIST offset + value %Digits; #REQUIRED> + + <!ELEMENT ttl EMPTY> + <!-- 0 <= ttl <= 255 --> + <!ATTLIST ttl + value %Digits; #REQUIRED> + + <!ELEMENT protocol EMPTY> + <!-- 0 <= protocol <= 255 (per IANA) --> + <!ATTLIST protocol + value %Digits; #REQUIRED> + + <!ELEMENT checksum EMPTY> + <!-- 0 <= checksum <= 65535 (over header only) --> + <!ATTLIST checksum + value %Digits; #REQUIRED> + + <!ELEMENT source EMPTY> + <!ATTLIST source + address %IP4Addr; #REQUIRED> + + <!ELEMENT destination EMPTY> + <!ATTLIST destination + address %IP4Addr; #REQUIRED> + + <!ELEMENT options ( end | noop | security | loose | strict | record + | stream | timestamp )*> + + <!ELEMENT end EMPTY> + <!ATTLIST end + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "0"> + + <!ELEMENT noop EMPTY> + <!ATTLIST noop + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "1"> + + <!ELEMENT security EMPTY> + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST security + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "2" + length CDATA #FIXED "11" + security %Sec; #REQUIRED + compartments %Compartments; #REQUIRED + handling %Handling; #REQUIRED + tcc %TCC; #REQUIRED> + <!ELEMENT loose (hop)+> + <!ATTLIST loose + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "3" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT hop EMPTY> + <!ATTLIST hop + address %IP4Addr; #REQUIRED> + + <!ELEMENT strict (hop)+> + <!ATTLIST strict + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "9" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT record (hop)+> + <!ATTLIST record + copied CDATA #FIXED "0" + class CDATA #FIXED "0" + number CDATA #FIXED "7" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT stream EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST stream + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "8" + length CDATA #FIXED "4" + id %Digits; #REQUIRED> + + <!ELEMENT timestamp (tstamp)+> + <!-- 0 <= oflw <=15 --> + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST timestamp + copied CDATA #FIXED "0" + class CDATA #FIXED "2" + number CDATA #FIXED "4" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED + oflw %Digits; #REQUIRED + flag (0 | 1 | 3) #REQUIRED> + + <!ELEMENT tstamp EMPTY> + <!ATTLIST tstamp + time %Digits; #REQUIRED + address %IP4Addr; #IMPLIED> + <!-- + padding to bring header to 32-bit boundary. + pad MUST be "0"* + --> + <!ELEMENT padding EMPTY> + <!ATTLIST padding + pad CDATA #REQUIRED> + + <!-- payload MUST be encoded as base-64 [RFC2045], as modified + by section 2.1 of this RFC --> + <!ELEMENT payload (CDATA)> + +7.2. TCPoXML DTD + + <!-- + DTD for TCP over XML. + Refer to this DTD as: + + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + --> + + <!-- the pseudoheader is only included for checksum calculations --> + <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)> + + <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset, + reserved, control, window, checksum, urgent, + tcp.options, padding)> + + <!ELEMENT src EMPTY> + <!-- 0 <= port <= 65,535 --> + <!ATTLIST src + port %Digits; #REQUIRED> + + <!ELEMENT dest EMPTY> + <!-- 0 <= port <= 65,535 --> + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST dest + port %Digits; #REQUIRED> + + <!ELEMENT sequence EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST sequence + number %Digits; #REQUIRED> + + <!ELEMENT acknowledgement EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST acknowledgement + number %Digits; #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= number <= 255 --> + <!ATTLIST offset + number %Digits; #REQUIRED> + + <!ELEMENT reserved EMPTY> + <!ATTLIST reserved + value CDATA #FIXED "0"> + + <!ELEMENT control EMPTY> + <!ATTLIST control + urg (0|1) #IMPLIED + ack (0|1) #IMPLIED + psh (0|1) #IMPLIED + rst (0|1) #IMPLIED + syn (0|1) #IMPLIED + fin (0|1) #IMPLIED> + + <!ELEMENT window EMPTY> + <!-- 0 <= size <= 65,535 --> + <!ATTLIST window + size %Digits; #REQUIRED> + + <!-- + checksum as in ip, but with + the following pseudo-header added into the tcp element: + --> + <!ELEMENT tcp.pseudoheader (source, destination, protocol, + tcp.length)> + + <!-- + tcp header + data length in octets. does not include the size of + + the pseudoheader. + --> + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ELEMENT tcp.length EMPTY> + <!ATTLIST tcp.length + value %Digits; #REQUIRED> + + <!ELEMENT urgent EMPTY> + <!-- 0 <= pointer <= 65,535 --> + <!ATTLIST urgent + pointer %Digits; #REQUIRED> + + <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+> + + <!ELEMENT tcp.end EMPTY> + <!ATTLIST tcp.end + kind CDATA #FIXED "0"> + + <!ELEMENT tcp.noop EMPTY> + <!ATTLIST tcp.noop + kind CDATA #FIXED "1"> + + <!ELEMENT tcp.mss EMPTY> + <!ATTLIST tcp.mss + kind CDATA #FIXED "2" + length CDATA #FIXED "4" + size %Digits; #REQUIRED> + +7.3. UDPoXML DTD + + <!-- + DTD for UDP over XML. + Refer to this DTD as: + + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + --> + + <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)> + + <!ELEMENT udp.header (src, dest, udp.length, checksum)> + + <!ELEMENT udp.pseudoheader (source, destination, protocol, + udp.length)> + + <!-- + udp header + data length in octets. does not include the size of + the pseudoheader. + --> + <!ELEMENT udp.length EMPTY> + <!ATTLIST udp.length + value %Digits; #REQUIRED> + + + +Kennedy Informational [Page 13] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +8. Security Considerations + + XML, as a subset of SGML, has the same security considerations as + specified in SGML Media Types [RFC1874]. Security considerations + that apply to IP, TCP and UDP also likely apply to BLOAT as it does + not attempt to correct for issues not related to message format. + +9. References + + [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt, + February 2002. (Work in Progress) + + [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC894] Hornig, C., "Standard for the Transmission of IP + Datagrams over Ethernet Networks.", RFC 894, April 1984. + + [RFC1042] Postel, J. and J. Reynolds, "Standard for the + Transmission of IP Datagrams Over IEEE 802 Networks", STD + 43, RFC 1042, February 1988. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", RFC 1123, October 1989. + + [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December + 1995. + + [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, + October 1996. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + + + + +Kennedy Informational [Page 14] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", + RFC 3080, March 2001. + + [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., + Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D., + "Simple Object Access Protocol (SOAP) 1.1" World Wide Web + Consortium Note, May 2000 http://www.w3.org/TR/SOAP/ + + [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible + Markup Language (XML)" World Wide Web Consortium + Recommendation REC- xml-19980210. + http://www.w3.org/TR/1998/REC-xml-19980210 + +10. Author's Address + + Hugh Kennedy + Mimezine + 1060 West Addison + Chicago, IL 60613 + USA + + EMail: kennedyh@engin.umich.edu + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 15] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 16] + diff --git a/tests/auto/qnetworkreply/certs/aspiriniks.ca.crt b/tests/auto/qnetworkreply/certs/aspiriniks.ca.crt new file mode 100644 index 0000000000..36436b6248 --- /dev/null +++ b/tests/auto/qnetworkreply/certs/aspiriniks.ca.crt @@ -0,0 +1,22 @@ +-----BEGIN CERTIFICATE----- +MIIDnDCCAoQCCQDV3otC4hs2KTANBgkqhkiG9w0BAQUFADCBjzELMAkGA1UEBhMC +Tk8xDTALBgNVBAgTBE9zbG8xDTALBgNVBAcTBE9zbG8xDzANBgNVBAoTBlRUIEFT +QTEOMAwGA1UECxMFUVQgU1cxHDAaBgNVBAMTE2FzcGlyaW5pa3MudHJvbGwubm8x +IzAhBgkqhkiG9w0BCQEWFGFiYWJpY0B0cm9sbHRlY2guY29tMB4XDTA4MTEwMTA4 +NTcyOFoXDTA5MTEwMTA4NTcyOFowgY8xCzAJBgNVBAYTAk5PMQ0wCwYDVQQIEwRP +c2xvMQ0wCwYDVQQHEwRPc2xvMQ8wDQYDVQQKEwZUVCBBU0ExDjAMBgNVBAsTBVFU +IFNXMRwwGgYDVQQDExNhc3BpcmluaWtzLnRyb2xsLm5vMSMwIQYJKoZIhvcNAQkB +FhRhYmFiaWNAdHJvbGx0ZWNoLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC +AQoCggEBAMV2bMD1DN3DMgbxU3DXw2i7EWGDXcWjTDtdHvqgIb+9nHqo3MJSrzJy +qgEPoOsXqswMla9wDPZAsWv5gVAmVSqpy2lfEgfY7LaSHiGD75seF7zIy+CxREHW +DofHXpJGGJpBCZEKQt2HfHu3+yAYNPucN78tWNZAcPbUg5tfxMZeepRimAZNIxBI +93SDrl/f9Ka7hvPSzUQsnp8hfdpHlFPFznKfD6yPrjxgz2mT9efavJ4DhtyIa4m+ +paiX515CidDz4A8CFxKZbYvuqq1ilibF/si2so9VhALC77ZcAJP1IMuT8T+WUCxq +skJqiSCncl0Hgr+ba8MDGF9UQYowgjMCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEA +KcJuNUHvjB8ok3cnTmQEeF0LPPkgj28Tqb5TFB8xpVfRI+wvTYsHsmGdOKCgYJ3a +7VflIsr63ojG8/rXK8H/cx2o2f2Hr3liJdi1UnoLDDRjBqGGz7JNuMreYokPvIbm +eP01mVyK4PO2iYRwHUIAw5eeB1vMWKX2z95MupD+HRLtmGyaLALg8aQxj5N84Ewl +eU2PQfhv8A1wj7aL17kfEUxDerQ1kUzlThJMV1J8Dl0l4C9N8evQkelROJU00i46 +oJikA8BW6EpgbnGyNyyj5Loy4wLPKew9nTS8MCJ5xPMQc0urbY/VzuOeUK7WQof7 +xOFSsRAVyQv+yqgmcZMCtg== +-----END CERTIFICATE----- diff --git a/tests/auto/qnetworkreply/certs/fluke.cert b/tests/auto/qnetworkreply/certs/fluke.cert new file mode 100644 index 0000000000..069fa6b341 --- /dev/null +++ b/tests/auto/qnetworkreply/certs/fluke.cert @@ -0,0 +1,75 @@ +Certificate: + Data: + Version: 3 (0x2) + Serial Number: 0 (0x0) + Signature Algorithm: sha1WithRSAEncryption + Issuer: C=NO, ST=Oslo, L=Nydalen, O=Nokia Corporation and/or its subsidiary(-ies), OU=Development, CN=fluke.troll.no/emailAddress=ahanssen@trolltech.com + Validity + Not Before: Dec 4 01:10:32 2007 GMT + Not After : Apr 21 01:10:32 2035 GMT + Subject: C=NO, ST=Oslo, O=Nokia Corporation and/or its subsidiary(-ies), OU=Development, CN=fluke.troll.no + Subject Public Key Info: + Public Key Algorithm: rsaEncryption + RSA Public Key: (1024 bit) + Modulus (1024 bit): + 00:a7:c8:a0:4a:c4:19:05:1b:66:ba:32:e2:d2:f1: + 1c:6f:17:82:e4:39:2e:01:51:90:db:04:34:32:11: + 21:c2:0d:6f:59:d8:53:90:54:3f:83:8f:a9:d3:b3: + d5:ee:1a:9b:80:ae:c3:25:c9:5e:a5:af:4b:60:05: + aa:a0:d1:91:01:1f:ca:04:83:e3:58:1c:99:32:45: + 84:70:72:58:03:98:4a:63:8b:41:f5:08:49:d2:91: + 02:60:6b:e4:64:fe:dd:a0:aa:74:08:e9:34:4c:91: + 5f:12:3d:37:4d:54:2c:ad:7f:5b:98:60:36:02:8c: + 3b:f6:45:f3:27:6a:9b:94:9d + Exponent: 65537 (0x10001) + X509v3 extensions: + X509v3 Basic Constraints: + CA:FALSE + Netscape Comment: + OpenSSL Generated Certificate + X509v3 Subject Key Identifier: + 21:85:04:3D:23:01:66:E5:F7:9F:1A:84:24:8A:AF:0A:79:F4:E5:AC + X509v3 Authority Key Identifier: + DirName:/C=NO/ST=Oslo/L=Nydalen/O=Nokia Corporation and/or its subsidiary(-ies)/OU=Development/CN=fluke.troll.no/emailAddress=ahanssen@trolltech.com + serial:8E:A8:B4:E8:91:B7:54:2E + + Signature Algorithm: sha1WithRSAEncryption + 6d:57:5f:d1:05:43:f0:62:05:ec:2a:71:a5:dc:19:08:f2:c4: + a6:bd:bb:25:d9:ca:89:01:0e:e4:cf:1f:c1:8c:c8:24:18:35: + 53:59:7b:c0:43:b4:32:e6:98:b2:a6:ef:15:05:0b:48:5f:e1: + a0:0c:97:a9:a1:77:d8:35:18:30:bc:a9:8f:d3:b7:54:c7:f1: + a9:9e:5d:e6:19:bf:f6:3c:5b:2b:d8:e4:3e:62:18:88:8b:d3: + 24:e1:40:9b:0c:e6:29:16:62:ab:ea:05:24:70:36:aa:55:93: + ef:02:81:1b:23:10:a2:04:eb:56:95:75:fc:f8:94:b1:5d:42: + c5:3f:36:44:85:5d:3a:2e:90:46:8a:a2:b9:6f:87:ae:0c:15: + 40:19:31:90:fc:3b:25:bb:ae:f1:66:13:0d:85:90:d9:49:34: + 8f:f2:5d:f9:7a:db:4d:5d:27:f6:76:9d:35:8c:06:a6:4c:a3: + b1:b2:b6:6f:1d:d7:a3:00:fd:72:eb:9e:ea:44:a1:af:21:34: + 7d:c7:42:e2:49:91:19:8b:c0:ad:ba:82:80:a8:71:70:f4:35: + 31:91:63:84:20:95:e9:60:af:64:8b:cc:ff:3d:8a:76:74:3d: + c8:55:6d:e4:8e:c3:2b:1c:e8:42:18:ae:9f:e6:6b:9c:34:06: + ec:6a:f2:c3 +-----BEGIN CERTIFICATE----- +MIIEEzCCAvugAwIBAgIBADANBgkqhkiG9w0BAQUFADCBnDELMAkGA1UEBhMCTk8x +DTALBgNVBAgTBE9zbG8xEDAOBgNVBAcTB055ZGFsZW4xFjAUBgNVBAoTDVRyb2xs +dGVjaCBBU0ExFDASBgNVBAsTC0RldmVsb3BtZW50MRcwFQYDVQQDEw5mbHVrZS50 +cm9sbC5ubzElMCMGCSqGSIb3DQEJARYWYWhhbnNzZW5AdHJvbGx0ZWNoLmNvbTAe +Fw0wNzEyMDQwMTEwMzJaFw0zNTA0MjEwMTEwMzJaMGMxCzAJBgNVBAYTAk5PMQ0w +CwYDVQQIEwRPc2xvMRYwFAYDVQQKEw1Ucm9sbHRlY2ggQVNBMRQwEgYDVQQLEwtE +ZXZlbG9wbWVudDEXMBUGA1UEAxMOZmx1a2UudHJvbGwubm8wgZ8wDQYJKoZIhvcN +AQEBBQADgY0AMIGJAoGBAKfIoErEGQUbZroy4tLxHG8XguQ5LgFRkNsENDIRIcIN +b1nYU5BUP4OPqdOz1e4am4CuwyXJXqWvS2AFqqDRkQEfygSD41gcmTJFhHByWAOY +SmOLQfUISdKRAmBr5GT+3aCqdAjpNEyRXxI9N01ULK1/W5hgNgKMO/ZF8ydqm5Sd +AgMBAAGjggEaMIIBFjAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NM +IEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUIYUEPSMBZuX3nxqEJIqv +Cnn05awwgbsGA1UdIwSBszCBsKGBoqSBnzCBnDELMAkGA1UEBhMCTk8xDTALBgNV +BAgTBE9zbG8xEDAOBgNVBAcTB055ZGFsZW4xFjAUBgNVBAoTDVRyb2xsdGVjaCBB +U0ExFDASBgNVBAsTC0RldmVsb3BtZW50MRcwFQYDVQQDEw5mbHVrZS50cm9sbC5u +bzElMCMGCSqGSIb3DQEJARYWYWhhbnNzZW5AdHJvbGx0ZWNoLmNvbYIJAI6otOiR +t1QuMA0GCSqGSIb3DQEBBQUAA4IBAQBtV1/RBUPwYgXsKnGl3BkI8sSmvbsl2cqJ +AQ7kzx/BjMgkGDVTWXvAQ7Qy5piypu8VBQtIX+GgDJepoXfYNRgwvKmP07dUx/Gp +nl3mGb/2PFsr2OQ+YhiIi9Mk4UCbDOYpFmKr6gUkcDaqVZPvAoEbIxCiBOtWlXX8 ++JSxXULFPzZEhV06LpBGiqK5b4euDBVAGTGQ/Dslu67xZhMNhZDZSTSP8l35ettN +XSf2dp01jAamTKOxsrZvHdejAP1y657qRKGvITR9x0LiSZEZi8CtuoKAqHFw9DUx +kWOEIJXpYK9ki8z/PYp2dD3IVW3kjsMrHOhCGK6f5mucNAbsavLD +-----END CERTIFICATE----- diff --git a/tests/auto/qnetworkreply/certs/fluke.key b/tests/auto/qnetworkreply/certs/fluke.key new file mode 100644 index 0000000000..9d1664d609 --- /dev/null +++ b/tests/auto/qnetworkreply/certs/fluke.key @@ -0,0 +1,15 @@ +-----BEGIN RSA PRIVATE KEY----- +MIICXAIBAAKBgQCnyKBKxBkFG2a6MuLS8RxvF4LkOS4BUZDbBDQyESHCDW9Z2FOQ +VD+Dj6nTs9XuGpuArsMlyV6lr0tgBaqg0ZEBH8oEg+NYHJkyRYRwclgDmEpji0H1 +CEnSkQJga+Rk/t2gqnQI6TRMkV8SPTdNVCytf1uYYDYCjDv2RfMnapuUnQIDAQAB +AoGANFzLkanTeSGNFM0uttBipFT9F4a00dqHz6JnO7zXAT26I5r8sU1pqQBb6uLz +/+Qz5Zwk8RUAQcsMRgJetuPQUb0JZjF6Duv24hNazqXBCu7AZzUenjafwmKC/8ri +KpX3fTwqzfzi//FKGgbXQ80yykSSliDL3kn/drATxsLCgQECQQDXhEFWLJ0vVZ1s +1Ekf+3NITE+DR16X+LQ4W6vyEHAjTbaNWtcTKdAWLA2l6N4WAAPYSi6awm+zMxx4 +VomVTsjdAkEAx0z+e7natLeFcrrq8pbU+wa6SAP1VfhQWKitxL1e7u/QO90NCpxE +oQYKzMkmmpOOFjQwEMAy1dvFMbm4LHlewQJAC/ksDBaUcQHHqjktCtrUb8rVjAyW +A8lscckeB2fEYyG5J6dJVaY4ClNOOs5yMDS2Afk1F6H/xKvtQ/5CzInA/QJATDub +K+BPU8jO9q+gpuIi3VIZdupssVGmCgObVCHLakG4uO04y9IyPhV9lA9tALtoIf4c +VIvv5fWGXBrZ48kZAQJBAJmVCdzQxd9LZI5vxijUCj5EI4e+x5DRqVUvyP8KCZrC +AiNyoDP85T+hBZaSXK3aYGpVwelyj3bvo1GrTNwNWLw= +-----END RSA PRIVATE KEY----- diff --git a/tests/auto/qnetworkreply/certs/qt-test-server-cacert.pem b/tests/auto/qnetworkreply/certs/qt-test-server-cacert.pem new file mode 100644 index 0000000000..25bd4046e8 --- /dev/null +++ b/tests/auto/qnetworkreply/certs/qt-test-server-cacert.pem @@ -0,0 +1,17 @@ +-----BEGIN CERTIFICATE----- +MIICrTCCAhYCCQCdDn5rci6VDjANBgkqhkiG9w0BAQQFADCBmjEOMAwGA1UEChMF +Tm9raWExFDASBgNVBAsTC1F0IFNvZnR3YXJlMSIwIAYJKoZIhvcNAQkBFhNub2Jv +ZHlAbm9kb21haW4ub3JnMQ0wCwYDVQQHEwRPc2xvMQ0wCwYDVQQIEwRPc2xvMQsw +CQYDVQQGEwJOTzEjMCEGA1UEAxMacXQtdGVzdC1zZXJ2ZXIucXQtdGVzdC1uZXQw +HhcNMDkwNzEwMDc0MTIzWhcNMTkwNzA4MDc0MTIzWjCBmjEOMAwGA1UEChMFTm9r +aWExFDASBgNVBAsTC1F0IFNvZnR3YXJlMSIwIAYJKoZIhvcNAQkBFhNub2JvZHlA +bm9kb21haW4ub3JnMQ0wCwYDVQQHEwRPc2xvMQ0wCwYDVQQIEwRPc2xvMQswCQYD +VQQGEwJOTzEjMCEGA1UEAxMacXQtdGVzdC1zZXJ2ZXIucXQtdGVzdC1uZXQwgZ8w +DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM2q22/WNMmn8cC+5EEYGeICySLmp9W6 +Ay6eKHr0Xxp3X3epETuPfvAuxp7rOtkS18EMUegkUj8jw0IMEcbyHKFC/rTCaYOt +93CxGBXMIChiMPAsFeYzGa/D6xzAkfcRaJRQ+Ek3CDLXPnXfo7xpABXezYcPXAJr +gsgBfWrwHdxzAgMBAAEwDQYJKoZIhvcNAQEEBQADgYEAy7YOLCZABQy2Ygkchq1I ++TUpvMn+gLwAyW8TNErM1V4lNY2+K78RawzKx3SqM97ymCy4TD45EA3A2gmi32NI +xSKBNjFyzngUqsXBdcSasALiowlZCiJrGwlGX5qCkBlxXvJeUEbuJLPYVl5FBjXZ +6o00K4cSPCqtqUez7WSmDZU= +-----END CERTIFICATE----- diff --git a/tests/auto/qnetworkreply/certs/server.key b/tests/auto/qnetworkreply/certs/server.key new file mode 100644 index 0000000000..9d1664d609 --- /dev/null +++ b/tests/auto/qnetworkreply/certs/server.key @@ -0,0 +1,15 @@ +-----BEGIN RSA PRIVATE KEY----- +MIICXAIBAAKBgQCnyKBKxBkFG2a6MuLS8RxvF4LkOS4BUZDbBDQyESHCDW9Z2FOQ +VD+Dj6nTs9XuGpuArsMlyV6lr0tgBaqg0ZEBH8oEg+NYHJkyRYRwclgDmEpji0H1 +CEnSkQJga+Rk/t2gqnQI6TRMkV8SPTdNVCytf1uYYDYCjDv2RfMnapuUnQIDAQAB +AoGANFzLkanTeSGNFM0uttBipFT9F4a00dqHz6JnO7zXAT26I5r8sU1pqQBb6uLz +/+Qz5Zwk8RUAQcsMRgJetuPQUb0JZjF6Duv24hNazqXBCu7AZzUenjafwmKC/8ri +KpX3fTwqzfzi//FKGgbXQ80yykSSliDL3kn/drATxsLCgQECQQDXhEFWLJ0vVZ1s +1Ekf+3NITE+DR16X+LQ4W6vyEHAjTbaNWtcTKdAWLA2l6N4WAAPYSi6awm+zMxx4 +VomVTsjdAkEAx0z+e7natLeFcrrq8pbU+wa6SAP1VfhQWKitxL1e7u/QO90NCpxE +oQYKzMkmmpOOFjQwEMAy1dvFMbm4LHlewQJAC/ksDBaUcQHHqjktCtrUb8rVjAyW +A8lscckeB2fEYyG5J6dJVaY4ClNOOs5yMDS2Afk1F6H/xKvtQ/5CzInA/QJATDub +K+BPU8jO9q+gpuIi3VIZdupssVGmCgObVCHLakG4uO04y9IyPhV9lA9tALtoIf4c +VIvv5fWGXBrZ48kZAQJBAJmVCdzQxd9LZI5vxijUCj5EI4e+x5DRqVUvyP8KCZrC +AiNyoDP85T+hBZaSXK3aYGpVwelyj3bvo1GrTNwNWLw= +-----END RSA PRIVATE KEY----- diff --git a/tests/auto/qnetworkreply/certs/server.pem b/tests/auto/qnetworkreply/certs/server.pem new file mode 100644 index 0000000000..67eb495319 --- /dev/null +++ b/tests/auto/qnetworkreply/certs/server.pem @@ -0,0 +1,24 @@ +-----BEGIN CERTIFICATE----- +MIIEEzCCAvugAwIBAgIBADANBgkqhkiG9w0BAQUFADCBnDELMAkGA1UEBhMCTk8x +DTALBgNVBAgTBE9zbG8xEDAOBgNVBAcTB055ZGFsZW4xFjAUBgNVBAoTDVRyb2xs +dGVjaCBBU0ExFDASBgNVBAsTC0RldmVsb3BtZW50MRcwFQYDVQQDEw5mbHVrZS50 +cm9sbC5ubzElMCMGCSqGSIb3DQEJARYWYWhhbnNzZW5AdHJvbGx0ZWNoLmNvbTAe +Fw0wNzEyMDQwMTEwMzJaFw0zNTA0MjEwMTEwMzJaMGMxCzAJBgNVBAYTAk5PMQ0w +CwYDVQQIEwRPc2xvMRYwFAYDVQQKEw1Ucm9sbHRlY2ggQVNBMRQwEgYDVQQLEwtE +ZXZlbG9wbWVudDEXMBUGA1UEAxMOZmx1a2UudHJvbGwubm8wgZ8wDQYJKoZIhvcN +AQEBBQADgY0AMIGJAoGBAKfIoErEGQUbZroy4tLxHG8XguQ5LgFRkNsENDIRIcIN +b1nYU5BUP4OPqdOz1e4am4CuwyXJXqWvS2AFqqDRkQEfygSD41gcmTJFhHByWAOY +SmOLQfUISdKRAmBr5GT+3aCqdAjpNEyRXxI9N01ULK1/W5hgNgKMO/ZF8ydqm5Sd +AgMBAAGjggEaMIIBFjAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NM +IEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUIYUEPSMBZuX3nxqEJIqv +Cnn05awwgbsGA1UdIwSBszCBsKGBoqSBnzCBnDELMAkGA1UEBhMCTk8xDTALBgNV +BAgTBE9zbG8xEDAOBgNVBAcTB055ZGFsZW4xFjAUBgNVBAoTDVRyb2xsdGVjaCBB +U0ExFDASBgNVBAsTC0RldmVsb3BtZW50MRcwFQYDVQQDEw5mbHVrZS50cm9sbC5u +bzElMCMGCSqGSIb3DQEJARYWYWhhbnNzZW5AdHJvbGx0ZWNoLmNvbYIJAI6otOiR +t1QuMA0GCSqGSIb3DQEBBQUAA4IBAQBtV1/RBUPwYgXsKnGl3BkI8sSmvbsl2cqJ +AQ7kzx/BjMgkGDVTWXvAQ7Qy5piypu8VBQtIX+GgDJepoXfYNRgwvKmP07dUx/Gp +nl3mGb/2PFsr2OQ+YhiIi9Mk4UCbDOYpFmKr6gUkcDaqVZPvAoEbIxCiBOtWlXX8 ++JSxXULFPzZEhV06LpBGiqK5b4euDBVAGTGQ/Dslu67xZhMNhZDZSTSP8l35ettN +XSf2dp01jAamTKOxsrZvHdejAP1y657qRKGvITR9x0LiSZEZi8CtuoKAqHFw9DUx +kWOEIJXpYK9ki8z/PYp2dD3IVW3kjsMrHOhCGK6f5mucNAbsavLD +-----END CERTIFICATE----- diff --git a/tests/auto/qnetworkreply/echo/echo.pro b/tests/auto/qnetworkreply/echo/echo.pro new file mode 100644 index 0000000000..74b0bfcab3 --- /dev/null +++ b/tests/auto/qnetworkreply/echo/echo.pro @@ -0,0 +1,6 @@ +SOURCES += main.cpp +QT = core +CONFIG -= app_bundle debug_and_release_target +CONFIG += console + +symbian:TARGET.CAPABILITY="ALL -TCB" diff --git a/tests/auto/qnetworkreply/echo/main.cpp b/tests/auto/qnetworkreply/echo/main.cpp new file mode 100644 index 0000000000..f2d8256193 --- /dev/null +++ b/tests/auto/qnetworkreply/echo/main.cpp @@ -0,0 +1,62 @@ +/**************************************************************************** +** +** Copyright (C) 2011 Nokia Corporation and/or its subsidiary(-ies). +** All rights reserved. +** Contact: Nokia Corporation (qt-info@nokia.com) +** +** This file is part of the test suite of the Qt Toolkit. +** +** $QT_BEGIN_LICENSE:LGPL$ +** No Commercial Usage +** This file contains pre-release code and may not be distributed. +** You may use this file in accordance with the terms and conditions +** contained in the Technology Preview License Agreement accompanying +** this package. +** +** GNU Lesser General Public License Usage +** Alternatively, this file may be used under the terms of the GNU Lesser +** General Public License version 2.1 as published by the Free Software +** Foundation and appearing in the file LICENSE.LGPL included in the +** packaging of this file. Please review the following information to +** ensure the GNU Lesser General Public License version 2.1 requirements +** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html. +** +** In addition, as a special exception, Nokia gives you certain additional +** rights. These rights are described in the Nokia Qt LGPL Exception +** version 1.1, included in the file LGPL_EXCEPTION.txt in this package. +** +** If you have questions regarding the use of this file, please contact +** Nokia at qt-info@nokia.com. +** +** +** +** +** +** +** +** +** $QT_END_LICENSE$ +** +****************************************************************************/ + + +#include <QtCore> + +int main(int argc, char **) +{ + if (argc < 2) { + printf("usage: echo\n"); + printf("echos all its input to its output.\n"); + return 1; + } + + QFile file; + file.open(stdin, QFile::ReadWrite); + QByteArray data = file.readAll(); + file.close(); + + file.open(stdout, QFile::WriteOnly); + file.write(data); + file.close(); + return 0; +} diff --git a/tests/auto/qnetworkreply/empty b/tests/auto/qnetworkreply/empty new file mode 100644 index 0000000000..e69de29bb2 --- /dev/null +++ b/tests/auto/qnetworkreply/empty diff --git a/tests/auto/qnetworkreply/image1.jpg b/tests/auto/qnetworkreply/image1.jpg Binary files differnew file mode 100644 index 0000000000..dba31c1901 --- /dev/null +++ b/tests/auto/qnetworkreply/image1.jpg diff --git a/tests/auto/qnetworkreply/image2.jpg b/tests/auto/qnetworkreply/image2.jpg Binary files differnew file mode 100644 index 0000000000..72936e2de6 --- /dev/null +++ b/tests/auto/qnetworkreply/image2.jpg diff --git a/tests/auto/qnetworkreply/image3.jpg b/tests/auto/qnetworkreply/image3.jpg Binary files differnew file mode 100644 index 0000000000..cede519938 --- /dev/null +++ b/tests/auto/qnetworkreply/image3.jpg diff --git a/tests/auto/qnetworkreply/qnetworkreply.pro b/tests/auto/qnetworkreply/qnetworkreply.pro new file mode 100644 index 0000000000..86d3155c05 --- /dev/null +++ b/tests/auto/qnetworkreply/qnetworkreply.pro @@ -0,0 +1,7 @@ +TEMPLATE = subdirs +SUBDIRS = test + +requires(contains(QT_CONFIG,private_tests)) + +!wince*:SUBDIRS += echo +symbian: TARGET.CAPABILITY = NetworkServices diff --git a/tests/auto/qnetworkreply/qnetworkreply.qrc b/tests/auto/qnetworkreply/qnetworkreply.qrc new file mode 100644 index 0000000000..85ca6312af --- /dev/null +++ b/tests/auto/qnetworkreply/qnetworkreply.qrc @@ -0,0 +1,5 @@ +<!DOCTYPE RCC><RCC version="1.0"> +<qresource> + <file>resource</file> +</qresource> +</RCC> diff --git a/tests/auto/qnetworkreply/resource b/tests/auto/qnetworkreply/resource new file mode 100644 index 0000000000..e9b146042d --- /dev/null +++ b/tests/auto/qnetworkreply/resource @@ -0,0 +1,283 @@ + + + + + + +Network Working Group L. Masinter +Request for Comments: 2397 Xerox Corporation +Category: Standards Track August 1998 + + + The "data" URL scheme + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +1. Abstract + + A new URL scheme, "data", is defined. It allows inclusion of small + data items as "immediate" data, as if it had been included + externally. + +2. Description + + Some applications that use URLs also have a need to embed (small) + media type data directly inline. This document defines a new URL + scheme that would work like 'immediate addressing'. The URLs are of + the form: + + data:[<mediatype>][;base64],<data> + + The <mediatype> is an Internet media type specification (with + optional parameters.) The appearance of ";base64" means that the data + is encoded as base64. Without ";base64", the data (as a sequence of + octets) is represented using ASCII encoding for octets inside the + range of safe URL characters and using the standard %xx hex encoding + of URLs for octets outside that range. If <mediatype> is omitted, it + defaults to text/plain;charset=US-ASCII. As a shorthand, + "text/plain" can be omitted but the charset parameter supplied. + + The "data:" URL scheme is only useful for short values. Note that + some applications that use URLs may impose a length limit; for + example, URLs embedded within <A> anchors in HTML have a length limit + determined by the SGML declaration for HTML [RFC1866]. The LITLEN + (1024) limits the number of characters which can appear in a single + + + +Masinter Standards Track [Page 1] + +RFC 2397 The "data" URL scheme August 1998 + + + attribute value literal, the ATTSPLEN (2100) limits the sum of all + lengths of all attribute value specifications which appear in a tag, + and the TAGLEN (2100) limits the overall length of a tag. + + The "data" URL scheme has no relative URL forms. + +3. Syntax + + dataurl := "data:" [ mediatype ] [ ";base64" ] "," data + mediatype := [ type "/" subtype ] *( ";" parameter ) + data := *urlchar + parameter := attribute "=" value + + where "urlchar" is imported from [RFC2396], and "type", "subtype", + "attribute" and "value" are the corresponding tokens from [RFC2045], + represented using URL escaped encoding of [RFC2396] as necessary. + + Attribute values in [RFC2045] are allowed to be either represented as + tokens or as quoted strings. However, within a "data" URL, the + "quoted-string" representation would be awkward, since the quote mark + is itself not a valid urlchar. For this reason, parameter values + should use the URL Escaped encoding instead of quoted string if the + parameter values contain any "tspecial". + + The ";base64" extension is distinguishable from a content-type + parameter by the fact that it doesn't have a following "=" sign. + +4. Examples + + A data URL might be used for arbitrary types of data. The URL + + data:,A%20brief%20note + + encodes the text/plain string "A brief note", which might be useful + in a footnote link. + + The HTML fragment: + + <IMG + SRC="data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP///ywAAAAAMAAw + AAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFz + ByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSp + a/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJl + ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uis + F81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f1cf5VWzXyym7PH + hhx4dbgYKAAA7" + ALT="Larry"> + + + + +Masinter Standards Track [Page 2] + +RFC 2397 The "data" URL scheme August 1998 + + + could be used for a small inline image in a HTML document. (The + embedded image is probably near the limit of utility. For anything + else larger, data URLs are likely to be inappropriate.) + + A data URL scheme's media type specification can include other + parameters; for example, one might specify a charset parameter. + + data:text/plain;charset=iso-8859-7,%be%fg%be + + can be used for a short sequence of greek characters. + + Some applications may use the "data" URL scheme in order to provide + setup parameters for other kinds of networking applications. For + example, one might create a media type + application/vnd-xxx-query + + whose content consists of a query string and a database identifier + for the "xxx" vendor's databases. A URL of the form: + + data:application/vnd-xxx- + query,select_vcount,fcol_from_fieldtable/local + + could then be used in a local application to launch the "helper" for + application/vnd-xxx-query and give it the immediate data included. + +5. History + + This idea was originally proposed August 1995. Some versions of the + data URL scheme have been used in the definition of VRML, and a + version has appeared as part of a proposal for embedded data in HTML. + Various changes have been made, based on requests, to elide the media + type, pack the indication of the base64 encoding more tightly, and + eliminate "quoted printable" as an encoding since it would not easily + yield valid URLs without additional %xx encoding, which itself is + sufficient. The "data" URL scheme is in use in VRML, new applications + of HTML, and various commercial products. It is being used for object + parameters in Java and ActiveX applications. + +6. Security + + Interpretation of the data within a "data" URL has the same security + considerations as any implementation of the given media type. An + application should not interpret the contents of a data URL which is + marked with a media type that has been disallowed for processing by + the application's configuration. + + + + + + +Masinter Standards Track [Page 3] + +RFC 2397 The "data" URL scheme August 1998 + + + Sites which use firewall proxies to disallow the retrieval of certain + media types (such as application script languages or types with known + security problems) will find it difficult to screen against the + inclusion of such types using the "data" URL scheme. However, they + should be aware of the threat and take whatever precautions are + considered necessary within their domain. + + The effect of using long "data" URLs in applications is currently + unknown; some software packages may exhibit unreasonable behavior + when confronted with data that exceeds its allocated buffer size. + +7. References + + [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, + "Uniform Resource Identifiers (URI): Generic Syntax", RFC + 2396, August 1998. + + [RFC1866] Berners-Lee, T., and D. Connolly, "Hypertext Markup + Language - 2.0.", RFC 1866, November 1995. + + [RFC2045] Freed N., and N. Borenstein., "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + +Author contact information: + + Larry Masinter + Xerox Palo Alto Research Center + 3333 Coyote Hill Road + Palo Alto, CA 94304 + + EMail: masinter@parc.xerox.com + + + + + + + + + + + + + + + + + + + +Masinter Standards Track [Page 4] + +RFC 2397 The "data" URL scheme August 1998 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1998). 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. + + + + + + + + + + + + + + + + + + + + + + + + +Masinter Standards Track [Page 5] + diff --git a/tests/auto/qnetworkreply/rfc3252.txt b/tests/auto/qnetworkreply/rfc3252.txt new file mode 100644 index 0000000000..b80c61bf0a --- /dev/null +++ b/tests/auto/qnetworkreply/rfc3252.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group H. Kennedy +Request for Comments: 3252 Mimezine +Category: Informational 1 April 2002 + + + Binary Lexical Octet Ad-hoc Transport + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document defines a reformulation of IP and two transport layer + protocols (TCP and UDP) as XML applications. + +1. Introduction + +1.1. Overview + + This document describes the Binary Lexical Octet Ad-hoc Transport + (BLOAT): a reformulation of a widely-deployed network-layer protocol + (IP [RFC791]), and two associated transport layer protocols (TCP + [RFC793] and UDP [RFC768]) as XML [XML] applications. It also + describes methods for transporting BLOAT over Ethernet and IEEE 802 + networks as well as encapsulating BLOAT in IP for gatewaying BLOAT + across the public Internet. + +1.2. Motivation + + The wild popularity of XML as a basis for application-level protocols + such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple + Object Access Protocol [SOAP], and Jabber [JABBER] prompted + investigation into the possibility of extending the use of XML in the + protocol stack. Using XML at both the transport and network layer in + addition to the application layer would provide for an amazing amount + of power and flexibility while removing dependencies on proprietary + and hard-to-understand binary protocols. This protocol unification + would also allow applications to use a single XML parser for all + aspects of their operation, eliminating developer time spent figuring + out the intricacies of each new protocol, and moving the hard work of + + + + +Kennedy Informational [Page 1] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + parsing to the XML toolset. The use of XML also mitigates concerns + over "network vs. host" byte ordering which is at the root of many + network application bugs. + +1.3. Relation to Existing Protocols + + The reformulations specified in this RFC follow as closely as + possible the spirit of the RFCs on which they are based, and so MAY + contain elements or attributes that would not be needed in a pure + reworking (e.g. length attributes, which are implicit in XML.) + + The layering of network and transport protocols are maintained in + this RFC despite the optimizations that could be made if the line + were somewhat blurred (i.e. merging TCP and IP into a single, larger + element in the DTD) in order to foster future use of this protocol as + a basis for reformulating other protocols (such as ICMP.) + + Other than the encoding, the behavioral aspects of each of the + existing protocols remain unchanged. Routing, address spaces, TCP + congestion control, etc. behave as specified in the extant standards. + Adapting to new standards and experimental algorithm heuristics for + improving performance will become much easier once the move to BLOAT + has been completed. + +1.4. Requirement Levels + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 + [RFC2119]. + +2. IPoXML + + This protocol MUST be implemented to be compliant with this RFC. + IPoXML is the root protocol REQUIRED for effective use of TCPoXML + (section 3.) and higher-level application protocols. + + The DTD for this document type can be found in section 7.1. + + The routing of IPoXML can be easily implemented on hosts with an XML + parser, as the regular structure lends itself handily to parsing and + validation of the document/datagram and then processing the + destination address, TTL, and checksum before sending it on to its + next-hop. + + The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the + wider deployment of IPv4 and the fact that implementing IPv6 as XML + would have exceeded the 1500 byte Ethernet MTU. + + + +Kennedy Informational [Page 2] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + All BLOAT implementations MUST use - and specify - the UTF-8 encoding + of RFC 2279 [RFC2279]. All BLOAT document/datagrams MUST be well- + formed and include the XMLDecl. + +2.1. IP Description + + A number of items have changed (for the better) from the original IP + specification. Bit-masks, where present have been converted into + human-readable values. IP addresses are listed in their dotted- + decimal notation [RFC1123]. Length and checksum values are present + as decimal integers. + + To calculate the length and checksum fields of the IP element, a + canonicalized form of the element MUST be used. The canonical form + SHALL have no whitespace (including newline characters) between + elements and only one space character between attributes. There + SHALL NOT be a space following the last attribute in an element. + + An iterative method SHOULD be used to calculate checksums, as the + length field will vary based on the size of the checksum. + + The payload element bears special attention. Due to the character + set restrictions of XML, the payload of IP datagrams (which MAY + contain arbitrary data) MUST be encoded for transport. This RFC + REQUIRES the contents of the payload to be encoded in the base-64 + encoding of RFC 2045 [RFC2045], but removes the requirement that the + encoded output MUST be wrapped on 76-character lines. + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 3] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +2.2. Example Datagram + + The following is an example IPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + <ip> + <header length="474"> + <version value="4"/> + <tos precedence="Routine" delay="Normal" throughput="Normal" + relibility="Normal" reserved="0"/> + <total.length value="461"/> + <id value="1"/> + <flags reserved="0" df="dont" mf="last"/> + <offset value="0"/> + <ttl value="255"/> + <protocol value="6"/> + <checksum value="8707"/> + <source address="10.0.0.22"/> + <destination address="10.0.0.1"/> + <options> + <end copied="0" class="0" number="0"/> + </options> + <padding pad="0"/> + </header> + <payload> + </payload> + </ip> + +3. TCPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.2. + +3.1. TCP Description + + A number of items have changed from the original TCP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + To calculate the length and checksum fields of the TCP element, a + canonicalized form of the element MUST be used as in section 2.1. + + An iterative method SHOULD be used to calculate checksums as in + section 2.1. + + The payload element MUST be encoded as in section 2.1. + + + +Kennedy Informational [Page 4] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + The TCP offset element was expanded to a maximum of 255 from 16 to + allow for the increased size of the header in XML. + + TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + <tcp> + <tcp.header> + <src port="31415"/> + <dest port="42424"/> + <sequence number="322622954"/> + <acknowledgement number="689715995"/> + <offset number=""/> + <reserved value="0"/> + <control syn="1" ack="1"/> + <window size="1"/> + <urgent pointer="0"/> + <checksum value="2988"/> + <tcp.options> + <tcp.end kind="0"/> + </tcp.options> + <padding pad="0"/> + </tcp.header> + <payload> + </payload> + </tcp> + +4. UDPoXML + + This protocol MUST be implemented to be compliant with this RFC. The + DTD for this document type can be found in section 7.3. + +4.1. UDP Description + + A number of items have changed from the original UDP specification. + Bit-masks, where present have been converted into human-readable + values. Length and checksum and port values are present as decimal + integers. + + + + + + + +Kennedy Informational [Page 5] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + To calculate the length and checksum fields of the UDP element, a + canonicalized form of the element MUST be used as in section 2.1. An + iterative method SHOULD be used to calculate checksums as in section + 2.1. + + The payload element MUST be encoded as in section 2.1. + + UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header + as well as the <!DOCTYPE> declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + <udp> + <udp.header> + <src port="31415"/> + <dest port="42424"/> + <udp.length value="143"/> + <checksum value="2988"/> + </udp.header> + <payload> + </payload> + </udp> + +5. Network Transport + + This document provides for the transmission of BLOAT datagrams over + two common families of physical layer transport. Future RFCs will + address additional transports as routing vendors catch up to the + specification, and we begin to see BLOAT routed across the Internet + backbone. + +5.1. Ethernet + + BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the + exception that the type field of the Ethernet frame MUST contain the + value 0xBEEF. The first 5 octets of the Ethernet frame payload will + be 0x3c 3f 78 6d 6c ("<?xml".) + +5.2. IEEE 802 + + BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except + that the protocol type code for IPoXML is 0xBEEF. + + + + + +Kennedy Informational [Page 6] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +6. Gatewaying over IP + + In order to facilitate the gradual introduction of BLOAT into the + public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to + gateway between networks that run BLOAT natively on their LANs. + +7. DTDs + + The Transport DTDs (7.2. and 7.3.) build on the definitions in the + Network DTD (7.1.) + + The DTDs are referenced by their PubidLiteral and SystemLiteral (from + [XML]) although it is understood that most IPoXML implementations + will not need to pull down the DTD, as it will normally be embedded + in the implementation, and presents something of a catch-22 if you + need to load part of your network protocol over the network. + +7.1. IPoXML DTD + + <!-- + DTD for IP over XML. + Refer to this DTD as: + + <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd"> + --> + <!-- + DTD data types: + + Digits [0..9]+ + + Precedence "NetworkControl | InternetworkControl | + CRITIC | FlashOverride | Flash | Immediate | + Priority | Routine" + + IP4Addr "dotted-decimal" notation of [RFC1123] + + Class [0..3] + + Sec "Unclassified | Confidential | EFTO | MMMM | PROG | + Restricted | Secret | Top Secret | Reserved" + + Compartments [0..65535] + + Handling [0..65535] + + TCC [0..16777216] + + --> + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ENTITY % Digits "CDATA"> + <!ENTITY % Precedence "CDATA"> + <!ENTITY % IP4Addr "CDATA"> + <!ENTITY % Class "CDATA"> + <!ENTITY % Sec "CDATA"> + <!ENTITY % Compartments "CDATA"> + <!ENTITY % Handling "CDATA"> + <!ENTITY % TCC "CDATA"> + + <!ELEMENT ip (header, payload)> + + <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl, + protocol, checksum, source, destination, options, + padding)> + <!-- length of header in 32-bit words --> + <!ATTLIST header + length %Digits; #REQUIRED> + + <!ELEMENT version EMPTY> + <!-- ip version. SHOULD be "4" --> + <!ATTLIST version + value %Digits; #REQUIRED> + + <!ELEMENT tos EMPTY> + <!ATTLIST tos + precedence %Precedence; #REQUIRED + delay (normal | low) #REQUIRED + throughput (normal | high) #REQUIRED + relibility (normal | high) #REQUIRED + reserved CDATA #FIXED "0"> + + <!ELEMENT total.length EMPTY> + <!-- + total length of datagram (header and payload) in octets, MUST be + less than 65,535 (and SHOULD be less than 1024 for IPoXML on local + ethernets). + --> + <!ATTLIST total.length + value %Digits; #REQUIRED> + + <!ELEMENT id EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST id + value %Digits; #REQUIRED> + + <!ELEMENT flags EMPTY> + <!-- df = don't fragment, mf = more fragments --> + <!ATTLIST flags + + + +Kennedy Informational [Page 8] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + reserved CDATA #FIXED "0" + df (may|dont) #REQUIRED + mf (last|more) #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks --> + <!ATTLIST offset + value %Digits; #REQUIRED> + + <!ELEMENT ttl EMPTY> + <!-- 0 <= ttl <= 255 --> + <!ATTLIST ttl + value %Digits; #REQUIRED> + + <!ELEMENT protocol EMPTY> + <!-- 0 <= protocol <= 255 (per IANA) --> + <!ATTLIST protocol + value %Digits; #REQUIRED> + + <!ELEMENT checksum EMPTY> + <!-- 0 <= checksum <= 65535 (over header only) --> + <!ATTLIST checksum + value %Digits; #REQUIRED> + + <!ELEMENT source EMPTY> + <!ATTLIST source + address %IP4Addr; #REQUIRED> + + <!ELEMENT destination EMPTY> + <!ATTLIST destination + address %IP4Addr; #REQUIRED> + + <!ELEMENT options ( end | noop | security | loose | strict | record + | stream | timestamp )*> + + <!ELEMENT end EMPTY> + <!ATTLIST end + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "0"> + + <!ELEMENT noop EMPTY> + <!ATTLIST noop + copied (0|1) #REQUIRED + class CDATA #FIXED "0" + number CDATA #FIXED "1"> + + <!ELEMENT security EMPTY> + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST security + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "2" + length CDATA #FIXED "11" + security %Sec; #REQUIRED + compartments %Compartments; #REQUIRED + handling %Handling; #REQUIRED + tcc %TCC; #REQUIRED> + <!ELEMENT loose (hop)+> + <!ATTLIST loose + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "3" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT hop EMPTY> + <!ATTLIST hop + address %IP4Addr; #REQUIRED> + + <!ELEMENT strict (hop)+> + <!ATTLIST strict + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "9" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT record (hop)+> + <!ATTLIST record + copied CDATA #FIXED "0" + class CDATA #FIXED "0" + number CDATA #FIXED "7" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED> + + <!ELEMENT stream EMPTY> + <!-- 0 <= id <= 65,535 --> + <!ATTLIST stream + copied CDATA #FIXED "1" + class CDATA #FIXED "0" + number CDATA #FIXED "8" + length CDATA #FIXED "4" + id %Digits; #REQUIRED> + + <!ELEMENT timestamp (tstamp)+> + <!-- 0 <= oflw <=15 --> + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST timestamp + copied CDATA #FIXED "0" + class CDATA #FIXED "2" + number CDATA #FIXED "4" + length %Digits; #REQUIRED + pointer %Digits; #REQUIRED + oflw %Digits; #REQUIRED + flag (0 | 1 | 3) #REQUIRED> + + <!ELEMENT tstamp EMPTY> + <!ATTLIST tstamp + time %Digits; #REQUIRED + address %IP4Addr; #IMPLIED> + <!-- + padding to bring header to 32-bit boundary. + pad MUST be "0"* + --> + <!ELEMENT padding EMPTY> + <!ATTLIST padding + pad CDATA #REQUIRED> + + <!-- payload MUST be encoded as base-64 [RFC2045], as modified + by section 2.1 of this RFC --> + <!ELEMENT payload (CDATA)> + +7.2. TCPoXML DTD + + <!-- + DTD for TCP over XML. + Refer to this DTD as: + + <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd"> + --> + + <!-- the pseudoheader is only included for checksum calculations --> + <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)> + + <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset, + reserved, control, window, checksum, urgent, + tcp.options, padding)> + + <!ELEMENT src EMPTY> + <!-- 0 <= port <= 65,535 --> + <!ATTLIST src + port %Digits; #REQUIRED> + + <!ELEMENT dest EMPTY> + <!-- 0 <= port <= 65,535 --> + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ATTLIST dest + port %Digits; #REQUIRED> + + <!ELEMENT sequence EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST sequence + number %Digits; #REQUIRED> + + <!ELEMENT acknowledgement EMPTY> + <!-- 0 <= number <= 4294967295 --> + <!ATTLIST acknowledgement + number %Digits; #REQUIRED> + + <!ELEMENT offset EMPTY> + <!-- 0 <= number <= 255 --> + <!ATTLIST offset + number %Digits; #REQUIRED> + + <!ELEMENT reserved EMPTY> + <!ATTLIST reserved + value CDATA #FIXED "0"> + + <!ELEMENT control EMPTY> + <!ATTLIST control + urg (0|1) #IMPLIED + ack (0|1) #IMPLIED + psh (0|1) #IMPLIED + rst (0|1) #IMPLIED + syn (0|1) #IMPLIED + fin (0|1) #IMPLIED> + + <!ELEMENT window EMPTY> + <!-- 0 <= size <= 65,535 --> + <!ATTLIST window + size %Digits; #REQUIRED> + + <!-- + checksum as in ip, but with + the following pseudo-header added into the tcp element: + --> + <!ELEMENT tcp.pseudoheader (source, destination, protocol, + tcp.length)> + + <!-- + tcp header + data length in octets. does not include the size of + + the pseudoheader. + --> + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + <!ELEMENT tcp.length EMPTY> + <!ATTLIST tcp.length + value %Digits; #REQUIRED> + + <!ELEMENT urgent EMPTY> + <!-- 0 <= pointer <= 65,535 --> + <!ATTLIST urgent + pointer %Digits; #REQUIRED> + + <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+> + + <!ELEMENT tcp.end EMPTY> + <!ATTLIST tcp.end + kind CDATA #FIXED "0"> + + <!ELEMENT tcp.noop EMPTY> + <!ATTLIST tcp.noop + kind CDATA #FIXED "1"> + + <!ELEMENT tcp.mss EMPTY> + <!ATTLIST tcp.mss + kind CDATA #FIXED "2" + length CDATA #FIXED "4" + size %Digits; #REQUIRED> + +7.3. UDPoXML DTD + + <!-- + DTD for UDP over XML. + Refer to this DTD as: + + <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd"> + --> + + <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)> + + <!ELEMENT udp.header (src, dest, udp.length, checksum)> + + <!ELEMENT udp.pseudoheader (source, destination, protocol, + udp.length)> + + <!-- + udp header + data length in octets. does not include the size of + the pseudoheader. + --> + <!ELEMENT udp.length EMPTY> + <!ATTLIST udp.length + value %Digits; #REQUIRED> + + + +Kennedy Informational [Page 13] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +8. Security Considerations + + XML, as a subset of SGML, has the same security considerations as + specified in SGML Media Types [RFC1874]. Security considerations + that apply to IP, TCP and UDP also likely apply to BLOAT as it does + not attempt to correct for issues not related to message format. + +9. References + + [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt, + February 2002. (Work in Progress) + + [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC894] Hornig, C., "Standard for the Transmission of IP + Datagrams over Ethernet Networks.", RFC 894, April 1984. + + [RFC1042] Postel, J. and J. Reynolds, "Standard for the + Transmission of IP Datagrams Over IEEE 802 Networks", STD + 43, RFC 1042, February 1988. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", RFC 1123, October 1989. + + [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December + 1995. + + [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, + October 1996. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + + + + +Kennedy Informational [Page 14] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", + RFC 3080, March 2001. + + [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., + Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D., + "Simple Object Access Protocol (SOAP) 1.1" World Wide Web + Consortium Note, May 2000 http://www.w3.org/TR/SOAP/ + + [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible + Markup Language (XML)" World Wide Web Consortium + Recommendation REC- xml-19980210. + http://www.w3.org/TR/1998/REC-xml-19980210 + +10. Author's Address + + Hugh Kennedy + Mimezine + 1060 West Addison + Chicago, IL 60613 + USA + + EMail: kennedyh@engin.umich.edu + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 15] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 16] + diff --git a/tests/auto/qnetworkreply/smb-file.txt b/tests/auto/qnetworkreply/smb-file.txt new file mode 100644 index 0000000000..73c3ac2c07 --- /dev/null +++ b/tests/auto/qnetworkreply/smb-file.txt @@ -0,0 +1 @@ +This is 34 bytes. Do not change...
\ No newline at end of file diff --git a/tests/auto/qnetworkreply/test/test.pro b/tests/auto/qnetworkreply/test/test.pro new file mode 100644 index 0000000000..d1f6707f6f --- /dev/null +++ b/tests/auto/qnetworkreply/test/test.pro @@ -0,0 +1,36 @@ +load(qttest_p4) +QT -= gui +SOURCES += ../tst_qnetworkreply.cpp +TARGET = ../tst_qnetworkreply + +win32 { + CONFIG(debug, debug|release) { + TARGET = ../../debug/tst_qnetworkreply +} else { + TARGET = ../../release/tst_qnetworkreply + } +} + +!symbian:DEFINES += SRCDIR=\\\"$$PWD/..\\\" + +QT = core network +RESOURCES += ../qnetworkreply.qrc + +symbian|wince*:{ + # For cross compiled targets, reference data files need to be deployed + addFiles.files = ../empty ../rfc3252.txt ../resource ../bigfile ../*.jpg + addFiles.path = . + DEPLOYMENT += addFiles + + certFiles.files = ../certs + certFiles.path = . + DEPLOYMENT += certFiles +} + +symbian:{ + # Symbian toolchain does not support correct include semantics + INCLUDEPATH+=..\\..\\..\\..\\include\\QtNetwork\\private + # bigfile test case requires more heap + TARGET.EPOCHEAPSIZE="0x100 0x10000000" + TARGET.CAPABILITY="ALL -TCB" +} diff --git a/tests/auto/qnetworkreply/tst_qnetworkreply.cpp b/tests/auto/qnetworkreply/tst_qnetworkreply.cpp new file mode 100644 index 0000000000..f509ceaad6 --- /dev/null +++ b/tests/auto/qnetworkreply/tst_qnetworkreply.cpp @@ -0,0 +1,6172 @@ +/**************************************************************************** +** +** Copyright (C) 2011 Nokia Corporation and/or its subsidiary(-ies). +** All rights reserved. +** Contact: Nokia Corporation (qt-info@nokia.com) +** +** This file is part of the test suite of the Qt Toolkit. +** +** $QT_BEGIN_LICENSE:LGPL$ +** No Commercial Usage +** This file contains pre-release code and may not be distributed. +** You may use this file in accordance with the terms and conditions +** contained in the Technology Preview License Agreement accompanying +** this package. +** +** GNU Lesser General Public License Usage +** Alternatively, this file may be used under the terms of the GNU Lesser +** General Public License version 2.1 as published by the Free Software +** Foundation and appearing in the file LICENSE.LGPL included in the +** packaging of this file. Please review the following information to +** ensure the GNU Lesser General Public License version 2.1 requirements +** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html. +** +** In addition, as a special exception, Nokia gives you certain additional +** rights. These rights are described in the Nokia Qt LGPL Exception +** version 1.1, included in the file LGPL_EXCEPTION.txt in this package. +** +** If you have questions regarding the use of this file, please contact +** Nokia at qt-info@nokia.com. +** +** +** +** +** +** +** +** +** $QT_END_LICENSE$ +** +****************************************************************************/ + + +#include <QtTest/QtTest> +#include <QtCore/QCryptographicHash> +#include <QtCore/QDataStream> +#include <QtCore/QUrl> +#include <QtCore/QEventLoop> +#include <QtCore/QFile> +#include <QtCore/QSharedPointer> +#include <QtCore/QScopedPointer> +#include <QtCore/QTemporaryFile> +#include <QtNetwork/QTcpServer> +#include <QtNetwork/QTcpSocket> +#include <QtNetwork/QLocalSocket> +#include <QtNetwork/QLocalServer> +#include <QtNetwork/QHostInfo> +#include <QtNetwork/QFtp> +#include <QtNetwork/QAbstractNetworkCache> +#include <QtNetwork/qauthenticator.h> +#include <QtNetwork/qnetworkaccessmanager.h> +#include <QtNetwork/qnetworkrequest.h> +#include <QtNetwork/qnetworkreply.h> +#include <QtNetwork/qnetworkcookie.h> +#include <QtNetwork/QHttpPart> +#include <QtNetwork/QHttpMultiPart> +#ifndef QT_NO_OPENSSL +#include <QtNetwork/qsslerror.h> +#include <QtNetwork/qsslconfiguration.h> +#endif +#ifndef QT_NO_BEARERMANAGEMENT +#include <QtNetwork/qnetworkconfigmanager.h> +#include <QtNetwork/qnetworkconfiguration.h> +#include <QtNetwork/qnetworksession.h> +#endif + +#include <time.h> + +#include "private/qnetworkaccessmanager_p.h" + +#ifdef Q_OS_SYMBIAN +#define SRCDIR "." +#endif + +#include "../network-settings.h" + +Q_DECLARE_METATYPE(QSharedPointer<char>) +Q_DECLARE_METATYPE(QNetworkReply*) +Q_DECLARE_METATYPE(QAuthenticator*) +Q_DECLARE_METATYPE(QNetworkProxy) +Q_DECLARE_METATYPE(QNetworkProxyQuery) +Q_DECLARE_METATYPE(QList<QNetworkProxy>) +Q_DECLARE_METATYPE(QNetworkReply::NetworkError) +Q_DECLARE_METATYPE(QBuffer*) +Q_DECLARE_METATYPE(QHttpMultiPart *) +Q_DECLARE_METATYPE(QList<QFile*>) // for multiparts +#ifndef QT_NO_OPENSSL +Q_DECLARE_METATYPE(QSslConfiguration) +#endif + +class QNetworkReplyPtr: public QSharedPointer<QNetworkReply> +{ +public: + inline QNetworkReplyPtr(QNetworkReply *ptr = 0) + : QSharedPointer<QNetworkReply>(ptr) + { } + + inline operator QNetworkReply *() const { return data(); } +}; + +class MyCookieJar; +class tst_QNetworkReply: public QObject +{ + Q_OBJECT + + struct ProxyData { + ProxyData(const QNetworkProxy &p, const QByteArray &t, bool auth) + : tag(t), proxy(p), requiresAuthentication(auth) + { } + QByteArray tag; + QNetworkProxy proxy; + bool requiresAuthentication; + }; + + static bool seedCreated; + static QString createUniqueExtension() { + if (!seedCreated) { + qsrand(QTime(0,0,0).msecsTo(QTime::currentTime()) + QCoreApplication::applicationPid()); + seedCreated = true; // not thread-safe, but who cares + } + QString s = QString("%1-%2-%3").arg(QTime(0,0,0).msecsTo(QTime::currentTime())).arg(QCoreApplication::applicationPid()).arg(qrand()); + return s; + }; + + QEventLoop *loop; + enum RunSimpleRequestReturn { Timeout = 0, Success, Failure }; + int returnCode; + QString testFileName; +#if !defined Q_OS_WIN + QString wronlyFileName; +#endif + QString uniqueExtension; + QList<ProxyData> proxies; + QNetworkAccessManager manager; + MyCookieJar *cookieJar; +#ifndef QT_NO_OPENSSL + QSslConfiguration storedSslConfiguration; + QList<QSslError> storedExpectedSslErrors; +#endif +#ifndef QT_NO_BEARERMANAGEMENT + QNetworkConfigurationManager *netConfMan; + QNetworkConfiguration networkConfiguration; + QScopedPointer<QNetworkSession> networkSession; +#endif + +public: + tst_QNetworkReply(); + ~tst_QNetworkReply(); + QString runSimpleRequest(QNetworkAccessManager::Operation op, const QNetworkRequest &request, + QNetworkReplyPtr &reply, const QByteArray &data = QByteArray()); + QString runMultipartRequest(const QNetworkRequest &request, QNetworkReplyPtr &reply, + QHttpMultiPart *multiPart, const QByteArray &verb); + + QString runCustomRequest(const QNetworkRequest &request, QNetworkReplyPtr &reply, + const QByteArray &verb, QIODevice *data); + +public Q_SLOTS: + void finished(); + void gotError(); + void authenticationRequired(QNetworkReply*,QAuthenticator*); + void proxyAuthenticationRequired(const QNetworkProxy &,QAuthenticator*); + +#ifndef QT_NO_OPENSSL + void sslErrors(QNetworkReply*,const QList<QSslError> &); + void storeSslConfiguration(); + void ignoreSslErrorListSlot(QNetworkReply *reply, const QList<QSslError> &); +#endif + +protected Q_SLOTS: + void nestedEventLoops_slot(); + +private Q_SLOTS: + void init(); + void cleanup(); + void initTestCase(); + void cleanupTestCase(); + + void stateChecking(); + void invalidProtocol(); + void getFromData_data(); + void getFromData(); + void getFromFile(); + void getFromFileSpecial_data(); + void getFromFileSpecial(); + void getFromFtp_data(); + void getFromFtp(); + void getFromHttp_data(); + void getFromHttp(); + void getErrors_data(); + void getErrors(); + void putToFile_data(); + void putToFile(); + void putToFtp_data(); + void putToFtp(); + void putToHttp_data(); + void putToHttp(); + void putToHttpSynchronous_data(); + void putToHttpSynchronous(); + void putToHttpMultipart_data(); + void putToHttpMultipart(); + void postToHttp_data(); + void postToHttp(); + void postToHttpSynchronous_data(); + void postToHttpSynchronous(); + void postToHttpMultipart_data(); + void postToHttpMultipart(); + void deleteFromHttp_data(); + void deleteFromHttp(); + void putGetDeleteGetFromHttp_data(); + void putGetDeleteGetFromHttp(); + void sendCustomRequestToHttp_data(); + void sendCustomRequestToHttp(); + + void ioGetFromData_data(); + void ioGetFromData(); + void ioGetFromFileSpecial_data(); + void ioGetFromFileSpecial(); + void ioGetFromFile_data(); + void ioGetFromFile(); + void ioGetFromFtp_data(); + void ioGetFromFtp(); + void ioGetFromFtpWithReuse(); + void ioGetFromHttp(); + + void ioGetFromBuiltinHttp_data(); + void ioGetFromBuiltinHttp(); + void ioGetFromHttpWithReuseParallel(); + void ioGetFromHttpWithReuseSequential(); + void ioGetFromHttpWithAuth_data(); + void ioGetFromHttpWithAuth(); + void ioGetFromHttpWithAuthSynchronous(); + void ioGetFromHttpWithProxyAuth(); + void ioGetFromHttpWithProxyAuthSynchronous(); + void ioGetFromHttpWithSocksProxy(); +#ifndef QT_NO_OPENSSL + void ioGetFromHttpsWithSslErrors(); + void ioGetFromHttpsWithIgnoreSslErrors(); + void ioGetFromHttpsWithSslHandshakeError(); +#endif + void ioGetFromHttpBrokenServer_data(); + void ioGetFromHttpBrokenServer(); + void ioGetFromHttpStatus100_data(); + void ioGetFromHttpStatus100(); + void ioGetFromHttpNoHeaders_data(); + void ioGetFromHttpNoHeaders(); + void ioGetFromHttpWithCache_data(); + void ioGetFromHttpWithCache(); + + void ioGetWithManyProxies_data(); + void ioGetWithManyProxies(); + + void ioPutToFileFromFile_data(); + void ioPutToFileFromFile(); + void ioPutToFileFromSocket_data(); + void ioPutToFileFromSocket(); + void ioPutToFileFromLocalSocket_data(); + void ioPutToFileFromLocalSocket(); + void ioPutToFileFromProcess_data(); + void ioPutToFileFromProcess(); + void ioPutToFtpFromFile_data(); + void ioPutToFtpFromFile(); + void ioPutToHttpFromFile_data(); + void ioPutToHttpFromFile(); + void ioPostToHttpFromFile_data(); + void ioPostToHttpFromFile(); + void ioPostToHttpFromSocket_data(); + void ioPostToHttpFromSocket(); + void ioPostToHttpFromSocketSynchronous(); + void ioPostToHttpFromSocketSynchronous_data(); + void ioPostToHttpFromMiddleOfFileToEnd(); + void ioPostToHttpFromMiddleOfFileFiveBytes(); + void ioPostToHttpFromMiddleOfQBufferFiveBytes(); + void ioPostToHttpNoBufferFlag(); + void ioPostToHttpUploadProgress(); + void ioPostToHttpEmptyUploadProgress(); + + void lastModifiedHeaderForFile(); + void lastModifiedHeaderForHttp(); + + void httpCanReadLine(); + + void rateControl_data(); + void rateControl(); + + void downloadProgress_data(); + void downloadProgress(); + void uploadProgress_data(); + void uploadProgress(); + + void chaining_data(); + void chaining(); + + void receiveCookiesFromHttp_data(); + void receiveCookiesFromHttp(); + void receiveCookiesFromHttpSynchronous_data(); + void receiveCookiesFromHttpSynchronous(); + void sendCookies_data(); + void sendCookies(); + void sendCookiesSynchronous_data(); + void sendCookiesSynchronous(); + + void nestedEventLoops(); + + void httpProxyCommands_data(); + void httpProxyCommands(); + void httpProxyCommandsSynchronous_data(); + void httpProxyCommandsSynchronous(); + void proxyChange(); + void authorizationError_data(); + void authorizationError(); + + void httpConnectionCount(); + + void httpReUsingConnectionSequential_data(); + void httpReUsingConnectionSequential(); + void httpReUsingConnectionFromFinishedSlot_data(); + void httpReUsingConnectionFromFinishedSlot(); + + void httpRecursiveCreation(); + +#ifndef QT_NO_OPENSSL + void ioPostToHttpsUploadProgress(); + void ignoreSslErrorsList_data(); + void ignoreSslErrorsList(); + void ignoreSslErrorsListWithSlot_data(); + void ignoreSslErrorsListWithSlot(); + void sslConfiguration_data(); + void sslConfiguration(); +#endif + + void getAndThenDeleteObject_data(); + void getAndThenDeleteObject(); + + void symbianOpenCDataUrlCrash(); + + void getFromHttpIntoBuffer_data(); + void getFromHttpIntoBuffer(); + void getFromHttpIntoBuffer2_data(); + void getFromHttpIntoBuffer2(); + + void ioGetFromHttpWithoutContentLength(); + + void ioGetFromHttpBrokenChunkedEncoding(); + void qtbug12908compressedHttpReply(); + void compressedHttpReplyBrokenGzip(); + + void getFromUnreachableIp(); + + void qtbug4121unknownAuthentication(); + + void qtbug13431replyThrottling(); + + void httpWithNoCredentialUsage(); + + void qtbug15311doubleContentLength(); + + void qtbug18232gzipContentLengthZero(); + + void synchronousRequest_data(); + void synchronousRequest(); +#ifndef QT_NO_OPENSSL + void synchronousRequestSslFailure(); +#endif + + void httpAbort(); + + void dontInsertPartialContentIntoTheCache(); + + // NOTE: This test must be last! + void parentingRepliesToTheApp(); +}; + +bool tst_QNetworkReply::seedCreated = false; + +QT_BEGIN_NAMESPACE + +namespace QTest { + template<> + char *toString(const QNetworkReply::NetworkError& code) + { + const QMetaObject *mo = &QNetworkReply::staticMetaObject; + int index = mo->indexOfEnumerator("NetworkError"); + if (index == -1) + return qstrdup(""); + + QMetaEnum qme = mo->enumerator(index); + return qstrdup(qme.valueToKey(code)); + } + + template<> + char *toString(const QNetworkCookie &cookie) + { + return qstrdup(cookie.toRawForm()); + } + + template<> + char *toString(const QList<QNetworkCookie> &list) + { + QString result = "QList("; + bool first = true; + foreach (QNetworkCookie cookie, list) { + if (!first) + result += ", "; + first = false; + result += QString::fromLatin1("QNetworkCookie(%1)").arg(QLatin1String(cookie.toRawForm())); + } + + return qstrdup(result.append(')').toLocal8Bit()); + } +} + +QT_END_NAMESPACE + +#define RUN_REQUEST(call) \ + do { \ + QString errorMsg = call; \ + if (!errorMsg.isEmpty()) \ + QFAIL(qPrintable(errorMsg)); \ + } while (0); + +#ifndef QT_NO_OPENSSL +static void setupSslServer(QSslSocket* serverSocket) +{ + serverSocket->setProtocol(QSsl::AnyProtocol); + serverSocket->setLocalCertificate(SRCDIR "/certs/server.pem"); + serverSocket->setPrivateKey(SRCDIR "/certs/server.key"); +} +#endif + +// Does not work for POST/PUT! +class MiniHttpServer: public QTcpServer +{ + Q_OBJECT +public: + QTcpSocket *client; // always the last one that was received + QByteArray dataToTransmit; + QByteArray receivedData; + QSemaphore ready; + bool doClose; + bool doSsl; + bool multiple; + int totalConnections; + + MiniHttpServer(const QByteArray &data, bool ssl = false, QThread *thread = 0) + : client(0), dataToTransmit(data), doClose(true), doSsl(ssl), + multiple(false), totalConnections(0) + { + listen(); + if (thread) { + connect(thread, SIGNAL(started()), this, SLOT(threadStartedSlot())); + moveToThread(thread); + thread->start(); + ready.acquire(); + } + } + +protected: + void incomingConnection(int socketDescriptor) + { + //qDebug() << "incomingConnection" << socketDescriptor; + if (!doSsl) { + client = new QTcpSocket; + client->setSocketDescriptor(socketDescriptor); + connectSocketSignals(); + } else { +#ifndef QT_NO_OPENSSL + QSslSocket *serverSocket = new QSslSocket; + serverSocket->setParent(this); + if (serverSocket->setSocketDescriptor(socketDescriptor)) { + connect(serverSocket, SIGNAL(sslErrors(QList<QSslError>)), this, SLOT(slotSslErrors(QList<QSslError>))); + setupSslServer(serverSocket); + serverSocket->startServerEncryption(); + client = serverSocket; + connectSocketSignals(); + } else { + delete serverSocket; + return; + } +#endif + } + client->setParent(this); + ++totalConnections; + } +private: + void connectSocketSignals() + { + //qDebug() << "connectSocketSignals" << client; + connect(client, SIGNAL(readyRead()), this, SLOT(readyReadSlot())); + connect(client, SIGNAL(bytesWritten(qint64)), this, SLOT(bytesWrittenSlot())); + connect(client, SIGNAL(error(QAbstractSocket::SocketError)), + this, SLOT(slotError(QAbstractSocket::SocketError))); + } + +private slots: +#ifndef QT_NO_OPENSSL + void slotSslErrors(const QList<QSslError>& errors) + { + qDebug() << "slotSslErrors" << client->errorString() << errors; + } +#endif + void slotError(QAbstractSocket::SocketError err) + { + qDebug() << "slotError" << err << client->errorString(); + } + +public slots: + void readyReadSlot() + { + receivedData += client->readAll(); + int doubleEndlPos = receivedData.indexOf("\r\n\r\n"); + + if (doubleEndlPos != -1) { + // multiple requests incoming. remove the bytes of the current one + if (multiple) + receivedData.remove(0, doubleEndlPos+4); + + // we need to emulate the bytesWrittenSlot call if the data is empty. + if (dataToTransmit.size() == 0) + QMetaObject::invokeMethod(this, "bytesWrittenSlot", Qt::QueuedConnection); + else + client->write(dataToTransmit); + } + } + + void bytesWrittenSlot() { + if (doClose && client->bytesToWrite() == 0) { + client->disconnectFromHost(); + disconnect(client, 0, this, 0); + } + } + + void threadStartedSlot() + { + ready.release(); + } +}; + +class MyCookieJar: public QNetworkCookieJar +{ +public: + inline QList<QNetworkCookie> allCookies() const + { return QNetworkCookieJar::allCookies(); } + inline void setAllCookies(const QList<QNetworkCookie> &cookieList) + { QNetworkCookieJar::setAllCookies(cookieList); } +}; + +class MyProxyFactory: public QNetworkProxyFactory +{ +public: + int callCount; + QList<QNetworkProxy> toReturn; + QNetworkProxyQuery lastQuery; + inline MyProxyFactory() { clear(); } + + inline void clear() + { + callCount = 0; + toReturn = QList<QNetworkProxy>() << QNetworkProxy::DefaultProxy; + lastQuery = QNetworkProxyQuery(); + } + + virtual QList<QNetworkProxy> queryProxy(const QNetworkProxyQuery &query) + { + lastQuery = query; + ++callCount; + return toReturn; + } +}; + +class MyMemoryCache: public QAbstractNetworkCache +{ +public: + typedef QPair<QNetworkCacheMetaData, QByteArray> CachedContent; + typedef QHash<QByteArray, CachedContent> CacheData; + CacheData cache; + + MyMemoryCache(QObject *parent) : QAbstractNetworkCache(parent) {} + + QNetworkCacheMetaData metaData(const QUrl &url) + { + return cache.value(url.toEncoded()).first; + } + + void updateMetaData(const QNetworkCacheMetaData &metaData) + { + cache[metaData.url().toEncoded()].first = metaData; + } + + QIODevice *data(const QUrl &url) + { + CacheData::ConstIterator it = cache.find(url.toEncoded()); + if (it == cache.constEnd()) + return 0; + QBuffer *io = new QBuffer(this); + io->setData(it->second); + io->open(QIODevice::ReadOnly); + io->seek(0); + return io; + } + + bool remove(const QUrl &url) + { + cache.remove(url.toEncoded()); + return true; + } + + qint64 cacheSize() const + { + qint64 total = 0; + foreach (const CachedContent &entry, cache) + total += entry.second.size(); + return total; + } + + QIODevice *prepare(const QNetworkCacheMetaData &) + { Q_ASSERT(0 && "Should not have tried to add to the cache"); return 0; } + void insert(QIODevice *) + { Q_ASSERT(0 && "Should not have tried to add to the cache"); } + + void clear() { cache.clear(); } +}; +Q_DECLARE_METATYPE(MyMemoryCache::CachedContent) +Q_DECLARE_METATYPE(MyMemoryCache::CacheData) + +class MySpyMemoryCache: public QAbstractNetworkCache +{ +public: + MySpyMemoryCache(QObject *parent) : QAbstractNetworkCache(parent) {} + ~MySpyMemoryCache() + { + qDeleteAll(m_buffers); + m_buffers.clear(); + } + + QHash<QUrl, QIODevice*> m_buffers; + QList<QUrl> m_insertedUrls; + + QNetworkCacheMetaData metaData(const QUrl &) + { + return QNetworkCacheMetaData(); + } + + void updateMetaData(const QNetworkCacheMetaData &) + { + } + + QIODevice *data(const QUrl &) + { + return 0; + } + + bool remove(const QUrl &url) + { + delete m_buffers.take(url); + return m_insertedUrls.removeAll(url) > 0; + } + + qint64 cacheSize() const + { + return 0; + } + + QIODevice *prepare(const QNetworkCacheMetaData &metaData) + { + QBuffer* buffer = new QBuffer; + buffer->open(QIODevice::ReadWrite); + buffer->setProperty("url", metaData.url()); + m_buffers.insert(metaData.url(), buffer); + return buffer; + } + + void insert(QIODevice *buffer) + { + QUrl url = buffer->property("url").toUrl(); + m_insertedUrls << url; + delete m_buffers.take(url); + } + + void clear() { m_insertedUrls.clear(); } +}; + +class DataReader: public QObject +{ + Q_OBJECT +public: + qint64 totalBytes; + QByteArray data; + QIODevice *device; + bool accumulate; + DataReader(QIODevice *dev, bool acc = true) : totalBytes(0), device(dev), accumulate(acc) + { + connect(device, SIGNAL(readyRead()), SLOT(doRead())); + } + +public slots: + void doRead() + { + QByteArray buffer; + buffer.resize(device->bytesAvailable()); + qint64 bytesRead = device->read(buffer.data(), device->bytesAvailable()); + if (bytesRead == -1) { + QTestEventLoop::instance().exitLoop(); + return; + } + buffer.truncate(bytesRead); + totalBytes += bytesRead; + + if (accumulate) + data += buffer; + } +}; + + +class SocketPair: public QObject +{ + Q_OBJECT +public: + QIODevice *endPoints[2]; + + SocketPair(QObject *parent = 0) + : QObject(parent) + { + endPoints[0] = endPoints[1] = 0; + } + + bool create() + { + QTcpServer server; + server.listen(); + + QTcpSocket *active = new QTcpSocket(this); + active->connectToHost("127.0.0.1", server.serverPort()); +#ifndef Q_OS_SYMBIAN + // need more time as working with embedded + // device and testing from emualtor + // things tend to get slower + if (!active->waitForConnected(1000)) + return false; + + if (!server.waitForNewConnection(1000)) + return false; +#else + if (!active->waitForConnected(100)) + return false; + + if (!server.waitForNewConnection(100)) + return false; +#endif + QTcpSocket *passive = server.nextPendingConnection(); + passive->setParent(this); + + endPoints[0] = active; + endPoints[1] = passive; + return true; + } +}; + +// A blocking tcp server (must be used in a thread) which supports SSL. +class BlockingTcpServer : public QTcpServer +{ + Q_OBJECT +public: + BlockingTcpServer(bool ssl) : doSsl(ssl), sslSocket(0) {} + + QTcpSocket* waitForNextConnectionSocket() { + waitForNewConnection(-1); + if (doSsl) { + Q_ASSERT(sslSocket); + return sslSocket; + } else { + //qDebug() << "returning nextPendingConnection"; + return nextPendingConnection(); + } + } + virtual void incomingConnection(int socketDescriptor) + { +#ifndef QT_NO_OPENSSL + if (doSsl) { + QSslSocket *serverSocket = new QSslSocket; + serverSocket->setParent(this); + serverSocket->setSocketDescriptor(socketDescriptor); + connect(serverSocket, SIGNAL(sslErrors(QList<QSslError>)), this, SLOT(slotSslErrors(QList<QSslError>))); + setupSslServer(serverSocket); + serverSocket->startServerEncryption(); + sslSocket = serverSocket; + } else +#endif + { + QTcpServer::incomingConnection(socketDescriptor); + } + } +private slots: + +#ifndef QT_NO_OPENSSL + void slotSslErrors(const QList<QSslError>& errors) + { + qDebug() << "slotSslErrors" << sslSocket->errorString() << errors; + } +#endif + +private: + const bool doSsl; + QTcpSocket* sslSocket; +}; + +// This server tries to send data as fast as possible (like most servers) +// but it measures how fast it was able to send it, which shows at which +// rate the reader is processing the data. +class FastSender: public QThread +{ + Q_OBJECT + QSemaphore ready; + qint64 wantedSize; + int port; + enum Protocol { DebugPipe, ProvidedData }; + const Protocol protocol; + const bool doSsl; + const bool fillKernelBuffer; +public: + int transferRate; + QWaitCondition cond; + + QByteArray dataToTransmit; + int dataIndex; + + // a server that sends debugpipe data + FastSender(qint64 size) + : wantedSize(size), port(-1), protocol(DebugPipe), + doSsl(false), fillKernelBuffer(true), transferRate(-1), + dataIndex(0) + { + start(); + ready.acquire(); + } + + // a server that sends the data provided at construction time, useful for HTTP + FastSender(const QByteArray& data, bool https, bool fillBuffer) + : wantedSize(data.size()), port(-1), protocol(ProvidedData), + doSsl(https), fillKernelBuffer(fillBuffer), transferRate(-1), + dataToTransmit(data), dataIndex(0) + { + start(); + ready.acquire(); + } + + inline int serverPort() const { return port; } + + int writeNextData(QTcpSocket* socket, qint32 size) + { + if (protocol == DebugPipe) { + QByteArray data; + QDataStream stream(&data, QIODevice::WriteOnly); + stream << QVariantMap() << QByteArray(size, 'a'); + socket->write((char*)&size, sizeof size); + socket->write(data); + dataIndex += size; + return size; + } else { + const QByteArray data = dataToTransmit.mid(dataIndex, size); + socket->write(data); + dataIndex += data.size(); + //qDebug() << "wrote" << dataIndex << "/" << dataToTransmit.size(); + return data.size(); + } + } + void writeLastData(QTcpSocket* socket) + { + if (protocol == DebugPipe) { + QByteArray data; + QDataStream stream(&data, QIODevice::WriteOnly); + stream << QVariantMap() << QByteArray(); + const qint32 size = data.size(); + socket->write((char*)&size, sizeof size); + socket->write(data); + } + } + +protected: + void run() + { + BlockingTcpServer server(doSsl); + server.listen(); + port = server.serverPort(); + ready.release(); + + QTcpSocket *client = server.waitForNextConnectionSocket(); + + // get the "request" packet + if (!client->waitForReadyRead(2000)) { + qDebug() << "FastSender:" << client->error() << "waiting for \"request\" packet"; + return; + } + client->readAll(); // we're not interested in the actual contents (e.g. HTTP request) + + enum { BlockSize = 1024 }; + + if (fillKernelBuffer) { + + // write a bunch of bytes to fill up the buffers + bool done = false; + do { + if (writeNextData(client, BlockSize) < BlockSize) { + qDebug() << "ERROR: FastSender: not enough data to write in order to fill buffers; or client is reading too fast"; + return; + } + while (client->bytesToWrite() > 0) { + if (!client->waitForBytesWritten(0)) { + done = true; + break; + } + } + //qDebug() << "Filling kernel buffer: wrote" << dataIndex << "bytes"; + } while (!done); + + qDebug() << "FastSender: ok, kernel buffer is full after writing" << dataIndex << "bytes"; + } + + // Tell the client to start reading + emit dataReady(); + + // the kernel buffer is full + // clean up QAbstractSocket's residue: + while (client->bytesToWrite() > 0) { + qDebug() << "Still having" << client->bytesToWrite() << "bytes to write, doing that now"; + if (!client->waitForBytesWritten(2000)) { + qDebug() << "ERROR: FastSender:" << client->error() << "cleaning up residue"; + return; + } + } + + // now write in "blocking mode", this is where the rate measuring starts + QTime timer; + timer.start(); + //const qint64 writtenBefore = dataIndex; + //qint64 measuredTotalBytes = wantedSize - writtenBefore; + qint64 measuredSentBytes = 0; + while (dataIndex < wantedSize) { + const int remainingBytes = wantedSize - measuredSentBytes; + const int bytesToWrite = qMin(remainingBytes, static_cast<int>(BlockSize)); + Q_ASSERT(bytesToWrite); + measuredSentBytes += writeNextData(client, bytesToWrite); + + while (client->bytesToWrite() > 0) { + if (!client->waitForBytesWritten(2000)) { + qDebug() << "ERROR: FastSender:" << client->error() << "during blocking write"; + return; + } + } + /*qDebug() << "FastSender:" << bytesToWrite << "bytes written now;" + << measuredSentBytes << "measured bytes" << measuredSentBytes + writtenBefore << "total (" + << measuredSentBytes*100/measuredTotalBytes << "% complete);" + << timer.elapsed() << "ms elapsed";*/ + } + + transferRate = measuredSentBytes * 1000 / timer.elapsed(); + qDebug() << "FastSender: flushed" << measuredSentBytes << "bytes in" << timer.elapsed() << "ms: rate =" << transferRate << "B/s"; + + // write a "close connection" packet, if the protocol needs it + writeLastData(client); + } +signals: + void dataReady(); +}; + +class RateControlledReader: public QObject +{ + Q_OBJECT + QIODevice *device; + int bytesToRead; + int interval; + int readBufferSize; +public: + QByteArray data; + qint64 totalBytesRead; + RateControlledReader(QObject& senderObj, QIODevice *dev, int kbPerSec, int maxBufferSize = 0) + : device(dev), readBufferSize(maxBufferSize), totalBytesRead(0) + { + // determine how often we have to wake up + int timesPerSecond; + if (readBufferSize == 0) { + // The requirement is simply "N KB per seconds" + timesPerSecond = 20; + bytesToRead = kbPerSec * 1024 / timesPerSecond; + } else { + // The requirement also includes "<readBufferSize> bytes at a time" + bytesToRead = readBufferSize; + timesPerSecond = kbPerSec * 1024 / readBufferSize; + } + interval = 1000 / timesPerSecond; // in ms + + qDebug() << "RateControlledReader: going to read" << bytesToRead + << "bytes every" << interval << "ms"; + qDebug() << "actual read rate will be" + << (bytesToRead * 1000 / interval) << "bytes/sec (wanted" + << kbPerSec * 1024 << "bytes/sec)"; + + // Wait for data to be readyRead + bool ok = connect(&senderObj, SIGNAL(dataReady()), this, SLOT(slotDataReady())); + Q_ASSERT(ok); + } + + void wrapUp() + { + QByteArray someData = device->read(device->bytesAvailable()); + data += someData; + totalBytesRead += someData.size(); + qDebug() << "wrapUp: found" << someData.size() << "bytes left. progress" << data.size(); + //qDebug() << "wrapUp: now bytesAvailable=" << device->bytesAvailable(); + } + +private slots: + void slotDataReady() + { + //qDebug() << "RateControlledReader: ready to go"; + startTimer(interval); + } + +protected: + void timerEvent(QTimerEvent *) + { + //qDebug() << "RateControlledReader: timerEvent bytesAvailable=" << device->bytesAvailable(); + if (readBufferSize > 0) { + // This asserts passes all the time, except in the final flush. + //Q_ASSERT(device->bytesAvailable() <= readBufferSize); + } + + qint64 bytesRead = 0; + QTime stopWatch; + stopWatch.start(); + do { + if (device->bytesAvailable() == 0) { + if (stopWatch.elapsed() > 20) { + qDebug() << "RateControlledReader: Not enough data available for reading, waited too much, timing out"; + break; + } + if (!device->waitForReadyRead(5)) { + qDebug() << "RateControlledReader: Not enough data available for reading, even after waiting 5ms, bailing out"; + break; + } + } + QByteArray someData = device->read(bytesToRead - bytesRead); + data += someData; + bytesRead += someData.size(); + //qDebug() << "RateControlledReader: successfully read" << someData.size() << "progress:" << data.size(); + } while (bytesRead < bytesToRead); + totalBytesRead += bytesRead; + + if (bytesRead < bytesToRead) + qWarning() << "RateControlledReader: WARNING:" << bytesToRead - bytesRead << "bytes not read"; + } +}; + + +tst_QNetworkReply::tst_QNetworkReply() +{ + qRegisterMetaType<QNetworkReply *>(); // for QSignalSpy + qRegisterMetaType<QAuthenticator *>(); + qRegisterMetaType<QNetworkProxy>(); +#ifndef QT_NO_OPENSSL + qRegisterMetaType<QList<QSslError> >(); +#endif + qRegisterMetaType<QNetworkReply::NetworkError>(); + + Q_SET_DEFAULT_IAP + + testFileName = QDir::currentPath() + "/testfile"; + uniqueExtension = createUniqueExtension(); + cookieJar = new MyCookieJar; + manager.setCookieJar(cookieJar); + + QHostInfo hostInfo = QHostInfo::fromName(QtNetworkSettings::serverName()); + + proxies << ProxyData(QNetworkProxy::NoProxy, "", false); + + if (hostInfo.error() == QHostInfo::NoError && !hostInfo.addresses().isEmpty()) { + QString proxyserver = hostInfo.addresses().first().toString(); + proxies << ProxyData(QNetworkProxy(QNetworkProxy::HttpProxy, proxyserver, 3128), "+proxy", false) + << ProxyData(QNetworkProxy(QNetworkProxy::HttpProxy, proxyserver, 3129), "+proxyauth", true) + // currently unsupported + // << ProxyData(QNetworkProxy(QNetworkProxy::HttpProxy, proxyserver, 3130), "+proxyauth-ntlm", true); + << ProxyData(QNetworkProxy(QNetworkProxy::Socks5Proxy, proxyserver, 1080), "+socks", false) + << ProxyData(QNetworkProxy(QNetworkProxy::Socks5Proxy, proxyserver, 1081), "+socksauth", true); + } else { + printf("==================================================================\n"); + printf("Proxy could not be looked up. No proxy will be used while testing!\n"); + printf("==================================================================\n"); + } +} + +tst_QNetworkReply::~tst_QNetworkReply() +{ +} + + +void tst_QNetworkReply::authenticationRequired(QNetworkReply*, QAuthenticator* auth) +{ + auth->setUser("httptest"); + auth->setPassword("httptest"); +} + +void tst_QNetworkReply::proxyAuthenticationRequired(const QNetworkProxy &, QAuthenticator* auth) +{ + auth->setUser("qsockstest"); + auth->setPassword("password"); +} + +#ifndef QT_NO_OPENSSL +void tst_QNetworkReply::sslErrors(QNetworkReply *reply, const QList<QSslError> &errors) +{ + reply->ignoreSslErrors(); + QVERIFY(!errors.isEmpty()); + QVERIFY(!reply->sslConfiguration().isNull()); +} + +void tst_QNetworkReply::storeSslConfiguration() +{ + storedSslConfiguration = QSslConfiguration(); + QNetworkReply *reply = qobject_cast<QNetworkReply *>(sender()); + if (reply) + storedSslConfiguration = reply->sslConfiguration(); +} +#endif + +QString tst_QNetworkReply::runMultipartRequest(const QNetworkRequest &request, + QNetworkReplyPtr &reply, + QHttpMultiPart *multiPart, + const QByteArray &verb) +{ + if (verb == "POST") + reply = manager.post(request, multiPart); + else + reply = manager.put(request, multiPart); + + // the code below is copied from tst_QNetworkReply::runSimpleRequest, see below + reply->setParent(this); + connect(reply, SIGNAL(finished()), SLOT(finished())); + connect(reply, SIGNAL(error(QNetworkReply::NetworkError)), SLOT(gotError())); + multiPart->setParent(reply); + + returnCode = Timeout; + loop = new QEventLoop; + QTimer::singleShot(25000, loop, SLOT(quit())); + int code = returnCode == Timeout ? loop->exec() : returnCode; + delete loop; + loop = 0; + + switch (code) { + case Failure: + return "Request failed: " + reply->errorString(); + case Timeout: + return "Network timeout"; + } + return QString(); +} + +QString tst_QNetworkReply::runSimpleRequest(QNetworkAccessManager::Operation op, + const QNetworkRequest &request, + QNetworkReplyPtr &reply, + const QByteArray &data) +{ + switch (op) { + case QNetworkAccessManager::HeadOperation: + reply = manager.head(request); + break; + + case QNetworkAccessManager::GetOperation: + reply = manager.get(request); + break; + + case QNetworkAccessManager::PutOperation: + reply = manager.put(request, data); + break; + + case QNetworkAccessManager::PostOperation: + reply = manager.post(request, data); + break; + + case QNetworkAccessManager::DeleteOperation: + reply = manager.deleteResource(request); + break; + + default: + Q_ASSERT_X(false, "tst_QNetworkReply", "Invalid/unknown operation requested"); + } + reply->setParent(this); + + returnCode = Timeout; + int code = Success; + + if (request.attribute(QNetworkRequest::SynchronousRequestAttribute).toBool()) { + if (reply->isFinished()) + code = reply->error() != QNetworkReply::NoError ? Failure : Success; + else + code = Failure; + } else { + connect(reply, SIGNAL(finished()), SLOT(finished())); + connect(reply, SIGNAL(error(QNetworkReply::NetworkError)), SLOT(gotError())); + + loop = new QEventLoop; + QTimer::singleShot(20000, loop, SLOT(quit())); + code = returnCode == Timeout ? loop->exec() : returnCode; + delete loop; + loop = 0; + } + + switch (code) { + case Failure: + return "Request failed: " + reply->errorString(); + case Timeout: + return "Network timeout"; + } + return QString(); +} + +QString tst_QNetworkReply::runCustomRequest(const QNetworkRequest &request, + QNetworkReplyPtr &reply, + const QByteArray &verb, + QIODevice *data) +{ + reply = manager.sendCustomRequest(request, verb, data); + reply->setParent(this); + connect(reply, SIGNAL(finished()), SLOT(finished())); + connect(reply, SIGNAL(error(QNetworkReply::NetworkError)), SLOT(gotError())); + + returnCode = Timeout; + loop = new QEventLoop; + QTimer::singleShot(20000, loop, SLOT(quit())); + int code = returnCode == Timeout ? loop->exec() : returnCode; + delete loop; + loop = 0; + + switch (code) { + case Failure: + return "Request failed: " + reply->errorString(); + case Timeout: + return "Network timeout"; + } + return QString(); +} + +void tst_QNetworkReply::finished() +{ + loop->exit(returnCode = Success); +} + +void tst_QNetworkReply::gotError() +{ + loop->exit(returnCode = Failure); + disconnect(QObject::sender(), SIGNAL(finished()), this, 0); +} + +void tst_QNetworkReply::initTestCase() +{ +#if !defined Q_OS_WIN + wronlyFileName = QDir::currentPath() + "/write-only"; + QFile wr(wronlyFileName); + QVERIFY(wr.open(QIODevice::WriteOnly | QIODevice::Truncate)); + wr.setPermissions(QFile::WriteOwner | QFile::WriteUser); + wr.close(); +#endif + + QDir::setSearchPaths("srcdir", QStringList() << SRCDIR); +#ifndef QT_NO_OPENSSL + QSslSocket::defaultCaCertificates(); //preload certificates +#endif +#ifndef QT_NO_BEARERMANAGEMENT + netConfMan = new QNetworkConfigurationManager(this); + networkConfiguration = netConfMan->defaultConfiguration(); + networkSession.reset(new QNetworkSession(networkConfiguration)); + if (!networkSession->isOpen()) { + networkSession->open(); + QVERIFY(networkSession->waitForOpened(30000)); + } +#endif +} + +void tst_QNetworkReply::cleanupTestCase() +{ +#if !defined Q_OS_WIN + QFile::remove(wronlyFileName); +#endif + if (networkSession && networkSession->isOpen()) { + networkSession->close(); + } +} + +void tst_QNetworkReply::init() +{ + cleanup(); +} + +void tst_QNetworkReply::cleanup() +{ + QFile file(testFileName); + QVERIFY(!file.exists() || file.remove()); + + // clear the internal cache + QNetworkAccessManagerPrivate::clearCache(&manager); + manager.setProxy(QNetworkProxy()); + manager.setCache(0); + + // clear cookies + cookieJar->setAllCookies(QList<QNetworkCookie>()); +} + +void tst_QNetworkReply::stateChecking() +{ + QUrl url = QUrl("file:///"); + QNetworkRequest req(url); // you can't open this file, I know + QNetworkReplyPtr reply = manager.get(req); + + QVERIFY(reply.data()); + QVERIFY(reply->isOpen()); + QVERIFY(reply->isReadable()); + QVERIFY(!reply->isWritable()); + + // both behaviours are OK since we might change underlying behaviour again + if (!reply->isFinished()) + QCOMPARE(reply->errorString(), QString("Unknown error")); + else + QVERIFY(!reply->errorString().isEmpty()); + + + QCOMPARE(reply->manager(), &manager); + QCOMPARE(reply->request(), req); + QCOMPARE(int(reply->operation()), int(QNetworkAccessManager::GetOperation)); + // error and not error are OK since we might change underlying behaviour again + if (!reply->isFinished()) + QCOMPARE(reply->error(), QNetworkReply::NoError); + QCOMPARE(reply->url(), url); + + reply->abort(); +} + +void tst_QNetworkReply::invalidProtocol() +{ + QUrl url = QUrl::fromEncoded("not-a-known-protocol://foo/bar"); + QNetworkRequest req(url); + QNetworkReplyPtr reply; + + QString errorMsg = "Request failed: Protocol \"not-a-known-protocol\" is unknown"; + QString result = runSimpleRequest(QNetworkAccessManager::GetOperation, req, reply); + QCOMPARE(result, errorMsg); + + QCOMPARE(reply->url(), url); + QCOMPARE(reply->error(), QNetworkReply::ProtocolUnknownError); +} + +void tst_QNetworkReply::getFromData_data() +{ + QTest::addColumn<QString>("request"); + QTest::addColumn<QByteArray>("expected"); + QTest::addColumn<QString>("mimeType"); + + const QString defaultMimeType("text/plain;charset=US-ASCII"); + + //QTest::newRow("empty") << "data:" << QByteArray() << defaultMimeType; + QTest::newRow("empty2") << "data:," << QByteArray() << defaultMimeType; + QTest::newRow("just-charset_1") << "data:charset=iso-8859-1," + << QByteArray() << "text/plain;charset=iso-8859-1"; + QTest::newRow("just-charset_2") << "data:charset = iso-8859-1 ," + << QByteArray() << "text/plain;charset = iso-8859-1"; + //QTest::newRow("just-media") << "data:text/xml" << QByteArray() << "text/xml"; + QTest::newRow("just-media2") << "data:text/xml," << QByteArray() << "text/xml"; + + QTest::newRow("plain_1") << "data:,foo" << QByteArray("foo") << defaultMimeType; + QTest::newRow("plain_2") << "data:text/html,Hello World" << QByteArray("Hello World") + << "text/html"; + QTest::newRow("plain_3") << "data:text/html;charset=utf-8,Hello World" + << QByteArray("Hello World") << "text/html;charset=utf-8"; + + QTest::newRow("pct_1") << "data:,%3Cbody%20contentEditable%3Dtrue%3E%0D%0A" + << QByteArray("<body contentEditable=true>\r\n") << defaultMimeType; + QTest::newRow("pct_2") << "data:text/html;charset=utf-8,%3Cbody%20contentEditable%3Dtrue%3E%0D%0A" + << QByteArray("<body contentEditable=true>\r\n") + << "text/html;charset=utf-8"; + + QTest::newRow("base64-empty_1") << "data:;base64," << QByteArray() << defaultMimeType; + QTest::newRow("base64-empty_2") << "data:charset=utf-8;base64," << QByteArray() + << "text/plain;charset=utf-8"; + QTest::newRow("base64-empty_3") << "data:text/html;charset=utf-8;base64," + << QByteArray() << "text/html;charset=utf-8"; + + QTest::newRow("base64_1") << "data:;base64,UXQgaXMgZ3JlYXQh" << QByteArray("Qt is great!") + << defaultMimeType; + QTest::newRow("base64_2") << "data:charset=utf-8;base64,UXQgaXMgZ3JlYXQh" + << QByteArray("Qt is great!") << "text/plain;charset=utf-8"; + QTest::newRow("base64_3") << "data:text/html;charset=utf-8;base64,UXQgaXMgZ3JlYXQh" + << QByteArray("Qt is great!") << "text/html;charset=utf-8"; + + QTest::newRow("pct-nul") << "data:,a%00g" << QByteArray("a\0g", 3) << defaultMimeType; + QTest::newRow("base64-nul") << "data:;base64,YQBn" << QByteArray("a\0g", 3) << defaultMimeType; + QTest::newRow("pct-nonutf8") << "data:,a%E1g" << QByteArray("a\xE1g", 3) << defaultMimeType; + + QTest::newRow("base64") + << QString::fromLatin1("data:application/xml;base64,PGUvPg==") + << QByteArray("<e/>") + << "application/xml"; + + QTest::newRow("base64, no media type") + << QString::fromLatin1("data:;base64,PGUvPg==") + << QByteArray("<e/>") + << defaultMimeType; + + QTest::newRow("Percent encoding") + << QString::fromLatin1("data:application/xml,%3Ce%2F%3E") + << QByteArray("<e/>") + << "application/xml"; + + QTest::newRow("Percent encoding, no media type") + << QString::fromLatin1("data:,%3Ce%2F%3E") + << QByteArray("<e/>") + << defaultMimeType; + + QTest::newRow("querychars") + << QString::fromLatin1("data:,foo?x=0&y=0") + << QByteArray("foo?x=0&y=0") + << defaultMimeType; + + QTest::newRow("css") << "data:text/css,div%20{%20border-right:%20solid;%20}" + << QByteArray("div { border-right: solid; }") + << "text/css"; +} + +void tst_QNetworkReply::getFromData() +{ + QFETCH(QString, request); + QFETCH(QByteArray, expected); + QFETCH(QString, mimeType); + + QUrl url = QUrl::fromEncoded(request.toLatin1()); + QNetworkRequest req(url); + QNetworkReplyPtr reply; + + RUN_REQUEST(runSimpleRequest(QNetworkAccessManager::GetOperation, req, reply)); + + QCOMPARE(reply->url(), url); + QCOMPARE(reply->error(), QNetworkReply::NoError); + + QCOMPARE(reply->header(QNetworkRequest::ContentTypeHeader).toString(), mimeType); + QCOMPARE(reply->header(QNetworkRequest::ContentLengthHeader).toLongLong(), qint64(expected.size())); + QCOMPARE(reply->readAll(), expected); +} + +void tst_QNetworkReply::getFromFile() +{ + // create the file: + QTemporaryFile file(QDir::currentPath() + "/temp-XXXXXX"); + file.setAutoRemove(true); + QVERIFY(file.open()); + + QNetworkRequest request(QUrl::fromLocalFile(file.fileName())); + QNetworkReplyPtr reply; + + static const char fileData[] = "This is some data that is in the file.\r\n"; + QByteArray data = QByteArray::fromRawData(fileData, sizeof fileData - 1); + QVERIFY(file.write(data) == data.size()); + file.flush(); + QCOMPARE(file.size(), qint64(data.size())); + + RUN_REQUEST(runSimpleRequest(QNetworkAccessManager::GetOperation, request, reply)); + + QCOMPARE(reply->url(), request.url()); + QCOMPARE(reply->error(), QNetworkReply::NoError); + + QCOMPARE(reply->header(QNetworkRequest::ContentLengthHeader).toLongLong(), file.size()); + QCOMPARE(reply->readAll(), data); + + // make the file bigger + file.resize(0); + const int multiply = (128 * 1024) / (sizeof fileData - 1); + for (int i = 0; i < multiply; ++i) + file.write(fileData, sizeof fileData - 1); + file.flush(); + + // run again + reply = 0; + + RUN_REQUEST(runSimpleRequest(QNetworkAccessManager::GetOperation, request, reply)); + QCOMPARE(reply->url(), request.url()); + QCOMPARE(reply->error(), QNetworkReply::NoError); + + QCOMPARE(reply->header(QNetworkRequest::ContentLengthHeader).toLongLong(), file.size()); + QCOMPARE(qint64(reply->readAll().size()), file.size()); +} + +void tst_QNetworkReply::getFromFileSpecial_data() +{ + QTest::addColumn<QString>("fileName"); + QTest::addColumn<QString>("url"); + + QTest::newRow("resource") << ":/resource" << "qrc:/resource"; + QTest::newRow("search-path") << "srcdir:/rfc3252.txt" << "srcdir:/rfc3252.txt"; + QTest::newRow("bigfile-path") << "srcdir:/bigfile" << "srcdir:/bigfile"; +#ifdef Q_OS_WIN + QTest::newRow("smb-path") << "srcdir:/smb-file.txt" << "file://" + QtNetworkSettings::winServerName() + "/testshare/test.pri"; +#endif +} + +void tst_QNetworkReply::getFromFileSpecial() +{ + QFETCH(QString, fileName); + QFETCH(QString, url); + + // open the resource so we can find out its size + QFile resource(fileName); + QVERIFY(resource.open(QIODevice::ReadOnly)); + + QNetworkRequest request; + QNetworkReplyPtr reply; + request.setUrl(url); + RUN_REQUEST(runSimpleRequest(QNetworkAccessManager::GetOperation, request, reply)); + + QCOMPARE(reply->url(), request.url()); + QCOMPARE(reply->error(), QNetworkReply::NoError); + + QCOMPARE(reply->header(QNetworkRequest::ContentLengthHeader).toLongLong(), resource.size()); + QCOMPARE(reply->readAll(), resource.readAll()); +} + +void tst_QNetworkReply::getFromFtp_data() +{ + QTest::addColumn<QString>("referenceName"); + QTest::addColumn<QString>("url"); + + QTest::newRow("rfc3252.txt") << SRCDIR "/rfc3252.txt" << "ftp://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt"; + QTest::newRow("bigfile") << SRCDIR "/bigfile" << "ftp://" + QtNetworkSettings::serverName() + "/qtest/bigfile"; +} + +void tst_QNetworkReply::getFromFtp() +{ + QFETCH(QString, referenceName); + QFETCH(QString, url); + + QFile reference(referenceName); + QVERIFY(reference.open(QIODevice::ReadOnly)); + + QNetworkRequest request(url); + QNetworkReplyPtr reply; + RUN_REQUEST(runSimpleRequest(QNetworkAccessManager::GetOperation, request, reply)); + + QCOMPARE(reply->url(), request.url()); + QCOMPARE(reply->error(), QNetworkReply::NoError); + + QCOMPARE(reply->header(QNetworkRequest::ContentLengthHeader).toLongLong(), reference.size()); + QCOMPARE(reply->readAll(), reference.readAll()); +} + +void tst_QNetworkReply::getFromHttp_data() +{ + QTest::addColumn<QString>("referenceName"); + QTest::addColumn<QString>("url"); + + QTest::newRow("success-internal") << SRCDIR "/rfc3252.txt" << "http://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt"; + QTest::newRow("success-external") << SRCDIR "/rfc3252.txt" << "http://www.ietf.org/rfc/rfc3252.txt"; + QTest::newRow("bigfile-internal") << SRCDIR "/bigfile" << "http://" + QtNetworkSettings::serverName() + "/qtest/bigfile"; +} + +void tst_QNetworkReply::getFromHttp() +{ + QFETCH(QString, referenceName); + QFETCH(QString, url); + + QFile reference(referenceName); + QVERIFY(reference.open(QIODevice::ReadOnly)); + + QNetworkRequest request(url); + QNetworkReplyPtr reply; + RUN_REQUEST(runSimpleRequest(QNetworkAccessManager::GetOperation, request, reply)); + + QCOMPARE(reply->url(), request.url()); + QCOMPARE(reply->error(), QNetworkReply::NoError); + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); + QCOMPARE(reply->size(), reference.size()); + // only compare when the header is set. + if (reply->header(QNetworkRequest::ContentLengthHeader).isValid()) + QCOMPARE(reply->header(QNetworkRequest::ContentLengthHeader).toLongLong(), reference.size()); + QCOMPARE(reply->readAll(), reference.readAll()); +} + +void tst_QNetworkReply::getErrors_data() +{ + QTest::addColumn<QString>("url"); + QTest::addColumn<int>("error"); + QTest::addColumn<int>("httpStatusCode"); + QTest::addColumn<bool>("dataIsEmpty"); + + // empties + QTest::newRow("empty-url") << QString() << int(QNetworkReply::ProtocolUnknownError) << 0 << true; + QTest::newRow("empty-scheme-host") << SRCDIR "/rfc3252.txt" << int(QNetworkReply::ProtocolUnknownError) << 0 << true; + QTest::newRow("empty-scheme") << "//" + QtNetworkSettings::winServerName() + "/testshare/test.pri" + << int(QNetworkReply::ProtocolUnknownError) << 0 << true; + + // file: errors + QTest::newRow("file-host") << "file://this-host-doesnt-exist.troll.no/foo.txt" +#if !defined Q_OS_WIN + << int(QNetworkReply::ProtocolInvalidOperationError) << 0 << true; +#else + << int(QNetworkReply::ContentNotFoundError) << 0 << true; +#endif + QTest::newRow("file-no-path") << "file://localhost" + << int(QNetworkReply::ContentOperationNotPermittedError) << 0 << true; + QTest::newRow("file-is-dir") << QUrl::fromLocalFile(QDir::currentPath()).toString() + << int(QNetworkReply::ContentOperationNotPermittedError) << 0 << true; + QTest::newRow("file-exist") << QUrl::fromLocalFile(QDir::currentPath() + "/this-file-doesnt-exist.txt").toString() + << int(QNetworkReply::ContentNotFoundError) << 0 << true; +#if !defined Q_OS_WIN && !defined(Q_OS_SYMBIAN) + QTest::newRow("file-is-wronly") << QUrl::fromLocalFile(wronlyFileName).toString() + << int(QNetworkReply::ContentAccessDenied) << 0 << true; +#endif + if (QFile::exists("/etc/shadow")) + QTest::newRow("file-permissions") << "file:/etc/shadow" + << int(QNetworkReply::ContentAccessDenied) << 0 << true; + + // ftp: errors + QTest::newRow("ftp-host") << "ftp://this-host-doesnt-exist.troll.no/foo.txt" + << int(QNetworkReply::HostNotFoundError) << 0 << true; + QTest::newRow("ftp-no-path") << "ftp://" + QtNetworkSettings::serverName() + << int(QNetworkReply::ContentOperationNotPermittedError) << 0 << true; + QTest::newRow("ftp-is-dir") << "ftp://" + QtNetworkSettings::serverName() + "/qtest" + << int(QNetworkReply::ContentOperationNotPermittedError) << 0 << true; + QTest::newRow("ftp-dir-not-readable") << "ftp://" + QtNetworkSettings::serverName() + "/pub/dir-not-readable/foo.txt" + << int(QNetworkReply::ContentAccessDenied) << 0 << true; + QTest::newRow("ftp-file-not-readable") << "ftp://" + QtNetworkSettings::serverName() + "/pub/file-not-readable.txt" + << int(QNetworkReply::ContentAccessDenied) << 0 << true; + QTest::newRow("ftp-exist") << "ftp://" + QtNetworkSettings::serverName() + "/pub/this-file-doesnt-exist.txt" + << int(QNetworkReply::ContentNotFoundError) << 0 << true; + + // http: errors + QTest::newRow("http-host") << "http://this-host-will-never-exist.troll.no/" + << int(QNetworkReply::HostNotFoundError) << 0 << true; + QTest::newRow("http-exist") << "http://" + QtNetworkSettings::serverName() + "/this-file-doesnt-exist.txt" + << int(QNetworkReply::ContentNotFoundError) << 404 << false; + QTest::newRow("http-authentication") << "http://" + QtNetworkSettings::serverName() + "/qtest/rfcs-auth" + << int(QNetworkReply::AuthenticationRequiredError) << 401 << false; +} + +void tst_QNetworkReply::getErrors() +{ + QFETCH(QString, url); + QNetworkRequest request(url); + +#if defined(Q_OS_WIN) || defined (Q_OS_SYMBIAN) + if (qstrcmp(QTest::currentDataTag(), "empty-scheme-host") == 0 && QFileInfo(url).isAbsolute()) + QTest::ignoreMessage(QtWarningMsg, "QNetworkAccessFileBackendFactory: URL has no schema set, use file:// for files"); +#endif + + QNetworkReplyPtr reply = manager.get(request); + reply->setParent(this); // we have expect-fails + + if (!reply->isFinished()) + QCOMPARE(reply->error(), QNetworkReply::NoError); + + // now run the request: + connect(reply, SIGNAL(finished()), + &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + //qDebug() << reply->errorString(); + + QFETCH(int, error); +#if defined(Q_OS_WIN) || defined (Q_OS_SYMBIAN) + if (QFileInfo(url).isAbsolute()) + QEXPECT_FAIL("empty-scheme-host", "this is expected to fail on Windows and Symbian, QTBUG-17731", Abort); +#endif + QEXPECT_FAIL("ftp-is-dir", "QFtp cannot provide enough detail", Abort); + // the line below is not necessary + QEXPECT_FAIL("ftp-dir-not-readable", "QFtp cannot provide enough detail", Abort); + QCOMPARE(reply->error(), QNetworkReply::NetworkError(error)); + + QTEST(reply->readAll().isEmpty(), "dataIsEmpty"); + + QVERIFY(reply->isFinished()); + QVERIFY(!reply->isRunning()); + + QFETCH(int, httpStatusCode); + if (httpStatusCode != 0) { + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), httpStatusCode); + } +} + +static inline QByteArray md5sum(const QByteArray &data) +{ + return QCryptographicHash::hash(data, QCryptographicHash::Md5); +} + +void tst_QNetworkReply::putToFile_data() +{ + QTest::addColumn<QByteArray>("data"); + QTest::addColumn<QByteArray>("md5sum"); + + QByteArray data; + data = ""; + QTest::newRow("empty") << data << md5sum(data); + + data = "This is a normal message."; + QTest::newRow("generic") << data << md5sum(data); + + data = "This is a message to show that Qt rocks!\r\n\n"; + QTest::newRow("small") << data << md5sum(data); + + data = QByteArray("abcd\0\1\2\abcd",12); + QTest::newRow("with-nul") << data << md5sum(data); + + data = QByteArray(4097, '\4'); + QTest::newRow("4k+1") << data << md5sum(data); + + data = QByteArray(128*1024+1, '\177'); + QTest::newRow("128k+1") << data << md5sum(data); + + data = QByteArray(2*1024*1024+1, '\177'); + QTest::newRow("2MB+1") << data << md5sum(data); +} + +void tst_QNetworkReply::putToFile() +{ + QFile file(testFileName); + + QUrl url = QUrl::fromLocalFile(file.fileName()); + QNetworkRequest request(url); + QNetworkReplyPtr reply; + + QFETCH(QByteArray, data); + + RUN_REQUEST(runSimpleRequest(QNetworkAccessManager::PutOperation, request, reply, data)); + + QCOMPARE(reply->url(), url); + QCOMPARE(reply->error(), QNetworkReply::NoError); + QCOMPARE(reply->header(QNetworkRequest::ContentLengthHeader).toLongLong(), Q_INT64_C(0)); + QVERIFY(reply->readAll().isEmpty()); + + QVERIFY(file.open(QIODevice::ReadOnly)); + QCOMPARE(file.size(), qint64(data.size())); + QByteArray contents = file.readAll(); + QCOMPARE(contents, data); +} + +void tst_QNetworkReply::putToFtp_data() +{ + putToFile_data(); +} + +void tst_QNetworkReply::putToFtp() +{ + QUrl url("ftp://" + QtNetworkSettings::serverName()); + url.setPath(QString("/qtest/upload/qnetworkaccess-putToFtp-%1-%2") + .arg(QTest::currentDataTag()) + .arg(uniqueExtension)); + + QNetworkRequest request(url); + QNetworkReplyPtr reply; + + QFETCH(QByteArray, data); + + RUN_REQUEST(runSimpleRequest(QNetworkAccessManager::PutOperation, request, reply, data)); + + QCOMPARE(reply->url(), url); + QCOMPARE(reply->error(), QNetworkReply::NoError); + QCOMPARE(reply->header(QNetworkRequest::ContentLengthHeader).toLongLong(), Q_INT64_C(0)); + QVERIFY(reply->readAll().isEmpty()); + + // download the file again from FTP to make sure it was uploaded + // correctly + QFtp ftp; + ftp.connectToHost(url.host()); + ftp.login(); + ftp.get(url.path()); + + QObject::connect(&ftp, SIGNAL(done(bool)), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QObject::disconnect(&ftp, SIGNAL(done(bool)), &QTestEventLoop::instance(), SLOT(exitLoop())); + + QByteArray uploaded = ftp.readAll(); + QCOMPARE(uploaded.size(), data.size()); + QCOMPARE(uploaded, data); + + ftp.close(); + QObject::connect(&ftp, SIGNAL(done(bool)), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QObject::disconnect(&ftp, SIGNAL(done(bool)), &QTestEventLoop::instance(), SLOT(exitLoop())); +} + +void tst_QNetworkReply::putToHttp_data() +{ + putToFile_data(); +} + +void tst_QNetworkReply::putToHttp() +{ + QUrl url("http://" + QtNetworkSettings::serverName()); + url.setPath(QString("/dav/qnetworkaccess-putToHttp-%1-%2") + .arg(QTest::currentDataTag()) + .arg(uniqueExtension)); + + QNetworkRequest request(url); + QNetworkReplyPtr reply; + + QFETCH(QByteArray, data); + + RUN_REQUEST(runSimpleRequest(QNetworkAccessManager::PutOperation, request, reply, data)); + + QCOMPARE(reply->url(), url); + QCOMPARE(reply->error(), QNetworkReply::NoError); + + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 201); // 201 Created + + // download the file again from HTTP to make sure it was uploaded + // correctly. HTTP/0.9 is enough + QTcpSocket socket; + socket.connectToHost(QtNetworkSettings::serverName(), 80); + socket.write("GET " + url.toEncoded(QUrl::RemoveScheme | QUrl::RemoveAuthority) + "\r\n"); + if (!socket.waitForDisconnected(10000)) + QFAIL("Network timeout"); + + QByteArray uploadedData = socket.readAll(); + QCOMPARE(uploadedData, data); +} + +void tst_QNetworkReply::putToHttpSynchronous_data() +{ + uniqueExtension = createUniqueExtension(); + putToFile_data(); +} + +void tst_QNetworkReply::putToHttpSynchronous() +{ + QUrl url("http://" + QtNetworkSettings::serverName()); + url.setPath(QString("/dav/qnetworkaccess-putToHttp-%1-%2") + .arg(QTest::currentDataTag()) + .arg(uniqueExtension)); + + QNetworkRequest request(url); + QNetworkReplyPtr reply; + + QFETCH(QByteArray, data); + + request.setAttribute( + QNetworkRequest::SynchronousRequestAttribute, + true); + + RUN_REQUEST(runSimpleRequest(QNetworkAccessManager::PutOperation, request, reply, data)); + + QCOMPARE(reply->url(), url); + QCOMPARE(reply->error(), QNetworkReply::NoError); + + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 201); // 201 Created + + // download the file again from HTTP to make sure it was uploaded + // correctly. HTTP/0.9 is enough + QTcpSocket socket; + socket.connectToHost(QtNetworkSettings::serverName(), 80); + socket.write("GET " + url.toEncoded(QUrl::RemoveScheme | QUrl::RemoveAuthority) + "\r\n"); + if (!socket.waitForDisconnected(10000)) + QFAIL("Network timeout"); + + QByteArray uploadedData = socket.readAll(); + QCOMPARE(uploadedData, data); +} + +void tst_QNetworkReply::postToHttp_data() +{ + putToFile_data(); +} + +void tst_QNetworkReply::postToHttp() +{ + QUrl url("http://" + QtNetworkSettings::serverName() + "/qtest/cgi-bin/md5sum.cgi"); + + QNetworkRequest request(url); + request.setRawHeader("Content-Type", "application/octet-stream"); + QNetworkReplyPtr reply; + + QFETCH(QByteArray, data); + + RUN_REQUEST(runSimpleRequest(QNetworkAccessManager::PostOperation, request, reply, data)); + + QCOMPARE(reply->url(), url); + QCOMPARE(reply->error(), QNetworkReply::NoError); + + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); // 200 Ok + + QFETCH(QByteArray, md5sum); + QByteArray uploadedData = reply->readAll().trimmed(); + QCOMPARE(uploadedData, md5sum.toHex()); +} + +void tst_QNetworkReply::postToHttpSynchronous_data() +{ + putToFile_data(); +} + +void tst_QNetworkReply::postToHttpSynchronous() +{ + QUrl url("http://" + QtNetworkSettings::serverName() + "/qtest/cgi-bin/md5sum.cgi"); + + QNetworkRequest request(url); + request.setRawHeader("Content-Type", "application/octet-stream"); + + request.setAttribute( + QNetworkRequest::SynchronousRequestAttribute, + true); + + QNetworkReplyPtr reply; + + QFETCH(QByteArray, data); + + RUN_REQUEST(runSimpleRequest(QNetworkAccessManager::PostOperation, request, reply, data)); + + QCOMPARE(reply->url(), url); + QCOMPARE(reply->error(), QNetworkReply::NoError); + + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); // 200 Ok + + QFETCH(QByteArray, md5sum); + QByteArray uploadedData = reply->readAll().trimmed(); + QCOMPARE(uploadedData, md5sum.toHex()); +} + +void tst_QNetworkReply::postToHttpMultipart_data() +{ + QTest::addColumn<QUrl>("url"); + QTest::addColumn<QHttpMultiPart *>("multiPart"); + QTest::addColumn<QByteArray>("expectedReplyData"); + QTest::addColumn<QByteArray>("contentType"); + + QUrl url("http://" + QtNetworkSettings::serverName() + "/qtest/cgi-bin/multipart.cgi"); + QByteArray expectedData; + + + // empty parts + + QHttpMultiPart *emptyMultiPart = new QHttpMultiPart; + QTest::newRow("empty") << url << emptyMultiPart << expectedData << QByteArray("mixed"); + + QHttpMultiPart *emptyRelatedMultiPart = new QHttpMultiPart; + emptyRelatedMultiPart->setContentType(QHttpMultiPart::RelatedType); + QTest::newRow("empty-related") << url << emptyRelatedMultiPart << expectedData << QByteArray("related"); + + QHttpMultiPart *emptyAlternativeMultiPart = new QHttpMultiPart; + emptyAlternativeMultiPart->setContentType(QHttpMultiPart::AlternativeType); + QTest::newRow("empty-alternative") << url << emptyAlternativeMultiPart << expectedData << QByteArray("alternative"); + + + // text-only parts + + QHttpPart textPart; + textPart.setHeader(QNetworkRequest::ContentTypeHeader, QVariant("text/plain")); + textPart.setHeader(QNetworkRequest::ContentDispositionHeader, QVariant("form-data; name=\"text\"")); + textPart.setBody("7 bytes"); + QHttpMultiPart *multiPart1 = new QHttpMultiPart; + multiPart1->setContentType(QHttpMultiPart::FormDataType); + multiPart1->append(textPart); + expectedData = "key: text, value: 7 bytes\n"; + QTest::newRow("text") << url << multiPart1 << expectedData << QByteArray("form-data"); + + QHttpMultiPart *customMultiPart = new QHttpMultiPart; + customMultiPart->append(textPart); + expectedData = "header: Content-Type, value: 'text/plain'\n" + "header: Content-Disposition, value: 'form-data; name=\"text\"'\n" + "content: 7 bytes\n" + "\n"; + QTest::newRow("text-custom") << url << customMultiPart << expectedData << QByteArray("custom"); + + QHttpPart textPart2; + textPart2.setHeader(QNetworkRequest::ContentTypeHeader, QVariant("text/plain")); + textPart2.setRawHeader("myRawHeader", "myValue"); + textPart2.setHeader(QNetworkRequest::ContentDispositionHeader, QVariant("form-data; name=\"text2\"")); + textPart2.setBody("some more bytes"); + textPart2.setBodyDevice((QIODevice *) 1); // test whether setting and unsetting of the device works + textPart2.setBodyDevice(0); + QHttpMultiPart *multiPart2 = new QHttpMultiPart; + multiPart2->setContentType(QHttpMultiPart::FormDataType); + multiPart2->append(textPart); + multiPart2->append(textPart2); + expectedData = "key: text2, value: some more bytes\n" + "key: text, value: 7 bytes\n"; + QTest::newRow("text-text") << url << multiPart2 << expectedData << QByteArray("form-data"); + + + QHttpPart textPart3; + textPart3.setHeader(QNetworkRequest::ContentTypeHeader, QVariant("text/plain")); + textPart3.setHeader(QNetworkRequest::ContentDispositionHeader, QVariant("form-data; name=\"text3\"")); + textPart3.setRawHeader("Content-Location", "http://my.test.location.tld"); + textPart3.setBody("even more bytes"); + QHttpMultiPart *multiPart3 = new QHttpMultiPart; + multiPart3->setContentType(QHttpMultiPart::AlternativeType); + multiPart3->append(textPart); + multiPart3->append(textPart2); + multiPart3->append(textPart3); + expectedData = "header: Content-Type, value: 'text/plain'\n" + "header: Content-Disposition, value: 'form-data; name=\"text\"'\n" + "content: 7 bytes\n" + "\n" + "header: Content-Type, value: 'text/plain'\n" + "header: myRawHeader, value: 'myValue'\n" + "header: Content-Disposition, value: 'form-data; name=\"text2\"'\n" + "content: some more bytes\n" + "\n" + "header: Content-Type, value: 'text/plain'\n" + "header: Content-Disposition, value: 'form-data; name=\"text3\"'\n" + "header: Content-Location, value: 'http://my.test.location.tld'\n" + "content: even more bytes\n\n"; + QTest::newRow("text-text-text") << url << multiPart3 << expectedData << QByteArray("alternative"); + + + + // text and image parts + + QHttpPart imagePart11; + imagePart11.setHeader(QNetworkRequest::ContentTypeHeader, QVariant("image/jpeg")); + imagePart11.setHeader(QNetworkRequest::ContentDispositionHeader, QVariant("form-data; name=\"testImage\"")); + imagePart11.setRawHeader("Content-Location", "http://my.test.location.tld"); + imagePart11.setRawHeader("Content-ID", "my@id.tld"); + QFile *file11 = new QFile(SRCDIR "/image1.jpg"); + file11->open(QIODevice::ReadOnly); + imagePart11.setBodyDevice(file11); + QHttpMultiPart *imageMultiPart1 = new QHttpMultiPart(QHttpMultiPart::FormDataType); + imageMultiPart1->append(imagePart11); + file11->setParent(imageMultiPart1); + expectedData = "key: testImage, value: 87ef3bb319b004ba9e5e9c9fa713776e\n"; // md5 sum of file + QTest::newRow("image") << url << imageMultiPart1 << expectedData << QByteArray("form-data"); + + QHttpPart imagePart21; + imagePart21.setHeader(QNetworkRequest::ContentTypeHeader, QVariant("image/jpeg")); + imagePart21.setHeader(QNetworkRequest::ContentDispositionHeader, QVariant("form-data; name=\"testImage1\"")); + imagePart21.setRawHeader("Content-Location", "http://my.test.location.tld"); + imagePart21.setRawHeader("Content-ID", "my@id.tld"); + QFile *file21 = new QFile(SRCDIR "/image1.jpg"); + file21->open(QIODevice::ReadOnly); + imagePart21.setBodyDevice(file21); + QHttpMultiPart *imageMultiPart2 = new QHttpMultiPart(); + imageMultiPart2->setContentType(QHttpMultiPart::FormDataType); + imageMultiPart2->append(textPart); + imageMultiPart2->append(imagePart21); + file21->setParent(imageMultiPart2); + QHttpPart imagePart22; + imagePart22.setHeader(QNetworkRequest::ContentTypeHeader, QVariant("image/jpeg")); + imagePart22.setHeader(QNetworkRequest::ContentDispositionHeader, QVariant("form-data; name=\"testImage2\"")); + QFile *file22 = new QFile(SRCDIR "/image2.jpg"); + file22->open(QIODevice::ReadOnly); + imagePart22.setBodyDevice(file22); + imageMultiPart2->append(imagePart22); + file22->setParent(imageMultiPart2); + expectedData = "key: testImage1, value: 87ef3bb319b004ba9e5e9c9fa713776e\n" + "key: text, value: 7 bytes\n" + "key: testImage2, value: 483761b893f7fb1bd2414344cd1f3dfb\n"; + QTest::newRow("text-image-image") << url << imageMultiPart2 << expectedData << QByteArray("form-data"); + + + QHttpPart imagePart31; + imagePart31.setHeader(QNetworkRequest::ContentTypeHeader, QVariant("image/jpeg")); + imagePart31.setHeader(QNetworkRequest::ContentDispositionHeader, QVariant("form-data; name=\"testImage1\"")); + imagePart31.setRawHeader("Content-Location", "http://my.test.location.tld"); + imagePart31.setRawHeader("Content-ID", "my@id.tld"); + QFile *file31 = new QFile(SRCDIR "/image1.jpg"); + file31->open(QIODevice::ReadOnly); + imagePart31.setBodyDevice(file31); + QHttpMultiPart *imageMultiPart3 = new QHttpMultiPart(QHttpMultiPart::FormDataType); + imageMultiPart3->append(imagePart31); + file31->setParent(imageMultiPart3); + QHttpPart imagePart32; + imagePart32.setHeader(QNetworkRequest::ContentTypeHeader, QVariant("image/jpeg")); + imagePart32.setHeader(QNetworkRequest::ContentDispositionHeader, QVariant("form-data; name=\"testImage2\"")); + QFile *file32 = new QFile(SRCDIR "/image2.jpg"); + file32->open(QIODevice::ReadOnly); + imagePart32.setBodyDevice(file31); // check that resetting works + imagePart32.setBodyDevice(file32); + imageMultiPart3->append(imagePart32); + file32->setParent(imageMultiPart3); + QHttpPart imagePart33; + imagePart33.setHeader(QNetworkRequest::ContentTypeHeader, QVariant("image/jpeg")); + imagePart33.setHeader(QNetworkRequest::ContentDispositionHeader, QVariant("form-data; name=\"testImage3\"")); + QFile *file33 = new QFile(SRCDIR "/image3.jpg"); + file33->open(QIODevice::ReadOnly); + imagePart33.setBodyDevice(file33); + imageMultiPart3->append(imagePart33); + file33->setParent(imageMultiPart3); + expectedData = "key: testImage1, value: 87ef3bb319b004ba9e5e9c9fa713776e\n" + "key: testImage2, value: 483761b893f7fb1bd2414344cd1f3dfb\n" + "key: testImage3, value: ab0eb6fd4fcf8b4436254870b4513033\n"; + QTest::newRow("3-images") << url << imageMultiPart3 << expectedData << QByteArray("form-data"); + + + // note: nesting multiparts is not working currently; for that, the outputDevice would need to be public + +// QHttpPart imagePart41; +// imagePart41.setHeader(QNetworkRequest::ContentTypeHeader, QVariant("image/jpeg")); +// QFile *file41 = new QFile(SRCDIR "/image1.jpg"); +// file41->open(QIODevice::ReadOnly); +// imagePart41.setBodyDevice(file41); +// +// QHttpMultiPart *innerMultiPart = new QHttpMultiPart(); +// innerMultiPart->setContentType(QHttpMultiPart::FormDataType); +// textPart.setHeader(QNetworkRequest::ContentDispositionHeader, QVariant()); +// innerMultiPart->append(textPart); +// innerMultiPart->append(imagePart41); +// textPart2.setHeader(QNetworkRequest::ContentDispositionHeader, QVariant()); +// innerMultiPart->append(textPart2); +// +// QHttpPart nestedPart; +// nestedPart.setHeader(QNetworkRequest::ContentDispositionHeader, QVariant("form-data; name=\"nestedMessage")); +// nestedPart.setHeader(QNetworkRequest::ContentTypeHeader, QVariant("multipart/alternative; boundary=\"" + innerMultiPart->boundary() + "\"")); +// innerMultiPart->outputDevice()->open(QIODevice::ReadOnly); +// nestedPart.setBodyDevice(innerMultiPart->outputDevice()); +// +// QHttpMultiPart *outerMultiPart = new QHttpMultiPart; +// outerMultiPart->setContentType(QHttpMultiPart::FormDataType); +// outerMultiPart->append(textPart); +// outerMultiPart->append(nestedPart); +// outerMultiPart->append(textPart2); +// expectedData = "nothing"; // the CGI.pm module running on the test server does not understand nested multiparts +// openFiles.clear(); +// openFiles << file41; +// QTest::newRow("nested") << url << outerMultiPart << expectedData << openFiles; + + + // test setting large chunks of content with a byte array instead of a device (DISCOURAGED because of high memory consumption, + // but we need to test that the behavior is correct) + QHttpPart imagePart51; + imagePart51.setHeader(QNetworkRequest::ContentTypeHeader, QVariant("image/jpeg")); + imagePart51.setHeader(QNetworkRequest::ContentDispositionHeader, QVariant("form-data; name=\"testImage\"")); + QFile *file51 = new QFile(SRCDIR "/image1.jpg"); + file51->open(QIODevice::ReadOnly); + QByteArray imageData = file51->readAll(); + file51->close(); + delete file51; + imagePart51.setBody("7 bytes"); // check that resetting works + imagePart51.setBody(imageData); + QHttpMultiPart *imageMultiPart5 = new QHttpMultiPart; + imageMultiPart5->setContentType(QHttpMultiPart::FormDataType); + imageMultiPart5->append(imagePart51); + expectedData = "key: testImage, value: 87ef3bb319b004ba9e5e9c9fa713776e\n"; // md5 sum of file + QTest::newRow("image-as-content") << url << imageMultiPart5 << expectedData << QByteArray("form-data"); +} + +void tst_QNetworkReply::postToHttpMultipart() +{ + QFETCH(QUrl, url); + + static QSet<QByteArray> boundaries; + + QNetworkRequest request(url); + QNetworkReplyPtr reply; + + QFETCH(QHttpMultiPart *, multiPart); + QFETCH(QByteArray, expectedReplyData); + QFETCH(QByteArray, contentType); + + // hack for testing the setting of the content-type header by hand: + if (contentType == "custom") { + QByteArray contentType("multipart/custom; boundary=\"" + multiPart->boundary() + "\""); + request.setHeader(QNetworkRequest::ContentTypeHeader, contentType); + } + + QVERIFY2(! boundaries.contains(multiPart->boundary()), "boundary '" + multiPart->boundary() + "' has been created twice"); + boundaries.insert(multiPart->boundary()); + + RUN_REQUEST(runMultipartRequest(request, reply, multiPart, "POST")); + multiPart->deleteLater(); + + QCOMPARE(reply->url(), url); + QCOMPARE(reply->error(), QNetworkReply::NoError); + + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); // 200 Ok + + QVERIFY(multiPart->boundary().count() > 20); // check that there is randomness after the "boundary_.oOo._" string + QVERIFY(multiPart->boundary().count() < 70); + QByteArray replyData = reply->readAll(); + + expectedReplyData.prepend("content type: multipart/" + contentType + "; boundary=\"" + multiPart->boundary() + "\"\n"); +// QEXPECT_FAIL("nested", "the server does not understand nested multipart messages", Continue); // see above + QCOMPARE(replyData, expectedReplyData); +} + +void tst_QNetworkReply::putToHttpMultipart_data() +{ + postToHttpMultipart_data(); +} + +void tst_QNetworkReply::putToHttpMultipart() +{ + QSKIP("test server script cannot handle PUT data yet", SkipAll); + QFETCH(QUrl, url); + + static QSet<QByteArray> boundaries; + + QNetworkRequest request(url); + QNetworkReplyPtr reply; + + QFETCH(QHttpMultiPart *, multiPart); + QFETCH(QByteArray, expectedReplyData); + QFETCH(QByteArray, contentType); + + // hack for testing the setting of the content-type header by hand: + if (contentType == "custom") { + QByteArray contentType("multipart/custom; boundary=\"" + multiPart->boundary() + "\""); + request.setHeader(QNetworkRequest::ContentTypeHeader, contentType); + } + + QVERIFY2(! boundaries.contains(multiPart->boundary()), "boundary '" + multiPart->boundary() + "' has been created twice"); + boundaries.insert(multiPart->boundary()); + + RUN_REQUEST(runMultipartRequest(request, reply, multiPart, "PUT")); + multiPart->deleteLater(); + + QCOMPARE(reply->url(), url); + QCOMPARE(reply->error(), QNetworkReply::NoError); + + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); // 200 Ok + + QVERIFY(multiPart->boundary().count() > 20); // check that there is randomness after the "boundary_.oOo._" string + QVERIFY(multiPart->boundary().count() < 70); + QByteArray replyData = reply->readAll(); + + expectedReplyData.prepend("content type: multipart/" + contentType + "; boundary=\"" + multiPart->boundary() + "\"\n"); +// QEXPECT_FAIL("nested", "the server does not understand nested multipart messages", Continue); // see above + QCOMPARE(replyData, expectedReplyData); +} + +void tst_QNetworkReply::deleteFromHttp_data() +{ + QTest::addColumn<QUrl>("url"); + QTest::addColumn<int>("resultCode"); + QTest::addColumn<QNetworkReply::NetworkError>("error"); + + // for status codes to expect, see http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html + + QTest::newRow("405-method-not-allowed") << QUrl("http://" + QtNetworkSettings::serverName() + "/index.html") << 405 << QNetworkReply::ContentOperationNotPermittedError; + QTest::newRow("200-ok") << QUrl("http://" + QtNetworkSettings::serverName() + "/qtest/cgi-bin/http-delete.cgi?200-ok") << 200 << QNetworkReply::NoError; + QTest::newRow("202-accepted") << QUrl("http://" + QtNetworkSettings::serverName() + "/qtest/cgi-bin/http-delete.cgi?202-accepted") << 202 << QNetworkReply::NoError; + QTest::newRow("204-no-content") << QUrl("http://" + QtNetworkSettings::serverName() + "/qtest/cgi-bin/http-delete.cgi?204-no-content") << 204 << QNetworkReply::NoError; + QTest::newRow("404-not-found") << QUrl("http://" + QtNetworkSettings::serverName() + "/qtest/cgi-bin/http-delete.cgi?404-not-found") << 404 << QNetworkReply::ContentNotFoundError; +} + +void tst_QNetworkReply::deleteFromHttp() +{ + QFETCH(QUrl, url); + QFETCH(int, resultCode); + QFETCH(QNetworkReply::NetworkError, error); + QNetworkRequest request(url); + QNetworkReplyPtr reply; + runSimpleRequest(QNetworkAccessManager::DeleteOperation, request, reply, 0); + QCOMPARE(reply->url(), url); + QCOMPARE(reply->error(), error); + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), resultCode); +} + +void tst_QNetworkReply::putGetDeleteGetFromHttp_data() +{ + QTest::addColumn<QUrl>("putUrl"); + QTest::addColumn<int>("putResultCode"); + QTest::addColumn<QNetworkReply::NetworkError>("putError"); + QTest::addColumn<QUrl>("deleteUrl"); + QTest::addColumn<int>("deleteResultCode"); + QTest::addColumn<QNetworkReply::NetworkError>("deleteError"); + QTest::addColumn<QUrl>("get2Url"); + QTest::addColumn<int>("get2ResultCode"); + QTest::addColumn<QNetworkReply::NetworkError>("get2Error"); + + QUrl url("http://" + QtNetworkSettings::serverName()); + url.setPath(QString("/dav/qnetworkaccess-putToHttp-%1-%2") + .arg(QTest::currentDataTag()) + .arg(uniqueExtension)); + + // first use case: put, get (to check it is there), delete, get (to check it is not there anymore) + QTest::newRow("success") << url << 201 << QNetworkReply::NoError << url << 204 << QNetworkReply::NoError << url << 404 << QNetworkReply::ContentNotFoundError; + + QUrl wrongUrl("http://" + QtNetworkSettings::serverName()); + wrongUrl.setPath(QString("/dav/qnetworkaccess-thisURLisNotAvailable")); + + // second use case: put, get (to check it is there), delete wrong URL, get (to check it is still there) + QTest::newRow("delete-error") << url << 201 << QNetworkReply::NoError << wrongUrl << 404 << QNetworkReply::ContentNotFoundError << url << 200 << QNetworkReply::NoError; + +} + +void tst_QNetworkReply::putGetDeleteGetFromHttp() +{ + QFETCH(QUrl, putUrl); + QFETCH(int, putResultCode); + QFETCH(QNetworkReply::NetworkError, putError); + QFETCH(QUrl, deleteUrl); + QFETCH(int, deleteResultCode); + QFETCH(QNetworkReply::NetworkError, deleteError); + QFETCH(QUrl, get2Url); + QFETCH(int, get2ResultCode); + QFETCH(QNetworkReply::NetworkError, get2Error); + + QNetworkRequest putRequest(putUrl); + QNetworkRequest deleteRequest(deleteUrl); + QNetworkRequest get2Request(get2Url); + QNetworkReplyPtr reply; + + RUN_REQUEST(runSimpleRequest(QNetworkAccessManager::PutOperation, putRequest, reply, 0)); + QCOMPARE(reply->error(), putError); + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), putResultCode); + + runSimpleRequest(QNetworkAccessManager::GetOperation, putRequest, reply, 0); + QCOMPARE(reply->error(), QNetworkReply::NoError); + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); + + runSimpleRequest(QNetworkAccessManager::DeleteOperation, deleteRequest, reply, 0); + QCOMPARE(reply->error(), deleteError); + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), deleteResultCode); + + runSimpleRequest(QNetworkAccessManager::GetOperation, get2Request, reply, 0); + QCOMPARE(reply->error(), get2Error); + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), get2ResultCode); + +} + +void tst_QNetworkReply::sendCustomRequestToHttp_data() +{ + QTest::addColumn<QUrl>("url"); + QTest::addColumn<QByteArray>("verb"); + QTest::addColumn<QBuffer *>("device"); + QTest::addColumn<int>("resultCode"); + QTest::addColumn<QNetworkReply::NetworkError>("error"); + QTest::addColumn<QByteArray>("expectedContent"); + + QTest::newRow("options") << QUrl("http://" + QtNetworkSettings::serverName()) << + QByteArray("OPTIONS") << (QBuffer *) 0 << 200 << QNetworkReply::NoError << QByteArray(); + QTest::newRow("trace") << QUrl("http://" + QtNetworkSettings::serverName()) << + QByteArray("TRACE") << (QBuffer *) 0 << 200 << QNetworkReply::NoError << QByteArray(); + QTest::newRow("connect") << QUrl("http://" + QtNetworkSettings::serverName()) << + QByteArray("CONNECT") << (QBuffer *) 0 << 400 << QNetworkReply::UnknownContentError << QByteArray(); // 400 = Bad Request + QTest::newRow("nonsense") << QUrl("http://" + QtNetworkSettings::serverName()) << + QByteArray("NONSENSE") << (QBuffer *) 0 << 501 << QNetworkReply::ProtocolUnknownError << QByteArray(); // 501 = Method Not Implemented + + QByteArray ba("test"); + QBuffer *buffer = new QBuffer; + buffer->setData(ba); + buffer->open(QIODevice::ReadOnly); + QTest::newRow("post") << QUrl("http://" + QtNetworkSettings::serverName() + "/qtest/cgi-bin/md5sum.cgi") << QByteArray("POST") + << buffer << 200 << QNetworkReply::NoError << QByteArray("098f6bcd4621d373cade4e832627b4f6\n"); + + QByteArray ba2("test"); + QBuffer *buffer2 = new QBuffer; + buffer2->setData(ba2); + buffer2->open(QIODevice::ReadOnly); + QTest::newRow("put") << QUrl("http://" + QtNetworkSettings::serverName() + "/qtest/cgi-bin/md5sum.cgi") << QByteArray("PUT") + << buffer2 << 200 << QNetworkReply::NoError << QByteArray("098f6bcd4621d373cade4e832627b4f6\n"); +} + +void tst_QNetworkReply::sendCustomRequestToHttp() +{ + QFETCH(QUrl, url); + QNetworkRequest request(url); + QNetworkReplyPtr reply; + QFETCH(QByteArray, verb); + QFETCH(QBuffer *, device); + runCustomRequest(request, reply, verb, device); + QCOMPARE(reply->url(), url); + QFETCH(QNetworkReply::NetworkError, error); + QCOMPARE(reply->error(), error); + QFETCH(int, resultCode); + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), resultCode); + QFETCH(QByteArray, expectedContent); + if (! expectedContent.isEmpty()) + QCOMPARE(reply->readAll(), expectedContent); +} + +void tst_QNetworkReply::ioGetFromData_data() +{ + QTest::addColumn<QString>("urlStr"); + QTest::addColumn<QByteArray>("data"); + + QTest::newRow("data-empty") << "data:," << QByteArray(); + QTest::newRow("data-literal") << "data:,foo" << QByteArray("foo"); + QTest::newRow("data-pct") << "data:,%3Cbody%20contentEditable%3Dtrue%3E%0D%0A" + << QByteArray("<body contentEditable=true>\r\n"); + QTest::newRow("data-base64") << "data:;base64,UXQgaXMgZ3JlYXQh" << QByteArray("Qt is great!"); +} + +void tst_QNetworkReply::ioGetFromData() +{ + QFETCH(QString, urlStr); + + QUrl url = QUrl::fromEncoded(urlStr.toLatin1()); + QNetworkRequest request(url); + + QNetworkReplyPtr reply = manager.get(request); + DataReader reader(reply); + + connect(reply, SIGNAL(finished()), + &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QCOMPARE(reply->url(), request.url()); + QCOMPARE(reply->error(), QNetworkReply::NoError); + + QFETCH(QByteArray, data); + QCOMPARE(reply->header(QNetworkRequest::ContentLengthHeader).toInt(), data.size()); + QCOMPARE(reader.data.size(), data.size()); + QCOMPARE(reader.data, data); +} + +void tst_QNetworkReply::ioGetFromFileSpecial_data() +{ + getFromFileSpecial_data(); +} + +void tst_QNetworkReply::ioGetFromFileSpecial() +{ + QFETCH(QString, fileName); + QFETCH(QString, url); + + QFile resource(fileName); + QVERIFY(resource.open(QIODevice::ReadOnly)); + + QNetworkRequest request; + request.setUrl(url); + QNetworkReplyPtr reply = manager.get(request); + DataReader reader(reply); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QCOMPARE(reply->url(), request.url()); + QCOMPARE(reply->error(), QNetworkReply::NoError); + + QCOMPARE(reply->header(QNetworkRequest::ContentLengthHeader).toLongLong(), resource.size()); + QCOMPARE(qint64(reader.data.size()), resource.size()); + QCOMPARE(reader.data, resource.readAll()); +} + +void tst_QNetworkReply::ioGetFromFile_data() +{ + putToFile_data(); +} + +void tst_QNetworkReply::ioGetFromFile() +{ + QTemporaryFile file(QDir::currentPath() + "/temp-XXXXXX"); + file.setAutoRemove(true); + QVERIFY(file.open()); + + QFETCH(QByteArray, data); + QVERIFY(file.write(data) == data.size()); + file.flush(); + QCOMPARE(file.size(), qint64(data.size())); + + QNetworkRequest request(QUrl::fromLocalFile(file.fileName())); + QNetworkReplyPtr reply = manager.get(request); + QVERIFY(reply->isFinished()); // a file should immediatly be done + DataReader reader(reply); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QCOMPARE(reply->url(), request.url()); + QCOMPARE(reply->error(), QNetworkReply::NoError); + + QCOMPARE(reply->header(QNetworkRequest::ContentLengthHeader).toLongLong(), file.size()); + QCOMPARE(qint64(reader.data.size()), file.size()); + QCOMPARE(reader.data, data); +} + +void tst_QNetworkReply::ioGetFromFtp_data() +{ + QTest::addColumn<QString>("fileName"); + QTest::addColumn<qint64>("expectedSize"); + + QTest::newRow("bigfile") << "bigfile" << Q_INT64_C(519240); + + QFile file(SRCDIR "/rfc3252.txt"); + QTest::newRow("rfc3252.txt") << "rfc3252.txt" << file.size(); +} + +void tst_QNetworkReply::ioGetFromFtp() +{ + QFETCH(QString, fileName); + QFile reference(fileName); + reference.open(QIODevice::ReadOnly); // will fail for bigfile + + QNetworkRequest request("ftp://" + QtNetworkSettings::serverName() + "/qtest/" + fileName); + QNetworkReplyPtr reply = manager.get(request); + DataReader reader(reply); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QCOMPARE(reply->url(), request.url()); + QCOMPARE(reply->error(), QNetworkReply::NoError); + + QFETCH(qint64, expectedSize); + QCOMPARE(reply->header(QNetworkRequest::ContentLengthHeader).toLongLong(), expectedSize); + QCOMPARE(qint64(reader.data.size()), expectedSize); + + if (reference.isOpen()) + QCOMPARE(reader.data, reference.readAll()); +} + +void tst_QNetworkReply::ioGetFromFtpWithReuse() +{ + QString fileName = SRCDIR "/rfc3252.txt"; + QFile reference(fileName); + reference.open(QIODevice::ReadOnly); + + QNetworkRequest request(QUrl("ftp://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt")); + + // two concurrent (actually, consecutive) gets: + QNetworkReplyPtr reply1 = manager.get(request); + DataReader reader1(reply1); + QNetworkReplyPtr reply2 = manager.get(request); + DataReader reader2(reply2); + QSignalSpy spy(reply1, SIGNAL(finished())); + + connect(reply2, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + if (spy.count() == 0) { + connect(reply1, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + } + + QCOMPARE(reply1->url(), request.url()); + QCOMPARE(reply2->url(), request.url()); + QCOMPARE(reply1->error(), QNetworkReply::NoError); + QCOMPARE(reply2->error(), QNetworkReply::NoError); + + QCOMPARE(qint64(reader1.data.size()), reference.size()); + QCOMPARE(qint64(reader2.data.size()), reference.size()); + QCOMPARE(reply1->header(QNetworkRequest::ContentLengthHeader).toLongLong(), reference.size()); + QCOMPARE(reply2->header(QNetworkRequest::ContentLengthHeader).toLongLong(), reference.size()); + + QByteArray referenceData = reference.readAll(); + QCOMPARE(reader1.data, referenceData); + QCOMPARE(reader2.data, referenceData); +} + +void tst_QNetworkReply::ioGetFromHttp() +{ + QFile reference(SRCDIR "/rfc3252.txt"); + QVERIFY(reference.open(QIODevice::ReadOnly)); + + QNetworkRequest request(QUrl("http://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt")); + QNetworkReplyPtr reply = manager.get(request); + DataReader reader(reply); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QCOMPARE(reply->url(), request.url()); + QCOMPARE(reply->error(), QNetworkReply::NoError); + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); + + QCOMPARE(reply->header(QNetworkRequest::ContentLengthHeader).toLongLong(), reference.size()); + QCOMPARE(qint64(reader.data.size()), reference.size()); + + QCOMPARE(reader.data, reference.readAll()); +} + +void tst_QNetworkReply::ioGetFromHttpWithReuseParallel() +{ + QFile reference(SRCDIR "/rfc3252.txt"); + QVERIFY(reference.open(QIODevice::ReadOnly)); + + QNetworkRequest request(QUrl("http://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt")); + QNetworkReplyPtr reply1 = manager.get(request); + QNetworkReplyPtr reply2 = manager.get(request); + DataReader reader1(reply1); + DataReader reader2(reply2); + QSignalSpy spy(reply1, SIGNAL(finished())); + + connect(reply2, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + if (spy.count() == 0) { + connect(reply1, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + } + + QCOMPARE(reply1->url(), request.url()); + QCOMPARE(reply2->url(), request.url()); + QCOMPARE(reply1->error(), QNetworkReply::NoError); + QCOMPARE(reply2->error(), QNetworkReply::NoError); + QCOMPARE(reply1->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); + QCOMPARE(reply2->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); + + QCOMPARE(reply1->header(QNetworkRequest::ContentLengthHeader).toLongLong(), reference.size()); + QCOMPARE(reply2->header(QNetworkRequest::ContentLengthHeader).toLongLong(), reference.size()); + QCOMPARE(qint64(reader1.data.size()), reference.size()); + QCOMPARE(qint64(reader2.data.size()), reference.size()); + + QByteArray referenceData = reference.readAll(); + QCOMPARE(reader1.data, referenceData); + QCOMPARE(reader2.data, referenceData); +} + +void tst_QNetworkReply::ioGetFromHttpWithReuseSequential() +{ + QFile reference(SRCDIR "/rfc3252.txt"); + QVERIFY(reference.open(QIODevice::ReadOnly)); + + QNetworkRequest request(QUrl("http://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt")); + { + QNetworkReplyPtr reply = manager.get(request); + DataReader reader(reply); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QCOMPARE(reply->url(), request.url()); + QCOMPARE(reply->error(), QNetworkReply::NoError); + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); + + QCOMPARE(reply->header(QNetworkRequest::ContentLengthHeader).toLongLong(), reference.size()); + QCOMPARE(qint64(reader.data.size()), reference.size()); + + QCOMPARE(reader.data, reference.readAll()); + } + + reference.seek(0); + // rinse and repeat: + { + QNetworkReplyPtr reply = manager.get(request); + DataReader reader(reply); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QCOMPARE(reply->url(), request.url()); + QCOMPARE(reply->error(), QNetworkReply::NoError); + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); + + QCOMPARE(reply->header(QNetworkRequest::ContentLengthHeader).toLongLong(), reference.size()); + QCOMPARE(qint64(reader.data.size()), reference.size()); + + QCOMPARE(reader.data, reference.readAll()); + } +} + +void tst_QNetworkReply::ioGetFromHttpWithAuth_data() +{ + QTest::addColumn<QUrl>("url"); + QTest::addColumn<QByteArray>("expectedData"); + + QFile reference(SRCDIR "/rfc3252.txt"); + reference.open(QIODevice::ReadOnly); + QByteArray referenceData = reference.readAll(); + QTest::newRow("basic") << QUrl("http://" + QtNetworkSettings::serverName() + "/qtest/rfcs-auth/rfc3252.txt") << referenceData; + QTest::newRow("digest") << QUrl("http://" + QtNetworkSettings::serverName() + "/qtest/auth-digest/") << QByteArray("digest authentication successful\n"); +} + +void tst_QNetworkReply::ioGetFromHttpWithAuth() +{ + // This test sends three requests + // The first two in parallel + // The third after the first two finished + + QFETCH(QUrl, url); + QFETCH(QByteArray, expectedData); + QNetworkRequest request(url); + { + QNetworkReplyPtr reply1 = manager.get(request); + QNetworkReplyPtr reply2 = manager.get(request); + DataReader reader1(reply1); + DataReader reader2(reply2); + QSignalSpy finishedspy(reply1, SIGNAL(finished())); + + QSignalSpy authspy(&manager, SIGNAL(authenticationRequired(QNetworkReply*,QAuthenticator*))); + connect(&manager, SIGNAL(authenticationRequired(QNetworkReply*,QAuthenticator*)), + SLOT(authenticationRequired(QNetworkReply*,QAuthenticator*))); + + connect(reply2, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + if (finishedspy.count() == 0) { + connect(reply1, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + } + manager.disconnect(SIGNAL(authenticationRequired(QNetworkReply*,QAuthenticator*)), + this, SLOT(authenticationRequired(QNetworkReply*,QAuthenticator*))); + + QCOMPARE(reply1->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); + QCOMPARE(reply2->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); + QCOMPARE(reader1.data, expectedData); + QCOMPARE(reader2.data, expectedData); + + QCOMPARE(authspy.count(), 1); + } + + // rinse and repeat: + { + QNetworkReplyPtr reply = manager.get(request); + DataReader reader(reply); + + QSignalSpy authspy(&manager, SIGNAL(authenticationRequired(QNetworkReply*,QAuthenticator*))); + connect(&manager, SIGNAL(authenticationRequired(QNetworkReply*,QAuthenticator*)), + SLOT(authenticationRequired(QNetworkReply*,QAuthenticator*))); + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + manager.disconnect(SIGNAL(authenticationRequired(QNetworkReply*,QAuthenticator*)), + this, SLOT(authenticationRequired(QNetworkReply*,QAuthenticator*))); + + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); + QCOMPARE(reader.data, expectedData); + + QCOMPARE(authspy.count(), 0); + } + + // now check with synchronous calls: + { + request.setAttribute( + QNetworkRequest::SynchronousRequestAttribute, + true); + + QSignalSpy authspy(&manager, SIGNAL(authenticationRequired(QNetworkReply*,QAuthenticator*))); + QNetworkReplyPtr replySync = manager.get(request); + QVERIFY(replySync->isFinished()); // synchronous + QCOMPARE(authspy.count(), 0); + + // we cannot use a data reader here, since that connects to the readyRead signal, + // just use readAll() + + // the only thing we check here is that the auth cache was used when using synchronous requests + QCOMPARE(replySync->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); + QCOMPARE(replySync->readAll(), expectedData); + } +} + +void tst_QNetworkReply::ioGetFromHttpWithAuthSynchronous() +{ + // verify that we do not enter an endless loop with synchronous calls and wrong credentials + // the case when we succed with the login is tested in ioGetFromHttpWithAuth() + + QNetworkRequest request(QUrl("http://" + QtNetworkSettings::serverName() + "/qtest/rfcs-auth/rfc3252.txt")); + request.setAttribute( + QNetworkRequest::SynchronousRequestAttribute, + true); + + QSignalSpy authspy(&manager, SIGNAL(authenticationRequired(QNetworkReply*,QAuthenticator*))); + QNetworkReplyPtr replySync = manager.get(request); + QVERIFY(replySync->isFinished()); // synchronous + QCOMPARE(replySync->error(), QNetworkReply::AuthenticationRequiredError); + QCOMPARE(authspy.count(), 0); + QCOMPARE(replySync->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 401); +} + +void tst_QNetworkReply::ioGetFromHttpWithProxyAuth() +{ + qRegisterMetaType<QNetworkProxy>(); // for QSignalSpy + qRegisterMetaType<QAuthenticator *>(); + + // This test sends three requests + // The first two in parallel + // The third after the first two finished + QFile reference(SRCDIR "/rfc3252.txt"); + QVERIFY(reference.open(QIODevice::ReadOnly)); + + QNetworkProxy proxy(QNetworkProxy::HttpCachingProxy, QtNetworkSettings::serverName(), 3129); + QNetworkRequest request(QUrl("http://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt")); + { + manager.setProxy(proxy); + QNetworkReplyPtr reply1 = manager.get(request); + QNetworkReplyPtr reply2 = manager.get(request); + manager.setProxy(QNetworkProxy()); + + DataReader reader1(reply1); + DataReader reader2(reply2); + QSignalSpy finishedspy(reply1, SIGNAL(finished())); + + QSignalSpy authspy(&manager, SIGNAL(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*))); + connect(&manager, SIGNAL(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*)), + SLOT(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*))); + + connect(reply2, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + if (finishedspy.count() == 0) { + connect(reply1, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + } + manager.disconnect(SIGNAL(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*)), + this, SLOT(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*))); + + QCOMPARE(reply1->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); + QCOMPARE(reply2->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); + QByteArray referenceData = reference.readAll(); + QCOMPARE(reader1.data, referenceData); + QCOMPARE(reader2.data, referenceData); + + QCOMPARE(authspy.count(), 1); + } + + reference.seek(0); + // rinse and repeat: + { + manager.setProxy(proxy); + QNetworkReplyPtr reply = manager.get(request); + DataReader reader(reply); + manager.setProxy(QNetworkProxy()); + + QSignalSpy authspy(&manager, SIGNAL(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*))); + connect(&manager, SIGNAL(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*)), + SLOT(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*))); + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + manager.disconnect(SIGNAL(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*)), + this, SLOT(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*))); + + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); + QCOMPARE(reader.data, reference.readAll()); + + QCOMPARE(authspy.count(), 0); + } + + // now check with synchronous calls: + reference.seek(0); + { + request.setAttribute( + QNetworkRequest::SynchronousRequestAttribute, + true); + + QSignalSpy authspy(&manager, SIGNAL(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*))); + QNetworkReplyPtr replySync = manager.get(request); + QVERIFY(replySync->isFinished()); // synchronous + QCOMPARE(authspy.count(), 0); + + // we cannot use a data reader here, since that connects to the readyRead signal, + // just use readAll() + + // the only thing we check here is that the proxy auth cache was used when using synchronous requests + QCOMPARE(replySync->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); + QCOMPARE(replySync->readAll(), reference.readAll()); + } +} + +void tst_QNetworkReply::ioGetFromHttpWithProxyAuthSynchronous() +{ + // verify that we do not enter an endless loop with synchronous calls and wrong credentials + // the case when we succed with the login is tested in ioGetFromHttpWithAuth() + + QNetworkProxy proxy(QNetworkProxy::HttpCachingProxy, QtNetworkSettings::serverName(), 3129); + QNetworkRequest request(QUrl("http://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt")); + manager.setProxy(proxy); + request.setAttribute( + QNetworkRequest::SynchronousRequestAttribute, + true); + + QSignalSpy authspy(&manager, SIGNAL(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*))); + QNetworkReplyPtr replySync = manager.get(request); + manager.setProxy(QNetworkProxy()); // reset + QVERIFY(replySync->isFinished()); // synchronous + QCOMPARE(replySync->error(), QNetworkReply::ProxyAuthenticationRequiredError); + QCOMPARE(authspy.count(), 0); + QCOMPARE(replySync->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 407); +} + +void tst_QNetworkReply::ioGetFromHttpWithSocksProxy() +{ + // HTTP caching proxies are tested by the above function + // test SOCKSv5 proxies too + + qRegisterMetaType<QNetworkProxy>(); // for QSignalSpy + qRegisterMetaType<QAuthenticator *>(); + + QFile reference(SRCDIR "/rfc3252.txt"); + QVERIFY(reference.open(QIODevice::ReadOnly)); + + QNetworkProxy proxy(QNetworkProxy::Socks5Proxy, QtNetworkSettings::serverName(), 1080); + QNetworkRequest request(QUrl("http://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt")); + { + manager.setProxy(proxy); + QNetworkReplyPtr reply = manager.get(request); + DataReader reader(reply); + manager.setProxy(QNetworkProxy()); + + QSignalSpy authspy(&manager, SIGNAL(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*))); + connect(&manager, SIGNAL(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*)), + SLOT(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*))); + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + manager.disconnect(SIGNAL(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*)), + this, SLOT(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*))); + + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); + QCOMPARE(reader.data, reference.readAll()); + + QCOMPARE(authspy.count(), 0); + } + + // set an invalid proxy just to make sure that we can't load + proxy = QNetworkProxy(QNetworkProxy::Socks5Proxy, QtNetworkSettings::serverName(), 1079); + { + manager.setProxy(proxy); + QNetworkReplyPtr reply = manager.get(request); + DataReader reader(reply); + manager.setProxy(QNetworkProxy()); + + QSignalSpy authspy(&manager, SIGNAL(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*))); + connect(&manager, SIGNAL(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*)), + SLOT(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*))); + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + manager.disconnect(SIGNAL(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*)), + this, SLOT(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*))); + + QVERIFY(!reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).isValid()); + QVERIFY(reader.data.isEmpty()); + + QVERIFY(int(reply->error()) > 0); + QEXPECT_FAIL("", "QTcpSocket doesn't return enough information yet", Continue); + QCOMPARE(int(reply->error()), int(QNetworkReply::ProxyConnectionRefusedError)); + + QCOMPARE(authspy.count(), 0); + } +} + +#ifndef QT_NO_OPENSSL +void tst_QNetworkReply::ioGetFromHttpsWithSslErrors() +{ + qRegisterMetaType<QNetworkReply*>(); // for QSignalSpy + qRegisterMetaType<QList<QSslError> >(); + + QFile reference(SRCDIR "/rfc3252.txt"); + QVERIFY(reference.open(QIODevice::ReadOnly)); + + QNetworkRequest request(QUrl("https://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt")); + QNetworkReplyPtr reply = manager.get(request); + DataReader reader(reply); + + QSignalSpy sslspy(&manager, SIGNAL(sslErrors(QNetworkReply*,QList<QSslError>))); + connect(&manager, SIGNAL(sslErrors(QNetworkReply*,QList<QSslError>)), + SLOT(sslErrors(QNetworkReply*,QList<QSslError>))); + connect(reply, SIGNAL(metaDataChanged()), SLOT(storeSslConfiguration())); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + manager.disconnect(SIGNAL(sslErrors(QNetworkReply*,QList<QSslError>)), + this, SLOT(sslErrors(QNetworkReply*,QList<QSslError>))); + + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); + QCOMPARE(reader.data, reference.readAll()); + + QCOMPARE(sslspy.count(), 1); + + QVERIFY(!storedSslConfiguration.isNull()); + QVERIFY(!reply->sslConfiguration().isNull()); +} + +void tst_QNetworkReply::ioGetFromHttpsWithIgnoreSslErrors() +{ + // same as above, except that we call ignoreSslErrors and don't connect + // to the sslErrors() signal (which is *still* emitted) + + qRegisterMetaType<QNetworkReply*>(); // for QSignalSpy + qRegisterMetaType<QList<QSslError> >(); + + QFile reference(SRCDIR "/rfc3252.txt"); + QVERIFY(reference.open(QIODevice::ReadOnly)); + + QNetworkRequest request(QUrl("https://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt")); + + QNetworkReplyPtr reply = manager.get(request); + reply->ignoreSslErrors(); + DataReader reader(reply); + + QSignalSpy sslspy(&manager, SIGNAL(sslErrors(QNetworkReply*,QList<QSslError>))); + connect(reply, SIGNAL(metaDataChanged()), SLOT(storeSslConfiguration())); + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); + QCOMPARE(reader.data, reference.readAll()); + + QCOMPARE(sslspy.count(), 1); + + QVERIFY(!storedSslConfiguration.isNull()); + QVERIFY(!reply->sslConfiguration().isNull()); +} + +void tst_QNetworkReply::ioGetFromHttpsWithSslHandshakeError() +{ + qRegisterMetaType<QNetworkReply*>(); // for QSignalSpy + qRegisterMetaType<QList<QSslError> >(); + + QFile reference(SRCDIR "/rfc3252.txt"); + QVERIFY(reference.open(QIODevice::ReadOnly)); + + QNetworkRequest request(QUrl("https://" + QtNetworkSettings::serverName() + ":80")); + + QNetworkReplyPtr reply = manager.get(request); + reply->ignoreSslErrors(); + DataReader reader(reply); + + QSignalSpy sslspy(&manager, SIGNAL(sslErrors(QNetworkReply*,QList<QSslError>))); + connect(reply, SIGNAL(metaDataChanged()), SLOT(storeSslConfiguration())); + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QCOMPARE(reply->error(), QNetworkReply::SslHandshakeFailedError); + QCOMPARE(sslspy.count(), 0); +} +#endif + +void tst_QNetworkReply::ioGetFromHttpBrokenServer_data() +{ + QTest::addColumn<QByteArray>("dataToSend"); + QTest::addColumn<bool>("doDisconnect"); + + QTest::newRow("no-newline") << QByteArray("Hello World") << false; + + // these are OK now, we just eat the lonely newlines + //QTest::newRow("just-newline") << QByteArray("\r\n") << false; + //QTest::newRow("just-2newline") << QByteArray("\r\n\r\n") << false; + + QTest::newRow("with-newlines") << QByteArray("Long first line\r\nLong second line") << false; + QTest::newRow("with-newlines2") << QByteArray("\r\nSecond line") << false; + QTest::newRow("with-newlines3") << QByteArray("ICY\r\nSecond line") << false; + QTest::newRow("invalid-version") << QByteArray("HTTP/123 200 \r\n") << false; + QTest::newRow("invalid-version2") << QByteArray("HTTP/a.\033 200 \r\n") << false; + QTest::newRow("invalid-reply-code") << QByteArray("HTTP/1.0 fuu \r\n") << false; + + QTest::newRow("empty+disconnect") << QByteArray() << true; + + QTest::newRow("no-newline+disconnect") << QByteArray("Hello World") << true; + QTest::newRow("just-newline+disconnect") << QByteArray("\r\n") << true; + QTest::newRow("just-2newline+disconnect") << QByteArray("\r\n\r\n") << true; + QTest::newRow("with-newlines+disconnect") << QByteArray("Long first line\r\nLong second line") << true; + QTest::newRow("with-newlines2+disconnect") << QByteArray("\r\nSecond line") << true; + QTest::newRow("with-newlines3+disconnect") << QByteArray("ICY\r\nSecond line") << true; + + QTest::newRow("invalid-version+disconnect") << QByteArray("HTTP/123 200 ") << true; + QTest::newRow("invalid-version2+disconnect") << QByteArray("HTTP/a.\033 200 ") << true; + QTest::newRow("invalid-reply-code+disconnect") << QByteArray("HTTP/1.0 fuu ") << true; + + QTest::newRow("immediate disconnect") << QByteArray("") << true; + QTest::newRow("justHalfStatus+disconnect") << QByteArray("HTTP/1.1") << true; + QTest::newRow("justStatus+disconnect") << QByteArray("HTTP/1.1 200 OK\r\n") << true; + QTest::newRow("justStatusAndHalfHeaders+disconnect") << QByteArray("HTTP/1.1 200 OK\r\nContent-L") << true; + + QTest::newRow("halfContent+disconnect") << QByteArray("HTTP/1.1 200 OK\r\nContent-Length: 4\r\n\r\nAB") << true; + +} + +void tst_QNetworkReply::ioGetFromHttpBrokenServer() +{ + QFETCH(QByteArray, dataToSend); + QFETCH(bool, doDisconnect); + MiniHttpServer server(dataToSend); + server.doClose = doDisconnect; + + QNetworkRequest request(QUrl("http://localhost:" + QString::number(server.serverPort()))); + QNetworkReplyPtr reply = manager.get(request); + QSignalSpy spy(reply, SIGNAL(error(QNetworkReply::NetworkError))); + + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QCOMPARE(reply->url(), request.url()); + QCOMPARE(spy.count(), 1); + QVERIFY(reply->error() != QNetworkReply::NoError); +} + +void tst_QNetworkReply::ioGetFromHttpStatus100_data() +{ + QTest::addColumn<QByteArray>("dataToSend"); + QTest::addColumn<int>("statusCode"); + QTest::newRow("normal") << QByteArray("HTTP/1.1 100 Continue\r\n\r\nHTTP/1.1 200 OK\r\nContent-Length: 0\r\n\r\n") << 200; + QTest::newRow("minimal") << QByteArray("HTTP/1.1 100 Continue\n\nHTTP/1.1 200 OK\r\nContent-Length: 0\r\n\r\n") << 200; + QTest::newRow("minimal2") << QByteArray("HTTP/1.1 100 Continue\n\nHTTP/1.0 200 OK\r\n\r\n") << 200; + QTest::newRow("minimal3") << QByteArray("HTTP/1.1 100 Continue\n\nHTTP/1.0 200 OK\n\n") << 200; + QTest::newRow("minimal+404") << QByteArray("HTTP/1.1 100 Continue\n\nHTTP/1.0 204 No Content\r\n\r\n") << 204; + QTest::newRow("with_headers") << QByteArray("HTTP/1.1 100 Continue\r\nBla: x\r\n\r\nHTTP/1.1 200 OK\r\nContent-Length: 0\r\n\r\n") << 200; + QTest::newRow("with_headers2") << QByteArray("HTTP/1.1 100 Continue\nBla: x\n\nHTTP/1.1 200 OK\r\nContent-Length: 0\r\n\r\n") << 200; +} + +void tst_QNetworkReply::ioGetFromHttpStatus100() +{ + QFETCH(QByteArray, dataToSend); + QFETCH(int, statusCode); + MiniHttpServer server(dataToSend); + server.doClose = true; + + QNetworkRequest request(QUrl("http://localhost:" + QString::number(server.serverPort()))); + QNetworkReplyPtr reply = manager.get(request); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QCOMPARE(reply->url(), request.url()); + QCOMPARE(reply->error(), QNetworkReply::NoError); + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), statusCode); + QVERIFY(reply->rawHeader("bla").isNull()); +} + +void tst_QNetworkReply::ioGetFromHttpNoHeaders_data() +{ + QTest::addColumn<QByteArray>("dataToSend"); + QTest::newRow("justStatus+noheaders+disconnect") << QByteArray("HTTP/1.0 200 OK\r\n\r\n"); +} + +void tst_QNetworkReply::ioGetFromHttpNoHeaders() +{ + QFETCH(QByteArray, dataToSend); + MiniHttpServer server(dataToSend); + server.doClose = true; + + QNetworkRequest request(QUrl("http://localhost:" + QString::number(server.serverPort()))); + QNetworkReplyPtr reply = manager.get(request); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QCOMPARE(reply->url(), request.url()); + QCOMPARE(reply->error(), QNetworkReply::NoError); + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); +} + +void tst_QNetworkReply::ioGetFromHttpWithCache_data() +{ + qRegisterMetaType<MyMemoryCache::CachedContent>(); + QTest::addColumn<QByteArray>("dataToSend"); + QTest::addColumn<QString>("body"); + QTest::addColumn<MyMemoryCache::CachedContent>("cachedReply"); + QTest::addColumn<int>("cacheMode"); + QTest::addColumn<QStringList>("extraHttpHeaders"); + QTest::addColumn<bool>("loadedFromCache"); + QTest::addColumn<bool>("networkUsed"); + + QByteArray reply200 = + "HTTP/1.0 200\r\n" + "Connection: keep-alive\r\n" + "Content-Type: text/plain\r\n" + "Cache-control: no-cache\r\n" + "Content-length: 8\r\n" + "\r\n" + "Reloaded"; + QByteArray reply304 = + "HTTP/1.0 304 Use Cache\r\n" + "Connection: keep-alive\r\n" + "\r\n"; + + QTest::newRow("not-cached,always-network") + << reply200 << "Reloaded" << MyMemoryCache::CachedContent() << int(QNetworkRequest::AlwaysNetwork) << QStringList() << false << true; + QTest::newRow("not-cached,prefer-network") + << reply200 << "Reloaded" << MyMemoryCache::CachedContent() << int(QNetworkRequest::PreferNetwork) << QStringList() << false << true; + QTest::newRow("not-cached,prefer-cache") + << reply200 << "Reloaded" << MyMemoryCache::CachedContent() << int(QNetworkRequest::PreferCache) << QStringList() << false << true; + + QDateTime present = QDateTime::currentDateTime().toUTC(); + QDateTime past = present.addSecs(-3600); + QDateTime future = present.addSecs(3600); + static const char dateFormat[] = "ddd, dd MMM yyyy hh:mm:ss 'GMT'"; + + QNetworkCacheMetaData::RawHeaderList rawHeaders; + MyMemoryCache::CachedContent content; + content.second = "Not-reloaded"; + content.first.setLastModified(past); + + // + // Set to expired + // + rawHeaders.clear(); + rawHeaders << QNetworkCacheMetaData::RawHeader("Date", QLocale::c().toString(past, dateFormat).toLatin1()) + << QNetworkCacheMetaData::RawHeader("Cache-control", "max-age=0"); // isn't used in cache loading + content.first.setRawHeaders(rawHeaders); + content.first.setLastModified(past); + + QTest::newRow("expired,200,prefer-network") + << reply200 << "Reloaded" << content << int(QNetworkRequest::PreferNetwork) << QStringList() << false << true; + QTest::newRow("expired,200,prefer-cache") + << reply200 << "Reloaded" << content << int(QNetworkRequest::PreferCache) << QStringList() << false << true; + + QTest::newRow("expired,304,prefer-network") + << reply304 << "Not-reloaded" << content << int(QNetworkRequest::PreferNetwork) << QStringList() << true << true; + QTest::newRow("expired,304,prefer-cache") + << reply304 << "Not-reloaded" << content << int(QNetworkRequest::PreferCache) << QStringList() << true << true; + + // + // Set to not-expired + // + rawHeaders.clear(); + rawHeaders << QNetworkCacheMetaData::RawHeader("Date", QLocale::c().toString(past, dateFormat).toLatin1()) + << QNetworkCacheMetaData::RawHeader("Cache-control", "max-age=7200"); // isn't used in cache loading + content.first.setRawHeaders(rawHeaders); + content.first.setExpirationDate(future); + + QTest::newRow("not-expired,200,always-network") + << reply200 << "Reloaded" << content << int(QNetworkRequest::AlwaysNetwork) << QStringList() << false << true; + QTest::newRow("not-expired,200,prefer-network") + << reply200 << "Not-reloaded" << content << int(QNetworkRequest::PreferNetwork) << QStringList() << true << false; + QTest::newRow("not-expired,200,prefer-cache") + << reply200 << "Not-reloaded" << content << int(QNetworkRequest::PreferCache) << QStringList() << true << false; + QTest::newRow("not-expired,200,always-cache") + << reply200 << "Not-reloaded" << content << int(QNetworkRequest::AlwaysCache) << QStringList() << true << false; + + QTest::newRow("not-expired,304,prefer-network") + << reply304 << "Not-reloaded" << content << int(QNetworkRequest::PreferNetwork) << QStringList() << true << false; + QTest::newRow("not-expired,304,prefer-cache") + << reply304 << "Not-reloaded" << content << int(QNetworkRequest::PreferCache) << QStringList() << true << false; + QTest::newRow("not-expired,304,always-cache") + << reply304 << "Not-reloaded" << content << int(QNetworkRequest::AlwaysCache) << QStringList() << true << false; + + // + // Set must-revalidate now + // + rawHeaders.clear(); + rawHeaders << QNetworkCacheMetaData::RawHeader("Date", QLocale::c().toString(past, dateFormat).toLatin1()) + << QNetworkCacheMetaData::RawHeader("Cache-control", "max-age=7200, must-revalidate"); // must-revalidate is used + content.first.setRawHeaders(rawHeaders); + + QTest::newRow("must-revalidate,200,always-network") + << reply200 << "Reloaded" << content << int(QNetworkRequest::AlwaysNetwork) << QStringList() << false << true; + QTest::newRow("must-revalidate,200,prefer-network") + << reply200 << "Reloaded" << content << int(QNetworkRequest::PreferNetwork) << QStringList() << false << true; + QTest::newRow("must-revalidate,200,prefer-cache") + << reply200 << "Not-reloaded" << content << int(QNetworkRequest::PreferCache) << QStringList() << true << false; + QTest::newRow("must-revalidate,200,always-cache") + << reply200 << "Not-reloaded" << content << int(QNetworkRequest::AlwaysCache) << QStringList() << true << false; + + QTest::newRow("must-revalidate,304,prefer-network") + << reply304 << "Not-reloaded" << content << int(QNetworkRequest::PreferNetwork) << QStringList() << true << true; + QTest::newRow("must-revalidate,304,prefer-cache") + << reply304 << "Not-reloaded" << content << int(QNetworkRequest::PreferCache) << QStringList() << true << false; + QTest::newRow("must-revalidate,304,always-cache") + << reply304 << "Not-reloaded" << content << int(QNetworkRequest::AlwaysCache) << QStringList() << true << false; + + // + // Partial content + // + rawHeaders.clear(); + rawHeaders << QNetworkCacheMetaData::RawHeader("Date", QLocale::c().toString(past, dateFormat).toLatin1()) + << QNetworkCacheMetaData::RawHeader("Cache-control", "max-age=7200"); // isn't used in cache loading + content.first.setRawHeaders(rawHeaders); + content.first.setExpirationDate(future); + + QByteArray reply206 = + "HTTP/1.0 206\r\n" + "Connection: keep-alive\r\n" + "Content-Type: text/plain\r\n" + "Cache-control: no-cache\r\n" + "Content-Range: bytes 2-6/8\r\n" + "Content-length: 4\r\n" + "\r\n" + "load"; + + QTest::newRow("partial,dontuse-cache") + << reply206 << "load" << content << int(QNetworkRequest::PreferCache) << (QStringList() << "Range" << "bytes=2-6") << false << true; +} + +void tst_QNetworkReply::ioGetFromHttpWithCache() +{ + QFETCH(QByteArray, dataToSend); + MiniHttpServer server(dataToSend); + server.doClose = false; + + MyMemoryCache *memoryCache = new MyMemoryCache(&manager); + manager.setCache(memoryCache); + + QFETCH(MyMemoryCache::CachedContent, cachedReply); + QUrl url = "http://localhost:" + QString::number(server.serverPort()); + cachedReply.first.setUrl(url); + if (!cachedReply.second.isNull()) + memoryCache->cache.insert(url.toEncoded(), cachedReply); + + QFETCH(int, cacheMode); + QNetworkRequest request(url); + request.setAttribute(QNetworkRequest::CacheLoadControlAttribute, cacheMode); + request.setAttribute(QNetworkRequest::CacheSaveControlAttribute, false); + + QFETCH(QStringList, extraHttpHeaders); + QStringListIterator it(extraHttpHeaders); + while (it.hasNext()) { + QString header = it.next(); + QString value = it.next(); + request.setRawHeader(header.toLatin1(), value.toLatin1()); // To latin1? Deal with it! + } + + QNetworkReplyPtr reply = manager.get(request); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QTEST(reply->attribute(QNetworkRequest::SourceIsFromCacheAttribute).toBool(), "loadedFromCache"); + QTEST(server.totalConnections > 0, "networkUsed"); + QFETCH(QString, body); + QCOMPARE(reply->readAll().constData(), qPrintable(body)); +} + +void tst_QNetworkReply::ioGetWithManyProxies_data() +{ + QTest::addColumn<QList<QNetworkProxy> >("proxyList"); + QTest::addColumn<QNetworkProxy>("proxyUsed"); + QTest::addColumn<QString>("url"); + QTest::addColumn<QNetworkReply::NetworkError>("expectedError"); + + QList<QNetworkProxy> proxyList; + + // All of the other functions test DefaultProxy + // So let's test something else + + // Simple tests that work: + + // HTTP request with HTTP caching proxy + proxyList << QNetworkProxy(QNetworkProxy::HttpCachingProxy, QtNetworkSettings::serverName(), 3129); + QTest::newRow("http-on-http") + << proxyList << proxyList.at(0) + << "http://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt" + << QNetworkReply::NoError; + + // HTTP request with HTTP transparent proxy + proxyList.clear(); + proxyList << QNetworkProxy(QNetworkProxy::HttpProxy, QtNetworkSettings::serverName(), 3129); + QTest::newRow("http-on-http2") + << proxyList << proxyList.at(0) + << "http://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt" + << QNetworkReply::NoError; + + // HTTP request with SOCKS transparent proxy + proxyList.clear(); + proxyList << QNetworkProxy(QNetworkProxy::Socks5Proxy, QtNetworkSettings::serverName(), 1081); + QTest::newRow("http-on-socks") + << proxyList << proxyList.at(0) + << "http://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt" + << QNetworkReply::NoError; + + // FTP request with FTP caching proxy + proxyList.clear(); + proxyList << QNetworkProxy(QNetworkProxy::FtpCachingProxy, QtNetworkSettings::serverName(), 2121); + QTest::newRow("ftp-on-ftp") + << proxyList << proxyList.at(0) + << "ftp://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt" + << QNetworkReply::NoError; + + // The following test doesn't work because QFtp is too limited + // It can only talk to its own kind of proxies + + // FTP request with SOCKSv5 transparent proxy + proxyList.clear(); + proxyList << QNetworkProxy(QNetworkProxy::Socks5Proxy, QtNetworkSettings::serverName(), 1081); + QTest::newRow("ftp-on-socks") + << proxyList << proxyList.at(0) + << "ftp://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt" + << QNetworkReply::NoError; + +#ifndef QT_NO_OPENSSL + // HTTPS with HTTP transparent proxy + proxyList.clear(); + proxyList << QNetworkProxy(QNetworkProxy::HttpProxy, QtNetworkSettings::serverName(), 3129); + QTest::newRow("https-on-http") + << proxyList << proxyList.at(0) + << "https://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt" + << QNetworkReply::NoError; + + // HTTPS request with SOCKS transparent proxy + proxyList.clear(); + proxyList << QNetworkProxy(QNetworkProxy::Socks5Proxy, QtNetworkSettings::serverName(), 1081); + QTest::newRow("https-on-socks") + << proxyList << proxyList.at(0) + << "https://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt" + << QNetworkReply::NoError; +#endif + + // Tests that fail: + + // HTTP request with FTP caching proxy + proxyList.clear(); + proxyList << QNetworkProxy(QNetworkProxy::FtpCachingProxy, QtNetworkSettings::serverName(), 2121); + QTest::newRow("http-on-ftp") + << proxyList << QNetworkProxy() + << "http://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt" + << QNetworkReply::ProxyNotFoundError; + + // FTP request with HTTP caching proxy + proxyList.clear(); + proxyList << QNetworkProxy(QNetworkProxy::HttpCachingProxy, QtNetworkSettings::serverName(), 3129); + QTest::newRow("ftp-on-http") + << proxyList << QNetworkProxy() + << "ftp://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt" + << QNetworkReply::ProxyNotFoundError; + + // FTP request with HTTP caching proxies + proxyList.clear(); + proxyList << QNetworkProxy(QNetworkProxy::HttpCachingProxy, QtNetworkSettings::serverName(), 3129) + << QNetworkProxy(QNetworkProxy::HttpCachingProxy, QtNetworkSettings::serverName(), 3130); + QTest::newRow("ftp-on-multiple-http") + << proxyList << QNetworkProxy() + << "ftp://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt" + << QNetworkReply::ProxyNotFoundError; + +#ifndef QT_NO_OPENSSL + // HTTPS with HTTP caching proxy + proxyList.clear(); + proxyList << QNetworkProxy(QNetworkProxy::HttpCachingProxy, QtNetworkSettings::serverName(), 3129); + QTest::newRow("https-on-httptransparent") + << proxyList << QNetworkProxy() + << "https://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt" + << QNetworkReply::ProxyNotFoundError; + + // HTTPS with FTP caching proxy + proxyList.clear(); + proxyList << QNetworkProxy(QNetworkProxy::FtpCachingProxy, QtNetworkSettings::serverName(), 2121); + QTest::newRow("https-on-ftp") + << proxyList << QNetworkProxy() + << "https://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt" + << QNetworkReply::ProxyNotFoundError; +#endif + + // Complex requests: + + // HTTP request with more than one HTTP proxy + proxyList.clear(); + proxyList << QNetworkProxy(QNetworkProxy::HttpCachingProxy, QtNetworkSettings::serverName(), 3129) + << QNetworkProxy(QNetworkProxy::HttpCachingProxy, QtNetworkSettings::serverName(), 3130); + QTest::newRow("http-on-multiple-http") + << proxyList << proxyList.at(0) + << "http://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt" + << QNetworkReply::NoError; + + // HTTP request with HTTP + SOCKS + proxyList.clear(); + proxyList << QNetworkProxy(QNetworkProxy::HttpCachingProxy, QtNetworkSettings::serverName(), 3129) + << QNetworkProxy(QNetworkProxy::Socks5Proxy, QtNetworkSettings::serverName(), 1081); + QTest::newRow("http-on-http+socks") + << proxyList << proxyList.at(0) + << "http://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt" + << QNetworkReply::NoError; + + // HTTP request with FTP + HTTP + SOCKS + proxyList.clear(); + proxyList << QNetworkProxy(QNetworkProxy::FtpCachingProxy, QtNetworkSettings::serverName(), 2121) + << QNetworkProxy(QNetworkProxy::HttpCachingProxy, QtNetworkSettings::serverName(), 3129) + << QNetworkProxy(QNetworkProxy::Socks5Proxy, QtNetworkSettings::serverName(), 1081); + QTest::newRow("http-on-ftp+http+socks") + << proxyList << proxyList.at(1) // second proxy should be used + << "http://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt" + << QNetworkReply::NoError; + + // HTTP request with NoProxy + HTTP + proxyList.clear(); + proxyList << QNetworkProxy(QNetworkProxy::NoProxy) + << QNetworkProxy(QNetworkProxy::HttpCachingProxy, QtNetworkSettings::serverName(), 3129); + QTest::newRow("http-on-noproxy+http") + << proxyList << proxyList.at(0) + << "http://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt" + << QNetworkReply::NoError; + + // HTTP request with FTP + NoProxy + proxyList.clear(); + proxyList << QNetworkProxy(QNetworkProxy::FtpCachingProxy, QtNetworkSettings::serverName(), 2121) + << QNetworkProxy(QNetworkProxy::NoProxy); + QTest::newRow("http-on-ftp+noproxy") + << proxyList << proxyList.at(1) // second proxy should be used + << "http://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt" + << QNetworkReply::NoError; + + // FTP request with HTTP Caching + FTP + proxyList.clear(); + proxyList << QNetworkProxy(QNetworkProxy::HttpCachingProxy, QtNetworkSettings::serverName(), 3129) + << QNetworkProxy(QNetworkProxy::FtpCachingProxy, QtNetworkSettings::serverName(), 2121); + QTest::newRow("ftp-on-http+ftp") + << proxyList << proxyList.at(1) // second proxy should be used + << "ftp://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt" + << QNetworkReply::NoError; + +#ifndef QT_NO_OPENSSL + // HTTPS request with HTTP Caching + HTTP transparent + proxyList.clear(); + proxyList << QNetworkProxy(QNetworkProxy::HttpCachingProxy, QtNetworkSettings::serverName(), 3129) + << QNetworkProxy(QNetworkProxy::HttpProxy, QtNetworkSettings::serverName(), 3129); + QTest::newRow("https-on-httpcaching+http") + << proxyList << proxyList.at(1) // second proxy should be used + << "https://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt" + << QNetworkReply::NoError; + + // HTTPS request with FTP + HTTP C + HTTP T + proxyList.clear(); + proxyList << QNetworkProxy(QNetworkProxy::FtpCachingProxy, QtNetworkSettings::serverName(), 2121) + << QNetworkProxy(QNetworkProxy::HttpCachingProxy, QtNetworkSettings::serverName(), 3129) + << QNetworkProxy(QNetworkProxy::HttpProxy, QtNetworkSettings::serverName(), 3129); + QTest::newRow("https-on-ftp+httpcaching+http") + << proxyList << proxyList.at(2) // skip the first two + << "https://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt" + << QNetworkReply::NoError; +#endif +} + +void tst_QNetworkReply::ioGetWithManyProxies() +{ + // Test proxy factories + + qRegisterMetaType<QNetworkProxy>(); // for QSignalSpy + qRegisterMetaType<QAuthenticator *>(); + + QFile reference(SRCDIR "/rfc3252.txt"); + QVERIFY(reference.open(QIODevice::ReadOnly)); + + // set the proxy factory: + QFETCH(QList<QNetworkProxy>, proxyList); + MyProxyFactory *proxyFactory = new MyProxyFactory; + proxyFactory->toReturn = proxyList; + manager.setProxyFactory(proxyFactory); + + QFETCH(QString, url); + QUrl theUrl(url); + QNetworkRequest request(theUrl); + QNetworkReplyPtr reply = manager.get(request); + DataReader reader(reply); + + QSignalSpy authspy(&manager, SIGNAL(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*))); + connect(&manager, SIGNAL(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*)), + SLOT(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*))); + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); +#ifndef QT_NO_OPENSSL + connect(&manager, SIGNAL(sslErrors(QNetworkReply*,QList<QSslError>)), + SLOT(sslErrors(QNetworkReply*,QList<QSslError>))); +#endif + QTestEventLoop::instance().enterLoop(15); + QVERIFY(!QTestEventLoop::instance().timeout()); + + manager.disconnect(SIGNAL(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*)), + this, SLOT(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*))); +#ifndef QT_NO_OPENSSL + manager.disconnect(SIGNAL(sslErrors(QNetworkReply*,QList<QSslError>)), + this, SLOT(sslErrors(QNetworkReply*,QList<QSslError>))); +#endif + + QFETCH(QNetworkReply::NetworkError, expectedError); + QEXPECT_FAIL("ftp-on-socks", "QFtp is too limited and won't accept non-FTP proxies", Abort); + QCOMPARE(reply->error(), expectedError); + + // Verify that the factory was called properly + QCOMPARE(proxyFactory->callCount, 1); + QCOMPARE(proxyFactory->lastQuery, QNetworkProxyQuery(theUrl)); + + if (expectedError == QNetworkReply::NoError) { + // request succeeded + QCOMPARE(reader.data, reference.readAll()); + + // now verify that the proxies worked: + QFETCH(QNetworkProxy, proxyUsed); + if (proxyUsed.type() == QNetworkProxy::NoProxy) { + QCOMPARE(authspy.count(), 0); + } else { + if (QByteArray(QTest::currentDataTag()).startsWith("ftp-")) + return; // No authentication with current FTP or with FTP proxies + QCOMPARE(authspy.count(), 1); + QCOMPARE(qvariant_cast<QNetworkProxy>(authspy.at(0).at(0)), proxyUsed); + } + } else { + // request failed + QCOMPARE(authspy.count(), 0); + } +} + +void tst_QNetworkReply::ioPutToFileFromFile_data() +{ + QTest::addColumn<QString>("fileName"); + + QTest::newRow("empty") << SRCDIR "/empty"; + QTest::newRow("real-file") << SRCDIR "/rfc3252.txt"; + QTest::newRow("resource") << ":/resource"; + QTest::newRow("search-path") << "srcdir:/rfc3252.txt"; +} + +void tst_QNetworkReply::ioPutToFileFromFile() +{ + QFETCH(QString, fileName); + QFile sourceFile(fileName); + QFile targetFile(testFileName); + + QVERIFY(sourceFile.open(QIODevice::ReadOnly)); + + QUrl url = QUrl::fromLocalFile(targetFile.fileName()); + QNetworkRequest request(url); + QNetworkReplyPtr reply = manager.put(request, &sourceFile); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QCOMPARE(reply->url(), url); + QCOMPARE(reply->error(), QNetworkReply::NoError); + QCOMPARE(reply->header(QNetworkRequest::ContentLengthHeader).toLongLong(), Q_INT64_C(0)); + QVERIFY(reply->readAll().isEmpty()); + + QVERIFY(sourceFile.atEnd()); + sourceFile.seek(0); // reset it to the beginning + + QVERIFY(targetFile.open(QIODevice::ReadOnly)); + QCOMPARE(targetFile.size(), sourceFile.size()); + QCOMPARE(targetFile.readAll(), sourceFile.readAll()); +} + +void tst_QNetworkReply::ioPutToFileFromSocket_data() +{ + putToFile_data(); +} + +void tst_QNetworkReply::ioPutToFileFromSocket() +{ + QFile file(testFileName); + + QUrl url = QUrl::fromLocalFile(file.fileName()); + QNetworkRequest request(url); + + QFETCH(QByteArray, data); + SocketPair socketpair; + socketpair.create(); + QVERIFY(socketpair.endPoints[0] && socketpair.endPoints[1]); + + socketpair.endPoints[0]->write(data); + QNetworkReplyPtr reply = manager.put(QNetworkRequest(url), socketpair.endPoints[1]); + socketpair.endPoints[0]->close(); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QCOMPARE(reply->error(), QNetworkReply::NoError); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QCOMPARE(reply->url(), url); + QCOMPARE(reply->error(), QNetworkReply::NoError); + QCOMPARE(reply->header(QNetworkRequest::ContentLengthHeader).toLongLong(), Q_INT64_C(0)); + QVERIFY(reply->readAll().isEmpty()); + + QVERIFY(file.open(QIODevice::ReadOnly)); + QCOMPARE(file.size(), qint64(data.size())); + QByteArray contents = file.readAll(); + QCOMPARE(contents, data); +} + +void tst_QNetworkReply::ioPutToFileFromLocalSocket_data() +{ + putToFile_data(); +} + +void tst_QNetworkReply::ioPutToFileFromLocalSocket() +{ + QString socketname = "networkreplytest"; + QLocalServer server; + if (!server.listen(socketname)) { + QLocalServer::removeServer(socketname); + QVERIFY(server.listen(socketname)); + } + QLocalSocket active; + active.connectToServer(socketname); + QVERIFY2(server.waitForNewConnection(10), server.errorString().toLatin1().constData()); + QVERIFY2(active.waitForConnected(10), active.errorString().toLatin1().constData()); + QVERIFY2(server.hasPendingConnections(), server.errorString().toLatin1().constData()); + QLocalSocket *passive = server.nextPendingConnection(); + + QFile file(testFileName); + QUrl url = QUrl::fromLocalFile(file.fileName()); + QNetworkRequest request(url); + + QFETCH(QByteArray, data); + active.write(data); + active.close(); + QNetworkReplyPtr reply = manager.put(QNetworkRequest(url), passive); + passive->setParent(reply); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QCOMPARE(reply->error(), QNetworkReply::NoError); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QCOMPARE(reply->url(), url); + QCOMPARE(reply->error(), QNetworkReply::NoError); + QCOMPARE(reply->header(QNetworkRequest::ContentLengthHeader).toLongLong(), Q_INT64_C(0)); + QVERIFY(reply->readAll().isEmpty()); + + QVERIFY(file.open(QIODevice::ReadOnly)); + QCOMPARE(file.size(), qint64(data.size())); + QByteArray contents = file.readAll(); + QCOMPARE(contents, data); +} + +void tst_QNetworkReply::ioPutToFileFromProcess_data() +{ + putToFile_data(); +} + +void tst_QNetworkReply::ioPutToFileFromProcess() +{ +#if defined(Q_OS_WINCE) || defined (Q_OS_SYMBIAN) + QSKIP("Currently no stdin/out supported for Windows CE / Symbian OS", SkipAll); +#else + +#ifdef Q_OS_WIN + if (qstrcmp(QTest::currentDataTag(), "small") == 0) + QSKIP("When passing a CR-LF-LF sequence through Windows stdio, it gets converted, " + "so this test fails. Disabled on Windows", SkipSingle); +#endif + +#if defined(QT_NO_PROCESS) + QSKIP("Qt was compiled with QT_NO_PROCESS", SkipAll); +#else + QFile file(testFileName); + + QUrl url = QUrl::fromLocalFile(file.fileName()); + QNetworkRequest request(url); + + QFETCH(QByteArray, data); + QProcess process; + process.start("echo/echo all"); + process.write(data); + process.closeWriteChannel(); + + QNetworkReplyPtr reply = manager.put(QNetworkRequest(url), &process); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QCOMPARE(reply->url(), url); + QCOMPARE(reply->error(), QNetworkReply::NoError); + QCOMPARE(reply->header(QNetworkRequest::ContentLengthHeader).toLongLong(), Q_INT64_C(0)); + QVERIFY(reply->readAll().isEmpty()); + + QVERIFY(file.open(QIODevice::ReadOnly)); + QCOMPARE(file.size(), qint64(data.size())); + QByteArray contents = file.readAll(); + QCOMPARE(contents, data); +#endif +#endif +} + +void tst_QNetworkReply::ioPutToFtpFromFile_data() +{ + ioPutToFileFromFile_data(); +} + +void tst_QNetworkReply::ioPutToFtpFromFile() +{ + QFETCH(QString, fileName); + QFile sourceFile(fileName); + QVERIFY(sourceFile.open(QIODevice::ReadOnly)); + + QUrl url("ftp://" + QtNetworkSettings::serverName()); + url.setPath(QString("/qtest/upload/qnetworkaccess-ioPutToFtpFromFile-%1-%2") + .arg(QTest::currentDataTag()) + .arg(uniqueExtension)); + + QNetworkRequest request(url); + QNetworkReplyPtr reply = manager.put(request, &sourceFile); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QCOMPARE(reply->url(), url); + QCOMPARE(reply->error(), QNetworkReply::NoError); + QCOMPARE(reply->header(QNetworkRequest::ContentLengthHeader).toLongLong(), Q_INT64_C(0)); + QVERIFY(reply->readAll().isEmpty()); + + QVERIFY(sourceFile.atEnd()); + sourceFile.seek(0); // reset it to the beginning + + // download the file again from FTP to make sure it was uploaded + // correctly + QFtp ftp; + ftp.connectToHost(url.host()); + ftp.login(); + ftp.get(url.path()); + + QObject::connect(&ftp, SIGNAL(done(bool)), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(3); + QObject::disconnect(&ftp, SIGNAL(done(bool)), &QTestEventLoop::instance(), SLOT(exitLoop())); + + QByteArray uploaded = ftp.readAll(); + QCOMPARE(qint64(uploaded.size()), sourceFile.size()); + QCOMPARE(uploaded, sourceFile.readAll()); + + ftp.close(); + QObject::connect(&ftp, SIGNAL(done(bool)), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QObject::disconnect(&ftp, SIGNAL(done(bool)), &QTestEventLoop::instance(), SLOT(exitLoop())); +} + +void tst_QNetworkReply::ioPutToHttpFromFile_data() +{ + ioPutToFileFromFile_data(); +} + +void tst_QNetworkReply::ioPutToHttpFromFile() +{ + QFETCH(QString, fileName); + QFile sourceFile(fileName); + QVERIFY(sourceFile.open(QIODevice::ReadOnly)); + + QUrl url("http://" + QtNetworkSettings::serverName()); + url.setPath(QString("/dav/qnetworkaccess-ioPutToHttpFromFile-%1-%2") + .arg(QTest::currentDataTag()) + .arg(uniqueExtension)); + + QNetworkRequest request(url); + QNetworkReplyPtr reply = manager.put(request, &sourceFile); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QCOMPARE(reply->url(), url); + QCOMPARE(reply->error(), QNetworkReply::NoError); + + // verify that the HTTP status code is 201 Created + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 201); + + QVERIFY(sourceFile.atEnd()); + sourceFile.seek(0); // reset it to the beginning + + // download the file again from HTTP to make sure it was uploaded + // correctly + reply = manager.get(request); + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QCOMPARE(reply->url(), url); + QCOMPARE(reply->error(), QNetworkReply::NoError); + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); // 200 Ok + + QCOMPARE(reply->readAll(), sourceFile.readAll()); +} + +void tst_QNetworkReply::ioPostToHttpFromFile_data() +{ + ioPutToFileFromFile_data(); +} + +void tst_QNetworkReply::ioPostToHttpFromFile() +{ + QFETCH(QString, fileName); + QFile sourceFile(fileName); + QVERIFY(sourceFile.open(QIODevice::ReadOnly)); + + QUrl url("http://" + QtNetworkSettings::serverName() + "/qtest/cgi-bin/md5sum.cgi"); + QNetworkRequest request(url); + request.setRawHeader("Content-Type", "application/octet-stream"); + + QNetworkReplyPtr reply = manager.post(request, &sourceFile); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QCOMPARE(reply->url(), url); + QCOMPARE(reply->error(), QNetworkReply::NoError); + + // verify that the HTTP status code is 200 Ok + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); + + QVERIFY(sourceFile.atEnd()); + sourceFile.seek(0); // reset it to the beginning + + QCOMPARE(reply->readAll().trimmed(), md5sum(sourceFile.readAll()).toHex()); +} + +void tst_QNetworkReply::ioPostToHttpFromSocket_data() +{ + QTest::addColumn<QByteArray>("data"); + QTest::addColumn<QByteArray>("md5sum"); + QTest::addColumn<QUrl>("url"); + QTest::addColumn<QNetworkProxy>("proxy"); + QTest::addColumn<int>("authenticationRequiredCount"); + QTest::addColumn<int>("proxyAuthenticationRequiredCount"); + + for (int i = 0; i < proxies.count(); ++i) + for (int auth = 0; auth < 2; ++auth) { + QUrl url; + if (auth) + url = "http://" + QtNetworkSettings::serverName() + "/qtest/protected/cgi-bin/md5sum.cgi"; + else + url = "http://" + QtNetworkSettings::serverName() + "/qtest/cgi-bin/md5sum.cgi"; + + QNetworkProxy proxy = proxies.at(i).proxy; + QByteArray testsuffix = QByteArray(auth ? "+auth" : "") + proxies.at(i).tag; + int proxyauthcount = proxies.at(i).requiresAuthentication; + + QByteArray data; + data = ""; + QTest::newRow("empty" + testsuffix) << data << md5sum(data) << url << proxy << auth << proxyauthcount; + + data = "This is a normal message."; + QTest::newRow("generic" + testsuffix) << data << md5sum(data) << url << proxy << auth << proxyauthcount; + + data = "This is a message to show that Qt rocks!\r\n\n"; + QTest::newRow("small" + testsuffix) << data << md5sum(data) << url << proxy << auth << proxyauthcount; + + data = QByteArray("abcd\0\1\2\abcd",12); + QTest::newRow("with-nul" + testsuffix) << data << md5sum(data) << url << proxy << auth << proxyauthcount; + + data = QByteArray(4097, '\4'); + QTest::newRow("4k+1" + testsuffix) << data << md5sum(data) << url << proxy << auth << proxyauthcount; + + data = QByteArray(128*1024+1, '\177'); + QTest::newRow("128k+1" + testsuffix) << data << md5sum(data) << url << proxy << auth << proxyauthcount; + } +} + +void tst_QNetworkReply::ioPostToHttpFromSocket() +{ + qRegisterMetaType<QNetworkProxy>(); // for QSignalSpy + qRegisterMetaType<QAuthenticator *>(); + qRegisterMetaType<QNetworkReply *>(); + + QFETCH(QByteArray, data); + QFETCH(QUrl, url); + QFETCH(QNetworkProxy, proxy); + SocketPair socketpair; + socketpair.create(); + QVERIFY(socketpair.endPoints[0] && socketpair.endPoints[1]); + + socketpair.endPoints[0]->write(data); + + QNetworkRequest request(url); + request.setRawHeader("Content-Type", "application/octet-stream"); + + manager.setProxy(proxy); + QNetworkReplyPtr reply = manager.post(request, socketpair.endPoints[1]); + socketpair.endPoints[0]->close(); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + connect(&manager, SIGNAL(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*)), + SLOT(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*))); + connect(&manager, SIGNAL(authenticationRequired(QNetworkReply*,QAuthenticator*)), + SLOT(authenticationRequired(QNetworkReply*,QAuthenticator*))); + + QSignalSpy authenticationRequiredSpy(&manager, SIGNAL(authenticationRequired(QNetworkReply*,QAuthenticator*))); + QSignalSpy proxyAuthenticationRequiredSpy(&manager, SIGNAL(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*))); + + QTestEventLoop::instance().enterLoop(12); + disconnect(&manager, SIGNAL(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*)), + this, SLOT(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*))); + disconnect(&manager, SIGNAL(authenticationRequired(QNetworkReply*,QAuthenticator*)), + this, SLOT(authenticationRequired(QNetworkReply*,QAuthenticator*))); + QCOMPARE(reply->error(), QNetworkReply::NoError); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QCOMPARE(reply->url(), url); + QCOMPARE(reply->error(), QNetworkReply::NoError); + // verify that the HTTP status code is 200 Ok + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); + + QCOMPARE(reply->readAll().trimmed(), md5sum(data).toHex()); + + QTEST(authenticationRequiredSpy.count(), "authenticationRequiredCount"); + QTEST(proxyAuthenticationRequiredSpy.count(), "proxyAuthenticationRequiredCount"); +} + +void tst_QNetworkReply::ioPostToHttpFromSocketSynchronous_data() +{ + QTest::addColumn<QByteArray>("data"); + QTest::addColumn<QByteArray>("md5sum"); + + QByteArray data; + data = ""; + QTest::newRow("empty") << data << md5sum(data); + + data = "This is a normal message."; + QTest::newRow("generic") << data << md5sum(data); + + data = "This is a message to show that Qt rocks!\r\n\n"; + QTest::newRow("small") << data << md5sum(data); + + data = QByteArray("abcd\0\1\2\abcd",12); + QTest::newRow("with-nul") << data << md5sum(data); + + data = QByteArray(4097, '\4'); + QTest::newRow("4k+1") << data << md5sum(data); + + data = QByteArray(128*1024+1, '\177'); + QTest::newRow("128k+1") << data << md5sum(data); + + data = QByteArray(2*1024*1024+1, '\177'); + QTest::newRow("2MB+1") << data << md5sum(data); +} + +void tst_QNetworkReply::ioPostToHttpFromSocketSynchronous() +{ + QFETCH(QByteArray, data); + + SocketPair socketpair; + QVERIFY(socketpair.create()); + QVERIFY(socketpair.endPoints[0] && socketpair.endPoints[1]); + socketpair.endPoints[0]->write(data); + socketpair.endPoints[0]->waitForBytesWritten(5000); + // ### for 4.8: make the socket pair unbuffered, to not read everything in one go in QNetworkReplyImplPrivate::setup() + QTestEventLoop::instance().enterLoop(3); + + QUrl url("http://" + QtNetworkSettings::serverName() + "/qtest/cgi-bin/md5sum.cgi"); + QNetworkRequest request(url); + request.setRawHeader("Content-Type", "application/octet-stream"); + request.setAttribute( + QNetworkRequest::SynchronousRequestAttribute, + true); + + QNetworkReplyPtr reply = manager.post(request, socketpair.endPoints[1]); + QVERIFY(reply->isFinished()); + socketpair.endPoints[0]->close(); + + QCOMPARE(reply->error(), QNetworkReply::NoError); + + QCOMPARE(reply->url(), url); + QCOMPARE(reply->error(), QNetworkReply::NoError); + // verify that the HTTP status code is 200 Ok + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); + + QCOMPARE(reply->readAll().trimmed(), md5sum(data).toHex()); +} + +// this tests checks if rewinding the POST-data to some place in the middle +// worked. +void tst_QNetworkReply::ioPostToHttpFromMiddleOfFileToEnd() +{ + QFile sourceFile(SRCDIR "/rfc3252.txt"); + QVERIFY(sourceFile.open(QIODevice::ReadOnly)); + // seeking to the middle + sourceFile.seek(sourceFile.size() / 2); + + QUrl url = "http://" + QtNetworkSettings::serverName() + "/qtest/protected/cgi-bin/md5sum.cgi"; + QNetworkRequest request(url); + request.setRawHeader("Content-Type", "application/octet-stream"); + QNetworkReplyPtr reply = manager.post(request, &sourceFile); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + connect(&manager, SIGNAL(authenticationRequired(QNetworkReply*,QAuthenticator*)), + SLOT(authenticationRequired(QNetworkReply*,QAuthenticator*))); + + QTestEventLoop::instance().enterLoop(2); + disconnect(&manager, SIGNAL(authenticationRequired(QNetworkReply*,QAuthenticator*)), + this, SLOT(authenticationRequired(QNetworkReply*,QAuthenticator*))); + QVERIFY(!QTestEventLoop::instance().timeout()); + + // compare half data + sourceFile.seek(sourceFile.size() / 2); + QByteArray data = sourceFile.readAll(); + QCOMPARE(reply->readAll().trimmed(), md5sum(data).toHex()); +} + +void tst_QNetworkReply::ioPostToHttpFromMiddleOfFileFiveBytes() +{ + QFile sourceFile(SRCDIR "/rfc3252.txt"); + QVERIFY(sourceFile.open(QIODevice::ReadOnly)); + // seeking to the middle + sourceFile.seek(sourceFile.size() / 2); + + QUrl url = "http://" + QtNetworkSettings::serverName() + "/qtest/protected/cgi-bin/md5sum.cgi"; + QNetworkRequest request(url); + request.setRawHeader("Content-Type", "application/octet-stream"); + // only send 5 bytes + request.setHeader(QNetworkRequest::ContentLengthHeader, 5); + QVERIFY(request.header(QNetworkRequest::ContentLengthHeader).isValid()); + QNetworkReplyPtr reply = manager.post(request, &sourceFile); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + connect(&manager, SIGNAL(authenticationRequired(QNetworkReply*,QAuthenticator*)), + SLOT(authenticationRequired(QNetworkReply*,QAuthenticator*))); + + QTestEventLoop::instance().enterLoop(2); + disconnect(&manager, SIGNAL(authenticationRequired(QNetworkReply*,QAuthenticator*)), + this, SLOT(authenticationRequired(QNetworkReply*,QAuthenticator*))); + QVERIFY(!QTestEventLoop::instance().timeout()); + + // compare half data + sourceFile.seek(sourceFile.size() / 2); + QByteArray data = sourceFile.read(5); + QCOMPARE(reply->readAll().trimmed(), md5sum(data).toHex()); +} + +void tst_QNetworkReply::ioPostToHttpFromMiddleOfQBufferFiveBytes() +{ + // test needed since a QBuffer goes with a different codepath than the QFile + // tested in ioPostToHttpFromMiddleOfFileFiveBytes + QBuffer uploadBuffer; + uploadBuffer.open(QIODevice::ReadWrite); + uploadBuffer.write("1234567890"); + uploadBuffer.seek(5); + + QUrl url = "http://" + QtNetworkSettings::serverName() + "/qtest/protected/cgi-bin/md5sum.cgi"; + QNetworkRequest request(url); + QNetworkReplyPtr reply = manager.post(request, &uploadBuffer); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + connect(&manager, SIGNAL(authenticationRequired(QNetworkReply*,QAuthenticator*)), + SLOT(authenticationRequired(QNetworkReply*,QAuthenticator*))); + + QTestEventLoop::instance().enterLoop(2); + disconnect(&manager, SIGNAL(authenticationRequired(QNetworkReply*,QAuthenticator*)), + this, SLOT(authenticationRequired(QNetworkReply*,QAuthenticator*))); + QVERIFY(!QTestEventLoop::instance().timeout()); + + // compare half data + uploadBuffer.seek(5); + QByteArray data = uploadBuffer.read(5); + QCOMPARE(reply->readAll().trimmed(), md5sum(data).toHex()); +} + + +void tst_QNetworkReply::ioPostToHttpNoBufferFlag() +{ + QByteArray data = QByteArray("daaaaaaataaaaaaa"); + // create a sequential QIODevice by feeding the data into a local TCP server + SocketPair socketpair; + socketpair.create(); + QVERIFY(socketpair.endPoints[0] && socketpair.endPoints[1]); + socketpair.endPoints[0]->write(data); + + QUrl url = "http://" + QtNetworkSettings::serverName() + "/qtest/protected/cgi-bin/md5sum.cgi"; + QNetworkRequest request(url); + request.setRawHeader("Content-Type", "application/octet-stream"); + // disallow buffering + request.setAttribute(QNetworkRequest::DoNotBufferUploadDataAttribute, true); + request.setHeader(QNetworkRequest::ContentLengthHeader, data.size()); + QNetworkReplyPtr reply = manager.post(request, socketpair.endPoints[1]); + socketpair.endPoints[0]->close(); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + connect(&manager, SIGNAL(authenticationRequired(QNetworkReply*,QAuthenticator*)), + SLOT(authenticationRequired(QNetworkReply*,QAuthenticator*))); + + QTestEventLoop::instance().enterLoop(2); + disconnect(&manager, SIGNAL(authenticationRequired(QNetworkReply*,QAuthenticator*)), + this, SLOT(authenticationRequired(QNetworkReply*,QAuthenticator*))); + + // verify: error code is QNetworkReply::ContentReSendError + QCOMPARE(reply->error(), QNetworkReply::ContentReSendError); +} + +#ifndef QT_NO_OPENSSL +class SslServer : public QTcpServer { + Q_OBJECT +public: + SslServer() : socket(0) {}; + void incomingConnection(int socketDescriptor) { + QSslSocket *serverSocket = new QSslSocket; + serverSocket->setParent(this); + + if (serverSocket->setSocketDescriptor(socketDescriptor)) { + connect(serverSocket, SIGNAL(encrypted()), this, SLOT(encryptedSlot())); + serverSocket->setProtocol(QSsl::AnyProtocol); + connect(serverSocket, SIGNAL(sslErrors(const QList<QSslError>&)), serverSocket, SLOT(ignoreSslErrors())); + serverSocket->setLocalCertificate(SRCDIR "/certs/server.pem"); + serverSocket->setPrivateKey(SRCDIR "/certs/server.key"); + serverSocket->startServerEncryption(); + } else { + delete serverSocket; + } + } +signals: + void newEncryptedConnection(); +public slots: + void encryptedSlot() { + socket = (QSslSocket*) sender(); + emit newEncryptedConnection(); + } +public: + QSslSocket *socket; +}; + +// very similar to ioPostToHttpUploadProgress but for SSL +void tst_QNetworkReply::ioPostToHttpsUploadProgress() +{ + QFile sourceFile(SRCDIR "/bigfile"); + QVERIFY(sourceFile.open(QIODevice::ReadOnly)); + + // emulate a minimal https server + SslServer server; + server.listen(QHostAddress(QHostAddress::LocalHost), 0); + + // create the request + QUrl url = QUrl(QString("https://127.0.0.1:%1/").arg(server.serverPort())); + QNetworkRequest request(url); + request.setRawHeader("Content-Type", "application/octet-stream"); + QNetworkReplyPtr reply = manager.post(request, &sourceFile); + QSignalSpy spy(reply, SIGNAL(uploadProgress(qint64,qint64))); + connect(&server, SIGNAL(newEncryptedConnection()), &QTestEventLoop::instance(), SLOT(exitLoop())); + connect(reply, SIGNAL(sslErrors(const QList<QSslError>&)), reply, SLOT(ignoreSslErrors())); + + // get the request started and the incoming socket connected + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + QTcpSocket *incomingSocket = server.socket; + QVERIFY(incomingSocket); + disconnect(&server, SIGNAL(newEncryptedConnection()), &QTestEventLoop::instance(), SLOT(exitLoop())); + + + incomingSocket->setReadBufferSize(1*1024); + QTestEventLoop::instance().enterLoop(2); + // some progress should have been made + QVERIFY(!spy.isEmpty()); + QList<QVariant> args = spy.last(); + QVERIFY(args.at(0).toLongLong() > 0); + + QVERIFY(args.at(0).toLongLong() != sourceFile.size()); + + incomingSocket->setReadBufferSize(32*1024); + incomingSocket->read(16*1024); + QTestEventLoop::instance().enterLoop(2); + // some more progress than before + QVERIFY(!spy.isEmpty()); + QList<QVariant> args2 = spy.last(); + QVERIFY(args2.at(0).toLongLong() > args.at(0).toLongLong()); + + // set the read buffer to unlimited + incomingSocket->setReadBufferSize(0); + QTestEventLoop::instance().enterLoop(10); + // progress should be finished + QVERIFY(!spy.isEmpty()); + QList<QVariant> args3 = spy.last(); + QVERIFY(args3.at(0).toLongLong() > args2.at(0).toLongLong()); + QCOMPARE(args3.at(0).toLongLong(), args3.at(1).toLongLong()); + QCOMPARE(args3.at(0).toLongLong(), sourceFile.size()); + + // after sending this, the QNAM should emit finished() + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + incomingSocket->write("HTTP/1.0 200 OK\r\n"); + incomingSocket->write("Content-Length: 0\r\n"); + incomingSocket->write("\r\n"); + QTestEventLoop::instance().enterLoop(10); + // not timeouted -> finished() was emitted + QVERIFY(!QTestEventLoop::instance().timeout()); + + incomingSocket->close(); + server.close(); +} +#endif + +void tst_QNetworkReply::ioGetFromBuiltinHttp_data() +{ + QTest::addColumn<bool>("https"); + QTest::addColumn<int>("bufferSize"); + QTest::newRow("http+unlimited") << false << 0; + QTest::newRow("http+limited") << false << 4096; +#ifndef QT_NO_OPENSSL + QTest::newRow("https+unlimited") << true << 0; + QTest::newRow("https+limited") << true << 4096; +#endif +} + +void tst_QNetworkReply::ioGetFromBuiltinHttp() +{ + QSKIP("Limiting is broken right now, check QTBUG-15065", SkipAll); + QFETCH(bool, https); + QFETCH(int, bufferSize); + + QByteArray testData; + // Make the data big enough so that it can fill the kernel buffer + // (which seems to hold 202 KB here) + const int wantedSize = 1200 * 1000; + testData.reserve(wantedSize); + // And in the case of SSL, the compression can fool us and let the + // server send the data much faster than expected. + // So better provide random data that cannot be compressed. + for (int i = 0; i < wantedSize; ++i) + testData += (char)qrand(); + + QByteArray httpResponse = QByteArray("HTTP/1.0 200 OK\r\nContent-Length: "); + httpResponse += QByteArray::number(testData.size()); + httpResponse += "\r\n\r\n"; + httpResponse += testData; + + qDebug() << "Server will send" << (httpResponse.size()-testData.size()) << "bytes of header and" + << testData.size() << "bytes of data"; + + const bool fillKernelBuffer = bufferSize > 0; + FastSender server(httpResponse, https, fillKernelBuffer); + + QUrl url(QString("%1://127.0.0.1:%2/qtest/rfc3252.txt") + .arg(https?"https":"http") + .arg(server.serverPort())); + QNetworkRequest request(url); + QNetworkReplyPtr reply = manager.get(request); + reply->setReadBufferSize(bufferSize); + reply->ignoreSslErrors(); + const int rate = 200; // in kB per sec + RateControlledReader reader(server, reply, rate, bufferSize); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTime loopTime; + loopTime.start(); + QTestEventLoop::instance().enterLoop(30); + const int elapsedTime = loopTime.elapsed(); + server.wait(); + reader.wrapUp(); + + qDebug() << "send rate:" << server.transferRate << "B/s"; + qDebug() << "receive rate:" << reader.totalBytesRead * 1000 / elapsedTime + << "(it received" << reader.totalBytesRead << "bytes in" << elapsedTime << "ms)"; + + QVERIFY(!QTestEventLoop::instance().timeout()); + + QCOMPARE(reply->url(), request.url()); + QCOMPARE(reply->error(), QNetworkReply::NoError); + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); + + QCOMPARE(reply->header(QNetworkRequest::ContentLengthHeader).toLongLong(), (qint64)testData.size()); + if (reader.data.size() < testData.size()) { // oops? + QCOMPARE(reader.data, testData.mid(0, reader.data.size())); + qDebug() << "The data is incomplete, the last" << testData.size() - reader.data.size() << "bytes are missing"; + QEXPECT_FAIL("http+limited", "Limiting is broken right now, check QTBUG-15065", Abort); + QEXPECT_FAIL("https+limited", "Limiting is broken right now, check QTBUG-15065", Abort); + } + QCOMPARE(reader.data.size(), testData.size()); + QCOMPARE(reader.data, testData); + + // OK we got the file alright, but did setReadBufferSize work? + QVERIFY(server.transferRate != -1); + if (bufferSize > 0) { + const int allowedDeviation = 16; // TODO find out why the send rate is 13% faster currently + const int minRate = rate * 1024 * (100-allowedDeviation) / 100; + const int maxRate = rate * 1024 * (100+allowedDeviation) / 100; + qDebug() << minRate << "<="<< server.transferRate << "<=" << maxRate << "?"; + QEXPECT_FAIL("http+limited", "Limiting is broken right now, check QTBUG-15065", Continue); + QEXPECT_FAIL("https+limited", "Limiting is broken right now, check QTBUG-15065", Continue); + QVERIFY(server.transferRate >= minRate && server.transferRate <= maxRate); + } +} + +void tst_QNetworkReply::ioPostToHttpUploadProgress() +{ + QFile sourceFile(SRCDIR "/bigfile"); + QVERIFY(sourceFile.open(QIODevice::ReadOnly)); + + // emulate a minimal http server + QTcpServer server; + server.listen(QHostAddress(QHostAddress::LocalHost), 0); + + // create the request + QUrl url = QUrl(QString("http://127.0.0.1:%1/").arg(server.serverPort())); + QNetworkRequest request(url); + QNetworkReplyPtr reply = manager.post(request, &sourceFile); + QSignalSpy spy(reply, SIGNAL(uploadProgress(qint64,qint64))); + connect(&server, SIGNAL(newConnection()), &QTestEventLoop::instance(), SLOT(exitLoop())); + + // get the request started and the incoming socket connected + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + QTcpSocket *incomingSocket = server.nextPendingConnection(); + QVERIFY(incomingSocket); + disconnect(&server, SIGNAL(newConnection()), &QTestEventLoop::instance(), SLOT(exitLoop())); + + incomingSocket->setReadBufferSize(1*1024); + QTestEventLoop::instance().enterLoop(5); + // some progress should have been made + QList<QVariant> args = spy.last(); + QVERIFY(!args.isEmpty()); + QVERIFY(args.at(0).toLongLong() > 0); + // but not everything! + QVERIFY(args.at(0).toLongLong() != sourceFile.size()); + + // set the read buffer to unlimited + incomingSocket->setReadBufferSize(0); + QTestEventLoop::instance().enterLoop(10); + // progress should be finished + QList<QVariant> args3 = spy.last(); + QVERIFY(!args3.isEmpty()); + // More progress than before + QVERIFY(args3.at(0).toLongLong() > args.at(0).toLongLong()); + QCOMPARE(args3.at(0).toLongLong(), args3.at(1).toLongLong()); + // And actually finished.. + QCOMPARE(args3.at(0).toLongLong(), sourceFile.size()); + + // after sending this, the QNAM should emit finished() + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + incomingSocket->write("HTTP/1.0 200 OK\r\n"); + incomingSocket->write("Content-Length: 0\r\n"); + incomingSocket->write("\r\n"); + QTestEventLoop::instance().enterLoop(10); + // not timeouted -> finished() was emitted + QVERIFY(!QTestEventLoop::instance().timeout()); + + incomingSocket->close(); + server.close(); +} + +void tst_QNetworkReply::ioPostToHttpEmptyUploadProgress() +{ + QByteArray ba; + ba.resize(0); + QBuffer buffer(&ba,0); + QVERIFY(buffer.open(QIODevice::ReadOnly)); + + // emulate a minimal http server + QTcpServer server; + server.listen(QHostAddress(QHostAddress::LocalHost), 0); + + // create the request + QUrl url = QUrl(QString("http://127.0.0.1:%1/").arg(server.serverPort())); + QNetworkRequest request(url); + request.setRawHeader("Content-Type", "application/octet-stream"); + QNetworkReplyPtr reply = manager.post(request, &buffer); + QSignalSpy spy(reply, SIGNAL(uploadProgress(qint64,qint64))); + connect(&server, SIGNAL(newConnection()), &QTestEventLoop::instance(), SLOT(exitLoop())); + + + // get the request started and the incoming socket connected + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + QTcpSocket *incomingSocket = server.nextPendingConnection(); + QVERIFY(incomingSocket); + + // after sending this, the QNAM should emit finished() + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + incomingSocket->write("HTTP/1.0 200 OK\r\n"); + incomingSocket->write("Content-Length: 0\r\n"); + incomingSocket->write("\r\n"); + incomingSocket->flush(); + QTestEventLoop::instance().enterLoop(10); + // not timeouted -> finished() was emitted + QVERIFY(!QTestEventLoop::instance().timeout()); + + // final check: only 1 uploadProgress has been emitted + QVERIFY(spy.length() == 1); + QList<QVariant> args = spy.last(); + QVERIFY(!args.isEmpty()); + QCOMPARE(args.at(0).toLongLong(), buffer.size()); + QCOMPARE(args.at(0).toLongLong(), buffer.size()); + + incomingSocket->close(); + server.close(); +} + +void tst_QNetworkReply::lastModifiedHeaderForFile() +{ + QFileInfo fileInfo(SRCDIR "/bigfile"); + QVERIFY(fileInfo.exists()); + + QUrl url = QUrl::fromLocalFile(fileInfo.filePath()); + + QNetworkRequest request(url); + QNetworkReplyPtr reply = manager.head(request); + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QDateTime header = reply->header(QNetworkRequest::LastModifiedHeader).toDateTime(); + QCOMPARE(header, fileInfo.lastModified()); +} + +void tst_QNetworkReply::lastModifiedHeaderForHttp() +{ + // Tue, 22 May 2007 12:04:57 GMT according to webserver + QUrl url = "http://" + QtNetworkSettings::serverName() + "/qtest/fluke.gif"; + + QNetworkRequest request(url); + QNetworkReplyPtr reply = manager.head(request); + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QDateTime header = reply->header(QNetworkRequest::LastModifiedHeader).toDateTime(); + QDateTime realDate = QDateTime::fromString("2007-05-22T12:04:57", Qt::ISODate); + realDate.setTimeSpec(Qt::UTC); + + QCOMPARE(header, realDate); +} + +void tst_QNetworkReply::httpCanReadLine() +{ + QNetworkRequest request(QUrl("http://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt")); + QNetworkReplyPtr reply = manager.get(request); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + QCOMPARE(reply->error(), QNetworkReply::NoError); + + QVERIFY(reply->canReadLine()); + QVERIFY(!reply->readAll().isEmpty()); + QVERIFY(!reply->canReadLine()); +} + +void tst_QNetworkReply::rateControl_data() +{ + QTest::addColumn<int>("rate"); + + QTest::newRow("15") << 15; + QTest::newRow("40") << 40; + QTest::newRow("73") << 73; + QTest::newRow("80") << 80; + QTest::newRow("125") << 125; + QTest::newRow("250") << 250; + QTest::newRow("1024") << 1024; +} + +void tst_QNetworkReply::rateControl() +{ + QSKIP("Test disabled -- only for manual purposes", SkipAll); + // this function tests that we aren't reading from the network + // faster than the data is being consumed. + QFETCH(int, rate); + + // ask for 20 seconds worth of data + FastSender sender(20 * rate * 1024); + + QNetworkRequest request("debugpipe://localhost:" + QString::number(sender.serverPort())); + QNetworkReplyPtr reply = manager.get(request); + reply->setReadBufferSize(32768); + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + qRegisterMetaType<QNetworkReply::NetworkError>("QNetworkReply::NetworkError"); + QSignalSpy errorSpy(reply, SIGNAL(error(QNetworkReply::NetworkError))); + + RateControlledReader reader(sender, reply, rate, 20); + + // this test is designed to run for 25 seconds at most + QTime loopTime; + loopTime.start(); + QTestEventLoop::instance().enterLoop(40); + int elapsedTime = loopTime.elapsed(); + + if (!errorSpy.isEmpty()) { + qDebug() << "ERROR!" << errorSpy[0][0] << reply->errorString(); + } + + qDebug() << "tst_QNetworkReply::rateControl" << "send rate:" << sender.transferRate; + qDebug() << "tst_QNetworkReply::rateControl" << "receive rate:" << reader.totalBytesRead * 1000 / elapsedTime + << "(it received" << reader.totalBytesRead << "bytes in" << elapsedTime << "ms)"; + + sender.wait(); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QCOMPARE(reply->url(), request.url()); + QCOMPARE(reply->error(), QNetworkReply::NoError); + + QVERIFY(sender.transferRate != -1); + int minRate = rate * 1024 * 9 / 10; + int maxRate = rate * 1024 * 11 / 10; + QVERIFY(sender.transferRate >= minRate); + QVERIFY(sender.transferRate <= maxRate); +} + +void tst_QNetworkReply::downloadProgress_data() +{ + QTest::addColumn<int>("loopCount"); + + QTest::newRow("empty") << 0; + QTest::newRow("small") << 4; +#ifndef Q_OS_SYMBIAN + QTest::newRow("big") << 4096; +#else + // it can run even with 4096 + // but it takes lot time + //especially on emulator + QTest::newRow("big") << 1024; +#endif +} + +void tst_QNetworkReply::downloadProgress() +{ + QTcpServer server; + QVERIFY(server.listen()); + + QNetworkRequest request("debugpipe://127.0.0.1:" + QString::number(server.serverPort()) + "/?bare=1"); + QNetworkReplyPtr reply = manager.get(request); + QSignalSpy spy(reply, SIGNAL(downloadProgress(qint64,qint64))); + connect(reply, SIGNAL(downloadProgress(qint64,qint64)), + &QTestEventLoop::instance(), SLOT(exitLoop())); + QVERIFY(spy.isValid()); + QVERIFY(!reply->isFinished()); + QVERIFY(reply->isRunning()); + + QCoreApplication::instance()->processEvents(); + if (!server.hasPendingConnections()) + server.waitForNewConnection(1000); + QVERIFY(server.hasPendingConnections()); + QCOMPARE(spy.count(), 0); + + QByteArray data(128, 'a'); + QTcpSocket *sender = server.nextPendingConnection(); + QVERIFY(sender); + + QFETCH(int, loopCount); + for (int i = 1; i <= loopCount; ++i) { + sender->write(data); + QVERIFY2(sender->waitForBytesWritten(2000), "Network timeout"); + + spy.clear(); + QTestEventLoop::instance().enterLoop(2); + QVERIFY(!QTestEventLoop::instance().timeout()); + QVERIFY(spy.count() > 0); + QVERIFY(!reply->isFinished()); + QVERIFY(reply->isRunning()); + + QList<QVariant> args = spy.last(); + QCOMPARE(args.at(0).toInt(), i*data.size()); + QCOMPARE(args.at(1).toInt(), -1); + } + + // close the connection: + delete sender; + + spy.clear(); + QTestEventLoop::instance().enterLoop(2); + QCOMPARE(reply->error(), QNetworkReply::NoError); + QVERIFY(!QTestEventLoop::instance().timeout()); + QVERIFY(spy.count() > 0); + QVERIFY(!reply->isRunning()); + QVERIFY(reply->isFinished()); + + QList<QVariant> args = spy.last(); + QCOMPARE(args.at(0).toInt(), loopCount * data.size()); + QCOMPARE(args.at(1).toInt(), loopCount * data.size()); +} + +void tst_QNetworkReply::uploadProgress_data() +{ + putToFile_data(); +} + +void tst_QNetworkReply::uploadProgress() +{ + QFETCH(QByteArray, data); + QTcpServer server; + QVERIFY(server.listen()); + + QNetworkRequest request("debugpipe://127.0.0.1:" + QString::number(server.serverPort()) + "/?bare=1"); + QNetworkReplyPtr reply = manager.put(request, data); + QSignalSpy spy(reply, SIGNAL(uploadProgress(qint64,qint64))); + QSignalSpy finished(reply, SIGNAL(finished())); + QVERIFY(spy.isValid()); + QVERIFY(finished.isValid()); + + QCoreApplication::instance()->processEvents(); + if (!server.hasPendingConnections()) + server.waitForNewConnection(1000); + QVERIFY(server.hasPendingConnections()); + + QTcpSocket *receiver = server.nextPendingConnection(); + if (finished.count() == 0) { + // it's not finished yet, so wait for it to be + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(2); + QVERIFY(!QTestEventLoop::instance().timeout()); + } + delete receiver; + + QVERIFY(finished.count() > 0); + QVERIFY(spy.count() > 0); + + QList<QVariant> args = spy.last(); + QCOMPARE(args.at(0).toInt(), data.size()); + QCOMPARE(args.at(1).toInt(), data.size()); +} + +void tst_QNetworkReply::chaining_data() +{ + putToFile_data(); +} + +void tst_QNetworkReply::chaining() +{ + QTemporaryFile sourceFile(QDir::currentPath() + "/temp-XXXXXX"); + sourceFile.setAutoRemove(true); + QVERIFY(sourceFile.open()); + + QFETCH(QByteArray, data); + QVERIFY(sourceFile.write(data) == data.size()); + sourceFile.flush(); + QCOMPARE(sourceFile.size(), qint64(data.size())); + + QNetworkRequest request(QUrl::fromLocalFile(sourceFile.fileName())); + QNetworkReplyPtr getReply = manager.get(request); + + QFile targetFile(testFileName); + QUrl url = QUrl::fromLocalFile(targetFile.fileName()); + request.setUrl(url); + QNetworkReplyPtr putReply = manager.put(request, getReply); + + connect(putReply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QCOMPARE(getReply->url(), QUrl::fromLocalFile(sourceFile.fileName())); + QCOMPARE(getReply->error(), QNetworkReply::NoError); + QCOMPARE(getReply->header(QNetworkRequest::ContentLengthHeader).toLongLong(), sourceFile.size()); + + QCOMPARE(putReply->url(), url); + QCOMPARE(putReply->error(), QNetworkReply::NoError); + QCOMPARE(putReply->header(QNetworkRequest::ContentLengthHeader).toLongLong(), Q_INT64_C(0)); + QVERIFY(putReply->readAll().isEmpty()); + + QVERIFY(sourceFile.atEnd()); + sourceFile.seek(0); // reset it to the beginning + + QVERIFY(targetFile.open(QIODevice::ReadOnly)); + QCOMPARE(targetFile.size(), sourceFile.size()); + QCOMPARE(targetFile.readAll(), sourceFile.readAll()); +} + +void tst_QNetworkReply::receiveCookiesFromHttp_data() +{ + QTest::addColumn<QString>("cookieString"); + QTest::addColumn<QList<QNetworkCookie> >("expectedCookiesFromHttp"); + QTest::addColumn<QList<QNetworkCookie> >("expectedCookiesInJar"); + + QTest::newRow("empty") << "" << QList<QNetworkCookie>() << QList<QNetworkCookie>(); + + QList<QNetworkCookie> header, jar; + QNetworkCookie cookie("a", "b"); + header << cookie; + cookie.setDomain(QtNetworkSettings::serverName()); + cookie.setPath("/qtest/cgi-bin/"); + jar << cookie; + QTest::newRow("simple-cookie") << "a=b" << header << jar; + + header << QNetworkCookie("c", "d"); + cookie.setName("c"); + cookie.setValue("d"); + jar << cookie; + QTest::newRow("two-cookies") << "a=b, c=d" << header << jar; + QTest::newRow("two-cookies-2") << "a=b\nc=d" << header << jar; + + header.clear(); + jar.clear(); + cookie = QNetworkCookie("a", "b"); + cookie.setPath("/not/part-of-path"); + header << cookie; + cookie.setDomain(QtNetworkSettings::serverName()); + jar << cookie; + QTest::newRow("invalid-cookie-path") << "a=b; path=/not/part-of-path" << header << jar; + + jar.clear(); + cookie = QNetworkCookie("a", "b"); + cookie.setDomain(".example.com"); + header.clear(); + header << cookie; + QTest::newRow("invalid-cookie-domain") << "a=b; domain=.example.com" << header << jar; +} + +void tst_QNetworkReply::receiveCookiesFromHttp() +{ + QFETCH(QString, cookieString); + + QByteArray data = cookieString.toLatin1() + '\n'; + QUrl url("http://" + QtNetworkSettings::serverName() + "/qtest/cgi-bin/set-cookie.cgi"); + QNetworkRequest request(url); + request.setRawHeader("Content-Type", "application/octet-stream"); + QNetworkReplyPtr reply; + RUN_REQUEST(runSimpleRequest(QNetworkAccessManager::PostOperation, request, reply, data)); + + QCOMPARE(reply->url(), url); + QCOMPARE(reply->error(), QNetworkReply::NoError); + + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); // 200 Ok + + QList<QNetworkCookie> setCookies = + qvariant_cast<QList<QNetworkCookie> >(reply->header(QNetworkRequest::SetCookieHeader)); + QTEST(setCookies, "expectedCookiesFromHttp"); + QTEST(cookieJar->allCookies(), "expectedCookiesInJar"); +} + +void tst_QNetworkReply::receiveCookiesFromHttpSynchronous_data() +{ + tst_QNetworkReply::receiveCookiesFromHttp_data(); +} + +void tst_QNetworkReply::receiveCookiesFromHttpSynchronous() +{ + QFETCH(QString, cookieString); + + QByteArray data = cookieString.toLatin1() + '\n'; + QUrl url("http://" + QtNetworkSettings::serverName() + "/qtest/cgi-bin/set-cookie.cgi"); + + QNetworkRequest request(url); + request.setRawHeader("Content-Type", "application/octet-stream"); + request.setAttribute( + QNetworkRequest::SynchronousRequestAttribute, + true); + + QNetworkReplyPtr reply; + RUN_REQUEST(runSimpleRequest(QNetworkAccessManager::PostOperation, request, reply, data)); + + QCOMPARE(reply->url(), url); + QCOMPARE(reply->error(), QNetworkReply::NoError); + + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); // 200 Ok + + QList<QNetworkCookie> setCookies = + qvariant_cast<QList<QNetworkCookie> >(reply->header(QNetworkRequest::SetCookieHeader)); + QTEST(setCookies, "expectedCookiesFromHttp"); + QTEST(cookieJar->allCookies(), "expectedCookiesInJar"); +} + +void tst_QNetworkReply::sendCookies_data() +{ + QTest::addColumn<QList<QNetworkCookie> >("cookiesToSet"); + QTest::addColumn<QString>("expectedCookieString"); + + QList<QNetworkCookie> list; + QTest::newRow("empty") << list << ""; + + QNetworkCookie cookie("a", "b"); + cookie.setPath("/"); + cookie.setDomain("example.com"); + list << cookie; + QTest::newRow("no-match-domain") << list << ""; + + cookie.setDomain(QtNetworkSettings::serverName()); + cookie.setPath("/something/else"); + list << cookie; + QTest::newRow("no-match-path") << list << ""; + + cookie.setPath("/"); + list << cookie; + QTest::newRow("simple-cookie") << list << "a=b"; + + cookie.setPath("/qtest"); + cookie.setValue("longer"); + list << cookie; + QTest::newRow("two-cookies") << list << "a=longer; a=b"; + + list.clear(); + cookie = QNetworkCookie("a", "b"); + cookie.setPath("/"); + cookie.setDomain("." + QtNetworkSettings::serverDomainName()); + list << cookie; + QTest::newRow("domain-match") << list << "a=b"; + + // but it shouldn't match this: + cookie.setDomain(QtNetworkSettings::serverDomainName()); + list << cookie; + QTest::newRow("domain-match-2") << list << "a=b"; +} + +void tst_QNetworkReply::sendCookies() +{ + QFETCH(QString, expectedCookieString); + QFETCH(QList<QNetworkCookie>, cookiesToSet); + cookieJar->setAllCookies(cookiesToSet); + + QUrl url("http://" + QtNetworkSettings::serverName() + "/qtest/cgi-bin/get-cookie.cgi"); + QNetworkRequest request(url); + QNetworkReplyPtr reply; + RUN_REQUEST(runSimpleRequest(QNetworkAccessManager::GetOperation, request, reply)); + + QCOMPARE(reply->url(), url); + QCOMPARE(reply->error(), QNetworkReply::NoError); + + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); // 200 Ok + + QCOMPARE(QString::fromLatin1(reply->readAll()).trimmed(), expectedCookieString); +} + +void tst_QNetworkReply::sendCookiesSynchronous_data() +{ + tst_QNetworkReply::sendCookies_data(); +} + +void tst_QNetworkReply::sendCookiesSynchronous() +{ + QFETCH(QString, expectedCookieString); + QFETCH(QList<QNetworkCookie>, cookiesToSet); + cookieJar->setAllCookies(cookiesToSet); + + QUrl url("http://" + QtNetworkSettings::serverName() + "/qtest/cgi-bin/get-cookie.cgi"); + QNetworkRequest request(url); + + request.setAttribute( + QNetworkRequest::SynchronousRequestAttribute, + true); + + QNetworkReplyPtr reply; + RUN_REQUEST(runSimpleRequest(QNetworkAccessManager::GetOperation, request, reply)); + + QCOMPARE(reply->url(), url); + QCOMPARE(reply->error(), QNetworkReply::NoError); + + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); // 200 Ok + + QCOMPARE(QString::fromLatin1(reply->readAll()).trimmed(), expectedCookieString); +} + +void tst_QNetworkReply::nestedEventLoops_slot() +{ + QEventLoop subloop; + + // 16 seconds: fluke times out in 15 seconds, which triggers a QTcpSocket error + QTimer::singleShot(16000, &subloop, SLOT(quit())); + subloop.exec(); + + QTestEventLoop::instance().exitLoop(); +} + +void tst_QNetworkReply::nestedEventLoops() +{ + // Slightly fragile test, it may not be testing anything + // This is certifying that we're not running into the same issue + // that QHttp had (task 200432): the QTcpSocket connection is + // closed by the remote end because of the kept-alive HTTP + // connection timed out. + // + // The exact time required for this to happen is not exactly + // defined. Our server (Apache httpd) times out after 15 + // seconds. (see above) + + qDebug("Takes 16 seconds to run, please wait"); + qRegisterMetaType<QNetworkReply::NetworkError>(); + + QUrl url("http://" + QtNetworkSettings::serverName()); + QNetworkRequest request(url); + QNetworkReplyPtr reply = manager.get(request); + + QSignalSpy finishedspy(reply, SIGNAL(finished())); + QSignalSpy errorspy(reply, SIGNAL(error(QNetworkReply::NetworkError))); + + connect(reply, SIGNAL(finished()), SLOT(nestedEventLoops_slot())); + QTestEventLoop::instance().enterLoop(20); + QVERIFY2(!QTestEventLoop::instance().timeout(), "Network timeout"); + + QCOMPARE(finishedspy.count(), 1); + QCOMPARE(errorspy.count(), 0); +} + +void tst_QNetworkReply::httpProxyCommands_data() +{ + QTest::addColumn<QUrl>("url"); + QTest::addColumn<QByteArray>("responseToSend"); + QTest::addColumn<QString>("expectedCommand"); + + QTest::newRow("http") + << QUrl("http://0.0.0.0:4443/http-request") + << QByteArray("HTTP/1.0 200 OK\r\nProxy-Connection: close\r\nContent-Length: 1\r\n\r\n1") + << "GET http://0.0.0.0:4443/http-request HTTP/1."; +#ifndef QT_NO_OPENSSL + QTest::newRow("https") + << QUrl("https://0.0.0.0:4443/https-request") + << QByteArray("HTTP/1.0 200 Connection Established\r\n\r\n") + << "CONNECT 0.0.0.0:4443 HTTP/1."; +#endif +} + +void tst_QNetworkReply::httpProxyCommands() +{ + QFETCH(QUrl, url); + QFETCH(QByteArray, responseToSend); + QFETCH(QString, expectedCommand); + + MiniHttpServer proxyServer(responseToSend); + QNetworkProxy proxy(QNetworkProxy::HttpProxy, "127.0.0.1", proxyServer.serverPort()); + + manager.setProxy(proxy); + QNetworkReplyPtr reply = manager.get(QNetworkRequest(url)); + manager.setProxy(QNetworkProxy()); + + // wait for the finished signal + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + + QTestEventLoop::instance().enterLoop(1); + + QVERIFY(!QTestEventLoop::instance().timeout()); + + //qDebug() << reply->error() << reply->errorString(); + + // we don't really care if the request succeeded + // especially since it won't succeed in the HTTPS case + // so just check that the command was correct + + QString receivedHeader = proxyServer.receivedData.left(expectedCommand.length()); + QCOMPARE(receivedHeader, expectedCommand); +} + +class ProxyChangeHelper : public QObject { + Q_OBJECT +public: + ProxyChangeHelper() : QObject(), signalCount(0) {}; +public slots: + void finishedSlot() { + signalCount++; + if (signalCount == 2) + QMetaObject::invokeMethod(&QTestEventLoop::instance(), "exitLoop", Qt::QueuedConnection); + } +private: + int signalCount; +}; + +void tst_QNetworkReply::httpProxyCommandsSynchronous_data() +{ + httpProxyCommands_data(); +} + +struct QThreadCleanup +{ + static inline void cleanup(QThread *thread) + { + thread->quit(); + if (thread->wait(3000)) + delete thread; + else + qWarning("thread hung, leaking memory so test can finish"); + } +}; + +struct QDeleteLaterCleanup +{ + static inline void cleanup(QObject *o) + { + o->deleteLater(); + } +}; + +void tst_QNetworkReply::httpProxyCommandsSynchronous() +{ + QFETCH(QUrl, url); + QFETCH(QByteArray, responseToSend); + QFETCH(QString, expectedCommand); + + // when using synchronous commands, we need a different event loop for + // the server thread, because the client is never returning to the + // event loop + QScopedPointer<QThread, QThreadCleanup> serverThread(new QThread); + QScopedPointer<MiniHttpServer, QDeleteLaterCleanup> proxyServer(new MiniHttpServer(responseToSend, false, serverThread.data())); + QNetworkProxy proxy(QNetworkProxy::HttpProxy, "127.0.0.1", proxyServer->serverPort()); + + manager.setProxy(proxy); + QNetworkRequest request(url); + + // send synchronous request + request.setAttribute( + QNetworkRequest::SynchronousRequestAttribute, + true); + + QNetworkReplyPtr reply = manager.get(request); + QVERIFY(reply->isFinished()); // synchronous + manager.setProxy(QNetworkProxy()); + + //qDebug() << reply->error() << reply->errorString(); + + // we don't really care if the request succeeded + // especially since it won't succeed in the HTTPS case + // so just check that the command was correct + + QString receivedHeader = proxyServer->receivedData.left(expectedCommand.length()); + QCOMPARE(receivedHeader, expectedCommand); +} + +void tst_QNetworkReply::proxyChange() +{ + ProxyChangeHelper helper; + MiniHttpServer proxyServer( + "HTTP/1.0 200 OK\r\nProxy-Connection: keep-alive\r\n" + "Content-Length: 1\r\n\r\n1"); + QNetworkProxy dummyProxy(QNetworkProxy::HttpProxy, "127.0.0.1", proxyServer.serverPort()); + QNetworkRequest req(QUrl("http://" + QtNetworkSettings::serverName())); + proxyServer.doClose = false; + + manager.setProxy(dummyProxy); + QNetworkReplyPtr reply1 = manager.get(req); + connect(reply1, SIGNAL(finished()), &helper, SLOT(finishedSlot())); + + manager.setProxy(QNetworkProxy()); + QNetworkReplyPtr reply2 = manager.get(req); + connect(reply2, SIGNAL(finished()), &helper, SLOT(finishedSlot())); + + QTestEventLoop::instance().enterLoop(20); + QVERIFY(!QTestEventLoop::instance().timeout()); + + // verify that the replies succeeded + QCOMPARE(reply1->error(), QNetworkReply::NoError); + QCOMPARE(reply1->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); + QVERIFY(reply1->size() == 1); + + QCOMPARE(reply2->error(), QNetworkReply::NoError); + QCOMPARE(reply2->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); + QVERIFY(reply2->size() > 1); + + // now try again and get an error + // this verifies that we reuse the already-open connection + + proxyServer.doClose = true; + proxyServer.dataToTransmit = + "HTTP/1.0 403 Forbidden\r\nProxy-Connection: close\r\n" + "Content-Length: 1\r\n\r\n1"; + + manager.setProxy(dummyProxy); + QNetworkReplyPtr reply3 = manager.get(req); + connect(reply3, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(5); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QVERIFY(int(reply3->error()) > 0); +} + +void tst_QNetworkReply::authorizationError_data() +{ + + QTest::addColumn<QString>("url"); + QTest::addColumn<int>("errorSignalCount"); + QTest::addColumn<int>("finishedSignalCount"); + QTest::addColumn<int>("error"); + QTest::addColumn<int>("httpStatusCode"); + QTest::addColumn<QString>("httpBody"); + + QTest::newRow("unknown-authorization-method") << "http://" + QtNetworkSettings::serverName() + + "/qtest/cgi-bin/http-unknown-authentication-method.cgi?401-authorization-required" << 1 << 1 + << int(QNetworkReply::AuthenticationRequiredError) << 401 << "authorization required"; + QTest::newRow("unknown-proxy-authorization-method") << "http://" + QtNetworkSettings::serverName() + + "/qtest/cgi-bin/http-unknown-authentication-method.cgi?407-proxy-authorization-required" << 1 << 1 + << int(QNetworkReply::ProxyAuthenticationRequiredError) << 407 + << "authorization required"; +} + +void tst_QNetworkReply::authorizationError() +{ + QFETCH(QString, url); + QNetworkRequest request(url); + QNetworkReplyPtr reply = manager.get(request); + + QCOMPARE(reply->error(), QNetworkReply::NoError); + + qRegisterMetaType<QNetworkReply::NetworkError>("QNetworkReply::NetworkError"); + QSignalSpy errorSpy(reply, SIGNAL(error(QNetworkReply::NetworkError))); + QSignalSpy finishedSpy(reply, SIGNAL(finished())); + // now run the request: + connect(reply, SIGNAL(finished()), + &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QFETCH(int, errorSignalCount); + QCOMPARE(errorSpy.count(), errorSignalCount); + QFETCH(int, finishedSignalCount); + QCOMPARE(finishedSpy.count(), finishedSignalCount); + QFETCH(int, error); + QCOMPARE(reply->error(), QNetworkReply::NetworkError(error)); + + QFETCH(int, httpStatusCode); + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), httpStatusCode); + + QFETCH(QString, httpBody); + QCOMPARE(qint64(reply->size()), qint64(httpBody.size())); + QCOMPARE(QString(reply->readAll()), httpBody); +} + +void tst_QNetworkReply::httpConnectionCount() +{ + QTcpServer server; + QVERIFY(server.listen()); + QCoreApplication::instance()->processEvents(); + + for (int i = 0; i < 10; i++) { + QNetworkRequest request (QUrl("http://127.0.0.1:" + QString::number(server.serverPort()) + "/" + QString::number(i))); + QNetworkReply* reply = manager.get(request); + reply->setParent(&server); + } + + int pendingConnectionCount = 0; + QTime time; + time.start(); + + while(pendingConnectionCount <= 20) { + QTestEventLoop::instance().enterLoop(1); + QTcpSocket *socket = server.nextPendingConnection(); + while (socket != 0) { + pendingConnectionCount++; + socket->setParent(&server); + socket = server.nextPendingConnection(); + } + + // at max. wait 10 sec + if (time.elapsed() > 10000) + break; + } + +#ifdef Q_OS_SYMBIAN + // see in qhttpnetworkconnection.cpp + // hardcoded defaultChannelCount = 3 + QCOMPARE(pendingConnectionCount, 3); +#else + QCOMPARE(pendingConnectionCount, 6); +#endif +} + +void tst_QNetworkReply::httpReUsingConnectionSequential_data() +{ + QTest::addColumn<bool>("doDeleteLater"); + QTest::newRow("deleteLater") << true; + QTest::newRow("noDeleteLater") << false; +} + +void tst_QNetworkReply::httpReUsingConnectionSequential() +{ + QFETCH(bool, doDeleteLater); + + QByteArray response("HTTP/1.1 200 OK\r\nContent-Length: 0\r\n\r\n"); + MiniHttpServer server(response); + server.multiple = true; + server.doClose = false; + + QUrl url; + url.setScheme("http"); + url.setPort(server.serverPort()); + url.setHost("127.0.0.1"); + // first request + QNetworkReply* reply1 = manager.get(QNetworkRequest(url)); + connect(reply1, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(2); + QVERIFY(!QTestEventLoop::instance().timeout()); + QVERIFY(!reply1->error()); + int reply1port = server.client->peerPort(); + + if (doDeleteLater) + reply1->deleteLater(); + + // finished received, send the next one + QNetworkReply*reply2 = manager.get(QNetworkRequest(url)); + connect(reply2, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(2); + QVERIFY(!QTestEventLoop::instance().timeout()); + QVERIFY(!reply2->error()); + int reply2port = server.client->peerPort(); // should still be the same object + + QVERIFY(reply1port > 0); + QCOMPARE(server.totalConnections, 1); + QCOMPARE(reply2port, reply1port); + + if (!doDeleteLater) + reply1->deleteLater(); // only do it if it was not done earlier + reply2->deleteLater(); +} + +class HttpReUsingConnectionFromFinishedSlot : public QObject { + Q_OBJECT +public: + QNetworkReply* reply1; + QNetworkReply* reply2; + QUrl url; + QNetworkAccessManager manager; +public slots: + void finishedSlot() { + QVERIFY(!reply1->error()); + + QFETCH(bool, doDeleteLater); + if (doDeleteLater) { + reply1->deleteLater(); + reply1 = 0; + } + + // kick off 2nd request and exit the loop when it is done + reply2 = manager.get(QNetworkRequest(url)); + reply2->setParent(this); + connect(reply2, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + } +}; + +void tst_QNetworkReply::httpReUsingConnectionFromFinishedSlot_data() +{ + httpReUsingConnectionSequential_data(); +} + +void tst_QNetworkReply::httpReUsingConnectionFromFinishedSlot() +{ + QByteArray response("HTTP/1.1 200 OK\r\nContent-Length: 0\r\n\r\n"); + MiniHttpServer server(response); + server.multiple = true; + server.doClose = false; + + HttpReUsingConnectionFromFinishedSlot helper; + helper.reply1 = 0; + helper.reply2 = 0; + helper.url.setScheme("http"); + helper.url.setPort(server.serverPort()); + helper.url.setHost("127.0.0.1"); + + // first request + helper.reply1 = helper.manager.get(QNetworkRequest(helper.url)); + helper.reply1->setParent(&helper); + connect(helper.reply1, SIGNAL(finished()), &helper, SLOT(finishedSlot())); + QTestEventLoop::instance().enterLoop(4); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QVERIFY(helper.reply2); + QVERIFY(!helper.reply2->error()); + + QCOMPARE(server.totalConnections, 1); +} + +class HttpRecursiveCreationHelper : public QObject { + Q_OBJECT +public: + + HttpRecursiveCreationHelper(): + QObject(0), + requestsStartedCount_finished(0), + requestsStartedCount_readyRead(0), + requestsFinishedCount(0) + { + } + QNetworkAccessManager manager; + int requestsStartedCount_finished; + int requestsStartedCount_readyRead; + int requestsFinishedCount; +public slots: + void finishedSlot() { + requestsFinishedCount++; + + QNetworkReply *reply = qobject_cast<QNetworkReply*>(sender()); + QVERIFY(!reply->error()); + QVERIFY(reply->bytesAvailable() == 27906); + + if (requestsFinishedCount == 60) { + QTestEventLoop::instance().exitLoop(); + return; + } + + if (requestsStartedCount_finished < 30) { + startOne(); + requestsStartedCount_finished++; + } + + reply->deleteLater(); + } + void readyReadSlot() { + QNetworkReply *reply = qobject_cast<QNetworkReply*>(sender()); + QVERIFY(!reply->error()); + + if (requestsStartedCount_readyRead < 30 && reply->bytesAvailable() > 27906/2) { + startOne(); + requestsStartedCount_readyRead++; + } + } + void startOne() { + QUrl url = "http://" + QtNetworkSettings::serverName() + "/qtest/fluke.gif"; + QNetworkRequest request(url); + QNetworkReply *reply = manager.get(request); + reply->setParent(this); + connect(reply, SIGNAL(finished()), this, SLOT(finishedSlot())); + connect(reply, SIGNAL(readyRead()), this, SLOT(readyReadSlot())); + } +}; + +void tst_QNetworkReply::httpRecursiveCreation() +{ + // this test checks if creation of new requests to the same host properly works + // from readyRead() and finished() signals + HttpRecursiveCreationHelper helper; + helper.startOne(); + QTestEventLoop::instance().enterLoop(30); + QVERIFY(!QTestEventLoop::instance().timeout()); +} + +#ifndef QT_NO_OPENSSL +void tst_QNetworkReply::ignoreSslErrorsList_data() +{ + QTest::addColumn<QString>("url"); + QTest::addColumn<QList<QSslError> >("expectedSslErrors"); + QTest::addColumn<QNetworkReply::NetworkError>("expectedNetworkError"); + + QList<QSslError> expectedSslErrors; + // apparently, because of some weird behaviour of SRCDIR, the file name below needs to start with a slash + QList<QSslCertificate> certs = QSslCertificate::fromPath(QLatin1String(SRCDIR "/certs/qt-test-server-cacert.pem")); + QSslError rightError(QSslError::SelfSignedCertificate, certs.at(0)); + QSslError wrongError(QSslError::SelfSignedCertificate); + + QTest::newRow("SSL-failure-empty-list") << "https://" + QtNetworkSettings::serverName() + "/index.html" << expectedSslErrors << QNetworkReply::SslHandshakeFailedError; + expectedSslErrors.append(wrongError); + QTest::newRow("SSL-failure-wrong-error") << "https://" + QtNetworkSettings::serverName() + "/index.html" << expectedSslErrors << QNetworkReply::SslHandshakeFailedError; + expectedSslErrors.append(rightError); + QTest::newRow("allErrorsInExpectedList1") << "https://" + QtNetworkSettings::serverName() + "/index.html" << expectedSslErrors << QNetworkReply::NoError; + expectedSslErrors.removeAll(wrongError); + QTest::newRow("allErrorsInExpectedList2") << "https://" + QtNetworkSettings::serverName() + "/index.html" << expectedSslErrors << QNetworkReply::NoError; + expectedSslErrors.removeAll(rightError); + QTest::newRow("SSL-failure-empty-list-again") << "https://" + QtNetworkSettings::serverName() + "/index.html" << expectedSslErrors << QNetworkReply::SslHandshakeFailedError; +} + +void tst_QNetworkReply::ignoreSslErrorsList() +{ + QFETCH(QString, url); + QNetworkRequest request(url); + QNetworkReplyPtr reply = manager.get(request); + + QFETCH(QList<QSslError>, expectedSslErrors); + reply->ignoreSslErrors(expectedSslErrors); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QFETCH(QNetworkReply::NetworkError, expectedNetworkError); + QCOMPARE(reply->error(), expectedNetworkError); +} + +void tst_QNetworkReply::ignoreSslErrorsListWithSlot_data() +{ + ignoreSslErrorsList_data(); +} + +// this is not a test, just a slot called in the test below +void tst_QNetworkReply::ignoreSslErrorListSlot(QNetworkReply *reply, const QList<QSslError> &) +{ + reply->ignoreSslErrors(storedExpectedSslErrors); +} + +// do the same as in ignoreSslErrorsList, but ignore the errors in the slot +void tst_QNetworkReply::ignoreSslErrorsListWithSlot() +{ + QFETCH(QString, url); + QNetworkRequest request(url); + QNetworkReplyPtr reply = manager.get(request); + + QFETCH(QList<QSslError>, expectedSslErrors); + // store the errors to ignore them later in the slot connected below + storedExpectedSslErrors = expectedSslErrors; + connect(&manager, SIGNAL(sslErrors(QNetworkReply *, const QList<QSslError> &)), + this, SLOT(ignoreSslErrorListSlot(QNetworkReply *, const QList<QSslError> &))); + + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QFETCH(QNetworkReply::NetworkError, expectedNetworkError); + QCOMPARE(reply->error(), expectedNetworkError); +} + +void tst_QNetworkReply::sslConfiguration_data() +{ + QTest::addColumn<QSslConfiguration>("configuration"); + QTest::addColumn<bool>("works"); + + QTest::newRow("empty") << QSslConfiguration() << false; + QSslConfiguration conf = QSslConfiguration::defaultConfiguration(); + QTest::newRow("default") << conf << false; // does not contain test server cert + QList<QSslCertificate> testServerCert = QSslCertificate::fromPath(SRCDIR "/certs/qt-test-server-cacert.pem"); + conf.setCaCertificates(testServerCert); + QTest::newRow("set-root-cert") << conf << true; + conf.setProtocol(QSsl::SecureProtocols); + QTest::newRow("secure") << conf << true; +} + +void tst_QNetworkReply::sslConfiguration() +{ + QNetworkRequest request(QUrl("https://" + QtNetworkSettings::serverName() + "/index.html")); + QFETCH(QSslConfiguration, configuration); + request.setSslConfiguration(configuration); + QNetworkReplyPtr reply = manager.get(request); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QFETCH(bool, works); + QNetworkReply::NetworkError expectedError = works ? QNetworkReply::NoError : QNetworkReply::SslHandshakeFailedError; + QCOMPARE(reply->error(), expectedError); +} + +#endif // QT_NO_OPENSSL + +void tst_QNetworkReply::getAndThenDeleteObject_data() +{ + QTest::addColumn<bool>("replyFirst"); + + QTest::newRow("delete-reply-first") << true; + QTest::newRow("delete-qnam-first") << false; +} + +void tst_QNetworkReply::getAndThenDeleteObject() +{ + // yes, this will leak if the testcase fails. I don't care. It must not fail then :P + QNetworkAccessManager *manager = new QNetworkAccessManager(); + QNetworkRequest request("http://" + QtNetworkSettings::serverName() + "/qtest/bigfile"); + QNetworkReply *reply = manager->get(request); + reply->setReadBufferSize(1); + reply->setParent((QObject*)0); // must be 0 because else it is the manager + + QTime stopWatch; + stopWatch.start(); + forever { + QCoreApplication::instance()->processEvents(); + if (reply->bytesAvailable()) + break; + if (stopWatch.elapsed() >= 30000) + break; + } + + QVERIFY(reply->bytesAvailable()); + QCOMPARE(reply->attribute(QNetworkRequest::HttpStatusCodeAttribute).toInt(), 200); + QVERIFY(!reply->isFinished()); // must not be finished + + QFETCH(bool, replyFirst); + + if (replyFirst) { + delete reply; + delete manager; + } else { + delete manager; + delete reply; + } +} + +// see https://bugs.webkit.org/show_bug.cgi?id=38935 +void tst_QNetworkReply::symbianOpenCDataUrlCrash() +{ + QString requestUrl("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABkAAAAWCAYAAAA1vze2AAAAB3RJTUUH2AUSEgolrgBvVQAAAAlwSFlzAAALEwAACxMBAJqcGAAAAARnQU1BAACxjwv8YQUAAAHlSURBVHja5VbNShxBEK6ZaXtnHTebQPA1gngNmfaeq+QNPIlIXkC9iQdJxJNvEHLN3VkxhxxE8gTmEhAVddXZ6Z3f9Ndriz89/sHmkBQUVVT1fB9d9c3uOERUKTunIdn3HzstxGpYBDS4wZk7TAJj/wlJ90J+jnuygqs8svSj+/rGHBos3rE18XBvfU3no7NzlJfUaY/5whAwl8Lr/WDUv4ODxTMb+P5xLExe5LmO559WqTX/MQR4WZYEAtSePS4pE0qSnuhnRUcBU5Gm2k9XljU4Z26I3NRxBrd80rj2fh+KNE0FY4xevRgTjREvPFpasAK8Xli6MUbbuKw3afAGgSBXozo5u4hkmncAlkl5wx8iMGbdyQjnCFEiEwGiosj1UQA/x2rVddiVoi+l4IxE0PTDnx+mrQBvvnx9cFz3krhVvuhzFn579/aq/n5rW8fbtTqiWhIQZEo17YBvbkxOXNVndnYpTvod7AtiuN2re0+siwcB9oH8VxxrNwQQAhzyRs30n7wTI2HIN2g2QtQwjjhJIQatOq7E8bIVCLwzpl83Lvtvl+NohWWlE8UZTWEMAGCcR77fHKhPnZF5tYie6dfdxCphACmLPM+j8bYfmTryg64kV9Vh3mV8jP0b/4wO/YUPiT/8i0MLf55lSQAAAABJRU5ErkJggg=="); + QUrl url = QUrl::fromEncoded(requestUrl.toLatin1()); + QNetworkRequest req(url); + QNetworkReplyPtr reply; + + RUN_REQUEST(runSimpleRequest(QNetworkAccessManager::GetOperation, req, reply)); + + QCOMPARE(reply->url(), url); + QCOMPARE(reply->error(), QNetworkReply::NoError); + + QCOMPARE(reply->header(QNetworkRequest::ContentLengthHeader).toLongLong(), qint64(598)); +} + +void tst_QNetworkReply::getFromHttpIntoBuffer_data() +{ + QTest::addColumn<QUrl>("url"); + + QTest::newRow("rfc-internal") << QUrl("http://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt"); +} + +// Please note that the whole "zero copy" download buffer API is private right now. Do not use it. +void tst_QNetworkReply::getFromHttpIntoBuffer() +{ + QFETCH(QUrl, url); + QNetworkRequest request(url); + request.setAttribute(QNetworkRequest::MaximumDownloadBufferSizeAttribute, 1024*128); // 128 kB + + QNetworkAccessManager manager; + QNetworkReply *reply = manager.get(request); + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + QVERIFY(reply->isFinished()); + + QFile reference(SRCDIR "/rfc3252.txt"); + QVERIFY(reference.open(QIODevice::ReadOnly)); + + QCOMPARE(reference.bytesAvailable(), reply->bytesAvailable()); + QCOMPARE(reference.size(), reply->size()); + + // Compare the memory buffer + QVariant downloadBufferAttribute = reply->attribute(QNetworkRequest::DownloadBufferAttribute); + QVERIFY(downloadBufferAttribute.isValid()); + QSharedPointer<char> sharedPointer = downloadBufferAttribute.value<QSharedPointer<char> >(); + bool memoryComparison = + (0 == memcmp(static_cast<void*>(reference.readAll().data()), + sharedPointer.data(), reference.size())); + QVERIFY(memoryComparison); + + // Make sure the normal reading works + reference.seek(0); + QCOMPARE(reply->read(42), reference.read(42)); + QCOMPARE(reply->getChar(0), reference.getChar(0)); + QCOMPARE(reply->peek(23), reference.peek(23)); + QCOMPARE(reply->readLine(), reference.readLine()); + QCOMPARE(reference.bytesAvailable(), reply->bytesAvailable()); + QCOMPARE(reply->readAll(), reference.readAll()); + QVERIFY(reply->atEnd()); +} + +// FIXME we really need to consolidate all those server implementations +class GetFromHttpIntoBuffer2Server : QObject { + Q_OBJECT + qint64 dataSize; + qint64 dataSent; + QTcpServer server; + QTcpSocket *client; + bool serverSendsContentLength; + bool chunkedEncoding; + +public: + GetFromHttpIntoBuffer2Server (qint64 ds, bool sscl, bool ce) : dataSize(ds), dataSent(0), + client(0), serverSendsContentLength(sscl), chunkedEncoding(ce) { + server.listen(); + connect(&server, SIGNAL(newConnection()), this, SLOT(newConnectionSlot())); + } + + int serverPort() { + return server.serverPort(); + } + +public slots: + + void newConnectionSlot() { + client = server.nextPendingConnection(); + client->setParent(this); + connect(client, SIGNAL(readyRead()), this, SLOT(readyReadSlot())); + connect(client, SIGNAL(bytesWritten(qint64)), this, SLOT(bytesWrittenSlot(qint64))); + } + + void readyReadSlot() { + client->readAll(); + client->write("HTTP/1.0 200 OK\n"); + if (serverSendsContentLength) + client->write(QString("Content-Length: " + QString::number(dataSize) + "\n").toAscii()); + if (chunkedEncoding) + client->write(QString("Transfer-Encoding: chunked\n").toAscii()); + client->write("Connection: close\n\n"); + } + + void bytesWrittenSlot(qint64 amount) { + Q_UNUSED(amount); + if (dataSent == dataSize && client) { + // close eventually + + // chunked encoding: we have to send a last "empty" chunk + if (chunkedEncoding) + client->write(QString("0\r\n\r\n").toAscii()); + + client->disconnectFromHost(); + server.close(); + client = 0; + return; + } + + // send data + if (client && client->bytesToWrite() < 100*1024 && dataSent < dataSize) { + qint64 amount = qMin(qint64(16*1024), dataSize - dataSent); + QByteArray data(amount, '@'); + + if (chunkedEncoding) { + client->write(QString(QString("%1").arg(amount,0,16).toUpper() + "\r\n").toAscii()); + client->write(data.constData(), amount); + client->write(QString("\r\n").toAscii()); + } else { + client->write(data.constData(), amount); + } + + dataSent += amount; + } + } +}; + +class GetFromHttpIntoBuffer2Client : QObject { + Q_OBJECT +private: + bool useDownloadBuffer; + QNetworkReply *reply; + qint64 uploadSize; + QList<qint64> bytesAvailableList; +public: + GetFromHttpIntoBuffer2Client (QNetworkReply *reply, bool useDownloadBuffer, qint64 uploadSize) + : useDownloadBuffer(useDownloadBuffer), reply(reply), uploadSize(uploadSize) + { + connect(reply, SIGNAL(metaDataChanged()), this, SLOT(metaDataChangedSlot())); + connect(reply, SIGNAL(readyRead()), this, SLOT(readyReadSlot())); + connect(reply, SIGNAL(finished()), this, SLOT(finishedSlot())); + } + + public slots: + void metaDataChangedSlot() { + if (useDownloadBuffer) { + QSharedPointer<char> sharedPointer = qvariant_cast<QSharedPointer<char> >(reply->attribute(QNetworkRequest::DownloadBufferAttribute)); + QVERIFY(!sharedPointer.isNull()); // It will be 0 if it failed + } + + // metaDataChanged needs to come before everything else + QVERIFY(bytesAvailableList.isEmpty()); + } + + void readyReadSlot() { + QVERIFY(!reply->isFinished()); + + qint64 bytesAvailable = reply->bytesAvailable(); + + // bytesAvailable must never be 0 + QVERIFY(bytesAvailable != 0); + + if (bytesAvailableList.length() < 5) { + // We assume that the first few times the bytes available must be less than the complete size, e.g. + // the bytesAvailable() function works correctly in case of a downloadBuffer. + QVERIFY(bytesAvailable < uploadSize); + } + if (!bytesAvailableList.isEmpty()) { + // Also check that the same bytesAvailable is not coming twice in a row + QVERIFY(bytesAvailableList.last() != bytesAvailable); + } + + bytesAvailableList.append(bytesAvailable); + // Add bytesAvailable to a list an parse + } + + void finishedSlot() { + // We should have already received all readyRead + QVERIFY(!bytesAvailableList.isEmpty()); + QVERIFY(bytesAvailableList.last() == uploadSize); + } +}; + +void tst_QNetworkReply::getFromHttpIntoBuffer2_data() +{ + QTest::addColumn<bool>("useDownloadBuffer"); + + QTest::newRow("use-download-buffer") << true; + QTest::newRow("do-not-use-download-buffer") << false; +} + +// This test checks mostly that signal emissions are in correct order +// Please note that the whole "zero copy" download buffer API is private right now. Do not use it. +void tst_QNetworkReply::getFromHttpIntoBuffer2() +{ + QFETCH(bool, useDownloadBuffer); + + // On my Linux Desktop the results are already visible with 128 kB, however we use this to have good results. +#if defined(Q_OS_SYMBIAN) || defined(Q_WS_WINCE_WM) + // Show some mercy to non-desktop platform/s + enum {UploadSize = 4*1024*1024}; // 4 MB +#else + enum {UploadSize = 32*1024*1024}; // 32 MB +#endif + + GetFromHttpIntoBuffer2Server server(UploadSize, true, false); + + QNetworkRequest request(QUrl("http://127.0.0.1:" + QString::number(server.serverPort()) + "/?bare=1")); + if (useDownloadBuffer) + request.setAttribute(QNetworkRequest::MaximumDownloadBufferSizeAttribute, 1024*1024*128); // 128 MB is max allowed + + QNetworkAccessManager manager; + QNetworkReplyPtr reply = manager.get(request); + + GetFromHttpIntoBuffer2Client client(reply, useDownloadBuffer, UploadSize); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop()), Qt::QueuedConnection); + QTestEventLoop::instance().enterLoop(40); + QCOMPARE(reply->error(), QNetworkReply::NoError); + QVERIFY(!QTestEventLoop::instance().timeout()); +} + + +// Is handled somewhere else too, introduced this special test to have it more accessible +void tst_QNetworkReply::ioGetFromHttpWithoutContentLength() +{ + QByteArray dataToSend("HTTP/1.0 200 OK\r\n\r\nHALLO! 123!"); + MiniHttpServer server(dataToSend); + server.doClose = true; + + QNetworkRequest request(QUrl("http://localhost:" + QString::number(server.serverPort()))); + QNetworkReplyPtr reply = manager.get(request); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QCOMPARE(reply->url(), request.url()); + QVERIFY(reply->isFinished()); + QVERIFY(reply->error() == QNetworkReply::NoError); +} + +// Is handled somewhere else too, introduced this special test to have it more accessible +void tst_QNetworkReply::ioGetFromHttpBrokenChunkedEncoding() +{ + // This is wrong chunked encoding because of the X. What actually has to follow is \r\n + // and then the declaration of the final 0 chunk + QByteArray dataToSend("HTTP/1.0 200 OK\r\nTransfer-Encoding: chunked\r\n\r\n3\r\nABCX"); + MiniHttpServer server(dataToSend); + server.doClose = false; // FIXME + + QNetworkRequest request(QUrl("http://localhost:" + QString::number(server.serverPort()))); + QNetworkReplyPtr reply = manager.get(request); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + + QEXPECT_FAIL(0, "We should close the socket and not just do nothing", Continue); + QVERIFY(!QTestEventLoop::instance().timeout()); + QEXPECT_FAIL(0, "We should close the socket and not just do nothing", Continue); + QVERIFY(reply->isFinished()); + QCOMPARE(reply->error(), QNetworkReply::NoError); +} + +// TODO: +// Prepare a gzip that has one chunk that expands to the size mentioned in the bugreport. +// Then have a custom HTTP server that waits after this chunk so the returning gets +// triggered. +void tst_QNetworkReply::qtbug12908compressedHttpReply() +{ + QString header("HTTP/1.0 200 OK\r\nContent-Encoding: gzip\r\nContent-Length: 63\r\n\r\n"); + + // dd if=/dev/zero of=qtbug-12908 bs=16384 count=1 && gzip qtbug-12908 && base64 -w 0 qtbug-12908.gz + QString encodedFile("H4sICDdDaUwAA3F0YnVnLTEyOTA4AO3BMQEAAADCoPVPbQwfoAAAAAAAAAAAAAAAAAAAAIC3AYbSVKsAQAAA"); + QByteArray decodedFile = QByteArray::fromBase64(encodedFile.toAscii()); + QCOMPARE(decodedFile.size(), 63); + + MiniHttpServer server(header.toAscii() + decodedFile); + server.doClose = true; + + QNetworkRequest request(QUrl("http://localhost:" + QString::number(server.serverPort()))); + QNetworkReplyPtr reply = manager.get(request); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QCOMPARE(reply->error(), QNetworkReply::NoError); + QCOMPARE(reply->size(), qint64(16384)); + QCOMPARE(reply->readAll(), QByteArray(16384, '\0')); +} + +void tst_QNetworkReply::compressedHttpReplyBrokenGzip() +{ + QString header("HTTP/1.0 200 OK\r\nContent-Encoding: gzip\r\nContent-Length: 63\r\n\r\n"); + + // dd if=/dev/zero of=qtbug-12908 bs=16384 count=1 && gzip qtbug-12908 && base64 -w 0 qtbug-12908.gz + // Then change "BMQ" to "BMX" + QString encodedFile("H4sICDdDaUwAA3F0YnVnLTEyOTA4AO3BMXEAAADCoPVPbQwfoAAAAAAAAAAAAAAAAAAAAIC3AYbSVKsAQAAA"); + QByteArray decodedFile = QByteArray::fromBase64(encodedFile.toAscii()); + QCOMPARE(decodedFile.size(), 63); + + MiniHttpServer server(header.toAscii() + decodedFile); + server.doClose = true; + + QNetworkRequest request(QUrl("http://localhost:" + QString::number(server.serverPort()))); + QNetworkReplyPtr reply = manager.get(request); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QCOMPARE(reply->error(), QNetworkReply::ProtocolFailure); +} + +// TODO add similar test for FTP +void tst_QNetworkReply::getFromUnreachableIp() +{ + QNetworkAccessManager manager; + + QNetworkRequest request(QUrl("http://255.255.255.255/42/23/narf/narf/narf")); + QNetworkReplyPtr reply = manager.get(request); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QVERIFY(reply->error() != QNetworkReply::NoError); +} + +void tst_QNetworkReply::qtbug4121unknownAuthentication() +{ + MiniHttpServer server(QByteArray("HTTP/1.1 401 bla\r\nWWW-Authenticate: crap\r\nContent-Length: 0\r\n\r\n")); + server.doClose = false; + + QNetworkRequest request(QUrl("http://localhost:" + QString::number(server.serverPort()))); + QNetworkAccessManager manager; + QNetworkReplyPtr reply = manager.get(request); + + qRegisterMetaType<QNetworkReply*>("QNetworkReply*"); + qRegisterMetaType<QAuthenticator*>("QAuthenticator*"); + QSignalSpy authSpy(&manager, SIGNAL(authenticationRequired(QNetworkReply*,QAuthenticator*))); + QSignalSpy finishedSpy(&manager, SIGNAL(finished(QNetworkReply*))); + qRegisterMetaType<QNetworkReply::NetworkError>("QNetworkReply::NetworkError"); + QSignalSpy errorSpy(reply, SIGNAL(error(QNetworkReply::NetworkError))); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop()), Qt::QueuedConnection); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QCOMPARE(authSpy.count(), 0); + QCOMPARE(finishedSpy.count(), 1); + QCOMPARE(errorSpy.count(), 1); + + QCOMPARE(reply->error(), QNetworkReply::AuthenticationRequiredError); +} + +class QtBug13431Helper : public QObject { + Q_OBJECT +public: + QNetworkReply* m_reply; + QTimer m_dlTimer; +public slots: + void replyFinished(QNetworkReply*) { + QTestEventLoop::instance().exitLoop(); + } + + void onReadAndReschedule() { + const qint64 bytesReceived = m_reply->bytesAvailable(); + if (bytesReceived) { + QByteArray data = m_reply->read(bytesReceived); + // reschedule read + const int millisecDelay = static_cast<int>(bytesReceived * 1000 / m_reply->readBufferSize()); + m_dlTimer.start(millisecDelay); + } + else { + // reschedule read + m_dlTimer.start(200); + } + } +}; + +void tst_QNetworkReply::qtbug13431replyThrottling() +{ + QtBug13431Helper helper; + + QNetworkAccessManager nam; + connect(&nam, SIGNAL(finished(QNetworkReply*)), &helper, SLOT(replyFinished(QNetworkReply*))); + + // Download a bigger file + QNetworkRequest netRequest(QUrl("http://" + QtNetworkSettings::serverName() + "/qtest/bigfile")); + helper.m_reply = nam.get(netRequest); + // Set the throttle + helper.m_reply->setReadBufferSize(36000); + + // Schedule a timer that tries to read + + connect(&helper.m_dlTimer, SIGNAL(timeout()), &helper, SLOT(onReadAndReschedule())); + helper.m_dlTimer.setSingleShot(true); + helper.m_dlTimer.start(0); + + QTestEventLoop::instance().enterLoop(30); + QVERIFY(!QTestEventLoop::instance().timeout()); + QVERIFY(helper.m_reply->isFinished()); + QCOMPARE(helper.m_reply->error(), QNetworkReply::NoError); +} + +void tst_QNetworkReply::httpWithNoCredentialUsage() +{ + QNetworkRequest request(QUrl("http://httptest:httptest@" + QtNetworkSettings::serverName() + "/qtest/protected/cgi-bin/md5sum.cgi")); + // Do not use credentials + request.setAttribute(QNetworkRequest::AuthenticationReuseAttribute, QNetworkRequest::Manual); + QNetworkAccessManager manager; + QNetworkReplyPtr reply = manager.get(request); + + qRegisterMetaType<QNetworkReply*>("QNetworkReply*"); + qRegisterMetaType<QAuthenticator*>("QAuthenticator*"); + QSignalSpy authSpy(&manager, SIGNAL(authenticationRequired(QNetworkReply*,QAuthenticator*))); + QSignalSpy finishedSpy(&manager, SIGNAL(finished(QNetworkReply*))); + qRegisterMetaType<QNetworkReply::NetworkError>("QNetworkReply::NetworkError"); + QSignalSpy errorSpy(reply, SIGNAL(error(QNetworkReply::NetworkError))); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop()), Qt::QueuedConnection); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + // We check if authenticationRequired was emitted, however we do not anything in it so it should be 401 + QCOMPARE(authSpy.count(), 1); + QCOMPARE(finishedSpy.count(), 1); + QCOMPARE(errorSpy.count(), 1); + + QCOMPARE(reply->error(), QNetworkReply::AuthenticationRequiredError); +} + +void tst_QNetworkReply::qtbug15311doubleContentLength() +{ + QByteArray response("HTTP/1.0 200 OK\r\nContent-Length: 3\r\nServer: bogus\r\nContent-Length: 3\r\n\r\nABC"); + MiniHttpServer server(response); + server.doClose = true; + + QNetworkRequest request(QUrl("http://localhost:" + QString::number(server.serverPort()))); + QNetworkReplyPtr reply = manager.get(request); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + QVERIFY(reply->isFinished()); + QCOMPARE(reply->error(), QNetworkReply::NoError); + QCOMPARE(reply->size(), qint64(3)); + QCOMPARE(reply->header(QNetworkRequest::ContentLengthHeader).toLongLong(), qint64(3)); + QCOMPARE(reply->rawHeader("Content-length"), QByteArray("3, 3")); + QCOMPARE(reply->readAll(), QByteArray("ABC")); +} + +void tst_QNetworkReply::qtbug18232gzipContentLengthZero() +{ + QByteArray response("HTTP/1.0 200 OK\r\nContent-Encoding: gzip\r\nContent-Length: 0\r\n\r\n"); + MiniHttpServer server(response); + server.doClose = true; + + QNetworkRequest request(QUrl("http://localhost:" + QString::number(server.serverPort()))); + QNetworkReplyPtr reply = manager.get(request); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + QVERIFY(reply->isFinished()); + QCOMPARE(reply->error(), QNetworkReply::NoError); + QCOMPARE(reply->size(), qint64(0)); + QCOMPARE(reply->header(QNetworkRequest::ContentLengthHeader).toLongLong(), qint64(0)); + QCOMPARE(reply->readAll(), QByteArray()); +} + +void tst_QNetworkReply::synchronousRequest_data() +{ + QTest::addColumn<QUrl>("url"); + QTest::addColumn<QString>("expected"); + QTest::addColumn<bool>("checkContentLength"); + QTest::addColumn<QString>("mimeType"); + + // ### cache, auth, proxies + + QTest::newRow("http") + << QUrl("http://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt") + << QString("file:" SRCDIR "/rfc3252.txt") + << true + << QString("text/plain"); + + QTest::newRow("http-gzip") + << QUrl("http://" + QtNetworkSettings::serverName() + "/qtest/deflate/rfc3252.txt") + << QString("file:" SRCDIR "/rfc3252.txt") + << false // don't check content length, because it's gzip encoded + // ### we would need to enflate (un-deflate) the file content and compare the sizes + << QString("text/plain"); + +#ifndef QT_NO_OPENSSL + QTest::newRow("https") + << QUrl("https://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt") + << QString("file:" SRCDIR "/rfc3252.txt") + << true + << QString("text/plain"); +#endif + + QTest::newRow("data") + << QUrl(QString::fromLatin1("data:text/plain,hello world")) + << QString("data:hello world") + << true // check content length + << QString("text/plain"); + + QTest::newRow("simple-file") + << QUrl::fromLocalFile(SRCDIR "/rfc3252.txt") + << QString("file:" SRCDIR "/rfc3252.txt") + << true + << QString(); +} + +// FIXME add testcase for failing network etc +void tst_QNetworkReply::synchronousRequest() +{ + QFETCH(QUrl, url); + QFETCH(QString, expected); + QFETCH(bool, checkContentLength); + QFETCH(QString, mimeType); + + QNetworkRequest request(url); + +#ifndef QT_NO_OPENSSL + // workaround for HTTPS requests: add self-signed server cert to list of CA certs, + // since we cannot react to the sslErrors() signal + // to fix this properly we would need to have an ignoreSslErrors() method in the + // QNetworkRequest, see http://bugreports.qt.nokia.com/browse/QTBUG-14774 + if (url.scheme() == "https") { + QSslConfiguration sslConf; + QList<QSslCertificate> certs = QSslCertificate::fromPath(SRCDIR "/certs/qt-test-server-cacert.pem"); + sslConf.setCaCertificates(certs); + request.setSslConfiguration(sslConf); + } +#endif + + request.setAttribute( + QNetworkRequest::SynchronousRequestAttribute, + true); + + QNetworkReplyPtr reply; + QSignalSpy finishedSpy(&manager, SIGNAL(finished(QNetworkReply*))); + QSignalSpy sslErrorsSpy(&manager, SIGNAL(sslErrors(QNetworkReply*,QList<QSslError>))); + RUN_REQUEST(runSimpleRequest(QNetworkAccessManager::GetOperation, request, reply, 0)); + QVERIFY(reply->isFinished()); + QCOMPARE(finishedSpy.count(), 0); + QCOMPARE(sslErrorsSpy.count(), 0); + + QCOMPARE(reply->header(QNetworkRequest::ContentTypeHeader).toString(), mimeType); + + QByteArray expectedContent; + + if (expected.startsWith("file:")) { + QString path = expected.mid(5); + QFile file(path); + file.open(QIODevice::ReadOnly); + expectedContent = file.readAll(); + } else if (expected.startsWith("data:")) { + expectedContent = expected.mid(5).toUtf8(); + } + + if (checkContentLength) + QCOMPARE(reply->header(QNetworkRequest::ContentLengthHeader).toLongLong(), qint64(expectedContent.size())); + QCOMPARE(reply->readAll(), expectedContent); + + reply->deleteLater(); +} + +#ifndef QT_NO_OPENSSL +void tst_QNetworkReply::synchronousRequestSslFailure() +{ + // test that SSL won't be accepted with self-signed certificate, + // and that we do not emit the sslError signal (in the manager that is, + // in the reply we don't care) + + QUrl url("https://" + QtNetworkSettings::serverName() + "/qtest/rfc3252.txt"); + QNetworkRequest request(url); + request.setAttribute( + QNetworkRequest::SynchronousRequestAttribute, + true); + QNetworkReplyPtr reply; + QSignalSpy sslErrorsSpy(&manager, SIGNAL(sslErrors(QNetworkReply *, const QList<QSslError> &))); + runSimpleRequest(QNetworkAccessManager::GetOperation, request, reply, 0); + QVERIFY(reply->isFinished()); + QCOMPARE(reply->error(), QNetworkReply::SslHandshakeFailedError); + QCOMPARE(sslErrorsSpy.count(), 0); +} +#endif + +void tst_QNetworkReply::httpAbort() +{ + // FIXME: Implement a test that aborts a big HTTP reply + // a) after the first readyRead() + // b) immediatly after the get() + // c) after the finished() + // The goal is no crash and no irrelevant signals after the abort + + // FIXME Also implement one where we do a big upload and then abort(). + // It must not crash either. +} + +void tst_QNetworkReply::dontInsertPartialContentIntoTheCache() +{ + QByteArray reply206 = + "HTTP/1.0 206\r\n" + "Connection: keep-alive\r\n" + "Content-Type: text/plain\r\n" + "Cache-control: no-cache\r\n" + "Content-Range: bytes 2-6/8\r\n" + "Content-length: 4\r\n" + "\r\n" + "load"; + + MiniHttpServer server(reply206); + server.doClose = false; + + MySpyMemoryCache *memoryCache = new MySpyMemoryCache(&manager); + manager.setCache(memoryCache); + + QUrl url = "http://localhost:" + QString::number(server.serverPort()); + QNetworkRequest request(url); + request.setRawHeader("Range", "bytes=2-6"); + + QNetworkReplyPtr reply = manager.get(request); + + connect(reply, SIGNAL(finished()), &QTestEventLoop::instance(), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(10); + QVERIFY(!QTestEventLoop::instance().timeout()); + + QVERIFY(server.totalConnections > 0); + QCOMPARE(reply->readAll().constData(), "load"); + QCOMPARE(memoryCache->m_insertedUrls.count(), 0); +} + +// NOTE: This test must be last testcase in tst_qnetworkreply! +void tst_QNetworkReply::parentingRepliesToTheApp() +{ + QNetworkRequest request (QUrl("http://" + QtNetworkSettings::serverName())); + manager.get(request)->setParent(this); // parent to this object + manager.get(request)->setParent(qApp); // parent to the app +} + +QTEST_MAIN(tst_QNetworkReply) + +#include "tst_qnetworkreply.moc" |
