|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |