Merge branch '4.7' of scm.dev.nokia.troll.no:qt/oslo-staging-1 into 4.7-integration

* '4.7' of scm.dev.nokia.troll.no:qt/oslo-staging-1: (71 commits) Autotest: increase wait time to 3s on Windows to bypass 2s-granularity limitation Autotest: update to the new values for the locale do not expand variables in read()'s file name remove ability to use break() a block outside any loop don't add -unix to the qmake command line Increase the timeout for the QNAM getter test to 30 seconds Remove unstable hosts from the list qdoc: Output TOC for more class ref pages. Other fixes to the remote network stresstester Fix SSL connection problem. Make sure we don't try URLs that aren't HTTP or HTTPS Fix menu bar visibility. Add SSL remote host tests Split the remote and the local tests in two, in preparation for SSL tests Add tests for remote hosts Change the way we calculate the average transfer rates. Finish renaming Move these tests to tests/manual. Add a QNetworkAccessManager stresstest Add a non-blocking native function too ...
author: Qt Continuous Integration System <qt-info@nokia.com> 2010-04-17 18:30:02 (GMT)
committer: Qt Continuous Integration System <qt-info@nokia.com> 2010-04-17 18:30:02 (GMT)
commit: 66620e60c9526baf0d3c7a7198e3ab15d9abc0f8 (patch)
tree: 10a0fd8097aa2322fd91fe477b5b44e62d850396 /tests
parent: fd36b47e8758562fc9ff350f292fc9ae9ed91d4e (diff)
parent: 14845c8f3bba8437a89fa0843a884a5bdd2ad07f (diff)
download: Qt-66620e60c9526baf0d3c7a7198e3ab15d9abc0f8.zip
Qt-66620e60c9526baf0d3c7a7198e3ab15d9abc0f8.tar.gz
Qt-66620e60c9526baf0d3c7a7198e3ab15d9abc0f8.tar.bz2
28 files changed, 20021 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/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>
author	Qt Continuous Integration System <qt-info@nokia.com>	2010-04-17 18:30:02 (GMT)
committer	Qt Continuous Integration System <qt-info@nokia.com>	2010-04-17 18:30:02 (GMT)
commit	66620e60c9526baf0d3c7a7198e3ab15d9abc0f8 (patch)
tree	10a0fd8097aa2322fd91fe477b5b44e62d850396 /tests
parent	fd36b47e8758562fc9ff350f292fc9ae9ed91d4e (diff)
parent	14845c8f3bba8437a89fa0843a884a5bdd2ad07f (diff)
download	Qt-66620e60c9526baf0d3c7a7198e3ab15d9abc0f8.zip Qt-66620e60c9526baf0d3c7a7198e3ab15d9abc0f8.tar.gz Qt-66620e60c9526baf0d3c7a7198e3ab15d9abc0f8.tar.bz2