Merge branch '4.7' of git@scm.dev.nokia.troll.no:qt/qt-qml into 4.7

133 files changed, 26279 insertions, 130 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/declarative/declarative.pro b/tests/auto/declarative/declarative.pro
index 58371c1..9b3b3d0 100644
--- a/tests/auto/declarative/declarative.pro
+++ b/tests/auto/declarative/declarative.pro
@@ -64,6 +64,7 @@ SUBDIRS += \
            qdeclarativeimageprovider \       # Cover
            qdeclarativestyledtext \          # Cover
            qdeclarativesqldatabase \         # Cover
+           qdeclarativevisualdatamodel \     # Cover
            qmlvisual                    # Cover
 
 contains(QT_CONFIG, webkit) {
diff --git a/tests/auto/declarative/qdeclarativeanchors/tst_qdeclarativeanchors.cpp b/tests/auto/declarative/qdeclarativeanchors/tst_qdeclarativeanchors.cpp
index 06a8f64..dff62c7 100644
--- a/tests/auto/declarative/qdeclarativeanchors/tst_qdeclarativeanchors.cpp
+++ b/tests/auto/declarative/qdeclarativeanchors/tst_qdeclarativeanchors.cpp
@@ -49,7 +49,7 @@
 #include <private/qdeclarativetext_p.h>
 #include <QtDeclarative/private/qdeclarativeanchors_p_p.h>
 
-Q_DECLARE_METATYPE(QDeclarativeAnchors::UsedAnchor)
+Q_DECLARE_METATYPE(QDeclarativeAnchors::Anchor)
 Q_DECLARE_METATYPE(QDeclarativeAnchorLine::AnchorLine)
 
 
@@ -367,7 +367,7 @@ void tst_qdeclarativeanchors::reset()
 {
     QFETCH(QString, side);
     QFETCH(QDeclarativeAnchorLine::AnchorLine, anchorLine);
-    QFETCH(QDeclarativeAnchors::UsedAnchor, usedAnchor);
+    QFETCH(QDeclarativeAnchors::Anchor, usedAnchor);
 
     QDeclarativeItem *baseItem = new QDeclarativeItem;
 
@@ -394,16 +394,16 @@ void tst_qdeclarativeanchors::reset_data()
 {
     QTest::addColumn<QString>("side");
     QTest::addColumn<QDeclarativeAnchorLine::AnchorLine>("anchorLine");
-    QTest::addColumn<QDeclarativeAnchors::UsedAnchor>("usedAnchor");
+    QTest::addColumn<QDeclarativeAnchors::Anchor>("usedAnchor");
 
-    QTest::newRow("left") << "left" << QDeclarativeAnchorLine::Left << QDeclarativeAnchors::HasLeftAnchor;
-    QTest::newRow("top") << "top" << QDeclarativeAnchorLine::Top << QDeclarativeAnchors::HasTopAnchor;
-    QTest::newRow("right") << "right" << QDeclarativeAnchorLine::Right << QDeclarativeAnchors::HasRightAnchor;
-    QTest::newRow("bottom") << "bottom" << QDeclarativeAnchorLine::Bottom << QDeclarativeAnchors::HasBottomAnchor;
+    QTest::newRow("left") << "left" << QDeclarativeAnchorLine::Left << QDeclarativeAnchors::LeftAnchor;
+    QTest::newRow("top") << "top" << QDeclarativeAnchorLine::Top << QDeclarativeAnchors::TopAnchor;
+    QTest::newRow("right") << "right" << QDeclarativeAnchorLine::Right << QDeclarativeAnchors::RightAnchor;
+    QTest::newRow("bottom") << "bottom" << QDeclarativeAnchorLine::Bottom << QDeclarativeAnchors::BottomAnchor;
 
-    QTest::newRow("hcenter") << "horizontalCenter" << QDeclarativeAnchorLine::HCenter << QDeclarativeAnchors::HasHCenterAnchor;
-    QTest::newRow("vcenter") << "verticalCenter" << QDeclarativeAnchorLine::VCenter << QDeclarativeAnchors::HasVCenterAnchor;
-    QTest::newRow("baseline") << "baseline" << QDeclarativeAnchorLine::Baseline << QDeclarativeAnchors::HasBaselineAnchor;
+    QTest::newRow("hcenter") << "horizontalCenter" << QDeclarativeAnchorLine::HCenter << QDeclarativeAnchors::HCenterAnchor;
+    QTest::newRow("vcenter") << "verticalCenter" << QDeclarativeAnchorLine::VCenter << QDeclarativeAnchors::VCenterAnchor;
+    QTest::newRow("baseline") << "baseline" << QDeclarativeAnchorLine::Baseline << QDeclarativeAnchors::BaselineAnchor;
 }
 
 void tst_qdeclarativeanchors::resetConvenience()
diff --git a/tests/auto/declarative/qdeclarativedebug/tst_qdeclarativedebug.cpp b/tests/auto/declarative/qdeclarativedebug/tst_qdeclarativedebug.cpp
index 49d430e..e2d3ee4 100644
--- a/tests/auto/declarative/qdeclarativedebug/tst_qdeclarativedebug.cpp
+++ b/tests/auto/declarative/qdeclarativedebug/tst_qdeclarativedebug.cpp
@@ -276,6 +276,7 @@ void tst_QDeclarativeDebug::initTestCase()
 {
     qRegisterMetaType<QDeclarativeDebugWatch::State>();
 
+    QTest::ignoreMessage(QtWarningMsg, "QDeclarativeDebugServer: Waiting for connection on port 3768...");
     qputenv("QML_DEBUG_SERVER_PORT", "3768");
     m_engine = new QDeclarativeEngine(this);
 
@@ -301,13 +302,14 @@ void tst_QDeclarativeDebug::initTestCase()
     }
     m_rootItem = qobject_cast<QDeclarativeItem*>(m_components.first());
 
-
     // add an extra context to test for multiple contexts
     QDeclarativeContext *context = new QDeclarativeContext(m_engine->rootContext(), this);
     context->setObjectName("tst_QDeclarativeDebug_childContext");
 
     m_conn = new QDeclarativeDebugConnection(this);
     m_conn->connectToHost("127.0.0.1", 3768);
+
+    QTest::ignoreMessage(QtWarningMsg, "QDeclarativeDebugServer: Connection established");
     bool ok = m_conn->waitForConnected();
     Q_ASSERT(ok);
     QTRY_VERIFY(QDeclarativeDebugService::hasDebuggingClient());
diff --git a/tests/auto/declarative/qdeclarativedebugclient/tst_qdeclarativedebugclient.cpp b/tests/auto/declarative/qdeclarativedebugclient/tst_qdeclarativedebugclient.cpp
index fb17f90..a19c2c2 100644
--- a/tests/auto/declarative/qdeclarativedebugclient/tst_qdeclarativedebugclient.cpp
+++ b/tests/auto/declarative/qdeclarativedebugclient/tst_qdeclarativedebugclient.cpp
@@ -74,11 +74,15 @@ private slots:
 
 void tst_QDeclarativeDebugClient::initTestCase()
 {
-    qputenv("QML_DEBUG_SERVER_PORT", "3768");
+    QTest::ignoreMessage(QtWarningMsg, "QDeclarativeDebugServer: Waiting for connection on port 3770...");
+
+    qputenv("QML_DEBUG_SERVER_PORT", "3770");
     new QDeclarativeEngine(this);
 
     m_conn = new QDeclarativeDebugConnection(this);
-    m_conn->connectToHost("127.0.0.1", 3768);
+    m_conn->connectToHost("127.0.0.1", 3770);
+
+    QTest::ignoreMessage(QtWarningMsg, "QDeclarativeDebugServer: Connection established");
     bool ok = m_conn->waitForConnected();
     Q_ASSERT(ok);
 
diff --git a/tests/auto/declarative/qdeclarativedebugservice/tst_qdeclarativedebugservice.cpp b/tests/auto/declarative/qdeclarativedebugservice/tst_qdeclarativedebugservice.cpp
index 80d7f76..9ebbbaf 100644
--- a/tests/auto/declarative/qdeclarativedebugservice/tst_qdeclarativedebugservice.cpp
+++ b/tests/auto/declarative/qdeclarativedebugservice/tst_qdeclarativedebugservice.cpp
@@ -76,11 +76,14 @@ private slots:
 
 void tst_QDeclarativeDebugService::initTestCase()
 {
-    qputenv("QML_DEBUG_SERVER_PORT", "3768");
+    QTest::ignoreMessage(QtWarningMsg, "QDeclarativeDebugServer: Waiting for connection on port 3769...");
+    qputenv("QML_DEBUG_SERVER_PORT", "3769");
     new QDeclarativeEngine(this);
 
     m_conn = new QDeclarativeDebugConnection(this);
-    m_conn->connectToHost("127.0.0.1", 3768);
+    m_conn->connectToHost("127.0.0.1", 3769);
+
+    QTest::ignoreMessage(QtWarningMsg, "QDeclarativeDebugServer: Connection established");
     bool ok = m_conn->waitForConnected();
     Q_ASSERT(ok);
 
@@ -151,7 +154,7 @@ void tst_QDeclarativeDebugService::idForObject()
     int idB = QDeclarativeDebugService::idForObject(objB);
     QVERIFY(idB != idA);
     QCOMPARE(QDeclarativeDebugService::objectForId(idB), objB);
- 
+
     delete objA;
     delete objB;
 }
diff --git a/tests/auto/declarative/qdeclarativedom/tst_qdeclarativedom.cpp b/tests/auto/declarative/qdeclarativedom/tst_qdeclarativedom.cpp
index 1f0c47c..a951827 100644
--- a/tests/auto/declarative/qdeclarativedom/tst_qdeclarativedom.cpp
+++ b/tests/auto/declarative/qdeclarativedom/tst_qdeclarativedom.cpp
@@ -1303,7 +1303,8 @@ void tst_qdeclarativedom::position()
     QCOMPARE(child2Value.length(), 6);
 
     // All QDeclarativeDomList
-    qWarning("QDeclarativeListValue position test required");
+    QCOMPARE(childrenList.position(), 189);
+    QCOMPARE(childrenList.length(), 18);
 }
 
 QTEST_MAIN(tst_qdeclarativedom)
diff --git a/tests/auto/declarative/qdeclarativeecmascript/data/canAssignNullToQObject.1.qml b/tests/auto/declarative/qdeclarativeecmascript/data/canAssignNullToQObject.1.qml
new file mode 100644
index 0000000..3fd9131
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativeecmascript/data/canAssignNullToQObject.1.qml
@@ -0,0 +1,9 @@
+import Qt.test 1.0
+
+MyQmlObject {
+    property bool runTest: false
+
+    property variant a: MyQmlObject {}
+
+    objectProperty: (runTest == false)?a:null
+}
diff --git a/tests/auto/declarative/qdeclarativeecmascript/data/canAssignNullToQObject.2.qml b/tests/auto/declarative/qdeclarativeecmascript/data/canAssignNullToQObject.2.qml
new file mode 100644
index 0000000..19b0c42
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativeecmascript/data/canAssignNullToQObject.2.qml
@@ -0,0 +1,11 @@
+import Qt.test 1.0
+import Qt 4.6
+
+MyQmlObject {
+    objectProperty: MyQmlObject {}
+
+    Component.onCompleted: {
+        objectProperty = null;
+    }
+}
+
diff --git a/tests/auto/declarative/qdeclarativeecmascript/data/extensionObjectsPropertyOverride.qml b/tests/auto/declarative/qdeclarativeecmascript/data/extensionObjectsPropertyOverride.qml
new file mode 100644
index 0000000..3c443cb
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativeecmascript/data/extensionObjectsPropertyOverride.qml
@@ -0,0 +1,7 @@
+import Qt.test 1.0
+
+OverrideDefaultPropertyObject
+{
+    MyBaseExtendedObject {
+    }
+}
diff --git a/tests/auto/declarative/qdeclarativeecmascript/testtypes.cpp b/tests/auto/declarative/qdeclarativeecmascript/testtypes.cpp
index 0d07055..154ff4d 100644
--- a/tests/auto/declarative/qdeclarativeecmascript/testtypes.cpp
+++ b/tests/auto/declarative/qdeclarativeecmascript/testtypes.cpp
@@ -72,6 +72,14 @@ private:
     int m_value;
 };
 
+class DefaultPropertyExtensionObject : public QObject
+{
+    Q_OBJECT
+    Q_CLASSINFO("DefaultProperty", "firstProperty")
+public:
+    DefaultPropertyExtensionObject(QObject *parent) : QObject(parent) {}
+};
+
 void registerTypes()
 {
     qmlRegisterType<MyQmlObject>("Qt.test", 1,0, "MyQmlObject");
@@ -81,6 +89,8 @@ void registerTypes()
     qmlRegisterExtendedType<MyExtendedObject, ExtensionObject>("Qt.test", 1,0, "MyExtendedObject");
     qmlRegisterType<MyTypeObject>("Qt.test", 1,0, "MyTypeObject");
     qmlRegisterType<NumberAssignment>("Qt.test", 1,0, "NumberAssignment");
+    qmlRegisterExtendedType<DefaultPropertyExtendedObject, DefaultPropertyExtensionObject>("Qt.test", 1,0, "DefaultPropertyExtendedObject");
+    qmlRegisterType<OverrideDefaultPropertyObject>("Qt.test", 1,0, "OverrideDefaultPropertyObject");
 }
 
 #include "testtypes.moc"
diff --git a/tests/auto/declarative/qdeclarativeecmascript/testtypes.h b/tests/auto/declarative/qdeclarativeecmascript/testtypes.h
index 79d3226..1381d57 100644
--- a/tests/auto/declarative/qdeclarativeecmascript/testtypes.h
+++ b/tests/auto/declarative/qdeclarativeecmascript/testtypes.h
@@ -659,6 +659,31 @@ public:
     void setTest12(unsigned int v) { _test12 = v; }
 };
 
+class DefaultPropertyExtendedObject : public QObject
+{
+    Q_OBJECT
+    Q_PROPERTY(QObject *firstProperty READ firstProperty WRITE setFirstProperty)
+    Q_PROPERTY(QObject *secondProperty READ secondProperty WRITE setSecondProperty)
+public:
+    DefaultPropertyExtendedObject(QObject *parent = 0) : QObject(parent), m_firstProperty(0), m_secondProperty(0) {}
+
+    QObject *firstProperty() const { return m_firstProperty; }
+    QObject *secondProperty() const { return m_secondProperty; }
+    void setFirstProperty(QObject *property) { m_firstProperty = property; }
+    void setSecondProperty(QObject *property) { m_secondProperty = property; }
+private:
+    QObject* m_firstProperty;
+    QObject* m_secondProperty;
+};
+
+class OverrideDefaultPropertyObject : public DefaultPropertyExtendedObject
+{
+    Q_OBJECT
+    Q_CLASSINFO("DefaultProperty", "secondProperty")
+public:
+    OverrideDefaultPropertyObject() {}
+};
+
 void registerTypes();
 
 #endif // TESTTYPES_H
diff --git a/tests/auto/declarative/qdeclarativeecmascript/tst_qdeclarativeecmascript.cpp b/tests/auto/declarative/qdeclarativeecmascript/tst_qdeclarativeecmascript.cpp
index 33629b8..6939290 100644
--- a/tests/auto/declarative/qdeclarativeecmascript/tst_qdeclarativeecmascript.cpp
+++ b/tests/auto/declarative/qdeclarativeecmascript/tst_qdeclarativeecmascript.cpp
@@ -90,6 +90,7 @@ private slots:
     void objectPropertiesTriggerReeval();
     void deferredProperties();
     void extensionObjects();
+    void overrideExtensionProperties();
     void attachedProperties();
     void enums();
     void valueTypeFunctions();
@@ -140,6 +141,7 @@ private slots:
     void variantsAssignedUndefined();
     void qtbug_9792();
     void noSpuriousWarningsAtShutdown();
+    void canAssignNullToQObject();
 
     void callQtInvokables();
 private:
@@ -565,6 +567,16 @@ void tst_qdeclarativeecmascript::extensionObjects()
 
 }
 
+void tst_qdeclarativeecmascript::overrideExtensionProperties()
+{
+    QDeclarativeComponent component(&engine, TEST_FILE("extensionObjectsPropertyOverride.qml"));
+    OverrideDefaultPropertyObject *object =
+        qobject_cast<OverrideDefaultPropertyObject *>(component.create());
+    QVERIFY(object != 0);
+    QVERIFY(object->secondProperty() != 0);
+    QVERIFY(object->firstProperty() == 0);
+}
+
 void tst_qdeclarativeecmascript::attachedProperties()
 {
     QDeclarativeComponent component(&engine, TEST_FILE("attachedProperty.qml"));
@@ -2179,6 +2191,35 @@ void tst_qdeclarativeecmascript::noSpuriousWarningsAtShutdown()
     }
 }
 
+void tst_qdeclarativeecmascript::canAssignNullToQObject()
+{
+    {
+    QDeclarativeComponent component(&engine, TEST_FILE("canAssignNullToQObject.1.qml"));
+
+    MyQmlObject *o = qobject_cast<MyQmlObject *>(component.create());
+    QVERIFY(o != 0);
+
+    QVERIFY(o->objectProperty() != 0);
+
+    o->setProperty("runTest", true);
+
+    QVERIFY(o->objectProperty() == 0);
+
+    delete o;
+    }
+
+    {
+    QDeclarativeComponent component(&engine, TEST_FILE("canAssignNullToQObject.2.qml"));
+
+    MyQmlObject *o = qobject_cast<MyQmlObject *>(component.create());
+    QVERIFY(o != 0);
+
+    QVERIFY(o->objectProperty() == 0);
+
+    delete o;
+    }
+}
+
 QTEST_MAIN(tst_qdeclarativeecmascript)
 
 #include "tst_qdeclarativeecmascript.moc"
diff --git a/tests/auto/declarative/qdeclarativefocusscope/data/forcefocus.qml b/tests/auto/declarative/qdeclarativefocusscope/data/forcefocus.qml
new file mode 100644
index 0000000..adde522
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativefocusscope/data/forcefocus.qml
@@ -0,0 +1,81 @@
+import Qt 4.6
+
+Rectangle {
+    width: 800; height: 600
+
+    FocusScope {
+        focus: true
+
+        FocusScope {
+            id: firstScope
+            focus: true
+
+            Rectangle {
+                objectName: "item0"
+                height: 120; width: 420
+
+                color: "transparent"
+                border.width: 5; border.color: firstScope.wantsFocus?"blue":"black"
+
+                Rectangle {
+                    id: item1; objectName: "item1"
+                    x: 10; y: 10; width: 100; height: 100; color: "green"
+                    border.width: 5; border.color: wantsFocus?"blue":"black"
+                    focus: true
+
+                    Rectangle {
+                        width: 50; height: 50; anchors.centerIn: parent
+                        color: parent.focus?"red":"transparent"
+                    }
+                }
+
+                Rectangle {
+                    id: item2; objectName: "item2"
+                    x: 310; y: 10; width: 100; height: 100; color: "green"
+                    border.width: 5; border.color: wantsFocus?"blue":"black"
+
+                    Rectangle {
+                        width: 50; height: 50; anchors.centerIn: parent
+                        color: parent.focus?"red":"transparent"
+                    }
+                }
+            }
+        }
+
+        FocusScope {
+            id: secondScope
+
+            Rectangle {
+                objectName: "item3"
+                y: 160; height: 120; width: 420
+
+                color: "transparent"
+                border.width: 5; border.color: secondScope.wantsFocus?"blue":"black"
+
+                Rectangle {
+                    id: item4; objectName: "item4"
+                    x: 10; y: 10; width: 100; height: 100; color: "green"
+                    border.width: 5; border.color: wantsFocus?"blue":"black"
+
+                    Rectangle {
+                        width: 50; height: 50; anchors.centerIn: parent
+                        color: parent.focus?"red":"transparent"
+                    }
+                }
+
+                Rectangle {
+                    id: item5; objectName: "item5"
+                    x: 310; y: 10; width: 100; height: 100; color: "green"
+                    border.width: 5; border.color: wantsFocus?"blue":"black"
+
+                    Rectangle {
+                        width: 50; height: 50; anchors.centerIn: parent
+                        color: parent.focus?"red":"transparent"
+                    }
+                }
+            }
+        }
+    }
+    Keys.onDigit4Pressed: item4.focus = true
+    Keys.onDigit5Pressed: item5.forceFocus()
+}
diff --git a/tests/auto/declarative/qdeclarativefocusscope/data/test.qml b/tests/auto/declarative/qdeclarativefocusscope/data/test.qml
index 647e5bf..f060bdc 100644
--- a/tests/auto/declarative/qdeclarativefocusscope/data/test.qml
+++ b/tests/auto/declarative/qdeclarativefocusscope/data/test.qml
@@ -20,7 +20,7 @@ Rectangle {
 
             color: "transparent"
             border.width: 5
-            //border.color: myScope.wantsFocus?"blue":"black"
+            border.color: myScope.wantsFocus?"blue":"black"
 
             Rectangle {
                 id: item1; objectName: "item1"
diff --git a/tests/auto/declarative/qdeclarativefocusscope/data/test4.qml b/tests/auto/declarative/qdeclarativefocusscope/data/test4.qml
index d8bd390..e41c6b8 100644
--- a/tests/auto/declarative/qdeclarativefocusscope/data/test4.qml
+++ b/tests/auto/declarative/qdeclarativefocusscope/data/test4.qml
@@ -19,7 +19,7 @@ Rectangle {
 
             color: "transparent"
             border.width: 5
-            //border.color: myScope.wantsFocus?"blue":"black"
+            border.color: myScope.wantsFocus?"blue":"black"
 
             Rectangle {
                 id: item1; objectName: "item1"
diff --git a/tests/auto/declarative/qdeclarativefocusscope/data/test5.qml b/tests/auto/declarative/qdeclarativefocusscope/data/test5.qml
index da452cf..838e557 100644
--- a/tests/auto/declarative/qdeclarativefocusscope/data/test5.qml
+++ b/tests/auto/declarative/qdeclarativefocusscope/data/test5.qml
@@ -20,7 +20,7 @@ Rectangle {
 
             color: "transparent"
             border.width: 5
-            //border.color: myScope.wantsFocus?"blue":"black"
+            border.color: myScope.wantsFocus?"blue":"black"
 
             Rectangle {
                 x: 10; y: 10
diff --git a/tests/auto/declarative/qdeclarativefocusscope/tst_qdeclarativefocusscope.cpp b/tests/auto/declarative/qdeclarativefocusscope/tst_qdeclarativefocusscope.cpp
index 1bd8331..04bb1c5 100644
--- a/tests/auto/declarative/qdeclarativefocusscope/tst_qdeclarativefocusscope.cpp
+++ b/tests/auto/declarative/qdeclarativefocusscope/tst_qdeclarativefocusscope.cpp
@@ -63,6 +63,7 @@ private slots:
     void nested();
     void noFocus();
     void textEdit();
+    void forceFocus();
 };
 
 /*
@@ -273,6 +274,62 @@ void tst_qdeclarativefocusscope::textEdit()
     delete view;
 }
 
+void tst_qdeclarativefocusscope::forceFocus()
+{
+    QDeclarativeView *view = new QDeclarativeView;
+    view->setSource(QUrl::fromLocalFile(SRCDIR "/data/forcefocus.qml"));
+
+    QDeclarativeRectangle *item0 = findItem<QDeclarativeRectangle>(view->rootObject(), QLatin1String("item0"));
+    QDeclarativeRectangle *item1 = findItem<QDeclarativeRectangle>(view->rootObject(), QLatin1String("item1"));
+    QDeclarativeRectangle *item2 = findItem<QDeclarativeRectangle>(view->rootObject(), QLatin1String("item2"));
+    QDeclarativeRectangle *item3 = findItem<QDeclarativeRectangle>(view->rootObject(), QLatin1String("item3"));
+    QDeclarativeRectangle *item4 = findItem<QDeclarativeRectangle>(view->rootObject(), QLatin1String("item4"));
+    QDeclarativeRectangle *item5 = findItem<QDeclarativeRectangle>(view->rootObject(), QLatin1String("item5"));
+    QVERIFY(item0 != 0);
+    QVERIFY(item1 != 0);
+    QVERIFY(item2 != 0);
+    QVERIFY(item3 != 0);
+    QVERIFY(item4 != 0);
+    QVERIFY(item5 != 0);
+
+    view->show();
+    qApp->setActiveWindow(view);
+    qApp->processEvents();
+
+#ifdef Q_WS_X11
+    // to be safe and avoid failing setFocus with window managers
+    qt_x11_wait_for_window_manager(view);
+#endif
+
+    QVERIFY(view->hasFocus());
+    QVERIFY(view->scene()->hasFocus());
+    QVERIFY(item0->wantsFocus() == true);
+    QVERIFY(item1->hasFocus() == true);
+    QVERIFY(item2->hasFocus() == false);
+    QVERIFY(item3->wantsFocus() == false);
+    QVERIFY(item4->hasFocus() == false);
+    QVERIFY(item5->hasFocus() == false);
+
+    QTest::keyClick(view, Qt::Key_4);
+    QVERIFY(item0->wantsFocus() == true);
+    QVERIFY(item1->hasFocus() == true);
+    QVERIFY(item2->hasFocus() == false);
+    QVERIFY(item3->wantsFocus() == false);
+    QVERIFY(item4->hasFocus() == false);
+    QVERIFY(item5->hasFocus() == false);
+
+    QTest::keyClick(view, Qt::Key_5);
+    QVERIFY(item0->wantsFocus() == false);
+    QVERIFY(item1->hasFocus() == false);
+    QVERIFY(item2->hasFocus() == false);
+    QVERIFY(item3->wantsFocus() == true);
+    QVERIFY(item4->hasFocus() == false);
+    QVERIFY(item5->hasFocus() == true);
+
+    delete view;
+}
+
+
 QTEST_MAIN(tst_qdeclarativefocusscope)
 
 #include "tst_qdeclarativefocusscope.moc"
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/assignToNamespace.errors.txt b/tests/auto/declarative/qdeclarativelanguage/data/assignToNamespace.errors.txt
new file mode 100644
index 0000000..78aa471
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/assignToNamespace.errors.txt
@@ -0,0 +1 @@
+4:5:Invalid use of namespace
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/assignToNamespace.qml b/tests/auto/declarative/qdeclarativelanguage/data/assignToNamespace.qml
new file mode 100644
index 0000000..4681879
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/assignToNamespace.qml
@@ -0,0 +1,5 @@
+import Qt 4.6 as Qt
+
+Qt.QtObject {
+    Qt: 10
+}
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/component.7.errors.txt b/tests/auto/declarative/qdeclarativelanguage/data/component.7.errors.txt
new file mode 100644
index 0000000..b144814
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/component.7.errors.txt
@@ -0,0 +1 @@
+3:1:Component objects cannot declare new properties.
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/component.7.qml b/tests/auto/declarative/qdeclarativelanguage/data/component.7.qml
new file mode 100644
index 0000000..ad708fe
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/component.7.qml
@@ -0,0 +1,7 @@
+import Qt 4.6
+
+Component {
+    property int a
+    QtObject {}
+}
+
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/component.8.errors.txt b/tests/auto/declarative/qdeclarativelanguage/data/component.8.errors.txt
new file mode 100644
index 0000000..6f2d0d2
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/component.8.errors.txt
@@ -0,0 +1 @@
+3:1:Component objects cannot declare new signals.
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/component.8.qml b/tests/auto/declarative/qdeclarativelanguage/data/component.8.qml
new file mode 100644
index 0000000..67b1b89
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/component.8.qml
@@ -0,0 +1,7 @@
+import Qt 4.6
+
+Component {
+    signal a
+    QtObject {}
+}
+
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/component.9.errors.txt b/tests/auto/declarative/qdeclarativelanguage/data/component.9.errors.txt
new file mode 100644
index 0000000..92f1456
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/component.9.errors.txt
@@ -0,0 +1 @@
+3:1:Component objects cannot declare new functions.
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/component.9.qml b/tests/auto/declarative/qdeclarativelanguage/data/component.9.qml
new file mode 100644
index 0000000..a4dbae0
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/component.9.qml
@@ -0,0 +1,7 @@
+import Qt 4.6
+
+Component {
+    function a() {}
+    QtObject {}
+}
+
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/dynamicMeta.1.errors.txt b/tests/auto/declarative/qdeclarativelanguage/data/dynamicMeta.1.errors.txt
new file mode 100644
index 0000000..1f9f916
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/dynamicMeta.1.errors.txt
@@ -0,0 +1 @@
+5:5:Duplicate default property
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/dynamicMeta.1.qml b/tests/auto/declarative/qdeclarativelanguage/data/dynamicMeta.1.qml
new file mode 100644
index 0000000..1efe791
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/dynamicMeta.1.qml
@@ -0,0 +1,6 @@
+import Qt 4.6
+
+QtObject {
+    default property QtObject a
+    default property QtObject b
+}
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/dynamicMeta.2.errors.txt b/tests/auto/declarative/qdeclarativelanguage/data/dynamicMeta.2.errors.txt
new file mode 100644
index 0000000..7a4f63b
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/dynamicMeta.2.errors.txt
@@ -0,0 +1 @@
+5:5:Duplicate property name
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/dynamicMeta.2.qml b/tests/auto/declarative/qdeclarativelanguage/data/dynamicMeta.2.qml
new file mode 100644
index 0000000..4e7b5ae
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/dynamicMeta.2.qml
@@ -0,0 +1,6 @@
+import Qt 4.6
+
+QtObject {
+    property int a
+    property bool a
+}
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/dynamicMeta.3.errors.txt b/tests/auto/declarative/qdeclarativelanguage/data/dynamicMeta.3.errors.txt
new file mode 100644
index 0000000..c5860a2
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/dynamicMeta.3.errors.txt
@@ -0,0 +1 @@
+3:1:Duplicate signal name
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/dynamicMeta.3.qml b/tests/auto/declarative/qdeclarativelanguage/data/dynamicMeta.3.qml
new file mode 100644
index 0000000..573c1ba
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/dynamicMeta.3.qml
@@ -0,0 +1,6 @@
+import Qt 4.6
+
+QtObject {
+    signal a
+    signal a
+}
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/dynamicMeta.4.errors.txt b/tests/auto/declarative/qdeclarativelanguage/data/dynamicMeta.4.errors.txt
new file mode 100644
index 0000000..b293c86
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/dynamicMeta.4.errors.txt
@@ -0,0 +1 @@
+3:1:Duplicate method name
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/dynamicMeta.4.qml b/tests/auto/declarative/qdeclarativelanguage/data/dynamicMeta.4.qml
new file mode 100644
index 0000000..51dd834
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/dynamicMeta.4.qml
@@ -0,0 +1,6 @@
+import Qt 4.6
+
+QtObject {
+    function a() {}
+    function a() {}
+}
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/dynamicMeta.5.errors.txt b/tests/auto/declarative/qdeclarativelanguage/data/dynamicMeta.5.errors.txt
new file mode 100644
index 0000000..015d55b
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/dynamicMeta.5.errors.txt
@@ -0,0 +1 @@
+3:1:UnknownType is not a type
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/dynamicMeta.5.qml b/tests/auto/declarative/qdeclarativelanguage/data/dynamicMeta.5.qml
new file mode 100644
index 0000000..6b93e00
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/dynamicMeta.5.qml
@@ -0,0 +1,5 @@
+import Qt 4.6
+
+QtObject {
+    property UnknownType a
+}
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.1.errors.txt b/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.1.errors.txt
new file mode 100644
index 0000000..9848e48
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.1.errors.txt
@@ -0,0 +1 @@
+3:1:No property alias location
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.1.qml b/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.1.qml
new file mode 100644
index 0000000..985fb94
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.1.qml
@@ -0,0 +1,5 @@
+import Qt 4.7
+
+QtObject {
+    property alias a
+}
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.2.errors.txt b/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.2.errors.txt
new file mode 100644
index 0000000..3e15628
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.2.errors.txt
@@ -0,0 +1 @@
+4:23:Invalid alias location
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.2.qml b/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.2.qml
new file mode 100644
index 0000000..a2ac91c
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.2.qml
@@ -0,0 +1,6 @@
+import Qt 4.7
+
+QtObject {
+    property alias a: 10
+}
+
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.3.errors.txt b/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.3.errors.txt
new file mode 100644
index 0000000..7260be4
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.3.errors.txt
@@ -0,0 +1 @@
+5:23:Invalid alias reference. An alias reference must be specified as <id> or <id>.<property>
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.3.qml b/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.3.qml
new file mode 100644
index 0000000..cc71753
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.3.qml
@@ -0,0 +1,6 @@
+import Test 1.0
+
+MyTypeObject {
+    id: root
+    property alias a: root.rectProperty.x
+}
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.4.errors.txt b/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.4.errors.txt
new file mode 100644
index 0000000..7260be4
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.4.errors.txt
@@ -0,0 +1 @@
+5:23:Invalid alias reference. An alias reference must be specified as <id> or <id>.<property>
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.4.qml b/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.4.qml
new file mode 100644
index 0000000..cfdfca0
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.4.qml
@@ -0,0 +1,7 @@
+import Test 1.0
+
+MyTypeObject {
+    id: root
+    property alias a: print("Hello!")
+}
+
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.5.errors.txt b/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.5.errors.txt
new file mode 100644
index 0000000..6f78e59
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.5.errors.txt
@@ -0,0 +1 @@
+5:23:Invalid alias reference. Unable to find id "otherroot"
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.5.qml b/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.5.qml
new file mode 100644
index 0000000..0c1d5d7
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.5.qml
@@ -0,0 +1,7 @@
+import Test 1.0
+
+MyTypeObject {
+    id: root
+    property alias a: otherroot
+}
+
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.6.errors.txt b/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.6.errors.txt
new file mode 100644
index 0000000..93652a7
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.6.errors.txt
@@ -0,0 +1 @@
+5:23:Invalid alias location
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.6.qml b/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.6.qml
new file mode 100644
index 0000000..edfdb24
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/invalidAlias.6.qml
@@ -0,0 +1,7 @@
+import Test 1.0
+
+MyTypeObject {
+    id: root
+    property alias a: root.foobar
+}
+
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/invalidAttachedProperty.12.errors.txt b/tests/auto/declarative/qdeclarativelanguage/data/invalidAttachedProperty.12.errors.txt
new file mode 100644
index 0000000..189a795
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/invalidAttachedProperty.12.errors.txt
@@ -0,0 +1 @@
+4:13:Attached properties cannot be used here
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/invalidAttachedProperty.12.qml b/tests/auto/declarative/qdeclarativelanguage/data/invalidAttachedProperty.12.qml
new file mode 100644
index 0000000..7de503e
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/invalidAttachedProperty.12.qml
@@ -0,0 +1,6 @@
+import Test 1.0
+
+MyTypeObject {
+    grouped.MyQmlObject.value: 10
+}
+
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/invalidAttachedProperty.13.errors.txt b/tests/auto/declarative/qdeclarativelanguage/data/invalidAttachedProperty.13.errors.txt
new file mode 100644
index 0000000..46d7be2
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/invalidAttachedProperty.13.errors.txt
@@ -0,0 +1 @@
+5:9:Attached properties cannot be used here
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/invalidAttachedProperty.13.qml b/tests/auto/declarative/qdeclarativelanguage/data/invalidAttachedProperty.13.qml
new file mode 100644
index 0000000..986ab85
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/invalidAttachedProperty.13.qml
@@ -0,0 +1,8 @@
+import Test 1.0
+
+MyTypeObject {
+    grouped {
+        MyQmlObject.value: 10
+    }
+}
+
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/invalidOn.errors.txt b/tests/auto/declarative/qdeclarativelanguage/data/invalidOn.errors.txt
new file mode 100644
index 0000000..b4210a1
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/invalidOn.errors.txt
@@ -0,0 +1 @@
+3:5:"MyQmlObject" cannot operate on "value"
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/invalidOn.qml b/tests/auto/declarative/qdeclarativelanguage/data/invalidOn.qml
new file mode 100644
index 0000000..d748bf4
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/invalidOn.qml
@@ -0,0 +1,4 @@
+import Test 1.0
+MyQmlObject {
+    MyQmlObject on value {}
+}
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/listAssignment.1.errors.txt b/tests/auto/declarative/qdeclarativelanguage/data/listAssignment.1.errors.txt
new file mode 100644
index 0000000..35d2d35
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/listAssignment.1.errors.txt
@@ -0,0 +1 @@
+4:24:Cannot assign object to list
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/listAssignment.1.qml b/tests/auto/declarative/qdeclarativelanguage/data/listAssignment.1.qml
new file mode 100644
index 0000000..6c628e4
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/listAssignment.1.qml
@@ -0,0 +1,6 @@
+import Test 1.0
+import Qt 4.7
+MyContainer {
+    containerChildren: QtObject {}
+}
+
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/multiSet.11.errors.txt b/tests/auto/declarative/qdeclarativelanguage/data/multiSet.11.errors.txt
new file mode 100644
index 0000000..e1f7ec5
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/multiSet.11.errors.txt
@@ -0,0 +1 @@
+5:5:Property value set multiple times
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/multiSet.11.qml b/tests/auto/declarative/qdeclarativelanguage/data/multiSet.11.qml
new file mode 100644
index 0000000..7d03139
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/multiSet.11.qml
@@ -0,0 +1,6 @@
+import Test 1.0
+
+MyTypeObject {
+    rectProperty.x: 10
+    rectProperty.x: 11
+}
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/noCreation.errors.txt b/tests/auto/declarative/qdeclarativelanguage/data/noCreation.errors.txt
new file mode 100644
index 0000000..23cd3f3
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/noCreation.errors.txt
@@ -0,0 +1 @@
+3:1:Keys is only available via attached properties
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/noCreation.qml b/tests/auto/declarative/qdeclarativelanguage/data/noCreation.qml
new file mode 100644
index 0000000..0612fa2
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/noCreation.qml
@@ -0,0 +1,4 @@
+import Qt 4.6
+
+Keys {
+}
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/readOnly.4.errors.txt b/tests/auto/declarative/qdeclarativelanguage/data/readOnly.4.errors.txt
new file mode 100644
index 0000000..d857a04
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/readOnly.4.errors.txt
@@ -0,0 +1 @@
+3:5:Invalid property assignment: "readOnlyString" is a read-only property
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/readOnly.4.qml b/tests/auto/declarative/qdeclarativelanguage/data/readOnly.4.qml
new file mode 100644
index 0000000..5338ac7
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/readOnly.4.qml
@@ -0,0 +1,4 @@
+import Test 1.0
+MyQmlObject {
+    MyPropertyValueSource on readOnlyString {}
+}
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/readOnly.5.errors.txt b/tests/auto/declarative/qdeclarativelanguage/data/readOnly.5.errors.txt
new file mode 100644
index 0000000..baf4766
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/readOnly.5.errors.txt
@@ -0,0 +1 @@
+3:27:Invalid property assignment: "readOnlyEnumProperty" is a read-only property
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/readOnly.5.qml b/tests/auto/declarative/qdeclarativelanguage/data/readOnly.5.qml
new file mode 100644
index 0000000..422d13d
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/readOnly.5.qml
@@ -0,0 +1,4 @@
+import Test 1.0
+MyTypeObject {
+    readOnlyEnumProperty: MyTypeObject.EnumValue1
+}
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/scriptString.1.errors.txt b/tests/auto/declarative/qdeclarativelanguage/data/scriptString.1.errors.txt
new file mode 100644
index 0000000..14463e0
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/scriptString.1.errors.txt
@@ -0,0 +1 @@
+4:21:Invalid property assignment: script expected
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/scriptString.1.qml b/tests/auto/declarative/qdeclarativelanguage/data/scriptString.1.qml
new file mode 100644
index 0000000..f07d223
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/scriptString.1.qml
@@ -0,0 +1,5 @@
+import Test 1.0
+
+MyTypeObject {
+    scriptProperty: MyTypeObject {}
+}
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/scriptString.2.errors.txt b/tests/auto/declarative/qdeclarativelanguage/data/scriptString.2.errors.txt
new file mode 100644
index 0000000..f8a776f
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/scriptString.2.errors.txt
@@ -0,0 +1 @@
+4:40:Cannot assign multiple values to a script property
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/scriptString.2.qml b/tests/auto/declarative/qdeclarativelanguage/data/scriptString.2.qml
new file mode 100644
index 0000000..dc825c7
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/scriptString.2.qml
@@ -0,0 +1,6 @@
+import Test 1.0
+
+MyTypeObject {
+    scriptProperty: [ MyTypeObject {}, MyTypeObject {} ]
+}
+
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/wrongType.16.errors.txt b/tests/auto/declarative/qdeclarativelanguage/data/wrongType.16.errors.txt
new file mode 100644
index 0000000..77cf210
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/wrongType.16.errors.txt
@@ -0,0 +1 @@
+4:24:Cannot assign object to property
diff --git a/tests/auto/declarative/qdeclarativelanguage/data/wrongType.16.qml b/tests/auto/declarative/qdeclarativelanguage/data/wrongType.16.qml
new file mode 100644
index 0000000..1ddccc0
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativelanguage/data/wrongType.16.qml
@@ -0,0 +1,5 @@
+import Test 1.0
+import Qt 4.7
+MyQmlObject {
+    qmlobjectProperty: QtObject {}
+}
diff --git a/tests/auto/declarative/qdeclarativelanguage/testtypes.cpp b/tests/auto/declarative/qdeclarativelanguage/testtypes.cpp
index 623775a..5d87404 100644
--- a/tests/auto/declarative/qdeclarativelanguage/testtypes.cpp
+++ b/tests/auto/declarative/qdeclarativelanguage/testtypes.cpp
@@ -52,8 +52,7 @@ void registerTypes()
     qmlRegisterType<MyNamespace::MySecondNamespacedType>("Test",1,0,"MySecondNamespacedType");
     qmlRegisterType<MyGroupedObject>();
 
-    qmlRegisterCustomType<MyCustomParserType>("Test", 1, 0, "MyCustomParserType", "MyCustomParserType",
-                                                       new MyCustomParserTypeParser);
+    qmlRegisterCustomType<MyCustomParserType>("Test", 1, 0, "MyCustomParserType", new MyCustomParserTypeParser);
 }
 
 QVariant myCustomVariantTypeConverter(const QString &data)
diff --git a/tests/auto/declarative/qdeclarativelanguage/testtypes.h b/tests/auto/declarative/qdeclarativelanguage/testtypes.h
index 951cea0..89f99c8 100644
--- a/tests/auto/declarative/qdeclarativelanguage/testtypes.h
+++ b/tests/auto/declarative/qdeclarativelanguage/testtypes.h
@@ -200,6 +200,7 @@ class MyTypeObject : public QObject
     Q_PROPERTY(QDeclarativeComponent *componentProperty READ componentProperty WRITE setComponentProperty)
     Q_PROPERTY(MyFlags flagProperty READ flagProperty WRITE setFlagProperty)
     Q_PROPERTY(MyEnum enumProperty READ enumProperty WRITE setEnumProperty)
+    Q_PROPERTY(MyEnum readOnlyEnumProperty READ readOnlyEnumProperty)
     Q_PROPERTY(QString stringProperty READ stringProperty WRITE setStringProperty)
     Q_PROPERTY(uint uintProperty READ uintProperty WRITE setUintProperty)
     Q_PROPERTY(int intProperty READ intProperty WRITE setIntProperty)
@@ -273,6 +274,10 @@ public:
         enumPropertyValue = v;
     }
 
+    MyEnum readOnlyEnumProperty() const {
+        return EnumVal1;
+    }
+
     QString stringPropertyValue;
     QString stringProperty() const {
        return stringPropertyValue;
@@ -467,16 +472,19 @@ class MyContainer : public QObject
 {
     Q_OBJECT
     Q_PROPERTY(QDeclarativeListProperty<QObject> children READ children)
+    Q_PROPERTY(QDeclarativeListProperty<MyContainer> containerChildren READ containerChildren)
     Q_PROPERTY(QDeclarativeListProperty<MyInterface> qlistInterfaces READ qlistInterfaces)
     Q_CLASSINFO("DefaultProperty", "children")
 public:
     MyContainer() {}
 
     QDeclarativeListProperty<QObject> children() { return QDeclarativeListProperty<QObject>(this, m_children); }
+    QDeclarativeListProperty<MyContainer> containerChildren() { return QDeclarativeListProperty<MyContainer>(this, m_containerChildren); }
     QList<QObject *> *getChildren() { return &m_children; }
     QDeclarativeListProperty<MyInterface> qlistInterfaces() { return QDeclarativeListProperty<MyInterface>(this, m_interfaces); }
     QList<MyInterface *> *getQListInterfaces() { return &m_interfaces; }
 
+    QList<MyContainer*> m_containerChildren;
     QList<QObject*> m_children;
     QList<MyInterface *> m_interfaces;
 };
diff --git a/tests/auto/declarative/qdeclarativelanguage/tst_qdeclarativelanguage.cpp b/tests/auto/declarative/qdeclarativelanguage/tst_qdeclarativelanguage.cpp
index 07fbf83..c1397de 100644
--- a/tests/auto/declarative/qdeclarativelanguage/tst_qdeclarativelanguage.cpp
+++ b/tests/auto/declarative/qdeclarativelanguage/tst_qdeclarativelanguage.cpp
@@ -225,11 +225,15 @@ void tst_qdeclarativelanguage::errors_data()
     QTest::newRow("wrongType (number string for int)") << "wrongType.13.qml" << "wrongType.13.errors.txt" << false;
     QTest::newRow("wrongType (int for string)") << "wrongType.14.qml" << "wrongType.14.errors.txt" << false;
     QTest::newRow("wrongType (int for url)") << "wrongType.15.qml" << "wrongType.15.errors.txt" << false;
+    QTest::newRow("wrongType (invalid object)") << "wrongType.16.qml" << "wrongType.16.errors.txt" << false;
 
     QTest::newRow("readOnly.1") << "readOnly.1.qml" << "readOnly.1.errors.txt" << false;
     QTest::newRow("readOnly.2") << "readOnly.2.qml" << "readOnly.2.errors.txt" << false;
     QTest::newRow("readOnly.3") << "readOnly.3.qml" << "readOnly.3.errors.txt" << false;
+    QTest::newRow("readOnly.4") << "readOnly.4.qml" << "readOnly.4.errors.txt" << false;
+    QTest::newRow("readOnly.5") << "readOnly.5.qml" << "readOnly.5.errors.txt" << false;
 
+    QTest::newRow("listAssignment.1") << "listAssignment.1.qml" << "listAssignment.1.errors.txt" << false;
     QTest::newRow("listAssignment.2") << "listAssignment.2.qml" << "listAssignment.2.errors.txt" << false;
     QTest::newRow("listAssignment.3") << "listAssignment.3.qml" << "listAssignment.3.errors.txt" << false;
 
@@ -243,6 +247,9 @@ void tst_qdeclarativelanguage::errors_data()
     QTest::newRow("invalidID.8") << "invalidID.8.qml" << "invalidID.8.errors.txt" << false;
     QTest::newRow("invalidID.9") << "invalidID.9.qml" << "invalidID.9.errors.txt" << false;
 
+    QTest::newRow("scriptString.1") << "scriptString.1.qml" << "scriptString.1.errors.txt" << false;
+    QTest::newRow("scriptString.2") << "scriptString.2.qml" << "scriptString.2.errors.txt" << false;
+
     QTest::newRow("unsupportedProperty") << "unsupportedProperty.qml" << "unsupportedProperty.errors.txt" << false;
     QTest::newRow("nullDotProperty") << "nullDotProperty.qml" << "nullDotProperty.errors.txt" << true;
     QTest::newRow("fakeDotProperty") << "fakeDotProperty.qml" << "fakeDotProperty.errors.txt" << false;
@@ -296,6 +303,9 @@ void tst_qdeclarativelanguage::errors_data()
     QTest::newRow("Component.4") << "component.4.qml" << "component.4.errors.txt" << false;
     QTest::newRow("Component.5") << "component.5.qml" << "component.5.errors.txt" << false;
     QTest::newRow("Component.6") << "component.6.qml" << "component.6.errors.txt" << false;
+    QTest::newRow("Component.7") << "component.7.qml" << "component.7.errors.txt" << false;
+    QTest::newRow("Component.8") << "component.8.qml" << "component.8.errors.txt" << false;
+    QTest::newRow("Component.9") << "component.9.qml" << "component.9.errors.txt" << false;
 
     QTest::newRow("MultiSet.1") << "multiSet.1.qml" << "multiSet.1.errors.txt" << false;
     QTest::newRow("MultiSet.2") << "multiSet.2.qml" << "multiSet.2.errors.txt" << false;
@@ -307,6 +317,20 @@ void tst_qdeclarativelanguage::errors_data()
     QTest::newRow("MultiSet.8") << "multiSet.8.qml" << "multiSet.8.errors.txt" << false;
     QTest::newRow("MultiSet.9") << "multiSet.9.qml" << "multiSet.9.errors.txt" << false;
     QTest::newRow("MultiSet.10") << "multiSet.10.qml" << "multiSet.10.errors.txt" << false;
+    QTest::newRow("MultiSet.11") << "multiSet.11.qml" << "multiSet.11.errors.txt" << false;
+
+    QTest::newRow("dynamicMeta.1") << "dynamicMeta.1.qml" << "dynamicMeta.1.errors.txt" << false;
+    QTest::newRow("dynamicMeta.2") << "dynamicMeta.2.qml" << "dynamicMeta.2.errors.txt" << false;
+    QTest::newRow("dynamicMeta.3") << "dynamicMeta.3.qml" << "dynamicMeta.3.errors.txt" << false;
+    QTest::newRow("dynamicMeta.4") << "dynamicMeta.4.qml" << "dynamicMeta.4.errors.txt" << false;
+    QTest::newRow("dynamicMeta.5") << "dynamicMeta.5.qml" << "dynamicMeta.5.errors.txt" << false;
+
+    QTest::newRow("invalidAlias.1") << "invalidAlias.1.qml" << "invalidAlias.1.errors.txt" << false;
+    QTest::newRow("invalidAlias.2") << "invalidAlias.2.qml" << "invalidAlias.2.errors.txt" << false;
+    QTest::newRow("invalidAlias.3") << "invalidAlias.3.qml" << "invalidAlias.3.errors.txt" << false;
+    QTest::newRow("invalidAlias.4") << "invalidAlias.4.qml" << "invalidAlias.4.errors.txt" << false;
+    QTest::newRow("invalidAlias.5") << "invalidAlias.5.qml" << "invalidAlias.5.errors.txt" << false;
+    QTest::newRow("invalidAlias.6") << "invalidAlias.6.qml" << "invalidAlias.6.errors.txt" << false;
 
     QTest::newRow("invalidAttachedProperty.1") << "invalidAttachedProperty.1.qml" << "invalidAttachedProperty.1.errors.txt" << false;
     QTest::newRow("invalidAttachedProperty.2") << "invalidAttachedProperty.2.qml" << "invalidAttachedProperty.2.errors.txt" << false;
@@ -319,6 +343,8 @@ void tst_qdeclarativelanguage::errors_data()
     QTest::newRow("invalidAttachedProperty.9") << "invalidAttachedProperty.9.qml" << "invalidAttachedProperty.9.errors.txt" << false;
     QTest::newRow("invalidAttachedProperty.10") << "invalidAttachedProperty.10.qml" << "invalidAttachedProperty.10.errors.txt" << false;
     QTest::newRow("invalidAttachedProperty.11") << "invalidAttachedProperty.11.qml" << "invalidAttachedProperty.11.errors.txt" << false;
+    QTest::newRow("invalidAttachedProperty.12") << "invalidAttachedProperty.12.qml" << "invalidAttachedProperty.12.errors.txt" << false;
+    QTest::newRow("invalidAttachedProperty.13") << "invalidAttachedProperty.13.qml" << "invalidAttachedProperty.13.errors.txt" << false;
 
     QTest::newRow("emptySignal") << "emptySignal.qml" << "emptySignal.errors.txt" << false;
     QTest::newRow("emptySignal.2") << "emptySignal.2.qml" << "emptySignal.2.errors.txt" << false;
@@ -330,7 +356,10 @@ void tst_qdeclarativelanguage::errors_data()
     QTest::newRow("missingValueTypeProperty") << "missingValueTypeProperty.qml" << "missingValueTypeProperty.errors.txt" << false;
     QTest::newRow("objectValueTypeProperty") << "objectValueTypeProperty.qml" << "objectValueTypeProperty.errors.txt" << false;
     QTest::newRow("enumTypes") << "enumTypes.qml" << "enumTypes.errors.txt" << false;
+    QTest::newRow("noCreation") << "noCreation.qml" << "noCreation.errors.txt" << false;
     QTest::newRow("destroyedSignal") << "destroyedSignal.qml" << "destroyedSignal.errors.txt" << false;
+    QTest::newRow("assignToNamespace") << "assignToNamespace.qml" << "assignToNamespace.errors.txt" << false;
+    QTest::newRow("invalidOn") << "invalidOn.qml" << "invalidOn.errors.txt" << false;
 }
 
 
diff --git a/tests/auto/declarative/qdeclarativelistmodel/tst_qdeclarativelistmodel.cpp b/tests/auto/declarative/qdeclarativelistmodel/tst_qdeclarativelistmodel.cpp
index bbea98a..e4c296f 100644
--- a/tests/auto/declarative/qdeclarativelistmodel/tst_qdeclarativelistmodel.cpp
+++ b/tests/auto/declarative/qdeclarativelistmodel/tst_qdeclarativelistmodel.cpp
@@ -326,6 +326,12 @@ void tst_qdeclarativelistmodel::dynamic_worker()
         if (QByteArray(QTest::currentDataTag()).startsWith("nested"))
             QTest::ignoreMessage(QtWarningMsg, "<Unknown File>: QML ListModel: Cannot add nested list values when modifying or after modification from a worker script");
 
+        if (QByteArray(QTest::currentDataTag()).startsWith("nested-append")) {
+            int callsToGet = script.count(QLatin1String(";get("));
+            for (int i=0; i<callsToGet; i++)
+                QTest::ignoreMessage(QtWarningMsg, "<Unknown File>: QML ListModel: get: index 0 out of range");
+        }
+
         QVERIFY(QMetaObject::invokeMethod(item, "evalExpressionViaWorker", 
                 Q_ARG(QVariant, operations.mid(0, operations.length()-1))));
         waitForWorker(item);
diff --git a/tests/auto/declarative/qdeclarativeloader/data/SetSourceComponent.qml b/tests/auto/declarative/qdeclarativeloader/data/SetSourceComponent.qml
index 1db56c4..f600e85 100644
--- a/tests/auto/declarative/qdeclarativeloader/data/SetSourceComponent.qml
+++ b/tests/auto/declarative/qdeclarativeloader/data/SetSourceComponent.qml
@@ -1,6 +1,9 @@
 import Qt 4.6
 
 Item {
+    function clear() {
+        loader.sourceComponent = undefined
+    }
     Component { id: comp; Rectangle { width: 100; height: 50 } }
-    Loader { sourceComponent: comp }
+    Loader { id: loader; sourceComponent: comp }
 }
diff --git a/tests/auto/declarative/qdeclarativeloader/tst_qdeclarativeloader.cpp b/tests/auto/declarative/qdeclarativeloader/tst_qdeclarativeloader.cpp
index 1b17a56..7cdadb4 100644
--- a/tests/auto/declarative/qdeclarativeloader/tst_qdeclarativeloader.cpp
+++ b/tests/auto/declarative/qdeclarativeloader/tst_qdeclarativeloader.cpp
@@ -198,6 +198,26 @@ void tst_QDeclarativeLoader::clear()
 
         delete item;
     }
+    {
+        QDeclarativeComponent component(&engine, TEST_FILE("/SetSourceComponent.qml"));
+        QDeclarativeItem *item = qobject_cast<QDeclarativeItem*>(component.create());
+        QVERIFY(item);
+
+        QDeclarativeLoader *loader = qobject_cast<QDeclarativeLoader*>(item->QGraphicsObject::children().at(1)); 
+        QVERIFY(loader);
+        QVERIFY(loader->item());
+        QCOMPARE(loader->progress(), 1.0);
+        QCOMPARE(static_cast<QGraphicsItem*>(loader)->children().count(), 1);
+
+        QMetaObject::invokeMethod(item, "clear");
+
+        QVERIFY(loader->item() == 0);
+        QCOMPARE(loader->progress(), 0.0);
+        QCOMPARE(loader->status(), QDeclarativeLoader::Null);
+        QCOMPARE(static_cast<QGraphicsItem*>(loader)->children().count(), 0);
+
+        delete item;
+    }
 }
 
 void tst_QDeclarativeLoader::urlToComponent()
@@ -518,9 +538,8 @@ void tst_QDeclarativeLoader::nonItem()
 void tst_QDeclarativeLoader::vmeErrors()
 {
     QDeclarativeComponent component(&engine, TEST_FILE("vmeErrors.qml"));
-    //ignore message for now
-    //QString err = QUrl::fromLocalFile(SRCDIR "/data/VmeError.qml:6: Cannot assign object type QObject with no default method\n        onSomethingHappened: QtObject {}) ");
-    //QTest::ignoreMessage(QtWarningMsg, err.toLatin1().constData());
+    QString err = QUrl::fromLocalFile(SRCDIR).toString() + "/data/VmeError.qml:6: Cannot assign object type QObject with no default method";
+    QTest::ignoreMessage(QtWarningMsg, err.toLatin1().constData());
     QDeclarativeLoader *loader = qobject_cast<QDeclarativeLoader*>(component.create());
     QVERIFY(loader);
     QVERIFY(loader->item() == 0);
diff --git a/tests/auto/declarative/qdeclarativemousearea/data/dragging.qml b/tests/auto/declarative/qdeclarativemousearea/data/dragging.qml
new file mode 100644
index 0000000..a28f049
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativemousearea/data/dragging.qml
@@ -0,0 +1,28 @@
+import Qt 4.7
+Rectangle {
+    id: whiteRect
+    width: 200
+    height: 200
+    color: "white"
+    Rectangle {
+        id: blackRect
+        objectName: "blackrect"
+        color: "black"
+        y: 50
+        x: 50
+        width: 100
+        height: 100
+        opacity: (whiteRect.width-blackRect.x+whiteRect.height-blackRect.y-199)/200
+        Text { text: blackRect.opacity}
+        MouseArea {
+            objectName: "mouseregion"
+            anchors.fill: parent
+            drag.target: blackRect
+            drag.axis: Drag.XandYAxis
+            drag.minimumX: 0
+            drag.maximumX: whiteRect.width-blackRect.width
+            drag.minimumY: 0
+            drag.maximumY: whiteRect.height-blackRect.height
+         }
+     }
+ }
diff --git a/tests/auto/declarative/qdeclarativemousearea/tst_qdeclarativemousearea.cpp b/tests/auto/declarative/qdeclarativemousearea/tst_qdeclarativemousearea.cpp
index 4a58049..eb4aa12 100644
--- a/tests/auto/declarative/qdeclarativemousearea/tst_qdeclarativemousearea.cpp
+++ b/tests/auto/declarative/qdeclarativemousearea/tst_qdeclarativemousearea.cpp
@@ -52,6 +52,7 @@ class tst_QDeclarativeMouseArea: public QObject
 private slots:
     void dragProperties();
     void resetDrag();
+    void dragging();
     void updateMouseAreaPosOnClick();
     void updateMouseAreaPosOnResize();
     void noOnClickedWithPressAndHold();
@@ -163,6 +164,61 @@ void tst_QDeclarativeMouseArea::resetDrag()
 }
 
 
+void tst_QDeclarativeMouseArea::dragging()
+{
+    QDeclarativeView *canvas = createView();
+
+    canvas->setSource(QUrl::fromLocalFile(SRCDIR "/data/dragging.qml"));
+    canvas->show();
+    canvas->setFocus();
+    QVERIFY(canvas->rootObject() != 0);
+
+    QDeclarativeMouseArea *mouseRegion = canvas->rootObject()->findChild<QDeclarativeMouseArea*>("mouseregion");
+    QDeclarativeDrag *drag = mouseRegion->drag();
+    QVERIFY(mouseRegion != 0);
+    QVERIFY(drag != 0);
+
+    // target
+    QDeclarativeItem *blackRect = canvas->rootObject()->findChild<QDeclarativeItem*>("blackrect");
+    QVERIFY(blackRect != 0);
+    QVERIFY(blackRect == drag->target());
+
+    QVERIFY(!drag->active());
+
+    QGraphicsScene *scene = canvas->scene();
+    QGraphicsSceneMouseEvent pressEvent(QEvent::GraphicsSceneMousePress);
+    pressEvent.setScenePos(QPointF(100, 100));
+    pressEvent.setButton(Qt::LeftButton);
+    pressEvent.setButtons(Qt::LeftButton);
+    QApplication::sendEvent(scene, &pressEvent);
+
+    QVERIFY(!drag->active());
+    QCOMPARE(blackRect->x(), 50.0);
+    QCOMPARE(blackRect->y(), 50.0);
+
+    QGraphicsSceneMouseEvent moveEvent(QEvent::GraphicsSceneMouseMove);
+    moveEvent.setScenePos(QPointF(110, 110));
+    moveEvent.setButton(Qt::LeftButton);
+    moveEvent.setButtons(Qt::LeftButton);
+    QApplication::sendEvent(scene, &moveEvent);
+
+    QVERIFY(drag->active());
+    QCOMPARE(blackRect->x(), 60.0);
+    QCOMPARE(blackRect->y(), 60.0);
+
+    QGraphicsSceneMouseEvent releaseEvent(QEvent::GraphicsSceneMouseRelease);
+    releaseEvent.setScenePos(QPointF(110, 110));
+    releaseEvent.setButton(Qt::LeftButton);
+    releaseEvent.setButtons(Qt::LeftButton);
+    QApplication::sendEvent(scene, &releaseEvent);
+
+    QVERIFY(!drag->active());
+    QCOMPARE(blackRect->x(), 60.0);
+    QCOMPARE(blackRect->y(), 60.0);
+
+    delete canvas;
+}
+
 QDeclarativeView *tst_QDeclarativeMouseArea::createView()
 {
     QDeclarativeView *canvas = new QDeclarativeView(0);
diff --git a/tests/auto/declarative/qdeclarativestates/tst_qdeclarativestates.cpp b/tests/auto/declarative/qdeclarativestates/tst_qdeclarativestates.cpp
index bd3186a..a016fa7 100644
--- a/tests/auto/declarative/qdeclarativestates/tst_qdeclarativestates.cpp
+++ b/tests/auto/declarative/qdeclarativestates/tst_qdeclarativestates.cpp
@@ -566,10 +566,10 @@ void tst_qdeclarativestates::anchorChanges()
 
     rect->setState("right");
     QCOMPARE(innerRect->x(), qreal(150));
-    QCOMPARE(aChanges->anchors()->left().anchorLine, QDeclarativeAnchorLine::Invalid);  //### was reset (how do we distinguish from not set at all)
     QCOMPARE(aChanges->object(), qobject_cast<QDeclarativeItem*>(innerRect));
-    QCOMPARE(aChanges->anchors()->right().item, rect->right().item);
-    QCOMPARE(aChanges->anchors()->right().anchorLine, rect->right().anchorLine);
+    QCOMPARE(aChanges->object()->anchors()->left().anchorLine, QDeclarativeAnchorLine::Invalid);  //### was reset (how do we distinguish from not set at all)
+    QCOMPARE(aChanges->object()->anchors()->right().item, rect->right().item);
+    QCOMPARE(aChanges->object()->anchors()->right().anchorLine, rect->right().anchorLine);
 
     rect->setState("");
     QCOMPARE(innerRect->x(), qreal(5));
@@ -589,7 +589,6 @@ void tst_qdeclarativestates::anchorChanges2()
     QVERIFY(innerRect != 0);
 
     rect->setState("right");
-    QEXPECT_FAIL("", "QTBUG-5338", Continue);
     QCOMPARE(innerRect->x(), qreal(150));
 
     rect->setState("");
@@ -625,14 +624,14 @@ void tst_qdeclarativestates::anchorChanges3()
 
     rect->setState("reanchored");
     QCOMPARE(aChanges->object(), qobject_cast<QDeclarativeItem*>(innerRect));
-    QCOMPARE(aChanges->anchors()->left().item, leftGuideline->left().item);
-    QCOMPARE(aChanges->anchors()->left().anchorLine, leftGuideline->left().anchorLine);
-    QCOMPARE(aChanges->anchors()->right().item, rect->right().item);
-    QCOMPARE(aChanges->anchors()->right().anchorLine, rect->right().anchorLine);
-    QCOMPARE(aChanges->anchors()->top().item, rect->top().item);
-    QCOMPARE(aChanges->anchors()->top().anchorLine, rect->top().anchorLine);
-    QCOMPARE(aChanges->anchors()->bottom().item, bottomGuideline->bottom().item);
-    QCOMPARE(aChanges->anchors()->bottom().anchorLine, bottomGuideline->bottom().anchorLine);
+    QCOMPARE(aChanges->object()->anchors()->left().item, leftGuideline->left().item);
+    QCOMPARE(aChanges->object()->anchors()->left().anchorLine, leftGuideline->left().anchorLine);
+    QCOMPARE(aChanges->object()->anchors()->right().item, rect->right().item);
+    QCOMPARE(aChanges->object()->anchors()->right().anchorLine, rect->right().anchorLine);
+    QCOMPARE(aChanges->object()->anchors()->top().item, rect->top().item);
+    QCOMPARE(aChanges->object()->anchors()->top().anchorLine, rect->top().anchorLine);
+    QCOMPARE(aChanges->object()->anchors()->bottom().item, bottomGuideline->bottom().item);
+    QCOMPARE(aChanges->object()->anchors()->bottom().anchorLine, bottomGuideline->bottom().anchorLine);
 
     QCOMPARE(innerRect->x(), qreal(10));
     QCOMPARE(innerRect->y(), qreal(0));
@@ -675,10 +674,10 @@ void tst_qdeclarativestates::anchorChanges4()
 
     rect->setState("reanchored");
     QCOMPARE(aChanges->object(), qobject_cast<QDeclarativeItem*>(innerRect));
-    QCOMPARE(aChanges->anchors()->horizontalCenter().item, bottomGuideline->horizontalCenter().item);
-    QCOMPARE(aChanges->anchors()->horizontalCenter().anchorLine, bottomGuideline->horizontalCenter().anchorLine);
-    QCOMPARE(aChanges->anchors()->verticalCenter().item, leftGuideline->verticalCenter().item);
-    QCOMPARE(aChanges->anchors()->verticalCenter().anchorLine, leftGuideline->verticalCenter().anchorLine);
+    QCOMPARE(aChanges->object()->anchors()->horizontalCenter().item, bottomGuideline->horizontalCenter().item);
+    QCOMPARE(aChanges->object()->anchors()->horizontalCenter().anchorLine, bottomGuideline->horizontalCenter().anchorLine);
+    QCOMPARE(aChanges->object()->anchors()->verticalCenter().item, leftGuideline->verticalCenter().item);
+    QCOMPARE(aChanges->object()->anchors()->verticalCenter().anchorLine, leftGuideline->verticalCenter().anchorLine);
 
     delete rect;
 }
@@ -710,10 +709,10 @@ void tst_qdeclarativestates::anchorChanges5()
 
     rect->setState("reanchored");
     QCOMPARE(aChanges->object(), qobject_cast<QDeclarativeItem*>(innerRect));
-    QCOMPARE(aChanges->anchors()->horizontalCenter().item, bottomGuideline->horizontalCenter().item);
-    QCOMPARE(aChanges->anchors()->horizontalCenter().anchorLine, bottomGuideline->horizontalCenter().anchorLine);
-    QCOMPARE(aChanges->anchors()->baseline().item, leftGuideline->baseline().item);
-    QCOMPARE(aChanges->anchors()->baseline().anchorLine, leftGuideline->baseline().anchorLine);
+    //QCOMPARE(aChanges->anchors()->horizontalCenter().item, bottomGuideline->horizontalCenter().item);
+    //QCOMPARE(aChanges->anchors()->horizontalCenter().anchorLine, bottomGuideline->horizontalCenter().anchorLine);
+    //QCOMPARE(aChanges->anchors()->baseline().item, leftGuideline->baseline().item);
+    //QCOMPARE(aChanges->anchors()->baseline().anchorLine, leftGuideline->baseline().anchorLine);
 
     delete rect;
 }
diff --git a/tests/auto/declarative/qdeclarativevisualdatamodel/data/visualdatamodel.qml b/tests/auto/declarative/qdeclarativevisualdatamodel/data/visualdatamodel.qml
new file mode 100644
index 0000000..d70f82b
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativevisualdatamodel/data/visualdatamodel.qml
@@ -0,0 +1,11 @@
+import Qt 4.7
+
+VisualDataModel {
+    function setRoot() {
+        rootIndex = modelIndex(0);
+    }
+    function setRootToParent() {
+        rootIndex = parentModelIndex();
+    }
+    model: myModel
+}
diff --git a/tests/auto/declarative/qdeclarativevisualdatamodel/qdeclarativevisualdatamodel.pro b/tests/auto/declarative/qdeclarativevisualdatamodel/qdeclarativevisualdatamodel.pro
new file mode 100644
index 0000000..d76b582
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativevisualdatamodel/qdeclarativevisualdatamodel.pro
@@ -0,0 +1,11 @@
+load(qttest_p4)
+contains(QT_CONFIG,declarative): QT += declarative gui
+macx:CONFIG -= app_bundle
+
+SOURCES += tst_qdeclarativevisualdatamodel.cpp
+
+# Define SRCDIR equal to test's source directory
+DEFINES += SRCDIR=\\\"$$PWD\\\"
+
+CONFIG += parallel_test
+
diff --git a/tests/auto/declarative/qdeclarativevisualdatamodel/tst_qdeclarativevisualdatamodel.cpp b/tests/auto/declarative/qdeclarativevisualdatamodel/tst_qdeclarativevisualdatamodel.cpp
new file mode 100644
index 0000000..7de15a3
--- /dev/null
+++ b/tests/auto/declarative/qdeclarativevisualdatamodel/tst_qdeclarativevisualdatamodel.cpp
@@ -0,0 +1,111 @@
+/****************************************************************************
+**
+** 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 <qtest.h>
+#include <QtTest/QSignalSpy>
+#include <QStandardItemModel>
+#include <QtDeclarative/qdeclarativeengine.h>
+#include <QtDeclarative/qdeclarativecomponent.h>
+#include <QtDeclarative/qdeclarativecontext.h>
+#include <private/qdeclarativevisualitemmodel_p.h>
+#include <private/qdeclarativevaluetype_p.h>
+#include <math.h>
+
+static void initStandardTreeModel(QStandardItemModel *model)
+{
+    QStandardItem *item;
+    item = new QStandardItem(QLatin1String("Row 1 Item"));
+    model->insertRow(0, item);
+
+    item = new QStandardItem(QLatin1String("Row 2 Item"));
+    item->setCheckable(true);
+    model->insertRow(1, item);
+
+    QStandardItem *childItem = new QStandardItem(QLatin1String("Row 2 Child Item"));
+    item->setChild(0, childItem);
+
+    item = new QStandardItem(QLatin1String("Row 3 Item"));
+    item->setIcon(QIcon());
+    model->insertRow(2, item);
+}
+
+class tst_qdeclarativevisualdatamodel : public QObject
+{
+    Q_OBJECT
+public:
+    tst_qdeclarativevisualdatamodel();
+
+private slots:
+    void rootIndex();
+
+private:
+    QDeclarativeEngine engine;
+};
+
+tst_qdeclarativevisualdatamodel::tst_qdeclarativevisualdatamodel()
+{
+}
+
+void tst_qdeclarativevisualdatamodel::rootIndex()
+{
+    QDeclarativeEngine engine;
+    QDeclarativeComponent c(&engine, QUrl::fromLocalFile(SRCDIR "/data/visualdatamodel.qml"));
+
+    QStandardItemModel model;
+    initStandardTreeModel(&model);
+
+    engine.rootContext()->setContextProperty("myModel", &model);
+
+    QDeclarativeVisualDataModel *obj = qobject_cast<QDeclarativeVisualDataModel*>(c.create());
+    QVERIFY(obj != 0);
+
+    QMetaObject::invokeMethod(obj, "setRoot");
+    QVERIFY(qvariant_cast<QModelIndex>(obj->rootIndex()) == model.index(0,0));
+
+    QMetaObject::invokeMethod(obj, "setRootToParent");
+    QVERIFY(qvariant_cast<QModelIndex>(obj->rootIndex()) == QModelIndex());
+
+    delete obj;
+}
+
+
+QTEST_MAIN(tst_qdeclarativevisualdatamodel)
+
+#include "tst_qdeclarativevisualdatamodel.moc"
diff --git a/tests/auto/declarative/qdeclarativexmllistmodel/tst_qdeclarativexmllistmodel.cpp b/tests/auto/declarative/qdeclarativexmllistmodel/tst_qdeclarativexmllistmodel.cpp
index cf7e357..831e318 100644
--- a/tests/auto/declarative/qdeclarativexmllistmodel/tst_qdeclarativexmllistmodel.cpp
+++ b/tests/auto/declarative/qdeclarativexmllistmodel/tst_qdeclarativexmllistmodel.cpp
@@ -222,7 +222,7 @@ void tst_qdeclarativexmllistmodel::roles()
 void tst_qdeclarativexmllistmodel::roleErrors()
 {
     QDeclarativeComponent component(&engine, QUrl::fromLocalFile(SRCDIR "/data/roleErrors.qml"));
-    QTest::ignoreMessage(QtWarningMsg, QString("QML XmlRole (" + QUrl::fromLocalFile(SRCDIR "/data/roleErrors.qml").toString() + ":6:5) An XmlRole query must not start with '/'").toUtf8().constData());
+    QTest::ignoreMessage(QtWarningMsg, (QUrl::fromLocalFile(SRCDIR "/data/roleErrors.qml").toString() + ":6:5: QML XmlRole: An XmlRole query must not start with '/'").toUtf8().constData());
     //### make sure we receive all expected warning messages.
     QDeclarativeXmlListModel *model = qobject_cast<QDeclarativeXmlListModel*>(component.create());
     QVERIFY(model != 0);
@@ -247,7 +247,7 @@ void tst_qdeclarativexmllistmodel::roleErrors()
 void tst_qdeclarativexmllistmodel::uniqueRoleNames()
 {
     QDeclarativeComponent component(&engine, QUrl::fromLocalFile(SRCDIR "/data/unique.qml"));
-    QTest::ignoreMessage(QtWarningMsg, QString("QML XmlRole (" + QUrl::fromLocalFile(SRCDIR "/data/unique.qml").toString() + ":7:5) \"name\" duplicates a previous role name and will be disabled.").toUtf8().constData());
+    QTest::ignoreMessage(QtWarningMsg, (QUrl::fromLocalFile(SRCDIR "/data/unique.qml").toString() + ":7:5: QML XmlRole: \"name\" duplicates a previous role name and will be disabled.").toUtf8().constData());
     QDeclarativeXmlListModel *model = qobject_cast<QDeclarativeXmlListModel*>(component.create());
     QVERIFY(model != 0);
     QTRY_COMPARE(model->count(), 9);
diff --git a/tests/auto/declarative/qmlvisual/fillmode/data/fillmode.0.png b/tests/auto/declarative/qmlvisual/fillmode/data/fillmode.0.png
index 9c9ceae..02fa5c9 100644
--- a/tests/auto/declarative/qmlvisual/fillmode/data/fillmode.0.png
+++ b/tests/auto/declarative/qmlvisual/fillmode/data/fillmode.0.png
diff --git a/tests/auto/declarative/qmlvisual/fillmode/data/fillmode.qml b/tests/auto/declarative/qmlvisual/fillmode/data/fillmode.qml
index 08ed609..1dc2d29 100644
--- a/tests/auto/declarative/qmlvisual/fillmode/data/fillmode.qml
+++ b/tests/auto/declarative/qmlvisual/fillmode/data/fillmode.qml
@@ -7,5 +7,5 @@ VisualTest {
     Frame {
         msec: 16
         image: "fillmode.0.png"
-    }    
+    }
 }
diff --git a/tests/auto/declarative/qmlvisual/qdeclarativeborderimage/data/borders.qml b/tests/auto/declarative/qmlvisual/qdeclarativeborderimage/data/borders.qml
index 1403d35..dd38ea5 100644
--- a/tests/auto/declarative/qmlvisual/qdeclarativeborderimage/data/borders.qml
+++ b/tests/auto/declarative/qmlvisual/qdeclarativeborderimage/data/borders.qml
@@ -6,6 +6,6 @@ VisualTest {
     }
     Frame {
         msec: 16
-        hash: "258a7e75b491e4f51a91739c776803b3"
+        image: "borders.0.png"
     }
 }
diff --git a/tests/auto/declarative/qmlvisual/qdeclarativeflipable/data/test_flipable_resize.qml b/tests/auto/declarative/qmlvisual/qdeclarativeflipable/data/test_flipable_resize.qml
new file mode 100644
index 0000000..6e5f7a0
--- /dev/null
+++ b/tests/auto/declarative/qmlvisual/qdeclarativeflipable/data/test_flipable_resize.qml
@@ -0,0 +1,207 @@
+import Qt.VisualTest 4.6
+
+VisualTest {
+    Frame {
+        msec: 0
+    }
+    Frame {
+        msec: 16
+        hash: "04382a80a203e1fe3d0d4944c9195e0b"
+    }
+    Frame {
+        msec: 32
+        hash: "8d8c6a3c37ba3cb77afcc7ed4234d40f"
+    }
+    Frame {
+        msec: 48
+        hash: "93ab01494e2229c0921c25d3acbcffe6"
+    }
+    Frame {
+        msec: 64
+        hash: "5036bf3c842e5ad09b7bac5512e433ad"
+    }
+    Frame {
+        msec: 80
+        hash: "ef02ef4598fbe6390391b7f2c17ec99d"
+    }
+    Frame {
+        msec: 96
+        hash: "7fa83afca86cfec48a4986ba3df08e3b"
+    }
+    Frame {
+        msec: 112
+        hash: "d9388827bd7755bb9bc1ef78507cc0ac"
+    }
+    Frame {
+        msec: 128
+        hash: "d18778f4f748f7ee54404db334831ff7"
+    }
+    Frame {
+        msec: 144
+        hash: "fee69ae3b4d79b795d4443b055a8a91a"
+    }
+    Frame {
+        msec: 160
+        hash: "f80fa0131c859286e900071b51e74784"
+    }
+    Frame {
+        msec: 176
+        hash: "b654e51ea71ec118e6b985743281b6a1"
+    }
+    Frame {
+        msec: 192
+        hash: "91c771226e9c97e0f00c6f7c6fc6c95c"
+    }
+    Frame {
+        msec: 208
+        hash: "0f612f81541b093442e68d99e00c288c"
+    }
+    Frame {
+        msec: 224
+        hash: "246b619598606fef9f0442439cee4ec6"
+    }
+    Frame {
+        msec: 240
+        hash: "1d2f34459b2128877218cef340f46f06"
+    }
+    Frame {
+        msec: 256
+        hash: "af3c2eef734da05d45484bbb19646425"
+    }
+    Frame {
+        msec: 272
+        hash: "85dfe5680e47919500728de6e93c8290"
+    }
+    Frame {
+        msec: 288
+        hash: "8fd7d439bafa07461a65a3c97cf8602a"
+    }
+    Frame {
+        msec: 304
+        hash: "1ebf543a84aae4abfd480f24ad362cb0"
+    }
+    Frame {
+        msec: 320
+        hash: "60a9c9300981282986659e7c73d381b0"
+    }
+    Frame {
+        msec: 336
+        hash: "686f3ff048f2b214033988d989ed087a"
+    }
+    Frame {
+        msec: 352
+        hash: "24694e17476b0ffe9848159aa282e931"
+    }
+    Frame {
+        msec: 368
+        hash: "c05e1bdf62e3e58972f868b930823a58"
+    }
+    Frame {
+        msec: 384
+        hash: "cbc1a3c78b8f79047d1221d5ae06f0f8"
+    }
+    Frame {
+        msec: 400
+        hash: "05ad366e74bf30b1619cf2ef1f530d82"
+    }
+    Frame {
+        msec: 416
+        hash: "4c5c536f2c03ecfb7d3d8f56638001ec"
+    }
+    Frame {
+        msec: 432
+        hash: "9754048ffcb7863a8a676e5bee4a7991"
+    }
+    Frame {
+        msec: 448
+        hash: "047aa8203ad18023f5af340a41f1084e"
+    }
+    Frame {
+        msec: 464
+        hash: "1351b7c92cd873db387e93dc74cca848"
+    }
+    Frame {
+        msec: 480
+        hash: "4066f52fae753013396195dc98311058"
+    }
+    Frame {
+        msec: 496
+        hash: "21d969b92993e428e79babb574e9203d"
+    }
+    Frame {
+        msec: 512
+        hash: "62c00f52e8b0592fbb59f88deb3b022e"
+    }
+    Frame {
+        msec: 528
+        hash: "322719dee40d3495e9b4d2faac351e89"
+    }
+    Frame {
+        msec: 544
+        hash: "322719dee40d3495e9b4d2faac351e89"
+    }
+    Frame {
+        msec: 560
+        hash: "322719dee40d3495e9b4d2faac351e89"
+    }
+    Frame {
+        msec: 576
+        hash: "322719dee40d3495e9b4d2faac351e89"
+    }
+    Frame {
+        msec: 592
+        hash: "322719dee40d3495e9b4d2faac351e89"
+    }
+    Frame {
+        msec: 608
+        hash: "322719dee40d3495e9b4d2faac351e89"
+    }
+    Frame {
+        msec: 624
+        hash: "322719dee40d3495e9b4d2faac351e89"
+    }
+    Frame {
+        msec: 640
+        hash: "322719dee40d3495e9b4d2faac351e89"
+    }
+    Frame {
+        msec: 656
+        hash: "322719dee40d3495e9b4d2faac351e89"
+    }
+    Frame {
+        msec: 672
+        hash: "322719dee40d3495e9b4d2faac351e89"
+    }
+    Frame {
+        msec: 688
+        hash: "322719dee40d3495e9b4d2faac351e89"
+    }
+    Frame {
+        msec: 704
+        hash: "322719dee40d3495e9b4d2faac351e89"
+    }
+    Frame {
+        msec: 720
+        hash: "322719dee40d3495e9b4d2faac351e89"
+    }
+    Key {
+        type: 6
+        key: 16777249
+        modifiers: 67108864
+        text: ""
+        autorep: false
+        count: 1
+    }
+    Frame {
+        msec: 736
+        hash: "322719dee40d3495e9b4d2faac351e89"
+    }
+    Frame {
+        msec: 752
+        hash: "322719dee40d3495e9b4d2faac351e89"
+    }
+    Frame {
+        msec: 768
+        hash: "322719dee40d3495e9b4d2faac351e89"
+    }
+}
diff --git a/tests/auto/declarative/qmlvisual/qdeclarativeflipable/test_flipable_resize.qml b/tests/auto/declarative/qmlvisual/qdeclarativeflipable/test_flipable_resize.qml
new file mode 100644
index 0000000..5a73e67
--- /dev/null
+++ b/tests/auto/declarative/qmlvisual/qdeclarativeflipable/test_flipable_resize.qml
@@ -0,0 +1,62 @@
+import Qt 4.6
+Item { //realWindow
+    width: 370
+    height: 480
+    Item {
+        id: window
+        NumberAnimation on width{ from:320; to:370; duration: 500 }
+        NumberAnimation on height{ from:480; to:320; duration: 500 }
+        Flipable {
+            id: flipable
+            x: 0
+            y: window.height / 3.0 - 40
+            width: parent.width
+            height: parent.height
+            transform: Rotation {
+                id: transform
+                origin.x: window.width / 2.0
+                origin.y: 0
+                origin.z: 0
+                axis.x: 0
+                axis.y: 1
+                axis.z: 0
+                angle: 0;
+            }
+            front: Rectangle{
+                width: parent.width
+                height: 80
+                color: "blue"
+            }back: Rectangle{
+                width: parent.width
+                height: 80
+                color: "red"
+            }
+        }
+        Flipable {
+            id: flipableBack
+            x: 0
+            y: 2.0 * window.height / 3.0 - 40
+            width: parent.width
+            height: parent.height
+            transform: Rotation {
+                id: transformBack
+                origin.x: window.width / 2.0
+                origin.y: 0
+                origin.z: 0
+                axis.x: 0
+                axis.y: 1
+                axis.z: 0
+                angle: 180;
+            }
+            front: Rectangle{
+                width: parent.width
+                height: 80
+                color: "blue"
+            }back: Rectangle{
+                width: parent.width
+                height: 80
+                color: "red"
+            }
+        }
+    }
+}
diff --git a/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.0.png b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.0.png
new file mode 100644
index 0000000..993610f
--- /dev/null
+++ b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.0.png
diff --git a/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.1.png b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.1.png
new file mode 100644
index 0000000..993610f
--- /dev/null
+++ b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.1.png
diff --git a/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.10.png b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.10.png
new file mode 100644
index 0000000..12c6cf5
--- /dev/null
+++ b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.10.png
diff --git a/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.11.png b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.11.png
new file mode 100644
index 0000000..ccb9fdd
--- /dev/null
+++ b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.11.png
diff --git a/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.12.png b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.12.png
new file mode 100644
index 0000000..ace0752
--- /dev/null
+++ b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.12.png
diff --git a/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.13.png b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.13.png
new file mode 100644
index 0000000..993610f
--- /dev/null
+++ b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.13.png
diff --git a/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.2.png b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.2.png
new file mode 100644
index 0000000..e58c68b
--- /dev/null
+++ b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.2.png
diff --git a/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.3.png b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.3.png
new file mode 100644
index 0000000..e58c68b
--- /dev/null
+++ b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.3.png
diff --git a/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.4.png b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.4.png
new file mode 100644
index 0000000..cb6d2f8
--- /dev/null
+++ b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.4.png
diff --git a/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.5.png b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.5.png
new file mode 100644
index 0000000..db6bea2
--- /dev/null
+++ b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.5.png
diff --git a/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.6.png b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.6.png
new file mode 100644
index 0000000..c18bb34
--- /dev/null
+++ b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.6.png
diff --git a/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.7.png b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.7.png
new file mode 100644
index 0000000..c18bb34
--- /dev/null
+++ b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.7.png
diff --git a/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.8.png b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.8.png
new file mode 100644
index 0000000..3b56301
--- /dev/null
+++ b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.8.png
diff --git a/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.9.png b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.9.png
new file mode 100644
index 0000000..993610f
--- /dev/null
+++ b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.9.png
diff --git a/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.qml b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.qml
new file mode 100644
index 0000000..e6a09bf
--- /dev/null
+++ b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/data/mousearea-flickable.qml
@@ -0,0 +1,5127 @@
+import Qt.VisualTest 4.6
+
+VisualTest {
+    Frame {
+        msec: 0
+    }
+    Frame {
+        msec: 16
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 32
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 48
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 64
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 80
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 96
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 112
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 128
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 144
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 160
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 176
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 192
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 208
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 224
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 240
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 256
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 272
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 288
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 304
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 320
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 336
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 352
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 368
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 384
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 400
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 416
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 432
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 448
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 464
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 480
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 496
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 512
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 528
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 544
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 560
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 576
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 592
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 608
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 624
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 640
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 656
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 672
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 688
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 704
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 720
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 736
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 752
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 768
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 784
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 800
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 816
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 832
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 848
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 864
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 880
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 896
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 912
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 928
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 944
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 960
+        image: "mousearea-flickable.0.png"
+    }
+    Frame {
+        msec: 976
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 992
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1008
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1024
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1040
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1056
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1072
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1088
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1104
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1120
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1136
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1152
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1168
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1184
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1200
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1216
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1232
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1248
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1264
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1280
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1296
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1312
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1328
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1344
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1360
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1376
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1392
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1408
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1424
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1440
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1456
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1472
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1488
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1504
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1520
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1536
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1552
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1568
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1584
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1600
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1616
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1632
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1648
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1664
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1680
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1696
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1712
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1728
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1744
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1760
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1776
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1792
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1808
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1824
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1840
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1856
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1872
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1888
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1904
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1920
+        image: "mousearea-flickable.1.png"
+    }
+    Frame {
+        msec: 1936
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1952
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1968
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 1984
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2000
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2016
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2032
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2048
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2064
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2080
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2096
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2112
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2128
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2144
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2160
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2176
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2192
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2208
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2224
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2240
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2256
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2272
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2288
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2304
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2320
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2336
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2352
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2368
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2384
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2400
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2416
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2432
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2448
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2464
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2480
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2496
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2512
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2528
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2544
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2560
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2576
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2592
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 2608
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Mouse {
+        type: 2
+        button: 1
+        buttons: 1
+        x: 188; y: 41
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 2624
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 2640
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 2656
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 2672
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 2688
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 2704
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 2720
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 2736
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 2752
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 2768
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 2784
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 2800
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 2816
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 2832
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 2848
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 2864
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 2880
+        image: "mousearea-flickable.2.png"
+    }
+    Frame {
+        msec: 2896
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 2912
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 2928
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 2944
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 2960
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 2976
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 2992
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3008
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3024
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3040
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3056
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3072
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3088
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3104
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3120
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3136
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3152
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3168
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3184
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3200
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3216
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3232
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3248
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3264
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3280
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3296
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3312
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3328
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3344
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3360
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3376
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3392
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3408
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3424
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3440
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3456
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3472
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3488
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3504
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3520
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3536
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3552
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3568
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3584
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3600
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3616
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3632
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3648
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3664
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3680
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3696
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3712
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3728
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3744
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3760
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3776
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3792
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3808
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3824
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3840
+        image: "mousearea-flickable.3.png"
+    }
+    Frame {
+        msec: 3856
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3872
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3888
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3904
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3920
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3936
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3952
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3968
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 3984
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4000
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4016
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4032
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4048
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4064
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4080
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4096
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4112
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4128
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4144
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4160
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4176
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4192
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4208
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4224
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4240
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4256
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4272
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4288
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4304
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4320
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4336
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4352
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4368
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4384
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4400
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4416
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4432
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4448
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4464
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4480
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4496
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Frame {
+        msec: 4512
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 189; y: 42
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 4528
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 189; y: 44
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 4544
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 190; y: 45
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 190; y: 47
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 4560
+        hash: "4a60ab820ca66548384b2257b21de8ec"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 190; y: 48
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 190; y: 50
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 4576
+        hash: "86b32befe0dada5bdce82a7dd14777ce"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 191; y: 51
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 191; y: 53
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 4592
+        hash: "7a5f69a1eecb5de0fc2295cd287eb449"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 191; y: 54
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 192; y: 56
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 4608
+        hash: "144eeb7c2a32cedb6ebba063501c9176"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 192; y: 57
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 192; y: 59
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 4624
+        hash: "11120d6de575ffa639b6abb3af4afef7"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 193; y: 61
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 193; y: 62
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 4640
+        hash: "ab4c936a81299adf080f3b14f7e6be49"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 193; y: 64
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 194; y: 66
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 4656
+        hash: "6602009ffe3c0f3072640ebc8749b76f"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 194; y: 68
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 194; y: 70
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 4672
+        hash: "8517007d5102af238935e93a3b38087f"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 195; y: 72
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 195; y: 75
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 4688
+        hash: "4e129ebba85d1f3717d09f71eb5a1a7d"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 196; y: 77
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 196; y: 79
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 4704
+        hash: "82f54d7e254edcf499ea12a63118e8a7"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 196; y: 82
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 197; y: 84
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 4720
+        hash: "572cb62d69ccb973ea18d3b0eaff571b"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 197; y: 86
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 197; y: 88
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 4736
+        hash: "79650397b868019909b931a32a115823"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 198; y: 90
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 198; y: 92
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 4752
+        hash: "43e50f4d4d37373e26af0a5d3cb64c4c"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 198; y: 94
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 198; y: 97
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 4768
+        hash: "a0f8eb8a796f67c368b0a479e8d14681"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 199; y: 99
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 199; y: 101
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 4784
+        hash: "01bf03313a0229e810a24e2adbbe9775"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 199; y: 106
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 4800
+        image: "mousearea-flickable.4.png"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 200; y: 111
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 4816
+        hash: "aafb12a520eb443ee1348282f2c54e4a"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 200; y: 113
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 200; y: 116
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 4832
+        hash: "806d22bc3533c729cd10dc889c36902d"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 201; y: 121
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 4848
+        hash: "05b3013c9e42ed9ced7009d2e2999357"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 201; y: 124
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 203; y: 130
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 4864
+        hash: "cb49adcd2c8afe27fd5926bd622added"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 203; y: 133
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 203; y: 135
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 4880
+        hash: "d0b4215b43403c97d83250add6d2b6db"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 203; y: 138
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 205; y: 146
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 4896
+        hash: "ee0523fe6a33b59871ad3b311ca0cbeb"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 205; y: 149
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 205; y: 152
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 4912
+        hash: "29ca97cc573d3a1fde65320b61678c60"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 207; y: 161
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 4928
+        hash: "021bda841eaefa76ce5e1c97150af6f6"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 207; y: 164
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 208; y: 166
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 4944
+        hash: "80edf52cc9e64a29f677bc2203220ba9"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 208; y: 172
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 4960
+        hash: "c09f4002ed9d41f62bb1aaff95723cce"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 208; y: 175
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 209; y: 177
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 4976
+        hash: "7bb17b13db811b02c86a24a0051336d9"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 209; y: 180
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 209; y: 182
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 4992
+        hash: "da5c33ee9e9e1d9aaa7d5efa83b8bf69"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 209; y: 187
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 5008
+        hash: "3ca9742356b6ff833fd287a95520174a"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 209; y: 189
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 209; y: 192
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 5024
+        hash: "d1372239a681d1fccc25257b4a02fb39"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 210; y: 194
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 210; y: 196
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 5040
+        hash: "1f37473ab2fb0643e11e4a41a2ee4561"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 210; y: 198
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 210; y: 200
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 5056
+        hash: "1533c6ff17e79a47a5d3510aa85bcf8a"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 210; y: 202
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 211; y: 204
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 5072
+        hash: "4cad3c6caf8d3009f63923df897c4723"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 211; y: 205
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 211; y: 207
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 5088
+        hash: "b81183233961b34c2a3f21a249b0fbfb"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 211; y: 209
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 211; y: 210
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 5104
+        hash: "9f876eb93a16c24843dd6a5acd303ab3"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 211; y: 211
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 211; y: 213
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 5120
+        hash: "237dd62011f4253970b946b335e3fb71"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 211; y: 215
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 5136
+        hash: "6206ad3e633b6b1b068304caa4efe48a"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 211; y: 217
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 5152
+        hash: "1eb5f0e1aa014a38e6ca66ddfc2a076b"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 211; y: 218
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 5168
+        hash: "d9e953d132330f8a58a190d61aec6ec3"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 210; y: 219
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 210; y: 220
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 5184
+        hash: "c1570ad4cb688ea51818e0a09e349daa"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 210; y: 222
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 5200
+        hash: "11853dcbad9d1d9a8b7d8a4e6fcca140"
+    }
+    Frame {
+        msec: 5216
+        hash: "11853dcbad9d1d9a8b7d8a4e6fcca140"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 210; y: 223
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 5232
+        hash: "11853dcbad9d1d9a8b7d8a4e6fcca140"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 209; y: 224
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 5248
+        hash: "c6a81be579382f25ac583734897c2570"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 209; y: 225
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 5264
+        hash: "c6a81be579382f25ac583734897c2570"
+    }
+    Frame {
+        msec: 5280
+        hash: "c6a81be579382f25ac583734897c2570"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 209; y: 226
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 5296
+        hash: "8cbeb925f039bde9846d37a5ec6cd3f9"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 209; y: 227
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 5312
+        hash: "8cbeb925f039bde9846d37a5ec6cd3f9"
+    }
+    Frame {
+        msec: 5328
+        hash: "8cbeb925f039bde9846d37a5ec6cd3f9"
+    }
+    Frame {
+        msec: 5344
+        hash: "8cbeb925f039bde9846d37a5ec6cd3f9"
+    }
+    Frame {
+        msec: 5360
+        hash: "8cbeb925f039bde9846d37a5ec6cd3f9"
+    }
+    Mouse {
+        type: 3
+        button: 1
+        buttons: 0
+        x: 209; y: 227
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 5376
+        hash: "8cbeb925f039bde9846d37a5ec6cd3f9"
+    }
+    Frame {
+        msec: 5392
+        hash: "c6a81be579382f25ac583734897c2570"
+    }
+    Frame {
+        msec: 5408
+        hash: "11853dcbad9d1d9a8b7d8a4e6fcca140"
+    }
+    Frame {
+        msec: 5424
+        hash: "1eb5f0e1aa014a38e6ca66ddfc2a076b"
+    }
+    Frame {
+        msec: 5440
+        hash: "9f876eb93a16c24843dd6a5acd303ab3"
+    }
+    Frame {
+        msec: 5456
+        hash: "1533c6ff17e79a47a5d3510aa85bcf8a"
+    }
+    Frame {
+        msec: 5472
+        hash: "9a9d1e0b1d7b9291480b3ec641f354ce"
+    }
+    Frame {
+        msec: 5488
+        hash: "ee40862a59f14667c89fa62f380c10fb"
+    }
+    Frame {
+        msec: 5504
+        hash: "95b57cd3dac3bce56674f2c4143f42d4"
+    }
+    Frame {
+        msec: 5520
+        hash: "52d45e8dde81fef5ee93bbd5a40d4851"
+    }
+    Frame {
+        msec: 5536
+        hash: "05b3013c9e42ed9ced7009d2e2999357"
+    }
+    Frame {
+        msec: 5552
+        hash: "7d03030f5a672d87aeabefdf4f3a39a4"
+    }
+    Frame {
+        msec: 5568
+        hash: "79650397b868019909b931a32a115823"
+    }
+    Frame {
+        msec: 5584
+        hash: "82f54d7e254edcf499ea12a63118e8a7"
+    }
+    Frame {
+        msec: 5600
+        hash: "8517007d5102af238935e93a3b38087f"
+    }
+    Frame {
+        msec: 5616
+        hash: "dc272fc8fc98d822a154da1d495d4f7e"
+    }
+    Frame {
+        msec: 5632
+        hash: "11120d6de575ffa639b6abb3af4afef7"
+    }
+    Frame {
+        msec: 5648
+        hash: "70e522f64236dfa4e1613ffc29b4b23e"
+    }
+    Frame {
+        msec: 5664
+        hash: "7a5f69a1eecb5de0fc2295cd287eb449"
+    }
+    Frame {
+        msec: 5680
+        hash: "a569789b082296415321ba11c859abe5"
+    }
+    Frame {
+        msec: 5696
+        hash: "9f9f85d5f879b0e52ebc751d6668cfb8"
+    }
+    Frame {
+        msec: 5712
+        hash: "9f9f85d5f879b0e52ebc751d6668cfb8"
+    }
+    Frame {
+        msec: 5728
+        hash: "43fc85bb3b1501f5e12f1fedaaa14c64"
+    }
+    Frame {
+        msec: 5744
+        hash: "43fc85bb3b1501f5e12f1fedaaa14c64"
+    }
+    Frame {
+        msec: 5760
+        image: "mousearea-flickable.5.png"
+    }
+    Frame {
+        msec: 5776
+        hash: "d75a43305e2884759ca41d7b1cbadf52"
+    }
+    Frame {
+        msec: 5792
+        hash: "d75a43305e2884759ca41d7b1cbadf52"
+    }
+    Frame {
+        msec: 5808
+        hash: "d75a43305e2884759ca41d7b1cbadf52"
+    }
+    Frame {
+        msec: 5824
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 5840
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 5856
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 5872
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 5888
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 5904
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 5920
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 5936
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 5952
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 5968
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 5984
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 6000
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 6016
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 6032
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 6048
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 6064
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 6080
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 6096
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 6112
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 6128
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 6144
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 6160
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 6176
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 6192
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 6208
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 6224
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 6240
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 6256
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 6272
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 6288
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 6304
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 6320
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 6336
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 6352
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 6368
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Mouse {
+        type: 2
+        button: 1
+        buttons: 1
+        x: 188; y: 180
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 6384
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6400
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6416
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6432
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6448
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6464
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6480
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6496
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6512
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6528
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6544
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6560
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6576
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6592
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6608
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6624
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6640
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6656
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6672
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6688
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6704
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6720
+        image: "mousearea-flickable.6.png"
+    }
+    Frame {
+        msec: 6736
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6752
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6768
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6784
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6800
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6816
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6832
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6848
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6864
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6880
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6896
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6912
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6928
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6944
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6960
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6976
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 6992
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7008
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7024
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7040
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7056
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7072
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7088
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7104
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7120
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7136
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7152
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7168
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7184
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7200
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7216
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7232
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7248
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7264
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7280
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7296
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7312
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7328
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7344
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7360
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7376
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7392
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7408
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7424
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7440
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7456
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7472
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7488
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7504
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7520
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7536
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7552
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7568
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7584
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7600
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7616
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7632
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7648
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7664
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7680
+        image: "mousearea-flickable.7.png"
+    }
+    Frame {
+        msec: 7696
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7712
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7728
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7744
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7760
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7776
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7792
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7808
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7824
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7840
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7856
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7872
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7888
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7904
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7920
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7936
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7952
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7968
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 7984
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 8000
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 8016
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 8032
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 8048
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 8064
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 8080
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 8096
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 8112
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 8128
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 8144
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 8160
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 8176
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Frame {
+        msec: 8192
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 188; y: 182
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8208
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 188; y: 183
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8224
+        hash: "037386eb30a5e8d53a20a11258ee0f60"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 189; y: 185
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 189; y: 186
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8240
+        hash: "9f9f85d5f879b0e52ebc751d6668cfb8"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 191; y: 194
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8256
+        hash: "70e522f64236dfa4e1613ffc29b4b23e"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 191; y: 196
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 192; y: 198
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8272
+        hash: "11120d6de575ffa639b6abb3af4afef7"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 192; y: 201
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 192; y: 203
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8288
+        hash: "dc272fc8fc98d822a154da1d495d4f7e"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 194; y: 211
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 194; y: 214
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8304
+        hash: "4e129ebba85d1f3717d09f71eb5a1a7d"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 194; y: 219
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8320
+        hash: "837deeb2a92648d830acf29e829ebb53"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 194; y: 225
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8336
+        hash: "7d2606d432858288dac019e0002ff85a"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 192; y: 231
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 192; y: 234
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8352
+        hash: "c37507a29e3a6d80446ad68f2d92f266"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 192; y: 240
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8368
+        hash: "01bf03313a0229e810a24e2adbbe9775"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 192; y: 245
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8384
+        hash: "8ffbbed46737837e55383833b96d2624"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 192; y: 248
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 192; y: 251
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8400
+        hash: "6d49fc41fb6d74643c7613df7e417833"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 192; y: 257
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8416
+        hash: "1978cda418856b542d7c5a155b74f09c"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 192; y: 259
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 192; y: 262
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8432
+        hash: "cc6619c7cd6e4e274df4729aad6cca46"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 192; y: 265
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 192; y: 267
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8448
+        hash: "0b16e524cd5253d07aa9b5855967fa71"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 192; y: 270
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 192; y: 272
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8464
+        hash: "0121c18897c37481fddbac57db636a60"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 192; y: 275
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 192; y: 278
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8480
+        hash: "091d1ad7aba4b662cba98214c98a4707"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 193; y: 283
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8496
+        hash: "f334bfcc3af89bf1405762a215c54ea6"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 193; y: 285
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 193; y: 288
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8512
+        hash: "66f71641c7a607152f140428ab9621d6"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 194; y: 290
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 194; y: 293
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8528
+        hash: "7b41d651ad46341859d0188db341ae10"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 194; y: 298
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8544
+        hash: "95b57cd3dac3bce56674f2c4143f42d4"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 194; y: 299
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 196; y: 305
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8560
+        hash: "80edf52cc9e64a29f677bc2203220ba9"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 196; y: 306
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 196; y: 308
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8576
+        hash: "68c8c95edb8cce11320715266bd62628"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 196; y: 310
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 196; y: 312
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8592
+        hash: "c09f4002ed9d41f62bb1aaff95723cce"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 196; y: 316
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8608
+        hash: "7bb17b13db811b02c86a24a0051336d9"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 196; y: 318
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 196; y: 320
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8624
+        hash: "6d6cec95a6a2445d88b015ff76af032e"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 196; y: 322
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 196; y: 324
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8640
+        image: "mousearea-flickable.8.png"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 196; y: 328
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8656
+        hash: "9a9d1e0b1d7b9291480b3ec641f354ce"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 196; y: 330
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 196; y: 332
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8672
+        hash: "d1372239a681d1fccc25257b4a02fb39"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 196; y: 335
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 196; y: 338
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8688
+        hash: "2010f6f0c34e59f505bbe1aab262b646"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 196; y: 341
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 198; y: 347
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8704
+        hash: "2dc2def0c748ac94d33d90d4a3610136"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 198; y: 350
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 200; y: 356
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8720
+        hash: "1eb5f0e1aa014a38e6ca66ddfc2a076b"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 200; y: 358
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 200; y: 360
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8736
+        hash: "c1570ad4cb688ea51818e0a09e349daa"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 201; y: 364
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8752
+        hash: "c6a81be579382f25ac583734897c2570"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 201; y: 366
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8768
+        hash: "8cbeb925f039bde9846d37a5ec6cd3f9"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 202; y: 368
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8784
+        hash: "b34a796f25ad62f952101b296f9c2bac"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 202; y: 369
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8800
+        hash: "a0814b5ba881e5da8a1ecae8d714b4ce"
+    }
+    Frame {
+        msec: 8816
+        hash: "a0814b5ba881e5da8a1ecae8d714b4ce"
+    }
+    Frame {
+        msec: 8832
+        hash: "a0814b5ba881e5da8a1ecae8d714b4ce"
+    }
+    Frame {
+        msec: 8848
+        hash: "a0814b5ba881e5da8a1ecae8d714b4ce"
+    }
+    Frame {
+        msec: 8864
+        hash: "a0814b5ba881e5da8a1ecae8d714b4ce"
+    }
+    Frame {
+        msec: 8880
+        hash: "a0814b5ba881e5da8a1ecae8d714b4ce"
+    }
+    Frame {
+        msec: 8896
+        hash: "a0814b5ba881e5da8a1ecae8d714b4ce"
+    }
+    Frame {
+        msec: 8912
+        hash: "a0814b5ba881e5da8a1ecae8d714b4ce"
+    }
+    Frame {
+        msec: 8928
+        hash: "a0814b5ba881e5da8a1ecae8d714b4ce"
+    }
+    Frame {
+        msec: 8944
+        hash: "a0814b5ba881e5da8a1ecae8d714b4ce"
+    }
+    Frame {
+        msec: 8960
+        hash: "a0814b5ba881e5da8a1ecae8d714b4ce"
+    }
+    Frame {
+        msec: 8976
+        hash: "a0814b5ba881e5da8a1ecae8d714b4ce"
+    }
+    Mouse {
+        type: 3
+        button: 1
+        buttons: 0
+        x: 202; y: 369
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 8992
+        hash: "a0814b5ba881e5da8a1ecae8d714b4ce"
+    }
+    Frame {
+        msec: 9008
+        hash: "b34a796f25ad62f952101b296f9c2bac"
+    }
+    Frame {
+        msec: 9024
+        hash: "8cbeb925f039bde9846d37a5ec6cd3f9"
+    }
+    Frame {
+        msec: 9040
+        hash: "c1570ad4cb688ea51818e0a09e349daa"
+    }
+    Frame {
+        msec: 9056
+        hash: "237dd62011f4253970b946b335e3fb71"
+    }
+    Frame {
+        msec: 9072
+        hash: "c5980322acf00a04efbd5e1b92aa0e98"
+    }
+    Frame {
+        msec: 9088
+        hash: "d1372239a681d1fccc25257b4a02fb39"
+    }
+    Frame {
+        msec: 9104
+        hash: "524db6ce45674c777d72f9206415be2f"
+    }
+    Frame {
+        msec: 9120
+        hash: "021bda841eaefa76ce5e1c97150af6f6"
+    }
+    Frame {
+        msec: 9136
+        hash: "ce673b66f695f5b002515a5416bbf913"
+    }
+    Frame {
+        msec: 9152
+        hash: "cc6619c7cd6e4e274df4729aad6cca46"
+    }
+    Frame {
+        msec: 9168
+        hash: "7fb0ed99b7d751d1f335afd7c0de2f2c"
+    }
+    Frame {
+        msec: 9184
+        hash: "3d75735eefbf95f37e2a8605b9167ba1"
+    }
+    Frame {
+        msec: 9200
+        hash: "82f54d7e254edcf499ea12a63118e8a7"
+    }
+    Frame {
+        msec: 9216
+        hash: "8517007d5102af238935e93a3b38087f"
+    }
+    Frame {
+        msec: 9232
+        hash: "dc272fc8fc98d822a154da1d495d4f7e"
+    }
+    Frame {
+        msec: 9248
+        hash: "11120d6de575ffa639b6abb3af4afef7"
+    }
+    Frame {
+        msec: 9264
+        hash: "70e522f64236dfa4e1613ffc29b4b23e"
+    }
+    Frame {
+        msec: 9280
+        hash: "7a5f69a1eecb5de0fc2295cd287eb449"
+    }
+    Frame {
+        msec: 9296
+        hash: "a569789b082296415321ba11c859abe5"
+    }
+    Frame {
+        msec: 9312
+        hash: "9f9f85d5f879b0e52ebc751d6668cfb8"
+    }
+    Frame {
+        msec: 9328
+        hash: "9f9f85d5f879b0e52ebc751d6668cfb8"
+    }
+    Frame {
+        msec: 9344
+        hash: "43fc85bb3b1501f5e12f1fedaaa14c64"
+    }
+    Frame {
+        msec: 9360
+        hash: "43fc85bb3b1501f5e12f1fedaaa14c64"
+    }
+    Frame {
+        msec: 9376
+        hash: "d75a43305e2884759ca41d7b1cbadf52"
+    }
+    Frame {
+        msec: 9392
+        hash: "d75a43305e2884759ca41d7b1cbadf52"
+    }
+    Frame {
+        msec: 9408
+        hash: "d75a43305e2884759ca41d7b1cbadf52"
+    }
+    Frame {
+        msec: 9424
+        hash: "d75a43305e2884759ca41d7b1cbadf52"
+    }
+    Frame {
+        msec: 9440
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 9456
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 9472
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 9488
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 9504
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 9520
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 9536
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 9552
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 9568
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 9584
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 9600
+        image: "mousearea-flickable.9.png"
+    }
+    Frame {
+        msec: 9616
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 9632
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 9648
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 9664
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 9680
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 9696
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 9712
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 9728
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 9744
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Mouse {
+        type: 2
+        button: 1
+        buttons: 1
+        x: 205; y: 307
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 9760
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 9776
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 9792
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 9808
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 9824
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 9840
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 9856
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 9872
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 9888
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 9904
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 9920
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 9936
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 9952
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 9968
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 9984
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10000
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10016
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10032
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10048
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10064
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10080
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10096
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10112
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10128
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10144
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10160
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10176
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10192
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10208
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10224
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10240
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10256
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10272
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10288
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10304
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10320
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10336
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10352
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10368
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10384
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10400
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10416
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10432
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10448
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10464
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10480
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10496
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10512
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10528
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10544
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10560
+        image: "mousearea-flickable.10.png"
+    }
+    Frame {
+        msec: 10576
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10592
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10608
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10624
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10640
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10656
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10672
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10688
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10704
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10720
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10736
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10752
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10768
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10784
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10800
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10816
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10832
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10848
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10864
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10880
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10896
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10912
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10928
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10944
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10960
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10976
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 10992
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 11008
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 11024
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 11040
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 11056
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 11072
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 11088
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 205; y: 308
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11104
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 11120
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 11136
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 205; y: 309
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11152
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 11168
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Frame {
+        msec: 11184
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 205; y: 310
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11200
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 205; y: 311
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11216
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 205; y: 312
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11232
+        hash: "90cdfe8920f115fd55cde6fdbd95e867"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 206; y: 313
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 206; y: 314
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11248
+        hash: "a569789b082296415321ba11c859abe5"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 206; y: 316
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 206; y: 317
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11264
+        hash: "86b32befe0dada5bdce82a7dd14777ce"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 206; y: 319
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 206; y: 321
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11280
+        hash: "70e522f64236dfa4e1613ffc29b4b23e"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 206; y: 324
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11296
+        hash: "11120d6de575ffa639b6abb3af4afef7"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 206; y: 326
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 206; y: 327
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11312
+        hash: "8e05207e0d0d9d15a61a0d21d985a83a"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 206; y: 330
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 206; y: 332
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11328
+        hash: "6602009ffe3c0f3072640ebc8749b76f"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 206; y: 335
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 206; y: 337
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11344
+        hash: "8517007d5102af238935e93a3b38087f"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 204; y: 343
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 204; y: 345
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11360
+        hash: "82f54d7e254edcf499ea12a63118e8a7"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 204; y: 348
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 204; y: 350
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11376
+        hash: "572cb62d69ccb973ea18d3b0eaff571b"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 204; y: 352
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 204; y: 355
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11392
+        hash: "79650397b868019909b931a32a115823"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 204; y: 357
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 204; y: 359
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11408
+        hash: "43e50f4d4d37373e26af0a5d3cb64c4c"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 204; y: 361
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 204; y: 363
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11424
+        hash: "a0f8eb8a796f67c368b0a479e8d14681"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 204; y: 365
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 204; y: 367
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11440
+        hash: "01bf03313a0229e810a24e2adbbe9775"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 203; y: 369
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 203; y: 371
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11456
+        hash: "7fb0ed99b7d751d1f335afd7c0de2f2c"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 203; y: 373
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 203; y: 375
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11472
+        hash: "363eca81f97f20f14e8d480f83d2bc7d"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 203; y: 379
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11488
+        hash: "6d49fc41fb6d74643c7613df7e417833"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 203; y: 381
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 203; y: 383
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11504
+        hash: "806d22bc3533c729cd10dc889c36902d"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 203; y: 385
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 203; y: 387
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11520
+        image: "mousearea-flickable.11.png"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 203; y: 389
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 203; y: 392
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11536
+        hash: "929bf28dcb97e8c93dae5dbe23beecc8"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 203; y: 394
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 204; y: 396
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11552
+        hash: "cb49adcd2c8afe27fd5926bd622added"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 204; y: 398
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 204; y: 399
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11568
+        hash: "0121c18897c37481fddbac57db636a60"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 205; y: 402
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11584
+        hash: "c0a569ee064d844835dddab11eadcd33"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 205; y: 404
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 205; y: 406
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11600
+        hash: "52d45e8dde81fef5ee93bbd5a40d4851"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 205; y: 407
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 206; y: 409
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11616
+        hash: "ce673b66f695f5b002515a5416bbf913"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 206; y: 410
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11632
+        hash: "f334bfcc3af89bf1405762a215c54ea6"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 206; y: 411
+        modifiers: 0
+        sendToViewport: true
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 206; y: 412
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11648
+        hash: "ee0523fe6a33b59871ad3b311ca0cbeb"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 207; y: 414
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11664
+        hash: "66f71641c7a607152f140428ab9621d6"
+    }
+    Frame {
+        msec: 11680
+        hash: "66f71641c7a607152f140428ab9621d6"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 207; y: 415
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11696
+        hash: "66f71641c7a607152f140428ab9621d6"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 207; y: 416
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11712
+        hash: "ddd3d8cb82e238358cdb16c1df7d27b7"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 207; y: 417
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11728
+        hash: "ddd3d8cb82e238358cdb16c1df7d27b7"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 208; y: 418
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11744
+        hash: "29ca97cc573d3a1fde65320b61678c60"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 208; y: 419
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11760
+        hash: "29ca97cc573d3a1fde65320b61678c60"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 208; y: 421
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11776
+        hash: "7b41d651ad46341859d0188db341ae10"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 208; y: 423
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11792
+        hash: "6b236864b7d95bf9f76b8afd6ba78613"
+    }
+    Frame {
+        msec: 11808
+        hash: "6b236864b7d95bf9f76b8afd6ba78613"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 208; y: 424
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11824
+        hash: "95b57cd3dac3bce56674f2c4143f42d4"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 208; y: 425
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11840
+        hash: "95b57cd3dac3bce56674f2c4143f42d4"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 209; y: 426
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11856
+        hash: "021bda841eaefa76ce5e1c97150af6f6"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 209; y: 428
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11872
+        hash: "b1ea82b880a2fc35bf1ed117d8ab21b0"
+    }
+    Frame {
+        msec: 11888
+        hash: "b1ea82b880a2fc35bf1ed117d8ab21b0"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 209; y: 429
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11904
+        hash: "b1ea82b880a2fc35bf1ed117d8ab21b0"
+    }
+    Frame {
+        msec: 11920
+        hash: "b1ea82b880a2fc35bf1ed117d8ab21b0"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 209; y: 430
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11936
+        hash: "1709dda08ce7494ff6d082cc5d93f0d2"
+    }
+    Frame {
+        msec: 11952
+        hash: "1709dda08ce7494ff6d082cc5d93f0d2"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 209; y: 431
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 11968
+        hash: "1709dda08ce7494ff6d082cc5d93f0d2"
+    }
+    Frame {
+        msec: 11984
+        hash: "1709dda08ce7494ff6d082cc5d93f0d2"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 209; y: 432
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 12000
+        hash: "80edf52cc9e64a29f677bc2203220ba9"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 209; y: 433
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 12016
+        hash: "80edf52cc9e64a29f677bc2203220ba9"
+    }
+    Frame {
+        msec: 12032
+        hash: "80edf52cc9e64a29f677bc2203220ba9"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 210; y: 434
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 12048
+        hash: "68c8c95edb8cce11320715266bd62628"
+    }
+    Frame {
+        msec: 12064
+        hash: "68c8c95edb8cce11320715266bd62628"
+    }
+    Frame {
+        msec: 12080
+        hash: "68c8c95edb8cce11320715266bd62628"
+    }
+    Frame {
+        msec: 12096
+        hash: "68c8c95edb8cce11320715266bd62628"
+    }
+    Frame {
+        msec: 12112
+        hash: "68c8c95edb8cce11320715266bd62628"
+    }
+    Mouse {
+        type: 5
+        button: 0
+        buttons: 1
+        x: 210; y: 435
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 12128
+        hash: "68c8c95edb8cce11320715266bd62628"
+    }
+    Frame {
+        msec: 12144
+        hash: "68c8c95edb8cce11320715266bd62628"
+    }
+    Frame {
+        msec: 12160
+        hash: "68c8c95edb8cce11320715266bd62628"
+    }
+    Frame {
+        msec: 12176
+        hash: "68c8c95edb8cce11320715266bd62628"
+    }
+    Frame {
+        msec: 12192
+        hash: "68c8c95edb8cce11320715266bd62628"
+    }
+    Mouse {
+        type: 3
+        button: 1
+        buttons: 0
+        x: 210; y: 435
+        modifiers: 0
+        sendToViewport: true
+    }
+    Frame {
+        msec: 12208
+        hash: "68c8c95edb8cce11320715266bd62628"
+    }
+    Frame {
+        msec: 12224
+        hash: "68c8c95edb8cce11320715266bd62628"
+    }
+    Frame {
+        msec: 12240
+        hash: "80edf52cc9e64a29f677bc2203220ba9"
+    }
+    Frame {
+        msec: 12256
+        hash: "b1ea82b880a2fc35bf1ed117d8ab21b0"
+    }
+    Frame {
+        msec: 12272
+        hash: "6b236864b7d95bf9f76b8afd6ba78613"
+    }
+    Frame {
+        msec: 12288
+        hash: "ddd3d8cb82e238358cdb16c1df7d27b7"
+    }
+    Frame {
+        msec: 12304
+        hash: "ce673b66f695f5b002515a5416bbf913"
+    }
+    Frame {
+        msec: 12320
+        hash: "0121c18897c37481fddbac57db636a60"
+    }
+    Frame {
+        msec: 12336
+        hash: "cc6619c7cd6e4e274df4729aad6cca46"
+    }
+    Frame {
+        msec: 12352
+        hash: "aafb12a520eb443ee1348282f2c54e4a"
+    }
+    Frame {
+        msec: 12368
+        hash: "c37507a29e3a6d80446ad68f2d92f266"
+    }
+    Frame {
+        msec: 12384
+        hash: "6ef4abc294d928381346e8ff9b012475"
+    }
+    Frame {
+        msec: 12400
+        hash: "4e129ebba85d1f3717d09f71eb5a1a7d"
+    }
+    Frame {
+        msec: 12416
+        hash: "6602009ffe3c0f3072640ebc8749b76f"
+    }
+    Frame {
+        msec: 12432
+        hash: "8e05207e0d0d9d15a61a0d21d985a83a"
+    }
+    Frame {
+        msec: 12448
+        hash: "144eeb7c2a32cedb6ebba063501c9176"
+    }
+    Frame {
+        msec: 12464
+        hash: "7a5f69a1eecb5de0fc2295cd287eb449"
+    }
+    Frame {
+        msec: 12480
+        image: "mousearea-flickable.12.png"
+    }
+    Frame {
+        msec: 12496
+        hash: "a569789b082296415321ba11c859abe5"
+    }
+    Frame {
+        msec: 12512
+        hash: "9f9f85d5f879b0e52ebc751d6668cfb8"
+    }
+    Frame {
+        msec: 12528
+        hash: "43fc85bb3b1501f5e12f1fedaaa14c64"
+    }
+    Frame {
+        msec: 12544
+        hash: "43fc85bb3b1501f5e12f1fedaaa14c64"
+    }
+    Frame {
+        msec: 12560
+        hash: "d75a43305e2884759ca41d7b1cbadf52"
+    }
+    Frame {
+        msec: 12576
+        hash: "d75a43305e2884759ca41d7b1cbadf52"
+    }
+    Frame {
+        msec: 12592
+        hash: "d75a43305e2884759ca41d7b1cbadf52"
+    }
+    Frame {
+        msec: 12608
+        hash: "d75a43305e2884759ca41d7b1cbadf52"
+    }
+    Frame {
+        msec: 12624
+        hash: "d75a43305e2884759ca41d7b1cbadf52"
+    }
+    Frame {
+        msec: 12640
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 12656
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 12672
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 12688
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 12704
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 12720
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 12736
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 12752
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 12768
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 12784
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 12800
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 12816
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 12832
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 12848
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 12864
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 12880
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 12896
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 12912
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 12928
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 12944
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 12960
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 12976
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 12992
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 13008
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 13024
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 13040
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 13056
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 13072
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 13088
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 13104
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 13120
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 13136
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 13152
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 13168
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 13184
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 13200
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 13216
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 13232
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 13248
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 13264
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 13280
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 13296
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 13312
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 13328
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 13344
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 13360
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Key {
+        type: 6
+        key: 16777251
+        modifiers: 134217728
+        text: ""
+        autorep: false
+        count: 1
+    }
+    Frame {
+        msec: 13376
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 13392
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 13408
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 13424
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 13440
+        image: "mousearea-flickable.13.png"
+    }
+    Frame {
+        msec: 13456
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 13472
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 13488
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+    Frame {
+        msec: 13504
+        hash: "cc1fd2f4c3be318052254a9b6be7a57b"
+    }
+}
diff --git a/tests/auto/declarative/qmlvisual/qdeclarativemousearea/mousearea-flickable.qml b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/mousearea-flickable.qml
new file mode 100644
index 0000000..a0b787f
--- /dev/null
+++ b/tests/auto/declarative/qmlvisual/qdeclarativemousearea/mousearea-flickable.qml
@@ -0,0 +1,52 @@
+import Qt 4.7
+
+Rectangle {
+    width: 400; height: 480
+    color: "white"
+
+    Flickable {
+        anchors.fill: parent
+        contentHeight: 100
+
+        Rectangle {
+            id: yellow
+            width: 400; height: 120
+            color: "yellow"
+            MouseArea {
+                anchors.fill: parent
+                onPressedChanged: pressed ? yellow.color = "lightyellow": yellow.color = "yellow"
+            }
+        }
+        Rectangle {
+            id: blue
+            width: 400; height: 120
+            y: 120
+            color: "steelblue"
+            MouseArea {
+                anchors.fill: parent
+                onPressed: blue.color = "lightsteelblue"
+                onReleased: blue.color = "steelblue"
+            }
+        }
+        Rectangle {
+            id: red
+            y: 240
+            width: 400; height: 120
+            color: "red"
+            MouseArea {
+                anchors.fill: parent
+                onEntered:  { red.color = "darkred"; tooltip.opacity = 1 }
+                onExited: { red.color = "red"; tooltip.opacity = 0 }
+            }
+            Rectangle {
+                id: tooltip
+                x: 10; y: 20
+                width: 100; height: 50
+                color: "green"
+                opacity: 0
+            }
+        }
+
+    }
+
+}
diff --git a/tests/auto/declarative/qmlvisual/tst_qmlvisual.cpp b/tests/auto/declarative/qmlvisual/tst_qmlvisual.cpp
index 681b530..5f25882 100644
--- a/tests/auto/declarative/qmlvisual/tst_qmlvisual.cpp
+++ b/tests/auto/declarative/qmlvisual/tst_qmlvisual.cpp
@@ -117,6 +117,9 @@ void tst_qmlvisual::visual_data()
         files << QT_TEST_SOURCE_DIR "/qdeclarativemousearea/drag.qml";
         files << QT_TEST_SOURCE_DIR "/fillmode/fillmode.qml";
 
+        // new tests
+        files << QT_TEST_SOURCE_DIR "/qdeclarativemousearea/mousearea-flickable.qml";
+
         //these reliably fail in CI, for unknown reasons
         //files << QT_TEST_SOURCE_DIR "/animation/easing/easing.qml";
         //files << QT_TEST_SOURCE_DIR "/animation/pauseAnimation/pauseAnimation-visual.qml";
diff --git a/tests/auto/macgui/tst_macgui.cpp b/tests/auto/macgui/tst_macgui.cpp
index 847ba4b..7f558a3 100644
--- a/tests/auto/macgui/tst_macgui.cpp
+++ b/tests/auto/macgui/tst_macgui.cpp
@@ -60,7 +60,6 @@ private slots:
     
     void dummy();
     void splashScreenModality();
-    void dialogModality();
     void nonModalOrder();
 
     void spinBoxArrowButtons();
@@ -157,32 +156,6 @@ void tst_MacGui::splashScreenModality()
     QVERIFY(QTestEventLoop::instance().timeout() == false);
 }
 
-
-/*
-    Test that a non-modal dialog created as a child of a modal dialog is
-    shown in front.
-*/
-void tst_MacGui::dialogModality()
-{ 
-    QDialog d;
-    d.setModal(true);
-    d.show();
-    
-    QProgressDialog progress(&d);
-    progress.setValue(2);
-
-    InterfaceChildPair interface = wn.find(QAccessible::Name, "Cancel", &progress);
-    QVERIFY(interface.iface);
-    const int delay = 2000;
-    clickLater(interface, Qt::LeftButton, delay);
-    
-    connect(&progress, SIGNAL(canceled()), SLOT(exitLoopSlot()));
-
-    const int timeout = 3;
-    QTestEventLoop::instance().enterLoop(timeout);
-    QVERIFY(QTestEventLoop::instance().timeout() == false);
-}
-
 class PrimaryWindowDialog : public QDialog
 {
 Q_OBJECT
diff --git a/tests/auto/macnativeevents/tst_macnativeevents.cpp b/tests/auto/macnativeevents/tst_macnativeevents.cpp
index 08ab9e6..70a14f5 100644
--- a/tests/auto/macnativeevents/tst_macnativeevents.cpp
+++ b/tests/auto/macnativeevents/tst_macnativeevents.cpp
@@ -41,6 +41,7 @@
 
 #include <QApplication>
 #include <QWidget>
+#include <QDialog>
 #include <QPushButton>
 #include <QtTest/QtTest>
 
@@ -65,6 +66,7 @@ private slots:
     void testMouseDragToNonClientArea();
     void testDragWindow();
     void testMouseEnter();
+    void testChildDialogInFrontOfModalParent();
 };
 
 void tst_MacNativeEvents::testMouseMoveLocation()
@@ -282,6 +284,28 @@ void tst_MacNativeEvents::testMouseEnter()
     QVERIFY2(expected.waitForAllEvents(), "the test did not receive all expected events!");
 }
 
+void tst_MacNativeEvents::testChildDialogInFrontOfModalParent()
+{
+    // Test that a child dialog of a modal parent dialog is 
+    // in front of the parent, and active:
+    QDialog parent;
+    parent.setWindowModality(Qt::ApplicationModal);
+    QDialog child(&parent);
+    QPushButton button("close", &child);
+    connect(&button, SIGNAL(clicked()), &child, SLOT(close()));
+    parent.show();
+    child.show();
+    QPoint inside = button.mapToGlobal(button.geometry().center());
+
+    // Post a click on the button to close the child dialog:
+    NativeEventList native;
+    native.append(new QNativeMouseButtonEvent(inside, Qt::LeftButton, 1, Qt::NoModifier));
+    native.append(new QNativeMouseButtonEvent(inside, Qt::LeftButton, 0, Qt::NoModifier));
+
+    native.play();
+    QTest::qWait(100);
+    QVERIFY(!child.isVisible());
+}
 
 #include "tst_macnativeevents.moc"
 
diff --git a/tests/auto/qfileinfo/tst_qfileinfo.cpp b/tests/auto/qfileinfo/tst_qfileinfo.cpp
index da5c772..403c5f9 100644
--- a/tests/auto/qfileinfo/tst_qfileinfo.cpp
+++ b/tests/auto/qfileinfo/tst_qfileinfo.cpp
@@ -1189,7 +1189,7 @@ void tst_QFileInfo::isLocalFs()
 
 void tst_QFileInfo::refresh()
 {
-#if defined(Q_OS_WINCE)
+#if defined(Q_OS_WINCE) || defined(Q_OS_WIN)
     int sleepTime = 3000;
 #else
     int sleepTime = 2000;
diff --git a/tests/auto/qlocale/tst_qlocale.cpp b/tests/auto/qlocale/tst_qlocale.cpp
index 182f73b..7a5d8a6 100644
--- a/tests/auto/qlocale/tst_qlocale.cpp
+++ b/tests/auto/qlocale/tst_qlocale.cpp
@@ -1921,7 +1921,7 @@ void tst_QLocale::dateFormat()
     const QLocale no("no_NO");
     QCOMPARE(no.dateFormat(QLocale::NarrowFormat), QLatin1String("dd.MM.yy"));
     QCOMPARE(no.dateFormat(QLocale::ShortFormat), QLatin1String("dd.MM.yy"));
-    QCOMPARE(no.dateFormat(QLocale::LongFormat), QLatin1String("dddd d. MMMM y"));
+    QCOMPARE(no.dateFormat(QLocale::LongFormat), QLatin1String("dddd d. MMMM yyyy"));
 }
 
 void tst_QLocale::timeFormat()
@@ -1933,7 +1933,7 @@ void tst_QLocale::timeFormat()
     const QLocale no("no_NO");
     QCOMPARE(no.timeFormat(QLocale::NarrowFormat), QLatin1String("HH:mm"));
     QCOMPARE(no.timeFormat(QLocale::ShortFormat), QLatin1String("HH:mm"));
-    QCOMPARE(no.timeFormat(QLocale::LongFormat), QLatin1String("'kl'. HH:mm:ss tttt"));
+    QCOMPARE(no.timeFormat(QLocale::LongFormat), QLatin1String("'kl'. HH:mm:ss t"));
 }
 
 void tst_QLocale::dateTimeFormat()
@@ -1945,7 +1945,7 @@ void tst_QLocale::dateTimeFormat()
     const QLocale no("no_NO");
     QCOMPARE(no.dateTimeFormat(QLocale::NarrowFormat), QLatin1String("dd.MM.yy HH:mm"));
     QCOMPARE(no.dateTimeFormat(QLocale::ShortFormat), QLatin1String("dd.MM.yy HH:mm"));
-    QCOMPARE(no.dateTimeFormat(QLocale::LongFormat), QLatin1String("dddd d. MMMM y 'kl'. HH:mm:ss tttt"));
+    QCOMPARE(no.dateTimeFormat(QLocale::LongFormat), QLatin1String("dddd d. MMMM yyyy 'kl'. HH:mm:ss t"));
 }
 
 void tst_QLocale::monthName()
diff --git a/tests/auto/qnetworkconfiguration/qnetworkconfiguration.pro b/tests/auto/qnetworkconfiguration/qnetworkconfiguration.pro
index df2d2d9..ca463bd 100644
--- a/tests/auto/qnetworkconfiguration/qnetworkconfiguration.pro
+++ b/tests/auto/qnetworkconfiguration/qnetworkconfiguration.pro
@@ -8,7 +8,7 @@ symbian {
     TARGET.CAPABILITY = NetworkServices NetworkControl ReadUserData 
 }
 
-maemo6 {
+maemo6|maemo5 {
     CONFIG += link_pkgconfig
 
     PKGCONFIG += conninet
diff --git a/tests/auto/qnetworkconfiguration/tst_qnetworkconfiguration.cpp b/tests/auto/qnetworkconfiguration/tst_qnetworkconfiguration.cpp
index 70f4447..ce3acb7 100644
--- a/tests/auto/qnetworkconfiguration/tst_qnetworkconfiguration.cpp
+++ b/tests/auto/qnetworkconfiguration/tst_qnetworkconfiguration.cpp
@@ -1,6 +1,6 @@
 /****************************************************************************
 **
-** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
+** Copyright (C) 2010 Nokia Corporation and/or its subsidiary(-ies).
 ** All rights reserved.
 ** Contact: Nokia Corporation (qt-info@nokia.com)
 **
@@ -41,10 +41,11 @@
 
 #include <QtTest/QtTest>
 #include "../qbearertestcommon.h"
-#include "qnetworkconfiguration.h"
-#include "qnetworkconfigmanager.h"
 
-#ifdef Q_WS_MAEMO_6
+#include <QtNetwork/qnetworkconfiguration.h>
+#include <QtNetwork/qnetworkconfigmanager.h>
+
+#if defined(Q_WS_MAEMO_6) || defined(Q_WS_MAEMO_5)
 #include <stdio.h>
 #include <iapconf.h>
 #endif
@@ -65,7 +66,7 @@ private slots:
     void isRoamingAvailable();
 
 private:
-#ifdef Q_WS_MAEMO_6
+#if defined(Q_WS_MAEMO_6) || defined(Q_WS_MAEMO_5)
     Maemo::IAPConf *iapconf;
     Maemo::IAPConf *iapconf2;
     Maemo::IAPConf *gprsiap;
@@ -77,7 +78,7 @@ private:
 
 void tst_QNetworkConfiguration::initTestCase()
 {
-#ifdef Q_WS_MAEMO_6
+#if defined(Q_WS_MAEMO_6) || defined(Q_WS_MAEMO_5)
     iapconf = new Maemo::IAPConf("007");
     iapconf->setValue("ipv4_type", "AUTO");
     iapconf->setValue("wlan_wepkey1", "connt");
@@ -150,7 +151,7 @@ void tst_QNetworkConfiguration::initTestCase()
 
 void tst_QNetworkConfiguration::cleanupTestCase()
 {
-#ifdef Q_WS_MAEMO_6
+#if defined(Q_WS_MAEMO_6) || defined(Q_WS_MAEMO_5)
     iapconf->clear();
     delete iapconf;
     iapconf2->clear();
diff --git a/tests/auto/qnetworkconfigurationmanager/qnetworkconfigurationmanager.pro b/tests/auto/qnetworkconfigurationmanager/qnetworkconfigurationmanager.pro
index e0028e5..d9c1d6b 100644
--- a/tests/auto/qnetworkconfigurationmanager/qnetworkconfigurationmanager.pro
+++ b/tests/auto/qnetworkconfigurationmanager/qnetworkconfigurationmanager.pro
@@ -8,7 +8,7 @@ symbian {
     TARGET.CAPABILITY = NetworkServices NetworkControl ReadUserData
 }
 
-maemo6 {
+maemo6|maemo5 {
     CONFIG += link_pkgconfig
 
     PKGCONFIG += conninet
diff --git a/tests/auto/qnetworkconfigurationmanager/tst_qnetworkconfigurationmanager.cpp b/tests/auto/qnetworkconfigurationmanager/tst_qnetworkconfigurationmanager.cpp
index 30c5a74..7cc527c 100644
--- a/tests/auto/qnetworkconfigurationmanager/tst_qnetworkconfigurationmanager.cpp
+++ b/tests/auto/qnetworkconfigurationmanager/tst_qnetworkconfigurationmanager.cpp
@@ -41,10 +41,11 @@
 
 #include <QtTest/QtTest>
 #include "../qbearertestcommon.h"
-#include "qnetworkconfiguration.h"
-#include "qnetworkconfigmanager.h"
 
-#ifdef Q_WS_MAEMO_6
+#include <QtNetwork/qnetworkconfiguration.h>
+#include <QtNetwork/qnetworkconfigmanager.h>
+
+#if defined(Q_WS_MAEMO_6) || defined(Q_WS_MAEMO_5)
 #include <stdio.h>
 #include <iapconf.h>
 #endif
@@ -66,7 +67,7 @@ private slots:
     void configurationFromIdentifier();
 
 private:
-#ifdef Q_WS_MAEMO_6
+#if defined(Q_WS_MAEMO_6) || defined(Q_WS_MAEMO_5)
     Maemo::IAPConf *iapconf;
     Maemo::IAPConf *iapconf2;
     Maemo::IAPConf *gprsiap;
@@ -78,7 +79,7 @@ private:
 
 void tst_QNetworkConfigurationManager::initTestCase()
 {
-#ifdef Q_WS_MAEMO_6
+#if defined(Q_WS_MAEMO_6) || defined(Q_WS_MAEMO_5)
     iapconf = new Maemo::IAPConf("007");
     iapconf->setValue("ipv4_type", "AUTO");
     iapconf->setValue("wlan_wepkey1", "connt");
@@ -152,7 +153,7 @@ void tst_QNetworkConfigurationManager::initTestCase()
 
 void tst_QNetworkConfigurationManager::cleanupTestCase()
 {
-#ifdef Q_WS_MAEMO_6
+#if defined(Q_WS_MAEMO_6) || defined(Q_WS_MAEMO_5)
     iapconf->clear();
     delete iapconf;
     iapconf2->clear();
diff --git a/tests/auto/qnetworksession/lackey/main.cpp b/tests/auto/qnetworksession/lackey/main.cpp
index 66d6dd4..8759b52 100644
--- a/tests/auto/qnetworksession/lackey/main.cpp
+++ b/tests/auto/qnetworksession/lackey/main.cpp
@@ -42,9 +42,10 @@
 #include <QCoreApplication>
 #include <QStringList>
 #include <QLocalSocket>
-#include <qnetworkconfigmanager.h>
-#include <qnetworkconfiguration.h>
-#include <qnetworksession.h>
+
+#include <QtNetwork/qnetworkconfiguration.h>
+#include <QtNetwork/qnetworkconfigmanager.h>
+#include <QtNetwork/qnetworksession.h>
 
 #include <QDebug>
 
diff --git a/tests/auto/qnetworksession/test/test.pro b/tests/auto/qnetworksession/test/test.pro
index d248b10..bfffe90 100644
--- a/tests/auto/qnetworksession/test/test.pro
+++ b/tests/auto/qnetworksession/test/test.pro
@@ -19,7 +19,7 @@ symbian {
     TARGET.CAPABILITY = NetworkServices NetworkControl ReadUserData PowerMgmt
 }
 
-maemo6 {
+maemo6|maemo5 {
     CONFIG += link_pkgconfig
 
     PKGCONFIG += conninet
diff --git a/tests/auto/qnetworksession/test/tst_qnetworksession.cpp b/tests/auto/qnetworksession/test/tst_qnetworksession.cpp
index 58b0576..23cdc6a 100644
--- a/tests/auto/qnetworksession/test/tst_qnetworksession.cpp
+++ b/tests/auto/qnetworksession/test/tst_qnetworksession.cpp
@@ -44,10 +44,11 @@
 #include <QLocalSocket>
 #include <QTimer>
 #include "../../qbearertestcommon.h"
-#include <qnetworkconfigmanager.h>
-#include <qnetworksession.h>
 
-#ifdef Q_WS_MAEMO_6
+#include <QtNetwork/qnetworkconfigmanager.h>
+#include <QtNetwork/qnetworksession.h>
+
+#if defined(Q_WS_MAEMO_6) || defined(Q_WS_MAEMO_5)
 #include <stdio.h>
 #include <iapconf.h>
 #endif
@@ -72,6 +73,8 @@ public slots:
 
 private slots:
 
+    void robustnessBombing();
+
     void outOfProcessSession();
     void invalidSession();
 
@@ -100,7 +103,7 @@ private:
 
     int inProcessSessionManagementCount;
 
-#ifdef Q_WS_MAEMO_6
+#if defined(Q_WS_MAEMO_6) || defined(Q_WS_MAEMO_5)
     Maemo::IAPConf *iapconf;
     Maemo::IAPConf *iapconf2;
     Maemo::IAPConf *gprsiap;
@@ -123,7 +126,7 @@ void tst_QNetworkSession::initTestCase()
     qRegisterMetaType<QNetworkConfiguration>("QNetworkConfiguration");
     qRegisterMetaType<QNetworkConfiguration::Type>("QNetworkConfiguration::Type");
 
-#ifdef Q_WS_MAEMO_6
+#if defined(Q_WS_MAEMO_6) || defined(Q_WS_MAEMO_5)
     iapconf = new Maemo::IAPConf("007");
     iapconf->setValue("ipv4_type", "AUTO");
     iapconf->setValue("wlan_wepkey1", "connt");
@@ -209,7 +212,7 @@ void tst_QNetworkSession::cleanupTestCase()
                  "inProcessSessionManagement()");
     }
 
-#ifdef Q_WS_MAEMO_6
+#if defined(Q_WS_MAEMO_6) || defined(Q_WS_MAEMO_5)
     iapconf->clear();
     delete iapconf;
     iapconf2->clear();
@@ -232,6 +235,23 @@ void tst_QNetworkSession::cleanupTestCase()
 #endif
 }
 
+// Robustness test for calling interfaces in nonsense order / with nonsense parameters
+void tst_QNetworkSession::robustnessBombing() 
+{
+    QNetworkConfigurationManager mgr;
+    QNetworkSession testSession(mgr.defaultConfiguration());
+    // Should not reset even session is not opened
+    testSession.migrate();
+    testSession.accept();
+    testSession.ignore();
+    testSession.reject();
+    quint64 temp;
+    temp = testSession.bytesWritten();
+    temp = testSession.bytesReceived();
+    temp = testSession.activeTime();
+}
+
+
 void tst_QNetworkSession::invalidSession()
 {
     // 1. Verify that session created with invalid configuration remains in invalid state
diff --git a/tests/auto/qthread/tst_qthread.cpp b/tests/auto/qthread/tst_qthread.cpp
index 871578e..9a4397e 100644
--- a/tests/auto/qthread/tst_qthread.cpp
+++ b/tests/auto/qthread/tst_qthread.cpp
@@ -174,8 +174,8 @@ public:
 
     void run()
     {
+        Simple_Thread::run();
         if (object) {
-            Simple_Thread::run();
             object->thread = this;
             object->code = code;
             QTimer::singleShot(100, object, SLOT(slot()));
@@ -218,8 +218,8 @@ public:
 
     void run()
     {
+        Simple_Thread::run();
         if (object) {
-            Simple_Thread::run();
             object->thread = this;
             QTimer::singleShot(100, object, SLOT(slot()));
         }
@@ -443,22 +443,24 @@ void tst_QThread::exit()
     thread2.code = 53;
     thread2.result = 0;
     thread2.start();
-    thread2.exit(thread.code);
+    thread2.exit(thread2.code);
+    QMutexLocker locker2(&thread2.mutex);
+    thread2.cond.wait(locker2.mutex());
     QVERIFY(thread2.wait(five_minutes));
-    QCOMPARE(thread.result, thread.code);
+    QCOMPARE(thread2.result, thread2.code);
 }
 
 void tst_QThread::start()
 {
     QThread::Priority priorities[] = {
-	QThread::IdlePriority,
-	QThread::LowestPriority,
-	QThread::LowPriority,
-	QThread::NormalPriority,
-	QThread::HighPriority,
-	QThread::HighestPriority,
-	QThread::TimeCriticalPriority,
-	QThread::InheritPriority
+        QThread::IdlePriority,
+        QThread::LowestPriority,
+        QThread::LowPriority,
+        QThread::NormalPriority,
+        QThread::HighPriority,
+        QThread::HighestPriority,
+        QThread::TimeCriticalPriority,
+        QThread::InheritPriority
     };
     const int prio_count = sizeof(priorities) / sizeof(QThread::Priority);
 
@@ -514,8 +516,10 @@ void tst_QThread::quit()
     thread2.result = -1;
     thread2.start();
     thread2.quit();
+    QMutexLocker locker2(&thread2.mutex);
+    thread2.cond.wait(locker2.mutex());
     QVERIFY(thread2.wait(five_minutes));
-    QCOMPARE(thread.result, 0);
+    QCOMPARE(thread2.result, 0);
 }
 
 void tst_QThread::wait()
@@ -692,7 +696,7 @@ void NativeThreadWrapper::start(FunctionPointer functionPointer, void *data)
     const int state = pthread_create(&nativeThreadHandle, 0, NativeThreadWrapper::runUnix, this);
     Q_UNUSED(state);
 #elif defined(Q_OS_WINCE)
-	nativeThreadHandle = CreateThread(NULL, 0 , (LPTHREAD_START_ROUTINE)NativeThreadWrapper::runWin , this, 0, NULL);
+        nativeThreadHandle = CreateThread(NULL, 0 , (LPTHREAD_START_ROUTINE)NativeThreadWrapper::runWin , this, 0, NULL);
 #elif defined Q_OS_WIN
     unsigned thrdid = 0;
     nativeThreadHandle = (Qt::HANDLE) _beginthreadex(NULL, 0, NativeThreadWrapper::runWin, this, 0, &thrdid);
diff --git a/tests/auto/qwidget/tst_qwidget.cpp b/tests/auto/qwidget/tst_qwidget.cpp
index 1b2944e..76e20b9 100644
--- a/tests/auto/qwidget/tst_qwidget.cpp
+++ b/tests/auto/qwidget/tst_qwidget.cpp
@@ -6056,9 +6056,6 @@ void tst_QWidget::setToolTip()
 #ifdef Q_OS_WINCE_WM
     QSKIP("Mouse over doesn't work on Windows mobile.", SkipAll);
 #endif
-#ifdef QT_MAC_USE_COCOA
-    QSKIP("Temporarily disable the rest on cocoa due to QCursor::setPos problems.", SkipAll);
-#endif
 
     for (int pass = 0; pass < 2; ++pass) {
         QWidget *popup = new QWidget(0, Qt::Popup);
diff --git a/tests/auto/qwindowsurface/tst_qwindowsurface.cpp b/tests/auto/qwindowsurface/tst_qwindowsurface.cpp
index dd985ca..7dde402 100644
--- a/tests/auto/qwindowsurface/tst_qwindowsurface.cpp
+++ b/tests/auto/qwindowsurface/tst_qwindowsurface.cpp
@@ -66,6 +66,7 @@ private slots:
     void getSetWindowSurface();
     void flushOutsidePaintEvent();
     void grabWidget();
+    void staticContentsAndPartialUpdateSupport();
 };
 
 class MyWindowSurface : public QWindowSurface
@@ -81,6 +82,8 @@ public:
         /* nothing */
     }
 
+    using QWindowSurface::setStaticContentsSupport;
+    using QWindowSurface::setPartialUpdateSupport;
 private:
     QImage image;
 };
@@ -280,6 +283,51 @@ void tst_QWindowSurface::grabWidget()
     QVERIFY(QColor(childInvalidSubImage.pixel(0, 0)) == QColor(Qt::white));
 }
 
+void tst_QWindowSurface::staticContentsAndPartialUpdateSupport()
+{
+    QWidget widget;
+    MyWindowSurface surface(&widget);
+
+    // Default values.
+    QVERIFY(surface.hasPartialUpdateSupport());
+    QVERIFY(!surface.hasStaticContentsSupport());
+
+    // Partial: YES, Static: YES
+    surface.setStaticContentsSupport(true);
+    QVERIFY(surface.hasPartialUpdateSupport());
+    QVERIFY(surface.hasStaticContentsSupport());
+
+    // Static contents requires support for partial updates.
+    // We simply ingore bad combinations and spit out a warning.
+
+    // CONFLICT: Partial: NO, Static: YES
+    QTest::ignoreMessage(QtWarningMsg, "QWindowSurface::setPartialUpdateSupport: static contents support requires partial update support");
+    surface.setPartialUpdateSupport(false);
+    QVERIFY(surface.hasPartialUpdateSupport());
+    QVERIFY(surface.hasStaticContentsSupport());
+
+    // Partial: YES, Static: NO
+    surface.setStaticContentsSupport(false);
+    QVERIFY(surface.hasPartialUpdateSupport());
+    QVERIFY(!surface.hasStaticContentsSupport());
+
+    // Partial: NO, Static: NO
+    surface.setPartialUpdateSupport(false);
+    QVERIFY(!surface.hasPartialUpdateSupport());
+    QVERIFY(!surface.hasStaticContentsSupport());
+
+    // CONFLICT: Partial: NO, Static: YES
+    QTest::ignoreMessage(QtWarningMsg, "QWindowSurface::setStaticContentsSupport: static contents support requires partial update support");
+    surface.setStaticContentsSupport(true);
+    QVERIFY(!surface.hasPartialUpdateSupport());
+    QVERIFY(!surface.hasStaticContentsSupport());
+
+    // Partial: YES, Static: NO
+    surface.setPartialUpdateSupport(true);
+    QVERIFY(surface.hasPartialUpdateSupport());
+    QVERIFY(!surface.hasStaticContentsSupport());
+}
+
 QTEST_MAIN(tst_QWindowSurface)
 
 #else // Q_WS_MAC
diff --git a/tests/manual/bearerex/bearerex.h b/tests/manual/bearerex/bearerex.h
index 2875d6a..6bcb3e5 100644
--- a/tests/manual/bearerex/bearerex.h
+++ b/tests/manual/bearerex/bearerex.h
@@ -1,6 +1,6 @@
 /****************************************************************************
 **
-** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
+** Copyright (C) 2010 Nokia Corporation and/or its subsidiary(-ies).
 ** All rights reserved.
 ** Contact: Nokia Corporation (qt-info@nokia.com)
 **
@@ -44,10 +44,15 @@
 
 #include <QtGui>
 
-#include "ui_bearerex.h"
 #include "ui_detailedinfodialog.h"
-#include "ui_sessiondialog.h"
 
+#if defined(Q_WS_MAEMO_5) || defined(Q_WS_MAEMO_6)
+#include "ui_bearerex_maemo.h"
+#include "ui_sessiondialog_maemo.h"
+#else
+#include "ui_bearerex.h"
+#include "ui_sessiondialog.h"
+#endif
 #include "qnetworkconfigmanager.h"
 #include "qnetworksession.h"
 #include "xqlistwidget.h"
diff --git a/tests/manual/bearerex/bearerex.pro b/tests/manual/bearerex/bearerex.pro
index 927f982..7b21183 100644
--- a/tests/manual/bearerex/bearerex.pro
+++ b/tests/manual/bearerex/bearerex.pro
@@ -5,9 +5,15 @@ QT += core \
       gui \
       network
 
-FORMS += sessiondialog.ui \
-         bearerex.ui \
-         detailedinfodialog.ui
+FORMS += detailedinfodialog.ui
+maemo5|maemo6 {
+    FORMS += sessiondialog_maemo.ui \
+        bearerex_maemo.ui
+} else {
+    FORMS += sessiondialog.ui \
+        bearerex.ui
+}
+
 
 # Example headers and sources
 HEADERS += bearerex.h \
@@ -17,4 +23,4 @@ SOURCES += bearerex.cpp \
            main.cpp \
            xqlistwidget.cpp
 
-symbian:TARGET.CAPABILITY = NetworkServices NetworkControl ReadUserData
\ No newline at end of file
+symbian:TARGET.CAPABILITY = NetworkServices NetworkControl ReadUserData
diff --git a/tests/manual/bearerex/bearerex_maemo.ui b/tests/manual/bearerex/bearerex_maemo.ui
new file mode 100644
index 0000000..cb17e38
--- /dev/null
+++ b/tests/manual/bearerex/bearerex_maemo.ui
@@ -0,0 +1,100 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<ui version="4.0">
+ <class>BearerExMainWindow</class>
+ <widget class="QMainWindow" name="BearerExMainWindow">
+  <property name="geometry">
+   <rect>
+    <x>0</x>
+    <y>0</y>
+    <width>360</width>
+    <height>640</height>
+   </rect>
+  </property>
+  <property name="windowTitle">
+   <string>Bearer Example</string>
+  </property>
+  <widget class="QWidget" name="centralwidget">
+   <layout class="QVBoxLayout" name="verticalLayout">
+    <item>
+     <widget class="QTabWidget" name="mainTabWidget">
+      <widget class="QWidget" name="tab">
+       <attribute name="title">
+        <string>Main</string>
+       </attribute>
+       <layout class="QHBoxLayout" name="horizontalLayout">
+        <item>
+         <layout class="QVBoxLayout" name="verticalLayout_2">
+          <item>
+           <widget class="QLabel" name="label">
+            <property name="text">
+             <string>Network Configurations</string>
+            </property>
+            <property name="alignment">
+             <set>Qt::AlignCenter</set>
+            </property>
+           </widget>
+          </item>
+          <item>
+           <widget class="QListWidget" name="listWidget"/>
+          </item>
+         </layout>
+        </item>
+        <item>
+         <layout class="QGridLayout" name="gridLayout">
+          <item row="0" column="0">
+           <widget class="QPushButton" name="updateConfigurationsButton">
+            <property name="text">
+             <string>Update Configs</string>
+            </property>
+           </widget>
+          </item>
+          <item row="1" column="0">
+           <widget class="QPushButton" name="updateListButton">
+            <property name="text">
+             <string>Update List</string>
+            </property>
+           </widget>
+          </item>
+          <item row="2" column="0">
+           <widget class="QPushButton" name="createSessionButton">
+            <property name="text">
+             <string>Create Session</string>
+            </property>
+           </widget>
+          </item>
+          <item row="3" column="0">
+           <widget class="QPushButton" name="showDetailsButton">
+            <property name="text">
+             <string>Show Details</string>
+            </property>
+           </widget>
+          </item>
+         </layout>
+        </item>
+       </layout>
+      </widget>
+      <widget class="QWidget" name="tab_2">
+       <attribute name="title">
+        <string>Events</string>
+       </attribute>
+       <layout class="QVBoxLayout" name="verticalLayout_3">
+        <item>
+         <widget class="QListWidget" name="eventListWidget"/>
+        </item>
+        <item>
+         <widget class="QPushButton" name="clearEventListButton">
+          <property name="text">
+           <string>Clear</string>
+          </property>
+         </widget>
+        </item>
+       </layout>
+      </widget>
+     </widget>
+    </item>
+   </layout>
+  </widget>
+ </widget>
+ <resources/>
+ <connections/>
+</ui>
diff --git a/tests/manual/bearerex/sessiondialog_maemo.ui b/tests/manual/bearerex/sessiondialog_maemo.ui
new file mode 100644
index 0000000..5eb98ce
--- /dev/null
+++ b/tests/manual/bearerex/sessiondialog_maemo.ui
@@ -0,0 +1,151 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<ui version="4.0">
+ <class>SessionTab</class>
+ <widget class="QWidget" name="SessionTab">
+  <property name="geometry">
+   <rect>
+    <x>0</x>
+    <y>0</y>
+    <width>423</width>
+    <height>214</height>
+   </rect>
+  </property>
+  <layout class="QHBoxLayout" name="horizontalLayout">
+   <item>
+    <layout class="QFormLayout" name="formLayout">
+     <property name="fieldGrowthPolicy">
+      <enum>QFormLayout::ExpandingFieldsGrow</enum>
+     </property>
+     <item row="0" column="0">
+      <widget class="QLabel" name="snapLabel">
+       <property name="text">
+        <string>SNAP</string>
+       </property>
+      </widget>
+     </item>
+     <item row="0" column="1">
+      <widget class="QLineEdit" name="snapLineEdit">
+       <property name="readOnly">
+        <bool>true</bool>
+       </property>
+      </widget>
+     </item>
+     <item row="1" column="0">
+      <widget class="QLabel" name="iapLabel">
+       <property name="text">
+        <string>IAP</string>
+       </property>
+      </widget>
+     </item>
+     <item row="1" column="1">
+      <widget class="QLineEdit" name="iapLineEdit">
+       <property name="enabled">
+        <bool>true</bool>
+       </property>
+       <property name="readOnly">
+        <bool>true</bool>
+       </property>
+      </widget>
+     </item>
+     <item row="2" column="0">
+      <widget class="QLabel" name="bearerLabel">
+       <property name="text">
+        <string>Bearer</string>
+       </property>
+      </widget>
+     </item>
+     <item row="2" column="1">
+      <widget class="QLineEdit" name="bearerLineEdit">
+       <property name="readOnly">
+        <bool>true</bool>
+       </property>
+      </widget>
+     </item>
+     <item row="3" column="0">
+      <widget class="QLabel" name="sentRecDataLabel">
+       <property name="text">
+        <string>Sent/Rec.</string>
+       </property>
+      </widget>
+     </item>
+     <item row="3" column="1">
+      <widget class="QLineEdit" name="sentRecDataLineEdit">
+       <property name="readOnly">
+        <bool>true</bool>
+       </property>
+      </widget>
+     </item>
+     <item row="4" column="0">
+      <widget class="QLabel" name="stateLabel">
+       <property name="text">
+        <string>State</string>
+       </property>
+      </widget>
+     </item>
+     <item row="4" column="1">
+      <widget class="QLineEdit" name="stateLineEdit">
+       <property name="readOnly">
+        <bool>true</bool>
+       </property>
+      </widget>
+     </item>
+    </layout>
+   </item>
+   <item>
+    <layout class="QGridLayout" name="gridLayout">
+     <item row="0" column="0">
+      <widget class="QPushButton" name="openSessionButton">
+       <property name="text">
+        <string>Open Session</string>
+       </property>
+      </widget>
+     </item>
+     <item row="0" column="1">
+      <widget class="QPushButton" name="closeSessionButton">
+       <property name="text">
+        <string>Close Session</string>
+       </property>
+      </widget>
+     </item>
+     <item row="1" column="0">
+      <widget class="QPushButton" name="stopConnectionButton">
+       <property name="text">
+        <string>Stop Conn.</string>
+       </property>
+      </widget>
+     </item>
+     <item row="1" column="1">
+      <widget class="QPushButton" name="sendRequestButton">
+       <property name="text">
+        <string>Send Test Req.</string>
+       </property>
+      </widget>
+     </item>
+     <item row="2" column="0">
+      <widget class="QPushButton" name="createQHttpButton">
+       <property name="text">
+        <string>Create QHttp</string>
+       </property>
+      </widget>
+     </item>
+     <item row="2" column="1">
+      <widget class="QPushButton" name="deleteSessionButton">
+       <property name="text">
+        <string>Delete Session</string>
+       </property>
+      </widget>
+     </item>
+     <item row="3" column="0">
+      <widget class="QPushButton" name="alrButton">
+       <property name="text">
+        <string>Enable ALR</string>
+       </property>
+      </widget>
+     </item>
+    </layout>
+   </item>
+  </layout>
+ </widget>
+ <resources/>
+ <connections/>
+</ui>
diff --git a/tests/manual/network_remote_stresstest/network_remote_stresstest.pro b/tests/manual/network_remote_stresstest/network_remote_stresstest.pro
new file mode 100644
index 0000000..9ed1090
--- /dev/null
+++ b/tests/manual/network_remote_stresstest/network_remote_stresstest.pro
@@ -0,0 +1,8 @@
+load(qttest_p4)
+
+QT = core network
+
+SOURCES  += tst_network_remote_stresstest.cpp
+
+RESOURCES += url-list.qrc
+
diff --git a/tests/manual/network_remote_stresstest/tst_network_remote_stresstest.cpp b/tests/manual/network_remote_stresstest/tst_network_remote_stresstest.cpp
new file mode 100644
index 0000000..90a95e7
--- /dev/null
+++ b/tests/manual/network_remote_stresstest/tst_network_remote_stresstest.cpp
@@ -0,0 +1,499 @@
+/****************************************************************************
+**
+** Copyright (C) 2010 Nokia Corporation and/or its subsidiary(-ies).
+** All rights reserved.
+** Contact: Nokia Corporation (qt-info@nokia.com)
+**
+** This file is part of the test suite of the Qt Toolkit.
+**
+** $QT_BEGIN_LICENSE:LGPL$
+** No Commercial Usage
+** This file contains pre-release code and may not be distributed.
+** You may use this file in accordance with the terms and conditions
+** contained in the Technology Preview License Agreement accompanying
+** this package.
+**
+** GNU Lesser General Public License Usage
+** Alternatively, this file may be used under the terms of the GNU Lesser
+** General Public License version 2.1 as published by the Free Software
+** Foundation and appearing in the file LICENSE.LGPL included in the
+** packaging of this file.  Please review the following information to
+** ensure the GNU Lesser General Public License version 2.1 requirements
+** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
+**
+** In addition, as a special exception, Nokia gives you certain additional
+** rights.  These rights are described in the Nokia Qt LGPL Exception
+** version 1.1, included in the file LGPL_EXCEPTION.txt in this package.
+**
+** If you have questions regarding the use of this file, please contact
+** Nokia at qt-info@nokia.com.
+**
+**
+**
+**
+**
+**
+**
+**
+** $QT_END_LICENSE$
+**
+****************************************************************************/
+
+#include <QtTest/QtTest>
+#include <QtCore/QThread>
+#include <QtCore/QSemaphore>
+#include <QtCore/QElapsedTimer>
+#include <QtCore/QSharedPointer>
+#include <QtCore/QVector>
+#include <QtNetwork/QTcpSocket>
+#include <QtNetwork/QSslSocket>
+#include <QtNetwork/QNetworkReply>
+#include <QtNetwork/QNetworkAccessManager>
+
+#ifdef QT_BUILD_INTERNAL
+# include <private/qnetworkaccessmanager_p.h>
+#endif
+
+#include <qplatformdefs.h>
+#ifdef Q_OS_UNIX
+# include <sys/types.h>
+# include <sys/socket.h>
+# include <sys/select.h>
+# include <netinet/in.h>
+# include <errno.h>
+# include <netdb.h>
+# include <signal.h>
+# include <unistd.h>
+# include <fcntl.h>
+
+typedef int SOCKET;
+# define INVALID_SOCKET -1
+# define SOCKET_ERROR -1
+
+#elif defined(Q_OS_WIN)
+# include <winsock2.h>
+#endif
+
+Q_DECLARE_METATYPE(QVector<QUrl>)
+
+class tst_NetworkRemoteStressTest : public QObject
+{
+    Q_OBJECT
+public:
+    enum { AttemptCount = 100 };
+    tst_NetworkRemoteStressTest();
+
+    qint64 byteCounter;
+    QNetworkAccessManager manager;
+    QVector<QUrl> httpUrls, httpsUrls, mixedUrls;
+    bool intermediateDebug;
+
+private:
+    void clearManager();
+
+public slots:
+    void initTestCase_data();
+    void init();
+
+    void slotReadAll() { byteCounter += static_cast<QIODevice *>(sender())->readAll().size(); }
+
+private Q_SLOTS:
+    void blockingSequentialRemoteHosts();
+    void sequentialRemoteHosts();
+    void parallelRemoteHosts_data();
+    void parallelRemoteHosts();
+    void namRemoteGet_data();
+    void namRemoteGet();
+};
+
+tst_NetworkRemoteStressTest::tst_NetworkRemoteStressTest()
+    : intermediateDebug(qgetenv("STRESSDEBUG").toInt() > 0)
+{
+#ifdef Q_OS_WIN
+    WSAData wsadata;
+
+    // IPv6 requires Winsock v2.0 or better.
+    WSAStartup(MAKEWORD(2,0), &wsadata);
+#elif defined(Q_OS_UNIX) && !defined(Q_OS_SYMBIAN)
+    ::signal(SIGALRM, SIG_IGN);
+#endif
+
+    QFile urlList(":/url-list.txt");
+    if (urlList.open(QIODevice::ReadOnly)) {
+        while (!urlList.atEnd()) {
+            QByteArray line = urlList.readLine().trimmed();
+            QUrl url = QUrl::fromEncoded(line);
+            if (url.scheme() == "http") {
+                httpUrls << url;
+                mixedUrls << url;
+            } else if (url.scheme() == "https") {
+                httpsUrls << url;
+                mixedUrls << url;
+            }
+        }
+    }
+
+    httpUrls << httpUrls;
+    httpsUrls << httpsUrls;
+}
+
+void tst_NetworkRemoteStressTest::initTestCase_data()
+{
+    QTest::addColumn<QVector<QUrl> >("urlList");
+    QTest::addColumn<bool>("useSslSocket");
+
+    QTest::newRow("no-ssl") << httpUrls << false;
+//    QTest::newRow("no-ssl-in-sslsocket") << httpUrls << true;
+    QTest::newRow("ssl") << httpsUrls << true;
+    QTest::newRow("mixed") << mixedUrls << false;
+//    QTest::newRow("mixed-in-sslsocket") << mixedUrls << true;
+}
+
+void tst_NetworkRemoteStressTest::init()
+{
+    // clear the internal cache
+#ifndef QT_BUILD_INTERNAL
+    if (strncmp(QTest::currentTestFunction(), "nam") == 0)
+        QSKIP("QNetworkAccessManager tests disabled", SkipAll);
+#endif
+}
+
+void tst_NetworkRemoteStressTest::clearManager()
+{
+#ifdef QT_BUILD_INTERNAL
+    QNetworkAccessManagerPrivate::clearCache(&manager);
+    manager.setProxy(QNetworkProxy());
+    manager.setCache(0);
+#endif
+}
+
+bool nativeLookup(const char *hostname, int port, QByteArray &buf)
+{
+#if !defined(QT_NO_GETADDRINFO) && 0
+    addrinfo *res = 0;
+    struct addrinfo hints;
+    memset(&hints, 0, sizeof(hints));
+    hints.ai_family = PF_UNSPEC;
+
+    int result = getaddrinfo(QUrl::toAce(hostname).constData(), QByteArray::number(port).constData(), &hints, &res);
+    if (!result)
+        return false;
+    for (addrinfo *node = res; node; node = node->ai_next) {
+        if (node->ai_family == AF_INET) {
+            buf = QByteArray((char *)node->ai_addr, node->ai_addrlen);
+            break;
+        }
+    }
+    freeaddrinfo(res);
+#else
+    hostent *result = gethostbyname(hostname);
+    if (!result || result->h_addrtype != AF_INET)
+        return false;
+
+    struct sockaddr_in s;
+    s.sin_family = AF_INET;
+    s.sin_port = htons(port);
+    s.sin_addr =  *(struct in_addr *) result->h_addr_list[0];
+
+    buf = QByteArray((char *)&s, sizeof s);
+#endif
+
+    return !buf.isEmpty();
+}
+
+bool nativeSelect(int fd, int timeout, bool selectForWrite)
+{
+    if (timeout < 0)
+        return false;
+
+    // wait for connected
+    fd_set fds, fde;
+    FD_ZERO(&fds);
+    FD_ZERO(&fde);
+    FD_SET(fd, &fds);
+    FD_SET(fd, &fde);
+
+    int ret;
+    do {
+        struct timeval tv;
+        tv.tv_sec = timeout / 1000;
+        tv.tv_usec = timeout % 1000;
+        if (selectForWrite)
+            ret = ::select(fd + 1, 0, &fds, &fde, &tv);
+        else
+            ret = ::select(fd + 1, &fds, 0, &fde, &tv);
+    } while (ret == -1 && errno == EINTR);
+    return ret != 0;
+}
+
+void tst_NetworkRemoteStressTest::blockingSequentialRemoteHosts()
+{
+    QFETCH_GLOBAL(QVector<QUrl>, urlList);
+    QFETCH_GLOBAL(bool, useSslSocket);
+
+    qint64 totalBytes = 0;
+    QElapsedTimer outerTimer;
+    outerTimer.start();
+
+    for (int i = 0; i < urlList.size(); ++i) {
+        const QUrl &url = urlList.at(i);
+        bool isHttps = url.scheme() == "https";
+        QElapsedTimer timeout;
+        byteCounter = 0;
+        timeout.start();
+
+        QSharedPointer<QTcpSocket> socket;
+        if (useSslSocket || isHttps) {
+            socket = QSharedPointer<QTcpSocket>(new QSslSocket);
+        } else {
+            socket = QSharedPointer<QTcpSocket>(new QTcpSocket);
+        }
+
+        socket->connectToHost(url.host(), url.port(isHttps ? 443 : 80));
+        QVERIFY2(socket->waitForConnected(10000), "Timeout connecting to " + url.encodedHost());
+
+        if (isHttps) {
+            static_cast<QSslSocket *>(socket.data())->setProtocol(QSsl::TlsV1);
+            static_cast<QSslSocket *>(socket.data())->startClientEncryption();
+            static_cast<QSslSocket *>(socket.data())->ignoreSslErrors();
+            QVERIFY2(static_cast<QSslSocket *>(socket.data())->waitForEncrypted(10000), "Timeout starting TLS with " + url.encodedHost());
+        }
+
+        socket->write("GET " + url.toEncoded(QUrl::RemoveScheme | QUrl::RemoveAuthority | QUrl::RemoveFragment) + " HTTP/1.0\r\n"
+                      "Connection: close\r\n"
+                      "User-Agent: tst_QTcpSocket_stresstest/1.0\r\n"
+                      "Host: " + url.encodedHost() + "\r\n"
+                      "\r\n");
+        while (socket->bytesToWrite())
+            QVERIFY2(socket->waitForBytesWritten(10000), "Timeout writing to " + url.encodedHost());
+
+        while (socket->state() == QAbstractSocket::ConnectedState && !timeout.hasExpired(10000)) {
+            socket->waitForReadyRead(10000);
+            byteCounter += socket->readAll().size(); // discard
+        }
+        QVERIFY2(!timeout.hasExpired(10000), "Timeout reading from " + url.encodedHost());
+
+        totalBytes += byteCounter;
+        if (intermediateDebug) {
+            double rate = (byteCounter * 1.0 / timeout.elapsed());
+            qDebug() << i << url << byteCounter << "bytes in" << timeout.elapsed() << "ms:"
+                    << (rate / 1024.0 * 1000) << "kB/s";
+        }
+    }
+    qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 * 1000 / outerTimer.elapsed()) << "kB/s";
+}
+
+void tst_NetworkRemoteStressTest::sequentialRemoteHosts()
+{
+    QFETCH_GLOBAL(QVector<QUrl>, urlList);
+    QFETCH_GLOBAL(bool, useSslSocket);
+
+    qint64 totalBytes = 0;
+    QElapsedTimer outerTimer;
+    outerTimer.start();
+
+    for (int i = 0; i < urlList.size(); ++i) {
+        const QUrl &url = urlList.at(i);
+        bool isHttps = url.scheme() == "https";
+        QElapsedTimer timeout;
+        byteCounter = 0;
+        timeout.start();
+
+        QSharedPointer<QTcpSocket> socket;
+        if (useSslSocket || isHttps) {
+            socket = QSharedPointer<QTcpSocket>(new QSslSocket);
+        } else {
+            socket = QSharedPointer<QTcpSocket>(new QTcpSocket);
+        }
+        if (isHttps) {
+            static_cast<QSslSocket *>(socket.data())->setProtocol(QSsl::TlsV1);
+            static_cast<QSslSocket *>(socket.data())->connectToHostEncrypted(url.host(), url.port(443));
+            static_cast<QSslSocket *>(socket.data())->ignoreSslErrors();
+        } else {
+            socket->connectToHost(url.host(), url.port(80));
+        }
+
+        socket->write("GET " + url.toEncoded(QUrl::RemoveScheme | QUrl::RemoveAuthority | QUrl::RemoveFragment) + " HTTP/1.0\r\n"
+                      "Connection: close\r\n"
+                      "User-Agent: tst_QTcpSocket_stresstest/1.0\r\n"
+                      "Host: " + url.encodedHost() + "\r\n"
+                      "\r\n");
+        connect(socket.data(), SIGNAL(readyRead()), SLOT(slotReadAll()));
+
+        QTestEventLoop::instance().connect(socket.data(), SIGNAL(disconnected()), SLOT(exitLoop()));
+        QTestEventLoop::instance().enterLoop(30);
+        QVERIFY2(!QTestEventLoop::instance().timeout(), "Timeout with " + url.encodedHost() + "; "
+                 + QByteArray::number(socket->bytesToWrite()) + " bytes to write");
+
+        totalBytes += byteCounter;
+        if (intermediateDebug) {
+            double rate = (byteCounter * 1.0 / timeout.elapsed());
+            qDebug() << i << url << byteCounter << "bytes in" << timeout.elapsed() << "ms:"
+                    << (rate / 1024.0 * 1000) << "kB/s";
+        }
+    }
+    qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 * 1000 / outerTimer.elapsed()) << "kB/s";
+}
+
+void tst_NetworkRemoteStressTest::parallelRemoteHosts_data()
+{
+    QTest::addColumn<int>("parallelAttempts");
+    QTest::newRow("1") << 1;
+    QTest::newRow("2") << 2;
+    QTest::newRow("4") << 4;
+    QTest::newRow("5") << 5;
+    QTest::newRow("6") << 6;
+    QTest::newRow("8") << 8;
+    QTest::newRow("10") << 10;
+    QTest::newRow("25") << 25;
+    QTest::newRow("500") << 500;
+}
+
+void tst_NetworkRemoteStressTest::parallelRemoteHosts()
+{
+    QFETCH_GLOBAL(QVector<QUrl>, urlList);
+    QFETCH_GLOBAL(bool, useSslSocket);
+
+    QFETCH(int, parallelAttempts);
+
+    qint64 totalBytes = 0;
+    QElapsedTimer outerTimer;
+    outerTimer.start();
+
+    QVector<QUrl>::ConstIterator it = urlList.constBegin();
+    while (it != urlList.constEnd()) {
+        QElapsedTimer timeout;
+        byteCounter = 0;
+        timeout.start();
+
+        QVector<QSharedPointer<QTcpSocket> > sockets;
+        sockets.reserve(parallelAttempts);
+        for (int j = 0; j < parallelAttempts && it != urlList.constEnd(); ++j, ++it) {
+            const QUrl &url = *it;
+            bool isHttps = url.scheme() == "https";
+            QTcpSocket *socket;
+            if (useSslSocket || isHttps)
+                socket = new QSslSocket;
+            else
+                socket = new QTcpSocket;
+            if (isHttps) {
+                static_cast<QSslSocket *>(socket)->setProtocol(QSsl::TlsV1);
+                static_cast<QSslSocket *>(socket)->connectToHostEncrypted(url.host(), url.port(443));
+                static_cast<QSslSocket *>(socket)->ignoreSslErrors();
+            } else {
+                socket->connectToHost(url.host(), url.port(isHttps ? 443 : 80));
+            }
+
+            socket->write("GET " + url.toEncoded(QUrl::RemoveScheme | QUrl::RemoveAuthority | QUrl::RemoveFragment) + " HTTP/1.0\r\n"
+                          "Connection: close\r\n"
+                          "User-Agent: tst_QTcpSocket_stresstest/1.0\r\n"
+                          "Host: " + url.encodedHost() + "\r\n"
+                          "\r\n");
+            connect(socket, SIGNAL(readyRead()), SLOT(slotReadAll()));
+            QTestEventLoop::instance().connect(socket, SIGNAL(disconnected()), SLOT(exitLoop()));
+            socket->setProperty("remoteUrl", url);
+
+            sockets.append(QSharedPointer<QTcpSocket>(socket));
+        }
+
+        while (!timeout.hasExpired(10000)) {
+            QTestEventLoop::instance().enterLoop(10);
+            int done = 0;
+            for (int j = 0; j < sockets.size(); ++j)
+                done += sockets[j]->state() == QAbstractSocket::UnconnectedState ? 1 : 0;
+            if (done == sockets.size())
+                break;
+        }
+        for (int j = 0; j < sockets.size(); ++j)
+            if (sockets[j]->state() != QAbstractSocket::UnconnectedState) {
+                qDebug() << "Socket to" << sockets[j]->property("remoteUrl").toUrl() << "still open with"
+                        << sockets[j]->bytesToWrite() << "bytes to write";
+                QFAIL("Timed out");
+            }
+
+        totalBytes += byteCounter;
+        if (intermediateDebug) {
+            double rate = (byteCounter * 1.0 / timeout.elapsed());
+            qDebug() << byteCounter << "bytes in" << timeout.elapsed() << "ms:"
+                    << (rate / 1024.0 * 1000) << "kB/s";
+        }
+    }
+    qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 * 1000 / outerTimer.elapsed()) << "kB/s";
+}
+
+void tst_NetworkRemoteStressTest::namRemoteGet_data()
+{
+    QTest::addColumn<int>("parallelAttempts");
+    QTest::newRow("1") << 1;
+    QTest::newRow("2") << 2;
+    QTest::newRow("4") << 4;
+    QTest::newRow("5") << 5;
+    QTest::newRow("6") << 6;
+    QTest::newRow("8") << 8;
+    QTest::newRow("10") << 10;
+    QTest::newRow("25") << 25;
+    QTest::newRow("500") << 500;
+}
+
+void tst_NetworkRemoteStressTest::namRemoteGet()
+{
+    QFETCH_GLOBAL(QVector<QUrl>, urlList);
+
+    QFETCH(int, parallelAttempts);
+    bool pipelineAllowed = false;// QFETCH(bool, pipelineAllowed);
+
+    qint64 totalBytes = 0;
+    QElapsedTimer outerTimer;
+    outerTimer.start();
+
+    QVector<QUrl>::ConstIterator it = urlList.constBegin();
+    while (it != urlList.constEnd()) {
+        QElapsedTimer timeout;
+        byteCounter = 0;
+        timeout.start();
+
+        QNetworkRequest req;
+        req.setAttribute(QNetworkRequest::HttpPipeliningAllowedAttribute, pipelineAllowed);
+
+        QVector<QSharedPointer<QNetworkReply> > replies;
+        replies.reserve(parallelAttempts);
+        for (int j = 0; j < parallelAttempts && it != urlList.constEnd(); ++j) {
+            req.setUrl(*it++);
+            QNetworkReply *r = manager.get(req);
+            r->ignoreSslErrors();
+
+            connect(r, SIGNAL(readyRead()), SLOT(slotReadAll()));
+            QTestEventLoop::instance().connect(r, SIGNAL(finished()), SLOT(exitLoop()));
+
+            replies.append(QSharedPointer<QNetworkReply>(r));
+        }
+
+        while (!timeout.hasExpired(30000)) {
+            QTestEventLoop::instance().enterLoop(30 - timeout.elapsed() / 1000);
+            int done = 0;
+            for (int j = 0; j < replies.size(); ++j)
+                done += replies[j]->isFinished() ? 1 : 0;
+            if (done == replies.size())
+                break;
+        }
+        if (timeout.hasExpired(30000)) {
+            for (int j = 0; j < replies.size(); ++j)
+                if (!replies[j]->isFinished())
+                    qDebug() << "Request" << replies[j]->url() << "not finished";
+            QFAIL("Timed out");
+        }
+        replies.clear();
+
+        totalBytes += byteCounter;
+        if (intermediateDebug) {
+            double rate = (byteCounter * 1.0 / timeout.elapsed());
+            qDebug() << byteCounter << "bytes in" << timeout.elapsed() << "ms:"
+                    << (rate / 1024.0 * 1000) << "kB/s";
+        }
+    }
+    qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 * 1000 / outerTimer.elapsed()) << "kB/s";
+}
+
+QTEST_MAIN(tst_NetworkRemoteStressTest);
+
+#include "tst_network_remote_stresstest.moc"
diff --git a/tests/manual/network_remote_stresstest/url-list.qrc b/tests/manual/network_remote_stresstest/url-list.qrc
new file mode 100644
index 0000000..ec529e5
--- /dev/null
+++ b/tests/manual/network_remote_stresstest/url-list.qrc
@@ -0,0 +1,5 @@
+<RCC>
+    <qresource prefix="/">
+        <file>url-list.txt</file>
+    </qresource>
+</RCC>
diff --git a/tests/manual/network_remote_stresstest/url-list.txt b/tests/manual/network_remote_stresstest/url-list.txt
new file mode 100644
index 0000000..edbf7e1
--- /dev/null
+++ b/tests/manual/network_remote_stresstest/url-list.txt
@@ -0,0 +1,62 @@
+http://www.digicert.com/CACerts/DigiCertAssuredIDRootCA.crt
+http://www.digicert.com/CACerts/DigiCertGlobalRootCA.crt
+http://www.digicert.com/CACerts/DigiCertHighAssuranceEVRootCA.crt
+http://www.quovadis.bm/public/qvrca2.crt
+http://www.quovadis.bm/public/qvrca3.crt
+https://secure.globalsign.net/cacert/root-r2.crt
+http://secure.globalsign.net/cacert/Root-R1.crt
+http://www.certplus.com/PC/certplus_class2.pem
+https://www.startssl.com/certs/ca.crt
+http://www.turktrust.com.tr/sertifikalar/TURKTRUST_Elektronik_Sertifika_Hizmet_Saglayicisi.crt
+http://www.turktrust.com.tr/sertifikalar/kok_s2.crt
+http://crt.comodoca.com/COMODOCertificationAuthority.crt
+http://crt.comodoca.com/COMODOECCCertificationAuthority.crt
+https://bugzilla.mozilla.org/attachment.cgi?id=368998
+https://bugzilla.mozilla.org/attachment.cgi?id=335538
+https://bugzilla.mozilla.org/attachment.cgi?id=304810
+https://www.securetrust.com/legal/STCA.txt
+https://www.securetrust.com/legal/SGCA.txt
+http://www.securetrust.com/legal/XGCA.txt
+http://www.diginotar.nl/files/Rootcertificaten/DigiNotar%20root%20CA2007.crt
+https://bugzilla.mozilla.org/attachment.cgi?id=294057
+https://bugzilla.mozilla.org/attachment.cgi?id=368997
+https://bugzilla.mozilla.org/attachment.cgi?id=306731
+https://certs.starfieldtech.com/repository/valicert_class2_root.crt
+https://certs.godaddy.com/repository/gd-class2-root.crt
+https://certs.starfieldtech.com/repository/sf-class2-root.crt
+ftp://ftp.networksolutions.com/certs/netsolevroot.crt
+https://bugzilla.mozilla.org/attachment.cgi?id=335551
+https://bugzilla.mozilla.org/attachment.cgi?id=369000
+https://bugzilla.mozilla.org/attachment.cgi?id=306736
+https://bugzilla.mozilla.org/attachment.cgi?id=267983
+https://swisssign.net/cgi-bin/authority/download?ca=50AFCC078715476F38C5B465D1DE95AAE9DF9CCC&into=browser
+https://swisssign.net/cgi-bin/authority/download?ca=5B257B96A465517EB839F3C078665EE83AE7F0EE&into=browser
+https://swisssign.net/cgi-bin/authority/download?ca=17A0CDC1E441B63A5B3BCB459DBD1CC298FA8658&into=browser
+http://apps.identrust.com/roots/DSTROOTCAX3.cer
+https://bugzilla.mozilla.org/attachment.cgi?id=277051
+http://www.ssi.gouv.fr/IMG/crt/igca-rsa.crt
+http://www.e-szigno.hu/RootCA.crt
+http://www.s-trust.de/service_support/zertifikatsmanagement/verzeichnisdienste/download_wurzelzertifikate/ordner_crt_dateien/authentication.crt
+http://www.trustcenter.de/media/class_2_ii.der
+http://www.trustcenter.de/media/class_3_ii.der
+http://www.trustcenter.de/media/Universal_CA-I.der
+http://www.certigna.fr/ca/ACcertigna.crt
+https://repository.secomtrust.net/EV-Root1/EVRoot1ca.cer
+http://fedir.comsign.co.il/cacert/ComsignCA.crt
+http://fedir.comsign.co.il/cacert/ComsignSecuredCA.crt
+http://crl.pki.wellsfargo.com/wsprca.crt
+http://cacert.omniroot.com/ct_root_ss.crt
+http://www.kamusm.gov.tr/BilgiDeposu/KOKSHS.v3.crt
+https://bugzilla.mozilla.org/attachment.cgi?id=380381
+http://210.71.154.6/download/ROOTeCA.cer
+https://bugzilla.mozilla.org/attachment.cgi?id=359654
+http://www.gpki.go.jp/apcaself/APCAroot.der
+https://bugzilla.mozilla.org/attachment.cgi?id=405525
+https://bugzilla.mozilla.org/attachment.cgi?id=361508
+https://bugzilla.mozilla.org/attachment.cgi?id=361508
+http://www.hongkongpost.gov.hk/product/download/root/img/smartid_rt.cacert
+http://www.sk.ee/files/JUUR-SK.der
+https://bugzilla.mozilla.org/attachment.cgi?id=408102
+http://www.disig.eu/ca/cert/ca_disig.der
+https://bugzilla.mozilla.org/attachment.cgi?id=365241
+https://www2.jcsinc.co.jp/repository/certs/SSAD-rca.der
diff --git a/tests/manual/network_stresstest/minihttpserver.cpp b/tests/manual/network_stresstest/minihttpserver.cpp
new file mode 100644
index 0000000..3630674
--- /dev/null
+++ b/tests/manual/network_stresstest/minihttpserver.cpp
@@ -0,0 +1,214 @@
+/****************************************************************************
+**
+** Copyright (C) 2010 Nokia Corporation and/or its subsidiary(-ies).
+** All rights reserved.
+** Contact: Nokia Corporation (qt-info@nokia.com)
+**
+** This file is part of the FOO module of the Qt Toolkit.
+**
+** $QT_BEGIN_LICENSE:LGPL$
+** No Commercial Usage
+** This file contains pre-release code and may not be distributed.
+** You may use this file in accordance with the terms and conditions
+** contained in the Technology Preview License Agreement accompanying
+** this package.
+**
+** GNU Lesser General Public License Usage
+** Alternatively, this file may be used under the terms of the GNU Lesser
+** General Public License version 2.1 as published by the Free Software
+** Foundation and appearing in the file LICENSE.LGPL included in the
+** packaging of this file.  Please review the following information to
+** ensure the GNU Lesser General Public License version 2.1 requirements
+** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
+**
+** In addition, as a special exception, Nokia gives you certain additional
+** rights.  These rights are described in the Nokia Qt LGPL Exception
+** version 1.1, included in the file LGPL_EXCEPTION.txt in this package.
+**
+** If you have questions regarding the use of this file, please contact
+** Nokia at qt-info@nokia.com.
+**
+**
+**
+**
+**
+**
+**
+**
+** $QT_END_LICENSE$
+**
+****************************************************************************/
+
+
+#include "minihttpserver.h"
+#include <QtCore/QFile>
+#include <QtCore/QSemaphore>
+#include <QtCore/QUrl>
+#include <QtNetwork/QTcpServer>
+#include <QtNetwork/QTcpSocket>
+
+MiniHttpServer::MiniHttpServer(QObject *parent) :
+    QThread(parent)
+{
+    readyToGo = new QSemaphore;
+    start();
+    readyToGo->acquire();
+    delete readyToGo;
+}
+
+MiniHttpServer::~MiniHttpServer()
+{
+    quitObject->deleteLater();
+    wait();
+}
+
+void MiniHttpServer::run()
+{
+    server = new QTcpServer;
+    server->listen(QHostAddress::LocalHost);
+    portnum = server->serverPort();
+    connect(server, SIGNAL(newConnection()), this, SLOT(handleConnection()), Qt::DirectConnection);
+
+    quitObject = new QObject;
+    connect(quitObject, SIGNAL(destroyed()), this, SLOT(quit()), Qt::DirectConnection);
+
+    readyToGo->release();
+    exec();
+
+    // cleanup
+    delete server;
+}
+
+void MiniHttpServer::handleConnection()
+{
+    while (server->hasPendingConnections()) {
+        QTcpSocket *socket = server->nextPendingConnection();
+        new MiniHttpServerConnection(socket); // handles its own lifetime
+    }
+}
+
+MiniHttpServerConnection::MiniHttpServerConnection(QTcpSocket *socket)
+    : QObject(socket), socket(socket), source(0)
+{
+    connect(socket, SIGNAL(readyRead()), SLOT(handleReadyRead()));
+    connect(socket, SIGNAL(bytesWritten(qint64)), SLOT(handleBytesWritten()));
+    connect(socket, SIGNAL(disconnected()), SLOT(handleDisconnected()));
+
+    timeout.setInterval(30000);
+    timeout.setSingleShot(true);
+    connect(&timeout, SIGNAL(timeout()), SLOT(handleTimeout()));
+    timeout.start();
+}
+
+void MiniHttpServerConnection::sendError500()
+{
+    static const char body[] =
+            "HTTP/1.1 500 Server Error\r\n"
+            "Connection: close\r\n"
+            "Content-Length: 0\r\n"
+            "\r\n";
+    socket->write(body, strlen(body));
+    socket->disconnectFromHost();
+}
+
+void MiniHttpServerConnection::sendError404()
+{
+    static const char body1[] =
+            "HTTP/1.1 404 File not found\r\n"
+            "Content-Length: 0\r\n";
+    socket->write(body1, strlen(body1));
+    if (connectionClose) {
+        socket->write("Connection: close\r\n\r\n");
+        socket->disconnectFromHost();
+    } else {
+        socket->write("\r\n");
+        handlePendingRequest();
+    }
+}
+
+void MiniHttpServerConnection::handlePendingRequest()
+{
+    int endOfRequest = buffer.indexOf("\r\n\r\n");
+    if (endOfRequest == -1)
+        return; // nothing to do
+
+    QByteArray request = buffer.left(endOfRequest);
+    buffer = buffer.mid(endOfRequest + 4);
+    //qDebug("request: %s", request.constData());
+
+    if (!request.startsWith("GET ")) {
+        sendError500();
+        return;
+    }
+
+    int eol = request.indexOf("\r\n");
+    static const char http11[] = " HTTP/1.1";
+    if (memcmp(request.data() + eol - strlen(http11), http11, strlen(http11)) != 0) {
+        sendError500();
+        return;
+    }
+
+    QUrl uri = QUrl::fromEncoded(request.mid(4, eol - strlen(http11) - 4));
+    source.setFileName(":" + uri.path());
+
+    // connection-close?
+    request = request.toLower();
+    connectionClose = request.contains("\r\nconnection: close\r\n");
+
+    if (!source.open(QIODevice::ReadOnly)) {
+        sendError404();
+        return;
+    }
+
+    // success
+    timeout.stop();
+    static const char body[] =
+            "HTTP/1.1 200 Ok\r\n"
+            "Content-Type: text/plain\r\n"
+            "Content-Length: ";
+    socket->write(body, strlen(body));
+    socket->write(QByteArray::number(source.size()));
+    if (connectionClose)
+        socket->write("\r\nConnection: close");
+    socket->write("\r\n\r\n");
+
+    handleBytesWritten();
+}
+
+void MiniHttpServerConnection::handleReadyRead()
+{
+    buffer += socket->readAll();
+    if (!source.isOpen())
+        handlePendingRequest();
+}
+
+void MiniHttpServerConnection::handleDisconnected()
+{
+    socket->deleteLater(); // will delete us too
+}
+
+void MiniHttpServerConnection::handleBytesWritten()
+{
+    qint64 maxBytes = qMin<qint64>(128*1024, source.bytesAvailable());
+    maxBytes = qMin(maxBytes, 128*1024 - socket->bytesToWrite());
+    if (maxBytes < 0)
+        return;
+
+    socket->write(source.read(maxBytes));
+
+    if (source.atEnd()) {
+        // file ended
+        source.close();
+        if (connectionClose) {
+            socket->disconnectFromHost();
+        } else {
+            timeout.start();
+            handlePendingRequest();
+        }
+    }
+}
+
+void MiniHttpServerConnection::handleTimeout()
+{
+    socket->disconnectFromHost();
+}
diff --git a/tests/manual/network_stresstest/minihttpserver.h b/tests/manual/network_stresstest/minihttpserver.h
new file mode 100644
index 0000000..9fcc8fc
--- /dev/null
+++ b/tests/manual/network_stresstest/minihttpserver.h
@@ -0,0 +1,99 @@
+/****************************************************************************
+**
+** Copyright (C) 2010 Nokia Corporation and/or its subsidiary(-ies).
+** All rights reserved.
+** Contact: Nokia Corporation (qt-info@nokia.com)
+**
+** This file is part of the FOO module of the Qt Toolkit.
+**
+** $QT_BEGIN_LICENSE:LGPL$
+** No Commercial Usage
+** This file contains pre-release code and may not be distributed.
+** You may use this file in accordance with the terms and conditions
+** contained in the Technology Preview License Agreement accompanying
+** this package.
+**
+** GNU Lesser General Public License Usage
+** Alternatively, this file may be used under the terms of the GNU Lesser
+** General Public License version 2.1 as published by the Free Software
+** Foundation and appearing in the file LICENSE.LGPL included in the
+** packaging of this file.  Please review the following information to
+** ensure the GNU Lesser General Public License version 2.1 requirements
+** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
+**
+** In addition, as a special exception, Nokia gives you certain additional
+** rights.  These rights are described in the Nokia Qt LGPL Exception
+** version 1.1, included in the file LGPL_EXCEPTION.txt in this package.
+**
+** If you have questions regarding the use of this file, please contact
+** Nokia at qt-info@nokia.com.
+**
+**
+**
+**
+**
+**
+**
+**
+** $QT_END_LICENSE$
+**
+****************************************************************************/
+
+
+#ifndef MINIHTTPSERVER_H
+#define MINIHTTPSERVER_H
+
+#include <QtCore/QThread>
+#include <QtCore/QFile>
+#include <QtCore/QTimer>
+
+class QFile;
+class QSemaphore;
+class QTcpServer;
+class QTcpSocket;
+
+class MiniHttpServer : public QThread
+{
+    Q_OBJECT
+public:
+    explicit MiniHttpServer(QObject *parent = 0);
+    ~MiniHttpServer();
+
+    int port() { return portnum; }
+
+protected:
+    void run();
+
+private slots:
+    void handleConnection();
+
+private:
+    QTcpServer *server;
+    QObject *quitObject;
+    QSemaphore *readyToGo;
+    int portnum;
+};
+
+class MiniHttpServerConnection: public QObject
+{
+    Q_OBJECT
+    QTcpSocket * const socket;
+    QFile source;
+    QTimer timeout;
+    QByteArray buffer;
+    bool connectionClose;
+public:
+    explicit MiniHttpServerConnection(QTcpSocket *socket);
+
+    void sendError500();
+    void sendError404();
+    void handlePendingRequest();
+
+public slots:
+    void handleReadyRead();
+    void handleBytesWritten();
+    void handleDisconnected();
+    void handleTimeout();
+};
+
+#endif // MINIHTTPSERVER_H
diff --git a/tests/manual/network_stresstest/network_stresstest.pro b/tests/manual/network_stresstest/network_stresstest.pro
new file mode 100644
index 0000000..0e272d1
--- /dev/null
+++ b/tests/manual/network_stresstest/network_stresstest.pro
@@ -0,0 +1,12 @@
+load(qttest_p4)
+
+QT = core network
+
+SOURCES  += tst_network_stresstest.cpp \
+    minihttpserver.cpp
+
+HEADERS += \
+    minihttpserver.h
+
+RESOURCES += wwwfiles.qrc
+QMAKE_RESOURCE_FLAGS += -no-compress
diff --git a/tests/manual/network_stresstest/qtest/bigfile b/tests/manual/network_stresstest/qtest/bigfile
new file mode 100644
index 0000000..cb114a2
--- /dev/null
+++ b/tests/manual/network_stresstest/qtest/bigfile
@@ -0,0 +1,17980 @@
+
+
+
+
+
+
+Network Working Group                                         H. Kennedy
+Request for Comments: 3252                                      Mimezine
+Category: Informational                                     1 April 2002
+
+
+                 Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document defines a reformulation of IP and two transport layer
+   protocols (TCP and UDP) as XML applications.
+
+1.   Introduction
+
+1.1. Overview
+
+   This document describes the Binary Lexical Octet Ad-hoc Transport
+   (BLOAT): a reformulation of a widely-deployed network-layer protocol
+   (IP [RFC791]), and two associated transport layer protocols (TCP
+   [RFC793] and UDP [RFC768]) as XML [XML] applications.  It also
+   describes methods for transporting BLOAT over Ethernet and IEEE 802
+   networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+   across the public Internet.
+
+1.2. Motivation
+
+   The wild popularity of XML as a basis for application-level protocols
+   such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+   Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+   investigation into the possibility of extending the use of XML in the
+   protocol stack.  Using XML at both the transport and network layer in
+   addition to the application layer would provide for an amazing amount
+   of power and flexibility while removing dependencies on proprietary
+   and hard-to-understand binary protocols.  This protocol unification
+   would also allow applications to use a single XML parser for all
+   aspects of their operation, eliminating developer time spent figuring
+   out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy                      Informational                      [Page 1]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   parsing to the XML toolset.  The use of XML also mitigates concerns
+   over "network vs. host" byte ordering which is at the root of many
+   network application bugs.
+
+1.3. Relation to Existing Protocols
+
+   The reformulations specified in this RFC follow as closely as
+   possible the spirit of the RFCs on which they are based, and so MAY
+   contain elements or attributes that would not be needed in a pure
+   reworking (e.g. length attributes, which are implicit in XML.)
+
+   The layering of network and transport protocols are maintained in
+   this RFC despite the optimizations that could be made if the line
+   were somewhat blurred (i.e. merging TCP and IP into a single, larger
+   element in the DTD) in order to foster future use of this protocol as
+   a basis for reformulating other protocols (such as ICMP.)
+
+   Other than the encoding, the behavioral aspects of each of the
+   existing protocols remain unchanged.  Routing, address spaces, TCP
+   congestion control, etc. behave as specified in the extant standards.
+   Adapting to new standards and experimental algorithm heuristics for
+   improving performance will become much easier once the move to BLOAT
+   has been completed.
+
+1.4. Requirement Levels
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119
+   [RFC2119].
+
+2.   IPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.
+   IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+   (section 3.) and higher-level application protocols.
+
+   The DTD for this document type can be found in section 7.1.
+
+   The routing of IPoXML can be easily implemented on hosts with an XML
+   parser, as the regular structure lends itself handily to parsing and
+   validation of the document/datagram and then processing the
+   destination address, TTL, and checksum before sending it on to its
+   next-hop.
+
+   The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+   wider deployment of IPv4 and the fact that implementing IPv6 as XML
+   would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy                      Informational                      [Page 2]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+   of RFC 2279 [RFC2279].  All BLOAT document/datagrams MUST be well-
+   formed and include the XMLDecl.
+
+2.1. IP Description
+
+   A number of items have changed (for the better) from the original IP
+   specification.  Bit-masks, where present have been converted into
+   human-readable values.  IP addresses are listed in their dotted-
+   decimal notation [RFC1123].  Length and checksum values are present
+   as decimal integers.
+
+   To calculate the length and checksum fields of the IP element, a
+   canonicalized form of the element MUST be used.  The canonical form
+   SHALL have no whitespace (including newline characters) between
+   elements and only one space character between attributes.  There
+   SHALL NOT be a space following the last attribute in an element.
+
+   An iterative method SHOULD be used to calculate checksums, as the
+   length field will vary based on the size of the checksum.
+
+   The payload element bears special attention.  Due to the character
+   set restrictions of XML, the payload of IP datagrams (which MAY
+   contain arbitrary data) MUST be encoded for transport. This RFC
+   REQUIRES the contents of the payload to be encoded in the base-64
+   encoding of RFC 2045 [RFC2045], but removes the requirement that the
+   encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 3]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+2.2. Example Datagram
+
+   The following is an example IPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   <ip>
+   <header length="474">
+   <version value="4"/>
+   <tos precedence="Routine" delay="Normal" throughput="Normal"
+        relibility="Normal" reserved="0"/>
+   <total.length value="461"/>
+   <id value="1"/>
+   <flags reserved="0" df="dont" mf="last"/>
+   <offset value="0"/>
+   <ttl value="255"/>
+   <protocol value="6"/>
+   <checksum value="8707"/>
+   <source address="10.0.0.22"/>
+   <destination address="10.0.0.1"/>
+   <options>
+   <end copied="0" class="0" number="0"/>
+   </options>
+   <padding pad="0"/>
+   </header>
+   <payload>
+   </payload>
+   </ip>
+
+3.   TCPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+   A number of items have changed from the original TCP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+   To calculate the length and checksum fields of the TCP element, a
+   canonicalized form of the element MUST be used as in section 2.1.
+
+   An iterative method SHOULD be used to calculate checksums as in
+   section 2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy                      Informational                      [Page 4]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   The TCP offset element was expanded to a maximum of 255 from 16 to
+   allow for the increased size of the header in XML.
+
+   TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+   The following is an example TCPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   <tcp>
+   <tcp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <sequence number="322622954"/>
+   <acknowledgement number="689715995"/>
+   <offset number=""/>
+   <reserved value="0"/>
+   <control syn="1" ack="1"/>
+   <window size="1"/>
+   <urgent pointer="0"/>
+   <checksum value="2988"/>
+   <tcp.options>
+   <tcp.end kind="0"/>
+   </tcp.options>
+   <padding pad="0"/>
+   </tcp.header>
+   <payload>
+   </payload>
+   </tcp>
+
+4.   UDPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+   A number of items have changed from the original UDP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 5]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   To calculate the length and checksum fields of the UDP element, a
+   canonicalized form of the element MUST be used as in section 2.1.  An
+   iterative method SHOULD be used to calculate checksums as in section
+   2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+   UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+   The following is an example UDPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   <udp>
+   <udp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <udp.length value="143"/>
+   <checksum value="2988"/>
+   </udp.header>
+   <payload>
+   </payload>
+   </udp>
+
+5.   Network Transport
+
+   This document provides for the transmission of BLOAT datagrams over
+   two common families of physical layer transport.  Future RFCs will
+   address additional transports as routing vendors catch up to the
+   specification, and we begin to see BLOAT routed across the Internet
+   backbone.
+
+5.1. Ethernet
+
+   BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+   exception that the type field of the Ethernet frame MUST contain the
+   value 0xBEEF.  The first 5 octets of the Ethernet frame payload will
+   be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+   BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+   that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy                      Informational                      [Page 6]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+6. Gatewaying over IP
+
+   In order to facilitate the gradual introduction of BLOAT into the
+   public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+   gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+   The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+   Network DTD (7.1.)
+
+   The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+   [XML]) although it is understood that most IPoXML implementations
+   will not need to pull down the DTD, as it will normally be embedded
+   in the implementation, and presents something of a catch-22 if you
+   need to load part of your network protocol over the network.
+
+7.1.  IPoXML DTD
+
+   <!--
+    DTD for IP over XML.
+    Refer to this DTD as:
+
+    <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   -->
+   <!--
+    DTD data types:
+
+      Digits      [0..9]+
+
+      Precedence  "NetworkControl | InternetworkControl |
+                   CRITIC | FlashOverride | Flash | Immediate |
+                   Priority | Routine"
+
+      IP4Addr     "dotted-decimal" notation of [RFC1123]
+
+      Class       [0..3]
+
+      Sec          "Unclassified | Confidential | EFTO | MMMM | PROG |
+                    Restricted | Secret | Top Secret | Reserved"
+
+      Compartments [0..65535]
+
+      Handling     [0..65535]
+
+      TCC          [0..16777216]
+
+   -->
+
+
+
+Kennedy                      Informational                      [Page 7]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ENTITY % Digits "CDATA">
+   <!ENTITY % Precedence "CDATA">
+   <!ENTITY % IP4Addr "CDATA">
+   <!ENTITY % Class "CDATA">
+   <!ENTITY % Sec "CDATA">
+   <!ENTITY % Compartments "CDATA">
+   <!ENTITY % Handling "CDATA">
+   <!ENTITY % TCC "CDATA">
+
+   <!ELEMENT ip (header, payload)>
+
+   <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+                    protocol, checksum, source, destination, options,
+                    padding)>
+   <!-- length of header in 32-bit words -->
+   <!ATTLIST header
+             length %Digits; #REQUIRED>
+
+   <!ELEMENT version EMPTY>
+   <!-- ip version. SHOULD be "4" -->
+   <!ATTLIST version
+             value   %Digits;  #REQUIRED>
+
+   <!ELEMENT tos EMPTY>
+   <!ATTLIST tos
+             precedence   %Precedence;    #REQUIRED
+             delay    (normal | low)  #REQUIRED
+             throughput   (normal | high) #REQUIRED
+             relibility   (normal | high) #REQUIRED
+             reserved     CDATA #FIXED "0">
+
+   <!ELEMENT total.length EMPTY>
+   <!--
+    total length of datagram (header and payload) in octets, MUST be
+    less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+    ethernets).
+   -->
+   <!ATTLIST total.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT id EMPTY>
+   <!-- 0 <= id <= 65,535  -->
+   <!ATTLIST id
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT flags EMPTY>
+   <!-- df = don't fragment, mf = more fragments  -->
+   <!ATTLIST flags
+
+
+
+Kennedy                      Informational                      [Page 8]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+          reserved CDATA  #FIXED "0"
+          df (may|dont)   #REQUIRED
+          mf (last|more)  #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+   <!ATTLIST offset
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT ttl EMPTY>
+   <!-- 0 <= ttl <= 255 -->
+   <!ATTLIST ttl
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT protocol EMPTY>
+   <!-- 0 <= protocol <= 255 (per IANA) -->
+   <!ATTLIST protocol
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT checksum EMPTY>
+   <!-- 0 <= checksum <= 65535 (over header only) -->
+   <!ATTLIST checksum
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT source EMPTY>
+   <!ATTLIST source
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT destination EMPTY>
+   <!ATTLIST destination
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT options ( end | noop | security | loose | strict | record
+                     | stream | timestamp )*>
+
+   <!ELEMENT end EMPTY>
+   <!ATTLIST end
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "0">
+
+   <!ELEMENT noop EMPTY>
+   <!ATTLIST noop
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "1">
+
+   <!ELEMENT security EMPTY>
+
+
+
+Kennedy                      Informational                      [Page 9]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST security
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "2"
+             length CDATA #FIXED "11"
+             security %Sec; #REQUIRED
+             compartments %Compartments; #REQUIRED
+             handling %Handling; #REQUIRED
+             tcc %TCC; #REQUIRED>
+   <!ELEMENT loose (hop)+>
+   <!ATTLIST loose
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "3"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT hop EMPTY>
+   <!ATTLIST hop
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT strict (hop)+>
+   <!ATTLIST strict
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "9"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT record (hop)+>
+   <!ATTLIST record
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "7"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT stream EMPTY>
+   <!-- 0 <= id <= 65,535 -->
+   <!ATTLIST stream
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "8"
+             length CDATA #FIXED "4"
+             id %Digits; #REQUIRED>
+
+   <!ELEMENT timestamp (tstamp)+>
+   <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy                      Informational                     [Page 10]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST timestamp
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "2"
+             number CDATA #FIXED "4"
+             length %Digits;  #REQUIRED
+             pointer %Digits; #REQUIRED
+             oflw %Digits;    #REQUIRED
+             flag (0 | 1 | 3)  #REQUIRED>
+
+   <!ELEMENT tstamp EMPTY>
+   <!ATTLIST tstamp
+             time %Digits;   #REQUIRED
+             address %IP4Addr; #IMPLIED>
+   <!--
+       padding to bring header to 32-bit boundary.
+       pad MUST be "0"*
+    -->
+   <!ELEMENT padding EMPTY>
+   <!ATTLIST padding
+             pad CDATA #REQUIRED>
+
+   <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+        by section 2.1 of this RFC -->
+   <!ELEMENT payload (CDATA)>
+
+7.2.  TCPoXML DTD
+
+   <!--
+      DTD for TCP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   -->
+
+   <!-- the pseudoheader is only included for checksum calculations -->
+   <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+   <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+                         reserved, control, window, checksum, urgent,
+                         tcp.options, padding)>
+
+   <!ELEMENT src EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+   <!ATTLIST src
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT dest EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy                      Informational                     [Page 11]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST dest
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT sequence EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST sequence
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT acknowledgement EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST acknowledgement
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= number <= 255 -->
+   <!ATTLIST offset
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT reserved EMPTY>
+   <!ATTLIST reserved
+             value CDATA #FIXED "0">
+
+   <!ELEMENT control EMPTY>
+   <!ATTLIST control
+             urg (0|1) #IMPLIED
+             ack (0|1) #IMPLIED
+             psh (0|1) #IMPLIED
+             rst (0|1) #IMPLIED
+             syn (0|1) #IMPLIED
+             fin (0|1) #IMPLIED>
+
+   <!ELEMENT window EMPTY>
+   <!-- 0 <= size <= 65,535 -->
+   <!ATTLIST window
+             size %Digits; #REQUIRED>
+
+   <!--
+      checksum as in ip, but with
+      the following pseudo-header added into the tcp element:
+     -->
+   <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+                               tcp.length)>
+
+   <!--
+      tcp header + data length in octets. does not include the size of
+
+      the pseudoheader.
+    -->
+
+
+
+Kennedy                      Informational                     [Page 12]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ELEMENT tcp.length EMPTY>
+   <!ATTLIST tcp.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT urgent EMPTY>
+   <!-- 0 <= pointer <= 65,535 -->
+   <!ATTLIST urgent
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+   <!ELEMENT tcp.end EMPTY>
+   <!ATTLIST tcp.end
+             kind CDATA #FIXED "0">
+
+   <!ELEMENT tcp.noop EMPTY>
+   <!ATTLIST tcp.noop
+             kind CDATA #FIXED "1">
+
+   <!ELEMENT tcp.mss EMPTY>
+   <!ATTLIST tcp.mss
+             kind CDATA #FIXED "2"
+             length CDATA #FIXED "4"
+             size %Digits; #REQUIRED>
+
+7.3.  UDPoXML DTD
+
+   <!--
+      DTD for UDP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   -->
+
+   <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+   <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+   <!ELEMENT udp.pseudoheader (source, destination, protocol,
+                               udp.length)>
+
+   <!--
+      udp header + data length in octets. does not include the size of
+      the pseudoheader.
+    -->
+   <!ELEMENT udp.length EMPTY>
+   <!ATTLIST udp.length
+             value %Digits; #REQUIRED>
+
+
+
+Kennedy                      Informational                     [Page 13]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+8. Security Considerations
+
+   XML, as a subset of SGML, has the same security considerations as
+   specified in SGML Media Types [RFC1874].  Security considerations
+   that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+   not attempt to correct for issues not related to message format.
+
+9.   References
+
+   [JABBER]    Miller, J., "Jabber", draft-miller-jabber-00.txt,
+               February 2002. (Work in Progress)
+
+   [RFC768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+               August 1980.
+
+   [RFC791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
+               September 1981.
+
+   [RFC793]    Postel, J., "Transmission Control Protocol", STD 7, RFC
+               793, September 1981.
+
+   [RFC894]    Hornig, C., "Standard for the Transmission of IP
+               Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+   [RFC1042]   Postel, J. and J. Reynolds, "Standard for the
+               Transmission of IP Datagrams Over IEEE 802 Networks", STD
+               43, RFC 1042, February 1988.
+
+   [RFC1123]   Braden, R., "Requirements for Internet Hosts -
+               Application and Support", RFC 1123, October 1989.
+
+   [RFC1874]   Levinson, E., "SGML Media Types", RFC 1874, December
+               1995.
+
+   [RFC2003]   Perkins, C., "IP Encapsulation within IP", RFC 2003,
+               October 1996.
+
+   [RFC2045]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part One: Format of Internet Message
+               Bodies", RFC 2045, November 1996.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2279]   Yergeau, F., "UTF-8, a transformation format of ISO
+               10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy                      Informational                     [Page 14]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   [RFC2460]   Deering, S. and R. Hinden, "Internet Protocol, Version 6
+               (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC3080]   Rose, M., "The Blocks Extensible Exchange Protocol Core",
+               RFC 3080, March 2001.
+
+   [SOAP]      Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+               Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+               "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+               Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+   [XML]       Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+               Markup Language (XML)" World Wide Web Consortium
+               Recommendation REC- xml-19980210.
+               http://www.w3.org/TR/1998/REC-xml-19980210
+
+10.  Author's Address
+
+   Hugh Kennedy
+   Mimezine
+   1060 West Addison
+   Chicago, IL 60613
+   USA
+
+   EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 15]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 16]
+
+
+
+
+
+
+
+Network Working Group                                         H. Kennedy
+Request for Comments: 3252                                      Mimezine
+Category: Informational                                     1 April 2002
+
+
+                 Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document defines a reformulation of IP and two transport layer
+   protocols (TCP and UDP) as XML applications.
+
+1.   Introduction
+
+1.1. Overview
+
+   This document describes the Binary Lexical Octet Ad-hoc Transport
+   (BLOAT): a reformulation of a widely-deployed network-layer protocol
+   (IP [RFC791]), and two associated transport layer protocols (TCP
+   [RFC793] and UDP [RFC768]) as XML [XML] applications.  It also
+   describes methods for transporting BLOAT over Ethernet and IEEE 802
+   networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+   across the public Internet.
+
+1.2. Motivation
+
+   The wild popularity of XML as a basis for application-level protocols
+   such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+   Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+   investigation into the possibility of extending the use of XML in the
+   protocol stack.  Using XML at both the transport and network layer in
+   addition to the application layer would provide for an amazing amount
+   of power and flexibility while removing dependencies on proprietary
+   and hard-to-understand binary protocols.  This protocol unification
+   would also allow applications to use a single XML parser for all
+   aspects of their operation, eliminating developer time spent figuring
+   out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy                      Informational                      [Page 1]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   parsing to the XML toolset.  The use of XML also mitigates concerns
+   over "network vs. host" byte ordering which is at the root of many
+   network application bugs.
+
+1.3. Relation to Existing Protocols
+
+   The reformulations specified in this RFC follow as closely as
+   possible the spirit of the RFCs on which they are based, and so MAY
+   contain elements or attributes that would not be needed in a pure
+   reworking (e.g. length attributes, which are implicit in XML.)
+
+   The layering of network and transport protocols are maintained in
+   this RFC despite the optimizations that could be made if the line
+   were somewhat blurred (i.e. merging TCP and IP into a single, larger
+   element in the DTD) in order to foster future use of this protocol as
+   a basis for reformulating other protocols (such as ICMP.)
+
+   Other than the encoding, the behavioral aspects of each of the
+   existing protocols remain unchanged.  Routing, address spaces, TCP
+   congestion control, etc. behave as specified in the extant standards.
+   Adapting to new standards and experimental algorithm heuristics for
+   improving performance will become much easier once the move to BLOAT
+   has been completed.
+
+1.4. Requirement Levels
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119
+   [RFC2119].
+
+2.   IPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.
+   IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+   (section 3.) and higher-level application protocols.
+
+   The DTD for this document type can be found in section 7.1.
+
+   The routing of IPoXML can be easily implemented on hosts with an XML
+   parser, as the regular structure lends itself handily to parsing and
+   validation of the document/datagram and then processing the
+   destination address, TTL, and checksum before sending it on to its
+   next-hop.
+
+   The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+   wider deployment of IPv4 and the fact that implementing IPv6 as XML
+   would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy                      Informational                      [Page 2]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+   of RFC 2279 [RFC2279].  All BLOAT document/datagrams MUST be well-
+   formed and include the XMLDecl.
+
+2.1. IP Description
+
+   A number of items have changed (for the better) from the original IP
+   specification.  Bit-masks, where present have been converted into
+   human-readable values.  IP addresses are listed in their dotted-
+   decimal notation [RFC1123].  Length and checksum values are present
+   as decimal integers.
+
+   To calculate the length and checksum fields of the IP element, a
+   canonicalized form of the element MUST be used.  The canonical form
+   SHALL have no whitespace (including newline characters) between
+   elements and only one space character between attributes.  There
+   SHALL NOT be a space following the last attribute in an element.
+
+   An iterative method SHOULD be used to calculate checksums, as the
+   length field will vary based on the size of the checksum.
+
+   The payload element bears special attention.  Due to the character
+   set restrictions of XML, the payload of IP datagrams (which MAY
+   contain arbitrary data) MUST be encoded for transport. This RFC
+   REQUIRES the contents of the payload to be encoded in the base-64
+   encoding of RFC 2045 [RFC2045], but removes the requirement that the
+   encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 3]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+2.2. Example Datagram
+
+   The following is an example IPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   <ip>
+   <header length="474">
+   <version value="4"/>
+   <tos precedence="Routine" delay="Normal" throughput="Normal"
+        relibility="Normal" reserved="0"/>
+   <total.length value="461"/>
+   <id value="1"/>
+   <flags reserved="0" df="dont" mf="last"/>
+   <offset value="0"/>
+   <ttl value="255"/>
+   <protocol value="6"/>
+   <checksum value="8707"/>
+   <source address="10.0.0.22"/>
+   <destination address="10.0.0.1"/>
+   <options>
+   <end copied="0" class="0" number="0"/>
+   </options>
+   <padding pad="0"/>
+   </header>
+   <payload>
+   </payload>
+   </ip>
+
+3.   TCPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+   A number of items have changed from the original TCP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+   To calculate the length and checksum fields of the TCP element, a
+   canonicalized form of the element MUST be used as in section 2.1.
+
+   An iterative method SHOULD be used to calculate checksums as in
+   section 2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy                      Informational                      [Page 4]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   The TCP offset element was expanded to a maximum of 255 from 16 to
+   allow for the increased size of the header in XML.
+
+   TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+   The following is an example TCPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   <tcp>
+   <tcp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <sequence number="322622954"/>
+   <acknowledgement number="689715995"/>
+   <offset number=""/>
+   <reserved value="0"/>
+   <control syn="1" ack="1"/>
+   <window size="1"/>
+   <urgent pointer="0"/>
+   <checksum value="2988"/>
+   <tcp.options>
+   <tcp.end kind="0"/>
+   </tcp.options>
+   <padding pad="0"/>
+   </tcp.header>
+   <payload>
+   </payload>
+   </tcp>
+
+4.   UDPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+   A number of items have changed from the original UDP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 5]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   To calculate the length and checksum fields of the UDP element, a
+   canonicalized form of the element MUST be used as in section 2.1.  An
+   iterative method SHOULD be used to calculate checksums as in section
+   2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+   UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+   The following is an example UDPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   <udp>
+   <udp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <udp.length value="143"/>
+   <checksum value="2988"/>
+   </udp.header>
+   <payload>
+   </payload>
+   </udp>
+
+5.   Network Transport
+
+   This document provides for the transmission of BLOAT datagrams over
+   two common families of physical layer transport.  Future RFCs will
+   address additional transports as routing vendors catch up to the
+   specification, and we begin to see BLOAT routed across the Internet
+   backbone.
+
+5.1. Ethernet
+
+   BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+   exception that the type field of the Ethernet frame MUST contain the
+   value 0xBEEF.  The first 5 octets of the Ethernet frame payload will
+   be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+   BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+   that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy                      Informational                      [Page 6]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+6. Gatewaying over IP
+
+   In order to facilitate the gradual introduction of BLOAT into the
+   public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+   gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+   The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+   Network DTD (7.1.)
+
+   The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+   [XML]) although it is understood that most IPoXML implementations
+   will not need to pull down the DTD, as it will normally be embedded
+   in the implementation, and presents something of a catch-22 if you
+   need to load part of your network protocol over the network.
+
+7.1.  IPoXML DTD
+
+   <!--
+    DTD for IP over XML.
+    Refer to this DTD as:
+
+    <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   -->
+   <!--
+    DTD data types:
+
+      Digits      [0..9]+
+
+      Precedence  "NetworkControl | InternetworkControl |
+                   CRITIC | FlashOverride | Flash | Immediate |
+                   Priority | Routine"
+
+      IP4Addr     "dotted-decimal" notation of [RFC1123]
+
+      Class       [0..3]
+
+      Sec          "Unclassified | Confidential | EFTO | MMMM | PROG |
+                    Restricted | Secret | Top Secret | Reserved"
+
+      Compartments [0..65535]
+
+      Handling     [0..65535]
+
+      TCC          [0..16777216]
+
+   -->
+
+
+
+Kennedy                      Informational                      [Page 7]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ENTITY % Digits "CDATA">
+   <!ENTITY % Precedence "CDATA">
+   <!ENTITY % IP4Addr "CDATA">
+   <!ENTITY % Class "CDATA">
+   <!ENTITY % Sec "CDATA">
+   <!ENTITY % Compartments "CDATA">
+   <!ENTITY % Handling "CDATA">
+   <!ENTITY % TCC "CDATA">
+
+   <!ELEMENT ip (header, payload)>
+
+   <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+                    protocol, checksum, source, destination, options,
+                    padding)>
+   <!-- length of header in 32-bit words -->
+   <!ATTLIST header
+             length %Digits; #REQUIRED>
+
+   <!ELEMENT version EMPTY>
+   <!-- ip version. SHOULD be "4" -->
+   <!ATTLIST version
+             value   %Digits;  #REQUIRED>
+
+   <!ELEMENT tos EMPTY>
+   <!ATTLIST tos
+             precedence   %Precedence;    #REQUIRED
+             delay    (normal | low)  #REQUIRED
+             throughput   (normal | high) #REQUIRED
+             relibility   (normal | high) #REQUIRED
+             reserved     CDATA #FIXED "0">
+
+   <!ELEMENT total.length EMPTY>
+   <!--
+    total length of datagram (header and payload) in octets, MUST be
+    less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+    ethernets).
+   -->
+   <!ATTLIST total.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT id EMPTY>
+   <!-- 0 <= id <= 65,535  -->
+   <!ATTLIST id
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT flags EMPTY>
+   <!-- df = don't fragment, mf = more fragments  -->
+   <!ATTLIST flags
+
+
+
+Kennedy                      Informational                      [Page 8]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+          reserved CDATA  #FIXED "0"
+          df (may|dont)   #REQUIRED
+          mf (last|more)  #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+   <!ATTLIST offset
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT ttl EMPTY>
+   <!-- 0 <= ttl <= 255 -->
+   <!ATTLIST ttl
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT protocol EMPTY>
+   <!-- 0 <= protocol <= 255 (per IANA) -->
+   <!ATTLIST protocol
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT checksum EMPTY>
+   <!-- 0 <= checksum <= 65535 (over header only) -->
+   <!ATTLIST checksum
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT source EMPTY>
+   <!ATTLIST source
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT destination EMPTY>
+   <!ATTLIST destination
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT options ( end | noop | security | loose | strict | record
+                     | stream | timestamp )*>
+
+   <!ELEMENT end EMPTY>
+   <!ATTLIST end
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "0">
+
+   <!ELEMENT noop EMPTY>
+   <!ATTLIST noop
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "1">
+
+   <!ELEMENT security EMPTY>
+
+
+
+Kennedy                      Informational                      [Page 9]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST security
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "2"
+             length CDATA #FIXED "11"
+             security %Sec; #REQUIRED
+             compartments %Compartments; #REQUIRED
+             handling %Handling; #REQUIRED
+             tcc %TCC; #REQUIRED>
+   <!ELEMENT loose (hop)+>
+   <!ATTLIST loose
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "3"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT hop EMPTY>
+   <!ATTLIST hop
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT strict (hop)+>
+   <!ATTLIST strict
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "9"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT record (hop)+>
+   <!ATTLIST record
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "7"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT stream EMPTY>
+   <!-- 0 <= id <= 65,535 -->
+   <!ATTLIST stream
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "8"
+             length CDATA #FIXED "4"
+             id %Digits; #REQUIRED>
+
+   <!ELEMENT timestamp (tstamp)+>
+   <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy                      Informational                     [Page 10]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST timestamp
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "2"
+             number CDATA #FIXED "4"
+             length %Digits;  #REQUIRED
+             pointer %Digits; #REQUIRED
+             oflw %Digits;    #REQUIRED
+             flag (0 | 1 | 3)  #REQUIRED>
+
+   <!ELEMENT tstamp EMPTY>
+   <!ATTLIST tstamp
+             time %Digits;   #REQUIRED
+             address %IP4Addr; #IMPLIED>
+   <!--
+       padding to bring header to 32-bit boundary.
+       pad MUST be "0"*
+    -->
+   <!ELEMENT padding EMPTY>
+   <!ATTLIST padding
+             pad CDATA #REQUIRED>
+
+   <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+        by section 2.1 of this RFC -->
+   <!ELEMENT payload (CDATA)>
+
+7.2.  TCPoXML DTD
+
+   <!--
+      DTD for TCP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   -->
+
+   <!-- the pseudoheader is only included for checksum calculations -->
+   <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+   <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+                         reserved, control, window, checksum, urgent,
+                         tcp.options, padding)>
+
+   <!ELEMENT src EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+   <!ATTLIST src
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT dest EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy                      Informational                     [Page 11]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST dest
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT sequence EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST sequence
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT acknowledgement EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST acknowledgement
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= number <= 255 -->
+   <!ATTLIST offset
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT reserved EMPTY>
+   <!ATTLIST reserved
+             value CDATA #FIXED "0">
+
+   <!ELEMENT control EMPTY>
+   <!ATTLIST control
+             urg (0|1) #IMPLIED
+             ack (0|1) #IMPLIED
+             psh (0|1) #IMPLIED
+             rst (0|1) #IMPLIED
+             syn (0|1) #IMPLIED
+             fin (0|1) #IMPLIED>
+
+   <!ELEMENT window EMPTY>
+   <!-- 0 <= size <= 65,535 -->
+   <!ATTLIST window
+             size %Digits; #REQUIRED>
+
+   <!--
+      checksum as in ip, but with
+      the following pseudo-header added into the tcp element:
+     -->
+   <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+                               tcp.length)>
+
+   <!--
+      tcp header + data length in octets. does not include the size of
+
+      the pseudoheader.
+    -->
+
+
+
+Kennedy                      Informational                     [Page 12]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ELEMENT tcp.length EMPTY>
+   <!ATTLIST tcp.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT urgent EMPTY>
+   <!-- 0 <= pointer <= 65,535 -->
+   <!ATTLIST urgent
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+   <!ELEMENT tcp.end EMPTY>
+   <!ATTLIST tcp.end
+             kind CDATA #FIXED "0">
+
+   <!ELEMENT tcp.noop EMPTY>
+   <!ATTLIST tcp.noop
+             kind CDATA #FIXED "1">
+
+   <!ELEMENT tcp.mss EMPTY>
+   <!ATTLIST tcp.mss
+             kind CDATA #FIXED "2"
+             length CDATA #FIXED "4"
+             size %Digits; #REQUIRED>
+
+7.3.  UDPoXML DTD
+
+   <!--
+      DTD for UDP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   -->
+
+   <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+   <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+   <!ELEMENT udp.pseudoheader (source, destination, protocol,
+                               udp.length)>
+
+   <!--
+      udp header + data length in octets. does not include the size of
+      the pseudoheader.
+    -->
+   <!ELEMENT udp.length EMPTY>
+   <!ATTLIST udp.length
+             value %Digits; #REQUIRED>
+
+
+
+Kennedy                      Informational                     [Page 13]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+8. Security Considerations
+
+   XML, as a subset of SGML, has the same security considerations as
+   specified in SGML Media Types [RFC1874].  Security considerations
+   that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+   not attempt to correct for issues not related to message format.
+
+9.   References
+
+   [JABBER]    Miller, J., "Jabber", draft-miller-jabber-00.txt,
+               February 2002. (Work in Progress)
+
+   [RFC768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+               August 1980.
+
+   [RFC791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
+               September 1981.
+
+   [RFC793]    Postel, J., "Transmission Control Protocol", STD 7, RFC
+               793, September 1981.
+
+   [RFC894]    Hornig, C., "Standard for the Transmission of IP
+               Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+   [RFC1042]   Postel, J. and J. Reynolds, "Standard for the
+               Transmission of IP Datagrams Over IEEE 802 Networks", STD
+               43, RFC 1042, February 1988.
+
+   [RFC1123]   Braden, R., "Requirements for Internet Hosts -
+               Application and Support", RFC 1123, October 1989.
+
+   [RFC1874]   Levinson, E., "SGML Media Types", RFC 1874, December
+               1995.
+
+   [RFC2003]   Perkins, C., "IP Encapsulation within IP", RFC 2003,
+               October 1996.
+
+   [RFC2045]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part One: Format of Internet Message
+               Bodies", RFC 2045, November 1996.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2279]   Yergeau, F., "UTF-8, a transformation format of ISO
+               10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy                      Informational                     [Page 14]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   [RFC2460]   Deering, S. and R. Hinden, "Internet Protocol, Version 6
+               (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC3080]   Rose, M., "The Blocks Extensible Exchange Protocol Core",
+               RFC 3080, March 2001.
+
+   [SOAP]      Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+               Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+               "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+               Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+   [XML]       Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+               Markup Language (XML)" World Wide Web Consortium
+               Recommendation REC- xml-19980210.
+               http://www.w3.org/TR/1998/REC-xml-19980210
+
+10.  Author's Address
+
+   Hugh Kennedy
+   Mimezine
+   1060 West Addison
+   Chicago, IL 60613
+   USA
+
+   EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 15]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 16]
+
+
+
+
+
+
+
+Network Working Group                                         H. Kennedy
+Request for Comments: 3252                                      Mimezine
+Category: Informational                                     1 April 2002
+
+
+                 Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document defines a reformulation of IP and two transport layer
+   protocols (TCP and UDP) as XML applications.
+
+1.   Introduction
+
+1.1. Overview
+
+   This document describes the Binary Lexical Octet Ad-hoc Transport
+   (BLOAT): a reformulation of a widely-deployed network-layer protocol
+   (IP [RFC791]), and two associated transport layer protocols (TCP
+   [RFC793] and UDP [RFC768]) as XML [XML] applications.  It also
+   describes methods for transporting BLOAT over Ethernet and IEEE 802
+   networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+   across the public Internet.
+
+1.2. Motivation
+
+   The wild popularity of XML as a basis for application-level protocols
+   such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+   Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+   investigation into the possibility of extending the use of XML in the
+   protocol stack.  Using XML at both the transport and network layer in
+   addition to the application layer would provide for an amazing amount
+   of power and flexibility while removing dependencies on proprietary
+   and hard-to-understand binary protocols.  This protocol unification
+   would also allow applications to use a single XML parser for all
+   aspects of their operation, eliminating developer time spent figuring
+   out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy                      Informational                      [Page 1]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   parsing to the XML toolset.  The use of XML also mitigates concerns
+   over "network vs. host" byte ordering which is at the root of many
+   network application bugs.
+
+1.3. Relation to Existing Protocols
+
+   The reformulations specified in this RFC follow as closely as
+   possible the spirit of the RFCs on which they are based, and so MAY
+   contain elements or attributes that would not be needed in a pure
+   reworking (e.g. length attributes, which are implicit in XML.)
+
+   The layering of network and transport protocols are maintained in
+   this RFC despite the optimizations that could be made if the line
+   were somewhat blurred (i.e. merging TCP and IP into a single, larger
+   element in the DTD) in order to foster future use of this protocol as
+   a basis for reformulating other protocols (such as ICMP.)
+
+   Other than the encoding, the behavioral aspects of each of the
+   existing protocols remain unchanged.  Routing, address spaces, TCP
+   congestion control, etc. behave as specified in the extant standards.
+   Adapting to new standards and experimental algorithm heuristics for
+   improving performance will become much easier once the move to BLOAT
+   has been completed.
+
+1.4. Requirement Levels
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119
+   [RFC2119].
+
+2.   IPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.
+   IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+   (section 3.) and higher-level application protocols.
+
+   The DTD for this document type can be found in section 7.1.
+
+   The routing of IPoXML can be easily implemented on hosts with an XML
+   parser, as the regular structure lends itself handily to parsing and
+   validation of the document/datagram and then processing the
+   destination address, TTL, and checksum before sending it on to its
+   next-hop.
+
+   The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+   wider deployment of IPv4 and the fact that implementing IPv6 as XML
+   would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy                      Informational                      [Page 2]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+   of RFC 2279 [RFC2279].  All BLOAT document/datagrams MUST be well-
+   formed and include the XMLDecl.
+
+2.1. IP Description
+
+   A number of items have changed (for the better) from the original IP
+   specification.  Bit-masks, where present have been converted into
+   human-readable values.  IP addresses are listed in their dotted-
+   decimal notation [RFC1123].  Length and checksum values are present
+   as decimal integers.
+
+   To calculate the length and checksum fields of the IP element, a
+   canonicalized form of the element MUST be used.  The canonical form
+   SHALL have no whitespace (including newline characters) between
+   elements and only one space character between attributes.  There
+   SHALL NOT be a space following the last attribute in an element.
+
+   An iterative method SHOULD be used to calculate checksums, as the
+   length field will vary based on the size of the checksum.
+
+   The payload element bears special attention.  Due to the character
+   set restrictions of XML, the payload of IP datagrams (which MAY
+   contain arbitrary data) MUST be encoded for transport. This RFC
+   REQUIRES the contents of the payload to be encoded in the base-64
+   encoding of RFC 2045 [RFC2045], but removes the requirement that the
+   encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 3]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+2.2. Example Datagram
+
+   The following is an example IPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   <ip>
+   <header length="474">
+   <version value="4"/>
+   <tos precedence="Routine" delay="Normal" throughput="Normal"
+        relibility="Normal" reserved="0"/>
+   <total.length value="461"/>
+   <id value="1"/>
+   <flags reserved="0" df="dont" mf="last"/>
+   <offset value="0"/>
+   <ttl value="255"/>
+   <protocol value="6"/>
+   <checksum value="8707"/>
+   <source address="10.0.0.22"/>
+   <destination address="10.0.0.1"/>
+   <options>
+   <end copied="0" class="0" number="0"/>
+   </options>
+   <padding pad="0"/>
+   </header>
+   <payload>
+   </payload>
+   </ip>
+
+3.   TCPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+   A number of items have changed from the original TCP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+   To calculate the length and checksum fields of the TCP element, a
+   canonicalized form of the element MUST be used as in section 2.1.
+
+   An iterative method SHOULD be used to calculate checksums as in
+   section 2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy                      Informational                      [Page 4]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   The TCP offset element was expanded to a maximum of 255 from 16 to
+   allow for the increased size of the header in XML.
+
+   TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+   The following is an example TCPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   <tcp>
+   <tcp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <sequence number="322622954"/>
+   <acknowledgement number="689715995"/>
+   <offset number=""/>
+   <reserved value="0"/>
+   <control syn="1" ack="1"/>
+   <window size="1"/>
+   <urgent pointer="0"/>
+   <checksum value="2988"/>
+   <tcp.options>
+   <tcp.end kind="0"/>
+   </tcp.options>
+   <padding pad="0"/>
+   </tcp.header>
+   <payload>
+   </payload>
+   </tcp>
+
+4.   UDPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+   A number of items have changed from the original UDP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 5]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   To calculate the length and checksum fields of the UDP element, a
+   canonicalized form of the element MUST be used as in section 2.1.  An
+   iterative method SHOULD be used to calculate checksums as in section
+   2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+   UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+   The following is an example UDPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   <udp>
+   <udp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <udp.length value="143"/>
+   <checksum value="2988"/>
+   </udp.header>
+   <payload>
+   </payload>
+   </udp>
+
+5.   Network Transport
+
+   This document provides for the transmission of BLOAT datagrams over
+   two common families of physical layer transport.  Future RFCs will
+   address additional transports as routing vendors catch up to the
+   specification, and we begin to see BLOAT routed across the Internet
+   backbone.
+
+5.1. Ethernet
+
+   BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+   exception that the type field of the Ethernet frame MUST contain the
+   value 0xBEEF.  The first 5 octets of the Ethernet frame payload will
+   be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+   BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+   that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy                      Informational                      [Page 6]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+6. Gatewaying over IP
+
+   In order to facilitate the gradual introduction of BLOAT into the
+   public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+   gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+   The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+   Network DTD (7.1.)
+
+   The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+   [XML]) although it is understood that most IPoXML implementations
+   will not need to pull down the DTD, as it will normally be embedded
+   in the implementation, and presents something of a catch-22 if you
+   need to load part of your network protocol over the network.
+
+7.1.  IPoXML DTD
+
+   <!--
+    DTD for IP over XML.
+    Refer to this DTD as:
+
+    <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   -->
+   <!--
+    DTD data types:
+
+      Digits      [0..9]+
+
+      Precedence  "NetworkControl | InternetworkControl |
+                   CRITIC | FlashOverride | Flash | Immediate |
+                   Priority | Routine"
+
+      IP4Addr     "dotted-decimal" notation of [RFC1123]
+
+      Class       [0..3]
+
+      Sec          "Unclassified | Confidential | EFTO | MMMM | PROG |
+                    Restricted | Secret | Top Secret | Reserved"
+
+      Compartments [0..65535]
+
+      Handling     [0..65535]
+
+      TCC          [0..16777216]
+
+   -->
+
+
+
+Kennedy                      Informational                      [Page 7]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ENTITY % Digits "CDATA">
+   <!ENTITY % Precedence "CDATA">
+   <!ENTITY % IP4Addr "CDATA">
+   <!ENTITY % Class "CDATA">
+   <!ENTITY % Sec "CDATA">
+   <!ENTITY % Compartments "CDATA">
+   <!ENTITY % Handling "CDATA">
+   <!ENTITY % TCC "CDATA">
+
+   <!ELEMENT ip (header, payload)>
+
+   <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+                    protocol, checksum, source, destination, options,
+                    padding)>
+   <!-- length of header in 32-bit words -->
+   <!ATTLIST header
+             length %Digits; #REQUIRED>
+
+   <!ELEMENT version EMPTY>
+   <!-- ip version. SHOULD be "4" -->
+   <!ATTLIST version
+             value   %Digits;  #REQUIRED>
+
+   <!ELEMENT tos EMPTY>
+   <!ATTLIST tos
+             precedence   %Precedence;    #REQUIRED
+             delay    (normal | low)  #REQUIRED
+             throughput   (normal | high) #REQUIRED
+             relibility   (normal | high) #REQUIRED
+             reserved     CDATA #FIXED "0">
+
+   <!ELEMENT total.length EMPTY>
+   <!--
+    total length of datagram (header and payload) in octets, MUST be
+    less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+    ethernets).
+   -->
+   <!ATTLIST total.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT id EMPTY>
+   <!-- 0 <= id <= 65,535  -->
+   <!ATTLIST id
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT flags EMPTY>
+   <!-- df = don't fragment, mf = more fragments  -->
+   <!ATTLIST flags
+
+
+
+Kennedy                      Informational                      [Page 8]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+          reserved CDATA  #FIXED "0"
+          df (may|dont)   #REQUIRED
+          mf (last|more)  #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+   <!ATTLIST offset
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT ttl EMPTY>
+   <!-- 0 <= ttl <= 255 -->
+   <!ATTLIST ttl
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT protocol EMPTY>
+   <!-- 0 <= protocol <= 255 (per IANA) -->
+   <!ATTLIST protocol
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT checksum EMPTY>
+   <!-- 0 <= checksum <= 65535 (over header only) -->
+   <!ATTLIST checksum
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT source EMPTY>
+   <!ATTLIST source
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT destination EMPTY>
+   <!ATTLIST destination
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT options ( end | noop | security | loose | strict | record
+                     | stream | timestamp )*>
+
+   <!ELEMENT end EMPTY>
+   <!ATTLIST end
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "0">
+
+   <!ELEMENT noop EMPTY>
+   <!ATTLIST noop
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "1">
+
+   <!ELEMENT security EMPTY>
+
+
+
+Kennedy                      Informational                      [Page 9]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST security
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "2"
+             length CDATA #FIXED "11"
+             security %Sec; #REQUIRED
+             compartments %Compartments; #REQUIRED
+             handling %Handling; #REQUIRED
+             tcc %TCC; #REQUIRED>
+   <!ELEMENT loose (hop)+>
+   <!ATTLIST loose
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "3"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT hop EMPTY>
+   <!ATTLIST hop
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT strict (hop)+>
+   <!ATTLIST strict
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "9"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT record (hop)+>
+   <!ATTLIST record
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "7"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT stream EMPTY>
+   <!-- 0 <= id <= 65,535 -->
+   <!ATTLIST stream
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "8"
+             length CDATA #FIXED "4"
+             id %Digits; #REQUIRED>
+
+   <!ELEMENT timestamp (tstamp)+>
+   <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy                      Informational                     [Page 10]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST timestamp
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "2"
+             number CDATA #FIXED "4"
+             length %Digits;  #REQUIRED
+             pointer %Digits; #REQUIRED
+             oflw %Digits;    #REQUIRED
+             flag (0 | 1 | 3)  #REQUIRED>
+
+   <!ELEMENT tstamp EMPTY>
+   <!ATTLIST tstamp
+             time %Digits;   #REQUIRED
+             address %IP4Addr; #IMPLIED>
+   <!--
+       padding to bring header to 32-bit boundary.
+       pad MUST be "0"*
+    -->
+   <!ELEMENT padding EMPTY>
+   <!ATTLIST padding
+             pad CDATA #REQUIRED>
+
+   <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+        by section 2.1 of this RFC -->
+   <!ELEMENT payload (CDATA)>
+
+7.2.  TCPoXML DTD
+
+   <!--
+      DTD for TCP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   -->
+
+   <!-- the pseudoheader is only included for checksum calculations -->
+   <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+   <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+                         reserved, control, window, checksum, urgent,
+                         tcp.options, padding)>
+
+   <!ELEMENT src EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+   <!ATTLIST src
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT dest EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy                      Informational                     [Page 11]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST dest
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT sequence EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST sequence
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT acknowledgement EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST acknowledgement
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= number <= 255 -->
+   <!ATTLIST offset
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT reserved EMPTY>
+   <!ATTLIST reserved
+             value CDATA #FIXED "0">
+
+   <!ELEMENT control EMPTY>
+   <!ATTLIST control
+             urg (0|1) #IMPLIED
+             ack (0|1) #IMPLIED
+             psh (0|1) #IMPLIED
+             rst (0|1) #IMPLIED
+             syn (0|1) #IMPLIED
+             fin (0|1) #IMPLIED>
+
+   <!ELEMENT window EMPTY>
+   <!-- 0 <= size <= 65,535 -->
+   <!ATTLIST window
+             size %Digits; #REQUIRED>
+
+   <!--
+      checksum as in ip, but with
+      the following pseudo-header added into the tcp element:
+     -->
+   <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+                               tcp.length)>
+
+   <!--
+      tcp header + data length in octets. does not include the size of
+
+      the pseudoheader.
+    -->
+
+
+
+Kennedy                      Informational                     [Page 12]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ELEMENT tcp.length EMPTY>
+   <!ATTLIST tcp.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT urgent EMPTY>
+   <!-- 0 <= pointer <= 65,535 -->
+   <!ATTLIST urgent
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+   <!ELEMENT tcp.end EMPTY>
+   <!ATTLIST tcp.end
+             kind CDATA #FIXED "0">
+
+   <!ELEMENT tcp.noop EMPTY>
+   <!ATTLIST tcp.noop
+             kind CDATA #FIXED "1">
+
+   <!ELEMENT tcp.mss EMPTY>
+   <!ATTLIST tcp.mss
+             kind CDATA #FIXED "2"
+             length CDATA #FIXED "4"
+             size %Digits; #REQUIRED>
+
+7.3.  UDPoXML DTD
+
+   <!--
+      DTD for UDP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   -->
+
+   <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+   <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+   <!ELEMENT udp.pseudoheader (source, destination, protocol,
+                               udp.length)>
+
+   <!--
+      udp header + data length in octets. does not include the size of
+      the pseudoheader.
+    -->
+   <!ELEMENT udp.length EMPTY>
+   <!ATTLIST udp.length
+             value %Digits; #REQUIRED>
+
+
+
+Kennedy                      Informational                     [Page 13]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+8. Security Considerations
+
+   XML, as a subset of SGML, has the same security considerations as
+   specified in SGML Media Types [RFC1874].  Security considerations
+   that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+   not attempt to correct for issues not related to message format.
+
+9.   References
+
+   [JABBER]    Miller, J., "Jabber", draft-miller-jabber-00.txt,
+               February 2002. (Work in Progress)
+
+   [RFC768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+               August 1980.
+
+   [RFC791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
+               September 1981.
+
+   [RFC793]    Postel, J., "Transmission Control Protocol", STD 7, RFC
+               793, September 1981.
+
+   [RFC894]    Hornig, C., "Standard for the Transmission of IP
+               Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+   [RFC1042]   Postel, J. and J. Reynolds, "Standard for the
+               Transmission of IP Datagrams Over IEEE 802 Networks", STD
+               43, RFC 1042, February 1988.
+
+   [RFC1123]   Braden, R., "Requirements for Internet Hosts -
+               Application and Support", RFC 1123, October 1989.
+
+   [RFC1874]   Levinson, E., "SGML Media Types", RFC 1874, December
+               1995.
+
+   [RFC2003]   Perkins, C., "IP Encapsulation within IP", RFC 2003,
+               October 1996.
+
+   [RFC2045]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part One: Format of Internet Message
+               Bodies", RFC 2045, November 1996.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2279]   Yergeau, F., "UTF-8, a transformation format of ISO
+               10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy                      Informational                     [Page 14]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   [RFC2460]   Deering, S. and R. Hinden, "Internet Protocol, Version 6
+               (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC3080]   Rose, M., "The Blocks Extensible Exchange Protocol Core",
+               RFC 3080, March 2001.
+
+   [SOAP]      Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+               Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+               "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+               Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+   [XML]       Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+               Markup Language (XML)" World Wide Web Consortium
+               Recommendation REC- xml-19980210.
+               http://www.w3.org/TR/1998/REC-xml-19980210
+
+10.  Author's Address
+
+   Hugh Kennedy
+   Mimezine
+   1060 West Addison
+   Chicago, IL 60613
+   USA
+
+   EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 15]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 16]
+
+
+
+
+
+
+
+Network Working Group                                         H. Kennedy
+Request for Comments: 3252                                      Mimezine
+Category: Informational                                     1 April 2002
+
+
+                 Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document defines a reformulation of IP and two transport layer
+   protocols (TCP and UDP) as XML applications.
+
+1.   Introduction
+
+1.1. Overview
+
+   This document describes the Binary Lexical Octet Ad-hoc Transport
+   (BLOAT): a reformulation of a widely-deployed network-layer protocol
+   (IP [RFC791]), and two associated transport layer protocols (TCP
+   [RFC793] and UDP [RFC768]) as XML [XML] applications.  It also
+   describes methods for transporting BLOAT over Ethernet and IEEE 802
+   networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+   across the public Internet.
+
+1.2. Motivation
+
+   The wild popularity of XML as a basis for application-level protocols
+   such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+   Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+   investigation into the possibility of extending the use of XML in the
+   protocol stack.  Using XML at both the transport and network layer in
+   addition to the application layer would provide for an amazing amount
+   of power and flexibility while removing dependencies on proprietary
+   and hard-to-understand binary protocols.  This protocol unification
+   would also allow applications to use a single XML parser for all
+   aspects of their operation, eliminating developer time spent figuring
+   out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy                      Informational                      [Page 1]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   parsing to the XML toolset.  The use of XML also mitigates concerns
+   over "network vs. host" byte ordering which is at the root of many
+   network application bugs.
+
+1.3. Relation to Existing Protocols
+
+   The reformulations specified in this RFC follow as closely as
+   possible the spirit of the RFCs on which they are based, and so MAY
+   contain elements or attributes that would not be needed in a pure
+   reworking (e.g. length attributes, which are implicit in XML.)
+
+   The layering of network and transport protocols are maintained in
+   this RFC despite the optimizations that could be made if the line
+   were somewhat blurred (i.e. merging TCP and IP into a single, larger
+   element in the DTD) in order to foster future use of this protocol as
+   a basis for reformulating other protocols (such as ICMP.)
+
+   Other than the encoding, the behavioral aspects of each of the
+   existing protocols remain unchanged.  Routing, address spaces, TCP
+   congestion control, etc. behave as specified in the extant standards.
+   Adapting to new standards and experimental algorithm heuristics for
+   improving performance will become much easier once the move to BLOAT
+   has been completed.
+
+1.4. Requirement Levels
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119
+   [RFC2119].
+
+2.   IPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.
+   IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+   (section 3.) and higher-level application protocols.
+
+   The DTD for this document type can be found in section 7.1.
+
+   The routing of IPoXML can be easily implemented on hosts with an XML
+   parser, as the regular structure lends itself handily to parsing and
+   validation of the document/datagram and then processing the
+   destination address, TTL, and checksum before sending it on to its
+   next-hop.
+
+   The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+   wider deployment of IPv4 and the fact that implementing IPv6 as XML
+   would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy                      Informational                      [Page 2]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+   of RFC 2279 [RFC2279].  All BLOAT document/datagrams MUST be well-
+   formed and include the XMLDecl.
+
+2.1. IP Description
+
+   A number of items have changed (for the better) from the original IP
+   specification.  Bit-masks, where present have been converted into
+   human-readable values.  IP addresses are listed in their dotted-
+   decimal notation [RFC1123].  Length and checksum values are present
+   as decimal integers.
+
+   To calculate the length and checksum fields of the IP element, a
+   canonicalized form of the element MUST be used.  The canonical form
+   SHALL have no whitespace (including newline characters) between
+   elements and only one space character between attributes.  There
+   SHALL NOT be a space following the last attribute in an element.
+
+   An iterative method SHOULD be used to calculate checksums, as the
+   length field will vary based on the size of the checksum.
+
+   The payload element bears special attention.  Due to the character
+   set restrictions of XML, the payload of IP datagrams (which MAY
+   contain arbitrary data) MUST be encoded for transport. This RFC
+   REQUIRES the contents of the payload to be encoded in the base-64
+   encoding of RFC 2045 [RFC2045], but removes the requirement that the
+   encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 3]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+2.2. Example Datagram
+
+   The following is an example IPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   <ip>
+   <header length="474">
+   <version value="4"/>
+   <tos precedence="Routine" delay="Normal" throughput="Normal"
+        relibility="Normal" reserved="0"/>
+   <total.length value="461"/>
+   <id value="1"/>
+   <flags reserved="0" df="dont" mf="last"/>
+   <offset value="0"/>
+   <ttl value="255"/>
+   <protocol value="6"/>
+   <checksum value="8707"/>
+   <source address="10.0.0.22"/>
+   <destination address="10.0.0.1"/>
+   <options>
+   <end copied="0" class="0" number="0"/>
+   </options>
+   <padding pad="0"/>
+   </header>
+   <payload>
+   </payload>
+   </ip>
+
+3.   TCPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+   A number of items have changed from the original TCP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+   To calculate the length and checksum fields of the TCP element, a
+   canonicalized form of the element MUST be used as in section 2.1.
+
+   An iterative method SHOULD be used to calculate checksums as in
+   section 2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy                      Informational                      [Page 4]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   The TCP offset element was expanded to a maximum of 255 from 16 to
+   allow for the increased size of the header in XML.
+
+   TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+   The following is an example TCPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   <tcp>
+   <tcp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <sequence number="322622954"/>
+   <acknowledgement number="689715995"/>
+   <offset number=""/>
+   <reserved value="0"/>
+   <control syn="1" ack="1"/>
+   <window size="1"/>
+   <urgent pointer="0"/>
+   <checksum value="2988"/>
+   <tcp.options>
+   <tcp.end kind="0"/>
+   </tcp.options>
+   <padding pad="0"/>
+   </tcp.header>
+   <payload>
+   </payload>
+   </tcp>
+
+4.   UDPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+   A number of items have changed from the original UDP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 5]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   To calculate the length and checksum fields of the UDP element, a
+   canonicalized form of the element MUST be used as in section 2.1.  An
+   iterative method SHOULD be used to calculate checksums as in section
+   2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+   UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+   The following is an example UDPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   <udp>
+   <udp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <udp.length value="143"/>
+   <checksum value="2988"/>
+   </udp.header>
+   <payload>
+   </payload>
+   </udp>
+
+5.   Network Transport
+
+   This document provides for the transmission of BLOAT datagrams over
+   two common families of physical layer transport.  Future RFCs will
+   address additional transports as routing vendors catch up to the
+   specification, and we begin to see BLOAT routed across the Internet
+   backbone.
+
+5.1. Ethernet
+
+   BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+   exception that the type field of the Ethernet frame MUST contain the
+   value 0xBEEF.  The first 5 octets of the Ethernet frame payload will
+   be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+   BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+   that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy                      Informational                      [Page 6]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+6. Gatewaying over IP
+
+   In order to facilitate the gradual introduction of BLOAT into the
+   public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+   gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+   The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+   Network DTD (7.1.)
+
+   The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+   [XML]) although it is understood that most IPoXML implementations
+   will not need to pull down the DTD, as it will normally be embedded
+   in the implementation, and presents something of a catch-22 if you
+   need to load part of your network protocol over the network.
+
+7.1.  IPoXML DTD
+
+   <!--
+    DTD for IP over XML.
+    Refer to this DTD as:
+
+    <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   -->
+   <!--
+    DTD data types:
+
+      Digits      [0..9]+
+
+      Precedence  "NetworkControl | InternetworkControl |
+                   CRITIC | FlashOverride | Flash | Immediate |
+                   Priority | Routine"
+
+      IP4Addr     "dotted-decimal" notation of [RFC1123]
+
+      Class       [0..3]
+
+      Sec          "Unclassified | Confidential | EFTO | MMMM | PROG |
+                    Restricted | Secret | Top Secret | Reserved"
+
+      Compartments [0..65535]
+
+      Handling     [0..65535]
+
+      TCC          [0..16777216]
+
+   -->
+
+
+
+Kennedy                      Informational                      [Page 7]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ENTITY % Digits "CDATA">
+   <!ENTITY % Precedence "CDATA">
+   <!ENTITY % IP4Addr "CDATA">
+   <!ENTITY % Class "CDATA">
+   <!ENTITY % Sec "CDATA">
+   <!ENTITY % Compartments "CDATA">
+   <!ENTITY % Handling "CDATA">
+   <!ENTITY % TCC "CDATA">
+
+   <!ELEMENT ip (header, payload)>
+
+   <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+                    protocol, checksum, source, destination, options,
+                    padding)>
+   <!-- length of header in 32-bit words -->
+   <!ATTLIST header
+             length %Digits; #REQUIRED>
+
+   <!ELEMENT version EMPTY>
+   <!-- ip version. SHOULD be "4" -->
+   <!ATTLIST version
+             value   %Digits;  #REQUIRED>
+
+   <!ELEMENT tos EMPTY>
+   <!ATTLIST tos
+             precedence   %Precedence;    #REQUIRED
+             delay    (normal | low)  #REQUIRED
+             throughput   (normal | high) #REQUIRED
+             relibility   (normal | high) #REQUIRED
+             reserved     CDATA #FIXED "0">
+
+   <!ELEMENT total.length EMPTY>
+   <!--
+    total length of datagram (header and payload) in octets, MUST be
+    less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+    ethernets).
+   -->
+   <!ATTLIST total.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT id EMPTY>
+   <!-- 0 <= id <= 65,535  -->
+   <!ATTLIST id
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT flags EMPTY>
+   <!-- df = don't fragment, mf = more fragments  -->
+   <!ATTLIST flags
+
+
+
+Kennedy                      Informational                      [Page 8]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+          reserved CDATA  #FIXED "0"
+          df (may|dont)   #REQUIRED
+          mf (last|more)  #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+   <!ATTLIST offset
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT ttl EMPTY>
+   <!-- 0 <= ttl <= 255 -->
+   <!ATTLIST ttl
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT protocol EMPTY>
+   <!-- 0 <= protocol <= 255 (per IANA) -->
+   <!ATTLIST protocol
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT checksum EMPTY>
+   <!-- 0 <= checksum <= 65535 (over header only) -->
+   <!ATTLIST checksum
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT source EMPTY>
+   <!ATTLIST source
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT destination EMPTY>
+   <!ATTLIST destination
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT options ( end | noop | security | loose | strict | record
+                     | stream | timestamp )*>
+
+   <!ELEMENT end EMPTY>
+   <!ATTLIST end
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "0">
+
+   <!ELEMENT noop EMPTY>
+   <!ATTLIST noop
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "1">
+
+   <!ELEMENT security EMPTY>
+
+
+
+Kennedy                      Informational                      [Page 9]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST security
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "2"
+             length CDATA #FIXED "11"
+             security %Sec; #REQUIRED
+             compartments %Compartments; #REQUIRED
+             handling %Handling; #REQUIRED
+             tcc %TCC; #REQUIRED>
+   <!ELEMENT loose (hop)+>
+   <!ATTLIST loose
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "3"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT hop EMPTY>
+   <!ATTLIST hop
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT strict (hop)+>
+   <!ATTLIST strict
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "9"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT record (hop)+>
+   <!ATTLIST record
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "7"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT stream EMPTY>
+   <!-- 0 <= id <= 65,535 -->
+   <!ATTLIST stream
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "8"
+             length CDATA #FIXED "4"
+             id %Digits; #REQUIRED>
+
+   <!ELEMENT timestamp (tstamp)+>
+   <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy                      Informational                     [Page 10]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST timestamp
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "2"
+             number CDATA #FIXED "4"
+             length %Digits;  #REQUIRED
+             pointer %Digits; #REQUIRED
+             oflw %Digits;    #REQUIRED
+             flag (0 | 1 | 3)  #REQUIRED>
+
+   <!ELEMENT tstamp EMPTY>
+   <!ATTLIST tstamp
+             time %Digits;   #REQUIRED
+             address %IP4Addr; #IMPLIED>
+   <!--
+       padding to bring header to 32-bit boundary.
+       pad MUST be "0"*
+    -->
+   <!ELEMENT padding EMPTY>
+   <!ATTLIST padding
+             pad CDATA #REQUIRED>
+
+   <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+        by section 2.1 of this RFC -->
+   <!ELEMENT payload (CDATA)>
+
+7.2.  TCPoXML DTD
+
+   <!--
+      DTD for TCP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   -->
+
+   <!-- the pseudoheader is only included for checksum calculations -->
+   <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+   <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+                         reserved, control, window, checksum, urgent,
+                         tcp.options, padding)>
+
+   <!ELEMENT src EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+   <!ATTLIST src
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT dest EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy                      Informational                     [Page 11]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST dest
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT sequence EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST sequence
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT acknowledgement EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST acknowledgement
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= number <= 255 -->
+   <!ATTLIST offset
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT reserved EMPTY>
+   <!ATTLIST reserved
+             value CDATA #FIXED "0">
+
+   <!ELEMENT control EMPTY>
+   <!ATTLIST control
+             urg (0|1) #IMPLIED
+             ack (0|1) #IMPLIED
+             psh (0|1) #IMPLIED
+             rst (0|1) #IMPLIED
+             syn (0|1) #IMPLIED
+             fin (0|1) #IMPLIED>
+
+   <!ELEMENT window EMPTY>
+   <!-- 0 <= size <= 65,535 -->
+   <!ATTLIST window
+             size %Digits; #REQUIRED>
+
+   <!--
+      checksum as in ip, but with
+      the following pseudo-header added into the tcp element:
+     -->
+   <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+                               tcp.length)>
+
+   <!--
+      tcp header + data length in octets. does not include the size of
+
+      the pseudoheader.
+    -->
+
+
+
+Kennedy                      Informational                     [Page 12]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ELEMENT tcp.length EMPTY>
+   <!ATTLIST tcp.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT urgent EMPTY>
+   <!-- 0 <= pointer <= 65,535 -->
+   <!ATTLIST urgent
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+   <!ELEMENT tcp.end EMPTY>
+   <!ATTLIST tcp.end
+             kind CDATA #FIXED "0">
+
+   <!ELEMENT tcp.noop EMPTY>
+   <!ATTLIST tcp.noop
+             kind CDATA #FIXED "1">
+
+   <!ELEMENT tcp.mss EMPTY>
+   <!ATTLIST tcp.mss
+             kind CDATA #FIXED "2"
+             length CDATA #FIXED "4"
+             size %Digits; #REQUIRED>
+
+7.3.  UDPoXML DTD
+
+   <!--
+      DTD for UDP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   -->
+
+   <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+   <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+   <!ELEMENT udp.pseudoheader (source, destination, protocol,
+                               udp.length)>
+
+   <!--
+      udp header + data length in octets. does not include the size of
+      the pseudoheader.
+    -->
+   <!ELEMENT udp.length EMPTY>
+   <!ATTLIST udp.length
+             value %Digits; #REQUIRED>
+
+
+
+Kennedy                      Informational                     [Page 13]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+8. Security Considerations
+
+   XML, as a subset of SGML, has the same security considerations as
+   specified in SGML Media Types [RFC1874].  Security considerations
+   that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+   not attempt to correct for issues not related to message format.
+
+9.   References
+
+   [JABBER]    Miller, J., "Jabber", draft-miller-jabber-00.txt,
+               February 2002. (Work in Progress)
+
+   [RFC768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+               August 1980.
+
+   [RFC791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
+               September 1981.
+
+   [RFC793]    Postel, J., "Transmission Control Protocol", STD 7, RFC
+               793, September 1981.
+
+   [RFC894]    Hornig, C., "Standard for the Transmission of IP
+               Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+   [RFC1042]   Postel, J. and J. Reynolds, "Standard for the
+               Transmission of IP Datagrams Over IEEE 802 Networks", STD
+               43, RFC 1042, February 1988.
+
+   [RFC1123]   Braden, R., "Requirements for Internet Hosts -
+               Application and Support", RFC 1123, October 1989.
+
+   [RFC1874]   Levinson, E., "SGML Media Types", RFC 1874, December
+               1995.
+
+   [RFC2003]   Perkins, C., "IP Encapsulation within IP", RFC 2003,
+               October 1996.
+
+   [RFC2045]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part One: Format of Internet Message
+               Bodies", RFC 2045, November 1996.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2279]   Yergeau, F., "UTF-8, a transformation format of ISO
+               10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy                      Informational                     [Page 14]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   [RFC2460]   Deering, S. and R. Hinden, "Internet Protocol, Version 6
+               (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC3080]   Rose, M., "The Blocks Extensible Exchange Protocol Core",
+               RFC 3080, March 2001.
+
+   [SOAP]      Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+               Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+               "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+               Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+   [XML]       Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+               Markup Language (XML)" World Wide Web Consortium
+               Recommendation REC- xml-19980210.
+               http://www.w3.org/TR/1998/REC-xml-19980210
+
+10.  Author's Address
+
+   Hugh Kennedy
+   Mimezine
+   1060 West Addison
+   Chicago, IL 60613
+   USA
+
+   EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 15]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 16]
+
+
+
+
+
+
+
+Network Working Group                                         H. Kennedy
+Request for Comments: 3252                                      Mimezine
+Category: Informational                                     1 April 2002
+
+
+                 Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document defines a reformulation of IP and two transport layer
+   protocols (TCP and UDP) as XML applications.
+
+1.   Introduction
+
+1.1. Overview
+
+   This document describes the Binary Lexical Octet Ad-hoc Transport
+   (BLOAT): a reformulation of a widely-deployed network-layer protocol
+   (IP [RFC791]), and two associated transport layer protocols (TCP
+   [RFC793] and UDP [RFC768]) as XML [XML] applications.  It also
+   describes methods for transporting BLOAT over Ethernet and IEEE 802
+   networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+   across the public Internet.
+
+1.2. Motivation
+
+   The wild popularity of XML as a basis for application-level protocols
+   such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+   Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+   investigation into the possibility of extending the use of XML in the
+   protocol stack.  Using XML at both the transport and network layer in
+   addition to the application layer would provide for an amazing amount
+   of power and flexibility while removing dependencies on proprietary
+   and hard-to-understand binary protocols.  This protocol unification
+   would also allow applications to use a single XML parser for all
+   aspects of their operation, eliminating developer time spent figuring
+   out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy                      Informational                      [Page 1]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   parsing to the XML toolset.  The use of XML also mitigates concerns
+   over "network vs. host" byte ordering which is at the root of many
+   network application bugs.
+
+1.3. Relation to Existing Protocols
+
+   The reformulations specified in this RFC follow as closely as
+   possible the spirit of the RFCs on which they are based, and so MAY
+   contain elements or attributes that would not be needed in a pure
+   reworking (e.g. length attributes, which are implicit in XML.)
+
+   The layering of network and transport protocols are maintained in
+   this RFC despite the optimizations that could be made if the line
+   were somewhat blurred (i.e. merging TCP and IP into a single, larger
+   element in the DTD) in order to foster future use of this protocol as
+   a basis for reformulating other protocols (such as ICMP.)
+
+   Other than the encoding, the behavioral aspects of each of the
+   existing protocols remain unchanged.  Routing, address spaces, TCP
+   congestion control, etc. behave as specified in the extant standards.
+   Adapting to new standards and experimental algorithm heuristics for
+   improving performance will become much easier once the move to BLOAT
+   has been completed.
+
+1.4. Requirement Levels
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119
+   [RFC2119].
+
+2.   IPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.
+   IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+   (section 3.) and higher-level application protocols.
+
+   The DTD for this document type can be found in section 7.1.
+
+   The routing of IPoXML can be easily implemented on hosts with an XML
+   parser, as the regular structure lends itself handily to parsing and
+   validation of the document/datagram and then processing the
+   destination address, TTL, and checksum before sending it on to its
+   next-hop.
+
+   The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+   wider deployment of IPv4 and the fact that implementing IPv6 as XML
+   would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy                      Informational                      [Page 2]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+   of RFC 2279 [RFC2279].  All BLOAT document/datagrams MUST be well-
+   formed and include the XMLDecl.
+
+2.1. IP Description
+
+   A number of items have changed (for the better) from the original IP
+   specification.  Bit-masks, where present have been converted into
+   human-readable values.  IP addresses are listed in their dotted-
+   decimal notation [RFC1123].  Length and checksum values are present
+   as decimal integers.
+
+   To calculate the length and checksum fields of the IP element, a
+   canonicalized form of the element MUST be used.  The canonical form
+   SHALL have no whitespace (including newline characters) between
+   elements and only one space character between attributes.  There
+   SHALL NOT be a space following the last attribute in an element.
+
+   An iterative method SHOULD be used to calculate checksums, as the
+   length field will vary based on the size of the checksum.
+
+   The payload element bears special attention.  Due to the character
+   set restrictions of XML, the payload of IP datagrams (which MAY
+   contain arbitrary data) MUST be encoded for transport. This RFC
+   REQUIRES the contents of the payload to be encoded in the base-64
+   encoding of RFC 2045 [RFC2045], but removes the requirement that the
+   encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 3]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+2.2. Example Datagram
+
+   The following is an example IPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   <ip>
+   <header length="474">
+   <version value="4"/>
+   <tos precedence="Routine" delay="Normal" throughput="Normal"
+        relibility="Normal" reserved="0"/>
+   <total.length value="461"/>
+   <id value="1"/>
+   <flags reserved="0" df="dont" mf="last"/>
+   <offset value="0"/>
+   <ttl value="255"/>
+   <protocol value="6"/>
+   <checksum value="8707"/>
+   <source address="10.0.0.22"/>
+   <destination address="10.0.0.1"/>
+   <options>
+   <end copied="0" class="0" number="0"/>
+   </options>
+   <padding pad="0"/>
+   </header>
+   <payload>
+   </payload>
+   </ip>
+
+3.   TCPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+   A number of items have changed from the original TCP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+   To calculate the length and checksum fields of the TCP element, a
+   canonicalized form of the element MUST be used as in section 2.1.
+
+   An iterative method SHOULD be used to calculate checksums as in
+   section 2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy                      Informational                      [Page 4]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   The TCP offset element was expanded to a maximum of 255 from 16 to
+   allow for the increased size of the header in XML.
+
+   TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+   The following is an example TCPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   <tcp>
+   <tcp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <sequence number="322622954"/>
+   <acknowledgement number="689715995"/>
+   <offset number=""/>
+   <reserved value="0"/>
+   <control syn="1" ack="1"/>
+   <window size="1"/>
+   <urgent pointer="0"/>
+   <checksum value="2988"/>
+   <tcp.options>
+   <tcp.end kind="0"/>
+   </tcp.options>
+   <padding pad="0"/>
+   </tcp.header>
+   <payload>
+   </payload>
+   </tcp>
+
+4.   UDPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+   A number of items have changed from the original UDP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 5]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   To calculate the length and checksum fields of the UDP element, a
+   canonicalized form of the element MUST be used as in section 2.1.  An
+   iterative method SHOULD be used to calculate checksums as in section
+   2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+   UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+   The following is an example UDPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   <udp>
+   <udp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <udp.length value="143"/>
+   <checksum value="2988"/>
+   </udp.header>
+   <payload>
+   </payload>
+   </udp>
+
+5.   Network Transport
+
+   This document provides for the transmission of BLOAT datagrams over
+   two common families of physical layer transport.  Future RFCs will
+   address additional transports as routing vendors catch up to the
+   specification, and we begin to see BLOAT routed across the Internet
+   backbone.
+
+5.1. Ethernet
+
+   BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+   exception that the type field of the Ethernet frame MUST contain the
+   value 0xBEEF.  The first 5 octets of the Ethernet frame payload will
+   be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+   BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+   that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy                      Informational                      [Page 6]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+6. Gatewaying over IP
+
+   In order to facilitate the gradual introduction of BLOAT into the
+   public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+   gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+   The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+   Network DTD (7.1.)
+
+   The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+   [XML]) although it is understood that most IPoXML implementations
+   will not need to pull down the DTD, as it will normally be embedded
+   in the implementation, and presents something of a catch-22 if you
+   need to load part of your network protocol over the network.
+
+7.1.  IPoXML DTD
+
+   <!--
+    DTD for IP over XML.
+    Refer to this DTD as:
+
+    <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   -->
+   <!--
+    DTD data types:
+
+      Digits      [0..9]+
+
+      Precedence  "NetworkControl | InternetworkControl |
+                   CRITIC | FlashOverride | Flash | Immediate |
+                   Priority | Routine"
+
+      IP4Addr     "dotted-decimal" notation of [RFC1123]
+
+      Class       [0..3]
+
+      Sec          "Unclassified | Confidential | EFTO | MMMM | PROG |
+                    Restricted | Secret | Top Secret | Reserved"
+
+      Compartments [0..65535]
+
+      Handling     [0..65535]
+
+      TCC          [0..16777216]
+
+   -->
+
+
+
+Kennedy                      Informational                      [Page 7]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ENTITY % Digits "CDATA">
+   <!ENTITY % Precedence "CDATA">
+   <!ENTITY % IP4Addr "CDATA">
+   <!ENTITY % Class "CDATA">
+   <!ENTITY % Sec "CDATA">
+   <!ENTITY % Compartments "CDATA">
+   <!ENTITY % Handling "CDATA">
+   <!ENTITY % TCC "CDATA">
+
+   <!ELEMENT ip (header, payload)>
+
+   <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+                    protocol, checksum, source, destination, options,
+                    padding)>
+   <!-- length of header in 32-bit words -->
+   <!ATTLIST header
+             length %Digits; #REQUIRED>
+
+   <!ELEMENT version EMPTY>
+   <!-- ip version. SHOULD be "4" -->
+   <!ATTLIST version
+             value   %Digits;  #REQUIRED>
+
+   <!ELEMENT tos EMPTY>
+   <!ATTLIST tos
+             precedence   %Precedence;    #REQUIRED
+             delay    (normal | low)  #REQUIRED
+             throughput   (normal | high) #REQUIRED
+             relibility   (normal | high) #REQUIRED
+             reserved     CDATA #FIXED "0">
+
+   <!ELEMENT total.length EMPTY>
+   <!--
+    total length of datagram (header and payload) in octets, MUST be
+    less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+    ethernets).
+   -->
+   <!ATTLIST total.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT id EMPTY>
+   <!-- 0 <= id <= 65,535  -->
+   <!ATTLIST id
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT flags EMPTY>
+   <!-- df = don't fragment, mf = more fragments  -->
+   <!ATTLIST flags
+
+
+
+Kennedy                      Informational                      [Page 8]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+          reserved CDATA  #FIXED "0"
+          df (may|dont)   #REQUIRED
+          mf (last|more)  #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+   <!ATTLIST offset
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT ttl EMPTY>
+   <!-- 0 <= ttl <= 255 -->
+   <!ATTLIST ttl
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT protocol EMPTY>
+   <!-- 0 <= protocol <= 255 (per IANA) -->
+   <!ATTLIST protocol
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT checksum EMPTY>
+   <!-- 0 <= checksum <= 65535 (over header only) -->
+   <!ATTLIST checksum
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT source EMPTY>
+   <!ATTLIST source
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT destination EMPTY>
+   <!ATTLIST destination
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT options ( end | noop | security | loose | strict | record
+                     | stream | timestamp )*>
+
+   <!ELEMENT end EMPTY>
+   <!ATTLIST end
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "0">
+
+   <!ELEMENT noop EMPTY>
+   <!ATTLIST noop
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "1">
+
+   <!ELEMENT security EMPTY>
+
+
+
+Kennedy                      Informational                      [Page 9]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST security
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "2"
+             length CDATA #FIXED "11"
+             security %Sec; #REQUIRED
+             compartments %Compartments; #REQUIRED
+             handling %Handling; #REQUIRED
+             tcc %TCC; #REQUIRED>
+   <!ELEMENT loose (hop)+>
+   <!ATTLIST loose
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "3"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT hop EMPTY>
+   <!ATTLIST hop
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT strict (hop)+>
+   <!ATTLIST strict
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "9"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT record (hop)+>
+   <!ATTLIST record
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "7"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT stream EMPTY>
+   <!-- 0 <= id <= 65,535 -->
+   <!ATTLIST stream
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "8"
+             length CDATA #FIXED "4"
+             id %Digits; #REQUIRED>
+
+   <!ELEMENT timestamp (tstamp)+>
+   <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy                      Informational                     [Page 10]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST timestamp
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "2"
+             number CDATA #FIXED "4"
+             length %Digits;  #REQUIRED
+             pointer %Digits; #REQUIRED
+             oflw %Digits;    #REQUIRED
+             flag (0 | 1 | 3)  #REQUIRED>
+
+   <!ELEMENT tstamp EMPTY>
+   <!ATTLIST tstamp
+             time %Digits;   #REQUIRED
+             address %IP4Addr; #IMPLIED>
+   <!--
+       padding to bring header to 32-bit boundary.
+       pad MUST be "0"*
+    -->
+   <!ELEMENT padding EMPTY>
+   <!ATTLIST padding
+             pad CDATA #REQUIRED>
+
+   <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+        by section 2.1 of this RFC -->
+   <!ELEMENT payload (CDATA)>
+
+7.2.  TCPoXML DTD
+
+   <!--
+      DTD for TCP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   -->
+
+   <!-- the pseudoheader is only included for checksum calculations -->
+   <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+   <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+                         reserved, control, window, checksum, urgent,
+                         tcp.options, padding)>
+
+   <!ELEMENT src EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+   <!ATTLIST src
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT dest EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy                      Informational                     [Page 11]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST dest
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT sequence EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST sequence
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT acknowledgement EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST acknowledgement
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= number <= 255 -->
+   <!ATTLIST offset
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT reserved EMPTY>
+   <!ATTLIST reserved
+             value CDATA #FIXED "0">
+
+   <!ELEMENT control EMPTY>
+   <!ATTLIST control
+             urg (0|1) #IMPLIED
+             ack (0|1) #IMPLIED
+             psh (0|1) #IMPLIED
+             rst (0|1) #IMPLIED
+             syn (0|1) #IMPLIED
+             fin (0|1) #IMPLIED>
+
+   <!ELEMENT window EMPTY>
+   <!-- 0 <= size <= 65,535 -->
+   <!ATTLIST window
+             size %Digits; #REQUIRED>
+
+   <!--
+      checksum as in ip, but with
+      the following pseudo-header added into the tcp element:
+     -->
+   <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+                               tcp.length)>
+
+   <!--
+      tcp header + data length in octets. does not include the size of
+
+      the pseudoheader.
+    -->
+
+
+
+Kennedy                      Informational                     [Page 12]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ELEMENT tcp.length EMPTY>
+   <!ATTLIST tcp.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT urgent EMPTY>
+   <!-- 0 <= pointer <= 65,535 -->
+   <!ATTLIST urgent
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+   <!ELEMENT tcp.end EMPTY>
+   <!ATTLIST tcp.end
+             kind CDATA #FIXED "0">
+
+   <!ELEMENT tcp.noop EMPTY>
+   <!ATTLIST tcp.noop
+             kind CDATA #FIXED "1">
+
+   <!ELEMENT tcp.mss EMPTY>
+   <!ATTLIST tcp.mss
+             kind CDATA #FIXED "2"
+             length CDATA #FIXED "4"
+             size %Digits; #REQUIRED>
+
+7.3.  UDPoXML DTD
+
+   <!--
+      DTD for UDP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   -->
+
+   <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+   <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+   <!ELEMENT udp.pseudoheader (source, destination, protocol,
+                               udp.length)>
+
+   <!--
+      udp header + data length in octets. does not include the size of
+      the pseudoheader.
+    -->
+   <!ELEMENT udp.length EMPTY>
+   <!ATTLIST udp.length
+             value %Digits; #REQUIRED>
+
+
+
+Kennedy                      Informational                     [Page 13]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+8. Security Considerations
+
+   XML, as a subset of SGML, has the same security considerations as
+   specified in SGML Media Types [RFC1874].  Security considerations
+   that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+   not attempt to correct for issues not related to message format.
+
+9.   References
+
+   [JABBER]    Miller, J., "Jabber", draft-miller-jabber-00.txt,
+               February 2002. (Work in Progress)
+
+   [RFC768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+               August 1980.
+
+   [RFC791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
+               September 1981.
+
+   [RFC793]    Postel, J., "Transmission Control Protocol", STD 7, RFC
+               793, September 1981.
+
+   [RFC894]    Hornig, C., "Standard for the Transmission of IP
+               Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+   [RFC1042]   Postel, J. and J. Reynolds, "Standard for the
+               Transmission of IP Datagrams Over IEEE 802 Networks", STD
+               43, RFC 1042, February 1988.
+
+   [RFC1123]   Braden, R., "Requirements for Internet Hosts -
+               Application and Support", RFC 1123, October 1989.
+
+   [RFC1874]   Levinson, E., "SGML Media Types", RFC 1874, December
+               1995.
+
+   [RFC2003]   Perkins, C., "IP Encapsulation within IP", RFC 2003,
+               October 1996.
+
+   [RFC2045]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part One: Format of Internet Message
+               Bodies", RFC 2045, November 1996.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2279]   Yergeau, F., "UTF-8, a transformation format of ISO
+               10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy                      Informational                     [Page 14]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   [RFC2460]   Deering, S. and R. Hinden, "Internet Protocol, Version 6
+               (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC3080]   Rose, M., "The Blocks Extensible Exchange Protocol Core",
+               RFC 3080, March 2001.
+
+   [SOAP]      Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+               Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+               "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+               Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+   [XML]       Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+               Markup Language (XML)" World Wide Web Consortium
+               Recommendation REC- xml-19980210.
+               http://www.w3.org/TR/1998/REC-xml-19980210
+
+10.  Author's Address
+
+   Hugh Kennedy
+   Mimezine
+   1060 West Addison
+   Chicago, IL 60613
+   USA
+
+   EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 15]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 16]
+
+
+
+
+
+
+
+Network Working Group                                         H. Kennedy
+Request for Comments: 3252                                      Mimezine
+Category: Informational                                     1 April 2002
+
+
+                 Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document defines a reformulation of IP and two transport layer
+   protocols (TCP and UDP) as XML applications.
+
+1.   Introduction
+
+1.1. Overview
+
+   This document describes the Binary Lexical Octet Ad-hoc Transport
+   (BLOAT): a reformulation of a widely-deployed network-layer protocol
+   (IP [RFC791]), and two associated transport layer protocols (TCP
+   [RFC793] and UDP [RFC768]) as XML [XML] applications.  It also
+   describes methods for transporting BLOAT over Ethernet and IEEE 802
+   networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+   across the public Internet.
+
+1.2. Motivation
+
+   The wild popularity of XML as a basis for application-level protocols
+   such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+   Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+   investigation into the possibility of extending the use of XML in the
+   protocol stack.  Using XML at both the transport and network layer in
+   addition to the application layer would provide for an amazing amount
+   of power and flexibility while removing dependencies on proprietary
+   and hard-to-understand binary protocols.  This protocol unification
+   would also allow applications to use a single XML parser for all
+   aspects of their operation, eliminating developer time spent figuring
+   out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy                      Informational                      [Page 1]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   parsing to the XML toolset.  The use of XML also mitigates concerns
+   over "network vs. host" byte ordering which is at the root of many
+   network application bugs.
+
+1.3. Relation to Existing Protocols
+
+   The reformulations specified in this RFC follow as closely as
+   possible the spirit of the RFCs on which they are based, and so MAY
+   contain elements or attributes that would not be needed in a pure
+   reworking (e.g. length attributes, which are implicit in XML.)
+
+   The layering of network and transport protocols are maintained in
+   this RFC despite the optimizations that could be made if the line
+   were somewhat blurred (i.e. merging TCP and IP into a single, larger
+   element in the DTD) in order to foster future use of this protocol as
+   a basis for reformulating other protocols (such as ICMP.)
+
+   Other than the encoding, the behavioral aspects of each of the
+   existing protocols remain unchanged.  Routing, address spaces, TCP
+   congestion control, etc. behave as specified in the extant standards.
+   Adapting to new standards and experimental algorithm heuristics for
+   improving performance will become much easier once the move to BLOAT
+   has been completed.
+
+1.4. Requirement Levels
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119
+   [RFC2119].
+
+2.   IPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.
+   IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+   (section 3.) and higher-level application protocols.
+
+   The DTD for this document type can be found in section 7.1.
+
+   The routing of IPoXML can be easily implemented on hosts with an XML
+   parser, as the regular structure lends itself handily to parsing and
+   validation of the document/datagram and then processing the
+   destination address, TTL, and checksum before sending it on to its
+   next-hop.
+
+   The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+   wider deployment of IPv4 and the fact that implementing IPv6 as XML
+   would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy                      Informational                      [Page 2]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+   of RFC 2279 [RFC2279].  All BLOAT document/datagrams MUST be well-
+   formed and include the XMLDecl.
+
+2.1. IP Description
+
+   A number of items have changed (for the better) from the original IP
+   specification.  Bit-masks, where present have been converted into
+   human-readable values.  IP addresses are listed in their dotted-
+   decimal notation [RFC1123].  Length and checksum values are present
+   as decimal integers.
+
+   To calculate the length and checksum fields of the IP element, a
+   canonicalized form of the element MUST be used.  The canonical form
+   SHALL have no whitespace (including newline characters) between
+   elements and only one space character between attributes.  There
+   SHALL NOT be a space following the last attribute in an element.
+
+   An iterative method SHOULD be used to calculate checksums, as the
+   length field will vary based on the size of the checksum.
+
+   The payload element bears special attention.  Due to the character
+   set restrictions of XML, the payload of IP datagrams (which MAY
+   contain arbitrary data) MUST be encoded for transport. This RFC
+   REQUIRES the contents of the payload to be encoded in the base-64
+   encoding of RFC 2045 [RFC2045], but removes the requirement that the
+   encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 3]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+2.2. Example Datagram
+
+   The following is an example IPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   <ip>
+   <header length="474">
+   <version value="4"/>
+   <tos precedence="Routine" delay="Normal" throughput="Normal"
+        relibility="Normal" reserved="0"/>
+   <total.length value="461"/>
+   <id value="1"/>
+   <flags reserved="0" df="dont" mf="last"/>
+   <offset value="0"/>
+   <ttl value="255"/>
+   <protocol value="6"/>
+   <checksum value="8707"/>
+   <source address="10.0.0.22"/>
+   <destination address="10.0.0.1"/>
+   <options>
+   <end copied="0" class="0" number="0"/>
+   </options>
+   <padding pad="0"/>
+   </header>
+   <payload>
+   </payload>
+   </ip>
+
+3.   TCPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+   A number of items have changed from the original TCP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+   To calculate the length and checksum fields of the TCP element, a
+   canonicalized form of the element MUST be used as in section 2.1.
+
+   An iterative method SHOULD be used to calculate checksums as in
+   section 2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy                      Informational                      [Page 4]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   The TCP offset element was expanded to a maximum of 255 from 16 to
+   allow for the increased size of the header in XML.
+
+   TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+   The following is an example TCPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   <tcp>
+   <tcp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <sequence number="322622954"/>
+   <acknowledgement number="689715995"/>
+   <offset number=""/>
+   <reserved value="0"/>
+   <control syn="1" ack="1"/>
+   <window size="1"/>
+   <urgent pointer="0"/>
+   <checksum value="2988"/>
+   <tcp.options>
+   <tcp.end kind="0"/>
+   </tcp.options>
+   <padding pad="0"/>
+   </tcp.header>
+   <payload>
+   </payload>
+   </tcp>
+
+4.   UDPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+   A number of items have changed from the original UDP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 5]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   To calculate the length and checksum fields of the UDP element, a
+   canonicalized form of the element MUST be used as in section 2.1.  An
+   iterative method SHOULD be used to calculate checksums as in section
+   2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+   UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+   The following is an example UDPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   <udp>
+   <udp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <udp.length value="143"/>
+   <checksum value="2988"/>
+   </udp.header>
+   <payload>
+   </payload>
+   </udp>
+
+5.   Network Transport
+
+   This document provides for the transmission of BLOAT datagrams over
+   two common families of physical layer transport.  Future RFCs will
+   address additional transports as routing vendors catch up to the
+   specification, and we begin to see BLOAT routed across the Internet
+   backbone.
+
+5.1. Ethernet
+
+   BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+   exception that the type field of the Ethernet frame MUST contain the
+   value 0xBEEF.  The first 5 octets of the Ethernet frame payload will
+   be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+   BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+   that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy                      Informational                      [Page 6]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+6. Gatewaying over IP
+
+   In order to facilitate the gradual introduction of BLOAT into the
+   public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+   gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+   The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+   Network DTD (7.1.)
+
+   The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+   [XML]) although it is understood that most IPoXML implementations
+   will not need to pull down the DTD, as it will normally be embedded
+   in the implementation, and presents something of a catch-22 if you
+   need to load part of your network protocol over the network.
+
+7.1.  IPoXML DTD
+
+   <!--
+    DTD for IP over XML.
+    Refer to this DTD as:
+
+    <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   -->
+   <!--
+    DTD data types:
+
+      Digits      [0..9]+
+
+      Precedence  "NetworkControl | InternetworkControl |
+                   CRITIC | FlashOverride | Flash | Immediate |
+                   Priority | Routine"
+
+      IP4Addr     "dotted-decimal" notation of [RFC1123]
+
+      Class       [0..3]
+
+      Sec          "Unclassified | Confidential | EFTO | MMMM | PROG |
+                    Restricted | Secret | Top Secret | Reserved"
+
+      Compartments [0..65535]
+
+      Handling     [0..65535]
+
+      TCC          [0..16777216]
+
+   -->
+
+
+
+Kennedy                      Informational                      [Page 7]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ENTITY % Digits "CDATA">
+   <!ENTITY % Precedence "CDATA">
+   <!ENTITY % IP4Addr "CDATA">
+   <!ENTITY % Class "CDATA">
+   <!ENTITY % Sec "CDATA">
+   <!ENTITY % Compartments "CDATA">
+   <!ENTITY % Handling "CDATA">
+   <!ENTITY % TCC "CDATA">
+
+   <!ELEMENT ip (header, payload)>
+
+   <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+                    protocol, checksum, source, destination, options,
+                    padding)>
+   <!-- length of header in 32-bit words -->
+   <!ATTLIST header
+             length %Digits; #REQUIRED>
+
+   <!ELEMENT version EMPTY>
+   <!-- ip version. SHOULD be "4" -->
+   <!ATTLIST version
+             value   %Digits;  #REQUIRED>
+
+   <!ELEMENT tos EMPTY>
+   <!ATTLIST tos
+             precedence   %Precedence;    #REQUIRED
+             delay    (normal | low)  #REQUIRED
+             throughput   (normal | high) #REQUIRED
+             relibility   (normal | high) #REQUIRED
+             reserved     CDATA #FIXED "0">
+
+   <!ELEMENT total.length EMPTY>
+   <!--
+    total length of datagram (header and payload) in octets, MUST be
+    less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+    ethernets).
+   -->
+   <!ATTLIST total.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT id EMPTY>
+   <!-- 0 <= id <= 65,535  -->
+   <!ATTLIST id
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT flags EMPTY>
+   <!-- df = don't fragment, mf = more fragments  -->
+   <!ATTLIST flags
+
+
+
+Kennedy                      Informational                      [Page 8]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+          reserved CDATA  #FIXED "0"
+          df (may|dont)   #REQUIRED
+          mf (last|more)  #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+   <!ATTLIST offset
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT ttl EMPTY>
+   <!-- 0 <= ttl <= 255 -->
+   <!ATTLIST ttl
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT protocol EMPTY>
+   <!-- 0 <= protocol <= 255 (per IANA) -->
+   <!ATTLIST protocol
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT checksum EMPTY>
+   <!-- 0 <= checksum <= 65535 (over header only) -->
+   <!ATTLIST checksum
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT source EMPTY>
+   <!ATTLIST source
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT destination EMPTY>
+   <!ATTLIST destination
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT options ( end | noop | security | loose | strict | record
+                     | stream | timestamp )*>
+
+   <!ELEMENT end EMPTY>
+   <!ATTLIST end
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "0">
+
+   <!ELEMENT noop EMPTY>
+   <!ATTLIST noop
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "1">
+
+   <!ELEMENT security EMPTY>
+
+
+
+Kennedy                      Informational                      [Page 9]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST security
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "2"
+             length CDATA #FIXED "11"
+             security %Sec; #REQUIRED
+             compartments %Compartments; #REQUIRED
+             handling %Handling; #REQUIRED
+             tcc %TCC; #REQUIRED>
+   <!ELEMENT loose (hop)+>
+   <!ATTLIST loose
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "3"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT hop EMPTY>
+   <!ATTLIST hop
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT strict (hop)+>
+   <!ATTLIST strict
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "9"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT record (hop)+>
+   <!ATTLIST record
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "7"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT stream EMPTY>
+   <!-- 0 <= id <= 65,535 -->
+   <!ATTLIST stream
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "8"
+             length CDATA #FIXED "4"
+             id %Digits; #REQUIRED>
+
+   <!ELEMENT timestamp (tstamp)+>
+   <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy                      Informational                     [Page 10]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST timestamp
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "2"
+             number CDATA #FIXED "4"
+             length %Digits;  #REQUIRED
+             pointer %Digits; #REQUIRED
+             oflw %Digits;    #REQUIRED
+             flag (0 | 1 | 3)  #REQUIRED>
+
+   <!ELEMENT tstamp EMPTY>
+   <!ATTLIST tstamp
+             time %Digits;   #REQUIRED
+             address %IP4Addr; #IMPLIED>
+   <!--
+       padding to bring header to 32-bit boundary.
+       pad MUST be "0"*
+    -->
+   <!ELEMENT padding EMPTY>
+   <!ATTLIST padding
+             pad CDATA #REQUIRED>
+
+   <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+        by section 2.1 of this RFC -->
+   <!ELEMENT payload (CDATA)>
+
+7.2.  TCPoXML DTD
+
+   <!--
+      DTD for TCP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   -->
+
+   <!-- the pseudoheader is only included for checksum calculations -->
+   <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+   <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+                         reserved, control, window, checksum, urgent,
+                         tcp.options, padding)>
+
+   <!ELEMENT src EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+   <!ATTLIST src
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT dest EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy                      Informational                     [Page 11]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST dest
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT sequence EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST sequence
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT acknowledgement EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST acknowledgement
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= number <= 255 -->
+   <!ATTLIST offset
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT reserved EMPTY>
+   <!ATTLIST reserved
+             value CDATA #FIXED "0">
+
+   <!ELEMENT control EMPTY>
+   <!ATTLIST control
+             urg (0|1) #IMPLIED
+             ack (0|1) #IMPLIED
+             psh (0|1) #IMPLIED
+             rst (0|1) #IMPLIED
+             syn (0|1) #IMPLIED
+             fin (0|1) #IMPLIED>
+
+   <!ELEMENT window EMPTY>
+   <!-- 0 <= size <= 65,535 -->
+   <!ATTLIST window
+             size %Digits; #REQUIRED>
+
+   <!--
+      checksum as in ip, but with
+      the following pseudo-header added into the tcp element:
+     -->
+   <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+                               tcp.length)>
+
+   <!--
+      tcp header + data length in octets. does not include the size of
+
+      the pseudoheader.
+    -->
+
+
+
+Kennedy                      Informational                     [Page 12]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ELEMENT tcp.length EMPTY>
+   <!ATTLIST tcp.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT urgent EMPTY>
+   <!-- 0 <= pointer <= 65,535 -->
+   <!ATTLIST urgent
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+   <!ELEMENT tcp.end EMPTY>
+   <!ATTLIST tcp.end
+             kind CDATA #FIXED "0">
+
+   <!ELEMENT tcp.noop EMPTY>
+   <!ATTLIST tcp.noop
+             kind CDATA #FIXED "1">
+
+   <!ELEMENT tcp.mss EMPTY>
+   <!ATTLIST tcp.mss
+             kind CDATA #FIXED "2"
+             length CDATA #FIXED "4"
+             size %Digits; #REQUIRED>
+
+7.3.  UDPoXML DTD
+
+   <!--
+      DTD for UDP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   -->
+
+   <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+   <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+   <!ELEMENT udp.pseudoheader (source, destination, protocol,
+                               udp.length)>
+
+   <!--
+      udp header + data length in octets. does not include the size of
+      the pseudoheader.
+    -->
+   <!ELEMENT udp.length EMPTY>
+   <!ATTLIST udp.length
+             value %Digits; #REQUIRED>
+
+
+
+Kennedy                      Informational                     [Page 13]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+8. Security Considerations
+
+   XML, as a subset of SGML, has the same security considerations as
+   specified in SGML Media Types [RFC1874].  Security considerations
+   that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+   not attempt to correct for issues not related to message format.
+
+9.   References
+
+   [JABBER]    Miller, J., "Jabber", draft-miller-jabber-00.txt,
+               February 2002. (Work in Progress)
+
+   [RFC768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+               August 1980.
+
+   [RFC791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
+               September 1981.
+
+   [RFC793]    Postel, J., "Transmission Control Protocol", STD 7, RFC
+               793, September 1981.
+
+   [RFC894]    Hornig, C., "Standard for the Transmission of IP
+               Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+   [RFC1042]   Postel, J. and J. Reynolds, "Standard for the
+               Transmission of IP Datagrams Over IEEE 802 Networks", STD
+               43, RFC 1042, February 1988.
+
+   [RFC1123]   Braden, R., "Requirements for Internet Hosts -
+               Application and Support", RFC 1123, October 1989.
+
+   [RFC1874]   Levinson, E., "SGML Media Types", RFC 1874, December
+               1995.
+
+   [RFC2003]   Perkins, C., "IP Encapsulation within IP", RFC 2003,
+               October 1996.
+
+   [RFC2045]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part One: Format of Internet Message
+               Bodies", RFC 2045, November 1996.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2279]   Yergeau, F., "UTF-8, a transformation format of ISO
+               10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy                      Informational                     [Page 14]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   [RFC2460]   Deering, S. and R. Hinden, "Internet Protocol, Version 6
+               (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC3080]   Rose, M., "The Blocks Extensible Exchange Protocol Core",
+               RFC 3080, March 2001.
+
+   [SOAP]      Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+               Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+               "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+               Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+   [XML]       Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+               Markup Language (XML)" World Wide Web Consortium
+               Recommendation REC- xml-19980210.
+               http://www.w3.org/TR/1998/REC-xml-19980210
+
+10.  Author's Address
+
+   Hugh Kennedy
+   Mimezine
+   1060 West Addison
+   Chicago, IL 60613
+   USA
+
+   EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 15]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 16]
+
+
+
+
+
+
+
+Network Working Group                                         H. Kennedy
+Request for Comments: 3252                                      Mimezine
+Category: Informational                                     1 April 2002
+
+
+                 Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document defines a reformulation of IP and two transport layer
+   protocols (TCP and UDP) as XML applications.
+
+1.   Introduction
+
+1.1. Overview
+
+   This document describes the Binary Lexical Octet Ad-hoc Transport
+   (BLOAT): a reformulation of a widely-deployed network-layer protocol
+   (IP [RFC791]), and two associated transport layer protocols (TCP
+   [RFC793] and UDP [RFC768]) as XML [XML] applications.  It also
+   describes methods for transporting BLOAT over Ethernet and IEEE 802
+   networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+   across the public Internet.
+
+1.2. Motivation
+
+   The wild popularity of XML as a basis for application-level protocols
+   such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+   Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+   investigation into the possibility of extending the use of XML in the
+   protocol stack.  Using XML at both the transport and network layer in
+   addition to the application layer would provide for an amazing amount
+   of power and flexibility while removing dependencies on proprietary
+   and hard-to-understand binary protocols.  This protocol unification
+   would also allow applications to use a single XML parser for all
+   aspects of their operation, eliminating developer time spent figuring
+   out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy                      Informational                      [Page 1]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   parsing to the XML toolset.  The use of XML also mitigates concerns
+   over "network vs. host" byte ordering which is at the root of many
+   network application bugs.
+
+1.3. Relation to Existing Protocols
+
+   The reformulations specified in this RFC follow as closely as
+   possible the spirit of the RFCs on which they are based, and so MAY
+   contain elements or attributes that would not be needed in a pure
+   reworking (e.g. length attributes, which are implicit in XML.)
+
+   The layering of network and transport protocols are maintained in
+   this RFC despite the optimizations that could be made if the line
+   were somewhat blurred (i.e. merging TCP and IP into a single, larger
+   element in the DTD) in order to foster future use of this protocol as
+   a basis for reformulating other protocols (such as ICMP.)
+
+   Other than the encoding, the behavioral aspects of each of the
+   existing protocols remain unchanged.  Routing, address spaces, TCP
+   congestion control, etc. behave as specified in the extant standards.
+   Adapting to new standards and experimental algorithm heuristics for
+   improving performance will become much easier once the move to BLOAT
+   has been completed.
+
+1.4. Requirement Levels
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119
+   [RFC2119].
+
+2.   IPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.
+   IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+   (section 3.) and higher-level application protocols.
+
+   The DTD for this document type can be found in section 7.1.
+
+   The routing of IPoXML can be easily implemented on hosts with an XML
+   parser, as the regular structure lends itself handily to parsing and
+   validation of the document/datagram and then processing the
+   destination address, TTL, and checksum before sending it on to its
+   next-hop.
+
+   The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+   wider deployment of IPv4 and the fact that implementing IPv6 as XML
+   would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy                      Informational                      [Page 2]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+   of RFC 2279 [RFC2279].  All BLOAT document/datagrams MUST be well-
+   formed and include the XMLDecl.
+
+2.1. IP Description
+
+   A number of items have changed (for the better) from the original IP
+   specification.  Bit-masks, where present have been converted into
+   human-readable values.  IP addresses are listed in their dotted-
+   decimal notation [RFC1123].  Length and checksum values are present
+   as decimal integers.
+
+   To calculate the length and checksum fields of the IP element, a
+   canonicalized form of the element MUST be used.  The canonical form
+   SHALL have no whitespace (including newline characters) between
+   elements and only one space character between attributes.  There
+   SHALL NOT be a space following the last attribute in an element.
+
+   An iterative method SHOULD be used to calculate checksums, as the
+   length field will vary based on the size of the checksum.
+
+   The payload element bears special attention.  Due to the character
+   set restrictions of XML, the payload of IP datagrams (which MAY
+   contain arbitrary data) MUST be encoded for transport. This RFC
+   REQUIRES the contents of the payload to be encoded in the base-64
+   encoding of RFC 2045 [RFC2045], but removes the requirement that the
+   encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 3]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+2.2. Example Datagram
+
+   The following is an example IPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   <ip>
+   <header length="474">
+   <version value="4"/>
+   <tos precedence="Routine" delay="Normal" throughput="Normal"
+        relibility="Normal" reserved="0"/>
+   <total.length value="461"/>
+   <id value="1"/>
+   <flags reserved="0" df="dont" mf="last"/>
+   <offset value="0"/>
+   <ttl value="255"/>
+   <protocol value="6"/>
+   <checksum value="8707"/>
+   <source address="10.0.0.22"/>
+   <destination address="10.0.0.1"/>
+   <options>
+   <end copied="0" class="0" number="0"/>
+   </options>
+   <padding pad="0"/>
+   </header>
+   <payload>
+   </payload>
+   </ip>
+
+3.   TCPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+   A number of items have changed from the original TCP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+   To calculate the length and checksum fields of the TCP element, a
+   canonicalized form of the element MUST be used as in section 2.1.
+
+   An iterative method SHOULD be used to calculate checksums as in
+   section 2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy                      Informational                      [Page 4]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   The TCP offset element was expanded to a maximum of 255 from 16 to
+   allow for the increased size of the header in XML.
+
+   TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+   The following is an example TCPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   <tcp>
+   <tcp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <sequence number="322622954"/>
+   <acknowledgement number="689715995"/>
+   <offset number=""/>
+   <reserved value="0"/>
+   <control syn="1" ack="1"/>
+   <window size="1"/>
+   <urgent pointer="0"/>
+   <checksum value="2988"/>
+   <tcp.options>
+   <tcp.end kind="0"/>
+   </tcp.options>
+   <padding pad="0"/>
+   </tcp.header>
+   <payload>
+   </payload>
+   </tcp>
+
+4.   UDPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+   A number of items have changed from the original UDP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 5]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   To calculate the length and checksum fields of the UDP element, a
+   canonicalized form of the element MUST be used as in section 2.1.  An
+   iterative method SHOULD be used to calculate checksums as in section
+   2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+   UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+   The following is an example UDPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   <udp>
+   <udp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <udp.length value="143"/>
+   <checksum value="2988"/>
+   </udp.header>
+   <payload>
+   </payload>
+   </udp>
+
+5.   Network Transport
+
+   This document provides for the transmission of BLOAT datagrams over
+   two common families of physical layer transport.  Future RFCs will
+   address additional transports as routing vendors catch up to the
+   specification, and we begin to see BLOAT routed across the Internet
+   backbone.
+
+5.1. Ethernet
+
+   BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+   exception that the type field of the Ethernet frame MUST contain the
+   value 0xBEEF.  The first 5 octets of the Ethernet frame payload will
+   be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+   BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+   that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy                      Informational                      [Page 6]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+6. Gatewaying over IP
+
+   In order to facilitate the gradual introduction of BLOAT into the
+   public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+   gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+   The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+   Network DTD (7.1.)
+
+   The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+   [XML]) although it is understood that most IPoXML implementations
+   will not need to pull down the DTD, as it will normally be embedded
+   in the implementation, and presents something of a catch-22 if you
+   need to load part of your network protocol over the network.
+
+7.1.  IPoXML DTD
+
+   <!--
+    DTD for IP over XML.
+    Refer to this DTD as:
+
+    <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   -->
+   <!--
+    DTD data types:
+
+      Digits      [0..9]+
+
+      Precedence  "NetworkControl | InternetworkControl |
+                   CRITIC | FlashOverride | Flash | Immediate |
+                   Priority | Routine"
+
+      IP4Addr     "dotted-decimal" notation of [RFC1123]
+
+      Class       [0..3]
+
+      Sec          "Unclassified | Confidential | EFTO | MMMM | PROG |
+                    Restricted | Secret | Top Secret | Reserved"
+
+      Compartments [0..65535]
+
+      Handling     [0..65535]
+
+      TCC          [0..16777216]
+
+   -->
+
+
+
+Kennedy                      Informational                      [Page 7]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ENTITY % Digits "CDATA">
+   <!ENTITY % Precedence "CDATA">
+   <!ENTITY % IP4Addr "CDATA">
+   <!ENTITY % Class "CDATA">
+   <!ENTITY % Sec "CDATA">
+   <!ENTITY % Compartments "CDATA">
+   <!ENTITY % Handling "CDATA">
+   <!ENTITY % TCC "CDATA">
+
+   <!ELEMENT ip (header, payload)>
+
+   <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+                    protocol, checksum, source, destination, options,
+                    padding)>
+   <!-- length of header in 32-bit words -->
+   <!ATTLIST header
+             length %Digits; #REQUIRED>
+
+   <!ELEMENT version EMPTY>
+   <!-- ip version. SHOULD be "4" -->
+   <!ATTLIST version
+             value   %Digits;  #REQUIRED>
+
+   <!ELEMENT tos EMPTY>
+   <!ATTLIST tos
+             precedence   %Precedence;    #REQUIRED
+             delay    (normal | low)  #REQUIRED
+             throughput   (normal | high) #REQUIRED
+             relibility   (normal | high) #REQUIRED
+             reserved     CDATA #FIXED "0">
+
+   <!ELEMENT total.length EMPTY>
+   <!--
+    total length of datagram (header and payload) in octets, MUST be
+    less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+    ethernets).
+   -->
+   <!ATTLIST total.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT id EMPTY>
+   <!-- 0 <= id <= 65,535  -->
+   <!ATTLIST id
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT flags EMPTY>
+   <!-- df = don't fragment, mf = more fragments  -->
+   <!ATTLIST flags
+
+
+
+Kennedy                      Informational                      [Page 8]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+          reserved CDATA  #FIXED "0"
+          df (may|dont)   #REQUIRED
+          mf (last|more)  #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+   <!ATTLIST offset
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT ttl EMPTY>
+   <!-- 0 <= ttl <= 255 -->
+   <!ATTLIST ttl
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT protocol EMPTY>
+   <!-- 0 <= protocol <= 255 (per IANA) -->
+   <!ATTLIST protocol
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT checksum EMPTY>
+   <!-- 0 <= checksum <= 65535 (over header only) -->
+   <!ATTLIST checksum
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT source EMPTY>
+   <!ATTLIST source
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT destination EMPTY>
+   <!ATTLIST destination
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT options ( end | noop | security | loose | strict | record
+                     | stream | timestamp )*>
+
+   <!ELEMENT end EMPTY>
+   <!ATTLIST end
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "0">
+
+   <!ELEMENT noop EMPTY>
+   <!ATTLIST noop
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "1">
+
+   <!ELEMENT security EMPTY>
+
+
+
+Kennedy                      Informational                      [Page 9]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST security
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "2"
+             length CDATA #FIXED "11"
+             security %Sec; #REQUIRED
+             compartments %Compartments; #REQUIRED
+             handling %Handling; #REQUIRED
+             tcc %TCC; #REQUIRED>
+   <!ELEMENT loose (hop)+>
+   <!ATTLIST loose
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "3"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT hop EMPTY>
+   <!ATTLIST hop
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT strict (hop)+>
+   <!ATTLIST strict
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "9"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT record (hop)+>
+   <!ATTLIST record
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "7"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT stream EMPTY>
+   <!-- 0 <= id <= 65,535 -->
+   <!ATTLIST stream
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "8"
+             length CDATA #FIXED "4"
+             id %Digits; #REQUIRED>
+
+   <!ELEMENT timestamp (tstamp)+>
+   <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy                      Informational                     [Page 10]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST timestamp
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "2"
+             number CDATA #FIXED "4"
+             length %Digits;  #REQUIRED
+             pointer %Digits; #REQUIRED
+             oflw %Digits;    #REQUIRED
+             flag (0 | 1 | 3)  #REQUIRED>
+
+   <!ELEMENT tstamp EMPTY>
+   <!ATTLIST tstamp
+             time %Digits;   #REQUIRED
+             address %IP4Addr; #IMPLIED>
+   <!--
+       padding to bring header to 32-bit boundary.
+       pad MUST be "0"*
+    -->
+   <!ELEMENT padding EMPTY>
+   <!ATTLIST padding
+             pad CDATA #REQUIRED>
+
+   <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+        by section 2.1 of this RFC -->
+   <!ELEMENT payload (CDATA)>
+
+7.2.  TCPoXML DTD
+
+   <!--
+      DTD for TCP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   -->
+
+   <!-- the pseudoheader is only included for checksum calculations -->
+   <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+   <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+                         reserved, control, window, checksum, urgent,
+                         tcp.options, padding)>
+
+   <!ELEMENT src EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+   <!ATTLIST src
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT dest EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy                      Informational                     [Page 11]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST dest
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT sequence EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST sequence
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT acknowledgement EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST acknowledgement
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= number <= 255 -->
+   <!ATTLIST offset
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT reserved EMPTY>
+   <!ATTLIST reserved
+             value CDATA #FIXED "0">
+
+   <!ELEMENT control EMPTY>
+   <!ATTLIST control
+             urg (0|1) #IMPLIED
+             ack (0|1) #IMPLIED
+             psh (0|1) #IMPLIED
+             rst (0|1) #IMPLIED
+             syn (0|1) #IMPLIED
+             fin (0|1) #IMPLIED>
+
+   <!ELEMENT window EMPTY>
+   <!-- 0 <= size <= 65,535 -->
+   <!ATTLIST window
+             size %Digits; #REQUIRED>
+
+   <!--
+      checksum as in ip, but with
+      the following pseudo-header added into the tcp element:
+     -->
+   <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+                               tcp.length)>
+
+   <!--
+      tcp header + data length in octets. does not include the size of
+
+      the pseudoheader.
+    -->
+
+
+
+Kennedy                      Informational                     [Page 12]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ELEMENT tcp.length EMPTY>
+   <!ATTLIST tcp.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT urgent EMPTY>
+   <!-- 0 <= pointer <= 65,535 -->
+   <!ATTLIST urgent
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+   <!ELEMENT tcp.end EMPTY>
+   <!ATTLIST tcp.end
+             kind CDATA #FIXED "0">
+
+   <!ELEMENT tcp.noop EMPTY>
+   <!ATTLIST tcp.noop
+             kind CDATA #FIXED "1">
+
+   <!ELEMENT tcp.mss EMPTY>
+   <!ATTLIST tcp.mss
+             kind CDATA #FIXED "2"
+             length CDATA #FIXED "4"
+             size %Digits; #REQUIRED>
+
+7.3.  UDPoXML DTD
+
+   <!--
+      DTD for UDP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   -->
+
+   <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+   <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+   <!ELEMENT udp.pseudoheader (source, destination, protocol,
+                               udp.length)>
+
+   <!--
+      udp header + data length in octets. does not include the size of
+      the pseudoheader.
+    -->
+   <!ELEMENT udp.length EMPTY>
+   <!ATTLIST udp.length
+             value %Digits; #REQUIRED>
+
+
+
+Kennedy                      Informational                     [Page 13]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+8. Security Considerations
+
+   XML, as a subset of SGML, has the same security considerations as
+   specified in SGML Media Types [RFC1874].  Security considerations
+   that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+   not attempt to correct for issues not related to message format.
+
+9.   References
+
+   [JABBER]    Miller, J., "Jabber", draft-miller-jabber-00.txt,
+               February 2002. (Work in Progress)
+
+   [RFC768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+               August 1980.
+
+   [RFC791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
+               September 1981.
+
+   [RFC793]    Postel, J., "Transmission Control Protocol", STD 7, RFC
+               793, September 1981.
+
+   [RFC894]    Hornig, C., "Standard for the Transmission of IP
+               Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+   [RFC1042]   Postel, J. and J. Reynolds, "Standard for the
+               Transmission of IP Datagrams Over IEEE 802 Networks", STD
+               43, RFC 1042, February 1988.
+
+   [RFC1123]   Braden, R., "Requirements for Internet Hosts -
+               Application and Support", RFC 1123, October 1989.
+
+   [RFC1874]   Levinson, E., "SGML Media Types", RFC 1874, December
+               1995.
+
+   [RFC2003]   Perkins, C., "IP Encapsulation within IP", RFC 2003,
+               October 1996.
+
+   [RFC2045]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part One: Format of Internet Message
+               Bodies", RFC 2045, November 1996.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2279]   Yergeau, F., "UTF-8, a transformation format of ISO
+               10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy                      Informational                     [Page 14]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   [RFC2460]   Deering, S. and R. Hinden, "Internet Protocol, Version 6
+               (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC3080]   Rose, M., "The Blocks Extensible Exchange Protocol Core",
+               RFC 3080, March 2001.
+
+   [SOAP]      Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+               Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+               "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+               Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+   [XML]       Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+               Markup Language (XML)" World Wide Web Consortium
+               Recommendation REC- xml-19980210.
+               http://www.w3.org/TR/1998/REC-xml-19980210
+
+10.  Author's Address
+
+   Hugh Kennedy
+   Mimezine
+   1060 West Addison
+   Chicago, IL 60613
+   USA
+
+   EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 15]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 16]
+
+
+
+
+
+
+
+Network Working Group                                         H. Kennedy
+Request for Comments: 3252                                      Mimezine
+Category: Informational                                     1 April 2002
+
+
+                 Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document defines a reformulation of IP and two transport layer
+   protocols (TCP and UDP) as XML applications.
+
+1.   Introduction
+
+1.1. Overview
+
+   This document describes the Binary Lexical Octet Ad-hoc Transport
+   (BLOAT): a reformulation of a widely-deployed network-layer protocol
+   (IP [RFC791]), and two associated transport layer protocols (TCP
+   [RFC793] and UDP [RFC768]) as XML [XML] applications.  It also
+   describes methods for transporting BLOAT over Ethernet and IEEE 802
+   networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+   across the public Internet.
+
+1.2. Motivation
+
+   The wild popularity of XML as a basis for application-level protocols
+   such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+   Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+   investigation into the possibility of extending the use of XML in the
+   protocol stack.  Using XML at both the transport and network layer in
+   addition to the application layer would provide for an amazing amount
+   of power and flexibility while removing dependencies on proprietary
+   and hard-to-understand binary protocols.  This protocol unification
+   would also allow applications to use a single XML parser for all
+   aspects of their operation, eliminating developer time spent figuring
+   out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy                      Informational                      [Page 1]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   parsing to the XML toolset.  The use of XML also mitigates concerns
+   over "network vs. host" byte ordering which is at the root of many
+   network application bugs.
+
+1.3. Relation to Existing Protocols
+
+   The reformulations specified in this RFC follow as closely as
+   possible the spirit of the RFCs on which they are based, and so MAY
+   contain elements or attributes that would not be needed in a pure
+   reworking (e.g. length attributes, which are implicit in XML.)
+
+   The layering of network and transport protocols are maintained in
+   this RFC despite the optimizations that could be made if the line
+   were somewhat blurred (i.e. merging TCP and IP into a single, larger
+   element in the DTD) in order to foster future use of this protocol as
+   a basis for reformulating other protocols (such as ICMP.)
+
+   Other than the encoding, the behavioral aspects of each of the
+   existing protocols remain unchanged.  Routing, address spaces, TCP
+   congestion control, etc. behave as specified in the extant standards.
+   Adapting to new standards and experimental algorithm heuristics for
+   improving performance will become much easier once the move to BLOAT
+   has been completed.
+
+1.4. Requirement Levels
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119
+   [RFC2119].
+
+2.   IPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.
+   IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+   (section 3.) and higher-level application protocols.
+
+   The DTD for this document type can be found in section 7.1.
+
+   The routing of IPoXML can be easily implemented on hosts with an XML
+   parser, as the regular structure lends itself handily to parsing and
+   validation of the document/datagram and then processing the
+   destination address, TTL, and checksum before sending it on to its
+   next-hop.
+
+   The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+   wider deployment of IPv4 and the fact that implementing IPv6 as XML
+   would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy                      Informational                      [Page 2]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+   of RFC 2279 [RFC2279].  All BLOAT document/datagrams MUST be well-
+   formed and include the XMLDecl.
+
+2.1. IP Description
+
+   A number of items have changed (for the better) from the original IP
+   specification.  Bit-masks, where present have been converted into
+   human-readable values.  IP addresses are listed in their dotted-
+   decimal notation [RFC1123].  Length and checksum values are present
+   as decimal integers.
+
+   To calculate the length and checksum fields of the IP element, a
+   canonicalized form of the element MUST be used.  The canonical form
+   SHALL have no whitespace (including newline characters) between
+   elements and only one space character between attributes.  There
+   SHALL NOT be a space following the last attribute in an element.
+
+   An iterative method SHOULD be used to calculate checksums, as the
+   length field will vary based on the size of the checksum.
+
+   The payload element bears special attention.  Due to the character
+   set restrictions of XML, the payload of IP datagrams (which MAY
+   contain arbitrary data) MUST be encoded for transport. This RFC
+   REQUIRES the contents of the payload to be encoded in the base-64
+   encoding of RFC 2045 [RFC2045], but removes the requirement that the
+   encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 3]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+2.2. Example Datagram
+
+   The following is an example IPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   <ip>
+   <header length="474">
+   <version value="4"/>
+   <tos precedence="Routine" delay="Normal" throughput="Normal"
+        relibility="Normal" reserved="0"/>
+   <total.length value="461"/>
+   <id value="1"/>
+   <flags reserved="0" df="dont" mf="last"/>
+   <offset value="0"/>
+   <ttl value="255"/>
+   <protocol value="6"/>
+   <checksum value="8707"/>
+   <source address="10.0.0.22"/>
+   <destination address="10.0.0.1"/>
+   <options>
+   <end copied="0" class="0" number="0"/>
+   </options>
+   <padding pad="0"/>
+   </header>
+   <payload>
+   </payload>
+   </ip>
+
+3.   TCPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+   A number of items have changed from the original TCP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+   To calculate the length and checksum fields of the TCP element, a
+   canonicalized form of the element MUST be used as in section 2.1.
+
+   An iterative method SHOULD be used to calculate checksums as in
+   section 2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy                      Informational                      [Page 4]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   The TCP offset element was expanded to a maximum of 255 from 16 to
+   allow for the increased size of the header in XML.
+
+   TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+   The following is an example TCPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   <tcp>
+   <tcp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <sequence number="322622954"/>
+   <acknowledgement number="689715995"/>
+   <offset number=""/>
+   <reserved value="0"/>
+   <control syn="1" ack="1"/>
+   <window size="1"/>
+   <urgent pointer="0"/>
+   <checksum value="2988"/>
+   <tcp.options>
+   <tcp.end kind="0"/>
+   </tcp.options>
+   <padding pad="0"/>
+   </tcp.header>
+   <payload>
+   </payload>
+   </tcp>
+
+4.   UDPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+   A number of items have changed from the original UDP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 5]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   To calculate the length and checksum fields of the UDP element, a
+   canonicalized form of the element MUST be used as in section 2.1.  An
+   iterative method SHOULD be used to calculate checksums as in section
+   2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+   UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+   The following is an example UDPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   <udp>
+   <udp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <udp.length value="143"/>
+   <checksum value="2988"/>
+   </udp.header>
+   <payload>
+   </payload>
+   </udp>
+
+5.   Network Transport
+
+   This document provides for the transmission of BLOAT datagrams over
+   two common families of physical layer transport.  Future RFCs will
+   address additional transports as routing vendors catch up to the
+   specification, and we begin to see BLOAT routed across the Internet
+   backbone.
+
+5.1. Ethernet
+
+   BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+   exception that the type field of the Ethernet frame MUST contain the
+   value 0xBEEF.  The first 5 octets of the Ethernet frame payload will
+   be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+   BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+   that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy                      Informational                      [Page 6]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+6. Gatewaying over IP
+
+   In order to facilitate the gradual introduction of BLOAT into the
+   public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+   gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+   The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+   Network DTD (7.1.)
+
+   The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+   [XML]) although it is understood that most IPoXML implementations
+   will not need to pull down the DTD, as it will normally be embedded
+   in the implementation, and presents something of a catch-22 if you
+   need to load part of your network protocol over the network.
+
+7.1.  IPoXML DTD
+
+   <!--
+    DTD for IP over XML.
+    Refer to this DTD as:
+
+    <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   -->
+   <!--
+    DTD data types:
+
+      Digits      [0..9]+
+
+      Precedence  "NetworkControl | InternetworkControl |
+                   CRITIC | FlashOverride | Flash | Immediate |
+                   Priority | Routine"
+
+      IP4Addr     "dotted-decimal" notation of [RFC1123]
+
+      Class       [0..3]
+
+      Sec          "Unclassified | Confidential | EFTO | MMMM | PROG |
+                    Restricted | Secret | Top Secret | Reserved"
+
+      Compartments [0..65535]
+
+      Handling     [0..65535]
+
+      TCC          [0..16777216]
+
+   -->
+
+
+
+Kennedy                      Informational                      [Page 7]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ENTITY % Digits "CDATA">
+   <!ENTITY % Precedence "CDATA">
+   <!ENTITY % IP4Addr "CDATA">
+   <!ENTITY % Class "CDATA">
+   <!ENTITY % Sec "CDATA">
+   <!ENTITY % Compartments "CDATA">
+   <!ENTITY % Handling "CDATA">
+   <!ENTITY % TCC "CDATA">
+
+   <!ELEMENT ip (header, payload)>
+
+   <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+                    protocol, checksum, source, destination, options,
+                    padding)>
+   <!-- length of header in 32-bit words -->
+   <!ATTLIST header
+             length %Digits; #REQUIRED>
+
+   <!ELEMENT version EMPTY>
+   <!-- ip version. SHOULD be "4" -->
+   <!ATTLIST version
+             value   %Digits;  #REQUIRED>
+
+   <!ELEMENT tos EMPTY>
+   <!ATTLIST tos
+             precedence   %Precedence;    #REQUIRED
+             delay    (normal | low)  #REQUIRED
+             throughput   (normal | high) #REQUIRED
+             relibility   (normal | high) #REQUIRED
+             reserved     CDATA #FIXED "0">
+
+   <!ELEMENT total.length EMPTY>
+   <!--
+    total length of datagram (header and payload) in octets, MUST be
+    less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+    ethernets).
+   -->
+   <!ATTLIST total.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT id EMPTY>
+   <!-- 0 <= id <= 65,535  -->
+   <!ATTLIST id
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT flags EMPTY>
+   <!-- df = don't fragment, mf = more fragments  -->
+   <!ATTLIST flags
+
+
+
+Kennedy                      Informational                      [Page 8]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+          reserved CDATA  #FIXED "0"
+          df (may|dont)   #REQUIRED
+          mf (last|more)  #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+   <!ATTLIST offset
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT ttl EMPTY>
+   <!-- 0 <= ttl <= 255 -->
+   <!ATTLIST ttl
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT protocol EMPTY>
+   <!-- 0 <= protocol <= 255 (per IANA) -->
+   <!ATTLIST protocol
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT checksum EMPTY>
+   <!-- 0 <= checksum <= 65535 (over header only) -->
+   <!ATTLIST checksum
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT source EMPTY>
+   <!ATTLIST source
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT destination EMPTY>
+   <!ATTLIST destination
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT options ( end | noop | security | loose | strict | record
+                     | stream | timestamp )*>
+
+   <!ELEMENT end EMPTY>
+   <!ATTLIST end
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "0">
+
+   <!ELEMENT noop EMPTY>
+   <!ATTLIST noop
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "1">
+
+   <!ELEMENT security EMPTY>
+
+
+
+Kennedy                      Informational                      [Page 9]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST security
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "2"
+             length CDATA #FIXED "11"
+             security %Sec; #REQUIRED
+             compartments %Compartments; #REQUIRED
+             handling %Handling; #REQUIRED
+             tcc %TCC; #REQUIRED>
+   <!ELEMENT loose (hop)+>
+   <!ATTLIST loose
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "3"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT hop EMPTY>
+   <!ATTLIST hop
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT strict (hop)+>
+   <!ATTLIST strict
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "9"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT record (hop)+>
+   <!ATTLIST record
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "7"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT stream EMPTY>
+   <!-- 0 <= id <= 65,535 -->
+   <!ATTLIST stream
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "8"
+             length CDATA #FIXED "4"
+             id %Digits; #REQUIRED>
+
+   <!ELEMENT timestamp (tstamp)+>
+   <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy                      Informational                     [Page 10]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST timestamp
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "2"
+             number CDATA #FIXED "4"
+             length %Digits;  #REQUIRED
+             pointer %Digits; #REQUIRED
+             oflw %Digits;    #REQUIRED
+             flag (0 | 1 | 3)  #REQUIRED>
+
+   <!ELEMENT tstamp EMPTY>
+   <!ATTLIST tstamp
+             time %Digits;   #REQUIRED
+             address %IP4Addr; #IMPLIED>
+   <!--
+       padding to bring header to 32-bit boundary.
+       pad MUST be "0"*
+    -->
+   <!ELEMENT padding EMPTY>
+   <!ATTLIST padding
+             pad CDATA #REQUIRED>
+
+   <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+        by section 2.1 of this RFC -->
+   <!ELEMENT payload (CDATA)>
+
+7.2.  TCPoXML DTD
+
+   <!--
+      DTD for TCP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   -->
+
+   <!-- the pseudoheader is only included for checksum calculations -->
+   <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+   <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+                         reserved, control, window, checksum, urgent,
+                         tcp.options, padding)>
+
+   <!ELEMENT src EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+   <!ATTLIST src
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT dest EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy                      Informational                     [Page 11]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST dest
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT sequence EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST sequence
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT acknowledgement EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST acknowledgement
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= number <= 255 -->
+   <!ATTLIST offset
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT reserved EMPTY>
+   <!ATTLIST reserved
+             value CDATA #FIXED "0">
+
+   <!ELEMENT control EMPTY>
+   <!ATTLIST control
+             urg (0|1) #IMPLIED
+             ack (0|1) #IMPLIED
+             psh (0|1) #IMPLIED
+             rst (0|1) #IMPLIED
+             syn (0|1) #IMPLIED
+             fin (0|1) #IMPLIED>
+
+   <!ELEMENT window EMPTY>
+   <!-- 0 <= size <= 65,535 -->
+   <!ATTLIST window
+             size %Digits; #REQUIRED>
+
+   <!--
+      checksum as in ip, but with
+      the following pseudo-header added into the tcp element:
+     -->
+   <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+                               tcp.length)>
+
+   <!--
+      tcp header + data length in octets. does not include the size of
+
+      the pseudoheader.
+    -->
+
+
+
+Kennedy                      Informational                     [Page 12]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ELEMENT tcp.length EMPTY>
+   <!ATTLIST tcp.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT urgent EMPTY>
+   <!-- 0 <= pointer <= 65,535 -->
+   <!ATTLIST urgent
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+   <!ELEMENT tcp.end EMPTY>
+   <!ATTLIST tcp.end
+             kind CDATA #FIXED "0">
+
+   <!ELEMENT tcp.noop EMPTY>
+   <!ATTLIST tcp.noop
+             kind CDATA #FIXED "1">
+
+   <!ELEMENT tcp.mss EMPTY>
+   <!ATTLIST tcp.mss
+             kind CDATA #FIXED "2"
+             length CDATA #FIXED "4"
+             size %Digits; #REQUIRED>
+
+7.3.  UDPoXML DTD
+
+   <!--
+      DTD for UDP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   -->
+
+   <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+   <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+   <!ELEMENT udp.pseudoheader (source, destination, protocol,
+                               udp.length)>
+
+   <!--
+      udp header + data length in octets. does not include the size of
+      the pseudoheader.
+    -->
+   <!ELEMENT udp.length EMPTY>
+   <!ATTLIST udp.length
+             value %Digits; #REQUIRED>
+
+
+
+Kennedy                      Informational                     [Page 13]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+8. Security Considerations
+
+   XML, as a subset of SGML, has the same security considerations as
+   specified in SGML Media Types [RFC1874].  Security considerations
+   that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+   not attempt to correct for issues not related to message format.
+
+9.   References
+
+   [JABBER]    Miller, J., "Jabber", draft-miller-jabber-00.txt,
+               February 2002. (Work in Progress)
+
+   [RFC768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+               August 1980.
+
+   [RFC791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
+               September 1981.
+
+   [RFC793]    Postel, J., "Transmission Control Protocol", STD 7, RFC
+               793, September 1981.
+
+   [RFC894]    Hornig, C., "Standard for the Transmission of IP
+               Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+   [RFC1042]   Postel, J. and J. Reynolds, "Standard for the
+               Transmission of IP Datagrams Over IEEE 802 Networks", STD
+               43, RFC 1042, February 1988.
+
+   [RFC1123]   Braden, R., "Requirements for Internet Hosts -
+               Application and Support", RFC 1123, October 1989.
+
+   [RFC1874]   Levinson, E., "SGML Media Types", RFC 1874, December
+               1995.
+
+   [RFC2003]   Perkins, C., "IP Encapsulation within IP", RFC 2003,
+               October 1996.
+
+   [RFC2045]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part One: Format of Internet Message
+               Bodies", RFC 2045, November 1996.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2279]   Yergeau, F., "UTF-8, a transformation format of ISO
+               10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy                      Informational                     [Page 14]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   [RFC2460]   Deering, S. and R. Hinden, "Internet Protocol, Version 6
+               (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC3080]   Rose, M., "The Blocks Extensible Exchange Protocol Core",
+               RFC 3080, March 2001.
+
+   [SOAP]      Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+               Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+               "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+               Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+   [XML]       Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+               Markup Language (XML)" World Wide Web Consortium
+               Recommendation REC- xml-19980210.
+               http://www.w3.org/TR/1998/REC-xml-19980210
+
+10.  Author's Address
+
+   Hugh Kennedy
+   Mimezine
+   1060 West Addison
+   Chicago, IL 60613
+   USA
+
+   EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 15]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 16]
+
+
+
+
+
+
+
+Network Working Group                                         H. Kennedy
+Request for Comments: 3252                                      Mimezine
+Category: Informational                                     1 April 2002
+
+
+                 Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document defines a reformulation of IP and two transport layer
+   protocols (TCP and UDP) as XML applications.
+
+1.   Introduction
+
+1.1. Overview
+
+   This document describes the Binary Lexical Octet Ad-hoc Transport
+   (BLOAT): a reformulation of a widely-deployed network-layer protocol
+   (IP [RFC791]), and two associated transport layer protocols (TCP
+   [RFC793] and UDP [RFC768]) as XML [XML] applications.  It also
+   describes methods for transporting BLOAT over Ethernet and IEEE 802
+   networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+   across the public Internet.
+
+1.2. Motivation
+
+   The wild popularity of XML as a basis for application-level protocols
+   such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+   Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+   investigation into the possibility of extending the use of XML in the
+   protocol stack.  Using XML at both the transport and network layer in
+   addition to the application layer would provide for an amazing amount
+   of power and flexibility while removing dependencies on proprietary
+   and hard-to-understand binary protocols.  This protocol unification
+   would also allow applications to use a single XML parser for all
+   aspects of their operation, eliminating developer time spent figuring
+   out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy                      Informational                      [Page 1]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   parsing to the XML toolset.  The use of XML also mitigates concerns
+   over "network vs. host" byte ordering which is at the root of many
+   network application bugs.
+
+1.3. Relation to Existing Protocols
+
+   The reformulations specified in this RFC follow as closely as
+   possible the spirit of the RFCs on which they are based, and so MAY
+   contain elements or attributes that would not be needed in a pure
+   reworking (e.g. length attributes, which are implicit in XML.)
+
+   The layering of network and transport protocols are maintained in
+   this RFC despite the optimizations that could be made if the line
+   were somewhat blurred (i.e. merging TCP and IP into a single, larger
+   element in the DTD) in order to foster future use of this protocol as
+   a basis for reformulating other protocols (such as ICMP.)
+
+   Other than the encoding, the behavioral aspects of each of the
+   existing protocols remain unchanged.  Routing, address spaces, TCP
+   congestion control, etc. behave as specified in the extant standards.
+   Adapting to new standards and experimental algorithm heuristics for
+   improving performance will become much easier once the move to BLOAT
+   has been completed.
+
+1.4. Requirement Levels
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119
+   [RFC2119].
+
+2.   IPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.
+   IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+   (section 3.) and higher-level application protocols.
+
+   The DTD for this document type can be found in section 7.1.
+
+   The routing of IPoXML can be easily implemented on hosts with an XML
+   parser, as the regular structure lends itself handily to parsing and
+   validation of the document/datagram and then processing the
+   destination address, TTL, and checksum before sending it on to its
+   next-hop.
+
+   The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+   wider deployment of IPv4 and the fact that implementing IPv6 as XML
+   would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy                      Informational                      [Page 2]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+   of RFC 2279 [RFC2279].  All BLOAT document/datagrams MUST be well-
+   formed and include the XMLDecl.
+
+2.1. IP Description
+
+   A number of items have changed (for the better) from the original IP
+   specification.  Bit-masks, where present have been converted into
+   human-readable values.  IP addresses are listed in their dotted-
+   decimal notation [RFC1123].  Length and checksum values are present
+   as decimal integers.
+
+   To calculate the length and checksum fields of the IP element, a
+   canonicalized form of the element MUST be used.  The canonical form
+   SHALL have no whitespace (including newline characters) between
+   elements and only one space character between attributes.  There
+   SHALL NOT be a space following the last attribute in an element.
+
+   An iterative method SHOULD be used to calculate checksums, as the
+   length field will vary based on the size of the checksum.
+
+   The payload element bears special attention.  Due to the character
+   set restrictions of XML, the payload of IP datagrams (which MAY
+   contain arbitrary data) MUST be encoded for transport. This RFC
+   REQUIRES the contents of the payload to be encoded in the base-64
+   encoding of RFC 2045 [RFC2045], but removes the requirement that the
+   encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 3]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+2.2. Example Datagram
+
+   The following is an example IPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   <ip>
+   <header length="474">
+   <version value="4"/>
+   <tos precedence="Routine" delay="Normal" throughput="Normal"
+        relibility="Normal" reserved="0"/>
+   <total.length value="461"/>
+   <id value="1"/>
+   <flags reserved="0" df="dont" mf="last"/>
+   <offset value="0"/>
+   <ttl value="255"/>
+   <protocol value="6"/>
+   <checksum value="8707"/>
+   <source address="10.0.0.22"/>
+   <destination address="10.0.0.1"/>
+   <options>
+   <end copied="0" class="0" number="0"/>
+   </options>
+   <padding pad="0"/>
+   </header>
+   <payload>
+   </payload>
+   </ip>
+
+3.   TCPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+   A number of items have changed from the original TCP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+   To calculate the length and checksum fields of the TCP element, a
+   canonicalized form of the element MUST be used as in section 2.1.
+
+   An iterative method SHOULD be used to calculate checksums as in
+   section 2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy                      Informational                      [Page 4]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   The TCP offset element was expanded to a maximum of 255 from 16 to
+   allow for the increased size of the header in XML.
+
+   TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+   The following is an example TCPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   <tcp>
+   <tcp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <sequence number="322622954"/>
+   <acknowledgement number="689715995"/>
+   <offset number=""/>
+   <reserved value="0"/>
+   <control syn="1" ack="1"/>
+   <window size="1"/>
+   <urgent pointer="0"/>
+   <checksum value="2988"/>
+   <tcp.options>
+   <tcp.end kind="0"/>
+   </tcp.options>
+   <padding pad="0"/>
+   </tcp.header>
+   <payload>
+   </payload>
+   </tcp>
+
+4.   UDPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+   A number of items have changed from the original UDP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 5]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   To calculate the length and checksum fields of the UDP element, a
+   canonicalized form of the element MUST be used as in section 2.1.  An
+   iterative method SHOULD be used to calculate checksums as in section
+   2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+   UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+   The following is an example UDPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   <udp>
+   <udp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <udp.length value="143"/>
+   <checksum value="2988"/>
+   </udp.header>
+   <payload>
+   </payload>
+   </udp>
+
+5.   Network Transport
+
+   This document provides for the transmission of BLOAT datagrams over
+   two common families of physical layer transport.  Future RFCs will
+   address additional transports as routing vendors catch up to the
+   specification, and we begin to see BLOAT routed across the Internet
+   backbone.
+
+5.1. Ethernet
+
+   BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+   exception that the type field of the Ethernet frame MUST contain the
+   value 0xBEEF.  The first 5 octets of the Ethernet frame payload will
+   be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+   BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+   that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy                      Informational                      [Page 6]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+6. Gatewaying over IP
+
+   In order to facilitate the gradual introduction of BLOAT into the
+   public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+   gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+   The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+   Network DTD (7.1.)
+
+   The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+   [XML]) although it is understood that most IPoXML implementations
+   will not need to pull down the DTD, as it will normally be embedded
+   in the implementation, and presents something of a catch-22 if you
+   need to load part of your network protocol over the network.
+
+7.1.  IPoXML DTD
+
+   <!--
+    DTD for IP over XML.
+    Refer to this DTD as:
+
+    <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   -->
+   <!--
+    DTD data types:
+
+      Digits      [0..9]+
+
+      Precedence  "NetworkControl | InternetworkControl |
+                   CRITIC | FlashOverride | Flash | Immediate |
+                   Priority | Routine"
+
+      IP4Addr     "dotted-decimal" notation of [RFC1123]
+
+      Class       [0..3]
+
+      Sec          "Unclassified | Confidential | EFTO | MMMM | PROG |
+                    Restricted | Secret | Top Secret | Reserved"
+
+      Compartments [0..65535]
+
+      Handling     [0..65535]
+
+      TCC          [0..16777216]
+
+   -->
+
+
+
+Kennedy                      Informational                      [Page 7]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ENTITY % Digits "CDATA">
+   <!ENTITY % Precedence "CDATA">
+   <!ENTITY % IP4Addr "CDATA">
+   <!ENTITY % Class "CDATA">
+   <!ENTITY % Sec "CDATA">
+   <!ENTITY % Compartments "CDATA">
+   <!ENTITY % Handling "CDATA">
+   <!ENTITY % TCC "CDATA">
+
+   <!ELEMENT ip (header, payload)>
+
+   <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+                    protocol, checksum, source, destination, options,
+                    padding)>
+   <!-- length of header in 32-bit words -->
+   <!ATTLIST header
+             length %Digits; #REQUIRED>
+
+   <!ELEMENT version EMPTY>
+   <!-- ip version. SHOULD be "4" -->
+   <!ATTLIST version
+             value   %Digits;  #REQUIRED>
+
+   <!ELEMENT tos EMPTY>
+   <!ATTLIST tos
+             precedence   %Precedence;    #REQUIRED
+             delay    (normal | low)  #REQUIRED
+             throughput   (normal | high) #REQUIRED
+             relibility   (normal | high) #REQUIRED
+             reserved     CDATA #FIXED "0">
+
+   <!ELEMENT total.length EMPTY>
+   <!--
+    total length of datagram (header and payload) in octets, MUST be
+    less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+    ethernets).
+   -->
+   <!ATTLIST total.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT id EMPTY>
+   <!-- 0 <= id <= 65,535  -->
+   <!ATTLIST id
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT flags EMPTY>
+   <!-- df = don't fragment, mf = more fragments  -->
+   <!ATTLIST flags
+
+
+
+Kennedy                      Informational                      [Page 8]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+          reserved CDATA  #FIXED "0"
+          df (may|dont)   #REQUIRED
+          mf (last|more)  #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+   <!ATTLIST offset
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT ttl EMPTY>
+   <!-- 0 <= ttl <= 255 -->
+   <!ATTLIST ttl
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT protocol EMPTY>
+   <!-- 0 <= protocol <= 255 (per IANA) -->
+   <!ATTLIST protocol
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT checksum EMPTY>
+   <!-- 0 <= checksum <= 65535 (over header only) -->
+   <!ATTLIST checksum
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT source EMPTY>
+   <!ATTLIST source
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT destination EMPTY>
+   <!ATTLIST destination
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT options ( end | noop | security | loose | strict | record
+                     | stream | timestamp )*>
+
+   <!ELEMENT end EMPTY>
+   <!ATTLIST end
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "0">
+
+   <!ELEMENT noop EMPTY>
+   <!ATTLIST noop
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "1">
+
+   <!ELEMENT security EMPTY>
+
+
+
+Kennedy                      Informational                      [Page 9]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST security
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "2"
+             length CDATA #FIXED "11"
+             security %Sec; #REQUIRED
+             compartments %Compartments; #REQUIRED
+             handling %Handling; #REQUIRED
+             tcc %TCC; #REQUIRED>
+   <!ELEMENT loose (hop)+>
+   <!ATTLIST loose
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "3"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT hop EMPTY>
+   <!ATTLIST hop
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT strict (hop)+>
+   <!ATTLIST strict
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "9"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT record (hop)+>
+   <!ATTLIST record
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "7"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT stream EMPTY>
+   <!-- 0 <= id <= 65,535 -->
+   <!ATTLIST stream
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "8"
+             length CDATA #FIXED "4"
+             id %Digits; #REQUIRED>
+
+   <!ELEMENT timestamp (tstamp)+>
+   <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy                      Informational                     [Page 10]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST timestamp
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "2"
+             number CDATA #FIXED "4"
+             length %Digits;  #REQUIRED
+             pointer %Digits; #REQUIRED
+             oflw %Digits;    #REQUIRED
+             flag (0 | 1 | 3)  #REQUIRED>
+
+   <!ELEMENT tstamp EMPTY>
+   <!ATTLIST tstamp
+             time %Digits;   #REQUIRED
+             address %IP4Addr; #IMPLIED>
+   <!--
+       padding to bring header to 32-bit boundary.
+       pad MUST be "0"*
+    -->
+   <!ELEMENT padding EMPTY>
+   <!ATTLIST padding
+             pad CDATA #REQUIRED>
+
+   <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+        by section 2.1 of this RFC -->
+   <!ELEMENT payload (CDATA)>
+
+7.2.  TCPoXML DTD
+
+   <!--
+      DTD for TCP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   -->
+
+   <!-- the pseudoheader is only included for checksum calculations -->
+   <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+   <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+                         reserved, control, window, checksum, urgent,
+                         tcp.options, padding)>
+
+   <!ELEMENT src EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+   <!ATTLIST src
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT dest EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy                      Informational                     [Page 11]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST dest
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT sequence EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST sequence
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT acknowledgement EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST acknowledgement
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= number <= 255 -->
+   <!ATTLIST offset
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT reserved EMPTY>
+   <!ATTLIST reserved
+             value CDATA #FIXED "0">
+
+   <!ELEMENT control EMPTY>
+   <!ATTLIST control
+             urg (0|1) #IMPLIED
+             ack (0|1) #IMPLIED
+             psh (0|1) #IMPLIED
+             rst (0|1) #IMPLIED
+             syn (0|1) #IMPLIED
+             fin (0|1) #IMPLIED>
+
+   <!ELEMENT window EMPTY>
+   <!-- 0 <= size <= 65,535 -->
+   <!ATTLIST window
+             size %Digits; #REQUIRED>
+
+   <!--
+      checksum as in ip, but with
+      the following pseudo-header added into the tcp element:
+     -->
+   <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+                               tcp.length)>
+
+   <!--
+      tcp header + data length in octets. does not include the size of
+
+      the pseudoheader.
+    -->
+
+
+
+Kennedy                      Informational                     [Page 12]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ELEMENT tcp.length EMPTY>
+   <!ATTLIST tcp.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT urgent EMPTY>
+   <!-- 0 <= pointer <= 65,535 -->
+   <!ATTLIST urgent
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+   <!ELEMENT tcp.end EMPTY>
+   <!ATTLIST tcp.end
+             kind CDATA #FIXED "0">
+
+   <!ELEMENT tcp.noop EMPTY>
+   <!ATTLIST tcp.noop
+             kind CDATA #FIXED "1">
+
+   <!ELEMENT tcp.mss EMPTY>
+   <!ATTLIST tcp.mss
+             kind CDATA #FIXED "2"
+             length CDATA #FIXED "4"
+             size %Digits; #REQUIRED>
+
+7.3.  UDPoXML DTD
+
+   <!--
+      DTD for UDP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   -->
+
+   <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+   <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+   <!ELEMENT udp.pseudoheader (source, destination, protocol,
+                               udp.length)>
+
+   <!--
+      udp header + data length in octets. does not include the size of
+      the pseudoheader.
+    -->
+   <!ELEMENT udp.length EMPTY>
+   <!ATTLIST udp.length
+             value %Digits; #REQUIRED>
+
+
+
+Kennedy                      Informational                     [Page 13]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+8. Security Considerations
+
+   XML, as a subset of SGML, has the same security considerations as
+   specified in SGML Media Types [RFC1874].  Security considerations
+   that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+   not attempt to correct for issues not related to message format.
+
+9.   References
+
+   [JABBER]    Miller, J., "Jabber", draft-miller-jabber-00.txt,
+               February 2002. (Work in Progress)
+
+   [RFC768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+               August 1980.
+
+   [RFC791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
+               September 1981.
+
+   [RFC793]    Postel, J., "Transmission Control Protocol", STD 7, RFC
+               793, September 1981.
+
+   [RFC894]    Hornig, C., "Standard for the Transmission of IP
+               Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+   [RFC1042]   Postel, J. and J. Reynolds, "Standard for the
+               Transmission of IP Datagrams Over IEEE 802 Networks", STD
+               43, RFC 1042, February 1988.
+
+   [RFC1123]   Braden, R., "Requirements for Internet Hosts -
+               Application and Support", RFC 1123, October 1989.
+
+   [RFC1874]   Levinson, E., "SGML Media Types", RFC 1874, December
+               1995.
+
+   [RFC2003]   Perkins, C., "IP Encapsulation within IP", RFC 2003,
+               October 1996.
+
+   [RFC2045]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part One: Format of Internet Message
+               Bodies", RFC 2045, November 1996.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2279]   Yergeau, F., "UTF-8, a transformation format of ISO
+               10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy                      Informational                     [Page 14]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   [RFC2460]   Deering, S. and R. Hinden, "Internet Protocol, Version 6
+               (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC3080]   Rose, M., "The Blocks Extensible Exchange Protocol Core",
+               RFC 3080, March 2001.
+
+   [SOAP]      Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+               Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+               "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+               Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+   [XML]       Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+               Markup Language (XML)" World Wide Web Consortium
+               Recommendation REC- xml-19980210.
+               http://www.w3.org/TR/1998/REC-xml-19980210
+
+10.  Author's Address
+
+   Hugh Kennedy
+   Mimezine
+   1060 West Addison
+   Chicago, IL 60613
+   USA
+
+   EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 15]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 16]
+
+
+
+
+
+
+
+Network Working Group                                         H. Kennedy
+Request for Comments: 3252                                      Mimezine
+Category: Informational                                     1 April 2002
+
+
+                 Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document defines a reformulation of IP and two transport layer
+   protocols (TCP and UDP) as XML applications.
+
+1.   Introduction
+
+1.1. Overview
+
+   This document describes the Binary Lexical Octet Ad-hoc Transport
+   (BLOAT): a reformulation of a widely-deployed network-layer protocol
+   (IP [RFC791]), and two associated transport layer protocols (TCP
+   [RFC793] and UDP [RFC768]) as XML [XML] applications.  It also
+   describes methods for transporting BLOAT over Ethernet and IEEE 802
+   networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+   across the public Internet.
+
+1.2. Motivation
+
+   The wild popularity of XML as a basis for application-level protocols
+   such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+   Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+   investigation into the possibility of extending the use of XML in the
+   protocol stack.  Using XML at both the transport and network layer in
+   addition to the application layer would provide for an amazing amount
+   of power and flexibility while removing dependencies on proprietary
+   and hard-to-understand binary protocols.  This protocol unification
+   would also allow applications to use a single XML parser for all
+   aspects of their operation, eliminating developer time spent figuring
+   out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy                      Informational                      [Page 1]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   parsing to the XML toolset.  The use of XML also mitigates concerns
+   over "network vs. host" byte ordering which is at the root of many
+   network application bugs.
+
+1.3. Relation to Existing Protocols
+
+   The reformulations specified in this RFC follow as closely as
+   possible the spirit of the RFCs on which they are based, and so MAY
+   contain elements or attributes that would not be needed in a pure
+   reworking (e.g. length attributes, which are implicit in XML.)
+
+   The layering of network and transport protocols are maintained in
+   this RFC despite the optimizations that could be made if the line
+   were somewhat blurred (i.e. merging TCP and IP into a single, larger
+   element in the DTD) in order to foster future use of this protocol as
+   a basis for reformulating other protocols (such as ICMP.)
+
+   Other than the encoding, the behavioral aspects of each of the
+   existing protocols remain unchanged.  Routing, address spaces, TCP
+   congestion control, etc. behave as specified in the extant standards.
+   Adapting to new standards and experimental algorithm heuristics for
+   improving performance will become much easier once the move to BLOAT
+   has been completed.
+
+1.4. Requirement Levels
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119
+   [RFC2119].
+
+2.   IPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.
+   IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+   (section 3.) and higher-level application protocols.
+
+   The DTD for this document type can be found in section 7.1.
+
+   The routing of IPoXML can be easily implemented on hosts with an XML
+   parser, as the regular structure lends itself handily to parsing and
+   validation of the document/datagram and then processing the
+   destination address, TTL, and checksum before sending it on to its
+   next-hop.
+
+   The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+   wider deployment of IPv4 and the fact that implementing IPv6 as XML
+   would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy                      Informational                      [Page 2]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+   of RFC 2279 [RFC2279].  All BLOAT document/datagrams MUST be well-
+   formed and include the XMLDecl.
+
+2.1. IP Description
+
+   A number of items have changed (for the better) from the original IP
+   specification.  Bit-masks, where present have been converted into
+   human-readable values.  IP addresses are listed in their dotted-
+   decimal notation [RFC1123].  Length and checksum values are present
+   as decimal integers.
+
+   To calculate the length and checksum fields of the IP element, a
+   canonicalized form of the element MUST be used.  The canonical form
+   SHALL have no whitespace (including newline characters) between
+   elements and only one space character between attributes.  There
+   SHALL NOT be a space following the last attribute in an element.
+
+   An iterative method SHOULD be used to calculate checksums, as the
+   length field will vary based on the size of the checksum.
+
+   The payload element bears special attention.  Due to the character
+   set restrictions of XML, the payload of IP datagrams (which MAY
+   contain arbitrary data) MUST be encoded for transport. This RFC
+   REQUIRES the contents of the payload to be encoded in the base-64
+   encoding of RFC 2045 [RFC2045], but removes the requirement that the
+   encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 3]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+2.2. Example Datagram
+
+   The following is an example IPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   <ip>
+   <header length="474">
+   <version value="4"/>
+   <tos precedence="Routine" delay="Normal" throughput="Normal"
+        relibility="Normal" reserved="0"/>
+   <total.length value="461"/>
+   <id value="1"/>
+   <flags reserved="0" df="dont" mf="last"/>
+   <offset value="0"/>
+   <ttl value="255"/>
+   <protocol value="6"/>
+   <checksum value="8707"/>
+   <source address="10.0.0.22"/>
+   <destination address="10.0.0.1"/>
+   <options>
+   <end copied="0" class="0" number="0"/>
+   </options>
+   <padding pad="0"/>
+   </header>
+   <payload>
+   </payload>
+   </ip>
+
+3.   TCPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+   A number of items have changed from the original TCP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+   To calculate the length and checksum fields of the TCP element, a
+   canonicalized form of the element MUST be used as in section 2.1.
+
+   An iterative method SHOULD be used to calculate checksums as in
+   section 2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy                      Informational                      [Page 4]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   The TCP offset element was expanded to a maximum of 255 from 16 to
+   allow for the increased size of the header in XML.
+
+   TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+   The following is an example TCPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   <tcp>
+   <tcp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <sequence number="322622954"/>
+   <acknowledgement number="689715995"/>
+   <offset number=""/>
+   <reserved value="0"/>
+   <control syn="1" ack="1"/>
+   <window size="1"/>
+   <urgent pointer="0"/>
+   <checksum value="2988"/>
+   <tcp.options>
+   <tcp.end kind="0"/>
+   </tcp.options>
+   <padding pad="0"/>
+   </tcp.header>
+   <payload>
+   </payload>
+   </tcp>
+
+4.   UDPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+   A number of items have changed from the original UDP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 5]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   To calculate the length and checksum fields of the UDP element, a
+   canonicalized form of the element MUST be used as in section 2.1.  An
+   iterative method SHOULD be used to calculate checksums as in section
+   2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+   UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+   The following is an example UDPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   <udp>
+   <udp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <udp.length value="143"/>
+   <checksum value="2988"/>
+   </udp.header>
+   <payload>
+   </payload>
+   </udp>
+
+5.   Network Transport
+
+   This document provides for the transmission of BLOAT datagrams over
+   two common families of physical layer transport.  Future RFCs will
+   address additional transports as routing vendors catch up to the
+   specification, and we begin to see BLOAT routed across the Internet
+   backbone.
+
+5.1. Ethernet
+
+   BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+   exception that the type field of the Ethernet frame MUST contain the
+   value 0xBEEF.  The first 5 octets of the Ethernet frame payload will
+   be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+   BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+   that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy                      Informational                      [Page 6]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+6. Gatewaying over IP
+
+   In order to facilitate the gradual introduction of BLOAT into the
+   public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+   gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+   The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+   Network DTD (7.1.)
+
+   The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+   [XML]) although it is understood that most IPoXML implementations
+   will not need to pull down the DTD, as it will normally be embedded
+   in the implementation, and presents something of a catch-22 if you
+   need to load part of your network protocol over the network.
+
+7.1.  IPoXML DTD
+
+   <!--
+    DTD for IP over XML.
+    Refer to this DTD as:
+
+    <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   -->
+   <!--
+    DTD data types:
+
+      Digits      [0..9]+
+
+      Precedence  "NetworkControl | InternetworkControl |
+                   CRITIC | FlashOverride | Flash | Immediate |
+                   Priority | Routine"
+
+      IP4Addr     "dotted-decimal" notation of [RFC1123]
+
+      Class       [0..3]
+
+      Sec          "Unclassified | Confidential | EFTO | MMMM | PROG |
+                    Restricted | Secret | Top Secret | Reserved"
+
+      Compartments [0..65535]
+
+      Handling     [0..65535]
+
+      TCC          [0..16777216]
+
+   -->
+
+
+
+Kennedy                      Informational                      [Page 7]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ENTITY % Digits "CDATA">
+   <!ENTITY % Precedence "CDATA">
+   <!ENTITY % IP4Addr "CDATA">
+   <!ENTITY % Class "CDATA">
+   <!ENTITY % Sec "CDATA">
+   <!ENTITY % Compartments "CDATA">
+   <!ENTITY % Handling "CDATA">
+   <!ENTITY % TCC "CDATA">
+
+   <!ELEMENT ip (header, payload)>
+
+   <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+                    protocol, checksum, source, destination, options,
+                    padding)>
+   <!-- length of header in 32-bit words -->
+   <!ATTLIST header
+             length %Digits; #REQUIRED>
+
+   <!ELEMENT version EMPTY>
+   <!-- ip version. SHOULD be "4" -->
+   <!ATTLIST version
+             value   %Digits;  #REQUIRED>
+
+   <!ELEMENT tos EMPTY>
+   <!ATTLIST tos
+             precedence   %Precedence;    #REQUIRED
+             delay    (normal | low)  #REQUIRED
+             throughput   (normal | high) #REQUIRED
+             relibility   (normal | high) #REQUIRED
+             reserved     CDATA #FIXED "0">
+
+   <!ELEMENT total.length EMPTY>
+   <!--
+    total length of datagram (header and payload) in octets, MUST be
+    less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+    ethernets).
+   -->
+   <!ATTLIST total.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT id EMPTY>
+   <!-- 0 <= id <= 65,535  -->
+   <!ATTLIST id
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT flags EMPTY>
+   <!-- df = don't fragment, mf = more fragments  -->
+   <!ATTLIST flags
+
+
+
+Kennedy                      Informational                      [Page 8]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+          reserved CDATA  #FIXED "0"
+          df (may|dont)   #REQUIRED
+          mf (last|more)  #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+   <!ATTLIST offset
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT ttl EMPTY>
+   <!-- 0 <= ttl <= 255 -->
+   <!ATTLIST ttl
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT protocol EMPTY>
+   <!-- 0 <= protocol <= 255 (per IANA) -->
+   <!ATTLIST protocol
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT checksum EMPTY>
+   <!-- 0 <= checksum <= 65535 (over header only) -->
+   <!ATTLIST checksum
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT source EMPTY>
+   <!ATTLIST source
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT destination EMPTY>
+   <!ATTLIST destination
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT options ( end | noop | security | loose | strict | record
+                     | stream | timestamp )*>
+
+   <!ELEMENT end EMPTY>
+   <!ATTLIST end
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "0">
+
+   <!ELEMENT noop EMPTY>
+   <!ATTLIST noop
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "1">
+
+   <!ELEMENT security EMPTY>
+
+
+
+Kennedy                      Informational                      [Page 9]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST security
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "2"
+             length CDATA #FIXED "11"
+             security %Sec; #REQUIRED
+             compartments %Compartments; #REQUIRED
+             handling %Handling; #REQUIRED
+             tcc %TCC; #REQUIRED>
+   <!ELEMENT loose (hop)+>
+   <!ATTLIST loose
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "3"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT hop EMPTY>
+   <!ATTLIST hop
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT strict (hop)+>
+   <!ATTLIST strict
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "9"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT record (hop)+>
+   <!ATTLIST record
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "7"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT stream EMPTY>
+   <!-- 0 <= id <= 65,535 -->
+   <!ATTLIST stream
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "8"
+             length CDATA #FIXED "4"
+             id %Digits; #REQUIRED>
+
+   <!ELEMENT timestamp (tstamp)+>
+   <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy                      Informational                     [Page 10]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST timestamp
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "2"
+             number CDATA #FIXED "4"
+             length %Digits;  #REQUIRED
+             pointer %Digits; #REQUIRED
+             oflw %Digits;    #REQUIRED
+             flag (0 | 1 | 3)  #REQUIRED>
+
+   <!ELEMENT tstamp EMPTY>
+   <!ATTLIST tstamp
+             time %Digits;   #REQUIRED
+             address %IP4Addr; #IMPLIED>
+   <!--
+       padding to bring header to 32-bit boundary.
+       pad MUST be "0"*
+    -->
+   <!ELEMENT padding EMPTY>
+   <!ATTLIST padding
+             pad CDATA #REQUIRED>
+
+   <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+        by section 2.1 of this RFC -->
+   <!ELEMENT payload (CDATA)>
+
+7.2.  TCPoXML DTD
+
+   <!--
+      DTD for TCP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   -->
+
+   <!-- the pseudoheader is only included for checksum calculations -->
+   <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+   <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+                         reserved, control, window, checksum, urgent,
+                         tcp.options, padding)>
+
+   <!ELEMENT src EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+   <!ATTLIST src
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT dest EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy                      Informational                     [Page 11]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST dest
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT sequence EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST sequence
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT acknowledgement EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST acknowledgement
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= number <= 255 -->
+   <!ATTLIST offset
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT reserved EMPTY>
+   <!ATTLIST reserved
+             value CDATA #FIXED "0">
+
+   <!ELEMENT control EMPTY>
+   <!ATTLIST control
+             urg (0|1) #IMPLIED
+             ack (0|1) #IMPLIED
+             psh (0|1) #IMPLIED
+             rst (0|1) #IMPLIED
+             syn (0|1) #IMPLIED
+             fin (0|1) #IMPLIED>
+
+   <!ELEMENT window EMPTY>
+   <!-- 0 <= size <= 65,535 -->
+   <!ATTLIST window
+             size %Digits; #REQUIRED>
+
+   <!--
+      checksum as in ip, but with
+      the following pseudo-header added into the tcp element:
+     -->
+   <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+                               tcp.length)>
+
+   <!--
+      tcp header + data length in octets. does not include the size of
+
+      the pseudoheader.
+    -->
+
+
+
+Kennedy                      Informational                     [Page 12]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ELEMENT tcp.length EMPTY>
+   <!ATTLIST tcp.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT urgent EMPTY>
+   <!-- 0 <= pointer <= 65,535 -->
+   <!ATTLIST urgent
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+   <!ELEMENT tcp.end EMPTY>
+   <!ATTLIST tcp.end
+             kind CDATA #FIXED "0">
+
+   <!ELEMENT tcp.noop EMPTY>
+   <!ATTLIST tcp.noop
+             kind CDATA #FIXED "1">
+
+   <!ELEMENT tcp.mss EMPTY>
+   <!ATTLIST tcp.mss
+             kind CDATA #FIXED "2"
+             length CDATA #FIXED "4"
+             size %Digits; #REQUIRED>
+
+7.3.  UDPoXML DTD
+
+   <!--
+      DTD for UDP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   -->
+
+   <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+   <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+   <!ELEMENT udp.pseudoheader (source, destination, protocol,
+                               udp.length)>
+
+   <!--
+      udp header + data length in octets. does not include the size of
+      the pseudoheader.
+    -->
+   <!ELEMENT udp.length EMPTY>
+   <!ATTLIST udp.length
+             value %Digits; #REQUIRED>
+
+
+
+Kennedy                      Informational                     [Page 13]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+8. Security Considerations
+
+   XML, as a subset of SGML, has the same security considerations as
+   specified in SGML Media Types [RFC1874].  Security considerations
+   that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+   not attempt to correct for issues not related to message format.
+
+9.   References
+
+   [JABBER]    Miller, J., "Jabber", draft-miller-jabber-00.txt,
+               February 2002. (Work in Progress)
+
+   [RFC768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+               August 1980.
+
+   [RFC791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
+               September 1981.
+
+   [RFC793]    Postel, J., "Transmission Control Protocol", STD 7, RFC
+               793, September 1981.
+
+   [RFC894]    Hornig, C., "Standard for the Transmission of IP
+               Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+   [RFC1042]   Postel, J. and J. Reynolds, "Standard for the
+               Transmission of IP Datagrams Over IEEE 802 Networks", STD
+               43, RFC 1042, February 1988.
+
+   [RFC1123]   Braden, R., "Requirements for Internet Hosts -
+               Application and Support", RFC 1123, October 1989.
+
+   [RFC1874]   Levinson, E., "SGML Media Types", RFC 1874, December
+               1995.
+
+   [RFC2003]   Perkins, C., "IP Encapsulation within IP", RFC 2003,
+               October 1996.
+
+   [RFC2045]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part One: Format of Internet Message
+               Bodies", RFC 2045, November 1996.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2279]   Yergeau, F., "UTF-8, a transformation format of ISO
+               10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy                      Informational                     [Page 14]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   [RFC2460]   Deering, S. and R. Hinden, "Internet Protocol, Version 6
+               (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC3080]   Rose, M., "The Blocks Extensible Exchange Protocol Core",
+               RFC 3080, March 2001.
+
+   [SOAP]      Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+               Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+               "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+               Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+   [XML]       Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+               Markup Language (XML)" World Wide Web Consortium
+               Recommendation REC- xml-19980210.
+               http://www.w3.org/TR/1998/REC-xml-19980210
+
+10.  Author's Address
+
+   Hugh Kennedy
+   Mimezine
+   1060 West Addison
+   Chicago, IL 60613
+   USA
+
+   EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 15]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 16]
+
+
+
+
+
+
+
+Network Working Group                                         H. Kennedy
+Request for Comments: 3252                                      Mimezine
+Category: Informational                                     1 April 2002
+
+
+                 Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document defines a reformulation of IP and two transport layer
+   protocols (TCP and UDP) as XML applications.
+
+1.   Introduction
+
+1.1. Overview
+
+   This document describes the Binary Lexical Octet Ad-hoc Transport
+   (BLOAT): a reformulation of a widely-deployed network-layer protocol
+   (IP [RFC791]), and two associated transport layer protocols (TCP
+   [RFC793] and UDP [RFC768]) as XML [XML] applications.  It also
+   describes methods for transporting BLOAT over Ethernet and IEEE 802
+   networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+   across the public Internet.
+
+1.2. Motivation
+
+   The wild popularity of XML as a basis for application-level protocols
+   such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+   Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+   investigation into the possibility of extending the use of XML in the
+   protocol stack.  Using XML at both the transport and network layer in
+   addition to the application layer would provide for an amazing amount
+   of power and flexibility while removing dependencies on proprietary
+   and hard-to-understand binary protocols.  This protocol unification
+   would also allow applications to use a single XML parser for all
+   aspects of their operation, eliminating developer time spent figuring
+   out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy                      Informational                      [Page 1]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   parsing to the XML toolset.  The use of XML also mitigates concerns
+   over "network vs. host" byte ordering which is at the root of many
+   network application bugs.
+
+1.3. Relation to Existing Protocols
+
+   The reformulations specified in this RFC follow as closely as
+   possible the spirit of the RFCs on which they are based, and so MAY
+   contain elements or attributes that would not be needed in a pure
+   reworking (e.g. length attributes, which are implicit in XML.)
+
+   The layering of network and transport protocols are maintained in
+   this RFC despite the optimizations that could be made if the line
+   were somewhat blurred (i.e. merging TCP and IP into a single, larger
+   element in the DTD) in order to foster future use of this protocol as
+   a basis for reformulating other protocols (such as ICMP.)
+
+   Other than the encoding, the behavioral aspects of each of the
+   existing protocols remain unchanged.  Routing, address spaces, TCP
+   congestion control, etc. behave as specified in the extant standards.
+   Adapting to new standards and experimental algorithm heuristics for
+   improving performance will become much easier once the move to BLOAT
+   has been completed.
+
+1.4. Requirement Levels
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119
+   [RFC2119].
+
+2.   IPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.
+   IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+   (section 3.) and higher-level application protocols.
+
+   The DTD for this document type can be found in section 7.1.
+
+   The routing of IPoXML can be easily implemented on hosts with an XML
+   parser, as the regular structure lends itself handily to parsing and
+   validation of the document/datagram and then processing the
+   destination address, TTL, and checksum before sending it on to its
+   next-hop.
+
+   The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+   wider deployment of IPv4 and the fact that implementing IPv6 as XML
+   would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy                      Informational                      [Page 2]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+   of RFC 2279 [RFC2279].  All BLOAT document/datagrams MUST be well-
+   formed and include the XMLDecl.
+
+2.1. IP Description
+
+   A number of items have changed (for the better) from the original IP
+   specification.  Bit-masks, where present have been converted into
+   human-readable values.  IP addresses are listed in their dotted-
+   decimal notation [RFC1123].  Length and checksum values are present
+   as decimal integers.
+
+   To calculate the length and checksum fields of the IP element, a
+   canonicalized form of the element MUST be used.  The canonical form
+   SHALL have no whitespace (including newline characters) between
+   elements and only one space character between attributes.  There
+   SHALL NOT be a space following the last attribute in an element.
+
+   An iterative method SHOULD be used to calculate checksums, as the
+   length field will vary based on the size of the checksum.
+
+   The payload element bears special attention.  Due to the character
+   set restrictions of XML, the payload of IP datagrams (which MAY
+   contain arbitrary data) MUST be encoded for transport. This RFC
+   REQUIRES the contents of the payload to be encoded in the base-64
+   encoding of RFC 2045 [RFC2045], but removes the requirement that the
+   encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 3]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+2.2. Example Datagram
+
+   The following is an example IPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   <ip>
+   <header length="474">
+   <version value="4"/>
+   <tos precedence="Routine" delay="Normal" throughput="Normal"
+        relibility="Normal" reserved="0"/>
+   <total.length value="461"/>
+   <id value="1"/>
+   <flags reserved="0" df="dont" mf="last"/>
+   <offset value="0"/>
+   <ttl value="255"/>
+   <protocol value="6"/>
+   <checksum value="8707"/>
+   <source address="10.0.0.22"/>
+   <destination address="10.0.0.1"/>
+   <options>
+   <end copied="0" class="0" number="0"/>
+   </options>
+   <padding pad="0"/>
+   </header>
+   <payload>
+   </payload>
+   </ip>
+
+3.   TCPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+   A number of items have changed from the original TCP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+   To calculate the length and checksum fields of the TCP element, a
+   canonicalized form of the element MUST be used as in section 2.1.
+
+   An iterative method SHOULD be used to calculate checksums as in
+   section 2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy                      Informational                      [Page 4]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   The TCP offset element was expanded to a maximum of 255 from 16 to
+   allow for the increased size of the header in XML.
+
+   TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+   The following is an example TCPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   <tcp>
+   <tcp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <sequence number="322622954"/>
+   <acknowledgement number="689715995"/>
+   <offset number=""/>
+   <reserved value="0"/>
+   <control syn="1" ack="1"/>
+   <window size="1"/>
+   <urgent pointer="0"/>
+   <checksum value="2988"/>
+   <tcp.options>
+   <tcp.end kind="0"/>
+   </tcp.options>
+   <padding pad="0"/>
+   </tcp.header>
+   <payload>
+   </payload>
+   </tcp>
+
+4.   UDPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+   A number of items have changed from the original UDP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 5]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   To calculate the length and checksum fields of the UDP element, a
+   canonicalized form of the element MUST be used as in section 2.1.  An
+   iterative method SHOULD be used to calculate checksums as in section
+   2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+   UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+   The following is an example UDPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   <udp>
+   <udp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <udp.length value="143"/>
+   <checksum value="2988"/>
+   </udp.header>
+   <payload>
+   </payload>
+   </udp>
+
+5.   Network Transport
+
+   This document provides for the transmission of BLOAT datagrams over
+   two common families of physical layer transport.  Future RFCs will
+   address additional transports as routing vendors catch up to the
+   specification, and we begin to see BLOAT routed across the Internet
+   backbone.
+
+5.1. Ethernet
+
+   BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+   exception that the type field of the Ethernet frame MUST contain the
+   value 0xBEEF.  The first 5 octets of the Ethernet frame payload will
+   be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+   BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+   that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy                      Informational                      [Page 6]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+6. Gatewaying over IP
+
+   In order to facilitate the gradual introduction of BLOAT into the
+   public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+   gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+   The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+   Network DTD (7.1.)
+
+   The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+   [XML]) although it is understood that most IPoXML implementations
+   will not need to pull down the DTD, as it will normally be embedded
+   in the implementation, and presents something of a catch-22 if you
+   need to load part of your network protocol over the network.
+
+7.1.  IPoXML DTD
+
+   <!--
+    DTD for IP over XML.
+    Refer to this DTD as:
+
+    <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   -->
+   <!--
+    DTD data types:
+
+      Digits      [0..9]+
+
+      Precedence  "NetworkControl | InternetworkControl |
+                   CRITIC | FlashOverride | Flash | Immediate |
+                   Priority | Routine"
+
+      IP4Addr     "dotted-decimal" notation of [RFC1123]
+
+      Class       [0..3]
+
+      Sec          "Unclassified | Confidential | EFTO | MMMM | PROG |
+                    Restricted | Secret | Top Secret | Reserved"
+
+      Compartments [0..65535]
+
+      Handling     [0..65535]
+
+      TCC          [0..16777216]
+
+   -->
+
+
+
+Kennedy                      Informational                      [Page 7]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ENTITY % Digits "CDATA">
+   <!ENTITY % Precedence "CDATA">
+   <!ENTITY % IP4Addr "CDATA">
+   <!ENTITY % Class "CDATA">
+   <!ENTITY % Sec "CDATA">
+   <!ENTITY % Compartments "CDATA">
+   <!ENTITY % Handling "CDATA">
+   <!ENTITY % TCC "CDATA">
+
+   <!ELEMENT ip (header, payload)>
+
+   <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+                    protocol, checksum, source, destination, options,
+                    padding)>
+   <!-- length of header in 32-bit words -->
+   <!ATTLIST header
+             length %Digits; #REQUIRED>
+
+   <!ELEMENT version EMPTY>
+   <!-- ip version. SHOULD be "4" -->
+   <!ATTLIST version
+             value   %Digits;  #REQUIRED>
+
+   <!ELEMENT tos EMPTY>
+   <!ATTLIST tos
+             precedence   %Precedence;    #REQUIRED
+             delay    (normal | low)  #REQUIRED
+             throughput   (normal | high) #REQUIRED
+             relibility   (normal | high) #REQUIRED
+             reserved     CDATA #FIXED "0">
+
+   <!ELEMENT total.length EMPTY>
+   <!--
+    total length of datagram (header and payload) in octets, MUST be
+    less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+    ethernets).
+   -->
+   <!ATTLIST total.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT id EMPTY>
+   <!-- 0 <= id <= 65,535  -->
+   <!ATTLIST id
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT flags EMPTY>
+   <!-- df = don't fragment, mf = more fragments  -->
+   <!ATTLIST flags
+
+
+
+Kennedy                      Informational                      [Page 8]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+          reserved CDATA  #FIXED "0"
+          df (may|dont)   #REQUIRED
+          mf (last|more)  #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+   <!ATTLIST offset
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT ttl EMPTY>
+   <!-- 0 <= ttl <= 255 -->
+   <!ATTLIST ttl
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT protocol EMPTY>
+   <!-- 0 <= protocol <= 255 (per IANA) -->
+   <!ATTLIST protocol
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT checksum EMPTY>
+   <!-- 0 <= checksum <= 65535 (over header only) -->
+   <!ATTLIST checksum
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT source EMPTY>
+   <!ATTLIST source
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT destination EMPTY>
+   <!ATTLIST destination
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT options ( end | noop | security | loose | strict | record
+                     | stream | timestamp )*>
+
+   <!ELEMENT end EMPTY>
+   <!ATTLIST end
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "0">
+
+   <!ELEMENT noop EMPTY>
+   <!ATTLIST noop
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "1">
+
+   <!ELEMENT security EMPTY>
+
+
+
+Kennedy                      Informational                      [Page 9]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST security
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "2"
+             length CDATA #FIXED "11"
+             security %Sec; #REQUIRED
+             compartments %Compartments; #REQUIRED
+             handling %Handling; #REQUIRED
+             tcc %TCC; #REQUIRED>
+   <!ELEMENT loose (hop)+>
+   <!ATTLIST loose
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "3"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT hop EMPTY>
+   <!ATTLIST hop
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT strict (hop)+>
+   <!ATTLIST strict
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "9"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT record (hop)+>
+   <!ATTLIST record
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "7"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT stream EMPTY>
+   <!-- 0 <= id <= 65,535 -->
+   <!ATTLIST stream
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "8"
+             length CDATA #FIXED "4"
+             id %Digits; #REQUIRED>
+
+   <!ELEMENT timestamp (tstamp)+>
+   <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy                      Informational                     [Page 10]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST timestamp
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "2"
+             number CDATA #FIXED "4"
+             length %Digits;  #REQUIRED
+             pointer %Digits; #REQUIRED
+             oflw %Digits;    #REQUIRED
+             flag (0 | 1 | 3)  #REQUIRED>
+
+   <!ELEMENT tstamp EMPTY>
+   <!ATTLIST tstamp
+             time %Digits;   #REQUIRED
+             address %IP4Addr; #IMPLIED>
+   <!--
+       padding to bring header to 32-bit boundary.
+       pad MUST be "0"*
+    -->
+   <!ELEMENT padding EMPTY>
+   <!ATTLIST padding
+             pad CDATA #REQUIRED>
+
+   <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+        by section 2.1 of this RFC -->
+   <!ELEMENT payload (CDATA)>
+
+7.2.  TCPoXML DTD
+
+   <!--
+      DTD for TCP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   -->
+
+   <!-- the pseudoheader is only included for checksum calculations -->
+   <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+   <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+                         reserved, control, window, checksum, urgent,
+                         tcp.options, padding)>
+
+   <!ELEMENT src EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+   <!ATTLIST src
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT dest EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy                      Informational                     [Page 11]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST dest
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT sequence EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST sequence
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT acknowledgement EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST acknowledgement
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= number <= 255 -->
+   <!ATTLIST offset
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT reserved EMPTY>
+   <!ATTLIST reserved
+             value CDATA #FIXED "0">
+
+   <!ELEMENT control EMPTY>
+   <!ATTLIST control
+             urg (0|1) #IMPLIED
+             ack (0|1) #IMPLIED
+             psh (0|1) #IMPLIED
+             rst (0|1) #IMPLIED
+             syn (0|1) #IMPLIED
+             fin (0|1) #IMPLIED>
+
+   <!ELEMENT window EMPTY>
+   <!-- 0 <= size <= 65,535 -->
+   <!ATTLIST window
+             size %Digits; #REQUIRED>
+
+   <!--
+      checksum as in ip, but with
+      the following pseudo-header added into the tcp element:
+     -->
+   <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+                               tcp.length)>
+
+   <!--
+      tcp header + data length in octets. does not include the size of
+
+      the pseudoheader.
+    -->
+
+
+
+Kennedy                      Informational                     [Page 12]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ELEMENT tcp.length EMPTY>
+   <!ATTLIST tcp.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT urgent EMPTY>
+   <!-- 0 <= pointer <= 65,535 -->
+   <!ATTLIST urgent
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+   <!ELEMENT tcp.end EMPTY>
+   <!ATTLIST tcp.end
+             kind CDATA #FIXED "0">
+
+   <!ELEMENT tcp.noop EMPTY>
+   <!ATTLIST tcp.noop
+             kind CDATA #FIXED "1">
+
+   <!ELEMENT tcp.mss EMPTY>
+   <!ATTLIST tcp.mss
+             kind CDATA #FIXED "2"
+             length CDATA #FIXED "4"
+             size %Digits; #REQUIRED>
+
+7.3.  UDPoXML DTD
+
+   <!--
+      DTD for UDP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   -->
+
+   <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+   <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+   <!ELEMENT udp.pseudoheader (source, destination, protocol,
+                               udp.length)>
+
+   <!--
+      udp header + data length in octets. does not include the size of
+      the pseudoheader.
+    -->
+   <!ELEMENT udp.length EMPTY>
+   <!ATTLIST udp.length
+             value %Digits; #REQUIRED>
+
+
+
+Kennedy                      Informational                     [Page 13]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+8. Security Considerations
+
+   XML, as a subset of SGML, has the same security considerations as
+   specified in SGML Media Types [RFC1874].  Security considerations
+   that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+   not attempt to correct for issues not related to message format.
+
+9.   References
+
+   [JABBER]    Miller, J., "Jabber", draft-miller-jabber-00.txt,
+               February 2002. (Work in Progress)
+
+   [RFC768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+               August 1980.
+
+   [RFC791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
+               September 1981.
+
+   [RFC793]    Postel, J., "Transmission Control Protocol", STD 7, RFC
+               793, September 1981.
+
+   [RFC894]    Hornig, C., "Standard for the Transmission of IP
+               Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+   [RFC1042]   Postel, J. and J. Reynolds, "Standard for the
+               Transmission of IP Datagrams Over IEEE 802 Networks", STD
+               43, RFC 1042, February 1988.
+
+   [RFC1123]   Braden, R., "Requirements for Internet Hosts -
+               Application and Support", RFC 1123, October 1989.
+
+   [RFC1874]   Levinson, E., "SGML Media Types", RFC 1874, December
+               1995.
+
+   [RFC2003]   Perkins, C., "IP Encapsulation within IP", RFC 2003,
+               October 1996.
+
+   [RFC2045]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part One: Format of Internet Message
+               Bodies", RFC 2045, November 1996.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2279]   Yergeau, F., "UTF-8, a transformation format of ISO
+               10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy                      Informational                     [Page 14]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   [RFC2460]   Deering, S. and R. Hinden, "Internet Protocol, Version 6
+               (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC3080]   Rose, M., "The Blocks Extensible Exchange Protocol Core",
+               RFC 3080, March 2001.
+
+   [SOAP]      Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+               Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+               "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+               Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+   [XML]       Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+               Markup Language (XML)" World Wide Web Consortium
+               Recommendation REC- xml-19980210.
+               http://www.w3.org/TR/1998/REC-xml-19980210
+
+10.  Author's Address
+
+   Hugh Kennedy
+   Mimezine
+   1060 West Addison
+   Chicago, IL 60613
+   USA
+
+   EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 15]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 16]
+
+
+
+
+
+
+
+Network Working Group                                         H. Kennedy
+Request for Comments: 3252                                      Mimezine
+Category: Informational                                     1 April 2002
+
+
+                 Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document defines a reformulation of IP and two transport layer
+   protocols (TCP and UDP) as XML applications.
+
+1.   Introduction
+
+1.1. Overview
+
+   This document describes the Binary Lexical Octet Ad-hoc Transport
+   (BLOAT): a reformulation of a widely-deployed network-layer protocol
+   (IP [RFC791]), and two associated transport layer protocols (TCP
+   [RFC793] and UDP [RFC768]) as XML [XML] applications.  It also
+   describes methods for transporting BLOAT over Ethernet and IEEE 802
+   networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+   across the public Internet.
+
+1.2. Motivation
+
+   The wild popularity of XML as a basis for application-level protocols
+   such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+   Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+   investigation into the possibility of extending the use of XML in the
+   protocol stack.  Using XML at both the transport and network layer in
+   addition to the application layer would provide for an amazing amount
+   of power and flexibility while removing dependencies on proprietary
+   and hard-to-understand binary protocols.  This protocol unification
+   would also allow applications to use a single XML parser for all
+   aspects of their operation, eliminating developer time spent figuring
+   out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy                      Informational                      [Page 1]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   parsing to the XML toolset.  The use of XML also mitigates concerns
+   over "network vs. host" byte ordering which is at the root of many
+   network application bugs.
+
+1.3. Relation to Existing Protocols
+
+   The reformulations specified in this RFC follow as closely as
+   possible the spirit of the RFCs on which they are based, and so MAY
+   contain elements or attributes that would not be needed in a pure
+   reworking (e.g. length attributes, which are implicit in XML.)
+
+   The layering of network and transport protocols are maintained in
+   this RFC despite the optimizations that could be made if the line
+   were somewhat blurred (i.e. merging TCP and IP into a single, larger
+   element in the DTD) in order to foster future use of this protocol as
+   a basis for reformulating other protocols (such as ICMP.)
+
+   Other than the encoding, the behavioral aspects of each of the
+   existing protocols remain unchanged.  Routing, address spaces, TCP
+   congestion control, etc. behave as specified in the extant standards.
+   Adapting to new standards and experimental algorithm heuristics for
+   improving performance will become much easier once the move to BLOAT
+   has been completed.
+
+1.4. Requirement Levels
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119
+   [RFC2119].
+
+2.   IPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.
+   IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+   (section 3.) and higher-level application protocols.
+
+   The DTD for this document type can be found in section 7.1.
+
+   The routing of IPoXML can be easily implemented on hosts with an XML
+   parser, as the regular structure lends itself handily to parsing and
+   validation of the document/datagram and then processing the
+   destination address, TTL, and checksum before sending it on to its
+   next-hop.
+
+   The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+   wider deployment of IPv4 and the fact that implementing IPv6 as XML
+   would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy                      Informational                      [Page 2]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+   of RFC 2279 [RFC2279].  All BLOAT document/datagrams MUST be well-
+   formed and include the XMLDecl.
+
+2.1. IP Description
+
+   A number of items have changed (for the better) from the original IP
+   specification.  Bit-masks, where present have been converted into
+   human-readable values.  IP addresses are listed in their dotted-
+   decimal notation [RFC1123].  Length and checksum values are present
+   as decimal integers.
+
+   To calculate the length and checksum fields of the IP element, a
+   canonicalized form of the element MUST be used.  The canonical form
+   SHALL have no whitespace (including newline characters) between
+   elements and only one space character between attributes.  There
+   SHALL NOT be a space following the last attribute in an element.
+
+   An iterative method SHOULD be used to calculate checksums, as the
+   length field will vary based on the size of the checksum.
+
+   The payload element bears special attention.  Due to the character
+   set restrictions of XML, the payload of IP datagrams (which MAY
+   contain arbitrary data) MUST be encoded for transport. This RFC
+   REQUIRES the contents of the payload to be encoded in the base-64
+   encoding of RFC 2045 [RFC2045], but removes the requirement that the
+   encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 3]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+2.2. Example Datagram
+
+   The following is an example IPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   <ip>
+   <header length="474">
+   <version value="4"/>
+   <tos precedence="Routine" delay="Normal" throughput="Normal"
+        relibility="Normal" reserved="0"/>
+   <total.length value="461"/>
+   <id value="1"/>
+   <flags reserved="0" df="dont" mf="last"/>
+   <offset value="0"/>
+   <ttl value="255"/>
+   <protocol value="6"/>
+   <checksum value="8707"/>
+   <source address="10.0.0.22"/>
+   <destination address="10.0.0.1"/>
+   <options>
+   <end copied="0" class="0" number="0"/>
+   </options>
+   <padding pad="0"/>
+   </header>
+   <payload>
+   </payload>
+   </ip>
+
+3.   TCPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+   A number of items have changed from the original TCP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+   To calculate the length and checksum fields of the TCP element, a
+   canonicalized form of the element MUST be used as in section 2.1.
+
+   An iterative method SHOULD be used to calculate checksums as in
+   section 2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy                      Informational                      [Page 4]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   The TCP offset element was expanded to a maximum of 255 from 16 to
+   allow for the increased size of the header in XML.
+
+   TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+   The following is an example TCPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   <tcp>
+   <tcp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <sequence number="322622954"/>
+   <acknowledgement number="689715995"/>
+   <offset number=""/>
+   <reserved value="0"/>
+   <control syn="1" ack="1"/>
+   <window size="1"/>
+   <urgent pointer="0"/>
+   <checksum value="2988"/>
+   <tcp.options>
+   <tcp.end kind="0"/>
+   </tcp.options>
+   <padding pad="0"/>
+   </tcp.header>
+   <payload>
+   </payload>
+   </tcp>
+
+4.   UDPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+   A number of items have changed from the original UDP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 5]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   To calculate the length and checksum fields of the UDP element, a
+   canonicalized form of the element MUST be used as in section 2.1.  An
+   iterative method SHOULD be used to calculate checksums as in section
+   2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+   UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+   The following is an example UDPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   <udp>
+   <udp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <udp.length value="143"/>
+   <checksum value="2988"/>
+   </udp.header>
+   <payload>
+   </payload>
+   </udp>
+
+5.   Network Transport
+
+   This document provides for the transmission of BLOAT datagrams over
+   two common families of physical layer transport.  Future RFCs will
+   address additional transports as routing vendors catch up to the
+   specification, and we begin to see BLOAT routed across the Internet
+   backbone.
+
+5.1. Ethernet
+
+   BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+   exception that the type field of the Ethernet frame MUST contain the
+   value 0xBEEF.  The first 5 octets of the Ethernet frame payload will
+   be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+   BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+   that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy                      Informational                      [Page 6]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+6. Gatewaying over IP
+
+   In order to facilitate the gradual introduction of BLOAT into the
+   public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+   gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+   The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+   Network DTD (7.1.)
+
+   The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+   [XML]) although it is understood that most IPoXML implementations
+   will not need to pull down the DTD, as it will normally be embedded
+   in the implementation, and presents something of a catch-22 if you
+   need to load part of your network protocol over the network.
+
+7.1.  IPoXML DTD
+
+   <!--
+    DTD for IP over XML.
+    Refer to this DTD as:
+
+    <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   -->
+   <!--
+    DTD data types:
+
+      Digits      [0..9]+
+
+      Precedence  "NetworkControl | InternetworkControl |
+                   CRITIC | FlashOverride | Flash | Immediate |
+                   Priority | Routine"
+
+      IP4Addr     "dotted-decimal" notation of [RFC1123]
+
+      Class       [0..3]
+
+      Sec          "Unclassified | Confidential | EFTO | MMMM | PROG |
+                    Restricted | Secret | Top Secret | Reserved"
+
+      Compartments [0..65535]
+
+      Handling     [0..65535]
+
+      TCC          [0..16777216]
+
+   -->
+
+
+
+Kennedy                      Informational                      [Page 7]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ENTITY % Digits "CDATA">
+   <!ENTITY % Precedence "CDATA">
+   <!ENTITY % IP4Addr "CDATA">
+   <!ENTITY % Class "CDATA">
+   <!ENTITY % Sec "CDATA">
+   <!ENTITY % Compartments "CDATA">
+   <!ENTITY % Handling "CDATA">
+   <!ENTITY % TCC "CDATA">
+
+   <!ELEMENT ip (header, payload)>
+
+   <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+                    protocol, checksum, source, destination, options,
+                    padding)>
+   <!-- length of header in 32-bit words -->
+   <!ATTLIST header
+             length %Digits; #REQUIRED>
+
+   <!ELEMENT version EMPTY>
+   <!-- ip version. SHOULD be "4" -->
+   <!ATTLIST version
+             value   %Digits;  #REQUIRED>
+
+   <!ELEMENT tos EMPTY>
+   <!ATTLIST tos
+             precedence   %Precedence;    #REQUIRED
+             delay    (normal | low)  #REQUIRED
+             throughput   (normal | high) #REQUIRED
+             relibility   (normal | high) #REQUIRED
+             reserved     CDATA #FIXED "0">
+
+   <!ELEMENT total.length EMPTY>
+   <!--
+    total length of datagram (header and payload) in octets, MUST be
+    less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+    ethernets).
+   -->
+   <!ATTLIST total.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT id EMPTY>
+   <!-- 0 <= id <= 65,535  -->
+   <!ATTLIST id
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT flags EMPTY>
+   <!-- df = don't fragment, mf = more fragments  -->
+   <!ATTLIST flags
+
+
+
+Kennedy                      Informational                      [Page 8]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+          reserved CDATA  #FIXED "0"
+          df (may|dont)   #REQUIRED
+          mf (last|more)  #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+   <!ATTLIST offset
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT ttl EMPTY>
+   <!-- 0 <= ttl <= 255 -->
+   <!ATTLIST ttl
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT protocol EMPTY>
+   <!-- 0 <= protocol <= 255 (per IANA) -->
+   <!ATTLIST protocol
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT checksum EMPTY>
+   <!-- 0 <= checksum <= 65535 (over header only) -->
+   <!ATTLIST checksum
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT source EMPTY>
+   <!ATTLIST source
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT destination EMPTY>
+   <!ATTLIST destination
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT options ( end | noop | security | loose | strict | record
+                     | stream | timestamp )*>
+
+   <!ELEMENT end EMPTY>
+   <!ATTLIST end
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "0">
+
+   <!ELEMENT noop EMPTY>
+   <!ATTLIST noop
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "1">
+
+   <!ELEMENT security EMPTY>
+
+
+
+Kennedy                      Informational                      [Page 9]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST security
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "2"
+             length CDATA #FIXED "11"
+             security %Sec; #REQUIRED
+             compartments %Compartments; #REQUIRED
+             handling %Handling; #REQUIRED
+             tcc %TCC; #REQUIRED>
+   <!ELEMENT loose (hop)+>
+   <!ATTLIST loose
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "3"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT hop EMPTY>
+   <!ATTLIST hop
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT strict (hop)+>
+   <!ATTLIST strict
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "9"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT record (hop)+>
+   <!ATTLIST record
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "7"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT stream EMPTY>
+   <!-- 0 <= id <= 65,535 -->
+   <!ATTLIST stream
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "8"
+             length CDATA #FIXED "4"
+             id %Digits; #REQUIRED>
+
+   <!ELEMENT timestamp (tstamp)+>
+   <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy                      Informational                     [Page 10]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST timestamp
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "2"
+             number CDATA #FIXED "4"
+             length %Digits;  #REQUIRED
+             pointer %Digits; #REQUIRED
+             oflw %Digits;    #REQUIRED
+             flag (0 | 1 | 3)  #REQUIRED>
+
+   <!ELEMENT tstamp EMPTY>
+   <!ATTLIST tstamp
+             time %Digits;   #REQUIRED
+             address %IP4Addr; #IMPLIED>
+   <!--
+       padding to bring header to 32-bit boundary.
+       pad MUST be "0"*
+    -->
+   <!ELEMENT padding EMPTY>
+   <!ATTLIST padding
+             pad CDATA #REQUIRED>
+
+   <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+        by section 2.1 of this RFC -->
+   <!ELEMENT payload (CDATA)>
+
+7.2.  TCPoXML DTD
+
+   <!--
+      DTD for TCP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   -->
+
+   <!-- the pseudoheader is only included for checksum calculations -->
+   <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+   <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+                         reserved, control, window, checksum, urgent,
+                         tcp.options, padding)>
+
+   <!ELEMENT src EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+   <!ATTLIST src
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT dest EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy                      Informational                     [Page 11]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST dest
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT sequence EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST sequence
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT acknowledgement EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST acknowledgement
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= number <= 255 -->
+   <!ATTLIST offset
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT reserved EMPTY>
+   <!ATTLIST reserved
+             value CDATA #FIXED "0">
+
+   <!ELEMENT control EMPTY>
+   <!ATTLIST control
+             urg (0|1) #IMPLIED
+             ack (0|1) #IMPLIED
+             psh (0|1) #IMPLIED
+             rst (0|1) #IMPLIED
+             syn (0|1) #IMPLIED
+             fin (0|1) #IMPLIED>
+
+   <!ELEMENT window EMPTY>
+   <!-- 0 <= size <= 65,535 -->
+   <!ATTLIST window
+             size %Digits; #REQUIRED>
+
+   <!--
+      checksum as in ip, but with
+      the following pseudo-header added into the tcp element:
+     -->
+   <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+                               tcp.length)>
+
+   <!--
+      tcp header + data length in octets. does not include the size of
+
+      the pseudoheader.
+    -->
+
+
+
+Kennedy                      Informational                     [Page 12]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ELEMENT tcp.length EMPTY>
+   <!ATTLIST tcp.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT urgent EMPTY>
+   <!-- 0 <= pointer <= 65,535 -->
+   <!ATTLIST urgent
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+   <!ELEMENT tcp.end EMPTY>
+   <!ATTLIST tcp.end
+             kind CDATA #FIXED "0">
+
+   <!ELEMENT tcp.noop EMPTY>
+   <!ATTLIST tcp.noop
+             kind CDATA #FIXED "1">
+
+   <!ELEMENT tcp.mss EMPTY>
+   <!ATTLIST tcp.mss
+             kind CDATA #FIXED "2"
+             length CDATA #FIXED "4"
+             size %Digits; #REQUIRED>
+
+7.3.  UDPoXML DTD
+
+   <!--
+      DTD for UDP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   -->
+
+   <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+   <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+   <!ELEMENT udp.pseudoheader (source, destination, protocol,
+                               udp.length)>
+
+   <!--
+      udp header + data length in octets. does not include the size of
+      the pseudoheader.
+    -->
+   <!ELEMENT udp.length EMPTY>
+   <!ATTLIST udp.length
+             value %Digits; #REQUIRED>
+
+
+
+Kennedy                      Informational                     [Page 13]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+8. Security Considerations
+
+   XML, as a subset of SGML, has the same security considerations as
+   specified in SGML Media Types [RFC1874].  Security considerations
+   that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+   not attempt to correct for issues not related to message format.
+
+9.   References
+
+   [JABBER]    Miller, J., "Jabber", draft-miller-jabber-00.txt,
+               February 2002. (Work in Progress)
+
+   [RFC768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+               August 1980.
+
+   [RFC791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
+               September 1981.
+
+   [RFC793]    Postel, J., "Transmission Control Protocol", STD 7, RFC
+               793, September 1981.
+
+   [RFC894]    Hornig, C., "Standard for the Transmission of IP
+               Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+   [RFC1042]   Postel, J. and J. Reynolds, "Standard for the
+               Transmission of IP Datagrams Over IEEE 802 Networks", STD
+               43, RFC 1042, February 1988.
+
+   [RFC1123]   Braden, R., "Requirements for Internet Hosts -
+               Application and Support", RFC 1123, October 1989.
+
+   [RFC1874]   Levinson, E., "SGML Media Types", RFC 1874, December
+               1995.
+
+   [RFC2003]   Perkins, C., "IP Encapsulation within IP", RFC 2003,
+               October 1996.
+
+   [RFC2045]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part One: Format of Internet Message
+               Bodies", RFC 2045, November 1996.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2279]   Yergeau, F., "UTF-8, a transformation format of ISO
+               10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy                      Informational                     [Page 14]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   [RFC2460]   Deering, S. and R. Hinden, "Internet Protocol, Version 6
+               (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC3080]   Rose, M., "The Blocks Extensible Exchange Protocol Core",
+               RFC 3080, March 2001.
+
+   [SOAP]      Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+               Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+               "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+               Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+   [XML]       Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+               Markup Language (XML)" World Wide Web Consortium
+               Recommendation REC- xml-19980210.
+               http://www.w3.org/TR/1998/REC-xml-19980210
+
+10.  Author's Address
+
+   Hugh Kennedy
+   Mimezine
+   1060 West Addison
+   Chicago, IL 60613
+   USA
+
+   EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 15]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 16]
+
+
+
+
+
+
+
+Network Working Group                                         H. Kennedy
+Request for Comments: 3252                                      Mimezine
+Category: Informational                                     1 April 2002
+
+
+                 Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document defines a reformulation of IP and two transport layer
+   protocols (TCP and UDP) as XML applications.
+
+1.   Introduction
+
+1.1. Overview
+
+   This document describes the Binary Lexical Octet Ad-hoc Transport
+   (BLOAT): a reformulation of a widely-deployed network-layer protocol
+   (IP [RFC791]), and two associated transport layer protocols (TCP
+   [RFC793] and UDP [RFC768]) as XML [XML] applications.  It also
+   describes methods for transporting BLOAT over Ethernet and IEEE 802
+   networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+   across the public Internet.
+
+1.2. Motivation
+
+   The wild popularity of XML as a basis for application-level protocols
+   such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+   Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+   investigation into the possibility of extending the use of XML in the
+   protocol stack.  Using XML at both the transport and network layer in
+   addition to the application layer would provide for an amazing amount
+   of power and flexibility while removing dependencies on proprietary
+   and hard-to-understand binary protocols.  This protocol unification
+   would also allow applications to use a single XML parser for all
+   aspects of their operation, eliminating developer time spent figuring
+   out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy                      Informational                      [Page 1]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   parsing to the XML toolset.  The use of XML also mitigates concerns
+   over "network vs. host" byte ordering which is at the root of many
+   network application bugs.
+
+1.3. Relation to Existing Protocols
+
+   The reformulations specified in this RFC follow as closely as
+   possible the spirit of the RFCs on which they are based, and so MAY
+   contain elements or attributes that would not be needed in a pure
+   reworking (e.g. length attributes, which are implicit in XML.)
+
+   The layering of network and transport protocols are maintained in
+   this RFC despite the optimizations that could be made if the line
+   were somewhat blurred (i.e. merging TCP and IP into a single, larger
+   element in the DTD) in order to foster future use of this protocol as
+   a basis for reformulating other protocols (such as ICMP.)
+
+   Other than the encoding, the behavioral aspects of each of the
+   existing protocols remain unchanged.  Routing, address spaces, TCP
+   congestion control, etc. behave as specified in the extant standards.
+   Adapting to new standards and experimental algorithm heuristics for
+   improving performance will become much easier once the move to BLOAT
+   has been completed.
+
+1.4. Requirement Levels
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119
+   [RFC2119].
+
+2.   IPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.
+   IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+   (section 3.) and higher-level application protocols.
+
+   The DTD for this document type can be found in section 7.1.
+
+   The routing of IPoXML can be easily implemented on hosts with an XML
+   parser, as the regular structure lends itself handily to parsing and
+   validation of the document/datagram and then processing the
+   destination address, TTL, and checksum before sending it on to its
+   next-hop.
+
+   The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+   wider deployment of IPv4 and the fact that implementing IPv6 as XML
+   would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy                      Informational                      [Page 2]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+   of RFC 2279 [RFC2279].  All BLOAT document/datagrams MUST be well-
+   formed and include the XMLDecl.
+
+2.1. IP Description
+
+   A number of items have changed (for the better) from the original IP
+   specification.  Bit-masks, where present have been converted into
+   human-readable values.  IP addresses are listed in their dotted-
+   decimal notation [RFC1123].  Length and checksum values are present
+   as decimal integers.
+
+   To calculate the length and checksum fields of the IP element, a
+   canonicalized form of the element MUST be used.  The canonical form
+   SHALL have no whitespace (including newline characters) between
+   elements and only one space character between attributes.  There
+   SHALL NOT be a space following the last attribute in an element.
+
+   An iterative method SHOULD be used to calculate checksums, as the
+   length field will vary based on the size of the checksum.
+
+   The payload element bears special attention.  Due to the character
+   set restrictions of XML, the payload of IP datagrams (which MAY
+   contain arbitrary data) MUST be encoded for transport. This RFC
+   REQUIRES the contents of the payload to be encoded in the base-64
+   encoding of RFC 2045 [RFC2045], but removes the requirement that the
+   encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 3]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+2.2. Example Datagram
+
+   The following is an example IPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   <ip>
+   <header length="474">
+   <version value="4"/>
+   <tos precedence="Routine" delay="Normal" throughput="Normal"
+        relibility="Normal" reserved="0"/>
+   <total.length value="461"/>
+   <id value="1"/>
+   <flags reserved="0" df="dont" mf="last"/>
+   <offset value="0"/>
+   <ttl value="255"/>
+   <protocol value="6"/>
+   <checksum value="8707"/>
+   <source address="10.0.0.22"/>
+   <destination address="10.0.0.1"/>
+   <options>
+   <end copied="0" class="0" number="0"/>
+   </options>
+   <padding pad="0"/>
+   </header>
+   <payload>
+   </payload>
+   </ip>
+
+3.   TCPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+   A number of items have changed from the original TCP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+   To calculate the length and checksum fields of the TCP element, a
+   canonicalized form of the element MUST be used as in section 2.1.
+
+   An iterative method SHOULD be used to calculate checksums as in
+   section 2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy                      Informational                      [Page 4]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   The TCP offset element was expanded to a maximum of 255 from 16 to
+   allow for the increased size of the header in XML.
+
+   TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+   The following is an example TCPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   <tcp>
+   <tcp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <sequence number="322622954"/>
+   <acknowledgement number="689715995"/>
+   <offset number=""/>
+   <reserved value="0"/>
+   <control syn="1" ack="1"/>
+   <window size="1"/>
+   <urgent pointer="0"/>
+   <checksum value="2988"/>
+   <tcp.options>
+   <tcp.end kind="0"/>
+   </tcp.options>
+   <padding pad="0"/>
+   </tcp.header>
+   <payload>
+   </payload>
+   </tcp>
+
+4.   UDPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+   A number of items have changed from the original UDP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 5]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   To calculate the length and checksum fields of the UDP element, a
+   canonicalized form of the element MUST be used as in section 2.1.  An
+   iterative method SHOULD be used to calculate checksums as in section
+   2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+   UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+   The following is an example UDPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   <udp>
+   <udp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <udp.length value="143"/>
+   <checksum value="2988"/>
+   </udp.header>
+   <payload>
+   </payload>
+   </udp>
+
+5.   Network Transport
+
+   This document provides for the transmission of BLOAT datagrams over
+   two common families of physical layer transport.  Future RFCs will
+   address additional transports as routing vendors catch up to the
+   specification, and we begin to see BLOAT routed across the Internet
+   backbone.
+
+5.1. Ethernet
+
+   BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+   exception that the type field of the Ethernet frame MUST contain the
+   value 0xBEEF.  The first 5 octets of the Ethernet frame payload will
+   be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+   BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+   that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy                      Informational                      [Page 6]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+6. Gatewaying over IP
+
+   In order to facilitate the gradual introduction of BLOAT into the
+   public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+   gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+   The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+   Network DTD (7.1.)
+
+   The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+   [XML]) although it is understood that most IPoXML implementations
+   will not need to pull down the DTD, as it will normally be embedded
+   in the implementation, and presents something of a catch-22 if you
+   need to load part of your network protocol over the network.
+
+7.1.  IPoXML DTD
+
+   <!--
+    DTD for IP over XML.
+    Refer to this DTD as:
+
+    <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   -->
+   <!--
+    DTD data types:
+
+      Digits      [0..9]+
+
+      Precedence  "NetworkControl | InternetworkControl |
+                   CRITIC | FlashOverride | Flash | Immediate |
+                   Priority | Routine"
+
+      IP4Addr     "dotted-decimal" notation of [RFC1123]
+
+      Class       [0..3]
+
+      Sec          "Unclassified | Confidential | EFTO | MMMM | PROG |
+                    Restricted | Secret | Top Secret | Reserved"
+
+      Compartments [0..65535]
+
+      Handling     [0..65535]
+
+      TCC          [0..16777216]
+
+   -->
+
+
+
+Kennedy                      Informational                      [Page 7]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ENTITY % Digits "CDATA">
+   <!ENTITY % Precedence "CDATA">
+   <!ENTITY % IP4Addr "CDATA">
+   <!ENTITY % Class "CDATA">
+   <!ENTITY % Sec "CDATA">
+   <!ENTITY % Compartments "CDATA">
+   <!ENTITY % Handling "CDATA">
+   <!ENTITY % TCC "CDATA">
+
+   <!ELEMENT ip (header, payload)>
+
+   <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+                    protocol, checksum, source, destination, options,
+                    padding)>
+   <!-- length of header in 32-bit words -->
+   <!ATTLIST header
+             length %Digits; #REQUIRED>
+
+   <!ELEMENT version EMPTY>
+   <!-- ip version. SHOULD be "4" -->
+   <!ATTLIST version
+             value   %Digits;  #REQUIRED>
+
+   <!ELEMENT tos EMPTY>
+   <!ATTLIST tos
+             precedence   %Precedence;    #REQUIRED
+             delay    (normal | low)  #REQUIRED
+             throughput   (normal | high) #REQUIRED
+             relibility   (normal | high) #REQUIRED
+             reserved     CDATA #FIXED "0">
+
+   <!ELEMENT total.length EMPTY>
+   <!--
+    total length of datagram (header and payload) in octets, MUST be
+    less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+    ethernets).
+   -->
+   <!ATTLIST total.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT id EMPTY>
+   <!-- 0 <= id <= 65,535  -->
+   <!ATTLIST id
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT flags EMPTY>
+   <!-- df = don't fragment, mf = more fragments  -->
+   <!ATTLIST flags
+
+
+
+Kennedy                      Informational                      [Page 8]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+          reserved CDATA  #FIXED "0"
+          df (may|dont)   #REQUIRED
+          mf (last|more)  #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+   <!ATTLIST offset
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT ttl EMPTY>
+   <!-- 0 <= ttl <= 255 -->
+   <!ATTLIST ttl
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT protocol EMPTY>
+   <!-- 0 <= protocol <= 255 (per IANA) -->
+   <!ATTLIST protocol
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT checksum EMPTY>
+   <!-- 0 <= checksum <= 65535 (over header only) -->
+   <!ATTLIST checksum
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT source EMPTY>
+   <!ATTLIST source
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT destination EMPTY>
+   <!ATTLIST destination
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT options ( end | noop | security | loose | strict | record
+                     | stream | timestamp )*>
+
+   <!ELEMENT end EMPTY>
+   <!ATTLIST end
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "0">
+
+   <!ELEMENT noop EMPTY>
+   <!ATTLIST noop
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "1">
+
+   <!ELEMENT security EMPTY>
+
+
+
+Kennedy                      Informational                      [Page 9]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST security
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "2"
+             length CDATA #FIXED "11"
+             security %Sec; #REQUIRED
+             compartments %Compartments; #REQUIRED
+             handling %Handling; #REQUIRED
+             tcc %TCC; #REQUIRED>
+   <!ELEMENT loose (hop)+>
+   <!ATTLIST loose
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "3"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT hop EMPTY>
+   <!ATTLIST hop
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT strict (hop)+>
+   <!ATTLIST strict
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "9"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT record (hop)+>
+   <!ATTLIST record
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "7"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT stream EMPTY>
+   <!-- 0 <= id <= 65,535 -->
+   <!ATTLIST stream
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "8"
+             length CDATA #FIXED "4"
+             id %Digits; #REQUIRED>
+
+   <!ELEMENT timestamp (tstamp)+>
+   <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy                      Informational                     [Page 10]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST timestamp
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "2"
+             number CDATA #FIXED "4"
+             length %Digits;  #REQUIRED
+             pointer %Digits; #REQUIRED
+             oflw %Digits;    #REQUIRED
+             flag (0 | 1 | 3)  #REQUIRED>
+
+   <!ELEMENT tstamp EMPTY>
+   <!ATTLIST tstamp
+             time %Digits;   #REQUIRED
+             address %IP4Addr; #IMPLIED>
+   <!--
+       padding to bring header to 32-bit boundary.
+       pad MUST be "0"*
+    -->
+   <!ELEMENT padding EMPTY>
+   <!ATTLIST padding
+             pad CDATA #REQUIRED>
+
+   <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+        by section 2.1 of this RFC -->
+   <!ELEMENT payload (CDATA)>
+
+7.2.  TCPoXML DTD
+
+   <!--
+      DTD for TCP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   -->
+
+   <!-- the pseudoheader is only included for checksum calculations -->
+   <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+   <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+                         reserved, control, window, checksum, urgent,
+                         tcp.options, padding)>
+
+   <!ELEMENT src EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+   <!ATTLIST src
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT dest EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy                      Informational                     [Page 11]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST dest
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT sequence EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST sequence
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT acknowledgement EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST acknowledgement
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= number <= 255 -->
+   <!ATTLIST offset
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT reserved EMPTY>
+   <!ATTLIST reserved
+             value CDATA #FIXED "0">
+
+   <!ELEMENT control EMPTY>
+   <!ATTLIST control
+             urg (0|1) #IMPLIED
+             ack (0|1) #IMPLIED
+             psh (0|1) #IMPLIED
+             rst (0|1) #IMPLIED
+             syn (0|1) #IMPLIED
+             fin (0|1) #IMPLIED>
+
+   <!ELEMENT window EMPTY>
+   <!-- 0 <= size <= 65,535 -->
+   <!ATTLIST window
+             size %Digits; #REQUIRED>
+
+   <!--
+      checksum as in ip, but with
+      the following pseudo-header added into the tcp element:
+     -->
+   <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+                               tcp.length)>
+
+   <!--
+      tcp header + data length in octets. does not include the size of
+
+      the pseudoheader.
+    -->
+
+
+
+Kennedy                      Informational                     [Page 12]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ELEMENT tcp.length EMPTY>
+   <!ATTLIST tcp.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT urgent EMPTY>
+   <!-- 0 <= pointer <= 65,535 -->
+   <!ATTLIST urgent
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+   <!ELEMENT tcp.end EMPTY>
+   <!ATTLIST tcp.end
+             kind CDATA #FIXED "0">
+
+   <!ELEMENT tcp.noop EMPTY>
+   <!ATTLIST tcp.noop
+             kind CDATA #FIXED "1">
+
+   <!ELEMENT tcp.mss EMPTY>
+   <!ATTLIST tcp.mss
+             kind CDATA #FIXED "2"
+             length CDATA #FIXED "4"
+             size %Digits; #REQUIRED>
+
+7.3.  UDPoXML DTD
+
+   <!--
+      DTD for UDP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   -->
+
+   <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+   <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+   <!ELEMENT udp.pseudoheader (source, destination, protocol,
+                               udp.length)>
+
+   <!--
+      udp header + data length in octets. does not include the size of
+      the pseudoheader.
+    -->
+   <!ELEMENT udp.length EMPTY>
+   <!ATTLIST udp.length
+             value %Digits; #REQUIRED>
+
+
+
+Kennedy                      Informational                     [Page 13]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+8. Security Considerations
+
+   XML, as a subset of SGML, has the same security considerations as
+   specified in SGML Media Types [RFC1874].  Security considerations
+   that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+   not attempt to correct for issues not related to message format.
+
+9.   References
+
+   [JABBER]    Miller, J., "Jabber", draft-miller-jabber-00.txt,
+               February 2002. (Work in Progress)
+
+   [RFC768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+               August 1980.
+
+   [RFC791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
+               September 1981.
+
+   [RFC793]    Postel, J., "Transmission Control Protocol", STD 7, RFC
+               793, September 1981.
+
+   [RFC894]    Hornig, C., "Standard for the Transmission of IP
+               Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+   [RFC1042]   Postel, J. and J. Reynolds, "Standard for the
+               Transmission of IP Datagrams Over IEEE 802 Networks", STD
+               43, RFC 1042, February 1988.
+
+   [RFC1123]   Braden, R., "Requirements for Internet Hosts -
+               Application and Support", RFC 1123, October 1989.
+
+   [RFC1874]   Levinson, E., "SGML Media Types", RFC 1874, December
+               1995.
+
+   [RFC2003]   Perkins, C., "IP Encapsulation within IP", RFC 2003,
+               October 1996.
+
+   [RFC2045]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part One: Format of Internet Message
+               Bodies", RFC 2045, November 1996.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2279]   Yergeau, F., "UTF-8, a transformation format of ISO
+               10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy                      Informational                     [Page 14]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   [RFC2460]   Deering, S. and R. Hinden, "Internet Protocol, Version 6
+               (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC3080]   Rose, M., "The Blocks Extensible Exchange Protocol Core",
+               RFC 3080, March 2001.
+
+   [SOAP]      Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+               Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+               "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+               Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+   [XML]       Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+               Markup Language (XML)" World Wide Web Consortium
+               Recommendation REC- xml-19980210.
+               http://www.w3.org/TR/1998/REC-xml-19980210
+
+10.  Author's Address
+
+   Hugh Kennedy
+   Mimezine
+   1060 West Addison
+   Chicago, IL 60613
+   USA
+
+   EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 15]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 16]
+
+
+
+
+
+
+
+Network Working Group                                         H. Kennedy
+Request for Comments: 3252                                      Mimezine
+Category: Informational                                     1 April 2002
+
+
+                 Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document defines a reformulation of IP and two transport layer
+   protocols (TCP and UDP) as XML applications.
+
+1.   Introduction
+
+1.1. Overview
+
+   This document describes the Binary Lexical Octet Ad-hoc Transport
+   (BLOAT): a reformulation of a widely-deployed network-layer protocol
+   (IP [RFC791]), and two associated transport layer protocols (TCP
+   [RFC793] and UDP [RFC768]) as XML [XML] applications.  It also
+   describes methods for transporting BLOAT over Ethernet and IEEE 802
+   networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+   across the public Internet.
+
+1.2. Motivation
+
+   The wild popularity of XML as a basis for application-level protocols
+   such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+   Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+   investigation into the possibility of extending the use of XML in the
+   protocol stack.  Using XML at both the transport and network layer in
+   addition to the application layer would provide for an amazing amount
+   of power and flexibility while removing dependencies on proprietary
+   and hard-to-understand binary protocols.  This protocol unification
+   would also allow applications to use a single XML parser for all
+   aspects of their operation, eliminating developer time spent figuring
+   out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy                      Informational                      [Page 1]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   parsing to the XML toolset.  The use of XML also mitigates concerns
+   over "network vs. host" byte ordering which is at the root of many
+   network application bugs.
+
+1.3. Relation to Existing Protocols
+
+   The reformulations specified in this RFC follow as closely as
+   possible the spirit of the RFCs on which they are based, and so MAY
+   contain elements or attributes that would not be needed in a pure
+   reworking (e.g. length attributes, which are implicit in XML.)
+
+   The layering of network and transport protocols are maintained in
+   this RFC despite the optimizations that could be made if the line
+   were somewhat blurred (i.e. merging TCP and IP into a single, larger
+   element in the DTD) in order to foster future use of this protocol as
+   a basis for reformulating other protocols (such as ICMP.)
+
+   Other than the encoding, the behavioral aspects of each of the
+   existing protocols remain unchanged.  Routing, address spaces, TCP
+   congestion control, etc. behave as specified in the extant standards.
+   Adapting to new standards and experimental algorithm heuristics for
+   improving performance will become much easier once the move to BLOAT
+   has been completed.
+
+1.4. Requirement Levels
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119
+   [RFC2119].
+
+2.   IPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.
+   IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+   (section 3.) and higher-level application protocols.
+
+   The DTD for this document type can be found in section 7.1.
+
+   The routing of IPoXML can be easily implemented on hosts with an XML
+   parser, as the regular structure lends itself handily to parsing and
+   validation of the document/datagram and then processing the
+   destination address, TTL, and checksum before sending it on to its
+   next-hop.
+
+   The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+   wider deployment of IPv4 and the fact that implementing IPv6 as XML
+   would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy                      Informational                      [Page 2]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+   of RFC 2279 [RFC2279].  All BLOAT document/datagrams MUST be well-
+   formed and include the XMLDecl.
+
+2.1. IP Description
+
+   A number of items have changed (for the better) from the original IP
+   specification.  Bit-masks, where present have been converted into
+   human-readable values.  IP addresses are listed in their dotted-
+   decimal notation [RFC1123].  Length and checksum values are present
+   as decimal integers.
+
+   To calculate the length and checksum fields of the IP element, a
+   canonicalized form of the element MUST be used.  The canonical form
+   SHALL have no whitespace (including newline characters) between
+   elements and only one space character between attributes.  There
+   SHALL NOT be a space following the last attribute in an element.
+
+   An iterative method SHOULD be used to calculate checksums, as the
+   length field will vary based on the size of the checksum.
+
+   The payload element bears special attention.  Due to the character
+   set restrictions of XML, the payload of IP datagrams (which MAY
+   contain arbitrary data) MUST be encoded for transport. This RFC
+   REQUIRES the contents of the payload to be encoded in the base-64
+   encoding of RFC 2045 [RFC2045], but removes the requirement that the
+   encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 3]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+2.2. Example Datagram
+
+   The following is an example IPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   <ip>
+   <header length="474">
+   <version value="4"/>
+   <tos precedence="Routine" delay="Normal" throughput="Normal"
+        relibility="Normal" reserved="0"/>
+   <total.length value="461"/>
+   <id value="1"/>
+   <flags reserved="0" df="dont" mf="last"/>
+   <offset value="0"/>
+   <ttl value="255"/>
+   <protocol value="6"/>
+   <checksum value="8707"/>
+   <source address="10.0.0.22"/>
+   <destination address="10.0.0.1"/>
+   <options>
+   <end copied="0" class="0" number="0"/>
+   </options>
+   <padding pad="0"/>
+   </header>
+   <payload>
+   </payload>
+   </ip>
+
+3.   TCPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+   A number of items have changed from the original TCP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+   To calculate the length and checksum fields of the TCP element, a
+   canonicalized form of the element MUST be used as in section 2.1.
+
+   An iterative method SHOULD be used to calculate checksums as in
+   section 2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy                      Informational                      [Page 4]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   The TCP offset element was expanded to a maximum of 255 from 16 to
+   allow for the increased size of the header in XML.
+
+   TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+   The following is an example TCPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   <tcp>
+   <tcp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <sequence number="322622954"/>
+   <acknowledgement number="689715995"/>
+   <offset number=""/>
+   <reserved value="0"/>
+   <control syn="1" ack="1"/>
+   <window size="1"/>
+   <urgent pointer="0"/>
+   <checksum value="2988"/>
+   <tcp.options>
+   <tcp.end kind="0"/>
+   </tcp.options>
+   <padding pad="0"/>
+   </tcp.header>
+   <payload>
+   </payload>
+   </tcp>
+
+4.   UDPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+   A number of items have changed from the original UDP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 5]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   To calculate the length and checksum fields of the UDP element, a
+   canonicalized form of the element MUST be used as in section 2.1.  An
+   iterative method SHOULD be used to calculate checksums as in section
+   2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+   UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+   The following is an example UDPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   <udp>
+   <udp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <udp.length value="143"/>
+   <checksum value="2988"/>
+   </udp.header>
+   <payload>
+   </payload>
+   </udp>
+
+5.   Network Transport
+
+   This document provides for the transmission of BLOAT datagrams over
+   two common families of physical layer transport.  Future RFCs will
+   address additional transports as routing vendors catch up to the
+   specification, and we begin to see BLOAT routed across the Internet
+   backbone.
+
+5.1. Ethernet
+
+   BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+   exception that the type field of the Ethernet frame MUST contain the
+   value 0xBEEF.  The first 5 octets of the Ethernet frame payload will
+   be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+   BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+   that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy                      Informational                      [Page 6]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+6. Gatewaying over IP
+
+   In order to facilitate the gradual introduction of BLOAT into the
+   public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+   gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+   The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+   Network DTD (7.1.)
+
+   The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+   [XML]) although it is understood that most IPoXML implementations
+   will not need to pull down the DTD, as it will normally be embedded
+   in the implementation, and presents something of a catch-22 if you
+   need to load part of your network protocol over the network.
+
+7.1.  IPoXML DTD
+
+   <!--
+    DTD for IP over XML.
+    Refer to this DTD as:
+
+    <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   -->
+   <!--
+    DTD data types:
+
+      Digits      [0..9]+
+
+      Precedence  "NetworkControl | InternetworkControl |
+                   CRITIC | FlashOverride | Flash | Immediate |
+                   Priority | Routine"
+
+      IP4Addr     "dotted-decimal" notation of [RFC1123]
+
+      Class       [0..3]
+
+      Sec          "Unclassified | Confidential | EFTO | MMMM | PROG |
+                    Restricted | Secret | Top Secret | Reserved"
+
+      Compartments [0..65535]
+
+      Handling     [0..65535]
+
+      TCC          [0..16777216]
+
+   -->
+
+
+
+Kennedy                      Informational                      [Page 7]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ENTITY % Digits "CDATA">
+   <!ENTITY % Precedence "CDATA">
+   <!ENTITY % IP4Addr "CDATA">
+   <!ENTITY % Class "CDATA">
+   <!ENTITY % Sec "CDATA">
+   <!ENTITY % Compartments "CDATA">
+   <!ENTITY % Handling "CDATA">
+   <!ENTITY % TCC "CDATA">
+
+   <!ELEMENT ip (header, payload)>
+
+   <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+                    protocol, checksum, source, destination, options,
+                    padding)>
+   <!-- length of header in 32-bit words -->
+   <!ATTLIST header
+             length %Digits; #REQUIRED>
+
+   <!ELEMENT version EMPTY>
+   <!-- ip version. SHOULD be "4" -->
+   <!ATTLIST version
+             value   %Digits;  #REQUIRED>
+
+   <!ELEMENT tos EMPTY>
+   <!ATTLIST tos
+             precedence   %Precedence;    #REQUIRED
+             delay    (normal | low)  #REQUIRED
+             throughput   (normal | high) #REQUIRED
+             relibility   (normal | high) #REQUIRED
+             reserved     CDATA #FIXED "0">
+
+   <!ELEMENT total.length EMPTY>
+   <!--
+    total length of datagram (header and payload) in octets, MUST be
+    less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+    ethernets).
+   -->
+   <!ATTLIST total.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT id EMPTY>
+   <!-- 0 <= id <= 65,535  -->
+   <!ATTLIST id
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT flags EMPTY>
+   <!-- df = don't fragment, mf = more fragments  -->
+   <!ATTLIST flags
+
+
+
+Kennedy                      Informational                      [Page 8]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+          reserved CDATA  #FIXED "0"
+          df (may|dont)   #REQUIRED
+          mf (last|more)  #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+   <!ATTLIST offset
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT ttl EMPTY>
+   <!-- 0 <= ttl <= 255 -->
+   <!ATTLIST ttl
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT protocol EMPTY>
+   <!-- 0 <= protocol <= 255 (per IANA) -->
+   <!ATTLIST protocol
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT checksum EMPTY>
+   <!-- 0 <= checksum <= 65535 (over header only) -->
+   <!ATTLIST checksum
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT source EMPTY>
+   <!ATTLIST source
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT destination EMPTY>
+   <!ATTLIST destination
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT options ( end | noop | security | loose | strict | record
+                     | stream | timestamp )*>
+
+   <!ELEMENT end EMPTY>
+   <!ATTLIST end
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "0">
+
+   <!ELEMENT noop EMPTY>
+   <!ATTLIST noop
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "1">
+
+   <!ELEMENT security EMPTY>
+
+
+
+Kennedy                      Informational                      [Page 9]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST security
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "2"
+             length CDATA #FIXED "11"
+             security %Sec; #REQUIRED
+             compartments %Compartments; #REQUIRED
+             handling %Handling; #REQUIRED
+             tcc %TCC; #REQUIRED>
+   <!ELEMENT loose (hop)+>
+   <!ATTLIST loose
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "3"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT hop EMPTY>
+   <!ATTLIST hop
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT strict (hop)+>
+   <!ATTLIST strict
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "9"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT record (hop)+>
+   <!ATTLIST record
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "7"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT stream EMPTY>
+   <!-- 0 <= id <= 65,535 -->
+   <!ATTLIST stream
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "8"
+             length CDATA #FIXED "4"
+             id %Digits; #REQUIRED>
+
+   <!ELEMENT timestamp (tstamp)+>
+   <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy                      Informational                     [Page 10]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST timestamp
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "2"
+             number CDATA #FIXED "4"
+             length %Digits;  #REQUIRED
+             pointer %Digits; #REQUIRED
+             oflw %Digits;    #REQUIRED
+             flag (0 | 1 | 3)  #REQUIRED>
+
+   <!ELEMENT tstamp EMPTY>
+   <!ATTLIST tstamp
+             time %Digits;   #REQUIRED
+             address %IP4Addr; #IMPLIED>
+   <!--
+       padding to bring header to 32-bit boundary.
+       pad MUST be "0"*
+    -->
+   <!ELEMENT padding EMPTY>
+   <!ATTLIST padding
+             pad CDATA #REQUIRED>
+
+   <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+        by section 2.1 of this RFC -->
+   <!ELEMENT payload (CDATA)>
+
+7.2.  TCPoXML DTD
+
+   <!--
+      DTD for TCP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   -->
+
+   <!-- the pseudoheader is only included for checksum calculations -->
+   <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+   <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+                         reserved, control, window, checksum, urgent,
+                         tcp.options, padding)>
+
+   <!ELEMENT src EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+   <!ATTLIST src
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT dest EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy                      Informational                     [Page 11]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST dest
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT sequence EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST sequence
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT acknowledgement EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST acknowledgement
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= number <= 255 -->
+   <!ATTLIST offset
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT reserved EMPTY>
+   <!ATTLIST reserved
+             value CDATA #FIXED "0">
+
+   <!ELEMENT control EMPTY>
+   <!ATTLIST control
+             urg (0|1) #IMPLIED
+             ack (0|1) #IMPLIED
+             psh (0|1) #IMPLIED
+             rst (0|1) #IMPLIED
+             syn (0|1) #IMPLIED
+             fin (0|1) #IMPLIED>
+
+   <!ELEMENT window EMPTY>
+   <!-- 0 <= size <= 65,535 -->
+   <!ATTLIST window
+             size %Digits; #REQUIRED>
+
+   <!--
+      checksum as in ip, but with
+      the following pseudo-header added into the tcp element:
+     -->
+   <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+                               tcp.length)>
+
+   <!--
+      tcp header + data length in octets. does not include the size of
+
+      the pseudoheader.
+    -->
+
+
+
+Kennedy                      Informational                     [Page 12]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ELEMENT tcp.length EMPTY>
+   <!ATTLIST tcp.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT urgent EMPTY>
+   <!-- 0 <= pointer <= 65,535 -->
+   <!ATTLIST urgent
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+   <!ELEMENT tcp.end EMPTY>
+   <!ATTLIST tcp.end
+             kind CDATA #FIXED "0">
+
+   <!ELEMENT tcp.noop EMPTY>
+   <!ATTLIST tcp.noop
+             kind CDATA #FIXED "1">
+
+   <!ELEMENT tcp.mss EMPTY>
+   <!ATTLIST tcp.mss
+             kind CDATA #FIXED "2"
+             length CDATA #FIXED "4"
+             size %Digits; #REQUIRED>
+
+7.3.  UDPoXML DTD
+
+   <!--
+      DTD for UDP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   -->
+
+   <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+   <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+   <!ELEMENT udp.pseudoheader (source, destination, protocol,
+                               udp.length)>
+
+   <!--
+      udp header + data length in octets. does not include the size of
+      the pseudoheader.
+    -->
+   <!ELEMENT udp.length EMPTY>
+   <!ATTLIST udp.length
+             value %Digits; #REQUIRED>
+
+
+
+Kennedy                      Informational                     [Page 13]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+8. Security Considerations
+
+   XML, as a subset of SGML, has the same security considerations as
+   specified in SGML Media Types [RFC1874].  Security considerations
+   that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+   not attempt to correct for issues not related to message format.
+
+9.   References
+
+   [JABBER]    Miller, J., "Jabber", draft-miller-jabber-00.txt,
+               February 2002. (Work in Progress)
+
+   [RFC768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+               August 1980.
+
+   [RFC791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
+               September 1981.
+
+   [RFC793]    Postel, J., "Transmission Control Protocol", STD 7, RFC
+               793, September 1981.
+
+   [RFC894]    Hornig, C., "Standard for the Transmission of IP
+               Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+   [RFC1042]   Postel, J. and J. Reynolds, "Standard for the
+               Transmission of IP Datagrams Over IEEE 802 Networks", STD
+               43, RFC 1042, February 1988.
+
+   [RFC1123]   Braden, R., "Requirements for Internet Hosts -
+               Application and Support", RFC 1123, October 1989.
+
+   [RFC1874]   Levinson, E., "SGML Media Types", RFC 1874, December
+               1995.
+
+   [RFC2003]   Perkins, C., "IP Encapsulation within IP", RFC 2003,
+               October 1996.
+
+   [RFC2045]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part One: Format of Internet Message
+               Bodies", RFC 2045, November 1996.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2279]   Yergeau, F., "UTF-8, a transformation format of ISO
+               10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy                      Informational                     [Page 14]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   [RFC2460]   Deering, S. and R. Hinden, "Internet Protocol, Version 6
+               (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC3080]   Rose, M., "The Blocks Extensible Exchange Protocol Core",
+               RFC 3080, March 2001.
+
+   [SOAP]      Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+               Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+               "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+               Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+   [XML]       Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+               Markup Language (XML)" World Wide Web Consortium
+               Recommendation REC- xml-19980210.
+               http://www.w3.org/TR/1998/REC-xml-19980210
+
+10.  Author's Address
+
+   Hugh Kennedy
+   Mimezine
+   1060 West Addison
+   Chicago, IL 60613
+   USA
+
+   EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 15]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 16]
+
+
+
+
+
+
+
+Network Working Group                                         H. Kennedy
+Request for Comments: 3252                                      Mimezine
+Category: Informational                                     1 April 2002
+
+
+                 Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document defines a reformulation of IP and two transport layer
+   protocols (TCP and UDP) as XML applications.
+
+1.   Introduction
+
+1.1. Overview
+
+   This document describes the Binary Lexical Octet Ad-hoc Transport
+   (BLOAT): a reformulation of a widely-deployed network-layer protocol
+   (IP [RFC791]), and two associated transport layer protocols (TCP
+   [RFC793] and UDP [RFC768]) as XML [XML] applications.  It also
+   describes methods for transporting BLOAT over Ethernet and IEEE 802
+   networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+   across the public Internet.
+
+1.2. Motivation
+
+   The wild popularity of XML as a basis for application-level protocols
+   such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+   Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+   investigation into the possibility of extending the use of XML in the
+   protocol stack.  Using XML at both the transport and network layer in
+   addition to the application layer would provide for an amazing amount
+   of power and flexibility while removing dependencies on proprietary
+   and hard-to-understand binary protocols.  This protocol unification
+   would also allow applications to use a single XML parser for all
+   aspects of their operation, eliminating developer time spent figuring
+   out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy                      Informational                      [Page 1]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   parsing to the XML toolset.  The use of XML also mitigates concerns
+   over "network vs. host" byte ordering which is at the root of many
+   network application bugs.
+
+1.3. Relation to Existing Protocols
+
+   The reformulations specified in this RFC follow as closely as
+   possible the spirit of the RFCs on which they are based, and so MAY
+   contain elements or attributes that would not be needed in a pure
+   reworking (e.g. length attributes, which are implicit in XML.)
+
+   The layering of network and transport protocols are maintained in
+   this RFC despite the optimizations that could be made if the line
+   were somewhat blurred (i.e. merging TCP and IP into a single, larger
+   element in the DTD) in order to foster future use of this protocol as
+   a basis for reformulating other protocols (such as ICMP.)
+
+   Other than the encoding, the behavioral aspects of each of the
+   existing protocols remain unchanged.  Routing, address spaces, TCP
+   congestion control, etc. behave as specified in the extant standards.
+   Adapting to new standards and experimental algorithm heuristics for
+   improving performance will become much easier once the move to BLOAT
+   has been completed.
+
+1.4. Requirement Levels
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119
+   [RFC2119].
+
+2.   IPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.
+   IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+   (section 3.) and higher-level application protocols.
+
+   The DTD for this document type can be found in section 7.1.
+
+   The routing of IPoXML can be easily implemented on hosts with an XML
+   parser, as the regular structure lends itself handily to parsing and
+   validation of the document/datagram and then processing the
+   destination address, TTL, and checksum before sending it on to its
+   next-hop.
+
+   The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+   wider deployment of IPv4 and the fact that implementing IPv6 as XML
+   would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy                      Informational                      [Page 2]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+   of RFC 2279 [RFC2279].  All BLOAT document/datagrams MUST be well-
+   formed and include the XMLDecl.
+
+2.1. IP Description
+
+   A number of items have changed (for the better) from the original IP
+   specification.  Bit-masks, where present have been converted into
+   human-readable values.  IP addresses are listed in their dotted-
+   decimal notation [RFC1123].  Length and checksum values are present
+   as decimal integers.
+
+   To calculate the length and checksum fields of the IP element, a
+   canonicalized form of the element MUST be used.  The canonical form
+   SHALL have no whitespace (including newline characters) between
+   elements and only one space character between attributes.  There
+   SHALL NOT be a space following the last attribute in an element.
+
+   An iterative method SHOULD be used to calculate checksums, as the
+   length field will vary based on the size of the checksum.
+
+   The payload element bears special attention.  Due to the character
+   set restrictions of XML, the payload of IP datagrams (which MAY
+   contain arbitrary data) MUST be encoded for transport. This RFC
+   REQUIRES the contents of the payload to be encoded in the base-64
+   encoding of RFC 2045 [RFC2045], but removes the requirement that the
+   encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 3]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+2.2. Example Datagram
+
+   The following is an example IPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   <ip>
+   <header length="474">
+   <version value="4"/>
+   <tos precedence="Routine" delay="Normal" throughput="Normal"
+        relibility="Normal" reserved="0"/>
+   <total.length value="461"/>
+   <id value="1"/>
+   <flags reserved="0" df="dont" mf="last"/>
+   <offset value="0"/>
+   <ttl value="255"/>
+   <protocol value="6"/>
+   <checksum value="8707"/>
+   <source address="10.0.0.22"/>
+   <destination address="10.0.0.1"/>
+   <options>
+   <end copied="0" class="0" number="0"/>
+   </options>
+   <padding pad="0"/>
+   </header>
+   <payload>
+   </payload>
+   </ip>
+
+3.   TCPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+   A number of items have changed from the original TCP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+   To calculate the length and checksum fields of the TCP element, a
+   canonicalized form of the element MUST be used as in section 2.1.
+
+   An iterative method SHOULD be used to calculate checksums as in
+   section 2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy                      Informational                      [Page 4]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   The TCP offset element was expanded to a maximum of 255 from 16 to
+   allow for the increased size of the header in XML.
+
+   TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+   The following is an example TCPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   <tcp>
+   <tcp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <sequence number="322622954"/>
+   <acknowledgement number="689715995"/>
+   <offset number=""/>
+   <reserved value="0"/>
+   <control syn="1" ack="1"/>
+   <window size="1"/>
+   <urgent pointer="0"/>
+   <checksum value="2988"/>
+   <tcp.options>
+   <tcp.end kind="0"/>
+   </tcp.options>
+   <padding pad="0"/>
+   </tcp.header>
+   <payload>
+   </payload>
+   </tcp>
+
+4.   UDPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+   A number of items have changed from the original UDP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 5]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   To calculate the length and checksum fields of the UDP element, a
+   canonicalized form of the element MUST be used as in section 2.1.  An
+   iterative method SHOULD be used to calculate checksums as in section
+   2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+   UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+   The following is an example UDPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   <udp>
+   <udp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <udp.length value="143"/>
+   <checksum value="2988"/>
+   </udp.header>
+   <payload>
+   </payload>
+   </udp>
+
+5.   Network Transport
+
+   This document provides for the transmission of BLOAT datagrams over
+   two common families of physical layer transport.  Future RFCs will
+   address additional transports as routing vendors catch up to the
+   specification, and we begin to see BLOAT routed across the Internet
+   backbone.
+
+5.1. Ethernet
+
+   BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+   exception that the type field of the Ethernet frame MUST contain the
+   value 0xBEEF.  The first 5 octets of the Ethernet frame payload will
+   be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+   BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+   that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy                      Informational                      [Page 6]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+6. Gatewaying over IP
+
+   In order to facilitate the gradual introduction of BLOAT into the
+   public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+   gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+   The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+   Network DTD (7.1.)
+
+   The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+   [XML]) although it is understood that most IPoXML implementations
+   will not need to pull down the DTD, as it will normally be embedded
+   in the implementation, and presents something of a catch-22 if you
+   need to load part of your network protocol over the network.
+
+7.1.  IPoXML DTD
+
+   <!--
+    DTD for IP over XML.
+    Refer to this DTD as:
+
+    <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   -->
+   <!--
+    DTD data types:
+
+      Digits      [0..9]+
+
+      Precedence  "NetworkControl | InternetworkControl |
+                   CRITIC | FlashOverride | Flash | Immediate |
+                   Priority | Routine"
+
+      IP4Addr     "dotted-decimal" notation of [RFC1123]
+
+      Class       [0..3]
+
+      Sec          "Unclassified | Confidential | EFTO | MMMM | PROG |
+                    Restricted | Secret | Top Secret | Reserved"
+
+      Compartments [0..65535]
+
+      Handling     [0..65535]
+
+      TCC          [0..16777216]
+
+   -->
+
+
+
+Kennedy                      Informational                      [Page 7]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ENTITY % Digits "CDATA">
+   <!ENTITY % Precedence "CDATA">
+   <!ENTITY % IP4Addr "CDATA">
+   <!ENTITY % Class "CDATA">
+   <!ENTITY % Sec "CDATA">
+   <!ENTITY % Compartments "CDATA">
+   <!ENTITY % Handling "CDATA">
+   <!ENTITY % TCC "CDATA">
+
+   <!ELEMENT ip (header, payload)>
+
+   <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+                    protocol, checksum, source, destination, options,
+                    padding)>
+   <!-- length of header in 32-bit words -->
+   <!ATTLIST header
+             length %Digits; #REQUIRED>
+
+   <!ELEMENT version EMPTY>
+   <!-- ip version. SHOULD be "4" -->
+   <!ATTLIST version
+             value   %Digits;  #REQUIRED>
+
+   <!ELEMENT tos EMPTY>
+   <!ATTLIST tos
+             precedence   %Precedence;    #REQUIRED
+             delay    (normal | low)  #REQUIRED
+             throughput   (normal | high) #REQUIRED
+             relibility   (normal | high) #REQUIRED
+             reserved     CDATA #FIXED "0">
+
+   <!ELEMENT total.length EMPTY>
+   <!--
+    total length of datagram (header and payload) in octets, MUST be
+    less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+    ethernets).
+   -->
+   <!ATTLIST total.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT id EMPTY>
+   <!-- 0 <= id <= 65,535  -->
+   <!ATTLIST id
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT flags EMPTY>
+   <!-- df = don't fragment, mf = more fragments  -->
+   <!ATTLIST flags
+
+
+
+Kennedy                      Informational                      [Page 8]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+          reserved CDATA  #FIXED "0"
+          df (may|dont)   #REQUIRED
+          mf (last|more)  #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+   <!ATTLIST offset
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT ttl EMPTY>
+   <!-- 0 <= ttl <= 255 -->
+   <!ATTLIST ttl
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT protocol EMPTY>
+   <!-- 0 <= protocol <= 255 (per IANA) -->
+   <!ATTLIST protocol
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT checksum EMPTY>
+   <!-- 0 <= checksum <= 65535 (over header only) -->
+   <!ATTLIST checksum
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT source EMPTY>
+   <!ATTLIST source
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT destination EMPTY>
+   <!ATTLIST destination
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT options ( end | noop | security | loose | strict | record
+                     | stream | timestamp )*>
+
+   <!ELEMENT end EMPTY>
+   <!ATTLIST end
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "0">
+
+   <!ELEMENT noop EMPTY>
+   <!ATTLIST noop
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "1">
+
+   <!ELEMENT security EMPTY>
+
+
+
+Kennedy                      Informational                      [Page 9]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST security
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "2"
+             length CDATA #FIXED "11"
+             security %Sec; #REQUIRED
+             compartments %Compartments; #REQUIRED
+             handling %Handling; #REQUIRED
+             tcc %TCC; #REQUIRED>
+   <!ELEMENT loose (hop)+>
+   <!ATTLIST loose
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "3"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT hop EMPTY>
+   <!ATTLIST hop
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT strict (hop)+>
+   <!ATTLIST strict
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "9"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT record (hop)+>
+   <!ATTLIST record
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "7"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT stream EMPTY>
+   <!-- 0 <= id <= 65,535 -->
+   <!ATTLIST stream
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "8"
+             length CDATA #FIXED "4"
+             id %Digits; #REQUIRED>
+
+   <!ELEMENT timestamp (tstamp)+>
+   <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy                      Informational                     [Page 10]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST timestamp
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "2"
+             number CDATA #FIXED "4"
+             length %Digits;  #REQUIRED
+             pointer %Digits; #REQUIRED
+             oflw %Digits;    #REQUIRED
+             flag (0 | 1 | 3)  #REQUIRED>
+
+   <!ELEMENT tstamp EMPTY>
+   <!ATTLIST tstamp
+             time %Digits;   #REQUIRED
+             address %IP4Addr; #IMPLIED>
+   <!--
+       padding to bring header to 32-bit boundary.
+       pad MUST be "0"*
+    -->
+   <!ELEMENT padding EMPTY>
+   <!ATTLIST padding
+             pad CDATA #REQUIRED>
+
+   <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+        by section 2.1 of this RFC -->
+   <!ELEMENT payload (CDATA)>
+
+7.2.  TCPoXML DTD
+
+   <!--
+      DTD for TCP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   -->
+
+   <!-- the pseudoheader is only included for checksum calculations -->
+   <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+   <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+                         reserved, control, window, checksum, urgent,
+                         tcp.options, padding)>
+
+   <!ELEMENT src EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+   <!ATTLIST src
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT dest EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy                      Informational                     [Page 11]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST dest
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT sequence EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST sequence
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT acknowledgement EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST acknowledgement
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= number <= 255 -->
+   <!ATTLIST offset
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT reserved EMPTY>
+   <!ATTLIST reserved
+             value CDATA #FIXED "0">
+
+   <!ELEMENT control EMPTY>
+   <!ATTLIST control
+             urg (0|1) #IMPLIED
+             ack (0|1) #IMPLIED
+             psh (0|1) #IMPLIED
+             rst (0|1) #IMPLIED
+             syn (0|1) #IMPLIED
+             fin (0|1) #IMPLIED>
+
+   <!ELEMENT window EMPTY>
+   <!-- 0 <= size <= 65,535 -->
+   <!ATTLIST window
+             size %Digits; #REQUIRED>
+
+   <!--
+      checksum as in ip, but with
+      the following pseudo-header added into the tcp element:
+     -->
+   <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+                               tcp.length)>
+
+   <!--
+      tcp header + data length in octets. does not include the size of
+
+      the pseudoheader.
+    -->
+
+
+
+Kennedy                      Informational                     [Page 12]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ELEMENT tcp.length EMPTY>
+   <!ATTLIST tcp.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT urgent EMPTY>
+   <!-- 0 <= pointer <= 65,535 -->
+   <!ATTLIST urgent
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+   <!ELEMENT tcp.end EMPTY>
+   <!ATTLIST tcp.end
+             kind CDATA #FIXED "0">
+
+   <!ELEMENT tcp.noop EMPTY>
+   <!ATTLIST tcp.noop
+             kind CDATA #FIXED "1">
+
+   <!ELEMENT tcp.mss EMPTY>
+   <!ATTLIST tcp.mss
+             kind CDATA #FIXED "2"
+             length CDATA #FIXED "4"
+             size %Digits; #REQUIRED>
+
+7.3.  UDPoXML DTD
+
+   <!--
+      DTD for UDP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   -->
+
+   <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+   <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+   <!ELEMENT udp.pseudoheader (source, destination, protocol,
+                               udp.length)>
+
+   <!--
+      udp header + data length in octets. does not include the size of
+      the pseudoheader.
+    -->
+   <!ELEMENT udp.length EMPTY>
+   <!ATTLIST udp.length
+             value %Digits; #REQUIRED>
+
+
+
+Kennedy                      Informational                     [Page 13]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+8. Security Considerations
+
+   XML, as a subset of SGML, has the same security considerations as
+   specified in SGML Media Types [RFC1874].  Security considerations
+   that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+   not attempt to correct for issues not related to message format.
+
+9.   References
+
+   [JABBER]    Miller, J., "Jabber", draft-miller-jabber-00.txt,
+               February 2002. (Work in Progress)
+
+   [RFC768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+               August 1980.
+
+   [RFC791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
+               September 1981.
+
+   [RFC793]    Postel, J., "Transmission Control Protocol", STD 7, RFC
+               793, September 1981.
+
+   [RFC894]    Hornig, C., "Standard for the Transmission of IP
+               Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+   [RFC1042]   Postel, J. and J. Reynolds, "Standard for the
+               Transmission of IP Datagrams Over IEEE 802 Networks", STD
+               43, RFC 1042, February 1988.
+
+   [RFC1123]   Braden, R., "Requirements for Internet Hosts -
+               Application and Support", RFC 1123, October 1989.
+
+   [RFC1874]   Levinson, E., "SGML Media Types", RFC 1874, December
+               1995.
+
+   [RFC2003]   Perkins, C., "IP Encapsulation within IP", RFC 2003,
+               October 1996.
+
+   [RFC2045]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part One: Format of Internet Message
+               Bodies", RFC 2045, November 1996.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2279]   Yergeau, F., "UTF-8, a transformation format of ISO
+               10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy                      Informational                     [Page 14]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   [RFC2460]   Deering, S. and R. Hinden, "Internet Protocol, Version 6
+               (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC3080]   Rose, M., "The Blocks Extensible Exchange Protocol Core",
+               RFC 3080, March 2001.
+
+   [SOAP]      Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+               Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+               "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+               Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+   [XML]       Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+               Markup Language (XML)" World Wide Web Consortium
+               Recommendation REC- xml-19980210.
+               http://www.w3.org/TR/1998/REC-xml-19980210
+
+10.  Author's Address
+
+   Hugh Kennedy
+   Mimezine
+   1060 West Addison
+   Chicago, IL 60613
+   USA
+
+   EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 15]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 16]
+
+
+
+
+
+
+
+Network Working Group                                         H. Kennedy
+Request for Comments: 3252                                      Mimezine
+Category: Informational                                     1 April 2002
+
+
+                 Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document defines a reformulation of IP and two transport layer
+   protocols (TCP and UDP) as XML applications.
+
+1.   Introduction
+
+1.1. Overview
+
+   This document describes the Binary Lexical Octet Ad-hoc Transport
+   (BLOAT): a reformulation of a widely-deployed network-layer protocol
+   (IP [RFC791]), and two associated transport layer protocols (TCP
+   [RFC793] and UDP [RFC768]) as XML [XML] applications.  It also
+   describes methods for transporting BLOAT over Ethernet and IEEE 802
+   networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+   across the public Internet.
+
+1.2. Motivation
+
+   The wild popularity of XML as a basis for application-level protocols
+   such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+   Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+   investigation into the possibility of extending the use of XML in the
+   protocol stack.  Using XML at both the transport and network layer in
+   addition to the application layer would provide for an amazing amount
+   of power and flexibility while removing dependencies on proprietary
+   and hard-to-understand binary protocols.  This protocol unification
+   would also allow applications to use a single XML parser for all
+   aspects of their operation, eliminating developer time spent figuring
+   out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy                      Informational                      [Page 1]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   parsing to the XML toolset.  The use of XML also mitigates concerns
+   over "network vs. host" byte ordering which is at the root of many
+   network application bugs.
+
+1.3. Relation to Existing Protocols
+
+   The reformulations specified in this RFC follow as closely as
+   possible the spirit of the RFCs on which they are based, and so MAY
+   contain elements or attributes that would not be needed in a pure
+   reworking (e.g. length attributes, which are implicit in XML.)
+
+   The layering of network and transport protocols are maintained in
+   this RFC despite the optimizations that could be made if the line
+   were somewhat blurred (i.e. merging TCP and IP into a single, larger
+   element in the DTD) in order to foster future use of this protocol as
+   a basis for reformulating other protocols (such as ICMP.)
+
+   Other than the encoding, the behavioral aspects of each of the
+   existing protocols remain unchanged.  Routing, address spaces, TCP
+   congestion control, etc. behave as specified in the extant standards.
+   Adapting to new standards and experimental algorithm heuristics for
+   improving performance will become much easier once the move to BLOAT
+   has been completed.
+
+1.4. Requirement Levels
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119
+   [RFC2119].
+
+2.   IPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.
+   IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+   (section 3.) and higher-level application protocols.
+
+   The DTD for this document type can be found in section 7.1.
+
+   The routing of IPoXML can be easily implemented on hosts with an XML
+   parser, as the regular structure lends itself handily to parsing and
+   validation of the document/datagram and then processing the
+   destination address, TTL, and checksum before sending it on to its
+   next-hop.
+
+   The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+   wider deployment of IPv4 and the fact that implementing IPv6 as XML
+   would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy                      Informational                      [Page 2]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+   of RFC 2279 [RFC2279].  All BLOAT document/datagrams MUST be well-
+   formed and include the XMLDecl.
+
+2.1. IP Description
+
+   A number of items have changed (for the better) from the original IP
+   specification.  Bit-masks, where present have been converted into
+   human-readable values.  IP addresses are listed in their dotted-
+   decimal notation [RFC1123].  Length and checksum values are present
+   as decimal integers.
+
+   To calculate the length and checksum fields of the IP element, a
+   canonicalized form of the element MUST be used.  The canonical form
+   SHALL have no whitespace (including newline characters) between
+   elements and only one space character between attributes.  There
+   SHALL NOT be a space following the last attribute in an element.
+
+   An iterative method SHOULD be used to calculate checksums, as the
+   length field will vary based on the size of the checksum.
+
+   The payload element bears special attention.  Due to the character
+   set restrictions of XML, the payload of IP datagrams (which MAY
+   contain arbitrary data) MUST be encoded for transport. This RFC
+   REQUIRES the contents of the payload to be encoded in the base-64
+   encoding of RFC 2045 [RFC2045], but removes the requirement that the
+   encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 3]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+2.2. Example Datagram
+
+   The following is an example IPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   <ip>
+   <header length="474">
+   <version value="4"/>
+   <tos precedence="Routine" delay="Normal" throughput="Normal"
+        relibility="Normal" reserved="0"/>
+   <total.length value="461"/>
+   <id value="1"/>
+   <flags reserved="0" df="dont" mf="last"/>
+   <offset value="0"/>
+   <ttl value="255"/>
+   <protocol value="6"/>
+   <checksum value="8707"/>
+   <source address="10.0.0.22"/>
+   <destination address="10.0.0.1"/>
+   <options>
+   <end copied="0" class="0" number="0"/>
+   </options>
+   <padding pad="0"/>
+   </header>
+   <payload>
+   </payload>
+   </ip>
+
+3.   TCPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+   A number of items have changed from the original TCP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+   To calculate the length and checksum fields of the TCP element, a
+   canonicalized form of the element MUST be used as in section 2.1.
+
+   An iterative method SHOULD be used to calculate checksums as in
+   section 2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy                      Informational                      [Page 4]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   The TCP offset element was expanded to a maximum of 255 from 16 to
+   allow for the increased size of the header in XML.
+
+   TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+   The following is an example TCPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   <tcp>
+   <tcp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <sequence number="322622954"/>
+   <acknowledgement number="689715995"/>
+   <offset number=""/>
+   <reserved value="0"/>
+   <control syn="1" ack="1"/>
+   <window size="1"/>
+   <urgent pointer="0"/>
+   <checksum value="2988"/>
+   <tcp.options>
+   <tcp.end kind="0"/>
+   </tcp.options>
+   <padding pad="0"/>
+   </tcp.header>
+   <payload>
+   </payload>
+   </tcp>
+
+4.   UDPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+   A number of items have changed from the original UDP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 5]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   To calculate the length and checksum fields of the UDP element, a
+   canonicalized form of the element MUST be used as in section 2.1.  An
+   iterative method SHOULD be used to calculate checksums as in section
+   2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+   UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+   The following is an example UDPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   <udp>
+   <udp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <udp.length value="143"/>
+   <checksum value="2988"/>
+   </udp.header>
+   <payload>
+   </payload>
+   </udp>
+
+5.   Network Transport
+
+   This document provides for the transmission of BLOAT datagrams over
+   two common families of physical layer transport.  Future RFCs will
+   address additional transports as routing vendors catch up to the
+   specification, and we begin to see BLOAT routed across the Internet
+   backbone.
+
+5.1. Ethernet
+
+   BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+   exception that the type field of the Ethernet frame MUST contain the
+   value 0xBEEF.  The first 5 octets of the Ethernet frame payload will
+   be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+   BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+   that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy                      Informational                      [Page 6]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+6. Gatewaying over IP
+
+   In order to facilitate the gradual introduction of BLOAT into the
+   public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+   gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+   The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+   Network DTD (7.1.)
+
+   The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+   [XML]) although it is understood that most IPoXML implementations
+   will not need to pull down the DTD, as it will normally be embedded
+   in the implementation, and presents something of a catch-22 if you
+   need to load part of your network protocol over the network.
+
+7.1.  IPoXML DTD
+
+   <!--
+    DTD for IP over XML.
+    Refer to this DTD as:
+
+    <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   -->
+   <!--
+    DTD data types:
+
+      Digits      [0..9]+
+
+      Precedence  "NetworkControl | InternetworkControl |
+                   CRITIC | FlashOverride | Flash | Immediate |
+                   Priority | Routine"
+
+      IP4Addr     "dotted-decimal" notation of [RFC1123]
+
+      Class       [0..3]
+
+      Sec          "Unclassified | Confidential | EFTO | MMMM | PROG |
+                    Restricted | Secret | Top Secret | Reserved"
+
+      Compartments [0..65535]
+
+      Handling     [0..65535]
+
+      TCC          [0..16777216]
+
+   -->
+
+
+
+Kennedy                      Informational                      [Page 7]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ENTITY % Digits "CDATA">
+   <!ENTITY % Precedence "CDATA">
+   <!ENTITY % IP4Addr "CDATA">
+   <!ENTITY % Class "CDATA">
+   <!ENTITY % Sec "CDATA">
+   <!ENTITY % Compartments "CDATA">
+   <!ENTITY % Handling "CDATA">
+   <!ENTITY % TCC "CDATA">
+
+   <!ELEMENT ip (header, payload)>
+
+   <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+                    protocol, checksum, source, destination, options,
+                    padding)>
+   <!-- length of header in 32-bit words -->
+   <!ATTLIST header
+             length %Digits; #REQUIRED>
+
+   <!ELEMENT version EMPTY>
+   <!-- ip version. SHOULD be "4" -->
+   <!ATTLIST version
+             value   %Digits;  #REQUIRED>
+
+   <!ELEMENT tos EMPTY>
+   <!ATTLIST tos
+             precedence   %Precedence;    #REQUIRED
+             delay    (normal | low)  #REQUIRED
+             throughput   (normal | high) #REQUIRED
+             relibility   (normal | high) #REQUIRED
+             reserved     CDATA #FIXED "0">
+
+   <!ELEMENT total.length EMPTY>
+   <!--
+    total length of datagram (header and payload) in octets, MUST be
+    less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+    ethernets).
+   -->
+   <!ATTLIST total.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT id EMPTY>
+   <!-- 0 <= id <= 65,535  -->
+   <!ATTLIST id
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT flags EMPTY>
+   <!-- df = don't fragment, mf = more fragments  -->
+   <!ATTLIST flags
+
+
+
+Kennedy                      Informational                      [Page 8]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+          reserved CDATA  #FIXED "0"
+          df (may|dont)   #REQUIRED
+          mf (last|more)  #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+   <!ATTLIST offset
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT ttl EMPTY>
+   <!-- 0 <= ttl <= 255 -->
+   <!ATTLIST ttl
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT protocol EMPTY>
+   <!-- 0 <= protocol <= 255 (per IANA) -->
+   <!ATTLIST protocol
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT checksum EMPTY>
+   <!-- 0 <= checksum <= 65535 (over header only) -->
+   <!ATTLIST checksum
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT source EMPTY>
+   <!ATTLIST source
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT destination EMPTY>
+   <!ATTLIST destination
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT options ( end | noop | security | loose | strict | record
+                     | stream | timestamp )*>
+
+   <!ELEMENT end EMPTY>
+   <!ATTLIST end
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "0">
+
+   <!ELEMENT noop EMPTY>
+   <!ATTLIST noop
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "1">
+
+   <!ELEMENT security EMPTY>
+
+
+
+Kennedy                      Informational                      [Page 9]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST security
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "2"
+             length CDATA #FIXED "11"
+             security %Sec; #REQUIRED
+             compartments %Compartments; #REQUIRED
+             handling %Handling; #REQUIRED
+             tcc %TCC; #REQUIRED>
+   <!ELEMENT loose (hop)+>
+   <!ATTLIST loose
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "3"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT hop EMPTY>
+   <!ATTLIST hop
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT strict (hop)+>
+   <!ATTLIST strict
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "9"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT record (hop)+>
+   <!ATTLIST record
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "7"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT stream EMPTY>
+   <!-- 0 <= id <= 65,535 -->
+   <!ATTLIST stream
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "8"
+             length CDATA #FIXED "4"
+             id %Digits; #REQUIRED>
+
+   <!ELEMENT timestamp (tstamp)+>
+   <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy                      Informational                     [Page 10]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST timestamp
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "2"
+             number CDATA #FIXED "4"
+             length %Digits;  #REQUIRED
+             pointer %Digits; #REQUIRED
+             oflw %Digits;    #REQUIRED
+             flag (0 | 1 | 3)  #REQUIRED>
+
+   <!ELEMENT tstamp EMPTY>
+   <!ATTLIST tstamp
+             time %Digits;   #REQUIRED
+             address %IP4Addr; #IMPLIED>
+   <!--
+       padding to bring header to 32-bit boundary.
+       pad MUST be "0"*
+    -->
+   <!ELEMENT padding EMPTY>
+   <!ATTLIST padding
+             pad CDATA #REQUIRED>
+
+   <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+        by section 2.1 of this RFC -->
+   <!ELEMENT payload (CDATA)>
+
+7.2.  TCPoXML DTD
+
+   <!--
+      DTD for TCP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   -->
+
+   <!-- the pseudoheader is only included for checksum calculations -->
+   <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+   <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+                         reserved, control, window, checksum, urgent,
+                         tcp.options, padding)>
+
+   <!ELEMENT src EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+   <!ATTLIST src
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT dest EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy                      Informational                     [Page 11]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST dest
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT sequence EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST sequence
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT acknowledgement EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST acknowledgement
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= number <= 255 -->
+   <!ATTLIST offset
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT reserved EMPTY>
+   <!ATTLIST reserved
+             value CDATA #FIXED "0">
+
+   <!ELEMENT control EMPTY>
+   <!ATTLIST control
+             urg (0|1) #IMPLIED
+             ack (0|1) #IMPLIED
+             psh (0|1) #IMPLIED
+             rst (0|1) #IMPLIED
+             syn (0|1) #IMPLIED
+             fin (0|1) #IMPLIED>
+
+   <!ELEMENT window EMPTY>
+   <!-- 0 <= size <= 65,535 -->
+   <!ATTLIST window
+             size %Digits; #REQUIRED>
+
+   <!--
+      checksum as in ip, but with
+      the following pseudo-header added into the tcp element:
+     -->
+   <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+                               tcp.length)>
+
+   <!--
+      tcp header + data length in octets. does not include the size of
+
+      the pseudoheader.
+    -->
+
+
+
+Kennedy                      Informational                     [Page 12]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ELEMENT tcp.length EMPTY>
+   <!ATTLIST tcp.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT urgent EMPTY>
+   <!-- 0 <= pointer <= 65,535 -->
+   <!ATTLIST urgent
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+   <!ELEMENT tcp.end EMPTY>
+   <!ATTLIST tcp.end
+             kind CDATA #FIXED "0">
+
+   <!ELEMENT tcp.noop EMPTY>
+   <!ATTLIST tcp.noop
+             kind CDATA #FIXED "1">
+
+   <!ELEMENT tcp.mss EMPTY>
+   <!ATTLIST tcp.mss
+             kind CDATA #FIXED "2"
+             length CDATA #FIXED "4"
+             size %Digits; #REQUIRED>
+
+7.3.  UDPoXML DTD
+
+   <!--
+      DTD for UDP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   -->
+
+   <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+   <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+   <!ELEMENT udp.pseudoheader (source, destination, protocol,
+                               udp.length)>
+
+   <!--
+      udp header + data length in octets. does not include the size of
+      the pseudoheader.
+    -->
+   <!ELEMENT udp.length EMPTY>
+   <!ATTLIST udp.length
+             value %Digits; #REQUIRED>
+
+
+
+Kennedy                      Informational                     [Page 13]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+8. Security Considerations
+
+   XML, as a subset of SGML, has the same security considerations as
+   specified in SGML Media Types [RFC1874].  Security considerations
+   that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+   not attempt to correct for issues not related to message format.
+
+9.   References
+
+   [JABBER]    Miller, J., "Jabber", draft-miller-jabber-00.txt,
+               February 2002. (Work in Progress)
+
+   [RFC768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+               August 1980.
+
+   [RFC791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
+               September 1981.
+
+   [RFC793]    Postel, J., "Transmission Control Protocol", STD 7, RFC
+               793, September 1981.
+
+   [RFC894]    Hornig, C., "Standard for the Transmission of IP
+               Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+   [RFC1042]   Postel, J. and J. Reynolds, "Standard for the
+               Transmission of IP Datagrams Over IEEE 802 Networks", STD
+               43, RFC 1042, February 1988.
+
+   [RFC1123]   Braden, R., "Requirements for Internet Hosts -
+               Application and Support", RFC 1123, October 1989.
+
+   [RFC1874]   Levinson, E., "SGML Media Types", RFC 1874, December
+               1995.
+
+   [RFC2003]   Perkins, C., "IP Encapsulation within IP", RFC 2003,
+               October 1996.
+
+   [RFC2045]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part One: Format of Internet Message
+               Bodies", RFC 2045, November 1996.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2279]   Yergeau, F., "UTF-8, a transformation format of ISO
+               10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy                      Informational                     [Page 14]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   [RFC2460]   Deering, S. and R. Hinden, "Internet Protocol, Version 6
+               (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC3080]   Rose, M., "The Blocks Extensible Exchange Protocol Core",
+               RFC 3080, March 2001.
+
+   [SOAP]      Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+               Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+               "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+               Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+   [XML]       Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+               Markup Language (XML)" World Wide Web Consortium
+               Recommendation REC- xml-19980210.
+               http://www.w3.org/TR/1998/REC-xml-19980210
+
+10.  Author's Address
+
+   Hugh Kennedy
+   Mimezine
+   1060 West Addison
+   Chicago, IL 60613
+   USA
+
+   EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 15]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 16]
+
+
+
+
+
+
+
+Network Working Group                                         H. Kennedy
+Request for Comments: 3252                                      Mimezine
+Category: Informational                                     1 April 2002
+
+
+                 Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document defines a reformulation of IP and two transport layer
+   protocols (TCP and UDP) as XML applications.
+
+1.   Introduction
+
+1.1. Overview
+
+   This document describes the Binary Lexical Octet Ad-hoc Transport
+   (BLOAT): a reformulation of a widely-deployed network-layer protocol
+   (IP [RFC791]), and two associated transport layer protocols (TCP
+   [RFC793] and UDP [RFC768]) as XML [XML] applications.  It also
+   describes methods for transporting BLOAT over Ethernet and IEEE 802
+   networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+   across the public Internet.
+
+1.2. Motivation
+
+   The wild popularity of XML as a basis for application-level protocols
+   such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+   Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+   investigation into the possibility of extending the use of XML in the
+   protocol stack.  Using XML at both the transport and network layer in
+   addition to the application layer would provide for an amazing amount
+   of power and flexibility while removing dependencies on proprietary
+   and hard-to-understand binary protocols.  This protocol unification
+   would also allow applications to use a single XML parser for all
+   aspects of their operation, eliminating developer time spent figuring
+   out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy                      Informational                      [Page 1]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   parsing to the XML toolset.  The use of XML also mitigates concerns
+   over "network vs. host" byte ordering which is at the root of many
+   network application bugs.
+
+1.3. Relation to Existing Protocols
+
+   The reformulations specified in this RFC follow as closely as
+   possible the spirit of the RFCs on which they are based, and so MAY
+   contain elements or attributes that would not be needed in a pure
+   reworking (e.g. length attributes, which are implicit in XML.)
+
+   The layering of network and transport protocols are maintained in
+   this RFC despite the optimizations that could be made if the line
+   were somewhat blurred (i.e. merging TCP and IP into a single, larger
+   element in the DTD) in order to foster future use of this protocol as
+   a basis for reformulating other protocols (such as ICMP.)
+
+   Other than the encoding, the behavioral aspects of each of the
+   existing protocols remain unchanged.  Routing, address spaces, TCP
+   congestion control, etc. behave as specified in the extant standards.
+   Adapting to new standards and experimental algorithm heuristics for
+   improving performance will become much easier once the move to BLOAT
+   has been completed.
+
+1.4. Requirement Levels
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119
+   [RFC2119].
+
+2.   IPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.
+   IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+   (section 3.) and higher-level application protocols.
+
+   The DTD for this document type can be found in section 7.1.
+
+   The routing of IPoXML can be easily implemented on hosts with an XML
+   parser, as the regular structure lends itself handily to parsing and
+   validation of the document/datagram and then processing the
+   destination address, TTL, and checksum before sending it on to its
+   next-hop.
+
+   The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+   wider deployment of IPv4 and the fact that implementing IPv6 as XML
+   would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy                      Informational                      [Page 2]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+   of RFC 2279 [RFC2279].  All BLOAT document/datagrams MUST be well-
+   formed and include the XMLDecl.
+
+2.1. IP Description
+
+   A number of items have changed (for the better) from the original IP
+   specification.  Bit-masks, where present have been converted into
+   human-readable values.  IP addresses are listed in their dotted-
+   decimal notation [RFC1123].  Length and checksum values are present
+   as decimal integers.
+
+   To calculate the length and checksum fields of the IP element, a
+   canonicalized form of the element MUST be used.  The canonical form
+   SHALL have no whitespace (including newline characters) between
+   elements and only one space character between attributes.  There
+   SHALL NOT be a space following the last attribute in an element.
+
+   An iterative method SHOULD be used to calculate checksums, as the
+   length field will vary based on the size of the checksum.
+
+   The payload element bears special attention.  Due to the character
+   set restrictions of XML, the payload of IP datagrams (which MAY
+   contain arbitrary data) MUST be encoded for transport. This RFC
+   REQUIRES the contents of the payload to be encoded in the base-64
+   encoding of RFC 2045 [RFC2045], but removes the requirement that the
+   encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 3]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+2.2. Example Datagram
+
+   The following is an example IPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   <ip>
+   <header length="474">
+   <version value="4"/>
+   <tos precedence="Routine" delay="Normal" throughput="Normal"
+        relibility="Normal" reserved="0"/>
+   <total.length value="461"/>
+   <id value="1"/>
+   <flags reserved="0" df="dont" mf="last"/>
+   <offset value="0"/>
+   <ttl value="255"/>
+   <protocol value="6"/>
+   <checksum value="8707"/>
+   <source address="10.0.0.22"/>
+   <destination address="10.0.0.1"/>
+   <options>
+   <end copied="0" class="0" number="0"/>
+   </options>
+   <padding pad="0"/>
+   </header>
+   <payload>
+   </payload>
+   </ip>
+
+3.   TCPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+   A number of items have changed from the original TCP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+   To calculate the length and checksum fields of the TCP element, a
+   canonicalized form of the element MUST be used as in section 2.1.
+
+   An iterative method SHOULD be used to calculate checksums as in
+   section 2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy                      Informational                      [Page 4]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   The TCP offset element was expanded to a maximum of 255 from 16 to
+   allow for the increased size of the header in XML.
+
+   TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+   The following is an example TCPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   <tcp>
+   <tcp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <sequence number="322622954"/>
+   <acknowledgement number="689715995"/>
+   <offset number=""/>
+   <reserved value="0"/>
+   <control syn="1" ack="1"/>
+   <window size="1"/>
+   <urgent pointer="0"/>
+   <checksum value="2988"/>
+   <tcp.options>
+   <tcp.end kind="0"/>
+   </tcp.options>
+   <padding pad="0"/>
+   </tcp.header>
+   <payload>
+   </payload>
+   </tcp>
+
+4.   UDPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+   A number of items have changed from the original UDP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 5]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   To calculate the length and checksum fields of the UDP element, a
+   canonicalized form of the element MUST be used as in section 2.1.  An
+   iterative method SHOULD be used to calculate checksums as in section
+   2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+   UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+   The following is an example UDPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   <udp>
+   <udp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <udp.length value="143"/>
+   <checksum value="2988"/>
+   </udp.header>
+   <payload>
+   </payload>
+   </udp>
+
+5.   Network Transport
+
+   This document provides for the transmission of BLOAT datagrams over
+   two common families of physical layer transport.  Future RFCs will
+   address additional transports as routing vendors catch up to the
+   specification, and we begin to see BLOAT routed across the Internet
+   backbone.
+
+5.1. Ethernet
+
+   BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+   exception that the type field of the Ethernet frame MUST contain the
+   value 0xBEEF.  The first 5 octets of the Ethernet frame payload will
+   be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+   BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+   that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy                      Informational                      [Page 6]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+6. Gatewaying over IP
+
+   In order to facilitate the gradual introduction of BLOAT into the
+   public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+   gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+   The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+   Network DTD (7.1.)
+
+   The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+   [XML]) although it is understood that most IPoXML implementations
+   will not need to pull down the DTD, as it will normally be embedded
+   in the implementation, and presents something of a catch-22 if you
+   need to load part of your network protocol over the network.
+
+7.1.  IPoXML DTD
+
+   <!--
+    DTD for IP over XML.
+    Refer to this DTD as:
+
+    <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   -->
+   <!--
+    DTD data types:
+
+      Digits      [0..9]+
+
+      Precedence  "NetworkControl | InternetworkControl |
+                   CRITIC | FlashOverride | Flash | Immediate |
+                   Priority | Routine"
+
+      IP4Addr     "dotted-decimal" notation of [RFC1123]
+
+      Class       [0..3]
+
+      Sec          "Unclassified | Confidential | EFTO | MMMM | PROG |
+                    Restricted | Secret | Top Secret | Reserved"
+
+      Compartments [0..65535]
+
+      Handling     [0..65535]
+
+      TCC          [0..16777216]
+
+   -->
+
+
+
+Kennedy                      Informational                      [Page 7]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ENTITY % Digits "CDATA">
+   <!ENTITY % Precedence "CDATA">
+   <!ENTITY % IP4Addr "CDATA">
+   <!ENTITY % Class "CDATA">
+   <!ENTITY % Sec "CDATA">
+   <!ENTITY % Compartments "CDATA">
+   <!ENTITY % Handling "CDATA">
+   <!ENTITY % TCC "CDATA">
+
+   <!ELEMENT ip (header, payload)>
+
+   <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+                    protocol, checksum, source, destination, options,
+                    padding)>
+   <!-- length of header in 32-bit words -->
+   <!ATTLIST header
+             length %Digits; #REQUIRED>
+
+   <!ELEMENT version EMPTY>
+   <!-- ip version. SHOULD be "4" -->
+   <!ATTLIST version
+             value   %Digits;  #REQUIRED>
+
+   <!ELEMENT tos EMPTY>
+   <!ATTLIST tos
+             precedence   %Precedence;    #REQUIRED
+             delay    (normal | low)  #REQUIRED
+             throughput   (normal | high) #REQUIRED
+             relibility   (normal | high) #REQUIRED
+             reserved     CDATA #FIXED "0">
+
+   <!ELEMENT total.length EMPTY>
+   <!--
+    total length of datagram (header and payload) in octets, MUST be
+    less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+    ethernets).
+   -->
+   <!ATTLIST total.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT id EMPTY>
+   <!-- 0 <= id <= 65,535  -->
+   <!ATTLIST id
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT flags EMPTY>
+   <!-- df = don't fragment, mf = more fragments  -->
+   <!ATTLIST flags
+
+
+
+Kennedy                      Informational                      [Page 8]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+          reserved CDATA  #FIXED "0"
+          df (may|dont)   #REQUIRED
+          mf (last|more)  #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+   <!ATTLIST offset
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT ttl EMPTY>
+   <!-- 0 <= ttl <= 255 -->
+   <!ATTLIST ttl
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT protocol EMPTY>
+   <!-- 0 <= protocol <= 255 (per IANA) -->
+   <!ATTLIST protocol
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT checksum EMPTY>
+   <!-- 0 <= checksum <= 65535 (over header only) -->
+   <!ATTLIST checksum
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT source EMPTY>
+   <!ATTLIST source
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT destination EMPTY>
+   <!ATTLIST destination
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT options ( end | noop | security | loose | strict | record
+                     | stream | timestamp )*>
+
+   <!ELEMENT end EMPTY>
+   <!ATTLIST end
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "0">
+
+   <!ELEMENT noop EMPTY>
+   <!ATTLIST noop
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "1">
+
+   <!ELEMENT security EMPTY>
+
+
+
+Kennedy                      Informational                      [Page 9]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST security
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "2"
+             length CDATA #FIXED "11"
+             security %Sec; #REQUIRED
+             compartments %Compartments; #REQUIRED
+             handling %Handling; #REQUIRED
+             tcc %TCC; #REQUIRED>
+   <!ELEMENT loose (hop)+>
+   <!ATTLIST loose
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "3"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT hop EMPTY>
+   <!ATTLIST hop
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT strict (hop)+>
+   <!ATTLIST strict
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "9"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT record (hop)+>
+   <!ATTLIST record
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "7"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT stream EMPTY>
+   <!-- 0 <= id <= 65,535 -->
+   <!ATTLIST stream
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "8"
+             length CDATA #FIXED "4"
+             id %Digits; #REQUIRED>
+
+   <!ELEMENT timestamp (tstamp)+>
+   <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy                      Informational                     [Page 10]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST timestamp
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "2"
+             number CDATA #FIXED "4"
+             length %Digits;  #REQUIRED
+             pointer %Digits; #REQUIRED
+             oflw %Digits;    #REQUIRED
+             flag (0 | 1 | 3)  #REQUIRED>
+
+   <!ELEMENT tstamp EMPTY>
+   <!ATTLIST tstamp
+             time %Digits;   #REQUIRED
+             address %IP4Addr; #IMPLIED>
+   <!--
+       padding to bring header to 32-bit boundary.
+       pad MUST be "0"*
+    -->
+   <!ELEMENT padding EMPTY>
+   <!ATTLIST padding
+             pad CDATA #REQUIRED>
+
+   <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+        by section 2.1 of this RFC -->
+   <!ELEMENT payload (CDATA)>
+
+7.2.  TCPoXML DTD
+
+   <!--
+      DTD for TCP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   -->
+
+   <!-- the pseudoheader is only included for checksum calculations -->
+   <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+   <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+                         reserved, control, window, checksum, urgent,
+                         tcp.options, padding)>
+
+   <!ELEMENT src EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+   <!ATTLIST src
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT dest EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy                      Informational                     [Page 11]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST dest
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT sequence EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST sequence
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT acknowledgement EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST acknowledgement
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= number <= 255 -->
+   <!ATTLIST offset
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT reserved EMPTY>
+   <!ATTLIST reserved
+             value CDATA #FIXED "0">
+
+   <!ELEMENT control EMPTY>
+   <!ATTLIST control
+             urg (0|1) #IMPLIED
+             ack (0|1) #IMPLIED
+             psh (0|1) #IMPLIED
+             rst (0|1) #IMPLIED
+             syn (0|1) #IMPLIED
+             fin (0|1) #IMPLIED>
+
+   <!ELEMENT window EMPTY>
+   <!-- 0 <= size <= 65,535 -->
+   <!ATTLIST window
+             size %Digits; #REQUIRED>
+
+   <!--
+      checksum as in ip, but with
+      the following pseudo-header added into the tcp element:
+     -->
+   <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+                               tcp.length)>
+
+   <!--
+      tcp header + data length in octets. does not include the size of
+
+      the pseudoheader.
+    -->
+
+
+
+Kennedy                      Informational                     [Page 12]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ELEMENT tcp.length EMPTY>
+   <!ATTLIST tcp.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT urgent EMPTY>
+   <!-- 0 <= pointer <= 65,535 -->
+   <!ATTLIST urgent
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+   <!ELEMENT tcp.end EMPTY>
+   <!ATTLIST tcp.end
+             kind CDATA #FIXED "0">
+
+   <!ELEMENT tcp.noop EMPTY>
+   <!ATTLIST tcp.noop
+             kind CDATA #FIXED "1">
+
+   <!ELEMENT tcp.mss EMPTY>
+   <!ATTLIST tcp.mss
+             kind CDATA #FIXED "2"
+             length CDATA #FIXED "4"
+             size %Digits; #REQUIRED>
+
+7.3.  UDPoXML DTD
+
+   <!--
+      DTD for UDP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   -->
+
+   <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+   <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+   <!ELEMENT udp.pseudoheader (source, destination, protocol,
+                               udp.length)>
+
+   <!--
+      udp header + data length in octets. does not include the size of
+      the pseudoheader.
+    -->
+   <!ELEMENT udp.length EMPTY>
+   <!ATTLIST udp.length
+             value %Digits; #REQUIRED>
+
+
+
+Kennedy                      Informational                     [Page 13]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+8. Security Considerations
+
+   XML, as a subset of SGML, has the same security considerations as
+   specified in SGML Media Types [RFC1874].  Security considerations
+   that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+   not attempt to correct for issues not related to message format.
+
+9.   References
+
+   [JABBER]    Miller, J., "Jabber", draft-miller-jabber-00.txt,
+               February 2002. (Work in Progress)
+
+   [RFC768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+               August 1980.
+
+   [RFC791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
+               September 1981.
+
+   [RFC793]    Postel, J., "Transmission Control Protocol", STD 7, RFC
+               793, September 1981.
+
+   [RFC894]    Hornig, C., "Standard for the Transmission of IP
+               Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+   [RFC1042]   Postel, J. and J. Reynolds, "Standard for the
+               Transmission of IP Datagrams Over IEEE 802 Networks", STD
+               43, RFC 1042, February 1988.
+
+   [RFC1123]   Braden, R., "Requirements for Internet Hosts -
+               Application and Support", RFC 1123, October 1989.
+
+   [RFC1874]   Levinson, E., "SGML Media Types", RFC 1874, December
+               1995.
+
+   [RFC2003]   Perkins, C., "IP Encapsulation within IP", RFC 2003,
+               October 1996.
+
+   [RFC2045]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part One: Format of Internet Message
+               Bodies", RFC 2045, November 1996.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2279]   Yergeau, F., "UTF-8, a transformation format of ISO
+               10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy                      Informational                     [Page 14]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   [RFC2460]   Deering, S. and R. Hinden, "Internet Protocol, Version 6
+               (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC3080]   Rose, M., "The Blocks Extensible Exchange Protocol Core",
+               RFC 3080, March 2001.
+
+   [SOAP]      Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+               Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+               "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+               Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+   [XML]       Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+               Markup Language (XML)" World Wide Web Consortium
+               Recommendation REC- xml-19980210.
+               http://www.w3.org/TR/1998/REC-xml-19980210
+
+10.  Author's Address
+
+   Hugh Kennedy
+   Mimezine
+   1060 West Addison
+   Chicago, IL 60613
+   USA
+
+   EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 15]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 16]
+
+
+
+
+
+
+
+Network Working Group                                         H. Kennedy
+Request for Comments: 3252                                      Mimezine
+Category: Informational                                     1 April 2002
+
+
+                 Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document defines a reformulation of IP and two transport layer
+   protocols (TCP and UDP) as XML applications.
+
+1.   Introduction
+
+1.1. Overview
+
+   This document describes the Binary Lexical Octet Ad-hoc Transport
+   (BLOAT): a reformulation of a widely-deployed network-layer protocol
+   (IP [RFC791]), and two associated transport layer protocols (TCP
+   [RFC793] and UDP [RFC768]) as XML [XML] applications.  It also
+   describes methods for transporting BLOAT over Ethernet and IEEE 802
+   networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+   across the public Internet.
+
+1.2. Motivation
+
+   The wild popularity of XML as a basis for application-level protocols
+   such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+   Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+   investigation into the possibility of extending the use of XML in the
+   protocol stack.  Using XML at both the transport and network layer in
+   addition to the application layer would provide for an amazing amount
+   of power and flexibility while removing dependencies on proprietary
+   and hard-to-understand binary protocols.  This protocol unification
+   would also allow applications to use a single XML parser for all
+   aspects of their operation, eliminating developer time spent figuring
+   out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy                      Informational                      [Page 1]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   parsing to the XML toolset.  The use of XML also mitigates concerns
+   over "network vs. host" byte ordering which is at the root of many
+   network application bugs.
+
+1.3. Relation to Existing Protocols
+
+   The reformulations specified in this RFC follow as closely as
+   possible the spirit of the RFCs on which they are based, and so MAY
+   contain elements or attributes that would not be needed in a pure
+   reworking (e.g. length attributes, which are implicit in XML.)
+
+   The layering of network and transport protocols are maintained in
+   this RFC despite the optimizations that could be made if the line
+   were somewhat blurred (i.e. merging TCP and IP into a single, larger
+   element in the DTD) in order to foster future use of this protocol as
+   a basis for reformulating other protocols (such as ICMP.)
+
+   Other than the encoding, the behavioral aspects of each of the
+   existing protocols remain unchanged.  Routing, address spaces, TCP
+   congestion control, etc. behave as specified in the extant standards.
+   Adapting to new standards and experimental algorithm heuristics for
+   improving performance will become much easier once the move to BLOAT
+   has been completed.
+
+1.4. Requirement Levels
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119
+   [RFC2119].
+
+2.   IPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.
+   IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+   (section 3.) and higher-level application protocols.
+
+   The DTD for this document type can be found in section 7.1.
+
+   The routing of IPoXML can be easily implemented on hosts with an XML
+   parser, as the regular structure lends itself handily to parsing and
+   validation of the document/datagram and then processing the
+   destination address, TTL, and checksum before sending it on to its
+   next-hop.
+
+   The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+   wider deployment of IPv4 and the fact that implementing IPv6 as XML
+   would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy                      Informational                      [Page 2]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+   of RFC 2279 [RFC2279].  All BLOAT document/datagrams MUST be well-
+   formed and include the XMLDecl.
+
+2.1. IP Description
+
+   A number of items have changed (for the better) from the original IP
+   specification.  Bit-masks, where present have been converted into
+   human-readable values.  IP addresses are listed in their dotted-
+   decimal notation [RFC1123].  Length and checksum values are present
+   as decimal integers.
+
+   To calculate the length and checksum fields of the IP element, a
+   canonicalized form of the element MUST be used.  The canonical form
+   SHALL have no whitespace (including newline characters) between
+   elements and only one space character between attributes.  There
+   SHALL NOT be a space following the last attribute in an element.
+
+   An iterative method SHOULD be used to calculate checksums, as the
+   length field will vary based on the size of the checksum.
+
+   The payload element bears special attention.  Due to the character
+   set restrictions of XML, the payload of IP datagrams (which MAY
+   contain arbitrary data) MUST be encoded for transport. This RFC
+   REQUIRES the contents of the payload to be encoded in the base-64
+   encoding of RFC 2045 [RFC2045], but removes the requirement that the
+   encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 3]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+2.2. Example Datagram
+
+   The following is an example IPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   <ip>
+   <header length="474">
+   <version value="4"/>
+   <tos precedence="Routine" delay="Normal" throughput="Normal"
+        relibility="Normal" reserved="0"/>
+   <total.length value="461"/>
+   <id value="1"/>
+   <flags reserved="0" df="dont" mf="last"/>
+   <offset value="0"/>
+   <ttl value="255"/>
+   <protocol value="6"/>
+   <checksum value="8707"/>
+   <source address="10.0.0.22"/>
+   <destination address="10.0.0.1"/>
+   <options>
+   <end copied="0" class="0" number="0"/>
+   </options>
+   <padding pad="0"/>
+   </header>
+   <payload>
+   </payload>
+   </ip>
+
+3.   TCPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+   A number of items have changed from the original TCP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+   To calculate the length and checksum fields of the TCP element, a
+   canonicalized form of the element MUST be used as in section 2.1.
+
+   An iterative method SHOULD be used to calculate checksums as in
+   section 2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy                      Informational                      [Page 4]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   The TCP offset element was expanded to a maximum of 255 from 16 to
+   allow for the increased size of the header in XML.
+
+   TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+   The following is an example TCPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   <tcp>
+   <tcp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <sequence number="322622954"/>
+   <acknowledgement number="689715995"/>
+   <offset number=""/>
+   <reserved value="0"/>
+   <control syn="1" ack="1"/>
+   <window size="1"/>
+   <urgent pointer="0"/>
+   <checksum value="2988"/>
+   <tcp.options>
+   <tcp.end kind="0"/>
+   </tcp.options>
+   <padding pad="0"/>
+   </tcp.header>
+   <payload>
+   </payload>
+   </tcp>
+
+4.   UDPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+   A number of items have changed from the original UDP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 5]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   To calculate the length and checksum fields of the UDP element, a
+   canonicalized form of the element MUST be used as in section 2.1.  An
+   iterative method SHOULD be used to calculate checksums as in section
+   2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+   UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+   The following is an example UDPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   <udp>
+   <udp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <udp.length value="143"/>
+   <checksum value="2988"/>
+   </udp.header>
+   <payload>
+   </payload>
+   </udp>
+
+5.   Network Transport
+
+   This document provides for the transmission of BLOAT datagrams over
+   two common families of physical layer transport.  Future RFCs will
+   address additional transports as routing vendors catch up to the
+   specification, and we begin to see BLOAT routed across the Internet
+   backbone.
+
+5.1. Ethernet
+
+   BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+   exception that the type field of the Ethernet frame MUST contain the
+   value 0xBEEF.  The first 5 octets of the Ethernet frame payload will
+   be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+   BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+   that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy                      Informational                      [Page 6]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+6. Gatewaying over IP
+
+   In order to facilitate the gradual introduction of BLOAT into the
+   public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+   gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+   The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+   Network DTD (7.1.)
+
+   The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+   [XML]) although it is understood that most IPoXML implementations
+   will not need to pull down the DTD, as it will normally be embedded
+   in the implementation, and presents something of a catch-22 if you
+   need to load part of your network protocol over the network.
+
+7.1.  IPoXML DTD
+
+   <!--
+    DTD for IP over XML.
+    Refer to this DTD as:
+
+    <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   -->
+   <!--
+    DTD data types:
+
+      Digits      [0..9]+
+
+      Precedence  "NetworkControl | InternetworkControl |
+                   CRITIC | FlashOverride | Flash | Immediate |
+                   Priority | Routine"
+
+      IP4Addr     "dotted-decimal" notation of [RFC1123]
+
+      Class       [0..3]
+
+      Sec          "Unclassified | Confidential | EFTO | MMMM | PROG |
+                    Restricted | Secret | Top Secret | Reserved"
+
+      Compartments [0..65535]
+
+      Handling     [0..65535]
+
+      TCC          [0..16777216]
+
+   -->
+
+
+
+Kennedy                      Informational                      [Page 7]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ENTITY % Digits "CDATA">
+   <!ENTITY % Precedence "CDATA">
+   <!ENTITY % IP4Addr "CDATA">
+   <!ENTITY % Class "CDATA">
+   <!ENTITY % Sec "CDATA">
+   <!ENTITY % Compartments "CDATA">
+   <!ENTITY % Handling "CDATA">
+   <!ENTITY % TCC "CDATA">
+
+   <!ELEMENT ip (header, payload)>
+
+   <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+                    protocol, checksum, source, destination, options,
+                    padding)>
+   <!-- length of header in 32-bit words -->
+   <!ATTLIST header
+             length %Digits; #REQUIRED>
+
+   <!ELEMENT version EMPTY>
+   <!-- ip version. SHOULD be "4" -->
+   <!ATTLIST version
+             value   %Digits;  #REQUIRED>
+
+   <!ELEMENT tos EMPTY>
+   <!ATTLIST tos
+             precedence   %Precedence;    #REQUIRED
+             delay    (normal | low)  #REQUIRED
+             throughput   (normal | high) #REQUIRED
+             relibility   (normal | high) #REQUIRED
+             reserved     CDATA #FIXED "0">
+
+   <!ELEMENT total.length EMPTY>
+   <!--
+    total length of datagram (header and payload) in octets, MUST be
+    less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+    ethernets).
+   -->
+   <!ATTLIST total.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT id EMPTY>
+   <!-- 0 <= id <= 65,535  -->
+   <!ATTLIST id
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT flags EMPTY>
+   <!-- df = don't fragment, mf = more fragments  -->
+   <!ATTLIST flags
+
+
+
+Kennedy                      Informational                      [Page 8]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+          reserved CDATA  #FIXED "0"
+          df (may|dont)   #REQUIRED
+          mf (last|more)  #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+   <!ATTLIST offset
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT ttl EMPTY>
+   <!-- 0 <= ttl <= 255 -->
+   <!ATTLIST ttl
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT protocol EMPTY>
+   <!-- 0 <= protocol <= 255 (per IANA) -->
+   <!ATTLIST protocol
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT checksum EMPTY>
+   <!-- 0 <= checksum <= 65535 (over header only) -->
+   <!ATTLIST checksum
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT source EMPTY>
+   <!ATTLIST source
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT destination EMPTY>
+   <!ATTLIST destination
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT options ( end | noop | security | loose | strict | record
+                     | stream | timestamp )*>
+
+   <!ELEMENT end EMPTY>
+   <!ATTLIST end
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "0">
+
+   <!ELEMENT noop EMPTY>
+   <!ATTLIST noop
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "1">
+
+   <!ELEMENT security EMPTY>
+
+
+
+Kennedy                      Informational                      [Page 9]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST security
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "2"
+             length CDATA #FIXED "11"
+             security %Sec; #REQUIRED
+             compartments %Compartments; #REQUIRED
+             handling %Handling; #REQUIRED
+             tcc %TCC; #REQUIRED>
+   <!ELEMENT loose (hop)+>
+   <!ATTLIST loose
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "3"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT hop EMPTY>
+   <!ATTLIST hop
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT strict (hop)+>
+   <!ATTLIST strict
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "9"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT record (hop)+>
+   <!ATTLIST record
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "7"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT stream EMPTY>
+   <!-- 0 <= id <= 65,535 -->
+   <!ATTLIST stream
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "8"
+             length CDATA #FIXED "4"
+             id %Digits; #REQUIRED>
+
+   <!ELEMENT timestamp (tstamp)+>
+   <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy                      Informational                     [Page 10]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST timestamp
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "2"
+             number CDATA #FIXED "4"
+             length %Digits;  #REQUIRED
+             pointer %Digits; #REQUIRED
+             oflw %Digits;    #REQUIRED
+             flag (0 | 1 | 3)  #REQUIRED>
+
+   <!ELEMENT tstamp EMPTY>
+   <!ATTLIST tstamp
+             time %Digits;   #REQUIRED
+             address %IP4Addr; #IMPLIED>
+   <!--
+       padding to bring header to 32-bit boundary.
+       pad MUST be "0"*
+    -->
+   <!ELEMENT padding EMPTY>
+   <!ATTLIST padding
+             pad CDATA #REQUIRED>
+
+   <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+        by section 2.1 of this RFC -->
+   <!ELEMENT payload (CDATA)>
+
+7.2.  TCPoXML DTD
+
+   <!--
+      DTD for TCP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   -->
+
+   <!-- the pseudoheader is only included for checksum calculations -->
+   <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+   <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+                         reserved, control, window, checksum, urgent,
+                         tcp.options, padding)>
+
+   <!ELEMENT src EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+   <!ATTLIST src
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT dest EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy                      Informational                     [Page 11]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST dest
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT sequence EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST sequence
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT acknowledgement EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST acknowledgement
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= number <= 255 -->
+   <!ATTLIST offset
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT reserved EMPTY>
+   <!ATTLIST reserved
+             value CDATA #FIXED "0">
+
+   <!ELEMENT control EMPTY>
+   <!ATTLIST control
+             urg (0|1) #IMPLIED
+             ack (0|1) #IMPLIED
+             psh (0|1) #IMPLIED
+             rst (0|1) #IMPLIED
+             syn (0|1) #IMPLIED
+             fin (0|1) #IMPLIED>
+
+   <!ELEMENT window EMPTY>
+   <!-- 0 <= size <= 65,535 -->
+   <!ATTLIST window
+             size %Digits; #REQUIRED>
+
+   <!--
+      checksum as in ip, but with
+      the following pseudo-header added into the tcp element:
+     -->
+   <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+                               tcp.length)>
+
+   <!--
+      tcp header + data length in octets. does not include the size of
+
+      the pseudoheader.
+    -->
+
+
+
+Kennedy                      Informational                     [Page 12]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ELEMENT tcp.length EMPTY>
+   <!ATTLIST tcp.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT urgent EMPTY>
+   <!-- 0 <= pointer <= 65,535 -->
+   <!ATTLIST urgent
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+   <!ELEMENT tcp.end EMPTY>
+   <!ATTLIST tcp.end
+             kind CDATA #FIXED "0">
+
+   <!ELEMENT tcp.noop EMPTY>
+   <!ATTLIST tcp.noop
+             kind CDATA #FIXED "1">
+
+   <!ELEMENT tcp.mss EMPTY>
+   <!ATTLIST tcp.mss
+             kind CDATA #FIXED "2"
+             length CDATA #FIXED "4"
+             size %Digits; #REQUIRED>
+
+7.3.  UDPoXML DTD
+
+   <!--
+      DTD for UDP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   -->
+
+   <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+   <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+   <!ELEMENT udp.pseudoheader (source, destination, protocol,
+                               udp.length)>
+
+   <!--
+      udp header + data length in octets. does not include the size of
+      the pseudoheader.
+    -->
+   <!ELEMENT udp.length EMPTY>
+   <!ATTLIST udp.length
+             value %Digits; #REQUIRED>
+
+
+
+Kennedy                      Informational                     [Page 13]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+8. Security Considerations
+
+   XML, as a subset of SGML, has the same security considerations as
+   specified in SGML Media Types [RFC1874].  Security considerations
+   that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+   not attempt to correct for issues not related to message format.
+
+9.   References
+
+   [JABBER]    Miller, J., "Jabber", draft-miller-jabber-00.txt,
+               February 2002. (Work in Progress)
+
+   [RFC768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+               August 1980.
+
+   [RFC791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
+               September 1981.
+
+   [RFC793]    Postel, J., "Transmission Control Protocol", STD 7, RFC
+               793, September 1981.
+
+   [RFC894]    Hornig, C., "Standard for the Transmission of IP
+               Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+   [RFC1042]   Postel, J. and J. Reynolds, "Standard for the
+               Transmission of IP Datagrams Over IEEE 802 Networks", STD
+               43, RFC 1042, February 1988.
+
+   [RFC1123]   Braden, R., "Requirements for Internet Hosts -
+               Application and Support", RFC 1123, October 1989.
+
+   [RFC1874]   Levinson, E., "SGML Media Types", RFC 1874, December
+               1995.
+
+   [RFC2003]   Perkins, C., "IP Encapsulation within IP", RFC 2003,
+               October 1996.
+
+   [RFC2045]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part One: Format of Internet Message
+               Bodies", RFC 2045, November 1996.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2279]   Yergeau, F., "UTF-8, a transformation format of ISO
+               10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy                      Informational                     [Page 14]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   [RFC2460]   Deering, S. and R. Hinden, "Internet Protocol, Version 6
+               (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC3080]   Rose, M., "The Blocks Extensible Exchange Protocol Core",
+               RFC 3080, March 2001.
+
+   [SOAP]      Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+               Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+               "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+               Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+   [XML]       Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+               Markup Language (XML)" World Wide Web Consortium
+               Recommendation REC- xml-19980210.
+               http://www.w3.org/TR/1998/REC-xml-19980210
+
+10.  Author's Address
+
+   Hugh Kennedy
+   Mimezine
+   1060 West Addison
+   Chicago, IL 60613
+   USA
+
+   EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 15]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 16]
+
+
+
+
+
+
+
+Network Working Group                                         H. Kennedy
+Request for Comments: 3252                                      Mimezine
+Category: Informational                                     1 April 2002
+
+
+                 Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document defines a reformulation of IP and two transport layer
+   protocols (TCP and UDP) as XML applications.
+
+1.   Introduction
+
+1.1. Overview
+
+   This document describes the Binary Lexical Octet Ad-hoc Transport
+   (BLOAT): a reformulation of a widely-deployed network-layer protocol
+   (IP [RFC791]), and two associated transport layer protocols (TCP
+   [RFC793] and UDP [RFC768]) as XML [XML] applications.  It also
+   describes methods for transporting BLOAT over Ethernet and IEEE 802
+   networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+   across the public Internet.
+
+1.2. Motivation
+
+   The wild popularity of XML as a basis for application-level protocols
+   such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+   Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+   investigation into the possibility of extending the use of XML in the
+   protocol stack.  Using XML at both the transport and network layer in
+   addition to the application layer would provide for an amazing amount
+   of power and flexibility while removing dependencies on proprietary
+   and hard-to-understand binary protocols.  This protocol unification
+   would also allow applications to use a single XML parser for all
+   aspects of their operation, eliminating developer time spent figuring
+   out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy                      Informational                      [Page 1]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   parsing to the XML toolset.  The use of XML also mitigates concerns
+   over "network vs. host" byte ordering which is at the root of many
+   network application bugs.
+
+1.3. Relation to Existing Protocols
+
+   The reformulations specified in this RFC follow as closely as
+   possible the spirit of the RFCs on which they are based, and so MAY
+   contain elements or attributes that would not be needed in a pure
+   reworking (e.g. length attributes, which are implicit in XML.)
+
+   The layering of network and transport protocols are maintained in
+   this RFC despite the optimizations that could be made if the line
+   were somewhat blurred (i.e. merging TCP and IP into a single, larger
+   element in the DTD) in order to foster future use of this protocol as
+   a basis for reformulating other protocols (such as ICMP.)
+
+   Other than the encoding, the behavioral aspects of each of the
+   existing protocols remain unchanged.  Routing, address spaces, TCP
+   congestion control, etc. behave as specified in the extant standards.
+   Adapting to new standards and experimental algorithm heuristics for
+   improving performance will become much easier once the move to BLOAT
+   has been completed.
+
+1.4. Requirement Levels
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119
+   [RFC2119].
+
+2.   IPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.
+   IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+   (section 3.) and higher-level application protocols.
+
+   The DTD for this document type can be found in section 7.1.
+
+   The routing of IPoXML can be easily implemented on hosts with an XML
+   parser, as the regular structure lends itself handily to parsing and
+   validation of the document/datagram and then processing the
+   destination address, TTL, and checksum before sending it on to its
+   next-hop.
+
+   The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+   wider deployment of IPv4 and the fact that implementing IPv6 as XML
+   would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy                      Informational                      [Page 2]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+   of RFC 2279 [RFC2279].  All BLOAT document/datagrams MUST be well-
+   formed and include the XMLDecl.
+
+2.1. IP Description
+
+   A number of items have changed (for the better) from the original IP
+   specification.  Bit-masks, where present have been converted into
+   human-readable values.  IP addresses are listed in their dotted-
+   decimal notation [RFC1123].  Length and checksum values are present
+   as decimal integers.
+
+   To calculate the length and checksum fields of the IP element, a
+   canonicalized form of the element MUST be used.  The canonical form
+   SHALL have no whitespace (including newline characters) between
+   elements and only one space character between attributes.  There
+   SHALL NOT be a space following the last attribute in an element.
+
+   An iterative method SHOULD be used to calculate checksums, as the
+   length field will vary based on the size of the checksum.
+
+   The payload element bears special attention.  Due to the character
+   set restrictions of XML, the payload of IP datagrams (which MAY
+   contain arbitrary data) MUST be encoded for transport. This RFC
+   REQUIRES the contents of the payload to be encoded in the base-64
+   encoding of RFC 2045 [RFC2045], but removes the requirement that the
+   encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 3]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+2.2. Example Datagram
+
+   The following is an example IPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   <ip>
+   <header length="474">
+   <version value="4"/>
+   <tos precedence="Routine" delay="Normal" throughput="Normal"
+        relibility="Normal" reserved="0"/>
+   <total.length value="461"/>
+   <id value="1"/>
+   <flags reserved="0" df="dont" mf="last"/>
+   <offset value="0"/>
+   <ttl value="255"/>
+   <protocol value="6"/>
+   <checksum value="8707"/>
+   <source address="10.0.0.22"/>
+   <destination address="10.0.0.1"/>
+   <options>
+   <end copied="0" class="0" number="0"/>
+   </options>
+   <padding pad="0"/>
+   </header>
+   <payload>
+   </payload>
+   </ip>
+
+3.   TCPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+   A number of items have changed from the original TCP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+   To calculate the length and checksum fields of the TCP element, a
+   canonicalized form of the element MUST be used as in section 2.1.
+
+   An iterative method SHOULD be used to calculate checksums as in
+   section 2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy                      Informational                      [Page 4]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   The TCP offset element was expanded to a maximum of 255 from 16 to
+   allow for the increased size of the header in XML.
+
+   TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+   The following is an example TCPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   <tcp>
+   <tcp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <sequence number="322622954"/>
+   <acknowledgement number="689715995"/>
+   <offset number=""/>
+   <reserved value="0"/>
+   <control syn="1" ack="1"/>
+   <window size="1"/>
+   <urgent pointer="0"/>
+   <checksum value="2988"/>
+   <tcp.options>
+   <tcp.end kind="0"/>
+   </tcp.options>
+   <padding pad="0"/>
+   </tcp.header>
+   <payload>
+   </payload>
+   </tcp>
+
+4.   UDPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+   A number of items have changed from the original UDP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 5]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   To calculate the length and checksum fields of the UDP element, a
+   canonicalized form of the element MUST be used as in section 2.1.  An
+   iterative method SHOULD be used to calculate checksums as in section
+   2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+   UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+   The following is an example UDPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   <udp>
+   <udp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <udp.length value="143"/>
+   <checksum value="2988"/>
+   </udp.header>
+   <payload>
+   </payload>
+   </udp>
+
+5.   Network Transport
+
+   This document provides for the transmission of BLOAT datagrams over
+   two common families of physical layer transport.  Future RFCs will
+   address additional transports as routing vendors catch up to the
+   specification, and we begin to see BLOAT routed across the Internet
+   backbone.
+
+5.1. Ethernet
+
+   BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+   exception that the type field of the Ethernet frame MUST contain the
+   value 0xBEEF.  The first 5 octets of the Ethernet frame payload will
+   be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+   BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+   that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy                      Informational                      [Page 6]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+6. Gatewaying over IP
+
+   In order to facilitate the gradual introduction of BLOAT into the
+   public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+   gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+   The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+   Network DTD (7.1.)
+
+   The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+   [XML]) although it is understood that most IPoXML implementations
+   will not need to pull down the DTD, as it will normally be embedded
+   in the implementation, and presents something of a catch-22 if you
+   need to load part of your network protocol over the network.
+
+7.1.  IPoXML DTD
+
+   <!--
+    DTD for IP over XML.
+    Refer to this DTD as:
+
+    <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   -->
+   <!--
+    DTD data types:
+
+      Digits      [0..9]+
+
+      Precedence  "NetworkControl | InternetworkControl |
+                   CRITIC | FlashOverride | Flash | Immediate |
+                   Priority | Routine"
+
+      IP4Addr     "dotted-decimal" notation of [RFC1123]
+
+      Class       [0..3]
+
+      Sec          "Unclassified | Confidential | EFTO | MMMM | PROG |
+                    Restricted | Secret | Top Secret | Reserved"
+
+      Compartments [0..65535]
+
+      Handling     [0..65535]
+
+      TCC          [0..16777216]
+
+   -->
+
+
+
+Kennedy                      Informational                      [Page 7]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ENTITY % Digits "CDATA">
+   <!ENTITY % Precedence "CDATA">
+   <!ENTITY % IP4Addr "CDATA">
+   <!ENTITY % Class "CDATA">
+   <!ENTITY % Sec "CDATA">
+   <!ENTITY % Compartments "CDATA">
+   <!ENTITY % Handling "CDATA">
+   <!ENTITY % TCC "CDATA">
+
+   <!ELEMENT ip (header, payload)>
+
+   <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+                    protocol, checksum, source, destination, options,
+                    padding)>
+   <!-- length of header in 32-bit words -->
+   <!ATTLIST header
+             length %Digits; #REQUIRED>
+
+   <!ELEMENT version EMPTY>
+   <!-- ip version. SHOULD be "4" -->
+   <!ATTLIST version
+             value   %Digits;  #REQUIRED>
+
+   <!ELEMENT tos EMPTY>
+   <!ATTLIST tos
+             precedence   %Precedence;    #REQUIRED
+             delay    (normal | low)  #REQUIRED
+             throughput   (normal | high) #REQUIRED
+             relibility   (normal | high) #REQUIRED
+             reserved     CDATA #FIXED "0">
+
+   <!ELEMENT total.length EMPTY>
+   <!--
+    total length of datagram (header and payload) in octets, MUST be
+    less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+    ethernets).
+   -->
+   <!ATTLIST total.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT id EMPTY>
+   <!-- 0 <= id <= 65,535  -->
+   <!ATTLIST id
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT flags EMPTY>
+   <!-- df = don't fragment, mf = more fragments  -->
+   <!ATTLIST flags
+
+
+
+Kennedy                      Informational                      [Page 8]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+          reserved CDATA  #FIXED "0"
+          df (may|dont)   #REQUIRED
+          mf (last|more)  #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+   <!ATTLIST offset
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT ttl EMPTY>
+   <!-- 0 <= ttl <= 255 -->
+   <!ATTLIST ttl
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT protocol EMPTY>
+   <!-- 0 <= protocol <= 255 (per IANA) -->
+   <!ATTLIST protocol
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT checksum EMPTY>
+   <!-- 0 <= checksum <= 65535 (over header only) -->
+   <!ATTLIST checksum
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT source EMPTY>
+   <!ATTLIST source
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT destination EMPTY>
+   <!ATTLIST destination
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT options ( end | noop | security | loose | strict | record
+                     | stream | timestamp )*>
+
+   <!ELEMENT end EMPTY>
+   <!ATTLIST end
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "0">
+
+   <!ELEMENT noop EMPTY>
+   <!ATTLIST noop
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "1">
+
+   <!ELEMENT security EMPTY>
+
+
+
+Kennedy                      Informational                      [Page 9]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST security
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "2"
+             length CDATA #FIXED "11"
+             security %Sec; #REQUIRED
+             compartments %Compartments; #REQUIRED
+             handling %Handling; #REQUIRED
+             tcc %TCC; #REQUIRED>
+   <!ELEMENT loose (hop)+>
+   <!ATTLIST loose
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "3"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT hop EMPTY>
+   <!ATTLIST hop
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT strict (hop)+>
+   <!ATTLIST strict
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "9"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT record (hop)+>
+   <!ATTLIST record
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "7"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT stream EMPTY>
+   <!-- 0 <= id <= 65,535 -->
+   <!ATTLIST stream
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "8"
+             length CDATA #FIXED "4"
+             id %Digits; #REQUIRED>
+
+   <!ELEMENT timestamp (tstamp)+>
+   <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy                      Informational                     [Page 10]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST timestamp
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "2"
+             number CDATA #FIXED "4"
+             length %Digits;  #REQUIRED
+             pointer %Digits; #REQUIRED
+             oflw %Digits;    #REQUIRED
+             flag (0 | 1 | 3)  #REQUIRED>
+
+   <!ELEMENT tstamp EMPTY>
+   <!ATTLIST tstamp
+             time %Digits;   #REQUIRED
+             address %IP4Addr; #IMPLIED>
+   <!--
+       padding to bring header to 32-bit boundary.
+       pad MUST be "0"*
+    -->
+   <!ELEMENT padding EMPTY>
+   <!ATTLIST padding
+             pad CDATA #REQUIRED>
+
+   <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+        by section 2.1 of this RFC -->
+   <!ELEMENT payload (CDATA)>
+
+7.2.  TCPoXML DTD
+
+   <!--
+      DTD for TCP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   -->
+
+   <!-- the pseudoheader is only included for checksum calculations -->
+   <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+   <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+                         reserved, control, window, checksum, urgent,
+                         tcp.options, padding)>
+
+   <!ELEMENT src EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+   <!ATTLIST src
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT dest EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy                      Informational                     [Page 11]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST dest
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT sequence EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST sequence
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT acknowledgement EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST acknowledgement
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= number <= 255 -->
+   <!ATTLIST offset
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT reserved EMPTY>
+   <!ATTLIST reserved
+             value CDATA #FIXED "0">
+
+   <!ELEMENT control EMPTY>
+   <!ATTLIST control
+             urg (0|1) #IMPLIED
+             ack (0|1) #IMPLIED
+             psh (0|1) #IMPLIED
+             rst (0|1) #IMPLIED
+             syn (0|1) #IMPLIED
+             fin (0|1) #IMPLIED>
+
+   <!ELEMENT window EMPTY>
+   <!-- 0 <= size <= 65,535 -->
+   <!ATTLIST window
+             size %Digits; #REQUIRED>
+
+   <!--
+      checksum as in ip, but with
+      the following pseudo-header added into the tcp element:
+     -->
+   <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+                               tcp.length)>
+
+   <!--
+      tcp header + data length in octets. does not include the size of
+
+      the pseudoheader.
+    -->
+
+
+
+Kennedy                      Informational                     [Page 12]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ELEMENT tcp.length EMPTY>
+   <!ATTLIST tcp.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT urgent EMPTY>
+   <!-- 0 <= pointer <= 65,535 -->
+   <!ATTLIST urgent
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+   <!ELEMENT tcp.end EMPTY>
+   <!ATTLIST tcp.end
+             kind CDATA #FIXED "0">
+
+   <!ELEMENT tcp.noop EMPTY>
+   <!ATTLIST tcp.noop
+             kind CDATA #FIXED "1">
+
+   <!ELEMENT tcp.mss EMPTY>
+   <!ATTLIST tcp.mss
+             kind CDATA #FIXED "2"
+             length CDATA #FIXED "4"
+             size %Digits; #REQUIRED>
+
+7.3.  UDPoXML DTD
+
+   <!--
+      DTD for UDP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   -->
+
+   <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+   <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+   <!ELEMENT udp.pseudoheader (source, destination, protocol,
+                               udp.length)>
+
+   <!--
+      udp header + data length in octets. does not include the size of
+      the pseudoheader.
+    -->
+   <!ELEMENT udp.length EMPTY>
+   <!ATTLIST udp.length
+             value %Digits; #REQUIRED>
+
+
+
+Kennedy                      Informational                     [Page 13]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+8. Security Considerations
+
+   XML, as a subset of SGML, has the same security considerations as
+   specified in SGML Media Types [RFC1874].  Security considerations
+   that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+   not attempt to correct for issues not related to message format.
+
+9.   References
+
+   [JABBER]    Miller, J., "Jabber", draft-miller-jabber-00.txt,
+               February 2002. (Work in Progress)
+
+   [RFC768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+               August 1980.
+
+   [RFC791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
+               September 1981.
+
+   [RFC793]    Postel, J., "Transmission Control Protocol", STD 7, RFC
+               793, September 1981.
+
+   [RFC894]    Hornig, C., "Standard for the Transmission of IP
+               Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+   [RFC1042]   Postel, J. and J. Reynolds, "Standard for the
+               Transmission of IP Datagrams Over IEEE 802 Networks", STD
+               43, RFC 1042, February 1988.
+
+   [RFC1123]   Braden, R., "Requirements for Internet Hosts -
+               Application and Support", RFC 1123, October 1989.
+
+   [RFC1874]   Levinson, E., "SGML Media Types", RFC 1874, December
+               1995.
+
+   [RFC2003]   Perkins, C., "IP Encapsulation within IP", RFC 2003,
+               October 1996.
+
+   [RFC2045]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part One: Format of Internet Message
+               Bodies", RFC 2045, November 1996.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2279]   Yergeau, F., "UTF-8, a transformation format of ISO
+               10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy                      Informational                     [Page 14]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   [RFC2460]   Deering, S. and R. Hinden, "Internet Protocol, Version 6
+               (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC3080]   Rose, M., "The Blocks Extensible Exchange Protocol Core",
+               RFC 3080, March 2001.
+
+   [SOAP]      Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+               Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+               "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+               Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+   [XML]       Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+               Markup Language (XML)" World Wide Web Consortium
+               Recommendation REC- xml-19980210.
+               http://www.w3.org/TR/1998/REC-xml-19980210
+
+10.  Author's Address
+
+   Hugh Kennedy
+   Mimezine
+   1060 West Addison
+   Chicago, IL 60613
+   USA
+
+   EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 15]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 16]
+
+
+
+
+
+
+
+Network Working Group                                         H. Kennedy
+Request for Comments: 3252                                      Mimezine
+Category: Informational                                     1 April 2002
+
+
+                 Binary Lexical Octet Ad-hoc Transport
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document defines a reformulation of IP and two transport layer
+   protocols (TCP and UDP) as XML applications.
+
+1.   Introduction
+
+1.1. Overview
+
+   This document describes the Binary Lexical Octet Ad-hoc Transport
+   (BLOAT): a reformulation of a widely-deployed network-layer protocol
+   (IP [RFC791]), and two associated transport layer protocols (TCP
+   [RFC793] and UDP [RFC768]) as XML [XML] applications.  It also
+   describes methods for transporting BLOAT over Ethernet and IEEE 802
+   networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
+   across the public Internet.
+
+1.2. Motivation
+
+   The wild popularity of XML as a basis for application-level protocols
+   such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
+   Object Access Protocol [SOAP], and Jabber [JABBER] prompted
+   investigation into the possibility of extending the use of XML in the
+   protocol stack.  Using XML at both the transport and network layer in
+   addition to the application layer would provide for an amazing amount
+   of power and flexibility while removing dependencies on proprietary
+   and hard-to-understand binary protocols.  This protocol unification
+   would also allow applications to use a single XML parser for all
+   aspects of their operation, eliminating developer time spent figuring
+   out the intricacies of each new protocol, and moving the hard work of
+
+
+
+
+Kennedy                      Informational                      [Page 1]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   parsing to the XML toolset.  The use of XML also mitigates concerns
+   over "network vs. host" byte ordering which is at the root of many
+   network application bugs.
+
+1.3. Relation to Existing Protocols
+
+   The reformulations specified in this RFC follow as closely as
+   possible the spirit of the RFCs on which they are based, and so MAY
+   contain elements or attributes that would not be needed in a pure
+   reworking (e.g. length attributes, which are implicit in XML.)
+
+   The layering of network and transport protocols are maintained in
+   this RFC despite the optimizations that could be made if the line
+   were somewhat blurred (i.e. merging TCP and IP into a single, larger
+   element in the DTD) in order to foster future use of this protocol as
+   a basis for reformulating other protocols (such as ICMP.)
+
+   Other than the encoding, the behavioral aspects of each of the
+   existing protocols remain unchanged.  Routing, address spaces, TCP
+   congestion control, etc. behave as specified in the extant standards.
+   Adapting to new standards and experimental algorithm heuristics for
+   improving performance will become much easier once the move to BLOAT
+   has been completed.
+
+1.4. Requirement Levels
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119
+   [RFC2119].
+
+2.   IPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.
+   IPoXML is the root protocol REQUIRED for effective use of TCPoXML
+   (section 3.) and higher-level application protocols.
+
+   The DTD for this document type can be found in section 7.1.
+
+   The routing of IPoXML can be easily implemented on hosts with an XML
+   parser, as the regular structure lends itself handily to parsing and
+   validation of the document/datagram and then processing the
+   destination address, TTL, and checksum before sending it on to its
+   next-hop.
+
+   The reformulation of IPv4 was chosen over IPv6 [RFC2460] due to the
+   wider deployment of IPv4 and the fact that implementing IPv6 as XML
+   would have exceeded the 1500 byte Ethernet MTU.
+
+
+
+Kennedy                      Informational                      [Page 2]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   All BLOAT implementations MUST use - and specify - the UTF-8 encoding
+   of RFC 2279 [RFC2279].  All BLOAT document/datagrams MUST be well-
+   formed and include the XMLDecl.
+
+2.1. IP Description
+
+   A number of items have changed (for the better) from the original IP
+   specification.  Bit-masks, where present have been converted into
+   human-readable values.  IP addresses are listed in their dotted-
+   decimal notation [RFC1123].  Length and checksum values are present
+   as decimal integers.
+
+   To calculate the length and checksum fields of the IP element, a
+   canonicalized form of the element MUST be used.  The canonical form
+   SHALL have no whitespace (including newline characters) between
+   elements and only one space character between attributes.  There
+   SHALL NOT be a space following the last attribute in an element.
+
+   An iterative method SHOULD be used to calculate checksums, as the
+   length field will vary based on the size of the checksum.
+
+   The payload element bears special attention.  Due to the character
+   set restrictions of XML, the payload of IP datagrams (which MAY
+   contain arbitrary data) MUST be encoded for transport. This RFC
+   REQUIRES the contents of the payload to be encoded in the base-64
+   encoding of RFC 2045 [RFC2045], but removes the requirement that the
+   encoded output MUST be wrapped on 76-character lines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 3]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+2.2. Example Datagram
+
+   The following is an example IPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   <ip>
+   <header length="474">
+   <version value="4"/>
+   <tos precedence="Routine" delay="Normal" throughput="Normal"
+        relibility="Normal" reserved="0"/>
+   <total.length value="461"/>
+   <id value="1"/>
+   <flags reserved="0" df="dont" mf="last"/>
+   <offset value="0"/>
+   <ttl value="255"/>
+   <protocol value="6"/>
+   <checksum value="8707"/>
+   <source address="10.0.0.22"/>
+   <destination address="10.0.0.1"/>
+   <options>
+   <end copied="0" class="0" number="0"/>
+   </options>
+   <padding pad="0"/>
+   </header>
+   <payload>
+   </payload>
+   </ip>
+
+3.   TCPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.2.
+
+3.1. TCP Description
+
+   A number of items have changed from the original TCP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+   To calculate the length and checksum fields of the TCP element, a
+   canonicalized form of the element MUST be used as in section 2.1.
+
+   An iterative method SHOULD be used to calculate checksums as in
+   section 2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+
+
+Kennedy                      Informational                      [Page 4]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   The TCP offset element was expanded to a maximum of 255 from 16 to
+   allow for the increased size of the header in XML.
+
+   TCPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+3.2. Example Datagram
+
+   The following is an example TCPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   <tcp>
+   <tcp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <sequence number="322622954"/>
+   <acknowledgement number="689715995"/>
+   <offset number=""/>
+   <reserved value="0"/>
+   <control syn="1" ack="1"/>
+   <window size="1"/>
+   <urgent pointer="0"/>
+   <checksum value="2988"/>
+   <tcp.options>
+   <tcp.end kind="0"/>
+   </tcp.options>
+   <padding pad="0"/>
+   </tcp.header>
+   <payload>
+   </payload>
+   </tcp>
+
+4.   UDPoXML
+
+   This protocol MUST be implemented to be compliant with this RFC.  The
+   DTD for this document type can be found in section 7.3.
+
+4.1. UDP Description
+
+   A number of items have changed from the original UDP specification.
+   Bit-masks, where present have been converted into human-readable
+   values.  Length and checksum and port values are present as decimal
+   integers.
+
+
+
+
+
+
+
+Kennedy                      Informational                      [Page 5]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   To calculate the length and checksum fields of the UDP element, a
+   canonicalized form of the element MUST be used as in section 2.1.  An
+   iterative method SHOULD be used to calculate checksums as in section
+   2.1.
+
+   The payload element MUST be encoded as in section 2.1.
+
+   UDPoXML datagrams encapsulated by IPoXML MAY omit the <?xml?> header
+   as well as the <!DOCTYPE> declaration.
+
+4.2. Example Datagram
+
+   The following is an example UDPoXML datagram with an empty payload:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   <udp>
+   <udp.header>
+   <src port="31415"/>
+   <dest port="42424"/>
+   <udp.length value="143"/>
+   <checksum value="2988"/>
+   </udp.header>
+   <payload>
+   </payload>
+   </udp>
+
+5.   Network Transport
+
+   This document provides for the transmission of BLOAT datagrams over
+   two common families of physical layer transport.  Future RFCs will
+   address additional transports as routing vendors catch up to the
+   specification, and we begin to see BLOAT routed across the Internet
+   backbone.
+
+5.1. Ethernet
+
+   BLOAT is encapsulated in Ethernet datagrams as in [RFC894] with the
+   exception that the type field of the Ethernet frame MUST contain the
+   value 0xBEEF.  The first 5 octets of the Ethernet frame payload will
+   be 0x3c 3f 78 6d 6c ("<?xml".)
+
+5.2. IEEE 802
+
+   BLOAT is encapsulated in IEEE 802 Networks as in [RFC1042] except
+   that the protocol type code for IPoXML is 0xBEEF.
+
+
+
+
+
+Kennedy                      Informational                      [Page 6]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+6. Gatewaying over IP
+
+   In order to facilitate the gradual introduction of BLOAT into the
+   public Internet, BLOAT MAY be encapsulated in IP as in [RFC2003] to
+   gateway between networks that run BLOAT natively on their LANs.
+
+7. DTDs
+
+   The Transport DTDs (7.2. and 7.3.) build on the definitions in the
+   Network DTD (7.1.)
+
+   The DTDs are referenced by their PubidLiteral and SystemLiteral (from
+   [XML]) although it is understood that most IPoXML implementations
+   will not need to pull down the DTD, as it will normally be embedded
+   in the implementation, and presents something of a catch-22 if you
+   need to load part of your network protocol over the network.
+
+7.1.  IPoXML DTD
+
+   <!--
+    DTD for IP over XML.
+    Refer to this DTD as:
+
+    <!DOCTYPE ip PUBLIC "-//IETF//DTD BLOAT 1.0 IP//EN" "bloat.dtd">
+   -->
+   <!--
+    DTD data types:
+
+      Digits      [0..9]+
+
+      Precedence  "NetworkControl | InternetworkControl |
+                   CRITIC | FlashOverride | Flash | Immediate |
+                   Priority | Routine"
+
+      IP4Addr     "dotted-decimal" notation of [RFC1123]
+
+      Class       [0..3]
+
+      Sec          "Unclassified | Confidential | EFTO | MMMM | PROG |
+                    Restricted | Secret | Top Secret | Reserved"
+
+      Compartments [0..65535]
+
+      Handling     [0..65535]
+
+      TCC          [0..16777216]
+
+   -->
+
+
+
+Kennedy                      Informational                      [Page 7]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ENTITY % Digits "CDATA">
+   <!ENTITY % Precedence "CDATA">
+   <!ENTITY % IP4Addr "CDATA">
+   <!ENTITY % Class "CDATA">
+   <!ENTITY % Sec "CDATA">
+   <!ENTITY % Compartments "CDATA">
+   <!ENTITY % Handling "CDATA">
+   <!ENTITY % TCC "CDATA">
+
+   <!ELEMENT ip (header, payload)>
+
+   <!ELEMENT header (version, tos, total.length, id, flags, offset, ttl,
+                    protocol, checksum, source, destination, options,
+                    padding)>
+   <!-- length of header in 32-bit words -->
+   <!ATTLIST header
+             length %Digits; #REQUIRED>
+
+   <!ELEMENT version EMPTY>
+   <!-- ip version. SHOULD be "4" -->
+   <!ATTLIST version
+             value   %Digits;  #REQUIRED>
+
+   <!ELEMENT tos EMPTY>
+   <!ATTLIST tos
+             precedence   %Precedence;    #REQUIRED
+             delay    (normal | low)  #REQUIRED
+             throughput   (normal | high) #REQUIRED
+             relibility   (normal | high) #REQUIRED
+             reserved     CDATA #FIXED "0">
+
+   <!ELEMENT total.length EMPTY>
+   <!--
+    total length of datagram (header and payload) in octets, MUST be
+    less than 65,535 (and SHOULD be less than 1024 for IPoXML on local
+    ethernets).
+   -->
+   <!ATTLIST total.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT id EMPTY>
+   <!-- 0 <= id <= 65,535  -->
+   <!ATTLIST id
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT flags EMPTY>
+   <!-- df = don't fragment, mf = more fragments  -->
+   <!ATTLIST flags
+
+
+
+Kennedy                      Informational                      [Page 8]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+          reserved CDATA  #FIXED "0"
+          df (may|dont)   #REQUIRED
+          mf (last|more)  #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= offset <= 8192 measured in 8 octet (64-bit) chunks -->
+   <!ATTLIST offset
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT ttl EMPTY>
+   <!-- 0 <= ttl <= 255 -->
+   <!ATTLIST ttl
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT protocol EMPTY>
+   <!-- 0 <= protocol <= 255 (per IANA) -->
+   <!ATTLIST protocol
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT checksum EMPTY>
+   <!-- 0 <= checksum <= 65535 (over header only) -->
+   <!ATTLIST checksum
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT source EMPTY>
+   <!ATTLIST source
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT destination EMPTY>
+   <!ATTLIST destination
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT options ( end | noop | security | loose | strict | record
+                     | stream | timestamp )*>
+
+   <!ELEMENT end EMPTY>
+   <!ATTLIST end
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "0">
+
+   <!ELEMENT noop EMPTY>
+   <!ATTLIST noop
+             copied (0|1) #REQUIRED
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "1">
+
+   <!ELEMENT security EMPTY>
+
+
+
+Kennedy                      Informational                      [Page 9]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST security
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "2"
+             length CDATA #FIXED "11"
+             security %Sec; #REQUIRED
+             compartments %Compartments; #REQUIRED
+             handling %Handling; #REQUIRED
+             tcc %TCC; #REQUIRED>
+   <!ELEMENT loose (hop)+>
+   <!ATTLIST loose
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "3"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT hop EMPTY>
+   <!ATTLIST hop
+             address %IP4Addr; #REQUIRED>
+
+   <!ELEMENT strict (hop)+>
+   <!ATTLIST strict
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "9"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT record (hop)+>
+   <!ATTLIST record
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "7"
+             length %Digits; #REQUIRED
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT stream EMPTY>
+   <!-- 0 <= id <= 65,535 -->
+   <!ATTLIST stream
+             copied CDATA #FIXED "1"
+             class  CDATA #FIXED "0"
+             number CDATA #FIXED "8"
+             length CDATA #FIXED "4"
+             id %Digits; #REQUIRED>
+
+   <!ELEMENT timestamp (tstamp)+>
+   <!-- 0 <= oflw <=15 -->
+
+
+
+Kennedy                      Informational                     [Page 10]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST timestamp
+             copied CDATA #FIXED "0"
+             class  CDATA #FIXED "2"
+             number CDATA #FIXED "4"
+             length %Digits;  #REQUIRED
+             pointer %Digits; #REQUIRED
+             oflw %Digits;    #REQUIRED
+             flag (0 | 1 | 3)  #REQUIRED>
+
+   <!ELEMENT tstamp EMPTY>
+   <!ATTLIST tstamp
+             time %Digits;   #REQUIRED
+             address %IP4Addr; #IMPLIED>
+   <!--
+       padding to bring header to 32-bit boundary.
+       pad MUST be "0"*
+    -->
+   <!ELEMENT padding EMPTY>
+   <!ATTLIST padding
+             pad CDATA #REQUIRED>
+
+   <!-- payload MUST be encoded as base-64 [RFC2045], as modified
+        by section 2.1 of this RFC -->
+   <!ELEMENT payload (CDATA)>
+
+7.2.  TCPoXML DTD
+
+   <!--
+      DTD for TCP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE tcp PUBLIC "-//IETF//DTD BLOAT 1.0 TCP//EN" "bloat.dtd">
+   -->
+
+   <!-- the pseudoheader is only included for checksum calculations -->
+   <!ELEMENT tcp (tcp.pseudoheader?, tcp.header, payload)>
+
+   <!ELEMENT tcp.header (src, dest, sequence, acknowledgement, offset,
+                         reserved, control, window, checksum, urgent,
+                         tcp.options, padding)>
+
+   <!ELEMENT src EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+   <!ATTLIST src
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT dest EMPTY>
+   <!-- 0 <= port <= 65,535 -->
+
+
+
+Kennedy                      Informational                     [Page 11]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ATTLIST dest
+             port %Digits; #REQUIRED>
+
+   <!ELEMENT sequence EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST sequence
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT acknowledgement EMPTY>
+   <!-- 0 <= number <= 4294967295 -->
+   <!ATTLIST acknowledgement
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT offset EMPTY>
+   <!-- 0 <= number <= 255 -->
+   <!ATTLIST offset
+             number %Digits; #REQUIRED>
+
+   <!ELEMENT reserved EMPTY>
+   <!ATTLIST reserved
+             value CDATA #FIXED "0">
+
+   <!ELEMENT control EMPTY>
+   <!ATTLIST control
+             urg (0|1) #IMPLIED
+             ack (0|1) #IMPLIED
+             psh (0|1) #IMPLIED
+             rst (0|1) #IMPLIED
+             syn (0|1) #IMPLIED
+             fin (0|1) #IMPLIED>
+
+   <!ELEMENT window EMPTY>
+   <!-- 0 <= size <= 65,535 -->
+   <!ATTLIST window
+             size %Digits; #REQUIRED>
+
+   <!--
+      checksum as in ip, but with
+      the following pseudo-header added into the tcp element:
+     -->
+   <!ELEMENT tcp.pseudoheader (source, destination, protocol,
+                               tcp.length)>
+
+   <!--
+      tcp header + data length in octets. does not include the size of
+
+      the pseudoheader.
+    -->
+
+
+
+Kennedy                      Informational                     [Page 12]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   <!ELEMENT tcp.length EMPTY>
+   <!ATTLIST tcp.length
+             value %Digits; #REQUIRED>
+
+   <!ELEMENT urgent EMPTY>
+   <!-- 0 <= pointer <= 65,535 -->
+   <!ATTLIST urgent
+             pointer %Digits; #REQUIRED>
+
+   <!ELEMENT tcp.options (tcp.end | tcp.noop | tcp.mss)+>
+
+   <!ELEMENT tcp.end EMPTY>
+   <!ATTLIST tcp.end
+             kind CDATA #FIXED "0">
+
+   <!ELEMENT tcp.noop EMPTY>
+   <!ATTLIST tcp.noop
+             kind CDATA #FIXED "1">
+
+   <!ELEMENT tcp.mss EMPTY>
+   <!ATTLIST tcp.mss
+             kind CDATA #FIXED "2"
+             length CDATA #FIXED "4"
+             size %Digits; #REQUIRED>
+
+7.3.  UDPoXML DTD
+
+   <!--
+      DTD for UDP over XML.
+      Refer to this DTD as:
+
+      <!DOCTYPE udp PUBLIC "-//IETF//DTD BLOAT 1.0 UDP//EN" "bloat.dtd">
+   -->
+
+   <!ELEMENT udp (udp.pseudoheader?, udp.header, payload)>
+
+   <!ELEMENT udp.header (src, dest, udp.length, checksum)>
+
+   <!ELEMENT udp.pseudoheader (source, destination, protocol,
+                               udp.length)>
+
+   <!--
+      udp header + data length in octets. does not include the size of
+      the pseudoheader.
+    -->
+   <!ELEMENT udp.length EMPTY>
+   <!ATTLIST udp.length
+             value %Digits; #REQUIRED>
+
+
+
+Kennedy                      Informational                     [Page 13]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+8. Security Considerations
+
+   XML, as a subset of SGML, has the same security considerations as
+   specified in SGML Media Types [RFC1874].  Security considerations
+   that apply to IP, TCP and UDP also likely apply to BLOAT as it does
+   not attempt to correct for issues not related to message format.
+
+9.   References
+
+   [JABBER]    Miller, J., "Jabber", draft-miller-jabber-00.txt,
+               February 2002. (Work in Progress)
+
+   [RFC768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+               August 1980.
+
+   [RFC791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
+               September 1981.
+
+   [RFC793]    Postel, J., "Transmission Control Protocol", STD 7, RFC
+               793, September 1981.
+
+   [RFC894]    Hornig, C., "Standard for the Transmission of IP
+               Datagrams over Ethernet Networks.", RFC 894, April 1984.
+
+   [RFC1042]   Postel, J. and J. Reynolds, "Standard for the
+               Transmission of IP Datagrams Over IEEE 802 Networks", STD
+               43, RFC 1042, February 1988.
+
+   [RFC1123]   Braden, R., "Requirements for Internet Hosts -
+               Application and Support", RFC 1123, October 1989.
+
+   [RFC1874]   Levinson, E., "SGML Media Types", RFC 1874, December
+               1995.
+
+   [RFC2003]   Perkins, C., "IP Encapsulation within IP", RFC 2003,
+               October 1996.
+
+   [RFC2045]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part One: Format of Internet Message
+               Bodies", RFC 2045, November 1996.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2279]   Yergeau, F., "UTF-8, a transformation format of ISO
+               10646", RFC 2279, January 1998.
+
+
+
+
+
+Kennedy                      Informational                     [Page 14]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+   [RFC2460]   Deering, S. and R. Hinden, "Internet Protocol, Version 6
+               (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC3080]   Rose, M., "The Blocks Extensible Exchange Protocol Core",
+               RFC 3080, March 2001.
+
+   [SOAP]      Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
+               Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D.,
+               "Simple Object Access Protocol (SOAP) 1.1" World Wide Web
+               Consortium Note, May 2000 http://www.w3.org/TR/SOAP/
+
+   [XML]       Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible
+               Markup Language (XML)" World Wide Web Consortium
+               Recommendation REC- xml-19980210.
+               http://www.w3.org/TR/1998/REC-xml-19980210
+
+10.  Author's Address
+
+   Hugh Kennedy
+   Mimezine
+   1060 West Addison
+   Chicago, IL 60613
+   USA
+
+   EMail: kennedyh@engin.umich.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 15]
+
+RFC 3252         Binary Lexical Octet Ad-hoc Transport      1 April 2002
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kennedy                      Informational                     [Page 16]
+
diff --git a/tests/manual/network_stresstest/tst_network_stresstest.cpp b/tests/manual/network_stresstest/tst_network_stresstest.cpp
new file mode 100644
index 0000000..34d83e1
--- /dev/null
+++ b/tests/manual/network_stresstest/tst_network_stresstest.cpp
@@ -0,0 +1,771 @@
+/****************************************************************************
+**
+** Copyright (C) 2010 Nokia Corporation and/or its subsidiary(-ies).
+** All rights reserved.
+** Contact: Nokia Corporation (qt-info@nokia.com)
+**
+** This file is part of the test suite of the Qt Toolkit.
+**
+** $QT_BEGIN_LICENSE:LGPL$
+** No Commercial Usage
+** This file contains pre-release code and may not be distributed.
+** You may use this file in accordance with the terms and conditions
+** contained in the Technology Preview License Agreement accompanying
+** this package.
+**
+** GNU Lesser General Public License Usage
+** Alternatively, this file may be used under the terms of the GNU Lesser
+** General Public License version 2.1 as published by the Free Software
+** Foundation and appearing in the file LICENSE.LGPL included in the
+** packaging of this file.  Please review the following information to
+** ensure the GNU Lesser General Public License version 2.1 requirements
+** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
+**
+** In addition, as a special exception, Nokia gives you certain additional
+** rights.  These rights are described in the Nokia Qt LGPL Exception
+** version 1.1, included in the file LGPL_EXCEPTION.txt in this package.
+**
+** If you have questions regarding the use of this file, please contact
+** Nokia at qt-info@nokia.com.
+**
+**
+**
+**
+**
+**
+**
+**
+** $QT_END_LICENSE$
+**
+****************************************************************************/
+
+#include <QtTest/QtTest>
+#include <QtCore/QThread>
+#include <QtCore/QSemaphore>
+#include <QtCore/QElapsedTimer>
+#include <QtCore/QSharedPointer>
+#include <QtCore/QVector>
+#include <QtNetwork/QTcpSocket>
+#include <QtNetwork/QNetworkReply>
+#include <QtNetwork/QNetworkAccessManager>
+
+#ifdef QT_BUILD_INTERNAL
+# include <private/qnetworkaccessmanager_p.h>
+#endif
+
+#include "minihttpserver.h"
+#include "../../auto/network-settings.h"
+
+#include <qplatformdefs.h>
+#ifdef Q_OS_UNIX
+# include <sys/types.h>
+# include <sys/socket.h>
+# include <sys/select.h>
+# include <netinet/in.h>
+# include <errno.h>
+# include <netdb.h>
+# include <signal.h>
+# include <unistd.h>
+# include <fcntl.h>
+
+typedef int SOCKET;
+# define INVALID_SOCKET -1
+# define SOCKET_ERROR -1
+
+#elif defined(Q_OS_WIN)
+# include <winsock2.h>
+#endif
+
+class tst_NetworkStressTest : public QObject
+{
+    Q_OBJECT
+public:
+    enum { AttemptCount = 100 };
+    tst_NetworkStressTest();
+    MiniHttpServer server;
+
+    qint64 byteCounter;
+    QNetworkAccessManager manager;
+    bool intermediateDebug;
+
+private:
+    void clearManager();
+
+public slots:
+    void initTestCase_data();
+    void init();
+
+    void slotReadAll() { byteCounter += static_cast<QIODevice *>(sender())->readAll().size(); }
+
+private Q_SLOTS:
+    void nativeBlockingConnectDisconnect();
+    void nativeNonBlockingConnectDisconnect();
+    void blockingConnectDisconnect();
+    void blockingPipelined();
+    void blockingMultipleRequests();
+    void connectDisconnect();
+    void parallelConnectDisconnect_data();
+    void parallelConnectDisconnect();
+    void namGet_data();
+    void namGet();
+};
+
+tst_NetworkStressTest::tst_NetworkStressTest()
+    : intermediateDebug(qgetenv("STRESSDEBUG").toInt() > 0)
+{
+#ifdef Q_OS_WIN
+    WSAData wsadata;
+
+    // IPv6 requires Winsock v2.0 or better.
+    WSAStartup(MAKEWORD(2,0), &wsadata);
+#elif defined(Q_OS_UNIX) && !defined(Q_OS_SYMBIAN)
+    ::signal(SIGALRM, SIG_IGN);
+#endif
+}
+
+void tst_NetworkStressTest::initTestCase_data()
+{
+    QTest::addColumn<bool>("isLocalhost");
+    QTest::addColumn<QString>("hostname");
+    QTest::addColumn<int>("port");
+
+    QTest::newRow("localhost") << true << "localhost" << server.port();
+    QTest::newRow("remote") << false << QtNetworkSettings::serverName() << 80;
+}
+
+void tst_NetworkStressTest::init()
+{
+    // clear the internal cache
+#ifndef QT_BUILD_INTERNAL
+    if (strncmp(QTest::currentTestFunction(), "nam") == 0)
+        QSKIP("QNetworkAccessManager tests disabled", SkipAll);
+#endif
+}
+
+void tst_NetworkStressTest::clearManager()
+{
+#ifdef QT_BUILD_INTERNAL
+    QNetworkAccessManagerPrivate::clearCache(&manager);
+    manager.setProxy(QNetworkProxy());
+    manager.setCache(0);
+#endif
+}
+
+bool nativeLookup(const char *hostname, int port, QByteArray &buf)
+{
+#if !defined(QT_NO_GETADDRINFO) && 0
+    addrinfo *res = 0;
+    struct addrinfo hints;
+    memset(&hints, 0, sizeof(hints));
+    hints.ai_family = PF_UNSPEC;
+
+    int result = getaddrinfo(QUrl::toAce(hostname).constData(), QByteArray::number(port).constData(), &hints, &res);
+    if (!result)
+        return false;
+    for (addrinfo *node = res; node; node = node->ai_next) {
+        if (node->ai_family == AF_INET) {
+            buf = QByteArray((char *)node->ai_addr, node->ai_addrlen);
+            break;
+        }
+    }
+    freeaddrinfo(res);
+#else
+    hostent *result = gethostbyname(hostname);
+    if (!result || result->h_addrtype != AF_INET)
+        return false;
+
+    struct sockaddr_in s;
+    s.sin_family = AF_INET;
+    s.sin_port = htons(port);
+    s.sin_addr =  *(struct in_addr *) result->h_addr_list[0];
+
+    buf = QByteArray((char *)&s, sizeof s);
+#endif
+
+    return !buf.isEmpty();
+}
+
+bool nativeSelect(int fd, int timeout, bool selectForWrite)
+{
+    if (timeout < 0)
+        return false;
+
+    // wait for connected
+    fd_set fds, fde;
+    FD_ZERO(&fds);
+    FD_ZERO(&fde);
+    FD_SET(fd, &fds);
+    FD_SET(fd, &fde);
+
+    int ret;
+    do {
+        struct timeval tv;
+        tv.tv_sec = timeout / 1000;
+        tv.tv_usec = timeout % 1000;
+        if (selectForWrite)
+            ret = ::select(fd + 1, 0, &fds, &fde, &tv);
+        else
+            ret = ::select(fd + 1, &fds, 0, &fde, &tv);
+    } while (ret == -1 && errno == EINTR);
+    return ret != 0;
+}
+
+void tst_NetworkStressTest::nativeBlockingConnectDisconnect()
+{
+    QFETCH_GLOBAL(QString, hostname);
+    QFETCH_GLOBAL(int, port);
+
+    qint64 totalBytes = 0;
+    QElapsedTimer outerTimer;
+    outerTimer.start();
+
+    for (int i = 0; i < AttemptCount; ++i) {
+        QElapsedTimer timeout;
+        byteCounter = 0;
+        timeout.start();
+
+#if defined(Q_OS_UNIX) && !defined(Q_OS_SYMBIAN)
+        alarm(10);
+#endif
+
+        // look up the host
+        QByteArray addr;
+        if (!nativeLookup(QUrl::toAce(hostname).constData(), port, addr))
+            QFAIL("Lookup failed");
+
+        // connect
+        SOCKET fd = ::socket(AF_INET, SOCK_STREAM, 0);
+        QVERIFY(fd != INVALID_SOCKET);
+        QVERIFY(::connect(fd, (sockaddr *)addr.data(), addr.size()) != SOCKET_ERROR);
+
+        // send request
+        {
+            QByteArray request = "GET /qtest/bigfile HTTP/1.1\r\n"
+                                 "Connection: close\r\n"
+                                 "User-Agent: tst_QTcpSocket_stresstest/1.0\r\n"
+                                 "Host: " + hostname.toLatin1() + "\r\n"
+                                 "\r\n";
+            qint64 bytesWritten = 0;
+            while (bytesWritten < request.size()) {
+                qint64 ret = ::send(fd, request.constData() + bytesWritten, request.size() - bytesWritten, 0);
+                if (ret == -1) {
+                    ::close(fd);
+                    QFAIL("Timeout");
+                }
+                bytesWritten += ret;
+            }
+        }
+
+        // receive reply
+        char buf[16384];
+        while (true) {
+            qint64 ret = ::recv(fd, buf, sizeof buf, 0);
+            if (ret == -1) {
+                ::close(fd);
+                QFAIL("Timeout");
+            } else if (ret == 0) {
+                break; // EOF
+            }
+            byteCounter += ret;
+        }
+        ::close(fd);
+
+        totalBytes += byteCounter;
+        if (intermediateDebug) {
+            double rate = (byteCounter * 1.0 / timeout.elapsed());
+            qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:"
+                    << (rate / 1024.0 / 1024 * 1000) << "MB/s";
+        }
+    }
+    qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s";
+
+#if defined(Q_OS_UNIX) && !defined(Q_OS_SYMBIAN)
+    alarm(0);
+#endif
+}
+
+void tst_NetworkStressTest::nativeNonBlockingConnectDisconnect()
+{
+    QFETCH_GLOBAL(QString, hostname);
+    QFETCH_GLOBAL(int, port);
+
+    qint64 totalBytes = 0;
+    QElapsedTimer outerTimer;
+    outerTimer.start();
+
+    for (int i = 0; i < AttemptCount; ++i) {
+        QElapsedTimer timeout;
+        byteCounter = 0;
+        timeout.start();
+
+        // look up the host
+        QByteArray addr;
+        if (!nativeLookup(QUrl::toAce(hostname).constData(), port, addr))
+            QFAIL("Lookup failed");
+
+        SOCKET fd;
+
+        {
+#if defined(Q_OS_UNIX)
+            fd = ::socket(AF_INET, SOCK_STREAM, 0);
+            QVERIFY(fd != INVALID_SOCKET);
+
+            // set the socket to non-blocking and start connecting
+# if !defined(Q_OS_VXWORKS)
+            int flags = ::fcntl(fd, F_GETFL, 0);
+            QVERIFY(flags != -1);
+            QVERIFY(::fcntl(fd, F_SETFL, flags | O_NONBLOCK) != -1);
+# else // Q_OS_VXWORKS
+            int onoff = 1;
+            QVERIFY(::ioctl(socketDescriptor, FIONBIO, &onoff) >= 0);
+# endif // Q_OS_VXWORKS
+            while (true) {
+                if (::connect(fd, (sockaddr *)addr.data(), addr.size()) == -1) {
+                    QVERIFY2(errno == EINPROGRESS, QByteArray("Error connecting: ").append(strerror(errno)).constData());
+                    QVERIFY2(nativeSelect(fd, 10000 - timeout.elapsed(), true), "Timeout");
+                } else {
+                    break; // connected
+                }
+            }
+#elif defined(Q_OS_WIN)
+            fd = ::WSASocket(AF_INET, SOCK_STREAM, 0, NULL, 0, WSA_FLAG_OVERLAPPED);
+            QVERIFY(fd != INVALID_SOCKET);
+
+            // set the socket to non-blocking and start connecting
+            unsigned long buf = v;
+            unsigned long outBuf;
+            DWORD sizeWritten = 0;
+            QVERIFY(::WSAIoctl(fd, FIONBIO, &buf, sizeof(unsigned long), &outBuf, sizeof(unsigned long), &sizeWritten, 0,0) != SOCKET_ERROR);
+
+            while (true) {
+                int connectResult = ::WSAConnect(fd, sockAddrPtr, sockAddrSize, 0,0,0,0);
+                if (connectResult == 0 || WSAGetLastError() == WSAEISCONN) {
+                    break; // connected
+                } else {
+                    QVERIFY2(WSAGetLastError() == WSAEINPROGRESS, "Unexpected error");
+                    QVERIFY2(nativeSelect(fd, 10000 - timeout.elapsed(), true), "Timeout");
+                }
+            }
+#endif
+        }
+
+        // send request
+        {
+            QByteArray request = "GET /qtest/bigfile HTTP/1.1\r\n"
+                                 "Connection: close\r\n"
+                                 "User-Agent: tst_QTcpSocket_stresstest/1.0\r\n"
+                                 "Host: " + hostname.toLatin1() + "\r\n"
+                                 "\r\n";
+            qint64 bytesWritten = 0;
+            while (bytesWritten < request.size()) {
+                qint64 ret = ::send(fd, request.constData() + bytesWritten, request.size() - bytesWritten, 0);
+                if (ret == -1 && errno != EWOULDBLOCK) {
+                    ::close(fd);
+                    QFAIL(QByteArray("Error writing: ").append(strerror(errno)).constData());
+                } else if (ret == -1) {
+                    // wait for writing
+                    QVERIFY2(nativeSelect(fd, 10000 - timeout.elapsed(), true), "Timeout");
+                    continue;
+                }
+                bytesWritten += ret;
+            }
+        }
+
+        // receive reply
+        char buf[16384];
+        while (true) {
+            qint64 ret = ::recv(fd, buf, sizeof buf, 0);
+            if (ret == -1 && errno != EWOULDBLOCK) {
+                ::close(fd);
+                QFAIL("Timeout");
+            } else if (ret == -1) {
+                // wait for reading
+                QVERIFY2(nativeSelect(fd, 10000 - timeout.elapsed(), false), "Timeout");
+            } else if (ret == 0) {
+                break; // EOF
+            }
+            byteCounter += ret;
+        }
+        ::close(fd);
+
+        totalBytes += byteCounter;
+        if (intermediateDebug) {
+            double rate = (byteCounter * 1.0 / timeout.elapsed());
+            qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:"
+                    << (rate / 1024.0 / 1024 * 1000) << "MB/s";
+        }
+    }
+    qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s";
+}
+
+void tst_NetworkStressTest::blockingConnectDisconnect()
+{
+    QFETCH_GLOBAL(QString, hostname);
+    QFETCH_GLOBAL(int, port);
+
+    qint64 totalBytes = 0;
+    QElapsedTimer outerTimer;
+    outerTimer.start();
+
+    for (int i = 0; i < AttemptCount; ++i) {
+        QElapsedTimer timeout;
+        byteCounter = 0;
+        timeout.start();
+
+        QTcpSocket socket;
+        socket.connectToHost(hostname, port);
+        QVERIFY2(socket.waitForConnected(), "Timeout");
+
+        socket.write("GET /qtest/bigfile HTTP/1.1\r\n"
+                     "Connection: close\r\n"
+                     "User-Agent: tst_QTcpSocket_stresstest/1.0\r\n"
+                     "Host: " + hostname.toLatin1() + "\r\n"
+                     "\r\n");
+        while (socket.bytesToWrite())
+            QVERIFY2(socket.waitForBytesWritten(), "Timeout");
+
+        while (socket.state() == QAbstractSocket::ConnectedState && !timeout.hasExpired(10000)) {
+            socket.waitForReadyRead();
+            byteCounter += socket.readAll().size(); // discard
+        }
+
+        totalBytes += byteCounter;
+        if (intermediateDebug) {
+            double rate = (byteCounter * 1.0 / timeout.elapsed());
+            qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:"
+                    << (rate / 1024.0 / 1024 * 1000) << "MB/s";
+        }
+    }
+    qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s";
+}
+
+void tst_NetworkStressTest::blockingPipelined()
+{
+    QFETCH_GLOBAL(QString, hostname);
+    QFETCH_GLOBAL(int, port);
+
+    qint64 totalBytes = 0;
+    QElapsedTimer outerTimer;
+    outerTimer.start();
+
+    for (int i = 0; i < AttemptCount / 2; ++i) {
+        QElapsedTimer timeout;
+        byteCounter = 0;
+        timeout.start();
+
+        QTcpSocket socket;
+        socket.connectToHost(hostname, port);
+        QVERIFY2(socket.waitForConnected(), "Timeout");
+
+        for (int j = 0 ; j < 3; ++j) {
+            if (intermediateDebug)
+                qDebug("Attempt %d%c", i, 'a' + j);
+            socket.write("GET /qtest/bigfile HTTP/1.1\r\n"
+                         "Connection: " + QByteArray(j == 2 ? "close" : "keep-alive") + "\r\n"
+                         "User-Agent: tst_QTcpSocket_stresstest/1.0\r\n"
+                         "Host: " + hostname.toLatin1() + "\r\n"
+                         "\r\n");
+            while (socket.bytesToWrite())
+                QVERIFY2(socket.waitForBytesWritten(), "Timeout");
+        }
+
+        while (socket.state() == QAbstractSocket::ConnectedState && !timeout.hasExpired(10000)) {
+            socket.waitForReadyRead();
+            byteCounter += socket.readAll().size(); // discard
+        }
+
+        totalBytes += byteCounter;
+        if (intermediateDebug) {
+            double rate = (byteCounter * 1.0 / timeout.elapsed());
+            qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:"
+                    << (rate / 1024.0 / 1024 * 1000) << "MB/s";
+        }
+    }
+    qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s";
+}
+
+void tst_NetworkStressTest::blockingMultipleRequests()
+{
+    QFETCH_GLOBAL(QString, hostname);
+    QFETCH_GLOBAL(int, port);
+
+    qint64 totalBytes = 0;
+    QElapsedTimer outerTimer;
+    outerTimer.start();
+
+    for (int i = 0; i < AttemptCount / 5; ++i) {
+        QTcpSocket socket;
+        socket.connectToHost(hostname, port);
+        QVERIFY2(socket.waitForConnected(), "Timeout");
+
+        for (int j = 0 ; j < 5; ++j) {
+            QElapsedTimer timeout;
+            byteCounter = 0;
+            timeout.start();
+
+            socket.write("GET /qtest/bigfile HTTP/1.1\r\n"
+                         "Connection: keep-alive\r\n"
+                         "User-Agent: tst_QTcpSocket_stresstest/1.0\r\n"
+                         "Host: " + hostname.toLatin1() + "\r\n"
+                         "\r\n");
+            while (socket.bytesToWrite())
+                QVERIFY2(socket.waitForBytesWritten(), "Timeout");
+
+            qint64 bytesRead = 0;
+            qint64 bytesExpected = -1;
+            QByteArray buffer;
+            while (socket.state() == QAbstractSocket::ConnectedState && !timeout.hasExpired(10000)) {
+                socket.waitForReadyRead();
+                buffer += socket.readAll();
+                byteCounter += buffer.size();
+                int pos = buffer.indexOf("\r\n\r\n");
+                if (pos == -1)
+                    continue;
+
+                bytesRead = buffer.length() - pos - 4;
+
+                buffer.truncate(pos + 2);
+                buffer = buffer.toLower();
+                pos = buffer.indexOf("\r\ncontent-length: ");
+                if (pos == -1) {
+                    qWarning() << "no content-length:" << QString(buffer);
+                    break;
+                }
+                pos += strlen("\r\ncontent-length: ");
+
+                int eol = buffer.indexOf("\r\n", pos + 2);
+                if (eol == -1) {
+                    qWarning() << "invalid header";
+                    break;
+                }
+
+                bytesExpected = buffer.mid(pos, eol - pos).toLongLong();
+                break;
+            }
+            QVERIFY(bytesExpected > 0);
+            QVERIFY2(!timeout.hasExpired(10000), "Timeout");
+
+            while (socket.state() == QAbstractSocket::ConnectedState && !timeout.hasExpired(10000) && bytesExpected > bytesRead) {
+                socket.waitForReadyRead();
+                int blocklen = socket.read(bytesExpected - bytesRead).length(); // discard
+                bytesRead += blocklen;
+                byteCounter += blocklen;
+            }
+            QVERIFY2(!timeout.hasExpired(10000), "Timeout");
+            QCOMPARE(bytesRead, bytesExpected);
+
+            totalBytes += byteCounter;
+            if (intermediateDebug) {
+                double rate = (byteCounter * 1.0 / timeout.elapsed());
+                qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:"
+                        << (rate / 1024.0 / 1024 * 1000) << "MB/s";
+            }
+        }
+
+        socket.disconnectFromHost();
+        QVERIFY(socket.state() == QAbstractSocket::UnconnectedState);
+    }
+    qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s";
+}
+
+void tst_NetworkStressTest::connectDisconnect()
+{
+    QFETCH_GLOBAL(QString, hostname);
+    QFETCH_GLOBAL(int, port);
+
+    qint64 totalBytes = 0;
+    QElapsedTimer outerTimer;
+    outerTimer.start();
+
+    for (int i = 0; i < AttemptCount; ++i) {
+        QElapsedTimer timeout;
+        byteCounter = 0;
+        timeout.start();
+
+        QTcpSocket socket;
+        socket.connectToHost(hostname, port);
+
+        socket.write("GET /qtest/bigfile HTTP/1.1\r\n"
+                     "Connection: close\r\n"
+                     "User-Agent: tst_QTcpSocket_stresstest/1.0\r\n"
+                     "Host: " + hostname.toLatin1() + "\r\n"
+                     "\r\n");
+        connect(&socket, SIGNAL(readyRead()), SLOT(slotReadAll()));
+
+        QTestEventLoop::instance().connect(&socket, SIGNAL(disconnected()), SLOT(exitLoop()));
+        QTestEventLoop::instance().enterLoop(30);
+        QVERIFY2(!QTestEventLoop::instance().timeout(), "Timeout");
+
+        totalBytes += byteCounter;
+        if (intermediateDebug) {
+            double rate = (byteCounter * 1.0 / timeout.elapsed());
+            qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:"
+                    << (rate / 1024.0 / 1024 * 1000) << "MB/s";
+        }
+    }
+    qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s";
+}
+
+void tst_NetworkStressTest::parallelConnectDisconnect_data()
+{
+    QTest::addColumn<int>("parallelAttempts");
+    QTest::newRow("1") << 1;
+    QTest::newRow("2") << 2;
+    QTest::newRow("4") << 4;
+    QTest::newRow("5") << 5;
+    QTest::newRow("6") << 6;
+    QTest::newRow("8") << 8;
+    QTest::newRow("10") << 10;
+    QTest::newRow("25") << 25;
+    QTest::newRow("100") << 100;
+    QTest::newRow("500") << 500;
+}
+
+void tst_NetworkStressTest::parallelConnectDisconnect()
+{
+    QFETCH_GLOBAL(QString, hostname);
+    QFETCH_GLOBAL(int, port);
+    QFETCH(int, parallelAttempts);
+
+    if (parallelAttempts > 100) {
+        QFETCH_GLOBAL(bool, isLocalhost);
+        if (!isLocalhost)
+            QSKIP("Localhost-only test", SkipSingle);
+    }
+
+    qint64 totalBytes = 0;
+    QElapsedTimer outerTimer;
+    outerTimer.start();
+
+    for (int i = 0; i < qMax(2, AttemptCount/qMax(2, parallelAttempts/4)); ++i) {
+        QElapsedTimer timeout;
+        byteCounter = 0;
+        timeout.start();
+
+        QTcpSocket *socket = new QTcpSocket[parallelAttempts];
+        for (int j = 0; j < parallelAttempts; ++j) {
+            socket[j].connectToHost(hostname, port);
+
+            socket[j].write("GET /qtest/bigfile HTTP/1.1\r\n"
+                            "Connection: close\r\n"
+                            "User-Agent: tst_QTcpSocket_stresstest/1.0\r\n"
+                            "Host: " + hostname.toLatin1() + "\r\n"
+                            "\r\n");
+            connect(&socket[j], SIGNAL(readyRead()), SLOT(slotReadAll()));
+
+            QTestEventLoop::instance().connect(&socket[j], SIGNAL(disconnected()), SLOT(exitLoop()));
+        }
+
+        while (!timeout.hasExpired(30000)) {
+            QTestEventLoop::instance().enterLoop(10);
+            int done = 0;
+            for (int j = 0; j < parallelAttempts; ++j)
+                done += socket[j].state() == QAbstractSocket::UnconnectedState ? 1 : 0;
+            if (done == parallelAttempts)
+                break;
+        }
+        delete[] socket;
+        QVERIFY2(!timeout.hasExpired(30000), "Timeout");
+
+        totalBytes += byteCounter;
+        if (intermediateDebug) {
+            double rate = (byteCounter * 1.0 / timeout.elapsed());
+            qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:"
+                    << (rate / 1024.0 / 1024 * 1000) << "MB/s";
+        }
+    }
+    qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s";
+}
+
+void tst_NetworkStressTest::namGet_data()
+{
+    QTest::addColumn<int>("parallelAttempts");
+    QTest::addColumn<bool>("pipelineAllowed");
+
+    QTest::newRow("1") << 1 << false;
+    QTest::newRow("1p") << 1 << true;
+    QTest::newRow("2") << 2 << false;
+    QTest::newRow("2p") << 2 << true;
+    QTest::newRow("4") << 4 << false;
+    QTest::newRow("4p") << 4 << true;
+    QTest::newRow("5") << 5 << false;
+    QTest::newRow("5p") << 5 << true;
+    QTest::newRow("6") << 6 << false;
+    QTest::newRow("6p") << 6 << true;
+    QTest::newRow("8") << 8 << false;
+    QTest::newRow("8p") << 8 << true;
+    QTest::newRow("10") << 10 << false;
+    QTest::newRow("10p") << 10 << true;
+    QTest::newRow("25") << 25 << false;
+    QTest::newRow("25p") << 25 << true;
+    QTest::newRow("100") << 100 << false;
+    QTest::newRow("100p") << 100 << true;
+    QTest::newRow("500") << 500 << false;
+    QTest::newRow("500p") << 500 << true;
+}
+
+void tst_NetworkStressTest::namGet()
+{
+    QFETCH_GLOBAL(QString, hostname);
+    QFETCH_GLOBAL(int, port);
+    QFETCH(int, parallelAttempts);
+    QFETCH(bool, pipelineAllowed);
+
+    if (parallelAttempts > 100) {
+        QFETCH_GLOBAL(bool, isLocalhost);
+        if (!isLocalhost)
+            QSKIP("Localhost-only test", SkipSingle);
+    }
+
+    qint64 totalBytes = 0;
+    QElapsedTimer outerTimer;
+    outerTimer.start();
+
+    for (int i = 0; i < qMax(2, AttemptCount/qMax(2, parallelAttempts/4)); ++i) {
+        QElapsedTimer timeout;
+        byteCounter = 0;
+        timeout.start();
+
+        QUrl url;
+        url.setScheme("http");
+        url.setHost(hostname);
+        url.setPort(port);
+        url.setEncodedPath("/qtest/bigfile");
+        QNetworkRequest req(url);
+        req.setAttribute(QNetworkRequest::HttpPipeliningAllowedAttribute, pipelineAllowed);
+
+        QVector<QSharedPointer<QNetworkReply> > replies;
+        replies.resize(parallelAttempts);
+        for (int j = 0; j < parallelAttempts; ++j) {
+            QNetworkReply *r = manager.get(req);
+
+            connect(r, SIGNAL(readyRead()), SLOT(slotReadAll()));
+            QTestEventLoop::instance().connect(r, SIGNAL(finished()), SLOT(exitLoop()));
+
+            replies[j] = QSharedPointer<QNetworkReply>(r);
+        }
+
+        while (!timeout.hasExpired(30000)) {
+            QTestEventLoop::instance().enterLoop(10);
+            int done = 0;
+            for (int j = 0; j < parallelAttempts; ++j)
+                done += replies[j]->isFinished() ? 1 : 0;
+            if (done == parallelAttempts)
+                break;
+        }
+        replies.clear();
+
+        QVERIFY2(!timeout.hasExpired(30000), "Timeout");
+        totalBytes += byteCounter;
+        if (intermediateDebug) {
+            double rate = (byteCounter * 1.0 / timeout.elapsed());
+            qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:"
+                    << (rate / 1024.0 / 1024 * 1000) << "MB/s";
+        }
+    }
+    qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s";
+}
+
+QTEST_MAIN(tst_NetworkStressTest);
+
+#include "tst_network_stresstest.moc"
diff --git a/tests/manual/network_stresstest/wwwfiles.qrc b/tests/manual/network_stresstest/wwwfiles.qrc
new file mode 100644
index 0000000..4d602a1
--- /dev/null
+++ b/tests/manual/network_stresstest/wwwfiles.qrc
@@ -0,0 +1,5 @@
+<RCC>
+    <qresource prefix="/">
+        <file>qtest</file>
+    </qresource>
+</RCC>