Merge branch '4.7' of scm.dev.nokia.troll.no:qt/qt into 4.7

Conflicts:
	doc/src/template/style/style.css
	tools/qdoc3/htmlgenerator.cpp

29 files changed, 20069 insertions, 80 deletions

diff --git a/tests/auto/bic/tst_bic.cpp b/tests/auto/bic/tst_bic.cpp
index 2349afa..28129c5 100644
--- a/tests/auto/bic/tst_bic.cpp
+++ b/tests/auto/bic/tst_bic.cpp
@@ -239,6 +239,9 @@ QBic::Info tst_Bic::getCurrentInfo(const QString &libName)
     QStringList args;
     args << "-c"
          << "-I" + qtDir + "/include"
+#ifdef Q_OS_MAC
+        << "-arch" << "i386" // Always use 32-bit data on Mac.
+#endif
 #ifndef Q_OS_WIN
          << "-I/usr/X11R6/include/"
 #endif
diff --git a/tests/auto/macgui/tst_macgui.cpp b/tests/auto/macgui/tst_macgui.cpp
index 847ba4b..7f558a3 100644
--- a/tests/auto/macgui/tst_macgui.cpp
+++ b/tests/auto/macgui/tst_macgui.cpp
@@ -60,7 +60,6 @@ private slots:
     
     void dummy();
     void splashScreenModality();
-    void dialogModality();
     void nonModalOrder();
 
     void spinBoxArrowButtons();
@@ -157,32 +156,6 @@ void tst_MacGui::splashScreenModality()
     QVERIFY(QTestEventLoop::instance().timeout() == false);
 }
 
-
-/*
-    Test that a non-modal dialog created as a child of a modal dialog is
-    shown in front.
-*/
-void tst_MacGui::dialogModality()
-{ 
-    QDialog d;
-    d.setModal(true);
-    d.show();
-    
-    QProgressDialog progress(&d);
-    progress.setValue(2);
-
-    InterfaceChildPair interface = wn.find(QAccessible::Name, "Cancel", &progress);
-    QVERIFY(interface.iface);
-    const int delay = 2000;
-    clickLater(interface, Qt::LeftButton, delay);
-    
-    connect(&progress, SIGNAL(canceled()), SLOT(exitLoopSlot()));
-
-    const int timeout = 3;
-    QTestEventLoop::instance().enterLoop(timeout);
-    QVERIFY(QTestEventLoop::instance().timeout() == false);
-}
-
 class PrimaryWindowDialog : public QDialog
 {
 Q_OBJECT
diff --git a/tests/auto/macnativeevents/tst_macnativeevents.cpp b/tests/auto/macnativeevents/tst_macnativeevents.cpp
index 08ab9e6..70a14f5 100644
--- a/tests/auto/macnativeevents/tst_macnativeevents.cpp
+++ b/tests/auto/macnativeevents/tst_macnativeevents.cpp
@@ -41,6 +41,7 @@
 
 #include <QApplication>
 #include <QWidget>
+#include <QDialog>
 #include <QPushButton>
 #include <QtTest/QtTest>
 
@@ -65,6 +66,7 @@ private slots:
     void testMouseDragToNonClientArea();
     void testDragWindow();
     void testMouseEnter();
+    void testChildDialogInFrontOfModalParent();
 };
 
 void tst_MacNativeEvents::testMouseMoveLocation()
@@ -282,6 +284,28 @@ void tst_MacNativeEvents::testMouseEnter()
     QVERIFY2(expected.waitForAllEvents(), "the test did not receive all expected events!");
 }
 
+void tst_MacNativeEvents::testChildDialogInFrontOfModalParent()
+{
+    // Test that a child dialog of a modal parent dialog is 
+    // in front of the parent, and active:
+    QDialog parent;
+    parent.setWindowModality(Qt::ApplicationModal);
+    QDialog child(&parent);
+    QPushButton button("close", &child);
+    connect(&button, SIGNAL(clicked()), &child, SLOT(close()));
+    parent.show();
+    child.show();
+    QPoint inside = button.mapToGlobal(button.geometry().center());
+
+    // Post a click on the button to close the child dialog:
+    NativeEventList native;
+    native.append(new QNativeMouseButtonEvent(inside, Qt::LeftButton, 1, Qt::NoModifier));
+    native.append(new QNativeMouseButtonEvent(inside, Qt::LeftButton, 0, Qt::NoModifier));
+
+    native.play();
+    QTest::qWait(100);
+    QVERIFY(!child.isVisible());
+}
 
 #include "tst_macnativeevents.moc"
 
diff --git a/tests/auto/qfileinfo/tst_qfileinfo.cpp b/tests/auto/qfileinfo/tst_qfileinfo.cpp
index da5c772..403c5f9 100644
--- a/tests/auto/qfileinfo/tst_qfileinfo.cpp
+++ b/tests/auto/qfileinfo/tst_qfileinfo.cpp
@@ -1189,7 +1189,7 @@ void tst_QFileInfo::isLocalFs()
 
 void tst_QFileInfo::refresh()
 {
-#if defined(Q_OS_WINCE)
+#if defined(Q_OS_WINCE) || defined(Q_OS_WIN)
     int sleepTime = 3000;
 #else
     int sleepTime = 2000;
diff --git a/tests/auto/qlocale/tst_qlocale.cpp b/tests/auto/qlocale/tst_qlocale.cpp
index 182f73b..7a5d8a6 100644
--- a/tests/auto/qlocale/tst_qlocale.cpp
+++ b/tests/auto/qlocale/tst_qlocale.cpp
@@ -1921,7 +1921,7 @@ void tst_QLocale::dateFormat()
     const QLocale no("no_NO");
     QCOMPARE(no.dateFormat(QLocale::NarrowFormat), QLatin1String("dd.MM.yy"));
     QCOMPARE(no.dateFormat(QLocale::ShortFormat), QLatin1String("dd.MM.yy"));
-    QCOMPARE(no.dateFormat(QLocale::LongFormat), QLatin1String("dddd d. MMMM y"));
+    QCOMPARE(no.dateFormat(QLocale::LongFormat), QLatin1String("dddd d. MMMM yyyy"));
 }
 
 void tst_QLocale::timeFormat()
@@ -1933,7 +1933,7 @@ void tst_QLocale::timeFormat()
     const QLocale no("no_NO");
     QCOMPARE(no.timeFormat(QLocale::NarrowFormat), QLatin1String("HH:mm"));
     QCOMPARE(no.timeFormat(QLocale::ShortFormat), QLatin1String("HH:mm"));
-    QCOMPARE(no.timeFormat(QLocale::LongFormat), QLatin1String("'kl'. HH:mm:ss tttt"));
+    QCOMPARE(no.timeFormat(QLocale::LongFormat), QLatin1String("'kl'. HH:mm:ss t"));
 }
 
 void tst_QLocale::dateTimeFormat()
@@ -1945,7 +1945,7 @@ void tst_QLocale::dateTimeFormat()
     const QLocale no("no_NO");
     QCOMPARE(no.dateTimeFormat(QLocale::NarrowFormat), QLatin1String("dd.MM.yy HH:mm"));
     QCOMPARE(no.dateTimeFormat(QLocale::ShortFormat), QLatin1String("dd.MM.yy HH:mm"));
-    QCOMPARE(no.dateTimeFormat(QLocale::LongFormat), QLatin1String("dddd d. MMMM y 'kl'. HH:mm:ss tttt"));
+    QCOMPARE(no.dateTimeFormat(QLocale::LongFormat), QLatin1String("dddd d. MMMM yyyy 'kl'. HH:mm:ss t"));
 }
 
 void tst_QLocale::monthName()
diff --git a/tests/auto/qnetworkconfiguration/qnetworkconfiguration.pro b/tests/auto/qnetworkconfiguration/qnetworkconfiguration.pro
index df2d2d9..ca463bd 100644
--- a/tests/auto/qnetworkconfiguration/qnetworkconfiguration.pro
+++ b/tests/auto/qnetworkconfiguration/qnetworkconfiguration.pro
@@ -8,7 +8,7 @@ symbian {
     TARGET.CAPABILITY = NetworkServices NetworkControl ReadUserData 
 }
 
-maemo6 {
+maemo6|maemo5 {
     CONFIG += link_pkgconfig
 
     PKGCONFIG += conninet
diff --git a/tests/auto/qnetworkconfiguration/tst_qnetworkconfiguration.cpp b/tests/auto/qnetworkconfiguration/tst_qnetworkconfiguration.cpp
index 70f4447..ce3acb7 100644
--- a/tests/auto/qnetworkconfiguration/tst_qnetworkconfiguration.cpp
+++ b/tests/auto/qnetworkconfiguration/tst_qnetworkconfiguration.cpp
@@ -1,6 +1,6 @@
 /****************************************************************************
 **
-** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
+** Copyright (C) 2010 Nokia Corporation and/or its subsidiary(-ies).
 ** All rights reserved.
 ** Contact: Nokia Corporation (qt-info@nokia.com)
 **
@@ -41,10 +41,11 @@
 
 #include <QtTest/QtTest>
 #include "../qbearertestcommon.h"
-#include "qnetworkconfiguration.h"
-#include "qnetworkconfigmanager.h"
 
-#ifdef Q_WS_MAEMO_6
+#include <QtNetwork/qnetworkconfiguration.h>
+#include <QtNetwork/qnetworkconfigmanager.h>
+
+#if defined(Q_WS_MAEMO_6) || defined(Q_WS_MAEMO_5)
 #include <stdio.h>
 #include <iapconf.h>
 #endif
@@ -65,7 +66,7 @@ private slots:
     void isRoamingAvailable();
 
 private:
-#ifdef Q_WS_MAEMO_6
+#if defined(Q_WS_MAEMO_6) || defined(Q_WS_MAEMO_5)
     Maemo::IAPConf *iapconf;
     Maemo::IAPConf *iapconf2;
     Maemo::IAPConf *gprsiap;
@@ -77,7 +78,7 @@ private:
 
 void tst_QNetworkConfiguration::initTestCase()
 {
-#ifdef Q_WS_MAEMO_6
+#if defined(Q_WS_MAEMO_6) || defined(Q_WS_MAEMO_5)
     iapconf = new Maemo::IAPConf("007");
     iapconf->setValue("ipv4_type", "AUTO");
     iapconf->setValue("wlan_wepkey1", "connt");
@@ -150,7 +151,7 @@ void tst_QNetworkConfiguration::initTestCase()
 
 void tst_QNetworkConfiguration::cleanupTestCase()
 {
-#ifdef Q_WS_MAEMO_6
+#if defined(Q_WS_MAEMO_6) || defined(Q_WS_MAEMO_5)
     iapconf->clear();
     delete iapconf;
     iapconf2->clear();
diff --git a/tests/auto/qnetworkconfigurationmanager/qnetworkconfigurationmanager.pro b/tests/auto/qnetworkconfigurationmanager/qnetworkconfigurationmanager.pro
index e0028e5..d9c1d6b 100644
--- a/tests/auto/qnetworkconfigurationmanager/qnetworkconfigurationmanager.pro
+++ b/tests/auto/qnetworkconfigurationmanager/qnetworkconfigurationmanager.pro
@@ -8,7 +8,7 @@ symbian {
     TARGET.CAPABILITY = NetworkServices NetworkControl ReadUserData
 }
 
-maemo6 {
+maemo6|maemo5 {
     CONFIG += link_pkgconfig
 
     PKGCONFIG += conninet
diff --git a/tests/auto/qnetworkconfigurationmanager/tst_qnetworkconfigurationmanager.cpp b/tests/auto/qnetworkconfigurationmanager/tst_qnetworkconfigurationmanager.cpp
index 30c5a74..7cc527c 100644
--- a/tests/auto/qnetworkconfigurationmanager/tst_qnetworkconfigurationmanager.cpp
+++ b/tests/auto/qnetworkconfigurationmanager/tst_qnetworkconfigurationmanager.cpp
@@ -41,10 +41,11 @@
 
 #include <QtTest/QtTest>
 #include "../qbearertestcommon.h"
-#include "qnetworkconfiguration.h"
-#include "qnetworkconfigmanager.h"
 
-#ifdef Q_WS_MAEMO_6
+#include <QtNetwork/qnetworkconfiguration.h>
+#include <QtNetwork/qnetworkconfigmanager.h>
+
+#if defined(Q_WS_MAEMO_6) || defined(Q_WS_MAEMO_5)
 #include <stdio.h>
 #include <iapconf.h>
 #endif
@@ -66,7 +67,7 @@ private slots:
     void configurationFromIdentifier();
 
 private:
-#ifdef Q_WS_MAEMO_6
+#if defined(Q_WS_MAEMO_6) || defined(Q_WS_MAEMO_5)
     Maemo::IAPConf *iapconf;
     Maemo::IAPConf *iapconf2;
     Maemo::IAPConf *gprsiap;
@@ -78,7 +79,7 @@ private:
 
 void tst_QNetworkConfigurationManager::initTestCase()
 {
-#ifdef Q_WS_MAEMO_6
+#if defined(Q_WS_MAEMO_6) || defined(Q_WS_MAEMO_5)
     iapconf = new Maemo::IAPConf("007");
     iapconf->setValue("ipv4_type", "AUTO");
     iapconf->setValue("wlan_wepkey1", "connt");
@@ -152,7 +153,7 @@ void tst_QNetworkConfigurationManager::initTestCase()
 
 void tst_QNetworkConfigurationManager::cleanupTestCase()
 {
-#ifdef Q_WS_MAEMO_6
+#if defined(Q_WS_MAEMO_6) || defined(Q_WS_MAEMO_5)
     iapconf->clear();
     delete iapconf;
     iapconf2->clear();
diff --git a/tests/auto/qnetworksession/lackey/main.cpp b/tests/auto/qnetworksession/lackey/main.cpp
index 66d6dd4..8759b52 100644
--- a/tests/auto/qnetworksession/lackey/main.cpp
+++ b/tests/auto/qnetworksession/lackey/main.cpp
@@ -42,9 +42,10 @@
 #include <QCoreApplication>
 #include <QStringList>
 #include <QLocalSocket>
-#include <qnetworkconfigmanager.h>
-#include <qnetworkconfiguration.h>
-#include <qnetworksession.h>
+
+#include <QtNetwork/qnetworkconfiguration.h>
+#include <QtNetwork/qnetworkconfigmanager.h>
+#include <QtNetwork/qnetworksession.h>
 
 #include <QDebug>
 
diff --git a/tests/auto/qnetworksession/test/test.pro b/tests/auto/qnetworksession/test/test.pro
index d248b10..bfffe90 100644
--- a/tests/auto/qnetworksession/test/test.pro
+++ b/tests/auto/qnetworksession/test/test.pro
@@ -19,7 +19,7 @@ symbian {
     TARGET.CAPABILITY = NetworkServices NetworkControl ReadUserData PowerMgmt
 }
 
-maemo6 {
+maemo6|maemo5 {
     CONFIG += link_pkgconfig
 
     PKGCONFIG += conninet
diff --git a/tests/auto/qnetworksession/test/tst_qnetworksession.cpp b/tests/auto/qnetworksession/test/tst_qnetworksession.cpp
index 58b0576..23cdc6a 100644
--- a/tests/auto/qnetworksession/test/tst_qnetworksession.cpp
+++ b/tests/auto/qnetworksession/test/tst_qnetworksession.cpp
@@ -44,10 +44,11 @@
 #include <QLocalSocket>
 #include <QTimer>
 #include "../../qbearertestcommon.h"
-#include <qnetworkconfigmanager.h>
-#include <qnetworksession.h>
 
-#ifdef Q_WS_MAEMO_6
+#include <QtNetwork/qnetworkconfigmanager.h>
+#include <QtNetwork/qnetworksession.h>
+
+#if defined(Q_WS_MAEMO_6) || defined(Q_WS_MAEMO_5)
 #include <stdio.h>
 #include <iapconf.h>
 #endif
@@ -72,6 +73,8 @@ public slots:
 
 private slots:
 
+    void robustnessBombing();
+
     void outOfProcessSession();
     void invalidSession();
 
@@ -100,7 +103,7 @@ private:
 
     int inProcessSessionManagementCount;
 
-#ifdef Q_WS_MAEMO_6
+#if defined(Q_WS_MAEMO_6) || defined(Q_WS_MAEMO_5)
     Maemo::IAPConf *iapconf;
     Maemo::IAPConf *iapconf2;
     Maemo::IAPConf *gprsiap;
@@ -123,7 +126,7 @@ void tst_QNetworkSession::initTestCase()
     qRegisterMetaType<QNetworkConfiguration>("QNetworkConfiguration");
     qRegisterMetaType<QNetworkConfiguration::Type>("QNetworkConfiguration::Type");
 
-#ifdef Q_WS_MAEMO_6
+#if defined(Q_WS_MAEMO_6) || defined(Q_WS_MAEMO_5)
     iapconf = new Maemo::IAPConf("007");
     iapconf->setValue("ipv4_type", "AUTO");
     iapconf->setValue("wlan_wepkey1", "connt");
@@ -209,7 +212,7 @@ void tst_QNetworkSession::cleanupTestCase()
                  "inProcessSessionManagement()");
     }
 
-#ifdef Q_WS_MAEMO_6
+#if defined(Q_WS_MAEMO_6) || defined(Q_WS_MAEMO_5)
     iapconf->clear();
     delete iapconf;
     iapconf2->clear();
@@ -232,6 +235,23 @@ void tst_QNetworkSession::cleanupTestCase()
 #endif
 }
 
+// Robustness test for calling interfaces in nonsense order / with nonsense parameters
+void tst_QNetworkSession::robustnessBombing() 
+{
+    QNetworkConfigurationManager mgr;
+    QNetworkSession testSession(mgr.defaultConfiguration());
+    // Should not reset even session is not opened
+    testSession.migrate();
+    testSession.accept();
+    testSession.ignore();
+    testSession.reject();
+    quint64 temp;
+    temp = testSession.bytesWritten();
+    temp = testSession.bytesReceived();
+    temp = testSession.activeTime();
+}
+
+
 void tst_QNetworkSession::invalidSession()
 {
     // 1. Verify that session created with invalid configuration remains in invalid state
diff --git a/tests/auto/qthread/tst_qthread.cpp b/tests/auto/qthread/tst_qthread.cpp
index 871578e..9a4397e 100644
--- a/tests/auto/qthread/tst_qthread.cpp
+++ b/tests/auto/qthread/tst_qthread.cpp
@@ -174,8 +174,8 @@ public:
 
     void run()
     {
+        Simple_Thread::run();
         if (object) {
-            Simple_Thread::run();
             object->thread = this;
             object->code = code;
             QTimer::singleShot(100, object, SLOT(slot()));
@@ -218,8 +218,8 @@ public:
 
     void run()
     {
+        Simple_Thread::run();
         if (object) {
-            Simple_Thread::run();
             object->thread = this;
             QTimer::singleShot(100, object, SLOT(slot()));
         }
@@ -443,22 +443,24 @@ void tst_QThread::exit()
     thread2.code = 53;
     thread2.result = 0;
     thread2.start();
-    thread2.exit(thread.code);
+    thread2.exit(thread2.code);
+    QMutexLocker locker2(&thread2.mutex);
+    thread2.cond.wait(locker2.mutex());
     QVERIFY(thread2.wait(five_minutes));
-    QCOMPARE(thread.result, thread.code);
+    QCOMPARE(thread2.result, thread2.code);
 }
 
 void tst_QThread::start()
 {
     QThread::Priority priorities[] = {
-	QThread::IdlePriority,
-	QThread::LowestPriority,
-	QThread::LowPriority,
-	QThread::NormalPriority,
-	QThread::HighPriority,
-	QThread::HighestPriority,
-	QThread::TimeCriticalPriority,
-	QThread::InheritPriority
+        QThread::IdlePriority,
+        QThread::LowestPriority,
+        QThread::LowPriority,
+        QThread::NormalPriority,
+        QThread::HighPriority,
+        QThread::HighestPriority,
+        QThread::TimeCriticalPriority,
+        QThread::InheritPriority
     };
     const int prio_count = sizeof(priorities) / sizeof(QThread::Priority);
 
@@ -514,8 +516,10 @@ void tst_QThread::quit()
     thread2.result = -1;
     thread2.start();
     thread2.quit();
+    QMutexLocker locker2(&thread2.mutex);
+    thread2.cond.wait(locker2.mutex());
     QVERIFY(thread2.wait(five_minutes));
-    QCOMPARE(thread.result, 0);
+    QCOMPARE(thread2.result, 0);
 }
 
 void tst_QThread::wait()
@@ -692,7 +696,7 @@ void NativeThreadWrapper::start(FunctionPointer functionPointer, void *data)
     const int state = pthread_create(&nativeThreadHandle, 0, NativeThreadWrapper::runUnix, this);
     Q_UNUSED(state);
 #elif defined(Q_OS_WINCE)
-	nativeThreadHandle = CreateThread(NULL, 0 , (LPTHREAD_START_ROUTINE)NativeThreadWrapper::runWin , this, 0, NULL);
+        nativeThreadHandle = CreateThread(NULL, 0 , (LPTHREAD_START_ROUTINE)NativeThreadWrapper::runWin , this, 0, NULL);
 #elif defined Q_OS_WIN
     unsigned thrdid = 0;
     nativeThreadHandle = (Qt::HANDLE) _beginthreadex(NULL, 0, NativeThreadWrapper::runWin, this, 0, &thrdid);
diff --git a/tests/auto/qwidget/tst_qwidget.cpp b/tests/auto/qwidget/tst_qwidget.cpp
index 1b2944e..76e20b9 100644
--- a/tests/auto/qwidget/tst_qwidget.cpp
+++ b/tests/auto/qwidget/tst_qwidget.cpp
@@ -6056,9 +6056,6 @@ void tst_QWidget::setToolTip()
 #ifdef Q_OS_WINCE_WM
     QSKIP("Mouse over doesn't work on Windows mobile.", SkipAll);
 #endif
-#ifdef QT_MAC_USE_COCOA
-    QSKIP("Temporarily disable the rest on cocoa due to QCursor::setPos problems.", SkipAll);
-#endif
 
     for (int pass = 0; pass < 2; ++pass) {
         QWidget *popup = new QWidget(0, Qt::Popup);
diff --git a/tests/auto/qwindowsurface/tst_qwindowsurface.cpp b/tests/auto/qwindowsurface/tst_qwindowsurface.cpp
index dd985ca..7dde402 100644
--- a/tests/auto/qwindowsurface/tst_qwindowsurface.cpp
+++ b/tests/auto/qwindowsurface/tst_qwindowsurface.cpp
@@ -66,6 +66,7 @@ private slots:
     void getSetWindowSurface();
     void flushOutsidePaintEvent();
     void grabWidget();
+    void staticContentsAndPartialUpdateSupport();
 };
 
 class MyWindowSurface : public QWindowSurface
@@ -81,6 +82,8 @@ public:
         /* nothing */
     }
 
+    using QWindowSurface::setStaticContentsSupport;
+    using QWindowSurface::setPartialUpdateSupport;
 private:
     QImage image;
 };
@@ -280,6 +283,51 @@ void tst_QWindowSurface::grabWidget()
     QVERIFY(QColor(childInvalidSubImage.pixel(0, 0)) == QColor(Qt::white));
 }
 
+void tst_QWindowSurface::staticContentsAndPartialUpdateSupport()
+{
+    QWidget widget;
+    MyWindowSurface surface(&widget);
+
+    // Default values.
+    QVERIFY(surface.hasPartialUpdateSupport());
+    QVERIFY(!surface.hasStaticContentsSupport());
+
+    // Partial: YES, Static: YES
+    surface.setStaticContentsSupport(true);
+    QVERIFY(surface.hasPartialUpdateSupport());
+    QVERIFY(surface.hasStaticContentsSupport());
+
+    // Static contents requires support for partial updates.
+    // We simply ingore bad combinations and spit out a warning.
+
+    // CONFLICT: Partial: NO, Static: YES
+    QTest::ignoreMessage(QtWarningMsg, "QWindowSurface::setPartialUpdateSupport: static contents support requires partial update support");
+    surface.setPartialUpdateSupport(false);
+    QVERIFY(surface.hasPartialUpdateSupport());
+    QVERIFY(surface.hasStaticContentsSupport());
+
+    // Partial: YES, Static: NO
+    surface.setStaticContentsSupport(false);
+    QVERIFY(surface.hasPartialUpdateSupport());
+    QVERIFY(!surface.hasStaticContentsSupport());
+
+    // Partial: NO, Static: NO
+    surface.setPartialUpdateSupport(false);
+    QVERIFY(!surface.hasPartialUpdateSupport());
+    QVERIFY(!surface.hasStaticContentsSupport());
+
+    // CONFLICT: Partial: NO, Static: YES
+    QTest::ignoreMessage(QtWarningMsg, "QWindowSurface::setStaticContentsSupport: static contents support requires partial update support");
+    surface.setStaticContentsSupport(true);
+    QVERIFY(!surface.hasPartialUpdateSupport());
+    QVERIFY(!surface.hasStaticContentsSupport());
+
+    // Partial: YES, Static: NO
+    surface.setPartialUpdateSupport(true);
+    QVERIFY(surface.hasPartialUpdateSupport());
+    QVERIFY(!surface.hasStaticContentsSupport());
+}
+
 QTEST_MAIN(tst_QWindowSurface)
 
 #else // Q_WS_MAC
diff --git a/tests/manual/bearerex/bearerex.h b/tests/manual/bearerex/bearerex.h
index 2875d6a..6bcb3e5 100644
--- a/tests/manual/bearerex/bearerex.h
+++ b/tests/manual/bearerex/bearerex.h
@@ -1,6 +1,6 @@
 /****************************************************************************
 **
-** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
+** Copyright (C) 2010 Nokia Corporation and/or its subsidiary(-ies).
 ** All rights reserved.
 ** Contact: Nokia Corporation (qt-info@nokia.com)
 **
@@ -44,10 +44,15 @@
 
 #include <QtGui>
 
-#include "ui_bearerex.h"
 #include "ui_detailedinfodialog.h"
-#include "ui_sessiondialog.h"
 
+#if defined(Q_WS_MAEMO_5) || defined(Q_WS_MAEMO_6)
+#include "ui_bearerex_maemo.h"
+#include "ui_sessiondialog_maemo.h"
+#else
+#include "ui_bearerex.h"
+#include "ui_sessiondialog.h"
+#endif
 #include "qnetworkconfigmanager.h"
 #include "qnetworksession.h"
 #include "xqlistwidget.h"
diff --git a/tests/manual/bearerex/bearerex.pro b/tests/manual/bearerex/bearerex.pro
index 927f982..7b21183 100644
--- a/tests/manual/bearerex/bearerex.pro
+++ b/tests/manual/bearerex/bearerex.pro
@@ -5,9 +5,15 @@ QT += core \
       gui \
       network
 
-FORMS += sessiondialog.ui \
-         bearerex.ui \
-         detailedinfodialog.ui
+FORMS += detailedinfodialog.ui
+maemo5|maemo6 {
+    FORMS += sessiondialog_maemo.ui \
+        bearerex_maemo.ui
+} else {
+    FORMS += sessiondialog.ui \
+        bearerex.ui
+}
+
 
 # Example headers and sources
 HEADERS += bearerex.h \
@@ -17,4 +23,4 @@ SOURCES += bearerex.cpp \
            main.cpp \
            xqlistwidget.cpp
 
-symbian:TARGET.CAPABILITY = NetworkServices NetworkControl ReadUserData
\ No newline at end of file
+symbian:TARGET.CAPABILITY = NetworkServices NetworkControl ReadUserData
diff --git a/tests/manual/bearerex/bearerex_maemo.ui b/tests/manual/bearerex/bearerex_maemo.ui
new file mode 100644
index 0000000..cb17e38
--- /dev/null
+++ b/tests/manual/bearerex/bearerex_maemo.ui
@@ -0,0 +1,100 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<ui version="4.0">
+ <class>BearerExMainWindow</class>
+ <widget class="QMainWindow" name="BearerExMainWindow">
+  <property name="geometry">
+   <rect>
+    <x>0</x>
+    <y>0</y>
+    <width>360</width>
+    <height>640</height>
+   </rect>
+  </property>
+  <property name="windowTitle">
+   <string>Bearer Example</string>
+  </property>
+  <widget class="QWidget" name="centralwidget">
+   <layout class="QVBoxLayout" name="verticalLayout">
+    <item>
+     <widget class="QTabWidget" name="mainTabWidget">
+      <widget class="QWidget" name="tab">
+       <attribute name="title">
+        <string>Main</string>
+       </attribute>
+       <layout class="QHBoxLayout" name="horizontalLayout">
+        <item>
+         <layout class="QVBoxLayout" name="verticalLayout_2">
+          <item>
+           <widget class="QLabel" name="label">
+            <property name="text">
+             <string>Network Configurations</string>
+            </property>
+            <property name="alignment">
+             <set>Qt::AlignCenter</set>
+            </property>
+           </widget>
+          </item>
+          <item>
+           <widget class="QListWidget" name="listWidget"/>
+          </item>
+         </layout>
+        </item>
+        <item>
+         <layout class="QGridLayout" name="gridLayout">
+          <item row="0" column="0">
+           <widget class="QPushButton" name="updateConfigurationsButton">
+            <property name="text">
+             <string>Update Configs</string>
+            </property>
+           </widget>
+          </item>
+          <item row="1" column="0">
+           <widget class="QPushButton" name="updateListButton">
+            <property name="text">
+             <string>Update List</string>
+            </property>
+           </widget>
+          </item>
+          <item row="2" column="0">
+           <widget class="QPushButton" name="createSessionButton">
+            <property name="text">
+             <string>Create Session</string>
+            </property>
+           </widget>
+          </item>
+          <item row="3" column="0">
+           <widget class="QPushButton" name="showDetailsButton">
+            <property name="text">
+             <string>Show Details</string>
+            </property>
+           </widget>
+          </item>
+         </layout>
+        </item>
+       </layout>
+      </widget>
+      <widget class="QWidget" name="tab_2">
+       <attribute name="title">
+        <string>Events</string>
+       </attribute>
+       <layout class="QVBoxLayout" name="verticalLayout_3">
+        <item>
+         <widget class="QListWidget" name="eventListWidget"/>
+        </item>
+        <item>
+         <widget class="QPushButton" name="clearEventListButton">
+          <property name="text">
+           <string>Clear</string>
+          </property>
+         </widget>
+        </item>
+       </layout>
+      </widget>
+     </widget>
+    </item>
+   </layout>
+  </widget>
+ </widget>
+ <resources/>
+ <connections/>
+</ui>
diff --git a/tests/manual/bearerex/sessiondialog_maemo.ui b/tests/manual/bearerex/sessiondialog_maemo.ui
new file mode 100644
index 0000000..5eb98ce
--- /dev/null
+++ b/tests/manual/bearerex/sessiondialog_maemo.ui
@@ -0,0 +1,151 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<ui version="4.0">
+ <class>SessionTab</class>
+ <widget class="QWidget" name="SessionTab">
+  <property name="geometry">
+   <rect>
+    <x>0</x>
+    <y>0</y>
+    <width>423</width>
+    <height>214</height>
+   </rect>
+  </property>
+  <layout class="QHBoxLayout" name="horizontalLayout">
+   <item>
+    <layout class="QFormLayout" name="formLayout">
+     <property name="fieldGrowthPolicy">
+      <enum>QFormLayout::ExpandingFieldsGrow</enum>
+     </property>
+     <item row="0" column="0">
+      <widget class="QLabel" name="snapLabel">
+       <property name="text">
+        <string>SNAP</string>
+       </property>
+      </widget>
+     </item>
+     <item row="0" column="1">
+      <widget class="QLineEdit" name="snapLineEdit">
+       <property name="readOnly">
+        <bool>true</bool>
+       </property>
+      </widget>
+     </item>
+     <item row="1" column="0">
+      <widget class="QLabel" name="iapLabel">
+       <property name="text">
+        <string>IAP</string>
+       </property>
+      </widget>
+     </item>
+     <item row="1" column="1">
+      <widget class="QLineEdit" name="iapLineEdit">
+       <property name="enabled">
+        <bool>true</bool>
+       </property>
+       <property name="readOnly">
+        <bool>true</bool>
+       </property>
+      </widget>
+     </item>
+     <item row="2" column="0">
+      <widget class="QLabel" name="bearerLabel">
+       <property name="text">
+        <string>Bearer</string>
+       </property>
+      </widget>
+     </item>
+     <item row="2" column="1">
+      <widget class="QLineEdit" name="bearerLineEdit">
+       <property name="readOnly">
+        <bool>true</bool>
+       </property>
+      </widget>
+     </item>
+     <item row="3" column="0">
+      <widget class="QLabel" name="sentRecDataLabel">
+       <property name="text">
+        <string>Sent/Rec.</string>
+       </property>
+      </widget>
+     </item>
+     <item row="3" column="1">
+      <widget class="QLineEdit" name="sentRecDataLineEdit">
+       <property name="readOnly">
+        <bool>true</bool>
+       </property>
+      </widget>
+     </item>
+     <item row="4" column="0">
+      <widget class="QLabel" name="stateLabel">
+       <property name="text">
+        <string>State</string>
+       </property>
+      </widget>
+     </item>
+     <item row="4" column="1">
+      <widget class="QLineEdit" name="stateLineEdit">
+       <property name="readOnly">
+        <bool>true</bool>
+       </property>
+      </widget>
+     </item>
+    </layout>
+   </item>
+   <item>
+    <layout class="QGridLayout" name="gridLayout">
+     <item row="0" column="0">
+      <widget class="QPushButton" name="openSessionButton">
+       <property name="text">
+        <string>Open Session</string>
+       </property>
+      </widget>
+     </item>
+     <item row="0" column="1">
+      <widget class="QPushButton" name="closeSessionButton">
+       <property name="text">
+        <string>Close Session</string>
+       </property>
+      </widget>
+     </item>
+     <item row="1" column="0">
+      <widget class="QPushButton" name="stopConnectionButton">
+       <property name="text">
+        <string>Stop Conn.</string>
+       </property>
+      </widget>
+     </item>
+     <item row="1" column="1">
+      <widget class="QPushButton" name="sendRequestButton">
+       <property name="text">
+        <string>Send Test Req.</string>
+       </property>
+      </widget>
+     </item>
+     <item row="2" column="0">
+      <widget class="QPushButton" name="createQHttpButton">
+       <property name="text">
+        <string>Create QHttp</string>
+       </property>
+      </widget>
+     </item>
+     <item row="2" column="1">
+      <widget class="QPushButton" name="deleteSessionButton">
+       <property name="text">
+        <string>Delete Session</string>
+       </property>
+      </widget>
+     </item>
+     <item row="3" column="0">
+      <widget class="QPushButton" name="alrButton">
+       <property name="text">
+        <string>Enable ALR</string>
+       </property>
+      </widget>
+     </item>
+    </layout>
+   </item>
+  </layout>
+ </widget>
+ <resources/>
+ <connections/>
+</ui>
diff --git a/tests/manual/network_remote_stresstest/network_remote_stresstest.pro b/tests/manual/network_remote_stresstest/network_remote_stresstest.pro
new file mode 100644
index 0000000..9ed1090
--- /dev/null
+++ b/tests/manual/network_remote_stresstest/network_remote_stresstest.pro
@@ -0,0 +1,8 @@
+load(qttest_p4)
+
+QT = core network
+
+SOURCES  += tst_network_remote_stresstest.cpp
+
+RESOURCES += url-list.qrc
+
diff --git a/tests/manual/network_remote_stresstest/tst_network_remote_stresstest.cpp b/tests/manual/network_remote_stresstest/tst_network_remote_stresstest.cpp
new file mode 100644
index 0000000..90a95e7
--- /dev/null
+++ b/tests/manual/network_remote_stresstest/tst_network_remote_stresstest.cpp
@@ -0,0 +1,499 @@
+/****************************************************************************
+**
+** Copyright (C) 2010 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/QThread>
+#include <QtCore/QSemaphore>
+#include <QtCore/QElapsedTimer>
+#include <QtCore/QSharedPointer>
+#include <QtCore/QVector>
+#include <QtNetwork/QTcpSocket>
+#include <QtNetwork/QSslSocket>
+#include <QtNetwork/QNetworkReply>
+#include <QtNetwork/QNetworkAccessManager>
+
+#ifdef QT_BUILD_INTERNAL
+# include <private/qnetworkaccessmanager_p.h>
+#endif
+
+#include <qplatformdefs.h>
+#ifdef Q_OS_UNIX
+# include <sys/types.h>
+# include <sys/socket.h>
+# include <sys/select.h>
+# include <netinet/in.h>
+# include <errno.h>
+# include <netdb.h>
+# include <signal.h>
+# include <unistd.h>
+# include <fcntl.h>
+
+typedef int SOCKET;
+# define INVALID_SOCKET -1
+# define SOCKET_ERROR -1
+
+#elif defined(Q_OS_WIN)
+# include <winsock2.h>
+#endif
+
+Q_DECLARE_METATYPE(QVector<QUrl>)
+
+class tst_NetworkRemoteStressTest : public QObject
+{
+    Q_OBJECT
+public:
+    enum { AttemptCount = 100 };
+    tst_NetworkRemoteStressTest();
+
+    qint64 byteCounter;
+    QNetworkAccessManager manager;
+    QVector<QUrl> httpUrls, httpsUrls, mixedUrls;
+    bool intermediateDebug;
+
+private:
+    void clearManager();
+
+public slots:
+    void initTestCase_data();
+    void init();
+
+    void slotReadAll() { byteCounter += static_cast<QIODevice *>(sender())->readAll().size(); }
+
+private Q_SLOTS:
+    void blockingSequentialRemoteHosts();
+    void sequentialRemoteHosts();
+    void parallelRemoteHosts_data();
+    void parallelRemoteHosts();
+    void namRemoteGet_data();
+    void namRemoteGet();
+};
+
+tst_NetworkRemoteStressTest::tst_NetworkRemoteStressTest()
+    : intermediateDebug(qgetenv("STRESSDEBUG").toInt() > 0)
+{
+#ifdef Q_OS_WIN
+    WSAData wsadata;
+
+    // IPv6 requires Winsock v2.0 or better.
+    WSAStartup(MAKEWORD(2,0), &wsadata);
+#elif defined(Q_OS_UNIX) && !defined(Q_OS_SYMBIAN)
+    ::signal(SIGALRM, SIG_IGN);
+#endif
+
+    QFile urlList(":/url-list.txt");
+    if (urlList.open(QIODevice::ReadOnly)) {
+        while (!urlList.atEnd()) {
+            QByteArray line = urlList.readLine().trimmed();
+            QUrl url = QUrl::fromEncoded(line);
+            if (url.scheme() == "http") {
+                httpUrls << url;
+                mixedUrls << url;
+            } else if (url.scheme() == "https") {
+                httpsUrls << url;
+                mixedUrls << url;
+            }
+        }
+    }
+
+    httpUrls << httpUrls;
+    httpsUrls << httpsUrls;
+}
+
+void tst_NetworkRemoteStressTest::initTestCase_data()
+{
+    QTest::addColumn<QVector<QUrl> >("urlList");
+    QTest::addColumn<bool>("useSslSocket");
+
+    QTest::newRow("no-ssl") << httpUrls << false;
+//    QTest::newRow("no-ssl-in-sslsocket") << httpUrls << true;
+    QTest::newRow("ssl") << httpsUrls << true;
+    QTest::newRow("mixed") << mixedUrls << false;
+//    QTest::newRow("mixed-in-sslsocket") << mixedUrls << true;
+}
+
+void tst_NetworkRemoteStressTest::init()
+{
+    // clear the internal cache
+#ifndef QT_BUILD_INTERNAL
+    if (strncmp(QTest::currentTestFunction(), "nam") == 0)
+        QSKIP("QNetworkAccessManager tests disabled", SkipAll);
+#endif
+}
+
+void tst_NetworkRemoteStressTest::clearManager()
+{
+#ifdef QT_BUILD_INTERNAL
+    QNetworkAccessManagerPrivate::clearCache(&manager);
+    manager.setProxy(QNetworkProxy());
+    manager.setCache(0);
+#endif
+}
+
+bool nativeLookup(const char *hostname, int port, QByteArray &buf)
+{
+#if !defined(QT_NO_GETADDRINFO) && 0
+    addrinfo *res = 0;
+    struct addrinfo hints;
+    memset(&hints, 0, sizeof(hints));
+    hints.ai_family = PF_UNSPEC;
+
+    int result = getaddrinfo(QUrl::toAce(hostname).constData(), QByteArray::number(port).constData(), &hints, &res);
+    if (!result)
+        return false;
+    for (addrinfo *node = res; node; node = node->ai_next) {
+        if (node->ai_family == AF_INET) {
+            buf = QByteArray((char *)node->ai_addr, node->ai_addrlen);
+            break;
+        }
+    }
+    freeaddrinfo(res);
+#else
+    hostent *result = gethostbyname(hostname);
+    if (!result || result->h_addrtype != AF_INET)
+        return false;
+
+    struct sockaddr_in s;
+    s.sin_family = AF_INET;
+    s.sin_port = htons(port);
+    s.sin_addr =  *(struct in_addr *) result->h_addr_list[0];
+
+    buf = QByteArray((char *)&s, sizeof s);
+#endif
+
+    return !buf.isEmpty();
+}
+
+bool nativeSelect(int fd, int timeout, bool selectForWrite)
+{
+    if (timeout < 0)
+        return false;
+
+    // wait for connected
+    fd_set fds, fde;
+    FD_ZERO(&fds);
+    FD_ZERO(&fde);
+    FD_SET(fd, &fds);
+    FD_SET(fd, &fde);
+
+    int ret;
+    do {
+        struct timeval tv;
+        tv.tv_sec = timeout / 1000;
+        tv.tv_usec = timeout % 1000;
+        if (selectForWrite)
+            ret = ::select(fd + 1, 0, &fds, &fde, &tv);
+        else
+            ret = ::select(fd + 1, &fds, 0, &fde, &tv);
+    } while (ret == -1 && errno == EINTR);
+    return ret != 0;
+}
+
+void tst_NetworkRemoteStressTest::blockingSequentialRemoteHosts()
+{
+    QFETCH_GLOBAL(QVector<QUrl>, urlList);
+    QFETCH_GLOBAL(bool, useSslSocket);
+
+    qint64 totalBytes = 0;
+    QElapsedTimer outerTimer;
+    outerTimer.start();
+
+    for (int i = 0; i < urlList.size(); ++i) {
+        const QUrl &url = urlList.at(i);
+        bool isHttps = url.scheme() == "https";
+        QElapsedTimer timeout;
+        byteCounter = 0;
+        timeout.start();
+
+        QSharedPointer<QTcpSocket> socket;
+        if (useSslSocket || isHttps) {
+            socket = QSharedPointer<QTcpSocket>(new QSslSocket);
+        } else {
+            socket = QSharedPointer<QTcpSocket>(new QTcpSocket);
+        }
+
+        socket->connectToHost(url.host(), url.port(isHttps ? 443 : 80));
+        QVERIFY2(socket->waitForConnected(10000), "Timeout connecting to " + url.encodedHost());
+
+        if (isHttps) {
+            static_cast<QSslSocket *>(socket.data())->setProtocol(QSsl::TlsV1);
+            static_cast<QSslSocket *>(socket.data())->startClientEncryption();
+            static_cast<QSslSocket *>(socket.data())->ignoreSslErrors();
+            QVERIFY2(static_cast<QSslSocket *>(socket.data())->waitForEncrypted(10000), "Timeout starting TLS with " + url.encodedHost());
+        }
+
+        socket->write("GET " + url.toEncoded(QUrl::RemoveScheme | QUrl::RemoveAuthority | QUrl::RemoveFragment) + " HTTP/1.0\r\n"
+                      "Connection: close\r\n"
+                      "User-Agent: tst_QTcpSocket_stresstest/1.0\r\n"
+                      "Host: " + url.encodedHost() + "\r\n"
+                      "\r\n");
+        while (socket->bytesToWrite())
+            QVERIFY2(socket->waitForBytesWritten(10000), "Timeout writing to " + url.encodedHost());
+
+        while (socket->state() == QAbstractSocket::ConnectedState && !timeout.hasExpired(10000)) {
+            socket->waitForReadyRead(10000);
+            byteCounter += socket->readAll().size(); // discard
+        }
+        QVERIFY2(!timeout.hasExpired(10000), "Timeout reading from " + url.encodedHost());
+
+        totalBytes += byteCounter;
+        if (intermediateDebug) {
+            double rate = (byteCounter * 1.0 / timeout.elapsed());
+            qDebug() << i << url << byteCounter << "bytes in" << timeout.elapsed() << "ms:"
+                    << (rate / 1024.0 * 1000) << "kB/s";
+        }
+    }
+    qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 * 1000 / outerTimer.elapsed()) << "kB/s";
+}
+
+void tst_NetworkRemoteStressTest::sequentialRemoteHosts()
+{
+    QFETCH_GLOBAL(QVector<QUrl>, urlList);
+    QFETCH_GLOBAL(bool, useSslSocket);
+
+    qint64 totalBytes = 0;
+    QElapsedTimer outerTimer;
+    outerTimer.start();
+
+    for (int i = 0; i < urlList.size(); ++i) {
+        const QUrl &url = urlList.at(i);
+        bool isHttps = url.scheme() == "https";
+        QElapsedTimer timeout;
+        byteCounter = 0;
+        timeout.start();
+
+        QSharedPointer<QTcpSocket> socket;
+        if (useSslSocket || isHttps) {
+            socket = QSharedPointer<QTcpSocket>(new QSslSocket);
+        } else {
+            socket = QSharedPointer<QTcpSocket>(new QTcpSocket);
+        }
+        if (isHttps) {
+            static_cast<QSslSocket *>(socket.data())->setProtocol(QSsl::TlsV1);
+            static_cast<QSslSocket *>(socket.data())->connectToHostEncrypted(url.host(), url.port(443));
+            static_cast<QSslSocket *>(socket.data())->ignoreSslErrors();
+        } else {
+            socket->connectToHost(url.host(), url.port(80));
+        }
+
+        socket->write("GET " + url.toEncoded(QUrl::RemoveScheme | QUrl::RemoveAuthority | QUrl::RemoveFragment) + " HTTP/1.0\r\n"
+                      "Connection: close\r\n"
+                      "User-Agent: tst_QTcpSocket_stresstest/1.0\r\n"
+                      "Host: " + url.encodedHost() + "\r\n"
+                      "\r\n");
+        connect(socket.data(), SIGNAL(readyRead()), SLOT(slotReadAll()));
+
+        QTestEventLoop::instance().connect(socket.data(), SIGNAL(disconnected()), SLOT(exitLoop()));
+        QTestEventLoop::instance().enterLoop(30);
+        QVERIFY2(!QTestEventLoop::instance().timeout(), "Timeout with " + url.encodedHost() + "; "
+                 + QByteArray::number(socket->bytesToWrite()) + " bytes to write");
+
+        totalBytes += byteCounter;
+        if (intermediateDebug) {
+            double rate = (byteCounter * 1.0 / timeout.elapsed());
+            qDebug() << i << url << byteCounter << "bytes in" << timeout.elapsed() << "ms:"
+                    << (rate / 1024.0 * 1000) << "kB/s";
+        }
+    }
+    qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 * 1000 / outerTimer.elapsed()) << "kB/s";
+}
+
+void tst_NetworkRemoteStressTest::parallelRemoteHosts_data()
+{
+    QTest::addColumn<int>("parallelAttempts");
+    QTest::newRow("1") << 1;
+    QTest::newRow("2") << 2;
+    QTest::newRow("4") << 4;
+    QTest::newRow("5") << 5;
+    QTest::newRow("6") << 6;
+    QTest::newRow("8") << 8;
+    QTest::newRow("10") << 10;
+    QTest::newRow("25") << 25;
+    QTest::newRow("500") << 500;
+}
+
+void tst_NetworkRemoteStressTest::parallelRemoteHosts()
+{
+    QFETCH_GLOBAL(QVector<QUrl>, urlList);
+    QFETCH_GLOBAL(bool, useSslSocket);
+
+    QFETCH(int, parallelAttempts);
+
+    qint64 totalBytes = 0;
+    QElapsedTimer outerTimer;
+    outerTimer.start();
+
+    QVector<QUrl>::ConstIterator it = urlList.constBegin();
+    while (it != urlList.constEnd()) {
+        QElapsedTimer timeout;
+        byteCounter = 0;
+        timeout.start();
+
+        QVector<QSharedPointer<QTcpSocket> > sockets;
+        sockets.reserve(parallelAttempts);
+        for (int j = 0; j < parallelAttempts && it != urlList.constEnd(); ++j, ++it) {
+            const QUrl &url = *it;
+            bool isHttps = url.scheme() == "https";
+            QTcpSocket *socket;
+            if (useSslSocket || isHttps)
+                socket = new QSslSocket;
+            else
+                socket = new QTcpSocket;
+            if (isHttps) {
+                static_cast<QSslSocket *>(socket)->setProtocol(QSsl::TlsV1);
+                static_cast<QSslSocket *>(socket)->connectToHostEncrypted(url.host(), url.port(443));
+                static_cast<QSslSocket *>(socket)->ignoreSslErrors();
+            } else {
+                socket->connectToHost(url.host(), url.port(isHttps ? 443 : 80));
+            }
+
+            socket->write("GET " + url.toEncoded(QUrl::RemoveScheme | QUrl::RemoveAuthority | QUrl::RemoveFragment) + " HTTP/1.0\r\n"
+                          "Connection: close\r\n"
+                          "User-Agent: tst_QTcpSocket_stresstest/1.0\r\n"
+                          "Host: " + url.encodedHost() + "\r\n"
+                          "\r\n");
+            connect(socket, SIGNAL(readyRead()), SLOT(slotReadAll()));
+            QTestEventLoop::instance().connect(socket, SIGNAL(disconnected()), SLOT(exitLoop()));
+            socket->setProperty("remoteUrl", url);
+
+            sockets.append(QSharedPointer<QTcpSocket>(socket));
+        }
+
+        while (!timeout.hasExpired(10000)) {
+            QTestEventLoop::instance().enterLoop(10);
+            int done = 0;
+            for (int j = 0; j < sockets.size(); ++j)
+                done += sockets[j]->state() == QAbstractSocket::UnconnectedState ? 1 : 0;
+            if (done == sockets.size())
+                break;
+        }
+        for (int j = 0; j < sockets.size(); ++j)
+            if (sockets[j]->state() != QAbstractSocket::UnconnectedState) {
+                qDebug() << "Socket to" << sockets[j]->property("remoteUrl").toUrl() << "still open with"
+                        << sockets[j]->bytesToWrite() << "bytes to write";
+                QFAIL("Timed out");
+            }
+
+        totalBytes += byteCounter;
+        if (intermediateDebug) {
+            double rate = (byteCounter * 1.0 / timeout.elapsed());
+            qDebug() << byteCounter << "bytes in" << timeout.elapsed() << "ms:"
+                    << (rate / 1024.0 * 1000) << "kB/s";
+        }
+    }
+    qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 * 1000 / outerTimer.elapsed()) << "kB/s";
+}
+
+void tst_NetworkRemoteStressTest::namRemoteGet_data()
+{
+    QTest::addColumn<int>("parallelAttempts");
+    QTest::newRow("1") << 1;
+    QTest::newRow("2") << 2;
+    QTest::newRow("4") << 4;
+    QTest::newRow("5") << 5;
+    QTest::newRow("6") << 6;
+    QTest::newRow("8") << 8;
+    QTest::newRow("10") << 10;
+    QTest::newRow("25") << 25;
+    QTest::newRow("500") << 500;
+}
+
+void tst_NetworkRemoteStressTest::namRemoteGet()
+{
+    QFETCH_GLOBAL(QVector<QUrl>, urlList);
+
+    QFETCH(int, parallelAttempts);
+    bool pipelineAllowed = false;// QFETCH(bool, pipelineAllowed);
+
+    qint64 totalBytes = 0;
+    QElapsedTimer outerTimer;
+    outerTimer.start();
+
+    QVector<QUrl>::ConstIterator it = urlList.constBegin();
+    while (it != urlList.constEnd()) {
+        QElapsedTimer timeout;
+        byteCounter = 0;
+        timeout.start();
+
+        QNetworkRequest req;
+        req.setAttribute(QNetworkRequest::HttpPipeliningAllowedAttribute, pipelineAllowed);
+
+        QVector<QSharedPointer<QNetworkReply> > replies;
+        replies.reserve(parallelAttempts);
+        for (int j = 0; j < parallelAttempts && it != urlList.constEnd(); ++j) {
+            req.setUrl(*it++);
+            QNetworkReply *r = manager.get(req);
+            r->ignoreSslErrors();
+
+            connect(r, SIGNAL(readyRead()), SLOT(slotReadAll()));
+            QTestEventLoop::instance().connect(r, SIGNAL(finished()), SLOT(exitLoop()));
+
+            replies.append(QSharedPointer<QNetworkReply>(r));
+        }
+
+        while (!timeout.hasExpired(30000)) {
+            QTestEventLoop::instance().enterLoop(30 - timeout.elapsed() / 1000);
+            int done = 0;
+            for (int j = 0; j < replies.size(); ++j)
+                done += replies[j]->isFinished() ? 1 : 0;
+            if (done == replies.size())
+                break;
+        }
+        if (timeout.hasExpired(30000)) {
+            for (int j = 0; j < replies.size(); ++j)
+                if (!replies[j]->isFinished())
+                    qDebug() << "Request" << replies[j]->url() << "not finished";
+            QFAIL("Timed out");
+        }
+        replies.clear();
+
+        totalBytes += byteCounter;
+        if (intermediateDebug) {
+            double rate = (byteCounter * 1.0 / timeout.elapsed());
+            qDebug() << byteCounter << "bytes in" << timeout.elapsed() << "ms:"
+                    << (rate / 1024.0 * 1000) << "kB/s";
+        }
+    }
+    qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 * 1000 / outerTimer.elapsed()) << "kB/s";
+}
+
+QTEST_MAIN(tst_NetworkRemoteStressTest);
+
+#include "tst_network_remote_stresstest.moc"
diff --git a/tests/manual/network_remote_stresstest/url-list.qrc b/tests/manual/network_remote_stresstest/url-list.qrc
new file mode 100644
index 0000000..ec529e5
--- /dev/null
+++ b/tests/manual/network_remote_stresstest/url-list.qrc
@@ -0,0 +1,5 @@
+<RCC>
+    <qresource prefix="/">
+        <file>url-list.txt</file>
+    </qresource>
+</RCC>
diff --git a/tests/manual/network_remote_stresstest/url-list.txt b/tests/manual/network_remote_stresstest/url-list.txt
new file mode 100644
index 0000000..edbf7e1
--- /dev/null
+++ b/tests/manual/network_remote_stresstest/url-list.txt
@@ -0,0 +1,62 @@
+http://www.digicert.com/CACerts/DigiCertAssuredIDRootCA.crt
+http://www.digicert.com/CACerts/DigiCertGlobalRootCA.crt
+http://www.digicert.com/CACerts/DigiCertHighAssuranceEVRootCA.crt
+http://www.quovadis.bm/public/qvrca2.crt
+http://www.quovadis.bm/public/qvrca3.crt
+https://secure.globalsign.net/cacert/root-r2.crt
+http://secure.globalsign.net/cacert/Root-R1.crt
+http://www.certplus.com/PC/certplus_class2.pem
+https://www.startssl.com/certs/ca.crt
+http://www.turktrust.com.tr/sertifikalar/TURKTRUST_Elektronik_Sertifika_Hizmet_Saglayicisi.crt
+http://www.turktrust.com.tr/sertifikalar/kok_s2.crt
+http://crt.comodoca.com/COMODOCertificationAuthority.crt
+http://crt.comodoca.com/COMODOECCCertificationAuthority.crt
+https://bugzilla.mozilla.org/attachment.cgi?id=368998
+https://bugzilla.mozilla.org/attachment.cgi?id=335538
+https://bugzilla.mozilla.org/attachment.cgi?id=304810
+https://www.securetrust.com/legal/STCA.txt
+https://www.securetrust.com/legal/SGCA.txt
+http://www.securetrust.com/legal/XGCA.txt
+http://www.diginotar.nl/files/Rootcertificaten/DigiNotar%20root%20CA2007.crt
+https://bugzilla.mozilla.org/attachment.cgi?id=294057
+https://bugzilla.mozilla.org/attachment.cgi?id=368997
+https://bugzilla.mozilla.org/attachment.cgi?id=306731
+https://certs.starfieldtech.com/repository/valicert_class2_root.crt
+https://certs.godaddy.com/repository/gd-class2-root.crt
+https://certs.starfieldtech.com/repository/sf-class2-root.crt
+ftp://ftp.networksolutions.com/certs/netsolevroot.crt
+https://bugzilla.mozilla.org/attachment.cgi?id=335551
+https://bugzilla.mozilla.org/attachment.cgi?id=369000
+https://bugzilla.mozilla.org/attachment.cgi?id=306736
+https://bugzilla.mozilla.org/attachment.cgi?id=267983
+https://swisssign.net/cgi-bin/authority/download?ca=50AFCC078715476F38C5B465D1DE95AAE9DF9CCC&into=browser
+https://swisssign.net/cgi-bin/authority/download?ca=5B257B96A465517EB839F3C078665EE83AE7F0EE&into=browser
+https://swisssign.net/cgi-bin/authority/download?ca=17A0CDC1E441B63A5B3BCB459DBD1CC298FA8658&into=browser
+http://apps.identrust.com/roots/DSTROOTCAX3.cer
+https://bugzilla.mozilla.org/attachment.cgi?id=277051
+http://www.ssi.gouv.fr/IMG/crt/igca-rsa.crt
+http://www.e-szigno.hu/RootCA.crt
+http://www.s-trust.de/service_support/zertifikatsmanagement/verzeichnisdienste/download_wurzelzertifikate/ordner_crt_dateien/authentication.crt
+http://www.trustcenter.de/media/class_2_ii.der
+http://www.trustcenter.de/media/class_3_ii.der
+http://www.trustcenter.de/media/Universal_CA-I.der
+http://www.certigna.fr/ca/ACcertigna.crt
+https://repository.secomtrust.net/EV-Root1/EVRoot1ca.cer
+http://fedir.comsign.co.il/cacert/ComsignCA.crt
+http://fedir.comsign.co.il/cacert/ComsignSecuredCA.crt
+http://crl.pki.wellsfargo.com/wsprca.crt
+http://cacert.omniroot.com/ct_root_ss.crt
+http://www.kamusm.gov.tr/BilgiDeposu/KOKSHS.v3.crt
+https://bugzilla.mozilla.org/attachment.cgi?id=380381
+http://210.71.154.6/download/ROOTeCA.cer
+https://bugzilla.mozilla.org/attachment.cgi?id=359654
+http://www.gpki.go.jp/apcaself/APCAroot.der
+https://bugzilla.mozilla.org/attachment.cgi?id=405525
+https://bugzilla.mozilla.org/attachment.cgi?id=361508
+https://bugzilla.mozilla.org/attachment.cgi?id=361508
+http://www.hongkongpost.gov.hk/product/download/root/img/smartid_rt.cacert
+http://www.sk.ee/files/JUUR-SK.der
+https://bugzilla.mozilla.org/attachment.cgi?id=408102
+http://www.disig.eu/ca/cert/ca_disig.der
+https://bugzilla.mozilla.org/attachment.cgi?id=365241
+https://www2.jcsinc.co.jp/repository/certs/SSAD-rca.der
diff --git a/tests/manual/network_stresstest/minihttpserver.cpp b/tests/manual/network_stresstest/minihttpserver.cpp
new file mode 100644
index 0000000..3630674
--- /dev/null
+++ b/tests/manual/network_stresstest/minihttpserver.cpp
@@ -0,0 +1,214 @@
+/****************************************************************************
+**
+** Copyright (C) 2010 Nokia Corporation and/or its subsidiary(-ies).
+** All rights reserved.
+** Contact: Nokia Corporation (qt-info@nokia.com)
+**
+** This file is part of the FOO module 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 "minihttpserver.h"
+#include <QtCore/QFile>
+#include <QtCore/QSemaphore>
+#include <QtCore/QUrl>
+#include <QtNetwork/QTcpServer>
+#include <QtNetwork/QTcpSocket>
+
+MiniHttpServer::MiniHttpServer(QObject *parent) :
+    QThread(parent)
+{
+    readyToGo = new QSemaphore;
+    start();
+    readyToGo->acquire();
+    delete readyToGo;
+}
+
+MiniHttpServer::~MiniHttpServer()
+{
+    quitObject->deleteLater();
+    wait();
+}
+
+void MiniHttpServer::run()
+{
+    server = new QTcpServer;
+    server->listen(QHostAddress::LocalHost);
+    portnum = server->serverPort();
+    connect(server, SIGNAL(newConnection()), this, SLOT(handleConnection()), Qt::DirectConnection);
+
+    quitObject = new QObject;
+    connect(quitObject, SIGNAL(destroyed()), this, SLOT(quit()), Qt::DirectConnection);
+
+    readyToGo->release();
+    exec();
+
+    // cleanup
+    delete server;
+}
+
+void MiniHttpServer::handleConnection()
+{
+    while (server->hasPendingConnections()) {
+        QTcpSocket *socket = server->nextPendingConnection();
+        new MiniHttpServerConnection(socket); // handles its own lifetime
+    }
+}
+
+MiniHttpServerConnection::MiniHttpServerConnection(QTcpSocket *socket)
+    : QObject(socket), socket(socket), source(0)
+{
+    connect(socket, SIGNAL(readyRead()), SLOT(handleReadyRead()));
+    connect(socket, SIGNAL(bytesWritten(qint64)), SLOT(handleBytesWritten()));
+    connect(socket, SIGNAL(disconnected()), SLOT(handleDisconnected()));
+
+    timeout.setInterval(30000);
+    timeout.setSingleShot(true);
+    connect(&timeout, SIGNAL(timeout()), SLOT(handleTimeout()));
+    timeout.start();
+}
+
+void MiniHttpServerConnection::sendError500()
+{
+    static const char body[] =
+            "HTTP/1.1 500 Server Error\r\n"
+            "Connection: close\r\n"
+            "Content-Length: 0\r\n"
+            "\r\n";
+    socket->write(body, strlen(body));
+    socket->disconnectFromHost();
+}
+
+void MiniHttpServerConnection::sendError404()
+{
+    static const char body1[] =
+            "HTTP/1.1 404 File not found\r\n"
+            "Content-Length: 0\r\n";
+    socket->write(body1, strlen(body1));
+    if (connectionClose) {
+        socket->write("Connection: close\r\n\r\n");
+        socket->disconnectFromHost();
+    } else {
+        socket->write("\r\n");
+        handlePendingRequest();
+    }
+}
+
+void MiniHttpServerConnection::handlePendingRequest()
+{
+    int endOfRequest = buffer.indexOf("\r\n\r\n");
+    if (endOfRequest == -1)
+        return; // nothing to do
+
+    QByteArray request = buffer.left(endOfRequest);
+    buffer = buffer.mid(endOfRequest + 4);
+    //qDebug("request: %s", request.constData());
+
+    if (!request.startsWith("GET ")) {
+        sendError500();
+        return;
+    }
+
+    int eol = request.indexOf("\r\n");
+    static const char http11[] = " HTTP/1.1";
+    if (memcmp(request.data() + eol - strlen(http11), http11, strlen(http11)) != 0) {
+        sendError500();
+        return;
+    }
+
+    QUrl uri = QUrl::fromEncoded(request.mid(4, eol - strlen(http11) - 4));
+    source.setFileName(":" + uri.path());
+
+    // connection-close?
+    request = request.toLower();
+    connectionClose = request.contains("\r\nconnection: close\r\n");
+
+    if (!source.open(QIODevice::ReadOnly)) {
+        sendError404();
+        return;
+    }
+
+    // success
+    timeout.stop();
+    static const char body[] =
+            "HTTP/1.1 200 Ok\r\n"
+            "Content-Type: text/plain\r\n"
+            "Content-Length: ";
+    socket->write(body, strlen(body));
+    socket->write(QByteArray::number(source.size()));
+    if (connectionClose)
+        socket->write("\r\nConnection: close");
+    socket->write("\r\n\r\n");
+
+    handleBytesWritten();
+}
+
+void MiniHttpServerConnection::handleReadyRead()
+{
+    buffer += socket->readAll();
+    if (!source.isOpen())
+        handlePendingRequest();
+}
+
+void MiniHttpServerConnection::handleDisconnected()
+{
+    socket->deleteLater(); // will delete us too
+}
+
+void MiniHttpServerConnection::handleBytesWritten()
+{
+    qint64 maxBytes = qMin<qint64>(128*1024, source.bytesAvailable());
+    maxBytes = qMin(maxBytes, 128*1024 - socket->bytesToWrite());
+    if (maxBytes < 0)
+        return;
+
+    socket->write(source.read(maxBytes));
+
+    if (source.atEnd()) {
+        // file ended
+        source.close();
+        if (connectionClose) {
+            socket->disconnectFromHost();
+        } else {
+            timeout.start();
+            handlePendingRequest();
+        }
+    }
+}
+
+void MiniHttpServerConnection::handleTimeout()
+{
+    socket->disconnectFromHost();
+}
diff --git a/tests/manual/network_stresstest/minihttpserver.h b/tests/manual/network_stresstest/minihttpserver.h
new file mode 100644
index 0000000..9fcc8fc
--- /dev/null
+++ b/tests/manual/network_stresstest/minihttpserver.h
@@ -0,0 +1,99 @@
+/****************************************************************************
+**
+** Copyright (C) 2010 Nokia Corporation and/or its subsidiary(-ies).
+** All rights reserved.
+** Contact: Nokia Corporation (qt-info@nokia.com)
+**
+** This file is part of the FOO module 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$
+**
+****************************************************************************/
+
+
+#ifndef MINIHTTPSERVER_H
+#define MINIHTTPSERVER_H
+
+#include <QtCore/QThread>
+#include <QtCore/QFile>
+#include <QtCore/QTimer>
+
+class QFile;
+class QSemaphore;
+class QTcpServer;
+class QTcpSocket;
+
+class MiniHttpServer : public QThread
+{
+    Q_OBJECT
+public:
+    explicit MiniHttpServer(QObject *parent = 0);
+    ~MiniHttpServer();
+
+    int port() { return portnum; }
+
+protected:
+    void run();
+
+private slots:
+    void handleConnection();
+
+private:
+    QTcpServer *server;
+    QObject *quitObject;
+    QSemaphore *readyToGo;
+    int portnum;
+};
+
+class MiniHttpServerConnection: public QObject
+{
+    Q_OBJECT
+    QTcpSocket * const socket;
+    QFile source;
+    QTimer timeout;
+    QByteArray buffer;
+    bool connectionClose;
+public:
+    explicit MiniHttpServerConnection(QTcpSocket *socket);
+
+    void sendError500();
+    void sendError404();
+    void handlePendingRequest();
+
+public slots:
+    void handleReadyRead();
+    void handleBytesWritten();
+    void handleDisconnected();
+    void handleTimeout();
+};
+
+#endif // MINIHTTPSERVER_H
diff --git a/tests/manual/network_stresstest/network_stresstest.pro b/tests/manual/network_stresstest/network_stresstest.pro
new file mode 100644
index 0000000..0e272d1
--- /dev/null
+++ b/tests/manual/network_stresstest/network_stresstest.pro
@@ -0,0 +1,12 @@
+load(qttest_p4)
+
+QT = core network
+
+SOURCES  += tst_network_stresstest.cpp \
+    minihttpserver.cpp
+
+HEADERS += \
+    minihttpserver.h
+
+RESOURCES += wwwfiles.qrc
+QMAKE_RESOURCE_FLAGS += -no-compress
diff --git a/tests/manual/network_stresstest/qtest/bigfile b/tests/manual/network_stresstest/qtest/bigfile
new file mode 100644
index 0000000..cb114a2
--- /dev/null
+++ b/tests/manual/network_stresstest/qtest/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/manual/network_stresstest/tst_network_stresstest.cpp b/tests/manual/network_stresstest/tst_network_stresstest.cpp
new file mode 100644
index 0000000..34d83e1
--- /dev/null
+++ b/tests/manual/network_stresstest/tst_network_stresstest.cpp
@@ -0,0 +1,771 @@
+/****************************************************************************
+**
+** Copyright (C) 2010 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/QThread>
+#include <QtCore/QSemaphore>
+#include <QtCore/QElapsedTimer>
+#include <QtCore/QSharedPointer>
+#include <QtCore/QVector>
+#include <QtNetwork/QTcpSocket>
+#include <QtNetwork/QNetworkReply>
+#include <QtNetwork/QNetworkAccessManager>
+
+#ifdef QT_BUILD_INTERNAL
+# include <private/qnetworkaccessmanager_p.h>
+#endif
+
+#include "minihttpserver.h"
+#include "../../auto/network-settings.h"
+
+#include <qplatformdefs.h>
+#ifdef Q_OS_UNIX
+# include <sys/types.h>
+# include <sys/socket.h>
+# include <sys/select.h>
+# include <netinet/in.h>
+# include <errno.h>
+# include <netdb.h>
+# include <signal.h>
+# include <unistd.h>
+# include <fcntl.h>
+
+typedef int SOCKET;
+# define INVALID_SOCKET -1
+# define SOCKET_ERROR -1
+
+#elif defined(Q_OS_WIN)
+# include <winsock2.h>
+#endif
+
+class tst_NetworkStressTest : public QObject
+{
+    Q_OBJECT
+public:
+    enum { AttemptCount = 100 };
+    tst_NetworkStressTest();
+    MiniHttpServer server;
+
+    qint64 byteCounter;
+    QNetworkAccessManager manager;
+    bool intermediateDebug;
+
+private:
+    void clearManager();
+
+public slots:
+    void initTestCase_data();
+    void init();
+
+    void slotReadAll() { byteCounter += static_cast<QIODevice *>(sender())->readAll().size(); }
+
+private Q_SLOTS:
+    void nativeBlockingConnectDisconnect();
+    void nativeNonBlockingConnectDisconnect();
+    void blockingConnectDisconnect();
+    void blockingPipelined();
+    void blockingMultipleRequests();
+    void connectDisconnect();
+    void parallelConnectDisconnect_data();
+    void parallelConnectDisconnect();
+    void namGet_data();
+    void namGet();
+};
+
+tst_NetworkStressTest::tst_NetworkStressTest()
+    : intermediateDebug(qgetenv("STRESSDEBUG").toInt() > 0)
+{
+#ifdef Q_OS_WIN
+    WSAData wsadata;
+
+    // IPv6 requires Winsock v2.0 or better.
+    WSAStartup(MAKEWORD(2,0), &wsadata);
+#elif defined(Q_OS_UNIX) && !defined(Q_OS_SYMBIAN)
+    ::signal(SIGALRM, SIG_IGN);
+#endif
+}
+
+void tst_NetworkStressTest::initTestCase_data()
+{
+    QTest::addColumn<bool>("isLocalhost");
+    QTest::addColumn<QString>("hostname");
+    QTest::addColumn<int>("port");
+
+    QTest::newRow("localhost") << true << "localhost" << server.port();
+    QTest::newRow("remote") << false << QtNetworkSettings::serverName() << 80;
+}
+
+void tst_NetworkStressTest::init()
+{
+    // clear the internal cache
+#ifndef QT_BUILD_INTERNAL
+    if (strncmp(QTest::currentTestFunction(), "nam") == 0)
+        QSKIP("QNetworkAccessManager tests disabled", SkipAll);
+#endif
+}
+
+void tst_NetworkStressTest::clearManager()
+{
+#ifdef QT_BUILD_INTERNAL
+    QNetworkAccessManagerPrivate::clearCache(&manager);
+    manager.setProxy(QNetworkProxy());
+    manager.setCache(0);
+#endif
+}
+
+bool nativeLookup(const char *hostname, int port, QByteArray &buf)
+{
+#if !defined(QT_NO_GETADDRINFO) && 0
+    addrinfo *res = 0;
+    struct addrinfo hints;
+    memset(&hints, 0, sizeof(hints));
+    hints.ai_family = PF_UNSPEC;
+
+    int result = getaddrinfo(QUrl::toAce(hostname).constData(), QByteArray::number(port).constData(), &hints, &res);
+    if (!result)
+        return false;
+    for (addrinfo *node = res; node; node = node->ai_next) {
+        if (node->ai_family == AF_INET) {
+            buf = QByteArray((char *)node->ai_addr, node->ai_addrlen);
+            break;
+        }
+    }
+    freeaddrinfo(res);
+#else
+    hostent *result = gethostbyname(hostname);
+    if (!result || result->h_addrtype != AF_INET)
+        return false;
+
+    struct sockaddr_in s;
+    s.sin_family = AF_INET;
+    s.sin_port = htons(port);
+    s.sin_addr =  *(struct in_addr *) result->h_addr_list[0];
+
+    buf = QByteArray((char *)&s, sizeof s);
+#endif
+
+    return !buf.isEmpty();
+}
+
+bool nativeSelect(int fd, int timeout, bool selectForWrite)
+{
+    if (timeout < 0)
+        return false;
+
+    // wait for connected
+    fd_set fds, fde;
+    FD_ZERO(&fds);
+    FD_ZERO(&fde);
+    FD_SET(fd, &fds);
+    FD_SET(fd, &fde);
+
+    int ret;
+    do {
+        struct timeval tv;
+        tv.tv_sec = timeout / 1000;
+        tv.tv_usec = timeout % 1000;
+        if (selectForWrite)
+            ret = ::select(fd + 1, 0, &fds, &fde, &tv);
+        else
+            ret = ::select(fd + 1, &fds, 0, &fde, &tv);
+    } while (ret == -1 && errno == EINTR);
+    return ret != 0;
+}
+
+void tst_NetworkStressTest::nativeBlockingConnectDisconnect()
+{
+    QFETCH_GLOBAL(QString, hostname);
+    QFETCH_GLOBAL(int, port);
+
+    qint64 totalBytes = 0;
+    QElapsedTimer outerTimer;
+    outerTimer.start();
+
+    for (int i = 0; i < AttemptCount; ++i) {
+        QElapsedTimer timeout;
+        byteCounter = 0;
+        timeout.start();
+
+#if defined(Q_OS_UNIX) && !defined(Q_OS_SYMBIAN)
+        alarm(10);
+#endif
+
+        // look up the host
+        QByteArray addr;
+        if (!nativeLookup(QUrl::toAce(hostname).constData(), port, addr))
+            QFAIL("Lookup failed");
+
+        // connect
+        SOCKET fd = ::socket(AF_INET, SOCK_STREAM, 0);
+        QVERIFY(fd != INVALID_SOCKET);
+        QVERIFY(::connect(fd, (sockaddr *)addr.data(), addr.size()) != SOCKET_ERROR);
+
+        // send request
+        {
+            QByteArray request = "GET /qtest/bigfile HTTP/1.1\r\n"
+                                 "Connection: close\r\n"
+                                 "User-Agent: tst_QTcpSocket_stresstest/1.0\r\n"
+                                 "Host: " + hostname.toLatin1() + "\r\n"
+                                 "\r\n";
+            qint64 bytesWritten = 0;
+            while (bytesWritten < request.size()) {
+                qint64 ret = ::send(fd, request.constData() + bytesWritten, request.size() - bytesWritten, 0);
+                if (ret == -1) {
+                    ::close(fd);
+                    QFAIL("Timeout");
+                }
+                bytesWritten += ret;
+            }
+        }
+
+        // receive reply
+        char buf[16384];
+        while (true) {
+            qint64 ret = ::recv(fd, buf, sizeof buf, 0);
+            if (ret == -1) {
+                ::close(fd);
+                QFAIL("Timeout");
+            } else if (ret == 0) {
+                break; // EOF
+            }
+            byteCounter += ret;
+        }
+        ::close(fd);
+
+        totalBytes += byteCounter;
+        if (intermediateDebug) {
+            double rate = (byteCounter * 1.0 / timeout.elapsed());
+            qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:"
+                    << (rate / 1024.0 / 1024 * 1000) << "MB/s";
+        }
+    }
+    qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s";
+
+#if defined(Q_OS_UNIX) && !defined(Q_OS_SYMBIAN)
+    alarm(0);
+#endif
+}
+
+void tst_NetworkStressTest::nativeNonBlockingConnectDisconnect()
+{
+    QFETCH_GLOBAL(QString, hostname);
+    QFETCH_GLOBAL(int, port);
+
+    qint64 totalBytes = 0;
+    QElapsedTimer outerTimer;
+    outerTimer.start();
+
+    for (int i = 0; i < AttemptCount; ++i) {
+        QElapsedTimer timeout;
+        byteCounter = 0;
+        timeout.start();
+
+        // look up the host
+        QByteArray addr;
+        if (!nativeLookup(QUrl::toAce(hostname).constData(), port, addr))
+            QFAIL("Lookup failed");
+
+        SOCKET fd;
+
+        {
+#if defined(Q_OS_UNIX)
+            fd = ::socket(AF_INET, SOCK_STREAM, 0);
+            QVERIFY(fd != INVALID_SOCKET);
+
+            // set the socket to non-blocking and start connecting
+# if !defined(Q_OS_VXWORKS)
+            int flags = ::fcntl(fd, F_GETFL, 0);
+            QVERIFY(flags != -1);
+            QVERIFY(::fcntl(fd, F_SETFL, flags | O_NONBLOCK) != -1);
+# else // Q_OS_VXWORKS
+            int onoff = 1;
+            QVERIFY(::ioctl(socketDescriptor, FIONBIO, &onoff) >= 0);
+# endif // Q_OS_VXWORKS
+            while (true) {
+                if (::connect(fd, (sockaddr *)addr.data(), addr.size()) == -1) {
+                    QVERIFY2(errno == EINPROGRESS, QByteArray("Error connecting: ").append(strerror(errno)).constData());
+                    QVERIFY2(nativeSelect(fd, 10000 - timeout.elapsed(), true), "Timeout");
+                } else {
+                    break; // connected
+                }
+            }
+#elif defined(Q_OS_WIN)
+            fd = ::WSASocket(AF_INET, SOCK_STREAM, 0, NULL, 0, WSA_FLAG_OVERLAPPED);
+            QVERIFY(fd != INVALID_SOCKET);
+
+            // set the socket to non-blocking and start connecting
+            unsigned long buf = v;
+            unsigned long outBuf;
+            DWORD sizeWritten = 0;
+            QVERIFY(::WSAIoctl(fd, FIONBIO, &buf, sizeof(unsigned long), &outBuf, sizeof(unsigned long), &sizeWritten, 0,0) != SOCKET_ERROR);
+
+            while (true) {
+                int connectResult = ::WSAConnect(fd, sockAddrPtr, sockAddrSize, 0,0,0,0);
+                if (connectResult == 0 || WSAGetLastError() == WSAEISCONN) {
+                    break; // connected
+                } else {
+                    QVERIFY2(WSAGetLastError() == WSAEINPROGRESS, "Unexpected error");
+                    QVERIFY2(nativeSelect(fd, 10000 - timeout.elapsed(), true), "Timeout");
+                }
+            }
+#endif
+        }
+
+        // send request
+        {
+            QByteArray request = "GET /qtest/bigfile HTTP/1.1\r\n"
+                                 "Connection: close\r\n"
+                                 "User-Agent: tst_QTcpSocket_stresstest/1.0\r\n"
+                                 "Host: " + hostname.toLatin1() + "\r\n"
+                                 "\r\n";
+            qint64 bytesWritten = 0;
+            while (bytesWritten < request.size()) {
+                qint64 ret = ::send(fd, request.constData() + bytesWritten, request.size() - bytesWritten, 0);
+                if (ret == -1 && errno != EWOULDBLOCK) {
+                    ::close(fd);
+                    QFAIL(QByteArray("Error writing: ").append(strerror(errno)).constData());
+                } else if (ret == -1) {
+                    // wait for writing
+                    QVERIFY2(nativeSelect(fd, 10000 - timeout.elapsed(), true), "Timeout");
+                    continue;
+                }
+                bytesWritten += ret;
+            }
+        }
+
+        // receive reply
+        char buf[16384];
+        while (true) {
+            qint64 ret = ::recv(fd, buf, sizeof buf, 0);
+            if (ret == -1 && errno != EWOULDBLOCK) {
+                ::close(fd);
+                QFAIL("Timeout");
+            } else if (ret == -1) {
+                // wait for reading
+                QVERIFY2(nativeSelect(fd, 10000 - timeout.elapsed(), false), "Timeout");
+            } else if (ret == 0) {
+                break; // EOF
+            }
+            byteCounter += ret;
+        }
+        ::close(fd);
+
+        totalBytes += byteCounter;
+        if (intermediateDebug) {
+            double rate = (byteCounter * 1.0 / timeout.elapsed());
+            qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:"
+                    << (rate / 1024.0 / 1024 * 1000) << "MB/s";
+        }
+    }
+    qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s";
+}
+
+void tst_NetworkStressTest::blockingConnectDisconnect()
+{
+    QFETCH_GLOBAL(QString, hostname);
+    QFETCH_GLOBAL(int, port);
+
+    qint64 totalBytes = 0;
+    QElapsedTimer outerTimer;
+    outerTimer.start();
+
+    for (int i = 0; i < AttemptCount; ++i) {
+        QElapsedTimer timeout;
+        byteCounter = 0;
+        timeout.start();
+
+        QTcpSocket socket;
+        socket.connectToHost(hostname, port);
+        QVERIFY2(socket.waitForConnected(), "Timeout");
+
+        socket.write("GET /qtest/bigfile HTTP/1.1\r\n"
+                     "Connection: close\r\n"
+                     "User-Agent: tst_QTcpSocket_stresstest/1.0\r\n"
+                     "Host: " + hostname.toLatin1() + "\r\n"
+                     "\r\n");
+        while (socket.bytesToWrite())
+            QVERIFY2(socket.waitForBytesWritten(), "Timeout");
+
+        while (socket.state() == QAbstractSocket::ConnectedState && !timeout.hasExpired(10000)) {
+            socket.waitForReadyRead();
+            byteCounter += socket.readAll().size(); // discard
+        }
+
+        totalBytes += byteCounter;
+        if (intermediateDebug) {
+            double rate = (byteCounter * 1.0 / timeout.elapsed());
+            qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:"
+                    << (rate / 1024.0 / 1024 * 1000) << "MB/s";
+        }
+    }
+    qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s";
+}
+
+void tst_NetworkStressTest::blockingPipelined()
+{
+    QFETCH_GLOBAL(QString, hostname);
+    QFETCH_GLOBAL(int, port);
+
+    qint64 totalBytes = 0;
+    QElapsedTimer outerTimer;
+    outerTimer.start();
+
+    for (int i = 0; i < AttemptCount / 2; ++i) {
+        QElapsedTimer timeout;
+        byteCounter = 0;
+        timeout.start();
+
+        QTcpSocket socket;
+        socket.connectToHost(hostname, port);
+        QVERIFY2(socket.waitForConnected(), "Timeout");
+
+        for (int j = 0 ; j < 3; ++j) {
+            if (intermediateDebug)
+                qDebug("Attempt %d%c", i, 'a' + j);
+            socket.write("GET /qtest/bigfile HTTP/1.1\r\n"
+                         "Connection: " + QByteArray(j == 2 ? "close" : "keep-alive") + "\r\n"
+                         "User-Agent: tst_QTcpSocket_stresstest/1.0\r\n"
+                         "Host: " + hostname.toLatin1() + "\r\n"
+                         "\r\n");
+            while (socket.bytesToWrite())
+                QVERIFY2(socket.waitForBytesWritten(), "Timeout");
+        }
+
+        while (socket.state() == QAbstractSocket::ConnectedState && !timeout.hasExpired(10000)) {
+            socket.waitForReadyRead();
+            byteCounter += socket.readAll().size(); // discard
+        }
+
+        totalBytes += byteCounter;
+        if (intermediateDebug) {
+            double rate = (byteCounter * 1.0 / timeout.elapsed());
+            qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:"
+                    << (rate / 1024.0 / 1024 * 1000) << "MB/s";
+        }
+    }
+    qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s";
+}
+
+void tst_NetworkStressTest::blockingMultipleRequests()
+{
+    QFETCH_GLOBAL(QString, hostname);
+    QFETCH_GLOBAL(int, port);
+
+    qint64 totalBytes = 0;
+    QElapsedTimer outerTimer;
+    outerTimer.start();
+
+    for (int i = 0; i < AttemptCount / 5; ++i) {
+        QTcpSocket socket;
+        socket.connectToHost(hostname, port);
+        QVERIFY2(socket.waitForConnected(), "Timeout");
+
+        for (int j = 0 ; j < 5; ++j) {
+            QElapsedTimer timeout;
+            byteCounter = 0;
+            timeout.start();
+
+            socket.write("GET /qtest/bigfile HTTP/1.1\r\n"
+                         "Connection: keep-alive\r\n"
+                         "User-Agent: tst_QTcpSocket_stresstest/1.0\r\n"
+                         "Host: " + hostname.toLatin1() + "\r\n"
+                         "\r\n");
+            while (socket.bytesToWrite())
+                QVERIFY2(socket.waitForBytesWritten(), "Timeout");
+
+            qint64 bytesRead = 0;
+            qint64 bytesExpected = -1;
+            QByteArray buffer;
+            while (socket.state() == QAbstractSocket::ConnectedState && !timeout.hasExpired(10000)) {
+                socket.waitForReadyRead();
+                buffer += socket.readAll();
+                byteCounter += buffer.size();
+                int pos = buffer.indexOf("\r\n\r\n");
+                if (pos == -1)
+                    continue;
+
+                bytesRead = buffer.length() - pos - 4;
+
+                buffer.truncate(pos + 2);
+                buffer = buffer.toLower();
+                pos = buffer.indexOf("\r\ncontent-length: ");
+                if (pos == -1) {
+                    qWarning() << "no content-length:" << QString(buffer);
+                    break;
+                }
+                pos += strlen("\r\ncontent-length: ");
+
+                int eol = buffer.indexOf("\r\n", pos + 2);
+                if (eol == -1) {
+                    qWarning() << "invalid header";
+                    break;
+                }
+
+                bytesExpected = buffer.mid(pos, eol - pos).toLongLong();
+                break;
+            }
+            QVERIFY(bytesExpected > 0);
+            QVERIFY2(!timeout.hasExpired(10000), "Timeout");
+
+            while (socket.state() == QAbstractSocket::ConnectedState && !timeout.hasExpired(10000) && bytesExpected > bytesRead) {
+                socket.waitForReadyRead();
+                int blocklen = socket.read(bytesExpected - bytesRead).length(); // discard
+                bytesRead += blocklen;
+                byteCounter += blocklen;
+            }
+            QVERIFY2(!timeout.hasExpired(10000), "Timeout");
+            QCOMPARE(bytesRead, bytesExpected);
+
+            totalBytes += byteCounter;
+            if (intermediateDebug) {
+                double rate = (byteCounter * 1.0 / timeout.elapsed());
+                qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:"
+                        << (rate / 1024.0 / 1024 * 1000) << "MB/s";
+            }
+        }
+
+        socket.disconnectFromHost();
+        QVERIFY(socket.state() == QAbstractSocket::UnconnectedState);
+    }
+    qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s";
+}
+
+void tst_NetworkStressTest::connectDisconnect()
+{
+    QFETCH_GLOBAL(QString, hostname);
+    QFETCH_GLOBAL(int, port);
+
+    qint64 totalBytes = 0;
+    QElapsedTimer outerTimer;
+    outerTimer.start();
+
+    for (int i = 0; i < AttemptCount; ++i) {
+        QElapsedTimer timeout;
+        byteCounter = 0;
+        timeout.start();
+
+        QTcpSocket socket;
+        socket.connectToHost(hostname, port);
+
+        socket.write("GET /qtest/bigfile HTTP/1.1\r\n"
+                     "Connection: close\r\n"
+                     "User-Agent: tst_QTcpSocket_stresstest/1.0\r\n"
+                     "Host: " + hostname.toLatin1() + "\r\n"
+                     "\r\n");
+        connect(&socket, SIGNAL(readyRead()), SLOT(slotReadAll()));
+
+        QTestEventLoop::instance().connect(&socket, SIGNAL(disconnected()), SLOT(exitLoop()));
+        QTestEventLoop::instance().enterLoop(30);
+        QVERIFY2(!QTestEventLoop::instance().timeout(), "Timeout");
+
+        totalBytes += byteCounter;
+        if (intermediateDebug) {
+            double rate = (byteCounter * 1.0 / timeout.elapsed());
+            qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:"
+                    << (rate / 1024.0 / 1024 * 1000) << "MB/s";
+        }
+    }
+    qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s";
+}
+
+void tst_NetworkStressTest::parallelConnectDisconnect_data()
+{
+    QTest::addColumn<int>("parallelAttempts");
+    QTest::newRow("1") << 1;
+    QTest::newRow("2") << 2;
+    QTest::newRow("4") << 4;
+    QTest::newRow("5") << 5;
+    QTest::newRow("6") << 6;
+    QTest::newRow("8") << 8;
+    QTest::newRow("10") << 10;
+    QTest::newRow("25") << 25;
+    QTest::newRow("100") << 100;
+    QTest::newRow("500") << 500;
+}
+
+void tst_NetworkStressTest::parallelConnectDisconnect()
+{
+    QFETCH_GLOBAL(QString, hostname);
+    QFETCH_GLOBAL(int, port);
+    QFETCH(int, parallelAttempts);
+
+    if (parallelAttempts > 100) {
+        QFETCH_GLOBAL(bool, isLocalhost);
+        if (!isLocalhost)
+            QSKIP("Localhost-only test", SkipSingle);
+    }
+
+    qint64 totalBytes = 0;
+    QElapsedTimer outerTimer;
+    outerTimer.start();
+
+    for (int i = 0; i < qMax(2, AttemptCount/qMax(2, parallelAttempts/4)); ++i) {
+        QElapsedTimer timeout;
+        byteCounter = 0;
+        timeout.start();
+
+        QTcpSocket *socket = new QTcpSocket[parallelAttempts];
+        for (int j = 0; j < parallelAttempts; ++j) {
+            socket[j].connectToHost(hostname, port);
+
+            socket[j].write("GET /qtest/bigfile HTTP/1.1\r\n"
+                            "Connection: close\r\n"
+                            "User-Agent: tst_QTcpSocket_stresstest/1.0\r\n"
+                            "Host: " + hostname.toLatin1() + "\r\n"
+                            "\r\n");
+            connect(&socket[j], SIGNAL(readyRead()), SLOT(slotReadAll()));
+
+            QTestEventLoop::instance().connect(&socket[j], SIGNAL(disconnected()), SLOT(exitLoop()));
+        }
+
+        while (!timeout.hasExpired(30000)) {
+            QTestEventLoop::instance().enterLoop(10);
+            int done = 0;
+            for (int j = 0; j < parallelAttempts; ++j)
+                done += socket[j].state() == QAbstractSocket::UnconnectedState ? 1 : 0;
+            if (done == parallelAttempts)
+                break;
+        }
+        delete[] socket;
+        QVERIFY2(!timeout.hasExpired(30000), "Timeout");
+
+        totalBytes += byteCounter;
+        if (intermediateDebug) {
+            double rate = (byteCounter * 1.0 / timeout.elapsed());
+            qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:"
+                    << (rate / 1024.0 / 1024 * 1000) << "MB/s";
+        }
+    }
+    qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s";
+}
+
+void tst_NetworkStressTest::namGet_data()
+{
+    QTest::addColumn<int>("parallelAttempts");
+    QTest::addColumn<bool>("pipelineAllowed");
+
+    QTest::newRow("1") << 1 << false;
+    QTest::newRow("1p") << 1 << true;
+    QTest::newRow("2") << 2 << false;
+    QTest::newRow("2p") << 2 << true;
+    QTest::newRow("4") << 4 << false;
+    QTest::newRow("4p") << 4 << true;
+    QTest::newRow("5") << 5 << false;
+    QTest::newRow("5p") << 5 << true;
+    QTest::newRow("6") << 6 << false;
+    QTest::newRow("6p") << 6 << true;
+    QTest::newRow("8") << 8 << false;
+    QTest::newRow("8p") << 8 << true;
+    QTest::newRow("10") << 10 << false;
+    QTest::newRow("10p") << 10 << true;
+    QTest::newRow("25") << 25 << false;
+    QTest::newRow("25p") << 25 << true;
+    QTest::newRow("100") << 100 << false;
+    QTest::newRow("100p") << 100 << true;
+    QTest::newRow("500") << 500 << false;
+    QTest::newRow("500p") << 500 << true;
+}
+
+void tst_NetworkStressTest::namGet()
+{
+    QFETCH_GLOBAL(QString, hostname);
+    QFETCH_GLOBAL(int, port);
+    QFETCH(int, parallelAttempts);
+    QFETCH(bool, pipelineAllowed);
+
+    if (parallelAttempts > 100) {
+        QFETCH_GLOBAL(bool, isLocalhost);
+        if (!isLocalhost)
+            QSKIP("Localhost-only test", SkipSingle);
+    }
+
+    qint64 totalBytes = 0;
+    QElapsedTimer outerTimer;
+    outerTimer.start();
+
+    for (int i = 0; i < qMax(2, AttemptCount/qMax(2, parallelAttempts/4)); ++i) {
+        QElapsedTimer timeout;
+        byteCounter = 0;
+        timeout.start();
+
+        QUrl url;
+        url.setScheme("http");
+        url.setHost(hostname);
+        url.setPort(port);
+        url.setEncodedPath("/qtest/bigfile");
+        QNetworkRequest req(url);
+        req.setAttribute(QNetworkRequest::HttpPipeliningAllowedAttribute, pipelineAllowed);
+
+        QVector<QSharedPointer<QNetworkReply> > replies;
+        replies.resize(parallelAttempts);
+        for (int j = 0; j < parallelAttempts; ++j) {
+            QNetworkReply *r = manager.get(req);
+
+            connect(r, SIGNAL(readyRead()), SLOT(slotReadAll()));
+            QTestEventLoop::instance().connect(r, SIGNAL(finished()), SLOT(exitLoop()));
+
+            replies[j] = QSharedPointer<QNetworkReply>(r);
+        }
+
+        while (!timeout.hasExpired(30000)) {
+            QTestEventLoop::instance().enterLoop(10);
+            int done = 0;
+            for (int j = 0; j < parallelAttempts; ++j)
+                done += replies[j]->isFinished() ? 1 : 0;
+            if (done == parallelAttempts)
+                break;
+        }
+        replies.clear();
+
+        QVERIFY2(!timeout.hasExpired(30000), "Timeout");
+        totalBytes += byteCounter;
+        if (intermediateDebug) {
+            double rate = (byteCounter * 1.0 / timeout.elapsed());
+            qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:"
+                    << (rate / 1024.0 / 1024 * 1000) << "MB/s";
+        }
+    }
+    qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s";
+}
+
+QTEST_MAIN(tst_NetworkStressTest);
+
+#include "tst_network_stresstest.moc"
diff --git a/tests/manual/network_stresstest/wwwfiles.qrc b/tests/manual/network_stresstest/wwwfiles.qrc
new file mode 100644
index 0000000..4d602a1
--- /dev/null
+++ b/tests/manual/network_stresstest/wwwfiles.qrc
@@ -0,0 +1,5 @@
+<RCC>
+    <qresource prefix="/">
+        <file>qtest</file>
+    </qresource>
+</RCC>