Removed rfc3252.txt from networkselftest unittest

- no longer needed after test that used it was removed

Change-Id: I63fc8a9db07f9250507becb9bf6c2aefe0fdc254
Reviewed-by: Jason McDonald <jason.mcdonald@nokia.com>
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>

2 files changed, 0 insertions, 910 deletions

diff --git a/tests/auto/other/networkselftest/networkselftest.pro b/tests/auto/other/networkselftest/networkselftest.pro
index 3cd5f26689..1c0d256dbb 100644
--- a/tests/auto/other/networkselftest/networkselftest.pro
+++ b/tests/auto/other/networkselftest/networkselftest.pro
@@ -4,14 +4,3 @@ TARGET = tst_networkselftest
 SOURCES += tst_networkselftest.cpp
 QT = core network testlib
 
-wince*: {
-    addFiles.files = rfc3252.txt
-    addFiles.path = .
-    DEPLOYMENT += addFiles
-    DEFINES += SRCDIR=\\\"\\\"
-} else:vxworks*: {
-    DEFINES += SRCDIR=\\\"\\\"
-} else {
-    DEFINES += SRCDIR=\\\"$$PWD/\\\"
-}
-
diff --git a/tests/auto/other/networkselftest/rfc3252.txt b/tests/auto/other/networkselftest/rfc3252.txt
deleted file mode 100644
index b80c61bf0a..0000000000
--- a/tests/auto/other/networkselftest/rfc3252.txt
+++ /dev/null
@@ -1,899 +0,0 @@
-
-
-
-
-
-
-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]
-