tests/auto/qftp/rfc3252.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                         H. Kennedy
   8 Request for Comments: 3252                                      Mimezine
   9 Category: Informational                                     1 April 2002
  10
  11
  12                  Binary Lexical Octet Ad-hoc Transport
  13
  14 Status of this Memo
  15
  16    This memo provides information for the Internet community.  It does
  17    not specify an Internet standard of any kind.  Distribution of this
  18    memo is unlimited.
  19
  20 Copyright Notice
  21
  22    Copyright (C) The Internet Society (2002).  All Rights Reserved.
  23
  24 Abstract
  25
  26    This document defines a reformulation of IP and two transport layer
  27    protocols (TCP and UDP) as XML applications.
  28
  29 1.   Introduction
  30
  31 1.1. Overview
  32
  33    This document describes the Binary Lexical Octet Ad-hoc Transport
  34    (BLOAT): a reformulation of a widely-deployed network-layer protocol
  35    (IP [RFC791]), and two associated transport layer protocols (TCP
  36    [RFC793] and UDP [RFC768]) as XML [XML] applications.  It also
  37    describes methods for transporting BLOAT over Ethernet and IEEE 802
  38    networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
  39    across the public Internet.
  40
  41 1.2. Motivation
  42
  43    The wild popularity of XML as a basis for application-level protocols
  44    such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
  45    Object Access Protocol [SOAP], and Jabber [JABBER] prompted
  46    investigation into the possibility of extending the use of XML in the
  47    protocol stack.  Using XML at both the transport and network layer in
  48    addition to the application layer would provide for an amazing amount
  49    of power and flexibility while removing dependencies on proprietary
  50    and hard-to-understand binary protocols.  This protocol unification
  51    would also allow applications to use a single XML parser for all
  52    aspects of their operation, eliminating developer time spent figuring
  53    out the intricacies of each new protocol, and moving the hard work of
  54
  55
  56
  57
  58 Kennedy                      Informational                      [Page 1]
  59 \f
  60 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
  61
  62
  63    parsing to the XML toolset.  The use of XML also mitigates concerns
  64    over "network vs. host" byte ordering which is at the root of many
  65    network application bugs.
  66
  67 1.3. Relation to Existing Protocols
  68
  69    The reformulations specified in this RFC follow as closely as
  70    possible the spirit of the RFCs on which they are based, and so MAY
  71    contain elements or attributes that would not be needed in a pure
  72    reworking (e.g. length attributes, which are implicit in XML.)
  73
  74    The layering of network and transport protocols are maintained in
  75    this RFC despite the optimizations that could be made if the line
  76    were somewhat blurred (i.e. merging TCP and IP into a single, larger
  77    element in the DTD) in order to foster future use of this protocol as
  78    a basis for reformulating other protocols (such as ICMP.)
  79
  80    Other than the encoding, the behavioral aspects of each of the
  81    existing protocols remain unchanged.  Routing, address spaces, TCP
  82    congestion control, etc. behave as specified in the extant standards.
  83    Adapting to new standards and experimental algorithm heuristics for
  84    improving performance will become much easier once the move to BLOAT
  85    has been completed.
  86
  87 1.4. Requirement Levels
  88
  89    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  90    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  91    document are to be interpreted as described in BCP 14, RFC 2119
  92    [RFC2119].
  93
  94 2.   IPoXML
  95
  96    This protocol MUST be implemented to be compliant with this RFC.
  97    IPoXML is the root protocol REQUIRED for effective use of TCPoXML
  98    (section 3.) and higher-level application protocols.
  99
 100    The DTD for this document type can be found in section 7.1.
 101
 102    The routing of IPoXML can be easily implemented on hosts with an XML
 103    parser, as the regular structure lends itself handily to parsing and
 104    validation of the document/datagram and then processing the
 105    destination address, TTL, and checksum before sending it on to its
 106    next-hop.
 107
 108    The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
 109    wider deployment of IPv4 and the fact that implementing IPv6 as XML
 110    would have exceeded the 1500 byte Ethernet MTU.
 111
 112
 113
 114 Kennedy                      Informational                      [Page 2]
 115 \f
 116 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
 117
 118
 119    All BLOAT implementations MUST use - and specify - the UTF-8 encoding
 120    of RFC 2279 [RFC2279].  All BLOAT document/datagrams MUST be well-
 121    formed and include the XMLDecl.
 122
 123 2.1. IP Description
 124
 125    A number of items have changed (for the better) from the original IP
 126    specification.  Bit-masks, where present have been converted into
 127    human-readable values.  IP addresses are listed in their dotted-
 128    decimal notation [RFC1123].  Length and checksum values are present
 129    as decimal integers.
 130
 131    To calculate the length and checksum fields of the IP element, a
 132    canonicalized form of the element MUST be used.  The canonical form
 133    SHALL have no whitespace (including newline characters) between
 134    elements and only one space character between attributes.  There
 135    SHALL NOT be a space following the last attribute in an element.
 136
 137    An iterative method SHOULD be used to calculate checksums, as the
 138    length field will vary based on the size of the checksum.
 139
 140    The payload element bears special attention.  Due to the character
 141    set restrictions of XML, the payload of IP datagrams (which MAY
 142    contain arbitrary data) MUST be encoded for transport. This RFC
 143    REQUIRES the contents of the payload to be encoded in the base-64
 144    encoding of RFC 2045 [RFC2045], but removes the requirement that the
 145    encoded output MUST be wrapped on 76-character lines.
 146
 147
 148
 149
 150
 151
 152
 153
 154
 155
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167
 168
 169
 170 Kennedy                      Informational                      [Page 3]
 171 \f
 172 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
 173
 174
 175 2.2. Example Datagram
 176
 177    The following is an example IPoXML datagram with an empty payload:
 178
 179    <?xml version="1.0" encoding="UTF-8"?>
 180    <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
 181    <ip>
 182    <header length="474">
 183    <version value="4"/>
 184    <tos precedence="Routine" delay="Normal" throughput="Normal"
 185         relibility="Normal" reserved="0"/>
 186    <total.length value="461"/>
 187    <id value="1"/>
 188    <flags reserved="0" df="dont" mf="last"/>
 189    <offset value="0"/>
 190    <ttl value="255"/>
 191    <protocol value="6"/>
 192    <checksum value="8707"/>
 193    <source address="10.0.0.22"/>
 194    <destination address="10.0.0.1"/>
 195    <options>
 196    <end copied="0" class="0" number="0"/>
 197    </options>
 198    <padding pad="0"/>
 199    </header>
 200    <payload>
 201    </payload>
 202    </ip>
 203
 204 3.   TCPoXML
 205
 206    This protocol MUST be implemented to be compliant with this RFC.  The
 207    DTD for this document type can be found in section 7.2.
 208
 209 3.1. TCP Description
 210
 211    A number of items have changed from the original TCP specification.
 212    Bit-masks, where present have been converted into human-readable
 213    values.  Length and checksum and port values are present as decimal
 214    integers.
 215
 216    To calculate the length and checksum fields of the TCP element, a
 217    canonicalized form of the element MUST be used as in section 2.1.
 218
 219    An iterative method SHOULD be used to calculate checksums as in
 220    section 2.1.
 221
 222    The payload element MUST be encoded as in section 2.1.
 223
 224
 225
 226 Kennedy                      Informational                      [Page 4]
 227 \f
 228 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
 229
 230
 231    The TCP offset element was expanded to a maximum of 255 from 16 to
 232    allow for the increased size of the header in XML.
 233
 234    TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
 235    as well as the <!DOCTYPE> declaration.
 236
 237 3.2. Example Datagram
 238
 239    The following is an example TCPoXML datagram with an empty payload:
 240
 241    <?xml version="1.0" encoding="UTF-8"?>
 242    <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
 243    <tcp>
 244    <tcp.header>
 245    <src port="31415"/>
 246    <dest port="42424"/>
 247    <sequence number="322622954"/>
 248    <acknowledgement number="689715995"/>
 249    <offset number=""/>
 250    <reserved value="0"/>
 251    <control syn="1" ack="1"/>
 252    <window size="1"/>
 253    <urgent pointer="0"/>
 254    <checksum value="2988"/>
 255    <tcp.options>
 256    <tcp.end kind="0"/>
 257    </tcp.options>
 258    <padding pad="0"/>
 259    </tcp.header>
 260    <payload>
 261    </payload>
 262    </tcp>
 263
 264 4.   UDPoXML
 265
 266    This protocol MUST be implemented to be compliant with this RFC.  The
 267    DTD for this document type can be found in section 7.3.
 268
 269 4.1. UDP Description
 270
 271    A number of items have changed from the original UDP specification.
 272    Bit-masks, where present have been converted into human-readable
 273    values.  Length and checksum and port values are present as decimal
 274    integers.
 275
 276
 277
 278
 279
 280
 281
 282 Kennedy                      Informational                      [Page 5]
 283 \f
 284 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
 285
 286
 287    To calculate the length and checksum fields of the UDP element, a
 288    canonicalized form of the element MUST be used as in section 2.1.  An
 289    iterative method SHOULD be used to calculate checksums as in section
 290    2.1.
 291
 292    The payload element MUST be encoded as in section 2.1.
 293
 294    UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
 295    as well as the <!DOCTYPE> declaration.
 296
 297 4.2. Example Datagram
 298
 299    The following is an example UDPoXML datagram with an empty payload:
 300
 301    <?xml version="1.0" encoding="UTF-8"?>
 302    <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
 303    <udp>
 304    <udp.header>
 305    <src port="31415"/>
 306    <dest port="42424"/>
 307    <udp.length value="143"/>
 308    <checksum value="2988"/>
 309    </udp.header>
 310    <payload>
 311    </payload>
 312    </udp>
 313
 314 5.   Network Transport
 315
 316    This document provides for the transmission of BLOAT datagrams over
 317    two common families of physical layer transport.  Future RFCs will
 318    address additional transports as routing vendors catch up to the
 319    specification, and we begin to see BLOAT routed across the Internet
 320    backbone.
 321
 322 5.1. Ethernet
 323
 324    BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
 325    exception that the type field of the Ethernet frame MUST contain the
 326    value 0xBEEF.  The first 5 octets of the Ethernet frame payload will
 327    be 0x3c 3f 78 6d 6c ("<?xml".)
 328
 329 5.2. IEEE 802
 330
 331    BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
 332    that the protocol type code for IPoXML is 0xBEEF.
 333
 334
 335
 336
 337
 338 Kennedy                      Informational                      [Page 6]
 339 \f
 340 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
 341
 342
 343 6. Gatewaying over IP
 344
 345    In order to facilitate the gradual introduction of BLOAT into the
 346    public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
 347    gateway between networks that run BLOAT natively on their LANs.
 348
 349 7. DTDs
 350
 351    The Transport DTDs (7.2. and 7.3.) build on the definitions in the
 352    Network DTD (7.1.)
 353
 354    The DTDs are referenced by their PubidLiteral and SystemLiteral (from
 355    [XML]) although it is understood that most IPoXML implementations
 356    will not need to pull down the DTD, as it will normally be embedded
 357    in the implementation, and presents something of a catch-22 if you
 358    need to load part of your network protocol over the network.
 359
 360 7.1.  IPoXML DTD
 361
 362    <!--
 363     DTD for IP over XML.
 364     Refer to this DTD as:
 365
 366     <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
 367    -->
 368    <!--
 369     DTD data types:
 370
 371       Digits      [0..9]+
 372
 373       Precedence  "NetworkControl | InternetworkControl |
 374                    CRITIC | FlashOverride | Flash | Immediate |
 375                    Priority | Routine"
 376
 377       IP4Addr     "dotted-decimal" notation of [RFC1123]
 378
 379       Class       [0..3]
 380
 381       Sec          "Unclassified | Confidential | EFTO | MMMM | PROG |
 382                     Restricted | Secret | Top Secret | Reserved"
 383
 384       Compartments [0..65535]
 385
 386       Handling     [0..65535]
 387
 388       TCC          [0..16777216]
 389
 390    -->
 391
 392
 393
 394 Kennedy                      Informational                      [Page 7]
 395 \f
 396 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
 397
 398
 399    <!ENTITY % Digits "CDATA">
 400    <!ENTITY % Precedence "CDATA">
 401    <!ENTITY % IP4Addr "CDATA">
 402    <!ENTITY % Class "CDATA">
 403    <!ENTITY % Sec "CDATA">
 404    <!ENTITY % Compartments "CDATA">
 405    <!ENTITY % Handling "CDATA">
 406    <!ENTITY % TCC "CDATA">
 407
 408    <!ELEMENT ip (header, payload)>
 409
 410    <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
 411                     protocol, checksum, source, destination, options,
 412                     padding)>
 413    <!-- length of header in 32-bit words -->
 414    <!ATTLIST header
 415              length %Digits; #REQUIRED>
 416
 417    <!ELEMENT version EMPTY>
 418    <!-- ip version. SHOULD be "4" -->
 419    <!ATTLIST version
 420              value   %Digits;  #REQUIRED>
 421
 422    <!ELEMENT tos EMPTY>
 423    <!ATTLIST tos
 424              precedence   %Precedence;    #REQUIRED
 425              delay    (normal | low)  #REQUIRED
 426              throughput   (normal | high) #REQUIRED
 427              relibility   (normal | high) #REQUIRED
 428              reserved     CDATA #FIXED "0">
 429
 430    <!ELEMENT total.length EMPTY>
 431    <!--
 432     total length of datagram (header and payload) in octets, MUST be
 433     less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
 434     ethernets).
 435    -->
 436    <!ATTLIST total.length
 437              value %Digits; #REQUIRED>
 438
 439    <!ELEMENT id EMPTY>
 440    <!-- 0 <= id <= 65,535  -->
 441    <!ATTLIST id
 442              value %Digits; #REQUIRED>
 443
 444    <!ELEMENT flags EMPTY>
 445    <!-- df = don't fragment, mf = more fragments  -->
 446    <!ATTLIST flags
 447
 448
 449
 450 Kennedy                      Informational                      [Page 8]
 451 \f
 452 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
 453
 454
 455           reserved CDATA  #FIXED "0"
 456           df (may|dont)   #REQUIRED
 457           mf (last|more)  #REQUIRED>
 458
 459    <!ELEMENT offset EMPTY>
 460    <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
 461    <!ATTLIST offset
 462              value %Digits; #REQUIRED>
 463
 464    <!ELEMENT ttl EMPTY>
 465    <!-- 0 <= ttl <= 255 -->
 466    <!ATTLIST ttl
 467              value %Digits; #REQUIRED>
 468
 469    <!ELEMENT protocol EMPTY>
 470    <!-- 0 <= protocol <= 255 (per IANA) -->
 471    <!ATTLIST protocol
 472              value %Digits; #REQUIRED>
 473
 474    <!ELEMENT checksum EMPTY>
 475    <!-- 0 <= checksum <= 65535 (over header only) -->
 476    <!ATTLIST checksum
 477              value %Digits; #REQUIRED>
 478
 479    <!ELEMENT source EMPTY>
 480    <!ATTLIST source
 481              address %IP4Addr; #REQUIRED>
 482
 483    <!ELEMENT destination EMPTY>
 484    <!ATTLIST destination
 485              address %IP4Addr; #REQUIRED>
 486
 487    <!ELEMENT options ( end | noop | security | loose | strict | record
 488                      | stream | timestamp )*>
 489
 490    <!ELEMENT end EMPTY>
 491    <!ATTLIST end
 492              copied (0|1) #REQUIRED
 493              class  CDATA #FIXED "0"
 494              number CDATA #FIXED "0">
 495
 496    <!ELEMENT noop EMPTY>
 497    <!ATTLIST noop
 498              copied (0|1) #REQUIRED
 499              class  CDATA #FIXED "0"
 500              number CDATA #FIXED "1">
 501
 502    <!ELEMENT security EMPTY>
 503
 504
 505
 506 Kennedy                      Informational                      [Page 9]
 507 \f
 508 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
 509
 510
 511    <!ATTLIST security
 512              copied CDATA #FIXED "1"
 513              class  CDATA #FIXED "0"
 514              number CDATA #FIXED "2"
 515              length CDATA #FIXED "11"
 516              security %Sec; #REQUIRED
 517              compartments %Compartments; #REQUIRED
 518              handling %Handling; #REQUIRED
 519              tcc %TCC; #REQUIRED>
 520    <!ELEMENT loose (hop)+>
 521    <!ATTLIST loose
 522              copied CDATA #FIXED "1"
 523              class  CDATA #FIXED "0"
 524              number CDATA #FIXED "3"
 525              length %Digits; #REQUIRED
 526              pointer %Digits; #REQUIRED>
 527
 528    <!ELEMENT hop EMPTY>
 529    <!ATTLIST hop
 530              address %IP4Addr; #REQUIRED>
 531
 532    <!ELEMENT strict (hop)+>
 533    <!ATTLIST strict
 534              copied CDATA #FIXED "1"
 535              class  CDATA #FIXED "0"
 536              number CDATA #FIXED "9"
 537              length %Digits; #REQUIRED
 538              pointer %Digits; #REQUIRED>
 539
 540    <!ELEMENT record (hop)+>
 541    <!ATTLIST record
 542              copied CDATA #FIXED "0"
 543              class  CDATA #FIXED "0"
 544              number CDATA #FIXED "7"
 545              length %Digits; #REQUIRED
 546              pointer %Digits; #REQUIRED>
 547
 548    <!ELEMENT stream EMPTY>
 549    <!-- 0 <= id <= 65,535 -->
 550    <!ATTLIST stream
 551              copied CDATA #FIXED "1"
 552              class  CDATA #FIXED "0"
 553              number CDATA #FIXED "8"
 554              length CDATA #FIXED "4"
 555              id %Digits; #REQUIRED>
 556
 557    <!ELEMENT timestamp (tstamp)+>
 558    <!-- 0 <= oflw <=15 -->
 559
 560
 561
 562 Kennedy                      Informational                     [Page 10]
 563 \f
 564 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
 565
 566
 567    <!ATTLIST timestamp
 568              copied CDATA #FIXED "0"
 569              class  CDATA #FIXED "2"
 570              number CDATA #FIXED "4"
 571              length %Digits;  #REQUIRED
 572              pointer %Digits; #REQUIRED
 573              oflw %Digits;    #REQUIRED
 574              flag (0 | 1 | 3)  #REQUIRED>
 575
 576    <!ELEMENT tstamp EMPTY>
 577    <!ATTLIST tstamp
 578              time %Digits;   #REQUIRED
 579              address %IP4Addr; #IMPLIED>
 580    <!--
 581        padding to bring header to 32-bit boundary.
 582        pad MUST be "0"*
 583     -->
 584    <!ELEMENT padding EMPTY>
 585    <!ATTLIST padding
 586              pad CDATA #REQUIRED>
 587
 588    <!-- payload MUST be encoded as base-64 [RFC2045], as modified
 589         by section 2.1 of this RFC -->
 590    <!ELEMENT payload (CDATA)>
 591
 592 7.2.  TCPoXML DTD
 593
 594    <!--
 595       DTD for TCP over XML.
 596       Refer to this DTD as:
 597
 598       <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
 599    -->
 600
 601    <!-- the pseudoheader is only included for checksum calculations -->
 602    <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
 603
 604    <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
 605                          reserved, control, window, checksum, urgent,
 606                          tcp.options, padding)>
 607
 608    <!ELEMENT src EMPTY>
 609    <!-- 0 <= port <= 65,535 -->
 610    <!ATTLIST src
 611              port %Digits; #REQUIRED>
 612
 613    <!ELEMENT dest EMPTY>
 614    <!-- 0 <= port <= 65,535 -->
 615
 616
 617
 618 Kennedy                      Informational                     [Page 11]
 619 \f
 620 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
 621
 622
 623    <!ATTLIST dest
 624              port %Digits; #REQUIRED>
 625
 626    <!ELEMENT sequence EMPTY>
 627    <!-- 0 <= number <= 4294967295 -->
 628    <!ATTLIST sequence
 629              number %Digits; #REQUIRED>
 630
 631    <!ELEMENT acknowledgement EMPTY>
 632    <!-- 0 <= number <= 4294967295 -->
 633    <!ATTLIST acknowledgement
 634              number %Digits; #REQUIRED>
 635
 636    <!ELEMENT offset EMPTY>
 637    <!-- 0 <= number <= 255 -->
 638    <!ATTLIST offset
 639              number %Digits; #REQUIRED>
 640
 641    <!ELEMENT reserved EMPTY>
 642    <!ATTLIST reserved
 643              value CDATA #FIXED "0">
 644
 645    <!ELEMENT control EMPTY>
 646    <!ATTLIST control
 647              urg (0|1) #IMPLIED
 648              ack (0|1) #IMPLIED
 649              psh (0|1) #IMPLIED
 650              rst (0|1) #IMPLIED
 651              syn (0|1) #IMPLIED
 652              fin (0|1) #IMPLIED>
 653
 654    <!ELEMENT window EMPTY>
 655    <!-- 0 <= size <= 65,535 -->
 656    <!ATTLIST window
 657              size %Digits; #REQUIRED>
 658
 659    <!--
 660       checksum as in ip, but with
 661       the following pseudo-header added into the tcp element:
 662      -->
 663    <!ELEMENT tcp.pseudoheader (source, destination, protocol,
 664                                tcp.length)>
 665
 666    <!--
 667       tcp header + data length in octets. does not include the size of
 668
 669       the pseudoheader.
 670     -->
 671
 672
 673
 674 Kennedy                      Informational                     [Page 12]
 675 \f
 676 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
 677
 678
 679    <!ELEMENT tcp.length EMPTY>
 680    <!ATTLIST tcp.length
 681              value %Digits; #REQUIRED>
 682
 683    <!ELEMENT urgent EMPTY>
 684    <!-- 0 <= pointer <= 65,535 -->
 685    <!ATTLIST urgent
 686              pointer %Digits; #REQUIRED>
 687
 688    <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
 689
 690    <!ELEMENT tcp.end EMPTY>
 691    <!ATTLIST tcp.end
 692              kind CDATA #FIXED "0">
 693
 694    <!ELEMENT tcp.noop EMPTY>
 695    <!ATTLIST tcp.noop
 696              kind CDATA #FIXED "1">
 697
 698    <!ELEMENT tcp.mss EMPTY>
 699    <!ATTLIST tcp.mss
 700              kind CDATA #FIXED "2"
 701              length CDATA #FIXED "4"
 702              size %Digits; #REQUIRED>
 703
 704 7.3.  UDPoXML DTD
 705
 706    <!--
 707       DTD for UDP over XML.
 708       Refer to this DTD as:
 709
 710       <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
 711    -->
 712
 713    <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
 714
 715    <!ELEMENT udp.header (src, dest, udp.length, checksum)>
 716
 717    <!ELEMENT udp.pseudoheader (source, destination, protocol,
 718                                udp.length)>
 719
 720    <!--
 721       udp header + data length in octets. does not include the size of
 722       the pseudoheader.
 723     -->
 724    <!ELEMENT udp.length EMPTY>
 725    <!ATTLIST udp.length
 726              value %Digits; #REQUIRED>
 727
 728
 729
 730 Kennedy                      Informational                     [Page 13]
 731 \f
 732 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
 733
 734
 735 8. Security Considerations
 736
 737    XML, as a subset of SGML, has the same security considerations as
 738    specified in SGML Media Types [RFC1874].  Security considerations
 739    that apply to IP, TCP and UDP also likely apply to BLOAT as it does
 740    not attempt to correct for issues not related to message format.
 741
 742 9.   References
 743
 744    [JABBER]    Miller, J., "Jabber", draft-miller-jabber-00.txt,
 745                February 2002. (Work in Progress)
 746
 747    [RFC768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
 748                August 1980.
 749
 750    [RFC791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
 751                September 1981.
 752
 753    [RFC793]    Postel, J., "Transmission Control Protocol", STD 7, RFC
 754                793, September 1981.
 755
 756    [RFC894]    Hornig, C., "Standard for the Transmission of IP
 757                Datagrams over Ethernet Networks.", RFC 894, April 1984.
 758
 759    [RFC1042]   Postel, J. and J. Reynolds, "Standard for the
 760                Transmission of IP Datagrams Over IEEE 802 Networks", STD
 761                43, RFC 1042, February 1988.
 762
 763    [RFC1123]   Braden, R., "Requirements for Internet Hosts -
 764                Application and Support", RFC 1123, October 1989.
 765
 766    [RFC1874]   Levinson, E., "SGML Media Types", RFC 1874, December
 767                1995.
 768
 769    [RFC2003]   Perkins, C., "IP Encapsulation within IP", RFC 2003,
 770                October 1996.
 771
 772    [RFC2045]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
 773                Extensions (MIME) Part One: Format of Internet Message
 774                Bodies", RFC 2045, November 1996.
 775
 776    [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
 777                Requirement Levels", BCP 14, RFC 2119, March 1997.
 778
 779    [RFC2279]   Yergeau, F., "UTF-8, a transformation format of ISO
 780                10646", RFC 2279, January 1998.
 781
 782
 783
 784
 785
 786 Kennedy                      Informational                     [Page 14]
 787 \f
 788 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
 789
 790
 791    [RFC2460]   Deering, S. and R. Hinden, "Internet Protocol, Version 6
 792                (IPv6) Specification", RFC 2460, December 1998.
 793
 794    [RFC3080]   Rose, M., "The Blocks Extensible Exchange Protocol Core",
 795                RFC 3080, March 2001.
 796
 797    [SOAP]      Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
 798                Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
 799                "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
 800                Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
 801
 802    [XML]       Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
 803                Markup Language (XML)" World Wide Web Consortium
 804                Recommendation REC- xml-19980210.
 805                http://www.w3.org/TR/1998/REC-xml-19980210
 806
 807 10.  Author's Address
 808
 809    Hugh Kennedy
 810    Mimezine
 811    1060 West Addison
 812    Chicago, IL 60613
 813    USA
 814
 815    EMail: kennedyh@engin.umich.edu
 816
 817
 818
 819
 820
 821
 822
 823
 824
 825
 826
 827
 828
 829
 830
 831
 832
 833
 834
 835
 836
 837
 838
 839
 840
 841
 842 Kennedy                      Informational                     [Page 15]
 843 \f
 844 RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
 845
 846
 847 11.  Full Copyright Statement
 848
 849    Copyright (C) The Internet Society (2002).  All Rights Reserved.
 850
 851    This document and translations of it may be copied and furnished to
 852    others, and derivative works that comment on or otherwise explain it
 853    or assist in its implementation may be prepared, copied, published
 854    and distributed, in whole or in part, without restriction of any
 855    kind, provided that the above copyright notice and this paragraph are
 856    included on all such copies and derivative works.  However, this
 857    document itself may not be modified in any way, such as by removing
 858    the copyright notice or references to the Internet Society or other
 859    Internet organizations, except as needed for the purpose of
 860    developing Internet standards in which case the procedures for
 861    copyrights defined in the Internet Standards process must be
 862    followed, or as required to translate it into languages other than
 863    English.
 864
 865    The limited permissions granted above are perpetual and will not be
 866    revoked by the Internet Society or its successors or assigns.
 867
 868    This document and the information contained herein is provided on an
 869    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 870    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 871    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 872    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 873    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 874
 875 Acknowledgement
 876
 877    Funding for the RFC Editor function is currently provided by the
 878    Internet Society.
 879
 880
 881
 882
 883
 884
 885
 886
 887
 888
 889
 890
 891
 892
 893
 894
 895
 896
 897
 898 Kennedy                      Informational                     [Page 16]
 899 \f