From 779123b79cc27599f73a61b2f2055a32cc15230a Mon Sep 17 00:00:00 2001 From: Jason Barron Date: Tue, 13 Apr 2010 17:37:06 +0200 Subject: Implement OpenVG buffer scrolling and enable it on Symbian. Add support for accelerated scrolling in the "direct" window surface implementation. Using vgCopyPixels(), the already rasterized content on the surface can be shifted to a new location such that only a portion of the suqsequent frame needs to be repainted instead of the entire frame. This only works when the "preserved" EGL swap behavior is enabled and the impact on performance is highly dependant on the specific hardware platform in use. Task-number: QT-2972 Reviewed-by: Rhys Weatherley --- doc/src/howtos/openvg.qdoc | 10 ++++++++++ doc/src/platforms/emb-openvg.qdocinc | 6 ++++++ src/openvg/openvg.pro | 2 +- src/openvg/qwindowsurface_vg.cpp | 5 ++++- src/openvg/qwindowsurface_vgegl.cpp | 27 +++++++++++++++++++++++++++ src/openvg/qwindowsurface_vgegl_p.h | 4 ++++ 6 files changed, 52 insertions(+), 2 deletions(-) diff --git a/doc/src/howtos/openvg.qdoc b/doc/src/howtos/openvg.qdoc index 9c805bb..f70ed54 100644 --- a/doc/src/howtos/openvg.qdoc +++ b/doc/src/howtos/openvg.qdoc @@ -295,6 +295,16 @@ Convolution, colorize, drop shadow, and blur filters are accelerated using OpenVG operations. + \section2 Scrolling + + By default, accelerated scrolling is not enabled because the impact on + performance is very much tied to the hardware platform. To enable + accelerated scrolling, you should ensure that QVG_BUFFER_SCROLLING is + defined when compiling the QtOpenVG module. + + You should only enable this feature if vgCopyPixels() is known to be + efficient on your hardware platform. + \section1 Known issues Performance of copying the contents of an OpenVG-rendered window to the diff --git a/doc/src/platforms/emb-openvg.qdocinc b/doc/src/platforms/emb-openvg.qdocinc index 37ccb9c..2f9cc21 100644 --- a/doc/src/platforms/emb-openvg.qdocinc +++ b/doc/src/platforms/emb-openvg.qdocinc @@ -259,6 +259,12 @@ at present. \o Convolution, colorize, drop shadow, and blur filters are accelerated using OpenVG operations. + \row + \o Scrolling + \o Accelerated scrolling is implemented but disabled by default +unless QVG_BUFFER_SCROLLING is defined. This should only be enabled on +OpenVG engines where vgCopyPixels() is known to be efficient. + \endtable \section2 Known issues diff --git a/src/openvg/openvg.pro b/src/openvg/openvg.pro index 3790492..883f0f3 100644 --- a/src/openvg/openvg.pro +++ b/src/openvg/openvg.pro @@ -33,7 +33,7 @@ contains(QT_CONFIG, egl) { qwindowsurface_vgegl.cpp } -symbian: DEFINES += QVG_RECREATE_ON_SIZE_CHANGE +symbian: DEFINES += QVG_RECREATE_ON_SIZE_CHANGE QVG_BUFFER_SCROLLING include(../qbase.pri) diff --git a/src/openvg/qwindowsurface_vg.cpp b/src/openvg/qwindowsurface_vg.cpp index 83b0764..c19d5d1 100644 --- a/src/openvg/qwindowsurface_vg.cpp +++ b/src/openvg/qwindowsurface_vg.cpp @@ -57,6 +57,7 @@ QVGWindowSurface::QVGWindowSurface(QWidget *window) { // Create the default type of EGL window surface for windows. d_ptr = new QVGEGLWindowSurfaceDirect(this); + setStaticContentsSupport(d_ptr->supportsStaticContents()); } QVGWindowSurface::QVGWindowSurface @@ -89,7 +90,9 @@ void QVGWindowSurface::setGeometry(const QRect &rect) bool QVGWindowSurface::scroll(const QRegion &area, int dx, int dy) { - return QWindowSurface::scroll(area, dx, dy); + if (!d_ptr->scroll(window(), area, dx, dy)) + return QWindowSurface::scroll(area, dx, dy); + return true; } void QVGWindowSurface::beginPaint(const QRegion ®ion) diff --git a/src/openvg/qwindowsurface_vgegl.cpp b/src/openvg/qwindowsurface_vgegl.cpp index 46a905f..99b614b 100644 --- a/src/openvg/qwindowsurface_vgegl.cpp +++ b/src/openvg/qwindowsurface_vgegl.cpp @@ -758,6 +758,33 @@ void QVGEGLWindowSurfaceDirect::endPaint } } +bool QVGEGLWindowSurfaceDirect::supportsStaticContents() const +{ +#if defined(QVG_BUFFER_SCROLLING) && !defined(QVG_NO_PRESERVED_SWAP) + return true; +#else + return QVGEGLWindowSurfacePrivate::supportsStaticContents(); +#endif +} + +bool QVGEGLWindowSurfaceDirect::scroll(QWidget *widget, const QRegion& area, int dx, int dy) +{ +#ifdef QVG_BUFFER_SCROLLING + QEglContext *context = ensureContext(widget); + if (context) { + context->makeCurrent(windowSurface); + QRect scrollRect = area.boundingRect(); + int sx = scrollRect.x(); + int sy = size.height() - scrollRect.y() - scrollRect.height(); + vgSeti(VG_SCISSORING, VG_FALSE); + vgCopyPixels(sx + dx, sy - dy, sx, sy, scrollRect.width(), scrollRect.height()); + context->lazyDoneCurrent(); + return true; + } +#endif + return false; +} + QT_END_NAMESPACE #endif diff --git a/src/openvg/qwindowsurface_vgegl_p.h b/src/openvg/qwindowsurface_vgegl_p.h index aa0c648..892fd9d 100644 --- a/src/openvg/qwindowsurface_vgegl_p.h +++ b/src/openvg/qwindowsurface_vgegl_p.h @@ -77,6 +77,8 @@ public: (QWidget *widget, const QRegion& region, QImage *image = 0) = 0; virtual VGImage surfaceImage() const; virtual QSize surfaceSize() const = 0; + virtual bool supportsStaticContents() const { return false; } + virtual bool scroll(QWidget *, const QRegion&, int, int) { return false; } private: QVGPaintEngine *engine; @@ -128,6 +130,8 @@ public: void beginPaint(QWidget *widget); void endPaint(QWidget *widget, const QRegion& region, QImage *image); QSize surfaceSize() const { return size; } + bool supportsStaticContents() const; + bool scroll(QWidget *widget, const QRegion& area, int dx, int dy); protected: QEglContext *context; -- cgit v0.12 From 4d3d85e1a9de727329e8a8df3b572a778e2da6e2 Mon Sep 17 00:00:00 2001 From: Markus Goetz Date: Wed, 14 Apr 2010 11:25:58 +0200 Subject: QFtp: Fix possible crash Task-number: QTBUG-7359 --- src/network/access/qftp.cpp | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/network/access/qftp.cpp b/src/network/access/qftp.cpp index efeef4e..7f6df0a 100644 --- a/src/network/access/qftp.cpp +++ b/src/network/access/qftp.cpp @@ -2309,6 +2309,12 @@ void QFtpPrivate::_q_piFinished(const QString&) void QFtpPrivate::_q_piError(int errorCode, const QString &text) { Q_Q(QFtp); + + if (pending.isEmpty()) { + qWarning() << "QFtpPrivate::_q_piError was called without pending command!"; + return; + } + QFtpCommand *c = pending.first(); // non-fatal errors -- cgit v0.12 From 00f01532342713e4adae0ce8ccd332829acfeec0 Mon Sep 17 00:00:00 2001 From: Kent Hansen Date: Wed, 14 Apr 2010 11:47:24 +0200 Subject: Improve test coverage of QtScript translation functions And fix two silly typos in the error messages. --- src/script/api/qscriptengine.cpp | 4 +-- tests/auto/qscriptengine/tst_qscriptengine.cpp | 42 ++++++++++++++++++++++++++ 2 files changed, 44 insertions(+), 2 deletions(-) diff --git a/src/script/api/qscriptengine.cpp b/src/script/api/qscriptengine.cpp index ccd3e56..9bd98f1 100644 --- a/src/script/api/qscriptengine.cpp +++ b/src/script/api/qscriptengine.cpp @@ -663,7 +663,7 @@ JSC::JSValue JSC_HOST_CALL functionQsTranslate(JSC::ExecState *exec, JSC::JSObje else if (encStr == QLatin1String("UnicodeUTF8")) encoding = QCoreApplication::UnicodeUTF8; else - return JSC::throwError(exec, JSC::GeneralError, QString::fromLatin1("qsTranslate(): invalid encoding '%s'").arg(encStr)); + return JSC::throwError(exec, JSC::GeneralError, QString::fromLatin1("qsTranslate(): invalid encoding '%0'").arg(encStr)); } int n = -1; if (args.size() > 4) @@ -697,7 +697,7 @@ JSC::JSValue JSC_HOST_CALL functionQsTr(JSC::ExecState *exec, JSC::JSObject*, JS if ((args.size() > 1) && !args.at(1).isString()) return JSC::throwError(exec, JSC::GeneralError, "qsTr(): second argument (comment) must be a string"); if ((args.size() > 2) && !args.at(2).isNumber()) - return JSC::throwError(exec, JSC::GeneralError, "qsTranslate(): third argument (n) must be a number"); + return JSC::throwError(exec, JSC::GeneralError, "qsTr(): third argument (n) must be a number"); #ifndef QT_NO_QOBJECT QString context; // The first non-empty source URL in the call stack determines the translation context. diff --git a/tests/auto/qscriptengine/tst_qscriptengine.cpp b/tests/auto/qscriptengine/tst_qscriptengine.cpp index aa5c85d..674e502 100644 --- a/tests/auto/qscriptengine/tst_qscriptengine.cpp +++ b/tests/auto/qscriptengine/tst_qscriptengine.cpp @@ -155,6 +155,8 @@ private slots: void installTranslatorFunctions_data(); void installTranslatorFunctions(); void translateScript(); + void translateWithInvalidArgs_data(); + void translateWithInvalidArgs(); void functionScopes(); void nativeFunctionScopes(); void evaluateProgram(); @@ -4341,6 +4343,15 @@ void tst_QScriptEngine::translateScript() QCOMPARE(engine.evaluate("eval('qsTranslate(\\'FooContext\\', \\'Two\\')')", fileName).toString(), QString::fromLatin1("To")); QCOMPARE(engine.evaluate("eval('qsTranslate(\\'FooContext\\', \\'Goodbye\\')')", fileName).toString(), QString::fromLatin1("Farvel")); + QCOMPARE(engine.evaluate("qsTranslate('FooContext', 'Goodbye', '', 'UnicodeUTF8')", fileName).toString(), QString::fromLatin1("Farvel")); + + QVERIFY(engine.evaluate("QT_TR_NOOP()").isUndefined()); + QCOMPARE(engine.evaluate("QT_TR_NOOP('One')").toString(), QString::fromLatin1("One")); + + QVERIFY(engine.evaluate("QT_TRANSLATE_NOOP()").isUndefined()); + QVERIFY(engine.evaluate("QT_TRANSLATE_NOOP('FooContext')").isUndefined()); + QCOMPARE(engine.evaluate("QT_TRANSLATE_NOOP('FooContext', 'Two')").toString(), QString::fromLatin1("Two")); + // Don't exist in translation QCOMPARE(engine.evaluate("qsTr('Three')", fileName).toString(), QString::fromLatin1("Three")); QCOMPARE(engine.evaluate("qsTranslate('FooContext', 'So long')", fileName).toString(), QString::fromLatin1("So long")); @@ -4354,6 +4365,37 @@ void tst_QScriptEngine::translateScript() QCoreApplication::instance()->removeTranslator(&translator); } +void tst_QScriptEngine::translateWithInvalidArgs_data() +{ + QTest::addColumn("expression"); + QTest::addColumn("expectedError"); + + QTest::newRow("qsTr()") << "qsTr()" << "Error: qsTr() requires at least one argument"; + QTest::newRow("qsTr(123)") << "qsTr(123)" << "Error: qsTr(): first argument (text) must be a string"; + QTest::newRow("qsTr('foo', 123)") << "qsTr('foo', 123)" << "Error: qsTr(): second argument (comment) must be a string"; + QTest::newRow("qsTr('foo', 'bar', 'baz')") << "qsTr('foo', 'bar', 'baz')" << "Error: qsTr(): third argument (n) must be a number"; + QTest::newRow("qsTr('foo', 'bar', true)") << "qsTr('foo', 'bar', true)" << "Error: qsTr(): third argument (n) must be a number"; + + QTest::newRow("qsTranslate()") << "qsTranslate()" << "Error: qsTranslate() requires at least two arguments"; + QTest::newRow("qsTranslate('foo')") << "qsTranslate('foo')" << "Error: qsTranslate() requires at least two arguments"; + QTest::newRow("qsTranslate('foo', 123)") << "qsTranslate('foo', 123)" << "Error: qsTranslate(): second argument (text) must be a string"; + QTest::newRow("qsTranslate('foo', 'bar', 123)") << "qsTranslate('foo', 'bar', 123)" << "Error: qsTranslate(): third argument (comment) must be a string"; + QTest::newRow("qsTranslate('foo', 'bar', 'baz', 123)") << "qsTranslate('foo', 'bar', 'baz', 123)" << "Error: qsTranslate(): fourth argument (encoding) must be a string"; + QTest::newRow("qsTranslate('foo', 'bar', 'baz', 'zab', 'rab')") << "qsTranslate('foo', 'bar', 'baz', 'zab', 'rab')" << "Error: qsTranslate(): fifth argument (n) must be a number"; + QTest::newRow("qsTranslate('foo', 'bar', 'baz', 'zab', 123)") << "qsTranslate('foo', 'bar', 'baz', 'zab', 123)" << "Error: qsTranslate(): invalid encoding 'zab'"; +} + +void tst_QScriptEngine::translateWithInvalidArgs() +{ + QFETCH(QString, expression); + QFETCH(QString, expectedError); + QScriptEngine engine; + engine.installTranslatorFunctions(); + QScriptValue result = engine.evaluate(expression); + QVERIFY(result.isError()); + QCOMPARE(result.toString(), expectedError); +} + void tst_QScriptEngine::functionScopes() { QScriptEngine eng; -- cgit v0.12 From e4d03c6b56decd63035a7c46498dae2d2a483c09 Mon Sep 17 00:00:00 2001 From: Sami Merila Date: Wed, 14 Apr 2010 13:03:38 +0300 Subject: QS60Style: Sometimes progressbars do not animate Style removes every progressbar from animation list whenever *any* QWidget is hidden/shown. To ensure that the animation list is only tempered with possible animation supporting qwidgets, re-interpret cast them to QProgressBar. If this works, then clear the animation list. Task-number: QTBUG-9836 Reviewed-by: Alessandro Portale --- src/gui/styles/qs60style.cpp | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/gui/styles/qs60style.cpp b/src/gui/styles/qs60style.cpp index 28cbc45..f154b2d 100644 --- a/src/gui/styles/qs60style.cpp +++ b/src/gui/styles/qs60style.cpp @@ -3313,8 +3313,10 @@ bool QS60Style::eventFilter(QObject *object, QEvent *event) break; case QEvent::Destroy: case QEvent::Hide: - d->stopAnimation(QS60StyleEnums::SP_QgnGrafBarWaitAnim); - d->m_bars.removeAll(reinterpret_cast(object)); + if (QProgressBar *bar = reinterpret_cast(object)) { + d->stopAnimation(QS60StyleEnums::SP_QgnGrafBarWaitAnim); + d->m_bars.removeAll(bar); + } break; default: break; -- cgit v0.12 From fcd009cd77f95106f4522103bab9aaf86109a17d Mon Sep 17 00:00:00 2001 From: Olivier Goffart Date: Wed, 14 Apr 2010 11:28:09 +0200 Subject: QAbstractScrollArea StyleSheet: fix drawing of border with SH_ScrollView_FrameOnlyAroundContents - Since Qt 4.6.0, the frame is drawn by PE_Widget, but there we do not take in account the scrollbar for the case where SH_ScrollView_FrameOnlyAroundContents is true. - We also reserved too much space for the border, as we included the native border as well in the computation, so do not reserve additional space by setting PM_ScrollView_ScrollBarSpacing to 0 Task-number: QTBUG-9821 Reviewed-by: jbache --- src/gui/styles/qstylesheetstyle.cpp | 16 ++++++++++++++-- src/gui/widgets/qabstractscrollarea.cpp | 2 +- tests/auto/uiloader/baseline/css_scroll.ui | 14 ++++++++------ 3 files changed, 23 insertions(+), 9 deletions(-) diff --git a/src/gui/styles/qstylesheetstyle.cpp b/src/gui/styles/qstylesheetstyle.cpp index c550938..285a789 100644 --- a/src/gui/styles/qstylesheetstyle.cpp +++ b/src/gui/styles/qstylesheetstyle.cpp @@ -4242,8 +4242,15 @@ void QStyleSheetStyle::drawPrimitive(PrimitiveElement pe, const QStyleOption *op if (const QAbstractScrollArea *sa = qobject_cast(w)) { const QAbstractScrollAreaPrivate *sap = sa->d_func(); rule.drawBackground(p, opt->rect, sap->contentsOffset()); - if (rule.hasBorder()) - rule.drawBorder(p, rule.borderRect(opt->rect)); + if (rule.hasBorder()) { + QRect brect = rule.borderRect(opt->rect); + if (styleHint(QStyle::SH_ScrollView_FrameOnlyAroundContents, opt, w)) { + QRect r = brect.adjusted(0, 0, sa->verticalScrollBar()->isVisible() ? -sa->verticalScrollBar()->width() : 0, + sa->horizontalScrollBar()->isVisible() ? -sa->horizontalScrollBar()->height() : 0); + brect = QStyle::visualRect(opt->direction, brect, r); + } + rule.drawBorder(p, brect); + } break; } #endif @@ -4628,6 +4635,11 @@ int QStyleSheetStyle::pixelMetric(PixelMetric m, const QStyleOption *opt, const return msz.width() == -1 ? msz.height() : msz.width(); } break; + + case PM_ScrollView_ScrollBarSpacing: + if(!rule.hasNativeBorder() || rule.hasBox()) + return 0; + break; #endif // QT_NO_SCROLLBAR case PM_ProgressBarChunkWidth: diff --git a/src/gui/widgets/qabstractscrollarea.cpp b/src/gui/widgets/qabstractscrollarea.cpp index 1d496d5..73ec53e 100644 --- a/src/gui/widgets/qabstractscrollarea.cpp +++ b/src/gui/widgets/qabstractscrollarea.cpp @@ -394,7 +394,7 @@ void QAbstractScrollAreaPrivate::layoutChildren() if ((frameStyle != QFrame::NoFrame) && q->style()->styleHint(QStyle::SH_ScrollView_FrameOnlyAroundContents, &opt, q)) { controlsRect = widgetRect; - const int extra = q->style()->pixelMetric(QStyle::PM_ScrollView_ScrollBarSpacing); + const int extra = q->style()->pixelMetric(QStyle::PM_ScrollView_ScrollBarSpacing, &opt, q); const QPoint cornerExtra(needv ? extra : 0, needh ? extra : 0); QRect frameRect = widgetRect; frameRect.adjust(0, 0, -cornerOffset.x() - cornerExtra.x(), -cornerOffset.y() - cornerExtra.y()); diff --git a/tests/auto/uiloader/baseline/css_scroll.ui b/tests/auto/uiloader/baseline/css_scroll.ui index 0537ab0..6ac6886 100644 --- a/tests/auto/uiloader/baseline/css_scroll.ui +++ b/tests/auto/uiloader/baseline/css_scroll.ui @@ -14,8 +14,10 @@ Form - QScrollArea { background:red; } -QScrollArea .QWidget { background:transparent; } + QScrollArea { background:red; + border: 5px dashed blue; } +QScrollArea .QWidget { background:transparent; + border: 5px dotted green;} QScrollArea::corner { background:yellow; } @@ -111,10 +113,10 @@ QScrollArea::corner { background:yellow; } - -60 - -145 - 554 - 575 + 0 + 0 + 520 + 532 -- cgit v0.12 From 1c5c69b01659acc33bb49ffe4b078848b6a2a9de Mon Sep 17 00:00:00 2001 From: Sami Merila Date: Wed, 14 Apr 2010 13:06:28 +0300 Subject: QS60Style: In a very short combobox, text is cut If QComboBox is very short, it is possible that the combobox text is cut. This is due to two reasons: 1) Style does not take into account text eliding (which should be preferred over clipping) 2) Clipping text rect is done with orginal text rect, before it is adjusted for borders, icons etc. Style is changed that it doesn't use clipping rect and uses text eliding. Task-number: QTBUG-9837 Reviewed-by: Alessandro Portale --- src/gui/styles/qs60style.cpp | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/src/gui/styles/qs60style.cpp b/src/gui/styles/qs60style.cpp index f154b2d..0ebfe39 100644 --- a/src/gui/styles/qs60style.cpp +++ b/src/gui/styles/qs60style.cpp @@ -1372,14 +1372,13 @@ void QS60Style::drawControl(ControlElement element, const QStyleOption *option, optionComboBox.palette.setColor(QPalette::Inactive, QPalette::WindowText, optionComboBox.palette.text().color() ); QRect editRect = subControlRect(CC_ComboBox, comboBox, SC_ComboBoxEditField, widget); - painter->save(); - painter->setClipRect(editRect); + const int frameW = proxy()->pixelMetric(PM_DefaultFrameWidth, option, widget); if (!comboBox->currentIcon.isNull()) { - QIcon::Mode mode = comboBox->state & State_Enabled ? QIcon::Normal : QIcon::Disabled; - QPixmap pixmap = comboBox->currentIcon.pixmap(comboBox->iconSize, mode); + const QIcon::Mode mode = comboBox->state & State_Enabled ? QIcon::Normal : QIcon::Disabled; + const QPixmap pixmap = comboBox->currentIcon.pixmap(comboBox->iconSize, mode); QRect iconRect(editRect); - iconRect.setWidth(comboBox->iconSize.width() + 4); + iconRect.setWidth(comboBox->iconSize.width() + frameW); iconRect = alignedRect(comboBox->direction, Qt::AlignLeft | Qt::AlignVCenter, iconRect.size(), editRect); @@ -1388,17 +1387,19 @@ void QS60Style::drawControl(ControlElement element, const QStyleOption *option, drawItemPixmap(painter, iconRect, Qt::AlignCenter, pixmap); if (comboBox->direction == Qt::RightToLeft) - editRect.translate(-4 - comboBox->iconSize.width(), 0); + editRect.setRight(editRect.right() - frameW - comboBox->iconSize.width()); else - editRect.translate(comboBox->iconSize.width() + 4, 0); + editRect.setLeft(comboBox->iconSize.width() + frameW); } if (!comboBox->currentText.isEmpty() && !comboBox->editable) { + const Qt::TextElideMode elideMode = (comboBox->direction == Qt::LeftToRight) ? Qt::ElideRight : Qt::ElideLeft; + const QString text = comboBox->fontMetrics.elidedText(comboBox->currentText, elideMode, editRect.width()); + QCommonStyle::drawItemText(painter, editRect.adjusted(QS60StylePrivate::pixelMetric(PM_FrameCornerWidth), 0, -1, 0), visualAlignment(comboBox->direction, Qt::AlignLeft | Qt::AlignVCenter), - comboBox->palette, comboBox->state & State_Enabled, comboBox->currentText); + comboBox->palette, comboBox->state & State_Enabled, text); } - painter->restore(); } break; #endif //QT_NO_COMBOBOX -- cgit v0.12 From 401aabde0d3da0e819a046f1eee47bb5f3a2d5d2 Mon Sep 17 00:00:00 2001 From: Sami Merila Date: Wed, 14 Apr 2010 13:11:10 +0300 Subject: QS60Style: HouseKeeping task Remove unnecessary comment. Added one @todo comment. Some whitespace corrections. Removed unnecessary QStyle scopes. Reviewed-by: Alessandro Portale --- src/gui/styles/qs60style.cpp | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/src/gui/styles/qs60style.cpp b/src/gui/styles/qs60style.cpp index 0ebfe39..27913cd 100644 --- a/src/gui/styles/qs60style.cpp +++ b/src/gui/styles/qs60style.cpp @@ -1542,7 +1542,6 @@ void QS60Style::drawControl(ControlElement element, const QStyleOption *option, QS60StylePrivate::pixelMetric(PM_DefaultFrameWidth); const int tabOverlap = QS60StylePrivate::pixelMetric(PM_TabBarTabOverlap) - borderThickness; - //todo: draw navi wipe behind tabbar - must be drawn with first draw if (skinElement==QS60StylePrivate::SE_TabBarTabEastInactive|| skinElement==QS60StylePrivate::SE_TabBarTabEastActive|| @@ -1646,7 +1645,7 @@ void QS60Style::drawControl(ControlElement element, const QStyleOption *option, painter->drawPixmap(tr.left() + tabOverlap, tr.center().y() - (tabIcon.height() >> 1), tabIcon); - tr.setLeft(tr.left() + iconSize.width() + 4); + tr.setLeft(tr.left() + iconSize.width() + 4); //todo: magic four } QCommonStyle::drawItemText(painter, tr, alignment, optionTab.palette, tab->state & State_Enabled, tab->text, QPalette::WindowText); @@ -1965,14 +1964,14 @@ void QS60Style::drawControl(ControlElement element, const QStyleOption *option, // We need to reduce the focus frame size if LayoutSpacing is smaller than FocusFrameMargin // Otherwise, we would overlay adjacent widgets. const int frameHeightReduction = - qMin(0, pixelMetric(QStyle::PM_LayoutVerticalSpacing) - - pixelMetric(QStyle::PM_FocusFrameVMargin)); + qMin(0, pixelMetric(PM_LayoutVerticalSpacing) + - pixelMetric(PM_FocusFrameVMargin)); const int frameWidthReduction = - qMin(0, pixelMetric(QStyle::PM_LayoutHorizontalSpacing) - - pixelMetric(QStyle::PM_FocusFrameHMargin)); + qMin(0, pixelMetric(PM_LayoutHorizontalSpacing) + - pixelMetric(PM_FocusFrameHMargin)); const int rounding = - qMin(pixelMetric(QStyle::PM_FocusFrameVMargin), - pixelMetric(QStyle::PM_LayoutVerticalSpacing)); + qMin(pixelMetric(PM_FocusFrameVMargin), + pixelMetric(PM_LayoutVerticalSpacing)); const QRect frameRect = option->rect.adjusted(-frameWidthReduction, -frameHeightReduction, frameWidthReduction, frameHeightReduction); @@ -2848,7 +2847,7 @@ QRect QS60Style::subElementRect(SubElement element, const QStyleOption *opt, con const int tabOverlapNoBorder = QS60StylePrivate::pixelMetric(PM_TabBarTabOverlap); const int tabOverlap = - tabOverlapNoBorder-QS60StylePrivate::pixelMetric(PM_DefaultFrameWidth); + tabOverlapNoBorder - QS60StylePrivate::pixelMetric(PM_DefaultFrameWidth); const QTabWidget *tab = qobject_cast(widget); int gain = (tab) ? tabOverlap * tab->count() : 0; switch (twf->shape) { @@ -2914,7 +2913,7 @@ QRect QS60Style::subElementRect(SubElement element, const QStyleOption *opt, con ret = QRect(); } else { if (menuItem->direction == Qt::RightToLeft) - ret.translate(ret.width()-indicatorWidth, 0); + ret.translate(ret.width() - indicatorWidth, 0); ret.setWidth(indicatorWidth); } } else { -- cgit v0.12 From aea71e2e02fa966842b094244bc3f5fc88f50f41 Mon Sep 17 00:00:00 2001 From: Thiago Macieira Date: Wed, 14 Apr 2010 12:56:33 +0200 Subject: Fix autotest failure: QIODevice::read() on a closed device must return -1 --- src/corelib/io/qiodevice.cpp | 1 + 1 file changed, 1 insertion(+) diff --git a/src/corelib/io/qiodevice.cpp b/src/corelib/io/qiodevice.cpp index f83c142..f2cef4e1 100644 --- a/src/corelib/io/qiodevice.cpp +++ b/src/corelib/io/qiodevice.cpp @@ -755,6 +755,7 @@ qint64 QIODevice::bytesToWrite() const qint64 QIODevice::read(char *data, qint64 maxSize) { Q_D(QIODevice); + CHECK_READABLE(read, qint64(-1)); #if defined QIODEVICE_DEBUG printf("%p QIODevice::read(%p, %d), d->pos = %d, d->buffer.size() = %d\n", -- cgit v0.12 From f3a0bd8827f5d0de575b0f8c044b4bf65405b69c Mon Sep 17 00:00:00 2001 From: Lars Knoll Date: Wed, 14 Apr 2010 17:15:49 +0200 Subject: merge commit c638ddc70f6a8196f2c8b11808ab01510233a0ee from harfbuzz: commit c638ddc70f6a8196f2c8b11808ab01510233a0ee Author: Lars Knoll Date: Wed Apr 14 17:01:49 2010 +0200 Fix a bug in malayalam shaping See http://bugreports.qt.nokia.com/browse/QTBUG-1887. We were not finding the base character correctly in the case where the syllable contained a ZWJ. In addition, the indic OT specs require us to also apply the 'loca', 'cjct' and 'calt' features. They seem to be mostly unused by todays fonts, but we should better apply them anyways. Task-number: QTBUG-1887 Reviewed-by: Eskil --- src/3rdparty/harfbuzz/src/harfbuzz-indic.cpp | 23 ++- .../harfbuzz/src/harfbuzz-shaper-private.h | 55 +++---- src/3rdparty/harfbuzz/tests/shaping/main.cpp | 165 ++++++++++++++++++--- .../qtextscriptengine/tst_qtextscriptengine.cpp | 2 + 4 files changed, 195 insertions(+), 50 deletions(-) diff --git a/src/3rdparty/harfbuzz/src/harfbuzz-indic.cpp b/src/3rdparty/harfbuzz/src/harfbuzz-indic.cpp index 3c9df93..4d8418b 100644 --- a/src/3rdparty/harfbuzz/src/harfbuzz-indic.cpp +++ b/src/3rdparty/harfbuzz/src/harfbuzz-indic.cpp @@ -1107,6 +1107,7 @@ static inline void splitMatra(unsigned short *reordered, int matra, int &len) #ifndef NO_OPENTYPE static const HB_OpenTypeFeature indic_features[] = { + { HB_MAKE_TAG('l', 'o', 'c', 'a'), LocaProperty }, { HB_MAKE_TAG('c', 'c', 'm', 'p'), CcmpProperty }, { HB_MAKE_TAG('i', 'n', 'i', 't'), InitProperty }, { HB_MAKE_TAG('n', 'u', 'k', 't'), NuktaProperty }, @@ -1115,12 +1116,14 @@ static const HB_OpenTypeFeature indic_features[] = { { HB_MAKE_TAG('b', 'l', 'w', 'f'), BelowFormProperty }, { HB_MAKE_TAG('h', 'a', 'l', 'f'), HalfFormProperty }, { HB_MAKE_TAG('p', 's', 't', 'f'), PostFormProperty }, + { HB_MAKE_TAG('c', 'j', 'c', 't'), ConjunctFormProperty }, { HB_MAKE_TAG('v', 'a', 't', 'u'), VattuProperty }, { HB_MAKE_TAG('p', 'r', 'e', 's'), PreSubstProperty }, { HB_MAKE_TAG('b', 'l', 'w', 's'), BelowSubstProperty }, { HB_MAKE_TAG('a', 'b', 'v', 's'), AboveSubstProperty }, { HB_MAKE_TAG('p', 's', 't', 's'), PostSubstProperty }, { HB_MAKE_TAG('h', 'a', 'l', 'n'), HalantProperty }, + { HB_MAKE_TAG('c', 'a', 'l', 't'), IndicCaltProperty }, { 0, 0 } }; #endif @@ -1148,6 +1151,8 @@ static QString propertiesToString(int properties) { QString res; properties = ~properties; + if (properties & LocaProperty) + res += "Loca "; if (properties & CcmpProperty) res += "Ccmp "; if (properties & InitProperty) @@ -1168,6 +1173,8 @@ static QString propertiesToString(int properties) res += "HalfForm "; if (properties & PostFormProperty) res += "PostForm "; + if (properties & ConjunctFormProperty) + res += "PostForm "; if (properties & VattuProperty) res += "Vattu "; if (properties & PreSubstProperty) @@ -1182,6 +1189,8 @@ static QString propertiesToString(int properties) res += "Halant "; if (properties & CligProperty) res += "Clig "; + if (properties & IndicCaltProperty) + res += "Calt "; return res; } #endif @@ -1296,10 +1305,15 @@ static bool indic_shape_syllable(HB_Bool openType, HB_ShaperItem *item, bool inv } int skipped = 0; Position pos = Post; - for (i = len-1; i > base; i--) { + for (i = len-1; i >= base; i--) { if (position[i] != Consonant && (position[i] != Control || script == HB_Script_Kannada)) continue; + if (i < len-1 && position[i] == Control && position[i+1] == Consonant) { + base = i+1; + break; + } + Position charPosition = indic_position(uc[i]); if (pos == Post && charPosition == Post) { pos = Post; @@ -1545,16 +1559,20 @@ static bool indic_shape_syllable(HB_Bool openType, HB_ShaperItem *item, bool inv // features we should always apply for (i = 0; i < len; ++i) - properties[i] = ~(CcmpProperty + properties[i] = ~(LocaProperty + | CcmpProperty | NuktaProperty | VattuProperty + | ConjunctFormProperty | PreSubstProperty | BelowSubstProperty | AboveSubstProperty | PostSubstProperty | HalantProperty + | IndicCaltProperty | PositioningProperties); + // Loca always applies // Ccmp always applies // Init if (item->item.pos == 0 @@ -1611,6 +1629,7 @@ static bool indic_shape_syllable(HB_Bool openType, HB_ShaperItem *item, bool inv // abvs always applies // psts always applies // halant always applies + // calt always applies #ifdef INDIC_DEBUG // { diff --git a/src/3rdparty/harfbuzz/src/harfbuzz-shaper-private.h b/src/3rdparty/harfbuzz/src/harfbuzz-shaper-private.h index 80bccf8..2fce7df 100644 --- a/src/3rdparty/harfbuzz/src/harfbuzz-shaper-private.h +++ b/src/3rdparty/harfbuzz/src/harfbuzz-shaper-private.h @@ -57,34 +57,37 @@ typedef enum } HB_CombiningClass; typedef enum { - CcmpProperty = 0x1, - InitProperty = 0x2, - IsolProperty = 0x4, - FinaProperty = 0x8, - MediProperty = 0x10, - RligProperty = 0x20, - CaltProperty = 0x40, - LigaProperty = 0x80, - DligProperty = 0x100, - CswhProperty = 0x200, - MsetProperty = 0x400, + LocaProperty = 0x1, + CcmpProperty = 0x2, + InitProperty = 0x4, + IsolProperty = 0x8, + FinaProperty = 0x10, + MediProperty = 0x20, + RligProperty = 0x40, + CaltProperty = 0x80, + LigaProperty = 0x100, + DligProperty = 0x200, + CswhProperty = 0x400, + MsetProperty = 0x800, /* used by indic and myanmar shaper */ - NuktaProperty = 0x4, - AkhantProperty = 0x8, - RephProperty = 0x10, - PreFormProperty = 0x20, - BelowFormProperty = 0x40, - AboveFormProperty = 0x80, - HalfFormProperty = 0x100, - PostFormProperty = 0x200, - VattuProperty = 0x400, - PreSubstProperty = 0x800, - BelowSubstProperty = 0x1000, - AboveSubstProperty = 0x2000, - PostSubstProperty = 0x4000, - HalantProperty = 0x8000, - CligProperty = 0x10000 + NuktaProperty = 0x8, + AkhantProperty = 0x10, + RephProperty = 0x20, + PreFormProperty = 0x40, + BelowFormProperty = 0x80, + AboveFormProperty = 0x100, + HalfFormProperty = 0x200, + PostFormProperty = 0x400, + ConjunctFormProperty = 0x800, + VattuProperty = 0x1000, + PreSubstProperty = 0x2000, + BelowSubstProperty = 0x4000, + AboveSubstProperty = 0x8000, + PostSubstProperty = 0x10000, + HalantProperty = 0x20000, + CligProperty = 0x40000, + IndicCaltProperty = 0x80000 } HB_OpenTypeProperty; diff --git a/src/3rdparty/harfbuzz/tests/shaping/main.cpp b/src/3rdparty/harfbuzz/tests/shaping/main.cpp index 827ac30..28f8e07 100644 --- a/src/3rdparty/harfbuzz/tests/shaping/main.cpp +++ b/src/3rdparty/harfbuzz/tests/shaping/main.cpp @@ -136,13 +136,13 @@ HB_Error hb_getPointInOutline(HB_Font font, HB_Glyph glyph, int flags, hb_uint32 return HB_Err_Ok; } -void hb_getGlyphMetrics(HB_Font font, HB_Glyph glyph, HB_GlyphMetrics *metrics) +void hb_getGlyphMetrics(HB_Font, HB_Glyph, HB_GlyphMetrics *metrics) { // ### metrics->x = metrics->y = metrics->width = metrics->height = metrics->xOffset = metrics->yOffset = 0; } -HB_Fixed hb_getFontMetric(HB_Font font, HB_FontMetric metric) +HB_Fixed hb_getFontMetric(HB_Font, HB_FontMetric ) { return 0; // #### } @@ -169,6 +169,8 @@ public slots: void initTestCase(); void cleanupTestCase(); private slots: + void greek(); + void devanagari(); void bengali(); void gurmukhi(); @@ -203,18 +205,25 @@ void tst_QScriptEngine::cleanupTestCase() FT_Done_FreeType(freetype); } -struct ShapeTable { - unsigned short unicode[16]; - unsigned short glyphs[16]; +class Shaper +{ +public: + Shaper(FT_Face face, HB_Script script, const QString &str); + + HB_FontRec hbFont; + HB_ShaperItem shaper_item; + QVarLengthArray hb_glyphs; + QVarLengthArray hb_attributes; + QVarLengthArray hb_advances; + QVarLengthArray hb_offsets; + QVarLengthArray hb_logClusters; + }; -static bool shaping(FT_Face face, const ShapeTable *s, HB_Script script) +Shaper::Shaper(FT_Face face, HB_Script script, const QString &str) { - QString str = QString::fromUtf16( s->unicode ); - HB_Face hbFace = HB_NewFace(face, hb_getSFntTable); - HB_FontRec hbFont; hbFont.klass = &hb_fontClass; hbFont.userData = face; hbFont.x_ppem = face->size->metrics.x_ppem; @@ -222,7 +231,6 @@ static bool shaping(FT_Face face, const ShapeTable *s, HB_Script script) hbFont.x_scale = face->size->metrics.x_scale; hbFont.y_scale = face->size->metrics.y_scale; - HB_ShaperItem shaper_item; shaper_item.kerning_applied = false; shaper_item.string = reinterpret_cast(str.constData()); shaper_item.stringLength = str.length(); @@ -237,11 +245,6 @@ static bool shaping(FT_Face face, const ShapeTable *s, HB_Script script) shaper_item.glyphIndicesPresent = false; shaper_item.initialGlyphCount = 0; - QVarLengthArray hb_glyphs(shaper_item.num_glyphs); - QVarLengthArray hb_attributes(shaper_item.num_glyphs); - QVarLengthArray hb_advances(shaper_item.num_glyphs); - QVarLengthArray hb_offsets(shaper_item.num_glyphs); - QVarLengthArray hb_logClusters(shaper_item.num_glyphs); while (1) { hb_glyphs.resize(shaper_item.num_glyphs); @@ -263,10 +266,66 @@ static bool shaping(FT_Face face, const ShapeTable *s, HB_Script script) if (HB_ShapeItem(&shaper_item)) break; - } HB_FreeFace(hbFace); +} + + +static bool decomposedShaping(FT_Face face, HB_Script script, const QChar &ch) +{ + QString uc = QString().append(ch); + Shaper shaper(face, script, uc); + + uc = uc.normalized(QString::NormalizationForm_D); + Shaper decomposed(face, script, uc); + + if( shaper.shaper_item.num_glyphs != decomposed.shaper_item.num_glyphs ) + goto error; + + for (unsigned int i = 0; i < shaper.shaper_item.num_glyphs; ++i) { + if ((shaper.shaper_item.glyphs[i]&0xffffff) != (decomposed.shaper_item.glyphs[i]&0xffffff)) + goto error; + } + return true; + error: + QString str = ""; + int i = 0; + while (i < uc.length()) { + str += QString("%1 ").arg(uc[i].unicode(), 4, 16); + ++i; + } + qDebug("%s: decomposedShaping of char %4x failed\n decomposedString: %s\n nglyphs=%d, decomposed nglyphs %d", + face->family_name, + ch.unicode(), str.toLatin1().data(), + shaper.shaper_item.num_glyphs, + decomposed.shaper_item.num_glyphs); + + str = ""; + i = 0; + while (i < shaper.shaper_item.num_glyphs) { + str += QString("%1 ").arg(shaper.shaper_item.glyphs[i], 4, 16); + ++i; + } + qDebug(" composed glyph result = %s", str.toLatin1().constData()); + str = ""; + i = 0; + while (i < decomposed.shaper_item.num_glyphs) { + str += QString("%1 ").arg(decomposed.shaper_item.glyphs[i], 4, 16); + ++i; + } + qDebug(" decomposed glyph result = %s", str.toLatin1().constData()); + return false; +} + +struct ShapeTable { + unsigned short unicode[16]; + unsigned short glyphs[16]; +}; + +static bool shaping(FT_Face face, const ShapeTable *s, HB_Script script) +{ + Shaper shaper(face, script, QString::fromUtf16( s->unicode )); hb_uint32 nglyphs = 0; const unsigned short *g = s->glyphs; @@ -275,16 +334,16 @@ static bool shaping(FT_Face face, const ShapeTable *s, HB_Script script) g++; } - if( nglyphs != shaper_item.num_glyphs ) + if( nglyphs != shaper.shaper_item.num_glyphs ) goto error; for (hb_uint32 i = 0; i < nglyphs; ++i) { - if ((shaper_item.glyphs[i]&0xffffff) != s->glyphs[i]) + if ((shaper.shaper_item.glyphs[i]&0xffffff) != s->glyphs[i]) goto error; } return true; error: - str = ""; + QString str = ""; const unsigned short *uc = s->unicode; while (*uc) { str += QString("%1 ").arg(*uc, 4, 16); @@ -293,18 +352,78 @@ static bool shaping(FT_Face face, const ShapeTable *s, HB_Script script) qDebug("%s: shaping of string %s failed, nglyphs=%d, expected %d", face->family_name, str.toLatin1().constData(), - shaper_item.num_glyphs, nglyphs); + shaper.shaper_item.num_glyphs, nglyphs); str = ""; hb_uint32 i = 0; - while (i < shaper_item.num_glyphs) { - str += QString("%1 ").arg(shaper_item.glyphs[i], 4, 16); + while (i < shaper.shaper_item.num_glyphs) { + str += QString("%1 ").arg(shaper.shaper_item.glyphs[i], 4, 16); ++i; } qDebug(" glyph result = %s", str.toLatin1().constData()); return false; } + +void tst_QScriptEngine::greek() +{ + FT_Face face = loadFace("DejaVuSans.ttf"); + if (face) { + for (int uc = 0x1f00; uc <= 0x1fff; ++uc) { + QString str; + str.append(uc); + if (str.normalized(QString::NormalizationForm_D).normalized(QString::NormalizationForm_C) != str) { + //qDebug() << "skipping" << hex << uc; + continue; + } + if (uc == 0x1fc1 || uc == 0x1fed) + continue; + QVERIFY( decomposedShaping(face, HB_Script_Greek, QChar(uc)) ); + } + FT_Done_Face(face); + } else { + QSKIP("couln't find DejaVu Sans", SkipAll); + } + + + face = loadFace("SBL_grk.ttf"); + if (face) { + for (int uc = 0x1f00; uc <= 0x1fff; ++uc) { + QString str; + str.append(uc); + if (str.normalized(QString::NormalizationForm_D).normalized(QString::NormalizationForm_C) != str) { + //qDebug() << "skipping" << hex << uc; + continue; + } + if (uc == 0x1fc1 || uc == 0x1fed) + continue; + QVERIFY( decomposedShaping(face, HB_Script_Greek, QChar(uc)) ); + + } + + const ShapeTable shape_table [] = { + { { 0x3b1, 0x300, 0x313, 0x0 }, + { 0xb8, 0x3d3, 0x3c7, 0x0 } }, + { { 0x3b1, 0x313, 0x300, 0x0 }, + { 0xd4, 0x0 } }, + + { {0}, {0} } + }; + + + const ShapeTable *s = shape_table; + while (s->unicode[0]) { + QVERIFY( shaping(face, s, HB_Script_Greek) ); + ++s; + } + + FT_Done_Face(face); + } else { + QSKIP("couln't find DejaVu Sans", SkipAll); + } +} + + void tst_QScriptEngine::devanagari() { { @@ -1011,6 +1130,8 @@ void tst_QScriptEngine::malayalam() { 0x3f8, 0x0 } }, { { 0xd2f, 0xd4d, 0xd15, 0xd4d, 0xd15, 0xd41, 0x0 }, { 0x2ff, 0x0 } }, + { { 0xd30, 0xd4d, 0x200d, 0xd35, 0xd4d, 0xd35, 0x0 }, + { 0xf3, 0x350, 0x0 } }, { {0}, {0} } }; diff --git a/tests/auto/qtextscriptengine/tst_qtextscriptengine.cpp b/tests/auto/qtextscriptengine/tst_qtextscriptengine.cpp index 6de3f59..940e78d 100644 --- a/tests/auto/qtextscriptengine/tst_qtextscriptengine.cpp +++ b/tests/auto/qtextscriptengine/tst_qtextscriptengine.cpp @@ -870,6 +870,8 @@ void tst_QTextScriptEngine::malayalam() { 0x3f8, 0x0 } }, { { 0xd2f, 0xd4d, 0xd15, 0xd4d, 0xd15, 0xd41, 0x0 }, { 0x2ff, 0x0 } }, + { { 0xd30, 0xd4d, 0x200d, 0xd35, 0xd4d, 0xd35, 0x0 }, + { 0xf3, 0x350, 0x0 } }, { {0}, {0} } }; -- cgit v0.12 From a3d6d4db2c12123873b809a9605b3ab50c740294 Mon Sep 17 00:00:00 2001 From: Kent Hansen Date: Wed, 14 Apr 2010 18:22:35 +0200 Subject: QtScript: Fix call stack issue with qsTr() when JIT is enabled When the JIT is enabled, as well as JIT_OPTIMIZE_NATIVE_CALL defined, NativeFunctionWrapper is a typedef for JSFunction. This has the consequence that the native call frame will not be fully initialized by JIT-generated code (because it shouldn't have to); in particular, ExecState::codeBlock() is not set up. qsTr() relies on codeBlock() to return a sensible value, though, so it breaks this contract. By making qsTr a PrototypeFunction, the JIT will detect that the function call needs more elaborate setup, i.e. initialize codeBlock() as well. Reviewed-by: Olivier Goffart --- src/script/api/qscriptengine.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/script/api/qscriptengine.cpp b/src/script/api/qscriptengine.cpp index 9bd98f1..9ce0f7d 100644 --- a/src/script/api/qscriptengine.cpp +++ b/src/script/api/qscriptengine.cpp @@ -2939,7 +2939,7 @@ void QScriptEngine::installTranslatorFunctions(const QScriptValue &object) // unsigned attribs = JSC::DontEnum; JSC::asObject(jscObject)->putDirectFunction(exec, new (exec)JSC::NativeFunctionWrapper(exec, glob->prototypeFunctionStructure(), 5, JSC::Identifier(exec, "qsTranslate"), QScript::functionQsTranslate)); JSC::asObject(jscObject)->putDirectFunction(exec, new (exec)JSC::NativeFunctionWrapper(exec, glob->prototypeFunctionStructure(), 2, JSC::Identifier(exec, "QT_TRANSLATE_NOOP"), QScript::functionQsTranslateNoOp)); - JSC::asObject(jscObject)->putDirectFunction(exec, new (exec)JSC::NativeFunctionWrapper(exec, glob->prototypeFunctionStructure(), 3, JSC::Identifier(exec, "qsTr"), QScript::functionQsTr)); + JSC::asObject(jscObject)->putDirectFunction(exec, new (exec)JSC::PrototypeFunction(exec, glob->prototypeFunctionStructure(), 3, JSC::Identifier(exec, "qsTr"), QScript::functionQsTr)); JSC::asObject(jscObject)->putDirectFunction(exec, new (exec)JSC::NativeFunctionWrapper(exec, glob->prototypeFunctionStructure(), 1, JSC::Identifier(exec, "QT_TR_NOOP"), QScript::functionQsTrNoOp)); glob->stringPrototype()->putDirectFunction(exec, new (exec)JSC::NativeFunctionWrapper(exec, glob->prototypeFunctionStructure(), 1, JSC::Identifier(exec, "arg"), QScript::stringProtoFuncArg)); -- cgit v0.12 From b84be32658f053a89e589ff66913213fb0d0b8e7 Mon Sep 17 00:00:00 2001 From: Kent Hansen Date: Wed, 14 Apr 2010 12:15:43 +0200 Subject: QtScript: Add test for translation disambiguation --- tests/auto/qscriptengine/translatable.js | 2 ++ .../auto/qscriptengine/translations/translatable_la.qm | Bin 241 -> 315 bytes .../auto/qscriptengine/translations/translatable_la.ts | 6 ++++++ tests/auto/qscriptengine/tst_qscriptengine.cpp | 2 ++ 4 files changed, 10 insertions(+) diff --git a/tests/auto/qscriptengine/translatable.js b/tests/auto/qscriptengine/translatable.js index 0c948e7..30e139a 100644 --- a/tests/auto/qscriptengine/translatable.js +++ b/tests/auto/qscriptengine/translatable.js @@ -5,3 +5,5 @@ var greeting_strings = [ QT_TR_NOOP("Hello"), QT_TRANSLATE_NOOP("FooContext", "Goodbye") ]; + +qsTr("One", "not the same one"); diff --git a/tests/auto/qscriptengine/translations/translatable_la.qm b/tests/auto/qscriptengine/translations/translatable_la.qm index 03fcc52..301cc77 100644 Binary files a/tests/auto/qscriptengine/translations/translatable_la.qm and b/tests/auto/qscriptengine/translations/translatable_la.qm differ diff --git a/tests/auto/qscriptengine/translations/translatable_la.ts b/tests/auto/qscriptengine/translations/translatable_la.ts index 3f631de..4eed72d 100644 --- a/tests/auto/qscriptengine/translations/translatable_la.ts +++ b/tests/auto/qscriptengine/translations/translatable_la.ts @@ -27,6 +27,12 @@ Hallo + + One + not the same one + Enda en + + Goodbye Farvel diff --git a/tests/auto/qscriptengine/tst_qscriptengine.cpp b/tests/auto/qscriptengine/tst_qscriptengine.cpp index 674e502..aa06bc9 100644 --- a/tests/auto/qscriptengine/tst_qscriptengine.cpp +++ b/tests/auto/qscriptengine/tst_qscriptengine.cpp @@ -4345,6 +4345,8 @@ void tst_QScriptEngine::translateScript() QCOMPARE(engine.evaluate("qsTranslate('FooContext', 'Goodbye', '', 'UnicodeUTF8')", fileName).toString(), QString::fromLatin1("Farvel")); + QCOMPARE(engine.evaluate("qsTr('One', 'not the same one')", fileName).toString(), QString::fromLatin1("Enda en")); + QVERIFY(engine.evaluate("QT_TR_NOOP()").isUndefined()); QCOMPARE(engine.evaluate("QT_TR_NOOP('One')").toString(), QString::fromLatin1("One")); -- cgit v0.12 From 9415afbd2ca6a4b136ecdc4cb4936e15cc523229 Mon Sep 17 00:00:00 2001 From: Kent Hansen Date: Wed, 14 Apr 2010 18:49:35 +0200 Subject: QtScript: Add tests for translation of multiple scripts Suggested by Olivier. --- tests/auto/qscriptengine/translatable2.js | 9 +++++ .../qscriptengine/translations/translatable_la.qm | Bin 315 -> 678 bytes .../qscriptengine/translations/translatable_la.ts | 32 +++++++++++++++++ tests/auto/qscriptengine/tst_qscriptengine.cpp | 40 +++++++++++++++++++++ 4 files changed, 81 insertions(+) create mode 100644 tests/auto/qscriptengine/translatable2.js diff --git a/tests/auto/qscriptengine/translatable2.js b/tests/auto/qscriptengine/translatable2.js new file mode 100644 index 0000000..eee66f1 --- /dev/null +++ b/tests/auto/qscriptengine/translatable2.js @@ -0,0 +1,9 @@ +qsTr("Three"); +qsTranslate("BarContext", "Four"); + +var celebration_strings = [ + QT_TR_NOOP("Happy birthday!"), + QT_TRANSLATE_NOOP("BarContext", "Congratulations!") +]; + +qsTr("Three", "not the same three"); diff --git a/tests/auto/qscriptengine/translations/translatable_la.qm b/tests/auto/qscriptengine/translations/translatable_la.qm index 301cc77..703d0f1 100644 Binary files a/tests/auto/qscriptengine/translations/translatable_la.qm and b/tests/auto/qscriptengine/translations/translatable_la.qm differ diff --git a/tests/auto/qscriptengine/translations/translatable_la.ts b/tests/auto/qscriptengine/translations/translatable_la.ts index 4eed72d..1598f39 100644 --- a/tests/auto/qscriptengine/translations/translatable_la.ts +++ b/tests/auto/qscriptengine/translations/translatable_la.ts @@ -2,6 +2,19 @@ + BarContext + + + Four + Fire + + + + Congratulations! + Gratulerer! + + + FooContext @@ -37,4 +50,23 @@ Farvel + + translatable2 + + + Three + Tre + + + + Happy birthday! + Gratulerer med dagen! + + + + Three + not the same three + Tre andre + + diff --git a/tests/auto/qscriptengine/tst_qscriptengine.cpp b/tests/auto/qscriptengine/tst_qscriptengine.cpp index aa06bc9..5713f8e 100644 --- a/tests/auto/qscriptengine/tst_qscriptengine.cpp +++ b/tests/auto/qscriptengine/tst_qscriptengine.cpp @@ -4317,6 +4317,11 @@ void tst_QScriptEngine::installTranslatorFunctions() } } +static QScriptValue callQsTr(QScriptContext *ctx, QScriptEngine *eng) +{ + return eng->globalObject().property("qsTr").call(ctx->thisObject(), ctx->argumentsObject()); +} + void tst_QScriptEngine::translateScript() { QScriptEngine engine; @@ -4364,6 +4369,41 @@ void tst_QScriptEngine::translateScript() QCOMPARE(engine.globalObject().property("qsTr").call( QScriptValue(), QScriptValueList() << "One").toString(), QString::fromLatin1("One")); + // Translate strings from the second script (translatable2.js) + + QString fileName2 = QString::fromLatin1("translatable2.js"); + + QCOMPARE(engine.evaluate("qsTr('Three')", fileName2).toString(), QString::fromLatin1("Tre")); + QCOMPARE(engine.evaluate("qsTr('Happy birthday!')", fileName2).toString(), QString::fromLatin1("Gratulerer med dagen!")); + + // Not translated because translation is only in translatable.js + QCOMPARE(engine.evaluate("qsTr('One')", fileName2).toString(), QString::fromLatin1("One")); + QCOMPARE(engine.evaluate("(function() { return qsTr('One'); })()", fileName2).toString(), QString::fromLatin1("One")); + + // For qsTranslate() the filename shouldn't matter + QCOMPARE(engine.evaluate("qsTranslate('FooContext', 'Two')", fileName2).toString(), QString::fromLatin1("To")); + QCOMPARE(engine.evaluate("qsTranslate('BarContext', 'Congratulations!')", fileName).toString(), QString::fromLatin1("Gratulerer!")); + + // qsTr() should use the innermost filename as context + engine.evaluate("function foo(s) { return bar(s); }", fileName); + engine.evaluate("function bar(s) { return qsTr(s); }", fileName2); + QCOMPARE(engine.evaluate("bar('Three')", fileName2).toString(), QString::fromLatin1("Tre")); + QCOMPARE(engine.evaluate("bar('Three')", fileName).toString(), QString::fromLatin1("Tre")); + QCOMPARE(engine.evaluate("bar('One')", fileName2).toString(), QString::fromLatin1("One")); + + engine.evaluate("function foo(s) { return bar(s); }", fileName2); + engine.evaluate("function bar(s) { return qsTr(s); }", fileName); + QCOMPARE(engine.evaluate("bar('Three')", fileName2).toString(), QString::fromLatin1("Three")); + QCOMPARE(engine.evaluate("bar('One')", fileName).toString(), QString::fromLatin1("En")); + QCOMPARE(engine.evaluate("bar('One')", fileName2).toString(), QString::fromLatin1("En")); + + // Calling qsTr() from a native function + engine.globalObject().setProperty("qsTrProxy", engine.newFunction(callQsTr)); + QCOMPARE(engine.evaluate("qsTrProxy('One')", fileName).toString(), QString::fromLatin1("En")); + QCOMPARE(engine.evaluate("qsTrProxy('One')", fileName2).toString(), QString::fromLatin1("One")); + QCOMPARE(engine.evaluate("qsTrProxy('Three')", fileName).toString(), QString::fromLatin1("Three")); + QCOMPARE(engine.evaluate("qsTrProxy('Three')", fileName2).toString(), QString::fromLatin1("Tre")); + QCoreApplication::instance()->removeTranslator(&translator); } -- cgit v0.12 From 840bcb0b56b5b96a81fe3d1d5d91e1477e0fa387 Mon Sep 17 00:00:00 2001 From: Simon Hausmann Date: Wed, 14 Apr 2010 21:25:38 +0200 Subject: Updated WebKit from /home/shausman/src/webkit/trunk to qtwebkit/qtwebkit-4.6 ( be2489a618c909c4a82d927f9fff9d12feafeb30 ) Changes in WebKit/qt since the last update: * http://trac.webkit.org/changeset/50486 -- Allow a frame to go back to copy-on-scroll when it ceases being overlapped --- src/3rdparty/webkit/VERSION | 2 +- src/3rdparty/webkit/WebCore/ChangeLog | 17 +++++++++++++++++ src/3rdparty/webkit/WebCore/page/FrameView.cpp | 5 +++++ src/3rdparty/webkit/WebCore/page/FrameView.h | 1 + src/3rdparty/webkit/WebCore/rendering/RenderWidget.cpp | 2 +- 5 files changed, 25 insertions(+), 2 deletions(-) diff --git a/src/3rdparty/webkit/VERSION b/src/3rdparty/webkit/VERSION index 7c9ea04..8c93308 100644 --- a/src/3rdparty/webkit/VERSION +++ b/src/3rdparty/webkit/VERSION @@ -8,4 +8,4 @@ The commit imported was from the and has the sha1 checksum - 14feb62c96ffe2c37e3e2fdac4e370fdbc76ef62 + be2489a618c909c4a82d927f9fff9d12feafeb30 diff --git a/src/3rdparty/webkit/WebCore/ChangeLog b/src/3rdparty/webkit/WebCore/ChangeLog index b7e46c7..fa7e4f0 100644 --- a/src/3rdparty/webkit/WebCore/ChangeLog +++ b/src/3rdparty/webkit/WebCore/ChangeLog @@ -1,3 +1,20 @@ +2009-11-03 Dan Bernstein + + Reviewed by Dave Hyatt. + + Allow a frame to go back to copy-on-scroll when it ceases being overlapped + + The code was not testing slow-scrolling frames for overlappedness, thinking the answer + would not matter. That is not the case if the only reason for the slow-scrolling is + being overlapped. + + * page/FrameView.cpp: + (WebCore::FrameView::useSlowRepaintsIfNotOverlapped): Added. Returns whether there is any + reason besides being overlapped that the frame would need to fully repaint on scroll. + * page/FrameView.h: + * rendering/RenderWidget.cpp: + (WebCore::RenderWidget::paint): Use useSlowRepaintsIfNotOverlapped(). + 2010-04-09 David Leong Reviewed by Simon Hausmann. diff --git a/src/3rdparty/webkit/WebCore/page/FrameView.cpp b/src/3rdparty/webkit/WebCore/page/FrameView.cpp index 4c3a0ab..cc7d171 100644 --- a/src/3rdparty/webkit/WebCore/page/FrameView.cpp +++ b/src/3rdparty/webkit/WebCore/page/FrameView.cpp @@ -739,6 +739,11 @@ bool FrameView::useSlowRepaints() const return m_useSlowRepaints || m_slowRepaintObjectCount > 0 || (platformWidget() && m_fixedObjectCount > 0) || m_isOverlapped || !m_contentIsOpaque; } +bool FrameView::useSlowRepaintsIfNotOverlapped() const +{ + return m_useSlowRepaints || m_slowRepaintObjectCount > 0 || !m_contentIsOpaque; +} + void FrameView::setUseSlowRepaints() { m_useSlowRepaints = true; diff --git a/src/3rdparty/webkit/WebCore/page/FrameView.h b/src/3rdparty/webkit/WebCore/page/FrameView.h index 5243c02..ed1e6c6 100644 --- a/src/3rdparty/webkit/WebCore/page/FrameView.h +++ b/src/3rdparty/webkit/WebCore/page/FrameView.h @@ -212,6 +212,7 @@ private: friend class RenderWidget; bool useSlowRepaints() const; + bool useSlowRepaintsIfNotOverlapped() const; void applyOverflowToViewport(RenderObject*, ScrollbarMode& hMode, ScrollbarMode& vMode); diff --git a/src/3rdparty/webkit/WebCore/rendering/RenderWidget.cpp b/src/3rdparty/webkit/WebCore/rendering/RenderWidget.cpp index 9af7137..ec23603 100644 --- a/src/3rdparty/webkit/WebCore/rendering/RenderWidget.cpp +++ b/src/3rdparty/webkit/WebCore/rendering/RenderWidget.cpp @@ -233,7 +233,7 @@ void RenderWidget::paint(PaintInfo& paintInfo, int tx, int ty) else m_widget->paint(paintInfo.context, paintInfo.rect); - if (m_widget->isFrameView() && paintInfo.overlapTestRequests && !static_cast(m_widget.get())->useSlowRepaints()) { + if (m_widget->isFrameView() && paintInfo.overlapTestRequests && !static_cast(m_widget.get())->useSlowRepaintsIfNotOverlapped()) { ASSERT(!paintInfo.overlapTestRequests->contains(this)); paintInfo.overlapTestRequests->set(this, m_widget->frameRect()); } -- cgit v0.12 From 53c139f4e42c182a07ebc589393b88e10077cacf Mon Sep 17 00:00:00 2001 From: Gareth Stockwell Date: Wed, 14 Apr 2010 20:42:37 +0100 Subject: Phonon MMF: fixed typo in trace statement This builds under RVCT 2.2 (although obviously the debug output will contain garbage), but causes a compiler error with RVCT 4. Reviewed-by: trustme --- src/3rdparty/phonon/mmf/videowidget.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/3rdparty/phonon/mmf/videowidget.cpp b/src/3rdparty/phonon/mmf/videowidget.cpp index 4ed9979..122094e 100644 --- a/src/3rdparty/phonon/mmf/videowidget.cpp +++ b/src/3rdparty/phonon/mmf/videowidget.cpp @@ -123,7 +123,7 @@ Phonon::VideoWidget::ScaleMode MMF::VideoWidget::scaleMode() const void MMF::VideoWidget::setScaleMode(Phonon::VideoWidget::ScaleMode scaleMode) { TRACE_CONTEXT(VideoWidget::setScaleMode, EVideoApi); - TRACE("setScaleMode %d", setScaleMode); + TRACE("setScaleMode %d", scaleMode); m_videoOutput->setScaleMode(scaleMode); } -- cgit v0.12 From a484dd7cf655818aa849cf9dd002f76e137b3319 Mon Sep 17 00:00:00 2001 From: Gareth Stockwell Date: Tue, 13 Apr 2010 16:22:33 +0100 Subject: tst_mediaobject: Removed compiler warnings Removed declaration of variables which are subsequently unused. Reviewed-by: Frans Englich --- tests/auto/mediaobject/tst_mediaobject.cpp | 6 ------ 1 file changed, 6 deletions(-) diff --git a/tests/auto/mediaobject/tst_mediaobject.cpp b/tests/auto/mediaobject/tst_mediaobject.cpp index 5b0943e..e62bfd7 100644 --- a/tests/auto/mediaobject/tst_mediaobject.cpp +++ b/tests/auto/mediaobject/tst_mediaobject.cpp @@ -194,12 +194,6 @@ static qint32 castQVariantToInt32(const QVariant &variant) } static const char *const red = "\033[0;31m"; -static const char *const green = "\033[0;32m"; -static const char *const yellow = "\033[0;33m"; -static const char *const blue = "\033[0;34m"; -static const char *const purple = "\033[0;35m"; -static const char *const cyan = "\033[0;36m"; -static const char *const white = "\033[0;37m"; static const char *const normal = "\033[0m"; void tst_MediaObject::stateChanged(Phonon::State newstate, Phonon::State oldstate) -- cgit v0.12 From 57dddfe5036e256a9d2648c85fadb5abef31fb19 Mon Sep 17 00:00:00 2001 From: Gareth Stockwell Date: Tue, 13 Apr 2010 16:25:14 +0100 Subject: tst_mediaobject: Removed compiler warnings Compiler warnings concerned unreachable code. Reviewed-by: Frans Englich --- tests/auto/mediaobject/qtesthelper.h | 1 - tests/auto/mediaobject/tst_mediaobject.cpp | 5 ++--- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/tests/auto/mediaobject/qtesthelper.h b/tests/auto/mediaobject/qtesthelper.h index f082296..39d5b91 100644 --- a/tests/auto/mediaobject/qtesthelper.h +++ b/tests/auto/mediaobject/qtesthelper.h @@ -215,7 +215,6 @@ namespace QTest default: return 0; } - return 0; } } // namespace QTest QT_END_NAMESPACE diff --git a/tests/auto/mediaobject/tst_mediaobject.cpp b/tests/auto/mediaobject/tst_mediaobject.cpp index e62bfd7..efb9132 100644 --- a/tests/auto/mediaobject/tst_mediaobject.cpp +++ b/tests/auto/mediaobject/tst_mediaobject.cpp @@ -209,9 +209,7 @@ void tst_MediaObject::testPlayFromResource() { #ifdef Q_OS_SYMBIAN QSKIP("Not implemented yet.", SkipAll); - return; -#endif - +#else QFile file(MEDIA_FILEPATH); MediaObject media; media.setCurrentSource(&file); @@ -223,6 +221,7 @@ void tst_MediaObject::testPlayFromResource() if (media.state() != Phonon::PlayingState) QTest::waitForSignal(&media, SIGNAL(stateChanged(Phonon::State, Phonon::State)), 10000); QCOMPARE(media.state(), Phonon::PlayingState); +#endif } void tst_MediaObject::testPlayIllegalFile() -- cgit v0.12 From 0d12963c85fc116cd7283cd16ca0524f086f9d09 Mon Sep 17 00:00:00 2001 From: Gareth Stockwell Date: Tue, 13 Apr 2010 17:51:31 +0100 Subject: tst_mediaobject: Ensure playSDP step cleanup is run This step previously did not guarantee that the m_media object would be left in StoppedState, which in turn meant that following test steps could fail. Task-number: QTBUG-9339 Reviewed-by: Frans Englich --- tests/auto/mediaobject/tst_mediaobject.cpp | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/tests/auto/mediaobject/tst_mediaobject.cpp b/tests/auto/mediaobject/tst_mediaobject.cpp index efb9132..7f9f57d 100644 --- a/tests/auto/mediaobject/tst_mediaobject.cpp +++ b/tests/auto/mediaobject/tst_mediaobject.cpp @@ -572,13 +572,18 @@ void tst_MediaObject::playSDP() if (m_media->state() != Phonon::StoppedState) QTest::waitForSignal(m_media, SIGNAL(stateChanged(Phonon::State, Phonon::State)), 10000); - // At this point we're in error state due to absent media, but it has now loaded the SDP: - QCOMPARE(m_media->errorString(), QString::fromLatin1("Buffering clip failed: Unknown error (-39)")); + // MediaObject should have loaded the SDP, but be in error state due to absent media + const bool stateMatch = (m_media->state() == Phonon::ErrorState); + const bool errorStringMatch = (m_media->errorString() == QString::fromLatin1("Buffering clip failed: Unknown error (-39)")); - // We cannot play the SDP, we can neither attempt to play it, because we - // won't get a state change from ErrorState to ErrorState, and hence block - // on a never occuring signal. + // Ensure that m_media is back in ground state prior to starting next test step m_media->setCurrentSource(oldSource); + if (m_media->state() != Phonon::StoppedState) + QTest::waitForSignal(m_media, SIGNAL(stateChanged(Phonon::State, Phonon::State))); + QCOMPARE(m_media->state(), Phonon::StoppedState); + + QVERIFY(stateMatch); + QVERIFY(errorStringMatch); #else QSKIP("Unsupported on this platform.", SkipAll); -- cgit v0.12 From 240cf56a6490bc05339cc05457c8bab3b5cab66c Mon Sep 17 00:00:00 2001 From: Gareth Stockwell Date: Wed, 14 Apr 2010 16:15:32 +0100 Subject: tst_mediaobject: Removed non-portable escape codes from output Test step was outputting ANSI escape codes in order to highlight certain text. These codes are not natively supported by Windows consoles, resulting in raw escape codes appearing in the output. Reviewed-by: Frans Englich --- tests/auto/mediaobject/tst_mediaobject.cpp | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/tests/auto/mediaobject/tst_mediaobject.cpp b/tests/auto/mediaobject/tst_mediaobject.cpp index 7f9f57d..5328f63 100644 --- a/tests/auto/mediaobject/tst_mediaobject.cpp +++ b/tests/auto/mediaobject/tst_mediaobject.cpp @@ -193,16 +193,10 @@ static qint32 castQVariantToInt32(const QVariant &variant) return *reinterpret_cast(variant.constData()); } -static const char *const red = "\033[0;31m"; -static const char *const normal = "\033[0m"; - void tst_MediaObject::stateChanged(Phonon::State newstate, Phonon::State oldstate) { - if (newstate == Phonon::ErrorState) { - QWARN(QByteArray(QByteArray(red) + ".......................................................... ") + QByteArray(QTest::toString(oldstate)) + " to " + QByteArray(QTest::toString(newstate)) + normal); - } else { - //qDebug() << ".........................................................." << cyan << QTest::toString(oldstate) << "to" << QTest::toString(newstate) << normal; - } + if (newstate == Phonon::ErrorState) + QWARN(QByteArray(QByteArray(QTest::toString(oldstate)) + " to " + QByteArray(QTest::toString(newstate)))); } void tst_MediaObject::testPlayFromResource() -- cgit v0.12 From 151c2a2bd5e764555f32e6141024172e77788efd Mon Sep 17 00:00:00 2001 From: Gareth Stockwell Date: Wed, 14 Apr 2010 16:37:21 +0100 Subject: tst_mediaobject: ensure MediaObject is in StoppedState before each step Many of the steps in the tst_mediaobject suite (a) check that the MediaObject is in StoppedState at the start of the step and (b) call stopPlayback() at the end. If, however, a QTest check fails during the test, stopPlayback may not be called. This patch adds a call to MediaObject::stop() in the suite's init() function. This is a symptom of a wider problem with this test suite, namely that it re-uses a single instance of Phonon::MediaObject for all steps. Given the highly stateful nature of MediaObject, this can lead to test steps failing due to some state which was erroneously carried forward from an earlier step. While this test suite design may more faithfully represent real-world usage of Phonon, it makes tracking down the root causes of test failures needlessly difficult. Reviewed-by: Frans Englich --- tests/auto/mediaobject/tst_mediaobject.cpp | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/tests/auto/mediaobject/tst_mediaobject.cpp b/tests/auto/mediaobject/tst_mediaobject.cpp index 5328f63..127b775 100644 --- a/tests/auto/mediaobject/tst_mediaobject.cpp +++ b/tests/auto/mediaobject/tst_mediaobject.cpp @@ -251,6 +251,13 @@ void tst_MediaObject::init() } m_stateChangedSignalSpy->clear(); } + + // Ensure that m_media is in StoppedState + if (m_media->state() != Phonon::StoppedState) { + m_media->stop(); + QTest::waitForSignal(m_media, SIGNAL(stateChanged(Phonon::State, Phonon::State))); + QCOMPARE(m_media->state(), Phonon::StoppedState); + } } void tst_MediaObject::cleanup() -- cgit v0.12 From 430718023edfe83b4e028d97c1a57fd0cdbbdace Mon Sep 17 00:00:00 2001 From: Gareth Stockwell Date: Tue, 13 Apr 2010 16:42:41 +0100 Subject: Phonon MMF: Removed compiler warning Reviewed-by: Frans Englich --- src/3rdparty/phonon/mmf/videoplayer_dsa.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/3rdparty/phonon/mmf/videoplayer_dsa.cpp b/src/3rdparty/phonon/mmf/videoplayer_dsa.cpp index d607f1d..fbd8397 100644 --- a/src/3rdparty/phonon/mmf/videoplayer_dsa.cpp +++ b/src/3rdparty/phonon/mmf/videoplayer_dsa.cpp @@ -296,7 +296,7 @@ bool MMF::DsaVideoPlayer::stopDirectScreenAccess() const bool dsaWasActive = m_dsaActive; if (m_dsaActive) { - TRAPD(err, m_player->StopDirectScreenAccessL()); + TRAP(err, m_player->StopDirectScreenAccessL()); if (KErrNone == err) m_dsaActive = false; else -- cgit v0.12 From 0fa644049f3a864df4c1ffa47efd16d7d0c81cf3 Mon Sep 17 00:00:00 2001 From: Gareth Stockwell Date: Wed, 14 Apr 2010 12:14:32 +0100 Subject: Phonon MMF: Emit prefinishMarkReached(), finished() signals Fixes testPrefinishMark step in tst_mediaobject. Task-number: QTBUG-9339 Reviewed-by: Frans Englich --- src/3rdparty/phonon/mmf/abstractmediaplayer.cpp | 1 + src/3rdparty/phonon/mmf/mediaobject.cpp | 16 ++++++++++++++-- src/3rdparty/phonon/mmf/mediaobject.h | 3 +++ 3 files changed, 18 insertions(+), 2 deletions(-) diff --git a/src/3rdparty/phonon/mmf/abstractmediaplayer.cpp b/src/3rdparty/phonon/mmf/abstractmediaplayer.cpp index 6356c21..a90131d 100644 --- a/src/3rdparty/phonon/mmf/abstractmediaplayer.cpp +++ b/src/3rdparty/phonon/mmf/abstractmediaplayer.cpp @@ -386,6 +386,7 @@ void MMF::AbstractMediaPlayer::playbackComplete(int error) } else { setError(tr("Playback complete"), error); + emit finished(); } } diff --git a/src/3rdparty/phonon/mmf/mediaobject.cpp b/src/3rdparty/phonon/mmf/mediaobject.cpp index ee459e6..f881da0 100644 --- a/src/3rdparty/phonon/mmf/mediaobject.cpp +++ b/src/3rdparty/phonon/mmf/mediaobject.cpp @@ -323,11 +323,11 @@ void MMF::MediaObject::createPlayer(const MediaSource &source) connect(m_player.data(), SIGNAL(totalTimeChanged(qint64)), SIGNAL(totalTimeChanged(qint64))); connect(m_player.data(), SIGNAL(stateChanged(Phonon::State,Phonon::State)), SIGNAL(stateChanged(Phonon::State,Phonon::State))); connect(m_player.data(), SIGNAL(finished()), SIGNAL(finished())); - connect(m_player.data(), SIGNAL(tick(qint64)), SIGNAL(tick(qint64))); connect(m_player.data(), SIGNAL(bufferStatus(int)), SIGNAL(bufferStatus(int))); connect(m_player.data(), SIGNAL(metaDataChanged(QMultiMap)), SIGNAL(metaDataChanged(QMultiMap))); connect(m_player.data(), SIGNAL(aboutToFinish()), SIGNAL(aboutToFinish())); - connect(m_player.data(), SIGNAL(prefinishMarkReached(qint32)), SIGNAL(tick(qint32))); + connect(m_player.data(), SIGNAL(prefinishMarkReached(qint32)), SIGNAL(prefinishMarkReached(qint32))); + connect(m_player.data(), SIGNAL(prefinishMarkReached(qint32)), SLOT(handlePrefinishMarkReached(qint32))); // We need to call setError() after doing the connects, otherwise the // error won't be received. @@ -414,8 +414,20 @@ void MMF::MediaObject::switchToNextSource() m_nextSourceSet = false; switchToSource(m_nextSource); play(); + } else { + emit finished(); } } +//----------------------------------------------------------------------------- +// Other private functions +//----------------------------------------------------------------------------- + +void MMF::MediaObject::handlePrefinishMarkReached(qint32 time) +{ + emit tick(time); +} + + QT_END_NAMESPACE diff --git a/src/3rdparty/phonon/mmf/mediaobject.h b/src/3rdparty/phonon/mmf/mediaobject.h index 62e0a0e..f15eb21 100644 --- a/src/3rdparty/phonon/mmf/mediaobject.h +++ b/src/3rdparty/phonon/mmf/mediaobject.h @@ -107,6 +107,9 @@ Q_SIGNALS: void finished(); void tick(qint64 time); +private Q_SLOTS: + void handlePrefinishMarkReached(qint32); + private: void switchToSource(const MediaSource &source); void createPlayer(const MediaSource &source); -- cgit v0.12 From dc2d0315fc18fdbad7686adaf5f4886252fe0e5a Mon Sep 17 00:00:00 2001 From: Gareth Stockwell Date: Wed, 14 Apr 2010 10:54:44 +0100 Subject: Phonon MMF: Emit tick() signal Fixes testTickSignal step in tst_mediaobject. Task-number: QTBUG-9339 Reviewed-by: Frans Englich --- src/3rdparty/phonon/mmf/mediaobject.cpp | 1 + 1 file changed, 1 insertion(+) diff --git a/src/3rdparty/phonon/mmf/mediaobject.cpp b/src/3rdparty/phonon/mmf/mediaobject.cpp index f881da0..e1b921b 100644 --- a/src/3rdparty/phonon/mmf/mediaobject.cpp +++ b/src/3rdparty/phonon/mmf/mediaobject.cpp @@ -328,6 +328,7 @@ void MMF::MediaObject::createPlayer(const MediaSource &source) connect(m_player.data(), SIGNAL(aboutToFinish()), SIGNAL(aboutToFinish())); connect(m_player.data(), SIGNAL(prefinishMarkReached(qint32)), SIGNAL(prefinishMarkReached(qint32))); connect(m_player.data(), SIGNAL(prefinishMarkReached(qint32)), SLOT(handlePrefinishMarkReached(qint32))); + connect(m_player.data(), SIGNAL(tick(qint64)), SIGNAL(tick(qint64))); // We need to call setError() after doing the connects, otherwise the // error won't be received. -- cgit v0.12 From 468a0b27f8706e7d40f7b1c07f0cc0b50a48971b Mon Sep 17 00:00:00 2001 From: Gareth Stockwell Date: Wed, 14 Apr 2010 14:03:35 +0100 Subject: Phonon MMF: Suppress intermediate stateChanged() signal If MediaObject::play() is called while the object is in LoadingState, playback will start once loading is completed. Previously, the Symbian backend at this point emitted two stateChanged signals - first to StoppedState and then to PlayingState. The testPlayOnFinish step in tst_mediaobject requires that only one state change occurs: directly from LoadingState to PlayingState. Reviewed-by: Frans Englich --- src/3rdparty/phonon/mmf/abstractmediaplayer.cpp | 20 +++++++++++++------- src/3rdparty/phonon/mmf/abstractmediaplayer.h | 4 +++- 2 files changed, 16 insertions(+), 8 deletions(-) diff --git a/src/3rdparty/phonon/mmf/abstractmediaplayer.cpp b/src/3rdparty/phonon/mmf/abstractmediaplayer.cpp index a90131d..221443e 100644 --- a/src/3rdparty/phonon/mmf/abstractmediaplayer.cpp +++ b/src/3rdparty/phonon/mmf/abstractmediaplayer.cpp @@ -79,9 +79,7 @@ void MMF::AbstractMediaPlayer::play() case StoppedState: case PausedState: - doPlay(); - startPositionTimer(); - changeState(PlayingState); + startPlayback(); break; case PlayingState: @@ -441,6 +439,13 @@ void MMF::AbstractMediaPlayer::resetMarksIfRewound() m_aboutToFinishSent = false; } +void MMF::AbstractMediaPlayer::startPlayback() +{ + doPlay(); + startPositionTimer(); + changeState(PlayingState); +} + void MMF::AbstractMediaPlayer::bufferStatusTick() { emit MMF::AbstractPlayer::bufferStatus(bufferStatus()); @@ -453,9 +458,6 @@ void MMF::AbstractMediaPlayer::changeState(PrivateState newState) const Phonon::State oldPhononState = phononState(privateState()); const Phonon::State newPhononState = phononState(newState); - // TODO: add some invariants to check that the transition is valid - AbstractPlayer::changeState(newState); - if (LoadingState == oldPhononState && StoppedState == newPhononState) { // Ensure initial volume is set on MMF API before starting playback doVolumeChanged(); @@ -465,8 +467,12 @@ void MMF::AbstractMediaPlayer::changeState(PrivateState newState) if (m_playPending) { TRACE_0("play was called while loading; starting playback now"); m_playPending = false; - play(); + startPlayback(); + } else { + AbstractPlayer::changeState(newState); } + } else { + AbstractPlayer::changeState(newState); } } diff --git a/src/3rdparty/phonon/mmf/abstractmediaplayer.h b/src/3rdparty/phonon/mmf/abstractmediaplayer.h index 308b5af..f8f86af 100644 --- a/src/3rdparty/phonon/mmf/abstractmediaplayer.h +++ b/src/3rdparty/phonon/mmf/abstractmediaplayer.h @@ -70,7 +70,8 @@ protected: virtual int openUrl(const QString& url) = 0; virtual int bufferStatus() const = 0; virtual void close() = 0; - virtual void changeState(PrivateState newState); + + void changeState(PrivateState newState); void updateMetaData(); virtual int numberOfMetaDataEntries() const = 0; @@ -93,6 +94,7 @@ private: void doVolumeChanged(); void emitMarksIfReached(qint64 position); void resetMarksIfRewound(); + void startPlayback(); private Q_SLOTS: void positionTick(); -- cgit v0.12 From 4f97cf29e5be9f34341dd99ad4bd8dd3d61b1441 Mon Sep 17 00:00:00 2001 From: Gareth Stockwell Date: Wed, 14 Apr 2010 14:39:39 +0100 Subject: Phonon MMF: change to PausedState, not StoppedState when finished This behaviour is required by the testPauseOnFinish step in tst_mediaobject. Reviewed-by: Frans Englich --- src/3rdparty/phonon/mmf/abstractmediaplayer.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/3rdparty/phonon/mmf/abstractmediaplayer.cpp b/src/3rdparty/phonon/mmf/abstractmediaplayer.cpp index 221443e..ea2d536 100644 --- a/src/3rdparty/phonon/mmf/abstractmediaplayer.cpp +++ b/src/3rdparty/phonon/mmf/abstractmediaplayer.cpp @@ -375,7 +375,7 @@ void MMF::AbstractMediaPlayer::playbackComplete(int error) } if (KErrNone == error) { - changeState(StoppedState); + changeState(PausedState); // MediaObject::switchToNextSource deletes the current player, so we // call it via delayed slot invokation to ensure that this object does -- cgit v0.12 From 7e598398ec161e3fc5df98ea754bd637d0c1ba30 Mon Sep 17 00:00:00 2001 From: Gareth Stockwell Date: Wed, 14 Apr 2010 16:03:50 +0100 Subject: Phonon MMF: calling pause() when in StoppedState triggers stateChanged() Previously, the MMF backend simply swallowed a call to pause() when in StoppedState. However, the stopToPause step in tst_mediaobject requires the backend to emit a stateChanged signal when this happens. Reviewed-by: Frans Englich --- src/3rdparty/phonon/mmf/abstractmediaplayer.cpp | 65 ++++++++++++++++++++----- src/3rdparty/phonon/mmf/abstractmediaplayer.h | 20 +++++--- src/3rdparty/phonon/mmf/abstractplayer.cpp | 2 +- src/3rdparty/phonon/mmf/abstractplayer.h | 2 +- src/3rdparty/phonon/mmf/abstractvideoplayer.cpp | 5 +- src/3rdparty/phonon/mmf/audioplayer.cpp | 6 +-- tests/auto/mediaobject/tst_mediaobject.cpp | 2 +- 7 files changed, 72 insertions(+), 30 deletions(-) diff --git a/src/3rdparty/phonon/mmf/abstractmediaplayer.cpp b/src/3rdparty/phonon/mmf/abstractmediaplayer.cpp index ea2d536..7104ebd 100644 --- a/src/3rdparty/phonon/mmf/abstractmediaplayer.cpp +++ b/src/3rdparty/phonon/mmf/abstractmediaplayer.cpp @@ -48,7 +48,7 @@ MMF::AbstractMediaPlayer::AbstractMediaPlayer (MediaObject *parent, const AbstractPlayer *player) : AbstractPlayer(player) , m_parent(parent) - , m_playPending(false) + , m_pending(NothingPending) , m_positionTimer(new QTimer(this)) , m_bufferStatusTimer(new QTimer(this)) , m_mmfMaxVolume(NullMaxVolume) @@ -74,7 +74,7 @@ void MMF::AbstractMediaPlayer::play() break; case LoadingState: - m_playPending = true; + setPending(PlayPending); break; case StoppedState: @@ -101,14 +101,16 @@ void MMF::AbstractMediaPlayer::pause() TRACE_CONTEXT(AbstractMediaPlayer::pause, EAudioApi); TRACE_ENTRY("state %d", privateState()); - m_playPending = false; stopTimers(); switch (privateState()) { case GroundState: case LoadingState: - case PausedState: case StoppedState: + setPending(PausePending); + break; + + case PausedState: // Do nothing break; @@ -133,7 +135,7 @@ void MMF::AbstractMediaPlayer::stop() TRACE_CONTEXT(AbstractMediaPlayer::stop, EAudioApi); TRACE_ENTRY("state %d", privateState()); - m_playPending = false; + setPending(NothingPending); stopTimers(); switch (privateState()) { @@ -363,6 +365,18 @@ void MMF::AbstractMediaPlayer::maxVolumeChanged(int mmfMaxVolume) doVolumeChanged(); } +void MMF::AbstractMediaPlayer::loadingComplete(int error) +{ + Q_ASSERT(Phonon::LoadingState == state()); + + if (KErrNone == error) { + updateMetaData(); + changeState(StoppedState); + } else { + setError(tr("Loading clip failed"), error); + } +} + void MMF::AbstractMediaPlayer::playbackComplete(int error) { stopTimers(); @@ -439,6 +453,15 @@ void MMF::AbstractMediaPlayer::resetMarksIfRewound() m_aboutToFinishSent = false; } +void MMF::AbstractMediaPlayer::setPending(Pending pending) +{ + const Phonon::State oldState = state(); + m_pending = pending; + const Phonon::State newState = state(); + if (newState != oldState) + emit stateChanged(newState, oldState); +} + void MMF::AbstractMediaPlayer::startPlayback() { doPlay(); @@ -451,6 +474,18 @@ void MMF::AbstractMediaPlayer::bufferStatusTick() emit MMF::AbstractPlayer::bufferStatus(bufferStatus()); } +Phonon::State MMF::AbstractMediaPlayer::phononState(PrivateState state) const +{ + Phonon::State result = AbstractPlayer::phononState(state); + + if (PausePending == m_pending) { + Q_ASSERT(Phonon::StoppedState == result || Phonon::LoadingState == result); + result = Phonon::PausedState; + } + + return result; +} + void MMF::AbstractMediaPlayer::changeState(PrivateState newState) { TRACE_CONTEXT(AbstractMediaPlayer::changeState, EAudioInternal); @@ -462,15 +497,21 @@ void MMF::AbstractMediaPlayer::changeState(PrivateState newState) // Ensure initial volume is set on MMF API before starting playback doVolumeChanged(); - // Check whether play() was called while clip was being loaded. If so, - // playback should be started now - if (m_playPending) { - TRACE_0("play was called while loading; starting playback now"); - m_playPending = false; - startPlayback(); - } else { + switch (m_pending) { + case NothingPending: AbstractPlayer::changeState(newState); + break; + + case PlayPending: + startPlayback(); + break; + + case PausePending: + AbstractPlayer::changeState(PausedState); + break; } + + setPending(NothingPending); } else { AbstractPlayer::changeState(newState); } diff --git a/src/3rdparty/phonon/mmf/abstractmediaplayer.h b/src/3rdparty/phonon/mmf/abstractmediaplayer.h index f8f86af..23a8233 100644 --- a/src/3rdparty/phonon/mmf/abstractmediaplayer.h +++ b/src/3rdparty/phonon/mmf/abstractmediaplayer.h @@ -60,6 +60,8 @@ public: protected: // AbstractPlayer virtual void doSetTickInterval(qint32 interval); + virtual Phonon::State phononState(PrivateState state) const; + virtual void changeState(PrivateState newState); virtual void doPlay() = 0; virtual void doPause() = 0; @@ -71,8 +73,6 @@ protected: virtual int bufferStatus() const = 0; virtual void close() = 0; - void changeState(PrivateState newState); - void updateMetaData(); virtual int numberOfMetaDataEntries() const = 0; virtual QPair metaDataEntry(int index) const = 0; @@ -81,6 +81,7 @@ protected: void bufferingStarted(); void bufferingComplete(); void maxVolumeChanged(int maxVolume); + void loadingComplete(int error); void playbackComplete(int error); static qint64 toMilliSeconds(const TTimeIntervalMicroSeconds &); @@ -96,6 +97,14 @@ private: void resetMarksIfRewound(); void startPlayback(); + enum Pending { + NothingPending, + PausePending, + PlayPending + }; + + void setPending(Pending pending); + private Q_SLOTS: void positionTick(); void bufferStatusTick(); @@ -103,12 +112,7 @@ private Q_SLOTS: private: MediaObject *const m_parent; - /** - * This flag is set to true if play is called when the object is - * in a Loading state. Once loading is complete, playback will - * be started. - */ - bool m_playPending; + Pending m_pending; QScopedPointer m_positionTimer; diff --git a/src/3rdparty/phonon/mmf/abstractplayer.cpp b/src/3rdparty/phonon/mmf/abstractplayer.cpp index 421155b..8c3f5cb 100644 --- a/src/3rdparty/phonon/mmf/abstractplayer.cpp +++ b/src/3rdparty/phonon/mmf/abstractplayer.cpp @@ -141,7 +141,7 @@ Phonon::State MMF::AbstractPlayer::phononState() const return phononState(m_state); } -Phonon::State MMF::AbstractPlayer::phononState(PrivateState state) +Phonon::State MMF::AbstractPlayer::phononState(PrivateState state) const { const Phonon::State phononState = GroundState == state diff --git a/src/3rdparty/phonon/mmf/abstractplayer.h b/src/3rdparty/phonon/mmf/abstractplayer.h index 92bd87e..ab892f5 100644 --- a/src/3rdparty/phonon/mmf/abstractplayer.h +++ b/src/3rdparty/phonon/mmf/abstractplayer.h @@ -133,7 +133,7 @@ protected: /** * Converts PrivateState into the corresponding Phonon::State */ - static Phonon::State phononState(PrivateState state); + virtual Phonon::State phononState(PrivateState state) const; virtual void videoOutputChanged(); diff --git a/src/3rdparty/phonon/mmf/abstractvideoplayer.cpp b/src/3rdparty/phonon/mmf/abstractvideoplayer.cpp index c2bcce0..2e0ab1c 100644 --- a/src/3rdparty/phonon/mmf/abstractvideoplayer.cpp +++ b/src/3rdparty/phonon/mmf/abstractvideoplayer.cpp @@ -268,11 +268,10 @@ void MMF::AbstractVideoPlayer::MvpuoPrepareComplete(TInt aError) handlePendingParametersChanged(); emit totalTimeChanged(totalTime()); - changeState(StoppedState); - } else { - setError(tr("Buffering clip failed"), err); } + loadingComplete(aError); + TRACE_EXIT_0(); } diff --git a/src/3rdparty/phonon/mmf/audioplayer.cpp b/src/3rdparty/phonon/mmf/audioplayer.cpp index ee07229..77a0964 100644 --- a/src/3rdparty/phonon/mmf/audioplayer.cpp +++ b/src/3rdparty/phonon/mmf/audioplayer.cpp @@ -203,12 +203,10 @@ void MMF::AudioPlayer::MapcInitComplete(TInt aError, maxVolumeChanged(m_player->MaxVolume()); m_totalTime = toMilliSeconds(m_player->Duration()); emit totalTimeChanged(m_totalTime); - updateMetaData(); - changeState(StoppedState); - } else { - setError(tr("Opening clip failed"), aError); } + loadingComplete(aError); + TRACE_EXIT_0(); } diff --git a/tests/auto/mediaobject/tst_mediaobject.cpp b/tests/auto/mediaobject/tst_mediaobject.cpp index 127b775..994057b 100644 --- a/tests/auto/mediaobject/tst_mediaobject.cpp +++ b/tests/auto/mediaobject/tst_mediaobject.cpp @@ -575,7 +575,7 @@ void tst_MediaObject::playSDP() // MediaObject should have loaded the SDP, but be in error state due to absent media const bool stateMatch = (m_media->state() == Phonon::ErrorState); - const bool errorStringMatch = (m_media->errorString() == QString::fromLatin1("Buffering clip failed: Unknown error (-39)")); + const bool errorStringMatch = (m_media->errorString() == QString::fromLatin1("Loading clip failed: Unknown error (-39)")); // Ensure that m_media is back in ground state prior to starting next test step m_media->setCurrentSource(oldSource); -- cgit v0.12 From 0c2f5376e921fa9badd87a3eb37d94868451248c Mon Sep 17 00:00:00 2001 From: Gareth Stockwell Date: Wed, 14 Apr 2010 19:31:22 +0100 Subject: Phonon MMF: fix state changes emitted during playlist handling This change is required by the testPlayBeforeFinish step in tst_mediaobject. This test starts playback of one track, then calls MediaObject::setCurrentSource() followed by MediaObject::play(). The step checks that the following stateChanged() signals are emitted by the MediaObject: 1. StoppedState (optionally) 2. LoadingState 3. BufferingState or PlayingState The state changes emitted by the Phonon MMF backend were: 1. PlayingState -> StoppedState 2. LoadingState -> PlayingState This patch fixes the discontinuity in state changes which occurred while processing a playlist. Reviewed-by: Frans Englich --- src/3rdparty/phonon/mmf/abstractplayer.cpp | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/3rdparty/phonon/mmf/abstractplayer.cpp b/src/3rdparty/phonon/mmf/abstractplayer.cpp index 8c3f5cb..77d7ae0 100644 --- a/src/3rdparty/phonon/mmf/abstractplayer.cpp +++ b/src/3rdparty/phonon/mmf/abstractplayer.cpp @@ -48,6 +48,11 @@ MMF::AbstractPlayer::AbstractPlayer(const AbstractPlayer *player) m_tickInterval = player->m_tickInterval; m_transitionTime = player->m_transitionTime; m_prefinishMark = player->m_prefinishMark; + + // This is to prevent unwanted state transitions occurring as a result + // of MediaObject::switchToNextSource() during playlist playback. + if (StoppedState == player->m_state) + m_state = player->m_state; } } -- cgit v0.12 From 92ed8a1a049f60733ce15c4a5b79ed0fc389cfcd Mon Sep 17 00:00:00 2001 From: Gareth Stockwell Date: Wed, 14 Apr 2010 20:04:39 +0100 Subject: Phonon MMF: ensure initial volume is applied A recent change meant that, if the user set a volume level before loading a clip into the MediaObject, that initial volume level was not applied to the audio output. Reviewed-by: Frans Englich --- src/3rdparty/phonon/mmf/abstractmediaplayer.cpp | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/src/3rdparty/phonon/mmf/abstractmediaplayer.cpp b/src/3rdparty/phonon/mmf/abstractmediaplayer.cpp index 7104ebd..be2a568 100644 --- a/src/3rdparty/phonon/mmf/abstractmediaplayer.cpp +++ b/src/3rdparty/phonon/mmf/abstractmediaplayer.cpp @@ -494,15 +494,14 @@ void MMF::AbstractMediaPlayer::changeState(PrivateState newState) const Phonon::State newPhononState = phononState(newState); if (LoadingState == oldPhononState && StoppedState == newPhononState) { - // Ensure initial volume is set on MMF API before starting playback - doVolumeChanged(); - switch (m_pending) { case NothingPending: AbstractPlayer::changeState(newState); break; case PlayPending: + changeState(PlayingState); // necessary in order to apply initial volume + doVolumeChanged(); startPlayback(); break; -- cgit v0.12 From 04c24781613a937c472c556391d738b6d563201d Mon Sep 17 00:00:00 2001 From: Gareth Stockwell Date: Wed, 14 Apr 2010 20:45:58 +0100 Subject: Phonon MMF: fixed crash during opening of video clip A crash was observed during opening a video clip, and was traced to dereferencing a null m_player pointer in DsaVideoPlayer::handleParametersChanged(), which is called during construction, but before createPlayer() has been called. This was reproducible using the following sequence: 1. Launch qmediaplayer 2. Play an audio clip 3. Open a video clip However, the following sequence worked as expected: 1. Launch qmediaplayer 2. Play a video clip 3. Play an audio clip 4. Play a video clip ... It is not clear which commit introduced this defect. Reviewed-by: Frans Englich --- src/3rdparty/phonon/mmf/videoplayer_dsa.cpp | 60 +++++++++++++------------ src/3rdparty/phonon/mmf/videoplayer_surface.cpp | 55 +++++++++++------------ 2 files changed, 58 insertions(+), 57 deletions(-) diff --git a/src/3rdparty/phonon/mmf/videoplayer_dsa.cpp b/src/3rdparty/phonon/mmf/videoplayer_dsa.cpp index fbd8397..1925471 100644 --- a/src/3rdparty/phonon/mmf/videoplayer_dsa.cpp +++ b/src/3rdparty/phonon/mmf/videoplayer_dsa.cpp @@ -226,38 +226,40 @@ void MMF::DsaVideoPlayer::handleParametersChanged(VideoParameters parameters) getDsaRegion(m_wsSession, *m_window); #endif - static const TBool antialias = ETrue; - int err = KErrNone; - - if (parameters & ScaleFactors) { - TRAP(err, m_player->SetScaleFactorL(m_scaleWidth, m_scaleHeight, - antialias)); - if(KErrNone != err) { - TRACE("SetScaleFactorL (1) err %d", err); - setError(tr("Video display error"), err); + if (m_player) { + static const TBool antialias = ETrue; + int err = KErrNone; + + if (parameters & ScaleFactors) { + TRAP(err, m_player->SetScaleFactorL(m_scaleWidth, m_scaleHeight, + antialias)); + if(KErrNone != err) { + TRACE("SetScaleFactorL (1) err %d", err); + setError(tr("Video display error"), err); + } } - } - if (KErrNone == err) { - if (parameters & WindowHandle || parameters & WindowScreenRect) { - TRAP(err, - m_player->SetDisplayWindowL(m_wsSession, m_screenDevice, - *m_window, - m_videoScreenRect, - m_videoScreenRect)); - } + if (KErrNone == err) { + if (parameters & WindowHandle || parameters & WindowScreenRect) { + TRAP(err, + m_player->SetDisplayWindowL(m_wsSession, m_screenDevice, + *m_window, + m_videoScreenRect, + m_videoScreenRect)); + } - if (KErrNone != err) { - TRACE("SetDisplayWindowL err %d", err); - setError(tr("Video display error"), err); - } else { - m_dsaActive = true; - if (parameters & ScaleFactors) { - TRAP(err, m_player->SetScaleFactorL(m_scaleWidth, m_scaleHeight, - antialias)); - if (KErrNone != err) { - TRACE("SetScaleFactorL (2) err %d", err); - setError(tr("Video display error"), err); + if (KErrNone != err) { + TRACE("SetDisplayWindowL err %d", err); + setError(tr("Video display error"), err); + } else { + m_dsaActive = true; + if (parameters & ScaleFactors) { + TRAP(err, m_player->SetScaleFactorL(m_scaleWidth, m_scaleHeight, + antialias)); + if (KErrNone != err) { + TRACE("SetScaleFactorL (2) err %d", err); + setError(tr("Video display error"), err); + } } } } diff --git a/src/3rdparty/phonon/mmf/videoplayer_surface.cpp b/src/3rdparty/phonon/mmf/videoplayer_surface.cpp index 5f234e5..fda7342 100644 --- a/src/3rdparty/phonon/mmf/videoplayer_surface.cpp +++ b/src/3rdparty/phonon/mmf/videoplayer_surface.cpp @@ -104,44 +104,43 @@ void MMF::SurfaceVideoPlayer::handleVideoWindowChanged() void MMF::SurfaceVideoPlayer::handleParametersChanged(VideoParameters parameters) { - CVideoPlayerUtility2 *player = static_cast(m_player.data()); - - int err = KErrNone; - TRect rect; - if (m_videoOutput) { m_videoOutput->dump(); const QSize size = m_videoOutput->videoWindowSize(); rect.SetSize(TSize(size.width(), size.height())); } - if (parameters & WindowHandle) { - if (m_displayWindow) - player->RemoveDisplayWindow(*m_displayWindow); - - RWindow *window = static_cast(m_window); - if (window) { - window->SetBackgroundColor(TRgb(0, 0, 0, 255)); - TRAP(err, player->AddDisplayWindowL(m_wsSession, m_screenDevice, *window, rect, rect)); - if (KErrNone != err) { - setError(tr("Video display error"), err); - window = 0; + CVideoPlayerUtility2 *player = static_cast(m_player.data()); + if (player) { + int err = KErrNone; + if (parameters & WindowHandle) { + if (m_displayWindow) + player->RemoveDisplayWindow(*m_displayWindow); + + RWindow *window = static_cast(m_window); + if (window) { + window->SetBackgroundColor(TRgb(0, 0, 0, 255)); + TRAP(err, player->AddDisplayWindowL(m_wsSession, m_screenDevice, *window, rect, rect)); + if (KErrNone != err) { + setError(tr("Video display error"), err); + window = 0; + } } + m_displayWindow = window; } - m_displayWindow = window; - } - if (KErrNone == err) { - if (parameters & ScaleFactors) { - Q_ASSERT(m_displayWindow); - TRAP(err, player->SetVideoExtentL(*m_displayWindow, rect)); - if (KErrNone == err) - TRAP(err, player->SetWindowClipRectL(*m_displayWindow, rect)); - if (KErrNone == err) - TRAP(err, player->SetScaleFactorL(*m_displayWindow, m_scaleWidth, m_scaleHeight)); - if (KErrNone != err) - setError(tr("Video display error"), err); + if (KErrNone == err) { + if (parameters & ScaleFactors) { + Q_ASSERT(m_displayWindow); + TRAP(err, player->SetVideoExtentL(*m_displayWindow, rect)); + if (KErrNone == err) + TRAP(err, player->SetWindowClipRectL(*m_displayWindow, rect)); + if (KErrNone == err) + TRAP(err, player->SetScaleFactorL(*m_displayWindow, m_scaleWidth, m_scaleHeight)); + if (KErrNone != err) + setError(tr("Video display error"), err); + } } } } -- cgit v0.12 From 0ebc9a600af8188e7a9d3c2904d012c6289a515d Mon Sep 17 00:00:00 2001 From: Gareth Stockwell Date: Thu, 15 Apr 2010 08:09:40 +0100 Subject: Fixed compiler warning Reviewed-by: trustme --- src/multimedia/audio/qaudio_symbian_p.cpp | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/multimedia/audio/qaudio_symbian_p.cpp b/src/multimedia/audio/qaudio_symbian_p.cpp index 58e3745..afe98f5 100644 --- a/src/multimedia/audio/qaudio_symbian_p.cpp +++ b/src/multimedia/audio/qaudio_symbian_p.cpp @@ -315,7 +315,7 @@ bool isFormatSupported(const QAudioFormat &formatQt, TUint32 fourCC; bool result = false; - if (formatQt.codec() == "audio/pcm" && + if (formatQt.codec() == QString::fromAscii("audio/pcm") && formatQtToNative(formatQt, fourCC, formatNative)) { result = (formatNative.iRate & caps.caps().iRate) @@ -337,7 +337,7 @@ bool formatQtToNative(const QAudioFormat &inputFormat, TMMFMonoStereo outputChannels; TMMFSoundEncoding outputEncoding; - if (inputFormat.codec() == "audio/pcm") { + if (inputFormat.codec() == QString::fromAscii("audio/pcm")) { result = sampleRateQtToNative(inputFormat.frequency(), outputSampleRate) && channelsQtToNative(inputFormat.channels(), outputChannels) -- cgit v0.12 From e93dd08b675029388d810eeea45e5f005642fcc9 Mon Sep 17 00:00:00 2001 From: Sami Merila Date: Thu, 15 Apr 2010 10:39:27 +0300 Subject: Slider graphics does not look correct in N95 The upscaling of theme graphics fails, if the original rect is taller than upscaled graphics rect height. This makes the start and end parts of the graphics appear as shorter then they should be. Fixed by forcing the destrination rect height to be used after upscaling the graphics. Task-number: QTBUG-9854 Reviewed-by: Janne Anttila --- src/gui/styles/qs60style.cpp | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gui/styles/qs60style.cpp b/src/gui/styles/qs60style.cpp index 27913cd..3259d82 100644 --- a/src/gui/styles/qs60style.cpp +++ b/src/gui/styles/qs60style.cpp @@ -548,6 +548,7 @@ void QS60StylePrivate::drawRow(QS60StyleEnums::SkinParts start, startEndSize.scale(rect.size(), Qt::KeepAspectRatio); QRect startRect = QRect(rect.topLeft(), startEndSize); + startRect.setHeight(rect.height()); QRect middleRect = rect; QRect endRect; -- cgit v0.12 From 9da13ea53aec6d841ba7f416531d6c52d4368df4 Mon Sep 17 00:00:00 2001 From: Yoann Lopes Date: Thu, 15 Apr 2010 10:41:18 +0200 Subject: Fixes tooltips for QGraphicsProxyWidget. Help event was not propagated to the widget. Also fixes tooltip value propagation when setting it on the proxy or on the widget. Autotest included. Task-number: QTBUG-5349 Reviewed-by: bnilsen --- src/gui/graphicsview/qgraphicsproxywidget.cpp | 31 +++++++ src/gui/graphicsview/qgraphicsproxywidget_p.h | 2 + src/gui/graphicsview/qgraphicsscene.cpp | 6 ++ src/gui/kernel/qtooltip.cpp | 4 +- .../tst_qgraphicsproxywidget.cpp | 99 +++++++++++++++++----- 5 files changed, 118 insertions(+), 24 deletions(-) diff --git a/src/gui/graphicsview/qgraphicsproxywidget.cpp b/src/gui/graphicsview/qgraphicsproxywidget.cpp index 2132526..bdd41cd 100644 --- a/src/gui/graphicsview/qgraphicsproxywidget.cpp +++ b/src/gui/graphicsview/qgraphicsproxywidget.cpp @@ -897,6 +897,29 @@ bool QGraphicsProxyWidget::event(QEvent *event) } break; } +#ifndef QT_NO_TOOLTIP + case QEvent::GraphicsSceneHelp: { + // Propagate the help event (for tooltip) to the widget under mouse + if (d->lastWidgetUnderMouse) { + QGraphicsSceneHelpEvent *he = static_cast(event); + QPoint pos = d->mapToReceiver(mapFromScene(he->scenePos()), d->lastWidgetUnderMouse).toPoint(); + QHelpEvent e(QEvent::ToolTip, pos, he->screenPos()); + QApplication::sendEvent(d->lastWidgetUnderMouse, &e); + event->setAccepted(e.isAccepted()); + return e.isAccepted(); + } + break; + } + case QEvent::ToolTipChange: { + // Propagate tooltip change to the widget + if (!d->tooltipChangeMode) { + d->tooltipChangeMode = QGraphicsProxyWidgetPrivate::ProxyToWidgetMode; + d->widget->setToolTip(toolTip()); + d->tooltipChangeMode = QGraphicsProxyWidgetPrivate::NoMode; + } + break; + } +#endif default: break; } @@ -952,6 +975,14 @@ bool QGraphicsProxyWidget::eventFilter(QObject *object, QEvent *event) d->styleChangeMode = QGraphicsProxyWidgetPrivate::NoMode; } break; + case QEvent::ToolTipChange: + // Propagate tooltip change to the proxy. + if (!d->tooltipChangeMode) { + d->tooltipChangeMode = QGraphicsProxyWidgetPrivate::WidgetToProxyMode; + setToolTip(d->widget->toolTip()); + d->tooltipChangeMode = QGraphicsProxyWidgetPrivate::NoMode; + } + break; default: break; } diff --git a/src/gui/graphicsview/qgraphicsproxywidget_p.h b/src/gui/graphicsview/qgraphicsproxywidget_p.h index 8aed363..0e29a7e 100644 --- a/src/gui/graphicsview/qgraphicsproxywidget_p.h +++ b/src/gui/graphicsview/qgraphicsproxywidget_p.h @@ -72,6 +72,7 @@ public: enabledChangeMode(NoMode), styleChangeMode(NoMode), paletteChangeMode(NoMode), + tooltipChangeMode(NoMode), focusFromWidgetToProxy(0) { } void init(); @@ -117,6 +118,7 @@ public: quint32 enabledChangeMode : 2; quint32 styleChangeMode : 2; quint32 paletteChangeMode : 2; + quint32 tooltipChangeMode : 2; quint32 focusFromWidgetToProxy : 1; quint32 proxyIsGivingFocus : 1; }; diff --git a/src/gui/graphicsview/qgraphicsscene.cpp b/src/gui/graphicsview/qgraphicsscene.cpp index 6581727..b368a82 100644 --- a/src/gui/graphicsview/qgraphicsscene.cpp +++ b/src/gui/graphicsview/qgraphicsscene.cpp @@ -3772,6 +3772,12 @@ void QGraphicsScene::helpEvent(QGraphicsSceneHelpEvent *helpEvent) QGraphicsItem *toolTipItem = 0; for (int i = 0; i < itemsAtPos.size(); ++i) { QGraphicsItem *tmp = itemsAtPos.at(i); + if (tmp->d_func()->isProxyWidget()) { + // if the item is a proxy widget, the event is forwarded to it + sendEvent(tmp, helpEvent); + if (helpEvent->isAccepted()) + return; + } if (!tmp->toolTip().isEmpty()) { toolTipItem = tmp; break; diff --git a/src/gui/kernel/qtooltip.cpp b/src/gui/kernel/qtooltip.cpp index 1343959..c8fcf45 100644 --- a/src/gui/kernel/qtooltip.cpp +++ b/src/gui/kernel/qtooltip.cpp @@ -168,9 +168,9 @@ QTipLabel *QTipLabel::instance = 0; QTipLabel::QTipLabel(const QString &text, QWidget *w) #ifndef QT_NO_STYLE_STYLESHEET - : QLabel(w, Qt::ToolTip), styleSheetParent(0), widget(0) + : QLabel(w, Qt::ToolTip | Qt::BypassGraphicsProxyWidget), styleSheetParent(0), widget(0) #else - : QLabel(w, Qt::ToolTip), widget(0) + : QLabel(w, Qt::ToolTip | Qt::BypassGraphicsProxyWidget), widget(0) #endif { delete instance; diff --git a/tests/auto/qgraphicsproxywidget/tst_qgraphicsproxywidget.cpp b/tests/auto/qgraphicsproxywidget/tst_qgraphicsproxywidget.cpp index e46709b..a5a039a 100644 --- a/tests/auto/qgraphicsproxywidget/tst_qgraphicsproxywidget.cpp +++ b/tests/auto/qgraphicsproxywidget/tst_qgraphicsproxywidget.cpp @@ -43,6 +43,7 @@ #include #include #include "../../shared/util.h" +#include #include // qSmartMin functions... #if defined(Q_WS_MAC) && !defined(QT_NO_STYLE_MAC) #include @@ -2582,33 +2583,87 @@ void tst_QGraphicsProxyWidget::changingCursor_basic() void tst_QGraphicsProxyWidget::tooltip_basic() { - // Confirm that mouse events are working properly by checking that - // when moving the mouse over a label with a tooptip the tooltip appears + QString toolTip = "Qt rocks!"; + QString toolTip2 = "Qt rocks even more!"; + + QPushButton *button = new QPushButton("button"); + QGraphicsProxyWidget *proxy = new QGraphicsProxyWidget; + QGraphicsProxyWidgetPrivate *proxyd = static_cast(QGraphicsItemPrivate::get(proxy)); + proxy->setWidget(button); + proxyd->lastWidgetUnderMouse = button; // force widget under mouse + + QVERIFY(button->toolTip().isEmpty()); + QVERIFY(proxy->toolTip().isEmpty()); + // Check that setting the tooltip on the proxy also set it on the widget + proxy->setToolTip(toolTip); + QCOMPARE(proxy->toolTip(), toolTip); + QCOMPARE(button->toolTip(), toolTip); + // Check that setting the tooltip on the widget also set it on the proxy + button->setToolTip(toolTip2); + QCOMPARE(proxy->toolTip(), toolTip2); + QCOMPARE(button->toolTip(), toolTip2); + QGraphicsScene scene; + scene.addItem(proxy); + QGraphicsView view(&scene); + view.setFixedSize(200, 200); view.show(); + QTest::qWaitForWindowShown(&view); + { + QHelpEvent helpEvent(QEvent::ToolTip, view.viewport()->rect().topLeft(), + view.viewport()->mapToGlobal(view.viewport()->rect().topLeft())); + QApplication::sendEvent(view.viewport(), &helpEvent); + QTest::qWait(350); + + bool foundView = false; + bool foundTipLabel = false; + foreach (QWidget *widget, QApplication::topLevelWidgets()) { + if (widget == &view) + foundView = true; + if (widget->inherits("QTipLabel")) + foundTipLabel = true; + } + QVERIFY(foundView); + QVERIFY(!foundTipLabel); + } - QSKIP("Tooltips don't work yet", SkipAll); - - SubQGraphicsProxyWidget *proxy = new SubQGraphicsProxyWidget; - QLabel *widget = new QLabel; - widget->setText("If it ain't tested it's broken"); - widget->setToolTip("When in doubt, test"); - proxy->setWidget(widget); - widget->show(); - scene.addItem(proxy); - QTest::qWait(125); - - // in - QTest::mouseMove(view.viewport(), view.mapFromScene(proxy->mapToScene(proxy->boundingRect().center()))); + { + QHelpEvent helpEvent(QEvent::ToolTip, view.mapFromScene(proxy->boundingRect().center()), + view.viewport()->mapToGlobal(view.mapFromScene(proxy->boundingRect().center()))); + QApplication::sendEvent(view.viewport(), &helpEvent); + QTest::qWait(350); + + bool foundView = false; + bool foundTipLabel = false; + foreach (QWidget *widget, QApplication::topLevelWidgets()) { + if (widget == &view) + foundView = true; + if (widget->inherits("QTipLabel")) + foundTipLabel = true; + } + QVERIFY(foundView); + QVERIFY(foundTipLabel); + } - QTRY_COMPARE(proxy->childItems().count(), 1); - QGraphicsProxyWidget *child = (QGraphicsProxyWidget*)(proxy->childItems())[0]; - QVERIFY(child->isWidget()); - QVERIFY(child->widget()); - QCOMPARE(child->widget()->parent(), static_cast(widget)); - QCOMPARE(child->widget()->x(), widget->x()); // ### ??? - QCOMPARE(child->widget()->y(), widget->y() + widget->height()); // ### ??? + { + QHelpEvent helpEvent(QEvent::ToolTip, view.viewport()->rect().topLeft(), + view.viewport()->mapToGlobal(view.viewport()->rect().topLeft())); + QApplication::sendEvent(view.viewport(), &helpEvent); + // Wait 350ms because the tooltip only hides after 300ms... + QTest::qWait(350); + + bool foundView = false; + bool foundTipLabel = false; + foreach (QWidget *widget, QApplication::topLevelWidgets()) { + if (widget == &view) + foundView = true; + if (widget->inherits("QTipLabel") && widget->isVisible()) + foundTipLabel = true; + } + QVERIFY(foundView); + QVERIFY(!foundTipLabel); + } } void tst_QGraphicsProxyWidget::childPos_data() -- cgit v0.12 From 6a78005ed2e2d29225e322d53bb422438c8f9935 Mon Sep 17 00:00:00 2001 From: Sami Merila Date: Thu, 15 Apr 2010 13:34:18 +0300 Subject: Slider graphics does not look correct in N95 (part2) The original fix for this, only fixed horizontal widgets. But the same issue can be reproduced also with vertical widgets. This latter fix replaces the orginal fix. Task-number: QTBUG-9854 Reviewed-by: Alessandro Portale --- src/gui/styles/qs60style.cpp | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gui/styles/qs60style.cpp b/src/gui/styles/qs60style.cpp index 3259d82..7587343 100644 --- a/src/gui/styles/qs60style.cpp +++ b/src/gui/styles/qs60style.cpp @@ -548,11 +548,11 @@ void QS60StylePrivate::drawRow(QS60StyleEnums::SkinParts start, startEndSize.scale(rect.size(), Qt::KeepAspectRatio); QRect startRect = QRect(rect.topLeft(), startEndSize); - startRect.setHeight(rect.height()); QRect middleRect = rect; QRect endRect; if (orientation == Qt::Horizontal) { + startRect.setHeight(rect.height()); startRect.setWidth(qMin((rect.width() >> 1) - 1, startRect.width())); endRect = startRect.translated(rect.width() - startRect.width(), 0); middleRect.adjust(startRect.width(), 0, -startRect.width(), 0); @@ -562,6 +562,7 @@ void QS60StylePrivate::drawRow(QS60StyleEnums::SkinParts start, endRect.adjust(overlap, 0, 0, 0); } } else { + startRect.setWidth(rect.width()); startRect.setHeight(qMin((rect.height() >> 1) - 1, startRect.height())); endRect = startRect.translated(0, rect.height() - startRect.height()); middleRect.adjust(0, startRect.height(), 0, -startRect.height()); -- cgit v0.12 From 22df502bd5fcdb51bfcfa2e5d3f6fbf2d9fc3562 Mon Sep 17 00:00:00 2001 From: Sami Merila Date: Thu, 15 Apr 2010 13:37:40 +0300 Subject: Dialogs in landscape mode are not correctly positioned If AVKON is using a StaCon component (combined Status and Control Pane), then dialogs were incorrectly positioned. Native side, places dialogs shown with StaCon to right border, whereas the current implementation was placing them to left. Fixed, by asking from AVKON the rect for StaCon. If it is empty, then use the existing placement rules, otherwise place to the right border. Task-number: QTBUG-9910 Reviewed-by: Janne Anttila --- src/gui/dialogs/qdialog.cpp | 41 ++++++++++++++++++++++++----------------- 1 file changed, 24 insertions(+), 17 deletions(-) diff --git a/src/gui/dialogs/qdialog.cpp b/src/gui/dialogs/qdialog.cpp index 25ba016..8b40b52 100644 --- a/src/gui/dialogs/qdialog.cpp +++ b/src/gui/dialogs/qdialog.cpp @@ -904,26 +904,33 @@ bool QDialog::s60AdjustedPosition() } else { cbaHeight = qt_TSize2QSize(bgContainer->Size()).height(); } - p.setY(S60->screenHeightInPixels-height()-cbaHeight); + p.setY(S60->screenHeightInPixels - height() - cbaHeight); p.setX(0); } else { const int scrollbarWidth = style()->pixelMetric(QStyle::PM_ScrollBarExtent); - TRect cbaRect = TRect(); - AknLayoutUtils::LayoutMetricsRect(AknLayoutUtils::EControlPane, cbaRect); - AknLayoutUtils::TAknCbaLocation cbaLocation = AknLayoutUtils::CbaLocation(); - switch (cbaLocation) { - case AknLayoutUtils::EAknCbaLocationBottom: - p.setY(S60->screenHeightInPixels - height()-cbaRect.Height()); - p.setX((S60->screenWidthInPixels - width())>>1); - break; - case AknLayoutUtils::EAknCbaLocationRight: - p.setY((S60->screenHeightInPixels - height())>>1); - p.setX(qMax(0,S60->screenWidthInPixels-width()-scrollbarWidth-cbaRect.Width())); - break; - case AknLayoutUtils::EAknCbaLocationLeft: - p.setY((S60->screenHeightInPixels - height())>>1); - p.setX(qMax(0,scrollbarWidth+cbaRect.Width())); - break; + TRect staConTopRect = TRect(); + AknLayoutUtils::LayoutMetricsRect(AknLayoutUtils::EStaconTop, staConTopRect); + if (staConTopRect.IsEmpty()) { + TRect cbaRect = TRect(); + AknLayoutUtils::LayoutMetricsRect(AknLayoutUtils::EControlPane, cbaRect); + AknLayoutUtils::TAknCbaLocation cbaLocation = AknLayoutUtils::CbaLocation(); + switch (cbaLocation) { + case AknLayoutUtils::EAknCbaLocationBottom: + p.setY(S60->screenHeightInPixels - height() - cbaRect.Height()); + p.setX((S60->screenWidthInPixels - width()) >> 1); + break; + case AknLayoutUtils::EAknCbaLocationRight: + p.setY((S60->screenHeightInPixels - height()) >> 1); + p.setX(qMax(0,S60->screenWidthInPixels - width() - scrollbarWidth - cbaRect.Width())); + break; + case AknLayoutUtils::EAknCbaLocationLeft: + p.setY((S60->screenHeightInPixels - height()) >> 1); + p.setX(qMax(0,scrollbarWidth + cbaRect.Width())); + break; + } + } else { + p.setY((S60->screenHeightInPixels - height()) >> 1); + p.setX(qMax(0,S60->screenWidthInPixels - width())); } } move(p); -- cgit v0.12 From a0b2992fe166bed4020e14fca9742ca3a7c9ae9e Mon Sep 17 00:00:00 2001 From: Sami Merila Date: Thu, 15 Apr 2010 14:53:24 +0300 Subject: ComboBox popuplist is not correctly layouted in fullscreen mode This is partial fix to issue 9913. Now combobox popup is correctly positioned with AVKON StaCon (Combined Status and Control Pane). Popup is centered onscreen in this case. Task-number: QTBUG-9913 Reviewed-by: Janne Anttila --- src/gui/widgets/qcombobox.cpp | 28 +++++++++++++++++++++------- 1 file changed, 21 insertions(+), 7 deletions(-) diff --git a/src/gui/widgets/qcombobox.cpp b/src/gui/widgets/qcombobox.cpp index 7d02e14..12b1c4a 100644 --- a/src/gui/widgets/qcombobox.cpp +++ b/src/gui/widgets/qcombobox.cpp @@ -76,6 +76,10 @@ #ifndef QT_NO_EFFECTS # include #endif +#if defined(Q_WS_S60) +#include "private/qt_s60_p.h" +#endif + QT_BEGIN_NAMESPACE QComboBoxPrivate::QComboBoxPrivate() @@ -2449,11 +2453,16 @@ void QComboBox::showPopup() // in portait, menu should be positioned above softkeys listRect.moveBottom(screen.bottom()); } else { - // landscape, menu should be at the right and horizontally centered + TRect staConTopRect = TRect(); + AknLayoutUtils::LayoutMetricsRect(AknLayoutUtils::EStaconTop, staConTopRect); listRect.setWidth(listRect.height()); + //by default popup is centered on screen in landscape listRect.moveCenter(screen.center()); - (opt.direction == Qt::LeftToRight) ? listRect.setRight(screen.right()) : - listRect.setLeft(screen.left()); + if (staConTopRect.IsEmpty()) { + // landscape without stacon, menu should be at the right + (opt.direction == Qt::LeftToRight) ? listRect.setRight(screen.right()) : + listRect.setLeft(screen.left()); + } } #endif } else if (!boundToScreen || listRect.height() <= belowHeight) { @@ -2681,13 +2690,18 @@ void QComboBox::changeEvent(QEvent *e) // in portait, menu should be positioned above softkeys listRect.moveBottom(screen.bottom()); } else { - // landscape, menu should be at the right and horizontally centered + TRect staConTopRect = TRect(); + AknLayoutUtils::LayoutMetricsRect(AknLayoutUtils::EStaconTop, staConTopRect); listRect.setWidth(listRect.height()); + //by default popup is centered on screen in landscape listRect.moveCenter(screen.center()); - (opt.direction == Qt::LeftToRight) ? listRect.setRight(screen.right()) : - listRect.setLeft(screen.left()); + if (staConTopRect.IsEmpty()) { + // landscape without stacon, menu should be at the right + (opt.direction == Qt::LeftToRight) ? listRect.setRight(screen.right()) : + listRect.setLeft(screen.left()); + } + d->container->setGeometry(listRect); } - d->container->setGeometry(listRect); } } #endif -- cgit v0.12 From 3fdf7e7a120b72819c5a0997ddb65951d4889813 Mon Sep 17 00:00:00 2001 From: Sami Merila Date: Thu, 15 Apr 2010 15:21:17 +0300 Subject: '#' gets inserted to editor when changing FEP modes This is regression in QCoeFepInputContext::commitCurrentString. Recent member variable removal broke the existing functionality. Fixed by removing the orphaned return-statement. Task-number: QTBUG-9867 Reviewed-by: Alessandro Portale --- src/gui/inputmethod/qcoefepinputcontext_s60.cpp | 1 - 1 file changed, 1 deletion(-) diff --git a/src/gui/inputmethod/qcoefepinputcontext_s60.cpp b/src/gui/inputmethod/qcoefepinputcontext_s60.cpp index 94036d0..b42e0ab 100644 --- a/src/gui/inputmethod/qcoefepinputcontext_s60.cpp +++ b/src/gui/inputmethod/qcoefepinputcontext_s60.cpp @@ -782,7 +782,6 @@ void QCoeFepInputContext::commitCurrentString(bool cancelFepTransaction) if (w->inputMethodQuery(Qt::ImCursorPosition).toInt() != m_cursorPos) longPress = 1; } - return; } QList attributes; -- cgit v0.12 From 0a93295aba1f5e80a03b095df68f22d0a805922f Mon Sep 17 00:00:00 2001 From: Markus Goetz Date: Thu, 15 Apr 2010 13:54:30 +0200 Subject: QNAM HTTP: Pipelining changes Re-wrote some code to improve pipelining efficiency. Greatly helps with combining into one TCP packet. Task-number: QTBUG-9894 Task-number: QT-3280 Reviewed-by: Peter Hartmann --- src/network/access/qhttpnetworkconnection.cpp | 94 +++++++++++++--------- src/network/access/qhttpnetworkconnection_p.h | 1 + .../access/qhttpnetworkconnectionchannel.cpp | 7 +- .../tst_qhttpnetworkconnection.cpp | 2 +- 4 files changed, 61 insertions(+), 43 deletions(-) diff --git a/src/network/access/qhttpnetworkconnection.cpp b/src/network/access/qhttpnetworkconnection.cpp index a887449..a6322a3 100644 --- a/src/network/access/qhttpnetworkconnection.cpp +++ b/src/network/access/qhttpnetworkconnection.cpp @@ -71,9 +71,11 @@ const int QHttpNetworkConnectionPrivate::defaultChannelCount = 3; const int QHttpNetworkConnectionPrivate::defaultChannelCount = 6; #endif -// the maximum amount of requests that might be pipelined into a socket -// from what was suggested, 3 seems to be OK +// The pipeline length. So there will be 4 requests in flight. const int QHttpNetworkConnectionPrivate::defaultPipelineLength = 3; +// Only re-fill the pipeline if there's defaultRePipelineLength slots free in the pipeline. +// This means that there are 2 requests in flight and 2 slots free that will be re-filled. +const int QHttpNetworkConnectionPrivate::defaultRePipelineLength = 2; QHttpNetworkConnectionPrivate::QHttpNetworkConnectionPrivate(const QString &hostName, quint16 port, bool encrypt) @@ -487,54 +489,68 @@ void QHttpNetworkConnectionPrivate::fillPipeline(QAbstractSocket *socket) int i = indexOf(socket); - bool highPriorityQueueProcessingDone = false; - bool lowPriorityQueueProcessingDone = false; + if (! (defaultPipelineLength - channels[i].alreadyPipelinedRequests.length() >= 2)) { + return; + } - while (!highPriorityQueueProcessingDone && !lowPriorityQueueProcessingDone) { - // this loop runs once per request we intend to pipeline in. + if (channels[i].pipeliningSupported != QHttpNetworkConnectionChannel::PipeliningProbablySupported) + return; - if (channels[i].pipeliningSupported != QHttpNetworkConnectionChannel::PipeliningProbablySupported) - return; + // the current request that is in must already support pipelining + if (!channels[i].request.isPipeliningAllowed()) + return; - // the current request that is in must already support pipelining - if (!channels[i].request.isPipeliningAllowed()) - return; + // the current request must be a idempotent (right now we only check GET) + if (channels[i].request.operation() != QHttpNetworkRequest::Get) + return; - // the current request must be a idempotent (right now we only check GET) - if (channels[i].request.operation() != QHttpNetworkRequest::Get) - return; + // check if socket is connected + if (socket->state() != QAbstractSocket::ConnectedState) + return; - // check if socket is connected - if (socket->state() != QAbstractSocket::ConnectedState) - return; + // check for resendCurrent + if (channels[i].resendCurrent) + return; - // check for resendCurrent - if (channels[i].resendCurrent) - return; + // we do not like authentication stuff + // ### make sure to be OK with this in later releases + if (!channels[i].authenticator.isNull() || !channels[i].authenticator.user().isEmpty()) + return; + if (!channels[i].proxyAuthenticator.isNull() || !channels[i].proxyAuthenticator.user().isEmpty()) + return; + + // must be in ReadingState or WaitingState + if (! (channels[i].state == QHttpNetworkConnectionChannel::WaitingState + || channels[i].state == QHttpNetworkConnectionChannel::ReadingState)) + return; - // we do not like authentication stuff - // ### make sure to be OK with this in later releases - if (!channels[i].authenticator.isNull() || !channels[i].authenticator.user().isEmpty()) - return; - if (!channels[i].proxyAuthenticator.isNull() || !channels[i].proxyAuthenticator.user().isEmpty()) - return; - // check for pipeline length + //qDebug() << "QHttpNetworkConnectionPrivate::fillPipeline processing highPriorityQueue, size=" << highPriorityQueue.size() << " alreadyPipelined=" << channels[i].alreadyPipelinedRequests.length(); + int lengthBefore; + while (!highPriorityQueue.isEmpty()) { + lengthBefore = channels[i].alreadyPipelinedRequests.length(); + fillPipeline(highPriorityQueue, channels[i]); + if (channels[i].alreadyPipelinedRequests.length() >= defaultPipelineLength) return; - // must be in ReadingState or WaitingState - if (! (channels[i].state == QHttpNetworkConnectionChannel::WaitingState - || channels[i].state == QHttpNetworkConnectionChannel::ReadingState)) + if (lengthBefore == channels[i].alreadyPipelinedRequests.length()) + break; // did not process anything, now do the low prio queue + } + + //qDebug() << "QHttpNetworkConnectionPrivate::fillPipeline processing lowPriorityQueue, size=" << lowPriorityQueue.size() << " alreadyPipelined=" << channels[i].alreadyPipelinedRequests.length(); + while (!lowPriorityQueue.isEmpty()) { + lengthBefore = channels[i].alreadyPipelinedRequests.length(); + fillPipeline(lowPriorityQueue, channels[i]); + + if (channels[i].alreadyPipelinedRequests.length() >= defaultPipelineLength) return; - highPriorityQueueProcessingDone = fillPipeline(highPriorityQueue, channels[i]); - // not finished with highPriorityQueue? then loop again - if (!highPriorityQueueProcessingDone) - continue; - // highPriorityQueue was processed, now deal with the lowPriorityQueue - lowPriorityQueueProcessingDone = fillPipeline(lowPriorityQueue, channels[i]); + if (lengthBefore == channels[i].alreadyPipelinedRequests.length()) + break; // did not process anything } + + } // returns true when the processing of a queue has been done @@ -707,7 +723,6 @@ void QHttpNetworkConnectionPrivate::_q_startNextRequest() // if this is not possible, error will be emitted and connection terminated if (!channels[i].resetUploadData()) continue; - channels[i].sendRequest(); } } @@ -747,8 +762,9 @@ void QHttpNetworkConnectionPrivate::_q_startNextRequest() // return fast if there is nothing to pipeline if (highPriorityQueue.isEmpty() && lowPriorityQueue.isEmpty()) return; - for (int j = 0; j < channelCount; j++) - fillPipeline(channels[j].socket); + for (int i = 0; i < channelCount; i++) + if (channels[i].socket->state() == QAbstractSocket::ConnectedState) + fillPipeline(channels[i].socket); } void QHttpNetworkConnectionPrivate::_q_restartAuthPendingRequests() diff --git a/src/network/access/qhttpnetworkconnection_p.h b/src/network/access/qhttpnetworkconnection_p.h index 823774e..b5bd300 100644 --- a/src/network/access/qhttpnetworkconnection_p.h +++ b/src/network/access/qhttpnetworkconnection_p.h @@ -156,6 +156,7 @@ class QHttpNetworkConnectionPrivate : public QObjectPrivate public: static const int defaultChannelCount; static const int defaultPipelineLength; + static const int defaultRePipelineLength; QHttpNetworkConnectionPrivate(const QString &hostName, quint16 port, bool encrypt); QHttpNetworkConnectionPrivate(quint16 channelCount, const QString &hostName, quint16 port, bool encrypt); diff --git a/src/network/access/qhttpnetworkconnectionchannel.cpp b/src/network/access/qhttpnetworkconnectionchannel.cpp index 83b7d4c..4c3dbe2 100644 --- a/src/network/access/qhttpnetworkconnectionchannel.cpp +++ b/src/network/access/qhttpnetworkconnectionchannel.cpp @@ -285,8 +285,8 @@ bool QHttpNetworkConnectionChannel::sendRequest() } // HTTP pipelining - connection->d_func()->fillPipeline(socket); - socket->flush(); + //connection->d_func()->fillPipeline(socket); + //socket->flush(); // ensure we try to receive a reply in all cases, even if _q_readyRead_ hat not been called // this is needed if the sends an reply before we have finished sending the request. In that @@ -661,7 +661,8 @@ void QHttpNetworkConnectionChannel::allDone() connection->d_func()->fillPipeline(socket); // continue reading - _q_receiveReply(); + //_q_receiveReply(); + // this was wrong, allDone gets called from that function anyway. } } else if (alreadyPipelinedRequests.isEmpty() && socket->bytesAvailable() > 0) { eatWhitespace(); diff --git a/tests/auto/qhttpnetworkconnection/tst_qhttpnetworkconnection.cpp b/tests/auto/qhttpnetworkconnection/tst_qhttpnetworkconnection.cpp index 35ebbd9..0b55390 100644 --- a/tests/auto/qhttpnetworkconnection/tst_qhttpnetworkconnection.cpp +++ b/tests/auto/qhttpnetworkconnection/tst_qhttpnetworkconnection.cpp @@ -801,7 +801,7 @@ void tst_QHttpNetworkConnection::getMultiple_data() QTest::newRow("6 connections, no pipelining, 100 requests") << quint16(6) << false << 100; QTest::newRow("1 connection, no pipelining, 100 requests") << quint16(1) << false << 100; - QTest::newRow("6 connections, pipelining allowed, 100 requests") << quint16(2) << true << 100; + QTest::newRow("6 connections, pipelining allowed, 100 requests") << quint16(6) << true << 100; QTest::newRow("1 connection, pipelining allowed, 100 requests") << quint16(1) << true << 100; } -- cgit v0.12 From 0caad7dc081812fcc056d917288757b2e475ea05 Mon Sep 17 00:00:00 2001 From: Yoann Lopes Date: Thu, 15 Apr 2010 15:55:13 +0200 Subject: Fixes auto-test failure for 9da13ea53aec6d841ba7f416531d6c52d4368df4. --- .../qgraphicsproxywidget/tst_qgraphicsproxywidget.cpp | 19 ------------------- 1 file changed, 19 deletions(-) diff --git a/tests/auto/qgraphicsproxywidget/tst_qgraphicsproxywidget.cpp b/tests/auto/qgraphicsproxywidget/tst_qgraphicsproxywidget.cpp index a5a039a..d5f63d3 100644 --- a/tests/auto/qgraphicsproxywidget/tst_qgraphicsproxywidget.cpp +++ b/tests/auto/qgraphicsproxywidget/tst_qgraphicsproxywidget.cpp @@ -2645,25 +2645,6 @@ void tst_QGraphicsProxyWidget::tooltip_basic() QVERIFY(foundView); QVERIFY(foundTipLabel); } - - { - QHelpEvent helpEvent(QEvent::ToolTip, view.viewport()->rect().topLeft(), - view.viewport()->mapToGlobal(view.viewport()->rect().topLeft())); - QApplication::sendEvent(view.viewport(), &helpEvent); - // Wait 350ms because the tooltip only hides after 300ms... - QTest::qWait(350); - - bool foundView = false; - bool foundTipLabel = false; - foreach (QWidget *widget, QApplication::topLevelWidgets()) { - if (widget == &view) - foundView = true; - if (widget->inherits("QTipLabel") && widget->isVisible()) - foundTipLabel = true; - } - QVERIFY(foundView); - QVERIFY(!foundTipLabel); - } } void tst_QGraphicsProxyWidget::childPos_data() -- cgit v0.12 From a7ded5708ce81a37404cc0db8de84521c2aa693d Mon Sep 17 00:00:00 2001 From: Iain Date: Thu, 15 Apr 2010 16:19:50 +0200 Subject: Symbol visibility fixes for RVCT4 on Symbian RVCT 4 is far more strict with regards to symbol visiblity that RVCT 2.2, and will hide symbols unless all references have default visibility in the object files. Update the various places in Qt code where the symbol visibility was set incorrectly for DLL-based platforms (those that use __declspec(dllimport) and (dllexport). Note: QtWebkit and QtScript are fixed in different commits. Task-number: QTBUG-9903 Reviewed-by: Jason Barron --- src/gui/graphicsview/qgraphicsproxywidget.cpp | 2 +- src/gui/image/qimage.cpp | 4 ++-- src/gui/image/qpaintengine_pic.cpp | 2 +- src/gui/image/qpicture.cpp | 4 ++-- src/gui/image/qpixmap_raster.cpp | 4 ++-- src/gui/image/qpixmapfilter.cpp | 2 +- src/gui/kernel/qapplication.cpp | 2 +- src/gui/kernel/qwhatsthis.cpp | 2 +- src/gui/painting/qbrush.cpp | 3 +-- src/gui/painting/qpaintbuffer.cpp | 4 ++-- src/gui/painting/qpaintengine_alpha.cpp | 4 ++-- src/gui/painting/qpaintengine_raster.cpp | 4 ++-- src/gui/painting/qpaintengineex.cpp | 2 +- src/gui/painting/qpdf.cpp | 2 +- src/gui/painting/qstroker.cpp | 2 +- src/gui/text/qfontdatabase.cpp | 2 +- src/gui/text/qfontmetrics.cpp | 2 +- src/gui/text/qtextdocument.cpp | 2 +- src/gui/text/qtextdocumentlayout.cpp | 2 +- src/gui/text/qtextengine.cpp | 4 ++-- src/gui/text/qtextimagehandler.cpp | 2 +- src/gui/widgets/qabstractbutton.cpp | 2 +- src/openvg/qpaintengine_vg.cpp | 8 ++++---- src/openvg/qpixmapdata_vg.cpp | 4 ++-- src/svg/qsvghandler.cpp | 2 +- src/xmlpatterns/data/qdecimal_p.h | 2 +- 26 files changed, 37 insertions(+), 38 deletions(-) diff --git a/src/gui/graphicsview/qgraphicsproxywidget.cpp b/src/gui/graphicsview/qgraphicsproxywidget.cpp index 2132526..75007e6 100644 --- a/src/gui/graphicsview/qgraphicsproxywidget.cpp +++ b/src/gui/graphicsview/qgraphicsproxywidget.cpp @@ -189,7 +189,7 @@ QT_BEGIN_NAMESPACE */ extern bool qt_sendSpontaneousEvent(QObject *, QEvent *); -extern bool qt_tab_all_widgets; +Q_GUI_EXPORT extern bool qt_tab_all_widgets; /*! \internal diff --git a/src/gui/image/qimage.cpp b/src/gui/image/qimage.cpp index 5d2b4c0..d46f40e 100644 --- a/src/gui/image/qimage.cpp +++ b/src/gui/image/qimage.cpp @@ -118,8 +118,8 @@ const QVector *qt_image_colortable(const QImage &image) return &image.d->colortable; } -extern int qt_defaultDpiX(); -extern int qt_defaultDpiY(); +Q_GUI_EXPORT extern int qt_defaultDpiX(); +Q_GUI_EXPORT extern int qt_defaultDpiY(); QBasicAtomicInt qimage_serial_number = Q_BASIC_ATOMIC_INITIALIZER(1); diff --git a/src/gui/image/qpaintengine_pic.cpp b/src/gui/image/qpaintengine_pic.cpp index 1aeb524..e7f41e7 100644 --- a/src/gui/image/qpaintengine_pic.cpp +++ b/src/gui/image/qpaintengine_pic.cpp @@ -477,7 +477,7 @@ void QPicturePaintEngine::drawImage(const QRectF &r, const QImage &image, const writeCmdLength(pos, r, false); } -extern int qt_defaultDpi(); +Q_GUI_EXPORT extern int qt_defaultDpi(); void QPicturePaintEngine::drawTextItem(const QPointF &p , const QTextItem &ti) { diff --git a/src/gui/image/qpicture.cpp b/src/gui/image/qpicture.cpp index fb70e36..48d2de3 100644 --- a/src/gui/image/qpicture.cpp +++ b/src/gui/image/qpicture.cpp @@ -108,8 +108,8 @@ void qt_format_text(const QFont &fnt, const QRectF &_r, const char *qt_mfhdr_tag = "QPIC"; // header tag static const quint16 mfhdr_maj = 11; // major version # static const quint16 mfhdr_min = 0; // minor version # -extern int qt_defaultDpiX(); -extern int qt_defaultDpiY(); +Q_GUI_EXPORT extern int qt_defaultDpiX(); +Q_GUI_EXPORT extern int qt_defaultDpiY(); /*! Constructs an empty picture. diff --git a/src/gui/image/qpixmap_raster.cpp b/src/gui/image/qpixmap_raster.cpp index 0b1c18d..a440dcc 100644 --- a/src/gui/image/qpixmap_raster.cpp +++ b/src/gui/image/qpixmap_raster.cpp @@ -357,8 +357,8 @@ QPaintEngine* QRasterPixmapData::paintEngine() const return image.paintEngine(); } -extern int qt_defaultDpiX(); -extern int qt_defaultDpiY(); +Q_GUI_EXPORT extern int qt_defaultDpiX(); +Q_GUI_EXPORT extern int qt_defaultDpiY(); int QRasterPixmapData::metric(QPaintDevice::PaintDeviceMetric metric) const { diff --git a/src/gui/image/qpixmapfilter.cpp b/src/gui/image/qpixmapfilter.cpp index c605880..664d5d5 100644 --- a/src/gui/image/qpixmapfilter.cpp +++ b/src/gui/image/qpixmapfilter.cpp @@ -898,7 +898,7 @@ Q_GUI_EXPORT void qt_blurImage(QImage &blurImage, qreal radius, bool quality, in expblur<12, 10, false>(blurImage, radius, quality, transposed); } -bool qt_scaleForTransform(const QTransform &transform, qreal *scale); +Q_GUI_EXPORT bool qt_scaleForTransform(const QTransform &transform, qreal *scale); /*! \internal diff --git a/src/gui/kernel/qapplication.cpp b/src/gui/kernel/qapplication.cpp index e480696..de74f53 100644 --- a/src/gui/kernel/qapplication.cpp +++ b/src/gui/kernel/qapplication.cpp @@ -138,7 +138,7 @@ static void initResources() QT_BEGIN_NAMESPACE -extern void qt_call_post_routines(); +Q_DECL_IMPORT extern void qt_call_post_routines(); int QApplicationPrivate::app_compile_version = 0x040000; //we don't know exactly, but it's at least 4.0.0 diff --git a/src/gui/kernel/qwhatsthis.cpp b/src/gui/kernel/qwhatsthis.cpp index b877784..6181b62 100644 --- a/src/gui/kernel/qwhatsthis.cpp +++ b/src/gui/kernel/qwhatsthis.cpp @@ -143,7 +143,7 @@ QT_BEGIN_NAMESPACE \sa QToolTip */ -extern void qDeleteInEventHandler(QObject *o); +Q_DECL_IMPORT extern void qDeleteInEventHandler(QObject *o); class QWhatsThat : public QWidget { diff --git a/src/gui/painting/qbrush.cpp b/src/gui/painting/qbrush.cpp index fcfc44d..c0c73a2 100644 --- a/src/gui/painting/qbrush.cpp +++ b/src/gui/painting/qbrush.cpp @@ -160,8 +160,7 @@ static void qt_cleanup_brush_pattern_image_cache() qt_brushPatternImageCache()->cleanup(); } -Q_GUI_EXPORT -QImage qt_imageForBrush(int brushStyle, bool invert) +Q_GUI_EXPORT QImage qt_imageForBrush(int brushStyle, bool invert) { return qt_brushPatternImageCache()->getImage(brushStyle, invert); } diff --git a/src/gui/painting/qpaintbuffer.cpp b/src/gui/painting/qpaintbuffer.cpp index 2344c04..9fdb96c 100644 --- a/src/gui/painting/qpaintbuffer.cpp +++ b/src/gui/painting/qpaintbuffer.cpp @@ -52,8 +52,8 @@ QT_BEGIN_NAMESPACE -extern int qt_defaultDpiX(); -extern int qt_defaultDpiY(); +Q_GUI_EXPORT extern int qt_defaultDpiX(); +Q_GUI_EXPORT extern int qt_defaultDpiY(); extern void qt_format_text(const QFont &font, const QRectF &_r, int tf, const QTextOption *option, const QString& str, QRectF *brect, int tabstops, int* tabarray, int tabarraylen, diff --git a/src/gui/painting/qpaintengine_alpha.cpp b/src/gui/painting/qpaintengine_alpha.cpp index 5a3c0cf..4b1c58d 100644 --- a/src/gui/painting/qpaintengine_alpha.cpp +++ b/src/gui/painting/qpaintengine_alpha.cpp @@ -93,8 +93,8 @@ bool QAlphaPaintEngine::begin(QPaintDevice *pdev) return true; } -extern int qt_defaultDpiX(); -extern int qt_defaultDpiY(); +Q_GUI_EXPORT extern int qt_defaultDpiX(); +Q_GUI_EXPORT extern int qt_defaultDpiY(); bool QAlphaPaintEngine::end() { diff --git a/src/gui/painting/qpaintengine_raster.cpp b/src/gui/painting/qpaintengine_raster.cpp index 3c2cc8c..975ebb0 100644 --- a/src/gui/painting/qpaintengine_raster.cpp +++ b/src/gui/painting/qpaintengine_raster.cpp @@ -102,7 +102,7 @@ QT_BEGIN_NAMESPACE -extern bool qt_scaleForTransform(const QTransform &transform, qreal *scale); // qtransform.cpp +Q_GUI_EXPORT extern bool qt_scaleForTransform(const QTransform &transform, qreal *scale); // qtransform.cpp #define qreal_to_fixed_26_6(f) (int(f * 64)) #define qt_swap_int(x, y) { int tmp = (x); (x) = (y); (y) = tmp; } @@ -4977,7 +4977,7 @@ void QSpanData::init(QRasterBuffer *rb, const QRasterPaintEngine *pe) clip = pe ? pe->d_func()->clip() : 0; } -extern QImage qt_imageForBrush(int brushStyle, bool invert); +Q_GUI_EXPORT extern QImage qt_imageForBrush(int brushStyle, bool invert); void QSpanData::setup(const QBrush &brush, int alpha, QPainter::CompositionMode compositionMode) { diff --git a/src/gui/painting/qpaintengineex.cpp b/src/gui/painting/qpaintengineex.cpp index 4f2fffa..d54c1ed 100644 --- a/src/gui/painting/qpaintengineex.cpp +++ b/src/gui/painting/qpaintengineex.cpp @@ -380,7 +380,7 @@ QPainterState *QPaintEngineEx::createState(QPainterState *orig) const return new QPainterState(orig); } -extern bool qt_scaleForTransform(const QTransform &transform, qreal *scale); // qtransform.cpp +Q_GUI_EXPORT extern bool qt_scaleForTransform(const QTransform &transform, qreal *scale); // qtransform.cpp void QPaintEngineEx::stroke(const QVectorPath &path, const QPen &pen) { diff --git a/src/gui/painting/qpdf.cpp b/src/gui/painting/qpdf.cpp index dd516b1..ee8b078 100644 --- a/src/gui/painting/qpdf.cpp +++ b/src/gui/painting/qpdf.cpp @@ -54,7 +54,7 @@ QT_BEGIN_NAMESPACE -extern int qt_defaultDpi(); +Q_GUI_EXPORT extern int qt_defaultDpi(); #ifndef QT_NO_PRINTER diff --git a/src/gui/painting/qstroker.cpp b/src/gui/painting/qstroker.cpp index 16e3c38..094d42e 100644 --- a/src/gui/painting/qstroker.cpp +++ b/src/gui/painting/qstroker.cpp @@ -825,7 +825,7 @@ qreal qt_t_for_arc_angle(qreal angle) return t; } -void qt_find_ellipse_coords(const QRectF &r, qreal angle, qreal length, +Q_GUI_EXPORT void qt_find_ellipse_coords(const QRectF &r, qreal angle, qreal length, QPointF* startPoint, QPointF *endPoint); /*! diff --git a/src/gui/text/qfontdatabase.cpp b/src/gui/text/qfontdatabase.cpp index 6803120..ae5e9ca 100644 --- a/src/gui/text/qfontdatabase.cpp +++ b/src/gui/text/qfontdatabase.cpp @@ -83,7 +83,7 @@ QT_BEGIN_NAMESPACE #define SMOOTH_SCALABLE 0xffff -extern int qt_defaultDpiY(); // in qfont.cpp +Q_GUI_EXPORT extern int qt_defaultDpiY(); // in qfont.cpp bool qt_enable_test_font = false; diff --git a/src/gui/text/qfontmetrics.cpp b/src/gui/text/qfontmetrics.cpp index 44a18de..e455bb4 100644 --- a/src/gui/text/qfontmetrics.cpp +++ b/src/gui/text/qfontmetrics.cpp @@ -63,7 +63,7 @@ extern void qt_format_text(const QFont& font, const QRectF &_r, int tf, const QString &text, QRectF *brect, int tabStops, int *tabArray, int tabArrayLen, QPainter *painter); -extern int qt_defaultDpi(); +Q_GUI_EXPORT extern int qt_defaultDpi(); /***************************************************************************** QFontMetrics member functions diff --git a/src/gui/text/qtextdocument.cpp b/src/gui/text/qtextdocument.cpp index 21f3189..f5d322a 100644 --- a/src/gui/text/qtextdocument.cpp +++ b/src/gui/text/qtextdocument.cpp @@ -1631,7 +1631,7 @@ static void printPage(int index, QPainter *painter, const QTextDocument *doc, co painter->restore(); } -extern int qt_defaultDpi(); +Q_GUI_EXPORT extern int qt_defaultDpi(); /*! Prints the document to the given \a printer. The QPrinter must be diff --git a/src/gui/text/qtextdocumentlayout.cpp b/src/gui/text/qtextdocumentlayout.cpp index b45fcbb..f12bf0b 100644 --- a/src/gui/text/qtextdocumentlayout.cpp +++ b/src/gui/text/qtextdocumentlayout.cpp @@ -75,7 +75,7 @@ QT_BEGIN_NAMESPACE -extern int qt_defaultDpi(); +Q_GUI_EXPORT extern int qt_defaultDpi(); // ################ should probably add frameFormatChange notification! diff --git a/src/gui/text/qtextengine.cpp b/src/gui/text/qtextengine.cpp index eaa80d3..76eb340 100644 --- a/src/gui/text/qtextengine.cpp +++ b/src/gui/text/qtextengine.cpp @@ -856,7 +856,7 @@ void QTextEngine::shapeLine(const QScriptLine &line) } } -extern int qt_defaultDpiY(); // in qfont.cpp +Q_GUI_EXPORT extern int qt_defaultDpiY(); // in qfont.cpp void QTextEngine::shapeText(int item) const { @@ -2495,7 +2495,7 @@ void QTextEngine::splitItem(int item, int pos) const // qDebug("split at position %d itempos=%d", pos, item); } -extern int qt_defaultDpiY(); +Q_GUI_EXPORT extern int qt_defaultDpiY(); QFixed QTextEngine::calculateTabWidth(int item, QFixed x) const { diff --git a/src/gui/text/qtextimagehandler.cpp b/src/gui/text/qtextimagehandler.cpp index fa49a32..6733793 100644 --- a/src/gui/text/qtextimagehandler.cpp +++ b/src/gui/text/qtextimagehandler.cpp @@ -123,7 +123,7 @@ static QSize getPixmapSize(QTextDocument *doc, const QTextImageFormat &format) qreal scale = 1.0; QPaintDevice *pdev = doc->documentLayout()->paintDevice(); if (pdev) { - extern int qt_defaultDpi(); + Q_GUI_EXPORT extern int qt_defaultDpi(); if (pm.isNull()) pm = getPixmap(doc, format); if (!pm.isNull()) diff --git a/src/gui/widgets/qabstractbutton.cpp b/src/gui/widgets/qabstractbutton.cpp index 5ceb237..995d659 100644 --- a/src/gui/widgets/qabstractbutton.cpp +++ b/src/gui/widgets/qabstractbutton.cpp @@ -57,7 +57,7 @@ QT_BEGIN_NAMESPACE #define AUTO_REPEAT_DELAY 300 #define AUTO_REPEAT_INTERVAL 100 -extern bool qt_tab_all_widgets; +Q_GUI_EXPORT extern bool qt_tab_all_widgets; /*! \class QAbstractButton diff --git a/src/openvg/qpaintengine_vg.cpp b/src/openvg/qpaintengine_vg.cpp index ebf34f5..96e0e86 100644 --- a/src/openvg/qpaintengine_vg.cpp +++ b/src/openvg/qpaintengine_vg.cpp @@ -75,8 +75,8 @@ QT_BEGIN_NAMESPACE #if !defined(QVG_NO_DRAW_GLYPHS) -extern int qt_defaultDpiX(); -extern int qt_defaultDpiY(); +Q_DECL_IMPORT extern int qt_defaultDpiX(); +Q_DECL_IMPORT extern int qt_defaultDpiY(); class QVGPaintEnginePrivate; @@ -497,7 +497,7 @@ void QVGPaintEnginePrivate::setTransform vgLoadMatrix(mat); } -extern bool qt_scaleForTransform(const QTransform &transform, qreal *scale); +Q_DECL_IMPORT extern bool qt_scaleForTransform(const QTransform &transform, qreal *scale); void QVGPaintEnginePrivate::updateTransform(QPaintDevice *pdev) { @@ -975,7 +975,7 @@ VGPath QVGPaintEnginePrivate::roundedRectPath(const QRectF &rect, qreal xRadius, return vgpath; } -extern QImage qt_imageForBrush(int style, bool invert); +Q_DECL_IMPORT extern QImage qt_imageForBrush(int style, bool invert); static QImage colorizeBitmap(const QImage &image, const QColor &color) { diff --git a/src/openvg/qpixmapdata_vg.cpp b/src/openvg/qpixmapdata_vg.cpp index 7efec2b..39c83d3 100644 --- a/src/openvg/qpixmapdata_vg.cpp +++ b/src/openvg/qpixmapdata_vg.cpp @@ -354,8 +354,8 @@ void QVGPixmapData::reclaimImages() destroyImages(); } -extern int qt_defaultDpiX(); -extern int qt_defaultDpiY(); +Q_DECL_IMPORT extern int qt_defaultDpiX(); +Q_DECL_IMPORT extern int qt_defaultDpiY(); int QVGPixmapData::metric(QPaintDevice::PaintDeviceMetric metric) const { diff --git a/src/svg/qsvghandler.cpp b/src/svg/qsvghandler.cpp index 926b04d..4cc8f41 100644 --- a/src/svg/qsvghandler.cpp +++ b/src/svg/qsvghandler.cpp @@ -74,7 +74,7 @@ QT_BEGIN_NAMESPACE static const char *qt_inherit_text = "inherit"; #define QT_INHERIT QLatin1String(qt_inherit_text) -double qstrtod(const char *s00, char const **se, bool *ok); +Q_DECL_IMPORT double qstrtod(const char *s00, char const **se, bool *ok); // ======== duplicated from qcolor_p diff --git a/src/xmlpatterns/data/qdecimal_p.h b/src/xmlpatterns/data/qdecimal_p.h index b746ff9..d17b647 100644 --- a/src/xmlpatterns/data/qdecimal_p.h +++ b/src/xmlpatterns/data/qdecimal_p.h @@ -61,7 +61,7 @@ QT_BEGIN_NAMESPACE /** * Defined in QtCore's qlocale.cpp. */ -extern char *qdtoa(double d, int mode, int ndigits, int *decpt, int *sign, char **rve, char **resultp); +Q_DECL_IMPORT extern char *qdtoa(double d, int mode, int ndigits, int *decpt, int *sign, char **rve, char **resultp); namespace QPatternist { -- cgit v0.12 From b2271d364cdc26187e5f9113f4c1816f334e37a1 Mon Sep 17 00:00:00 2001 From: Iain Date: Thu, 15 Apr 2010 16:38:02 +0200 Subject: Symbol visibility fixes for RVCT4 on Symbian RVCT 4 is far more strict with regards to symbol visiblity that RVCT 2.2, and will hide symbols unless all references have default visibility in the object files. Update the various places in Qt code where the symbol visibility was set incorrectly for DLL-based platforms (those that use __declspec(dllimport) and (dllexport). Note: QtWebkit and other Qt modules are fixed in different commits. Task-number: QTBUG-9903 Reviewed-by: Jason Barron --- src/script/api/qscriptengine.cpp | 2 +- src/script/parser/qscriptlexer.cpp | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/script/api/qscriptengine.cpp b/src/script/api/qscriptengine.cpp index 9ce0f7d..f44f33d 100644 --- a/src/script/api/qscriptengine.cpp +++ b/src/script/api/qscriptengine.cpp @@ -1603,7 +1603,7 @@ QScriptValue QScriptEngine::newFunction(QScriptEngine::FunctionSignature fun, #ifndef QT_NO_REGEXP -extern QString qt_regexp_toCanonical(const QString &, QRegExp::PatternSyntax); +Q_DECL_IMPORT extern QString qt_regexp_toCanonical(const QString &, QRegExp::PatternSyntax); /*! Creates a QtScript object of class RegExp with the given diff --git a/src/script/parser/qscriptlexer.cpp b/src/script/parser/qscriptlexer.cpp index 38ad6ce..ca64776 100644 --- a/src/script/parser/qscriptlexer.cpp +++ b/src/script/parser/qscriptlexer.cpp @@ -31,7 +31,7 @@ QT_BEGIN_NAMESPACE -extern double qstrtod(const char *s00, char const **se, bool *ok); +Q_DECL_IMPORT extern double qstrtod(const char *s00, char const **se, bool *ok); #define shiftWindowsLineBreak() \ do { \ -- cgit v0.12 From 81837e43e3f966c1755e90eb65df6e3bad506ed7 Mon Sep 17 00:00:00 2001 From: Iain Date: Thu, 15 Apr 2010 16:41:58 +0200 Subject: Symbol visibility fixes for RVCT4 on Symbian RVCT 4 is far more strict with regards to symbol visiblity that RVCT 2.2, and will hide symbols unless all references have default visibility in the object files. Update the various places in Qt code where the symbol visibility was set incorrectly for DLL-based platforms (those that use __declspec(dllimport) and (dllexport). Note: Other Qt modules and QtScript are fixed in different commits. Task-number: QTBUG-9903 Reviewed-by: Jason Barron Janne Koskinen --- src/3rdparty/webkit/WebCore/page/qt/EventHandlerQt.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/3rdparty/webkit/WebCore/page/qt/EventHandlerQt.cpp b/src/3rdparty/webkit/WebCore/page/qt/EventHandlerQt.cpp index 3425289..7563459 100644 --- a/src/3rdparty/webkit/WebCore/page/qt/EventHandlerQt.cpp +++ b/src/3rdparty/webkit/WebCore/page/qt/EventHandlerQt.cpp @@ -51,7 +51,7 @@ #include "NotImplemented.h" QT_BEGIN_NAMESPACE -extern Q_GUI_EXPORT bool qt_tab_all_widgets; // from qapplication.cpp +Q_DECL_IMPORT extern bool qt_tab_all_widgets; // from qapplication.cpp QT_END_NAMESPACE namespace WebCore { -- cgit v0.12 From 45ec585b46dc71de8a72e3bbc2401f50a2a42a8b Mon Sep 17 00:00:00 2001 From: Kent Hansen Date: Thu, 15 Apr 2010 17:13:50 +0200 Subject: QtScript: Add autotest for enumeration of QMetaObject properties The issue reported in QTBUG-3665 had been fixed since 4.6.0, but it went unnoticed that there had been a bug in the first place since there was no test for this behavior. --- .../qscriptextqobject/tst_qscriptextqobject.cpp | 34 ++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/tests/auto/qscriptextqobject/tst_qscriptextqobject.cpp b/tests/auto/qscriptextqobject/tst_qscriptextqobject.cpp index b4ce561..fddab3f 100644 --- a/tests/auto/qscriptextqobject/tst_qscriptextqobject.cpp +++ b/tests/auto/qscriptextqobject/tst_qscriptextqobject.cpp @@ -533,6 +533,7 @@ private slots: void objectDeleted(); void connectToDestroyedSignal(); void emitAfterReceiverDeleted(); + void enumerateMetaObject(); private: QScriptEngine *m_engine; @@ -3043,5 +3044,38 @@ void tst_QScriptExtQObject::emitAfterReceiverDeleted() } } +void tst_QScriptExtQObject::enumerateMetaObject() +{ + QScriptValue myClass = m_engine->newQMetaObject(m_myObject->metaObject(), m_engine->undefinedValue()); + + QStringList expectedNames; + expectedNames << "FooPolicy" << "BarPolicy" << "BazPolicy" + << "FooStrategy" << "BarStrategy" << "BazStrategy" + << "NoAbility" << "FooAbility" << "BarAbility" << "BazAbility" << "AllAbility"; + + for (int x = 0; x < 2; ++x) { + QSet actualNames; + if (x == 0) { + // From C++ + QScriptValueIterator it(myClass); + while (it.hasNext()) { + it.next(); + actualNames.insert(it.name()); + } + } else { + // From JS + m_engine->globalObject().setProperty("MyClass", myClass); + QScriptValue ret = m_engine->evaluate("a=[]; for (var p in MyClass) if (MyClass.hasOwnProperty(p)) a.push(p); a"); + QVERIFY(ret.isArray()); + QStringList strings = qscriptvalue_cast(ret); + for (int i = 0; i < strings.size(); ++i) + actualNames.insert(strings.at(i)); + } + QCOMPARE(actualNames.size(), expectedNames.size()); + for (int i = 0; i < expectedNames.size(); ++i) + QVERIFY(actualNames.contains(expectedNames.at(i))); + } +} + QTEST_MAIN(tst_QScriptExtQObject) #include "tst_qscriptextqobject.moc" -- cgit v0.12 From f62d8eb38d35d394aca01f9ec309a43525afb557 Mon Sep 17 00:00:00 2001 From: Kent Hansen Date: Thu, 15 Apr 2010 17:22:27 +0200 Subject: Add translation context to qsTr() benchmark That's a more realistic case, since translations are usually tied to a physical script. --- tests/benchmarks/script/qscriptengine/tst_qscriptengine.cpp | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/tests/benchmarks/script/qscriptengine/tst_qscriptengine.cpp b/tests/benchmarks/script/qscriptengine/tst_qscriptengine.cpp index 6c6f0b1..35e2f28 100644 --- a/tests/benchmarks/script/qscriptengine/tst_qscriptengine.cpp +++ b/tests/benchmarks/script/qscriptengine/tst_qscriptengine.cpp @@ -269,19 +269,22 @@ void tst_QScriptEngine::nativeCall() void tst_QScriptEngine::translation_data() { QTest::addColumn("text"); - QTest::newRow("no translation") << "\"hello world\""; - QTest::newRow("qsTr") << "qsTr(\"hello world\")"; - QTest::newRow("qsTranslate") << "qsTranslate(\"\", \"hello world\")"; + QTest::addColumn("fileName"); + QTest::newRow("no translation") << "\"hello world\"" << ""; + QTest::newRow("qsTr") << "qsTr(\"hello world\")" << ""; + QTest::newRow("qsTranslate") << "qsTranslate(\"\", \"hello world\")" << ""; + QTest::newRow("qsTr:script.js") << "qsTr(\"hello world\")" << "script.js"; } void tst_QScriptEngine::translation() { QFETCH(QString, text); + QFETCH(QString, fileName); QScriptEngine engine; engine.installTranslatorFunctions(); QBENCHMARK { - (void)engine.evaluate(text); + (void)engine.evaluate(text, fileName); } } -- cgit v0.12 From f14ae11e6731bd7416f45c3ef7ce464587862223 Mon Sep 17 00:00:00 2001 From: Iain Date: Thu, 15 Apr 2010 18:08:17 +0200 Subject: Update WebKit DEF files on Symbian Add/absent function with altered signature to BWINS DEF file. Correct ordinal numbering in EABI DEF file, it was broken and causing the build to fail. Reviewed-by: TrustMe --- src/3rdparty/webkit/WebKit/qt/symbian/bwins/QtWebKitu.def | 3 ++- src/3rdparty/webkit/WebKit/qt/symbian/eabi/QtWebKitu.def | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/src/3rdparty/webkit/WebKit/qt/symbian/bwins/QtWebKitu.def b/src/3rdparty/webkit/WebKit/qt/symbian/bwins/QtWebKitu.def index 086e986..cc609e1 100644 --- a/src/3rdparty/webkit/WebKit/qt/symbian/bwins/QtWebKitu.def +++ b/src/3rdparty/webkit/WebKit/qt/symbian/bwins/QtWebKitu.def @@ -623,5 +623,6 @@ EXPORTS ?qt_networkAccessAllowed@@YAX_N@Z @ 622 NONAME ; void qt_networkAccessAllowed(bool) ?qt_resumeActiveDOMObjects@@YAXPAVQWebFrame@@@Z @ 623 NONAME ; void qt_resumeActiveDOMObjects(class QWebFrame *) ?qt_suspendActiveDOMObjects@@YAXPAVQWebFrame@@@Z @ 624 NONAME ; void qt_suspendActiveDOMObjects(class QWebFrame *) - ?qtwebkit_webframe_scrollRecursively@@YA_NPAVQWebFrame@@HH@Z @ 625 NONAME ; bool qtwebkit_webframe_scrollRecursively(class QWebFrame *, int, int) + ?qtwebkit_webframe_scrollRecursively@@YA_NPAVQWebFrame@@HH@Z @ 625 NONAME ABSENT ; bool qtwebkit_webframe_scrollRecursively(class QWebFrame *, int, int) + ?qtwebkit_webframe_scrollRecursively@@YAXPAVQWebFrame@@HHABVQPoint@@@Z @ 626 NONAME ; void qtwebkit_webframe_scrollRecursively(class QWebFrame *, int, int, class QPoint const &) diff --git a/src/3rdparty/webkit/WebKit/qt/symbian/eabi/QtWebKitu.def b/src/3rdparty/webkit/WebKit/qt/symbian/eabi/QtWebKitu.def index cfa8f7f..d244ad5 100644 --- a/src/3rdparty/webkit/WebKit/qt/symbian/eabi/QtWebKitu.def +++ b/src/3rdparty/webkit/WebKit/qt/symbian/eabi/QtWebKitu.def @@ -694,4 +694,4 @@ EXPORTS _Z25qt_resumeActiveDOMObjectsP9QWebFrame @ 693 NONAME _Z26qt_suspendActiveDOMObjectsP9QWebFrame @ 694 NONAME _Z35qtwebkit_webframe_scrollRecursivelyP9QWebFrameii @ 695 NONAME ABSENT - _Z35qtwebkit_webframe_scrollRecursivelyP9QWebFrameiiRK6QPoint @ 715 NONAME + _Z35qtwebkit_webframe_scrollRecursivelyP9QWebFrameiiRK6QPoint @ 696 NONAME -- cgit v0.12 From 0d20ec571767bd80d0b6d636a3a83f472a6dc653 Mon Sep 17 00:00:00 2001 From: Iain Date: Thu, 15 Apr 2010 20:00:52 +0200 Subject: Update EABI and BWINS DEF files for Symbian Reviewed-by: TrustMe --- src/s60installs/bwins/QtCoreu.def | 2 ++ src/s60installs/bwins/QtGuiu.def | 16 ++++++++++++++-- src/s60installs/bwins/QtNetworku.def | 2 ++ src/s60installs/bwins/QtOpenVGu.def | 4 ++++ src/s60installs/eabi/QtGuiu.def | 14 +++++++++++++- 5 files changed, 35 insertions(+), 3 deletions(-) diff --git a/src/s60installs/bwins/QtCoreu.def b/src/s60installs/bwins/QtCoreu.def index df10406..536129b 100644 --- a/src/s60installs/bwins/QtCoreu.def +++ b/src/s60installs/bwins/QtCoreu.def @@ -4417,4 +4417,6 @@ EXPORTS ?QBasicAtomicInt_testAndSetRelease@@YA_NPCHHH@Z @ 4416 NONAME ; bool QBasicAtomicInt_testAndSetRelease(int volatile *, int, int) ?QBasicAtomicInt_fetchAndStoreAcquire@@YAHPCHH@Z @ 4417 NONAME ; int QBasicAtomicInt_fetchAndStoreAcquire(int volatile *, int) ?QBasicAtomicInt_fetchAndAddAcquire@@YAHPCHH@Z @ 4418 NONAME ; int QBasicAtomicInt_fetchAndAddAcquire(int volatile *, int) + ?validCodecs@QTextCodec@@CA_NXZ @ 4419 NONAME ; bool QTextCodec::validCodecs(void) + ?clearHistory@QStateMachinePrivate@@QAEXXZ @ 4420 NONAME ; void QStateMachinePrivate::clearHistory(void) diff --git a/src/s60installs/bwins/QtGuiu.def b/src/s60installs/bwins/QtGuiu.def index 6a4f07b..dad9e6c 100644 --- a/src/s60installs/bwins/QtGuiu.def +++ b/src/s60installs/bwins/QtGuiu.def @@ -11922,7 +11922,7 @@ EXPORTS ?updateCachedClipPathFromSetPosHelper@QGraphicsItemPrivate@@QAEXABVQPointF@@@Z @ 11921 NONAME ABSENT ; void QGraphicsItemPrivate::updateCachedClipPathFromSetPosHelper(class QPointF const &) ?updateCell@QCalendarWidget@@IAEXABVQDate@@@Z @ 11922 NONAME ; void QCalendarWidget::updateCell(class QDate const &) ?updateCells@QCalendarWidget@@IAEXXZ @ 11923 NONAME ; void QCalendarWidget::updateCells(void) - ?updateDisplayText@QLineControl@@AAEXXZ @ 11924 NONAME ; void QLineControl::updateDisplayText(void) + ?updateDisplayText@QLineControl@@AAEXXZ @ 11924 NONAME ABSENT ; void QLineControl::updateDisplayText(void) ?updateEditorData@QAbstractItemView@@MAEXXZ @ 11925 NONAME ; void QAbstractItemView::updateEditorData(void) ?updateEditorGeometries@QAbstractItemView@@MAEXXZ @ 11926 NONAME ; void QAbstractItemView::updateEditorGeometries(void) ?updateEditorGeometry@QAbstractItemDelegate@@UBEXPAVQWidget@@ABVQStyleOptionViewItem@@ABVQModelIndex@@@Z @ 11927 NONAME ; void QAbstractItemDelegate::updateEditorGeometry(class QWidget *, class QStyleOptionViewItem const &, class QModelIndex const &) const @@ -12601,5 +12601,17 @@ EXPORTS ?setPixelFormat@QEglProperties@@QAEXW4Format@QImage@@@Z @ 12600 NONAME ABSENT ; void QEglProperties::setPixelFormat(enum QImage::Format) ?currentContext@QEglContext@@CAPAV1@W4API@QEgl@@@Z @ 12601 NONAME ABSENT ; class QEglContext * QEglContext::currentContext(enum QEgl::API) ?errorString@QEglContext@@SA?AVQString@@H@Z @ 12602 NONAME ABSENT ; class QString QEglContext::errorString(int) - ?removeAllApplicationFonts@QFontDatabase@@SA_NXZ @12603 ; NONAME ; bool QFontDatabase::removeAllApplicationFonts() + ?removeAllApplicationFonts@QFontDatabase@@SA_NXZ @ 12603 NONAME ; bool QFontDatabase::removeAllApplicationFonts() + ?display@QEglContext@@SAHXZ @ 12604 NONAME ABSENT ; int QEglContext::display(void) + ?clearFocusHelper@QGraphicsItemPrivate@@QAEX_N@Z @ 12605 NONAME ; void QGraphicsItemPrivate::clearFocusHelper(bool) + ?canKeypadNavigate@QWidgetPrivate@@SA_NW4Orientation@Qt@@@Z @ 12606 NONAME ; bool QWidgetPrivate::canKeypadNavigate(enum Qt::Orientation) + ?updateDisplayText@QLineControl@@AAEX_N@Z @ 12607 NONAME ; void QLineControl::updateDisplayText(bool) + ?isPixmapCached@QImagePixmapCleanupHooks@@SA_NABVQPixmap@@@Z @ 12608 NONAME ; bool QImagePixmapCleanupHooks::isPixmapCached(class QPixmap const &) + ?nativeDisplay@QEglContext@@CAHXZ @ 12609 NONAME ABSENT ; int QEglContext::nativeDisplay(void) + ?getGlyphBearings@QFontEngine@@UAEXIPAM0@Z @ 12610 NONAME ; void QFontEngine::getGlyphBearings(unsigned int, float *, float *) + ?inTabWidget@QWidgetPrivate@@SA_NPAVQWidget@@@Z @ 12611 NONAME ; bool QWidgetPrivate::inTabWidget(class QWidget *) + ?destroyContext@QEglContext@@QAEXXZ @ 12612 NONAME ABSENT ; void QEglContext::destroyContext(void) + ?isImageCached@QImagePixmapCleanupHooks@@SA_NABVQImage@@@Z @ 12613 NONAME ; bool QImagePixmapCleanupHooks::isImageCached(class QImage const &) + ?dpy@QEglContext@@0HA @ 12614 NONAME ; int QEglContext::dpy + ?setFocusHelper@QGraphicsItemPrivate@@QAEXW4FocusReason@Qt@@_N1@Z @ 12615 NONAME ; void QGraphicsItemPrivate::setFocusHelper(enum Qt::FocusReason, bool, bool) diff --git a/src/s60installs/bwins/QtNetworku.def b/src/s60installs/bwins/QtNetworku.def index 3d604fc..5b27fcf 100644 --- a/src/s60installs/bwins/QtNetworku.def +++ b/src/s60installs/bwins/QtNetworku.def @@ -962,4 +962,6 @@ EXPORTS ?staticMetaObject@QTcpServer@@2UQMetaObject@@B @ 961 NONAME ; struct QMetaObject const QTcpServer::staticMetaObject ?staticMetaObject@QUdpSocket@@2UQMetaObject@@B @ 962 NONAME ; struct QMetaObject const QUdpSocket::staticMetaObject ?staticMetaObject@QAbstractSocket@@2UQMetaObject@@B @ 963 NONAME ; struct QMetaObject const QAbstractSocket::staticMetaObject + ?qt_qhostinfo_clear_cache@@YAXXZ @ 964 NONAME ; void qt_qhostinfo_clear_cache(void) + ?qt_qhostinfo_lookup@@YA?AVQHostInfo@@ABVQString@@PAVQObject@@PBDPA_NPAH@Z @ 965 NONAME ; class QHostInfo qt_qhostinfo_lookup(class QString const &, class QObject *, char const *, bool *, int *) diff --git a/src/s60installs/bwins/QtOpenVGu.def b/src/s60installs/bwins/QtOpenVGu.def index 26ee862..56614ed 100644 --- a/src/s60installs/bwins/QtOpenVGu.def +++ b/src/s60installs/bwins/QtOpenVGu.def @@ -164,4 +164,8 @@ EXPORTS ?qt_vg_create_context@@YAPAVQEglContext@@PAVQPaintDevice@@H@Z @ 163 NONAME ; class QEglContext * qt_vg_create_context(class QPaintDevice *, int) ?reclaimImages@QVGPixmapData@@UAEXXZ @ 164 NONAME ; void QVGPixmapData::reclaimImages(void) ?hibernate@QVGPixmapData@@UAEXXZ @ 165 NONAME ; void QVGPixmapData::hibernate(void) + ?supportsStaticContents@QVGEGLWindowSurfaceDirect@@UBE_NXZ @ 166 NONAME ; bool QVGEGLWindowSurfaceDirect::supportsStaticContents(void) const + ?scroll@QVGEGLWindowSurfacePrivate@@UAE_NPAVQWidget@@ABVQRegion@@HH@Z @ 167 NONAME ; bool QVGEGLWindowSurfacePrivate::scroll(class QWidget *, class QRegion const &, int, int) + ?scroll@QVGEGLWindowSurfaceDirect@@UAE_NPAVQWidget@@ABVQRegion@@HH@Z @ 168 NONAME ; bool QVGEGLWindowSurfaceDirect::scroll(class QWidget *, class QRegion const &, int, int) + ?supportsStaticContents@QVGEGLWindowSurfacePrivate@@UBE_NXZ @ 169 NONAME ; bool QVGEGLWindowSurfacePrivate::supportsStaticContents(void) const diff --git a/src/s60installs/eabi/QtGuiu.def b/src/s60installs/eabi/QtGuiu.def index a3fc452..ac70e70 100644 --- a/src/s60installs/eabi/QtGuiu.def +++ b/src/s60installs/eabi/QtGuiu.def @@ -1818,7 +1818,7 @@ EXPORTS _ZN12QLineControl17_q_deleteSelectedEv @ 1817 NONAME _ZN12QLineControl17processMouseEventEP11QMouseEvent @ 1818 NONAME _ZN12QLineControl17resetInputContextEv @ 1819 NONAME - _ZN12QLineControl17updateDisplayTextEv @ 1820 NONAME + _ZN12QLineControl17updateDisplayTextEv @ 1820 NONAME ABSENT _ZN12QLineControl18displayTextChangedERK7QString @ 1821 NONAME _ZN12QLineControl18removeSelectedTextEv @ 1822 NONAME _ZN12QLineControl19_q_clipboardChangedEv @ 1823 NONAME @@ -11806,4 +11806,16 @@ EXPORTS _ZN9QS60Style10timerEventEP11QTimerEvent @ 11805 NONAME _ZN9QS60Style11eventFilterEP7QObjectP6QEvent @ 11806 NONAME _ZN13QFontDatabase25removeAllApplicationFontsEv @ 11807 NONAME + _ZN11QEglContext13nativeDisplayEv @ 11808 NONAME ABSENT + _ZN11QEglContext14destroyContextEv @ 11809 NONAME ABSENT + _ZN11QEglContext3dpyE @ 11810 NONAME DATA 4 ABSENT + _ZN11QEglContext7displayEv @ 11811 NONAME ABSENT + _ZN11QFontEngine16getGlyphBearingsEjPfS0_ @ 11812 NONAME + _ZN12QLineControl17updateDisplayTextEb @ 11813 NONAME + _ZN14QWidgetPrivate11inTabWidgetEP7QWidget @ 11814 NONAME + _ZN14QWidgetPrivate17canKeypadNavigateEN2Qt11OrientationE @ 11815 NONAME + _ZN20QGraphicsItemPrivate14setFocusHelperEN2Qt11FocusReasonEbb @ 11816 NONAME + _ZN20QGraphicsItemPrivate16clearFocusHelperEb @ 11817 NONAME + _ZN24QImagePixmapCleanupHooks13isImageCachedERK6QImage @ 11818 NONAME + _ZN24QImagePixmapCleanupHooks14isPixmapCachedERK7QPixmap @ 11819 NONAME -- cgit v0.12 From 32aadef3a6621843fe065c3a5f2834a528a7d6fb Mon Sep 17 00:00:00 2001 From: Oswald Buddenhagen Date: Thu, 15 Apr 2010 20:59:20 +0200 Subject: remove pointless manual assignments from token type enum making the range discontiguous just makes the switch() jump table bigger or not applicable at all. --- tools/linguist/lupdate/cpp.cpp | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/tools/linguist/lupdate/cpp.cpp b/tools/linguist/lupdate/cpp.cpp index 2d5620e..66a079a 100644 --- a/tools/linguist/lupdate/cpp.cpp +++ b/tools/linguist/lupdate/cpp.cpp @@ -280,14 +280,14 @@ private: enum { Tok_Eof, Tok_class, Tok_friend, Tok_namespace, Tok_using, Tok_return, - Tok_tr = 10, Tok_trUtf8, Tok_translate, Tok_translateUtf8, Tok_trid, - Tok_Q_OBJECT = 20, Tok_Q_DECLARE_TR_FUNCTIONS, + Tok_tr, Tok_trUtf8, Tok_translate, Tok_translateUtf8, Tok_trid, + Tok_Q_OBJECT, Tok_Q_DECLARE_TR_FUNCTIONS, Tok_Ident, Tok_Comment, Tok_String, Tok_Arrow, Tok_Colon, Tok_ColonColon, Tok_Equals, - Tok_LeftBrace = 30, Tok_RightBrace, Tok_LeftParen, Tok_RightParen, Tok_Comma, Tok_Semicolon, - Tok_Null = 40, Tok_Integer, - Tok_QuotedInclude = 50, Tok_AngledInclude, - Tok_Other = 99 + Tok_LeftBrace, Tok_RightBrace, Tok_LeftParen, Tok_RightParen, Tok_Comma, Tok_Semicolon, + Tok_Null, Tok_Integer, + Tok_QuotedInclude, Tok_AngledInclude, + Tok_Other }; // Tokenizer state -- cgit v0.12 From 2c0f13ccfe750241eb7ddedf6412da380a146975 Mon Sep 17 00:00:00 2001 From: Oswald Buddenhagen Date: Thu, 15 Apr 2010 21:12:34 +0200 Subject: make HashString and HashStringList objects smaller qHash(QString) has only 28 bits, so we can use the upper bits for flagging whether the hash is valid. size effect: LP32: align(4, 4 + 4 + 1) = 12 vs. align(4, 4 + 4) = 8 LP64: align(8, 8 + 8 + 1) = 24 vs. align(8, 8 + 8) = 16 P64: align(8, 8 + 4 + 1) = 16 vs. align(8, 8 + 4) = 16 --- tools/linguist/lupdate/cpp.cpp | 23 ++++++++++------------- 1 file changed, 10 insertions(+), 13 deletions(-) diff --git a/tools/linguist/lupdate/cpp.cpp b/tools/linguist/lupdate/cpp.cpp index 66a079a..3422212 100644 --- a/tools/linguist/lupdate/cpp.cpp +++ b/tools/linguist/lupdate/cpp.cpp @@ -65,47 +65,44 @@ static QString MagicComment(QLatin1String("TRANSLATOR")); class HashString { public: - HashString() : m_hashed(false) {} - explicit HashString(const QString &str) : m_str(str), m_hashed(false) {} - void setValue(const QString &str) { m_str = str; m_hashed = false; } + HashString() : m_hash(0x80000000) {} + explicit HashString(const QString &str) : m_str(str), m_hash(0x80000000) {} + void setValue(const QString &str) { m_str = str; m_hash = 0x80000000; } const QString &value() const { return m_str; } bool operator==(const HashString &other) const { return m_str == other.m_str; } private: QString m_str; + // qHash() of a QString is only 28 bits wide, so we can use + // the highest bit(s) as the "hash valid" flag. mutable uint m_hash; - mutable bool m_hashed; friend uint qHash(const HashString &str); }; uint qHash(const HashString &str) { - if (!str.m_hashed) { - str.m_hashed = true; + if (str.m_hash & 0x80000000) str.m_hash = qHash(str.m_str); - } return str.m_hash; } class HashStringList { public: - explicit HashStringList(const QList &list) : m_list(list), m_hashed(false) {} + explicit HashStringList(const QList &list) : m_list(list), m_hash(0x80000000) {} const QList &value() const { return m_list; } bool operator==(const HashStringList &other) const { return m_list == other.m_list; } private: QList m_list; mutable uint m_hash; - mutable bool m_hashed; friend uint qHash(const HashStringList &list); }; uint qHash(const HashStringList &list) { - if (!list.m_hashed) { - list.m_hashed = true; + if (list.m_hash & 0x80000000) { uint hash = 0; foreach (const HashString &qs, list.m_list) { - hash ^= qHash(qs) ^ 0xa09df22f; - hash = (hash << 13) | (hash >> 19); + hash ^= qHash(qs) ^ 0x0ad9f526; + hash = ((hash << 13) & 0x0fffffff) | (hash >> 15); } list.m_hash = hash; } -- cgit v0.12 From d758d652e1b3950f9df6aa4c1bdef67ba9b88b15 Mon Sep 17 00:00:00 2001 From: Oswald Buddenhagen Date: Thu, 15 Apr 2010 21:48:28 +0200 Subject: make QT_TR_NOOP work in static initializers do that by ignoring all equal signs and everything between and including brackets. this makes static initializers look effectively like function definitions, thus creating proper context. Task-number: QTBUG-9276 --- .../lupdate/testdata/good/parsecpp/main.cpp | 23 ++++++++++ .../testdata/good/parsecpp/project.ts.result | 17 +++++++ tools/linguist/lupdate/cpp.cpp | 53 +++++++++++++++++++--- 3 files changed, 87 insertions(+), 6 deletions(-) diff --git a/tests/auto/linguist/lupdate/testdata/good/parsecpp/main.cpp b/tests/auto/linguist/lupdate/testdata/good/parsecpp/main.cpp index 6e73d6d..0765bfc 100644 --- a/tests/auto/linguist/lupdate/testdata/good/parsecpp/main.cpp +++ b/tests/auto/linguist/lupdate/testdata/good/parsecpp/main.cpp @@ -252,3 +252,26 @@ class YetAnotherTest : QObject { //: This is a message without a source string QString test = qtTrId("yet_another_id"); + + + +// QTBUG-9276: context in static initializers +class Bogus : QObject { + Q_OBJECT + + static const char * const s_strings[]; +}; + +const char * const Bogus::s_strings[] = { + QT_TR_NOOP("this should be in Bogus") +}; + +const char * const Bogus::s_strings[SIZE] = { + QT_TR_NOOP("this should be in Bogus") +}; + +void bogosity() +{ + // no spaces here. test collateral damage from ignoring equal sign + Class::member=QObject::tr("just QObject"); +} diff --git a/tests/auto/linguist/lupdate/testdata/good/parsecpp/project.ts.result b/tests/auto/linguist/lupdate/testdata/good/parsecpp/project.ts.result index 6d50c21..208191d 100644 --- a/tests/auto/linguist/lupdate/testdata/good/parsecpp/project.ts.result +++ b/tests/auto/linguist/lupdate/testdata/good/parsecpp/project.ts.result @@ -26,6 +26,15 @@ backslashed \ stuff. + Bogus + + + + this should be in Bogus + + + + Dialog2 @@ -184,6 +193,14 @@ backslashed \ stuff. + QObject + + + just QObject + + + + QTranslator diff --git a/tools/linguist/lupdate/cpp.cpp b/tools/linguist/lupdate/cpp.cpp index 3422212..4791450 100644 --- a/tools/linguist/lupdate/cpp.cpp +++ b/tools/linguist/lupdate/cpp.cpp @@ -212,13 +212,15 @@ public: private: struct IfdefState { IfdefState() {} - IfdefState(int _braceDepth, int _parenDepth) : + IfdefState(int _bracketDepth, int _braceDepth, int _parenDepth) : + bracketDepth(_bracketDepth), braceDepth(_braceDepth), parenDepth(_parenDepth), elseLine(-1) {} SavedState state; + int bracketDepth, bracketDepth1st; int braceDepth, braceDepth1st; int parenDepth, parenDepth1st; int elseLine; @@ -280,7 +282,7 @@ private: Tok_tr, Tok_trUtf8, Tok_translate, Tok_translateUtf8, Tok_trid, Tok_Q_OBJECT, Tok_Q_DECLARE_TR_FUNCTIONS, Tok_Ident, Tok_Comment, Tok_String, Tok_Arrow, Tok_Colon, Tok_ColonColon, - Tok_Equals, + Tok_Equals, Tok_LeftBracket, Tok_RightBracket, Tok_LeftBrace, Tok_RightBrace, Tok_LeftParen, Tok_RightParen, Tok_Comma, Tok_Semicolon, Tok_Null, Tok_Integer, Tok_QuotedInclude, Tok_AngledInclude, @@ -296,10 +298,12 @@ private: QString yyWord; qlonglong yyInteger; QStack yyIfdefStack; + int yyBracketDepth; int yyBraceDepth; int yyParenDepth; int yyLineNo; int yyCurLineNo; + int yyBracketLineNo; int yyBraceLineNo; int yyParenLineNo; @@ -336,9 +340,11 @@ CppParser::CppParser(ParseResults *_results) results = new ParseResults; directInclude = false; } + yyBracketDepth = 0; yyBraceDepth = 0; yyParenDepth = 0; yyCurLineNo = 1; + yyBracketLineNo = 1; yyBraceLineNo = 1; yyParenLineNo = 1; yyAtNewline = true; @@ -565,7 +571,7 @@ uint CppParser::getToken() yyCh = getChar(); if (yyCh == 'f') { // if, ifdef, ifndef - yyIfdefStack.push(IfdefState(yyBraceDepth, yyParenDepth)); + yyIfdefStack.push(IfdefState(yyBracketDepth, yyBraceDepth, yyParenDepth)); yyCh = getChar(); } else if (yyCh == 'n') { // include @@ -604,16 +610,20 @@ uint CppParser::getToken() if (!yyIfdefStack.isEmpty()) { IfdefState &is = yyIfdefStack.top(); if (is.elseLine != -1) { - if (yyBraceDepth != is.braceDepth1st || yyParenDepth != is.parenDepth1st) - qWarning("%s:%d: Parenthesis/brace mismatch between " + if (yyBracketDepth != is.bracketDepth1st + || yyBraceDepth != is.braceDepth1st + || yyParenDepth != is.parenDepth1st) + qWarning("%s:%d: Parenthesis/bracket/brace mismatch between " "#if and #else branches; using #if branch\n", qPrintable(yyFileName), is.elseLine); } else { + is.bracketDepth1st = yyBracketDepth; is.braceDepth1st = yyBraceDepth; is.parenDepth1st = yyParenDepth; saveState(&is.state); } is.elseLine = yyLineNo; + yyBracketDepth = is.bracketDepth; yyBraceDepth = is.braceDepth; yyParenDepth = is.parenDepth; } @@ -623,10 +633,13 @@ uint CppParser::getToken() if (!yyIfdefStack.isEmpty()) { IfdefState is = yyIfdefStack.pop(); if (is.elseLine != -1) { - if (yyBraceDepth != is.braceDepth1st || yyParenDepth != is.parenDepth1st) + if (yyBracketDepth != is.bracketDepth1st + || yyBraceDepth != is.braceDepth1st + || yyParenDepth != is.parenDepth1st) qWarning("%s:%d: Parenthesis/brace mismatch between " "#if and #else branches; using #if branch\n", qPrintable(yyFileName), is.elseLine); + yyBracketDepth = is.bracketDepth1st; yyBraceDepth = is.braceDepth1st; yyParenDepth = is.parenDepth1st; loadState(&is.state); @@ -899,6 +912,21 @@ uint CppParser::getToken() yyParenDepth--; yyCh = getChar(); return Tok_RightParen; + case '[': + if (yyBracketDepth == 0) + yyBracketLineNo = yyCurLineNo; + yyBracketDepth++; + yyCh = getChar(); + return Tok_LeftBracket; + case ']': + if (yyBracketDepth == 0) + qWarning("%s:%d: Excess closing bracket in C++ code" + " (or abuse of the C++ preprocessor)\n", + qPrintable(yyFileName), yyCurLineNo); + else + yyBracketDepth--; + yyCh = getChar(); + return Tok_RightBracket; case ',': yyCh = getChar(); return Tok_Comma; @@ -1534,6 +1562,12 @@ void CppParser::parseInternal(ConversionData &cd, QSet &inclusions) yyCh = getChar(); yyTok = getToken(); while (yyTok != Tok_Eof) { + // these are array indexing operations. we ignore them entirely + // so they don't confuse our scoping of static initializers. + // we enter the loop by either reading a left bracket or by an + // #else popping the state. + while (yyBracketDepth) + yyTok = getToken(); //qDebug() << "TOKEN: " << yyTok; switch (yyTok) { case Tok_QuotedInclude: { @@ -2074,6 +2108,9 @@ void CppParser::parseInternal(ConversionData &cd, QSet &inclusions) default: if (!yyParenDepth) prospectiveContext.clear(); + // fallthrough + case Tok_Equals: // for static initializers; other cases make no difference + case Tok_RightBracket: // ignoring indexing; same reason case_default: yyTok = getToken(); break; @@ -2088,6 +2125,10 @@ void CppParser::parseInternal(ConversionData &cd, QSet &inclusions) qWarning("%s:%d: Unbalanced opening parenthesis in C++ code" " (or abuse of the C++ preprocessor)\n", qPrintable(yyFileName), yyParenLineNo); + else if (yyBracketDepth != 0) + qWarning("%s:%d: Unbalanced opening bracket in C++ code" + " (or abuse of the C++ preprocessor)\n", + qPrintable(yyFileName), yyBracketLineNo); } const ParseResults *CppParser::recordResults(bool isHeader) -- cgit v0.12 From b7e6c2835ad7b5f5564290c1140c1db59869d54e Mon Sep 17 00:00:00 2001 From: Oswald Buddenhagen Date: Thu, 15 Apr 2010 22:12:18 +0200 Subject: create magic comment messages in "finished" state there is really no point in marking them "unfinished". later file rewrites would reset the state anyway. --- .../lupdate/testdata/good/parsecontexts/project.ts.result | 2 +- tools/linguist/lupdate/cpp.cpp | 9 +++++++-- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/tests/auto/linguist/lupdate/testdata/good/parsecontexts/project.ts.result b/tests/auto/linguist/lupdate/testdata/good/parsecontexts/project.ts.result index 2f21de2..53d7a25 100644 --- a/tests/auto/linguist/lupdate/testdata/good/parsecontexts/project.ts.result +++ b/tests/auto/linguist/lupdate/testdata/good/parsecontexts/project.ts.result @@ -98,7 +98,7 @@ This is a comment to the translator. - + diff --git a/tools/linguist/lupdate/cpp.cpp b/tools/linguist/lupdate/cpp.cpp index 4791450..db4bbca 100644 --- a/tools/linguist/lupdate/cpp.cpp +++ b/tools/linguist/lupdate/cpp.cpp @@ -2035,9 +2035,14 @@ void CppParser::parseInternal(ConversionData &cd, QSet &inclusions) } else { context = comment.left(k); comment.remove(0, k + 1); - recordMessage(yyLineNo, context, QString(), comment, extracomment, - QString(), TranslatorMessage::ExtraData(), false, false); + TranslatorMessage msg( + transcode(context, false), QString(), + transcode(comment, false), QString(), + yyFileName, yyLineNo, QStringList(), + TranslatorMessage::Finished, false); + msg.setExtraComment(transcode(extracomment.simplified(), false)); extracomment.clear(); + tor->append(msg); tor->setExtras(extra); extra.clear(); } -- cgit v0.12 From d397b62f9cb560e772fb0ba78b6a0af6c7232e33 Mon Sep 17 00:00:00 2001 From: Aaron Kennedy Date: Fri, 16 Apr 2010 10:20:01 +1000 Subject: Doc Update QObject documentation to match the Qt's Property System documentation. --- doc/src/snippets/code/src_corelib_kernel_qobject.cpp | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/doc/src/snippets/code/src_corelib_kernel_qobject.cpp b/doc/src/snippets/code/src_corelib_kernel_qobject.cpp index 2d86f8c..77c67ab 100644 --- a/doc/src/snippets/code/src_corelib_kernel_qobject.cpp +++ b/doc/src/snippets/code/src_corelib_kernel_qobject.cpp @@ -374,10 +374,13 @@ Q_PROPERTY(type name READ getFunction [WRITE setFunction] [RESET resetFunction] + [NOTIFY notifySignal] [DESIGNABLE bool] [SCRIPTABLE bool] [STORED bool] - [USER bool]) + [USER bool] + [CONSTANT] + [FINAL]) //! [36] -- cgit v0.12 From 728a4b8a6b44bc3dd8db0e49b823ea12b210644f Mon Sep 17 00:00:00 2001 From: Adam Wasila Date: Mon, 29 Mar 2010 17:55:01 +0300 Subject: adding new entries to qt::key enum --- src/corelib/global/qnamespace.h | 2 ++ src/gui/kernel/qkeymapper_s60.cpp | 4 ++-- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/src/corelib/global/qnamespace.h b/src/corelib/global/qnamespace.h index 09c000b..08674d2 100644 --- a/src/corelib/global/qnamespace.h +++ b/src/corelib/global/qnamespace.h @@ -1092,6 +1092,8 @@ public: Key_Call = 0x01100004, Key_Hangup = 0x01100005, Key_Flip = 0x01100006, + Key_Camera = 0x01100007, + Key_CameraFocus = 0x01100008, Key_unknown = 0x01ffffff }; diff --git a/src/gui/kernel/qkeymapper_s60.cpp b/src/gui/kernel/qkeymapper_s60.cpp index fd263ef..d019c0f 100644 --- a/src/gui/kernel/qkeymapper_s60.cpp +++ b/src/gui/kernel/qkeymapper_s60.cpp @@ -144,7 +144,7 @@ static const KeyMapping keyMapping[] = { {EKeyDevice0, EStdKeyDevice0, Key_Context1}, // Found by manual testing. {EKeyDevice1, EStdKeyDevice1, Key_Context2}, // Found by manual testing. {EKeyDevice3, EStdKeyDevice3, Key_Select}, -// {EKeyDevice7, EStdKeyDevice7, Key_Camera}, //not supported by qt yet + {EKeyDevice7, EStdKeyDevice7, Key_Camera}, {EKeyApplication0, EStdKeyApplication0, Key_Menu}, // Found by manual testing. {EKeyApplication1, EStdKeyApplication1, Key_Launch1}, // Found by manual testing. {EKeyApplication2, EStdKeyApplication2, Key_MediaPlay}, // Found by manual testing. @@ -161,7 +161,7 @@ static const KeyMapping keyMapping[] = { {EKeyApplicationD, EStdKeyApplicationD, Key_LaunchD}, {EKeyApplicationE, EStdKeyApplicationE, Key_LaunchE}, {EKeyApplicationF, EStdKeyApplicationF, Key_LaunchF}, -// {EKeyApplication19, EStdKeyApplication19, Key_CameraFocus}, //not supported by qt yet + {EKeyApplication19, EStdKeyApplication19, Key_CameraFocus}, {EKeyYes, EStdKeyYes, Key_Yes}, {EKeyNo, EStdKeyNo, Key_No}, {TKeyCode(0), TStdScanCode(0), Qt::Key(0)} -- cgit v0.12 From 4ba859e6cc73d2a3d73f8b68c35b2f6911a32fde Mon Sep 17 00:00:00 2001 From: Adam Wasila Date: Mon, 29 Mar 2010 17:55:01 +0300 Subject: adding new entries to qt::key enum documentation updated with two new Qt::Key keys --- src/corelib/global/qnamespace.qdoc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/corelib/global/qnamespace.qdoc b/src/corelib/global/qnamespace.qdoc index 992d2ba..f71ba9d 100644 --- a/src/corelib/global/qnamespace.qdoc +++ b/src/corelib/global/qnamespace.qdoc @@ -1742,6 +1742,8 @@ \value Key_unknown \value Key_Call + \value Key_Camera + \value Key_CameraFocus \value Key_Context1 \value Key_Context2 \value Key_Context3 -- cgit v0.12 From 2ab291e6c65ea1ad5ec70bef913e5fc4db3568b7 Mon Sep 17 00:00:00 2001 From: Denis Dzyubenko Date: Fri, 16 Apr 2010 11:36:59 +0200 Subject: Convert date/time format to something that Qt understands The date/time format in QLocale originate from unicode CLDR which has more format patterns that Qt understands, so when generating date for QLocale we remove unsupported patterns and convert some other to something that Qt understands. Task-number: QTBUG-9500 Reviewed-by: Thiago --- src/corelib/tools/qlocale_data_p.h | 842 +++++++++++++++++---------------- util/local_database/cldr2qlocalexml.py | 9 +- util/local_database/dateconverter.py | 120 +++++ 3 files changed, 547 insertions(+), 424 deletions(-) create mode 100755 util/local_database/dateconverter.py diff --git a/src/corelib/tools/qlocale_data_p.h b/src/corelib/tools/qlocale_data_p.h index 06609f2..13e95f7 100644 --- a/src/corelib/tools/qlocale_data_p.h +++ b/src/corelib/tools/qlocale_data_p.h @@ -305,437 +305,439 @@ static const quint16 locale_index[] = { static const QLocalePrivate locale_data[] = { // lang terr dec group list prcnt zero minus plus exp sDtFmt lDtFmt sTmFmt lTmFmt ssMonth slMonth sMonth lMonth sDays lDays am,len pm,len { 1, 0, 46, 44, 59, 37, 48, 45, 43, 101, 0,10 , 10,17 , 0,8 , 8,10 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 134,27 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 99,14 , 0,2 , 0,2 }, // C/AnyCountry - { 3, 69, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 35,15 , 18,7 , 25,15 , 158,48 , 206,111 , 134,24 , 161,48 , 209,111 , 320,24 , 113,28 , 141,55 , 85,14 , 113,28 , 141,55 , 85,14 , 2,2 , 2,2 }, // Afan/Ethiopia - { 3, 111, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 35,15 , 18,7 , 25,15 , 158,48 , 206,111 , 134,24 , 161,48 , 209,111 , 320,24 , 113,28 , 141,55 , 85,14 , 113,28 , 141,55 , 85,14 , 2,2 , 2,2 }, // Afan/Kenya - { 4, 59, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 50,16 , 18,7 , 25,15 , 317,48 , 365,129 , 494,24 , 344,48 , 392,129 , 521,24 , 196,28 , 224,52 , 276,14 , 196,28 , 224,52 , 276,14 , 0,2 , 0,2 }, // Afar/Djibouti - { 4, 67, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 50,16 , 18,7 , 25,15 , 317,48 , 518,118 , 494,24 , 344,48 , 545,118 , 521,24 , 196,28 , 224,52 , 276,14 , 196,28 , 224,52 , 276,14 , 0,2 , 0,2 }, // Afar/Eritrea - { 4, 69, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 50,16 , 18,7 , 25,15 , 317,48 , 518,118 , 494,24 , 344,48 , 545,118 , 521,24 , 196,28 , 224,52 , 276,14 , 196,28 , 224,52 , 276,14 , 0,2 , 0,2 }, // Afar/Ethiopia - { 5, 195, 44, 160, 59, 37, 48, 45, 43, 101, 66,10 , 76,14 , 18,7 , 25,15 , 636,48 , 684,92 , 134,24 , 663,48 , 711,92 , 320,24 , 290,21 , 311,58 , 369,14 , 290,21 , 311,58 , 369,14 , 4,3 , 4,3 }, // Afrikaans/SouthAfrica - { 5, 148, 44, 160, 59, 37, 48, 45, 43, 101, 66,10 , 90,13 , 40,5 , 45,13 , 636,48 , 684,92 , 134,24 , 663,48 , 711,92 , 320,24 , 290,21 , 311,58 , 369,14 , 290,21 , 311,58 , 369,14 , 4,3 , 4,3 }, // Afrikaans/Namibia - { 6, 2, 44, 46, 59, 37, 48, 45, 43, 101, 103,8 , 111,15 , 58,7 , 65,15 , 776,48 , 824,78 , 902,24 , 803,48 , 851,78 , 929,24 , 383,28 , 411,58 , 469,14 , 383,28 , 411,58 , 469,14 , 7,2 , 7,2 }, // Albanian/Albania - { 7, 69, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 926,46 , 972,62 , 1034,24 , 953,46 , 999,62 , 1061,24 , 483,27 , 510,28 , 538,14 , 483,27 , 510,28 , 538,14 , 9,3 , 9,4 }, // Amharic/Ethiopia - { 8, 186, 1643, 1644, 1563, 1642, 1632, 45, 43, 101, 150,10 , 160,15 , 18,7 , 80,15 , 1058,75 , 1058,75 , 1133,24 , 1085,75 , 1085,75 , 1160,24 , 552,52 , 604,52 , 656,14 , 552,52 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/SaudiArabia - { 8, 3, 44, 46, 59, 37, 48, 45, 43, 101, 150,10 , 160,15 , 18,7 , 80,15 , 1058,75 , 1058,75 , 1133,24 , 1085,75 , 1085,75 , 1160,24 , 670,38 , 604,52 , 656,14 , 670,38 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/Algeria - { 8, 17, 1643, 1644, 1563, 1642, 1632, 45, 43, 101, 150,10 , 160,15 , 18,7 , 80,15 , 1058,75 , 1058,75 , 1133,24 , 1085,75 , 1085,75 , 1160,24 , 670,38 , 604,52 , 656,14 , 670,38 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/Bahrain - { 8, 64, 1643, 1644, 1563, 1642, 1632, 45, 43, 101, 150,10 , 160,15 , 18,7 , 80,15 , 1058,75 , 1058,75 , 1133,24 , 1085,75 , 1085,75 , 1160,24 , 670,38 , 604,52 , 656,14 , 670,38 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/Egypt - { 8, 103, 1643, 1644, 1563, 1642, 1632, 45, 43, 101, 150,10 , 160,15 , 18,7 , 80,15 , 1058,75 , 1058,75 , 1133,24 , 1085,75 , 1085,75 , 1160,24 , 670,38 , 604,52 , 656,14 , 670,38 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/Iraq - { 8, 109, 1643, 1644, 1563, 1642, 1632, 45, 43, 101, 150,10 , 160,15 , 18,7 , 80,15 , 1157,92 , 1157,92 , 1133,24 , 1184,92 , 1184,92 , 1160,24 , 552,52 , 604,52 , 656,14 , 552,52 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/Jordan - { 8, 115, 1643, 1644, 1563, 1642, 1632, 45, 43, 101, 150,10 , 160,15 , 18,7 , 80,15 , 1058,75 , 1058,75 , 1133,24 , 1085,75 , 1085,75 , 1160,24 , 670,38 , 604,52 , 656,14 , 670,38 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/Kuwait - { 8, 119, 1643, 1644, 1563, 1642, 1632, 45, 43, 101, 150,10 , 160,15 , 18,7 , 80,15 , 1249,92 , 1249,92 , 1133,24 , 1276,92 , 1276,92 , 1160,24 , 552,52 , 604,52 , 656,14 , 552,52 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/Lebanon - { 8, 122, 1643, 1644, 1563, 1642, 1632, 45, 43, 101, 150,10 , 160,15 , 18,7 , 80,15 , 1058,75 , 1058,75 , 1133,24 , 1085,75 , 1085,75 , 1160,24 , 670,38 , 604,52 , 656,14 , 670,38 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/LibyanArabJamahiriya - { 8, 145, 44, 46, 59, 37, 48, 45, 43, 101, 150,10 , 160,15 , 18,7 , 80,15 , 1058,75 , 1058,75 , 1133,24 , 1085,75 , 1085,75 , 1160,24 , 670,38 , 604,52 , 656,14 , 670,38 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/Morocco - { 8, 162, 1643, 1644, 1563, 1642, 1632, 45, 43, 101, 150,10 , 160,15 , 18,7 , 80,15 , 1058,75 , 1058,75 , 1133,24 , 1085,75 , 1085,75 , 1160,24 , 670,38 , 604,52 , 656,14 , 670,38 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/Oman - { 8, 175, 1643, 1644, 1563, 1642, 1632, 45, 43, 101, 150,10 , 160,15 , 18,7 , 80,15 , 1058,75 , 1058,75 , 1133,24 , 1085,75 , 1085,75 , 1160,24 , 552,52 , 604,52 , 656,14 , 552,52 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/Qatar - { 8, 201, 1643, 1644, 1563, 1642, 1632, 45, 43, 101, 150,10 , 160,15 , 18,7 , 80,15 , 1058,75 , 1058,75 , 1133,24 , 1085,75 , 1085,75 , 1160,24 , 670,38 , 604,52 , 656,14 , 670,38 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/Sudan - { 8, 207, 1643, 1644, 1563, 1642, 1632, 45, 43, 101, 150,10 , 160,15 , 18,7 , 80,15 , 1249,92 , 1249,92 , 1133,24 , 1276,92 , 1276,92 , 1160,24 , 552,52 , 604,52 , 656,14 , 552,52 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/SyrianArabRepublic - { 8, 216, 44, 46, 59, 37, 48, 45, 43, 101, 150,10 , 160,15 , 18,7 , 80,15 , 1058,75 , 1058,75 , 1133,24 , 1085,75 , 1085,75 , 1160,24 , 552,52 , 604,52 , 656,14 , 552,52 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/Tunisia - { 8, 223, 1643, 1644, 1563, 1642, 1632, 45, 43, 101, 150,10 , 160,15 , 18,7 , 80,15 , 1058,75 , 1058,75 , 1133,24 , 1085,75 , 1085,75 , 1160,24 , 670,38 , 604,52 , 656,14 , 670,38 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/UnitedArabEmirates - { 8, 237, 1643, 1644, 1563, 1642, 1632, 45, 43, 101, 150,10 , 160,15 , 18,7 , 80,15 , 1058,75 , 1058,75 , 1133,24 , 1085,75 , 1085,75 , 1160,24 , 552,52 , 604,52 , 656,14 , 552,52 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/Yemen - { 9, 11, 44, 46, 59, 37, 48, 45, 43, 101, 175,8 , 35,15 , 40,5 , 45,13 , 1341,48 , 1389,94 , 1483,27 , 1368,48 , 1416,94 , 134,27 , 708,28 , 736,62 , 798,14 , 708,28 , 736,62 , 798,14 , 13,3 , 14,3 }, // Armenian/Armenia - { 10, 100, 46, 44, 59, 37, 48, 45, 43, 101, 183,8 , 191,15 , 95,8 , 103,15 , 1510,62 , 1572,88 , 1483,27 , 1510,62 , 1572,88 , 134,27 , 812,37 , 849,58 , 798,14 , 812,37 , 849,58 , 798,14 , 16,9 , 17,7 }, // Assamese/India - { 12, 15, 44, 46, 59, 37, 48, 45, 43, 101, 206,8 , 214,16 , 40,5 , 45,13 , 1660,48 , 1708,77 , 1483,27 , 1660,48 , 1708,77 , 134,27 , 907,26 , 933,67 , 99,14 , 907,26 , 933,67 , 99,14 , 0,2 , 0,2 }, // Azerbaijani/Azerbaijan - { 12, 102, 44, 46, 59, 37, 48, 45, 43, 101, 206,8 , 214,16 , 40,5 , 45,13 , 1660,48 , 1708,77 , 1483,27 , 1660,48 , 1708,77 , 134,27 , 907,26 , 933,67 , 99,14 , 907,26 , 933,67 , 99,14 , 0,2 , 0,2 }, // Azerbaijani/Iran - { 14, 197, 44, 46, 59, 37, 48, 45, 43, 101, 66,10 , 230,28 , 40,5 , 45,13 , 1785,48 , 1833,93 , 1926,24 , 1785,48 , 1833,93 , 1926,24 , 1000,21 , 1021,68 , 798,14 , 1000,21 , 1021,68 , 798,14 , 0,2 , 0,2 }, // Basque/Spain - { 15, 18, 46, 44, 59, 37, 2534, 45, 43, 101, 258,6 , 191,15 , 18,7 , 25,15 , 1950,90 , 1950,90 , 2040,33 , 1950,90 , 1950,90 , 2040,33 , 1089,37 , 1126,58 , 1184,18 , 1089,37 , 1126,58 , 1184,18 , 25,9 , 24,7 }, // Bengali/Bangladesh - { 15, 100, 46, 44, 59, 37, 2534, 45, 43, 101, 258,6 , 191,15 , 18,7 , 25,15 , 1950,90 , 1950,90 , 2040,33 , 1950,90 , 1950,90 , 2040,33 , 1089,37 , 1126,58 , 1184,18 , 1089,37 , 1126,58 , 1184,18 , 25,9 , 24,7 }, // Bengali/India - { 16, 25, 46, 44, 59, 37, 48, 45, 43, 101, 66,10 , 264,26 , 118,22 , 140,38 , 2073,75 , 2148,205 , 1483,27 , 2073,75 , 2148,205 , 134,27 , 1202,34 , 1236,79 , 798,14 , 1202,34 , 1236,79 , 798,14 , 0,2 , 0,2 }, // Bhutani/Bhutan - { 19, 74, 46, 44, 59, 37, 48, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 1483,27 , 1483,27 , 1483,27 , 134,27 , 134,27 , 134,27 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 0,2 , 0,2 }, // Breton/France - { 20, 33, 44, 160, 59, 37, 48, 45, 43, 101, 305,8 , 313,15 , 40,5 , 45,13 , 2353,59 , 2412,82 , 2494,24 , 2353,59 , 2412,82 , 2494,24 , 1315,21 , 1336,55 , 1391,14 , 1315,21 , 1336,55 , 1391,14 , 0,2 , 0,2 }, // Bulgarian/Bulgaria - { 21, 147, 46, 44, 4170, 37, 4160, 45, 43, 101, 206,8 , 290,15 , 40,5 , 45,13 , 2518,43 , 2561,88 , 2649,24 , 2518,43 , 2561,88 , 2649,24 , 1405,25 , 1430,54 , 1484,14 , 1405,25 , 1430,54 , 1484,14 , 0,2 , 0,2 }, // Burmese/Myanmar - { 22, 20, 44, 160, 59, 37, 48, 45, 43, 101, 328,6 , 136,14 , 178,5 , 183,13 , 2673,48 , 2721,99 , 2820,24 , 2673,48 , 2721,95 , 2816,24 , 1498,21 , 1519,56 , 1575,14 , 1498,21 , 1519,56 , 1575,14 , 34,10 , 31,13 }, // Byelorussian/Belarus - { 23, 36, 44, 46, 59, 37, 48, 45, 43, 101, 334,8 , 342,27 , 196,4 , 200,29 , 2844,27 , 2871,71 , 1483,27 , 2840,27 , 2867,71 , 134,27 , 1589,19 , 1608,76 , 798,14 , 1589,19 , 1608,76 , 798,14 , 44,5 , 44,5 }, // Cambodian/Cambodia - { 24, 197, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 369,18 , 196,4 , 229,12 , 2942,60 , 3002,82 , 3084,24 , 2938,93 , 3031,115 , 3146,24 , 1684,21 , 1705,60 , 1765,14 , 1779,28 , 1807,60 , 1867,14 , 49,4 , 49,4 }, // Catalan/Spain - { 25, 44, 46, 44, 59, 37, 48, 45, 43, 101, 387,6 , 393,10 , 241,6 , 247,14 , 3108,38 , 3108,38 , 3146,39 , 3170,39 , 3170,39 , 3170,39 , 1881,21 , 1902,28 , 1930,14 , 1881,21 , 1902,28 , 1930,14 , 0,2 , 0,2 }, // Chinese/China - { 25, 97, 46, 44, 59, 37, 48, 45, 43, 101, 403,7 , 393,10 , 241,6 , 261,14 , 3108,38 , 3108,38 , 1483,27 , 3170,39 , 3170,39 , 134,27 , 1944,21 , 1902,28 , 1930,14 , 1944,21 , 1902,28 , 1930,14 , 0,2 , 0,2 }, // Chinese/HongKong - { 25, 126, 46, 44, 59, 37, 48, 45, 43, 101, 403,7 , 410,12 , 241,6 , 261,14 , 3108,38 , 3108,38 , 1483,27 , 3170,39 , 3170,39 , 134,27 , 1944,21 , 1902,28 , 1930,14 , 1944,21 , 1902,28 , 1930,14 , 0,2 , 0,2 }, // Chinese/Macau - { 25, 190, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 393,10 , 275,7 , 247,14 , 3108,38 , 3108,38 , 3146,39 , 3170,39 , 3170,39 , 3170,39 , 1881,21 , 1902,28 , 1930,14 , 1881,21 , 1902,28 , 1930,14 , 0,2 , 0,2 }, // Chinese/Singapore - { 25, 208, 46, 44, 59, 37, 48, 45, 43, 101, 422,6 , 393,10 , 241,6 , 261,14 , 3108,38 , 3108,38 , 1483,27 , 3170,39 , 3170,39 , 134,27 , 1944,21 , 1902,28 , 1930,14 , 1944,21 , 1902,28 , 1930,14 , 0,2 , 0,2 }, // Chinese/Taiwan - { 27, 54, 44, 46, 59, 37, 48, 45, 43, 101, 428,13 , 441,16 , 40,5 , 45,13 , 3185,49 , 3234,94 , 3328,39 , 3209,49 , 3258,98 , 3356,39 , 1965,28 , 1993,58 , 2051,14 , 1965,28 , 1993,58 , 2051,14 , 0,2 , 0,2 }, // Croatian/Croatia - { 28, 57, 44, 160, 59, 37, 48, 45, 43, 101, 328,6 , 457,15 , 196,4 , 229,12 , 3328,39 , 3367,82 , 3449,24 , 134,27 , 3395,84 , 3479,24 , 2065,21 , 2086,49 , 2135,14 , 2065,21 , 2086,49 , 2135,14 , 53,4 , 53,4 }, // Czech/CzechRepublic - { 29, 58, 44, 46, 44, 37, 48, 45, 43, 101, 27,8 , 472,20 , 178,5 , 183,13 , 3473,48 , 3521,84 , 134,24 , 3503,59 , 3562,84 , 320,24 , 2149,28 , 2177,51 , 2228,14 , 2149,28 , 2177,51 , 2228,14 , 57,4 , 57,4 }, // Danish/Denmark - { 30, 151, 44, 46, 59, 37, 48, 45, 43, 101, 492,8 , 90,13 , 40,5 , 45,13 , 3605,48 , 3653,88 , 134,24 , 3646,59 , 3705,88 , 320,24 , 2242,21 , 2263,59 , 2322,14 , 2242,21 , 2263,59 , 2322,14 , 0,2 , 0,2 }, // Dutch/Netherlands - { 30, 21, 44, 46, 59, 37, 48, 45, 43, 101, 500,7 , 90,13 , 40,5 , 45,13 , 3605,48 , 3653,88 , 134,24 , 3646,59 , 3705,88 , 320,24 , 2242,21 , 2263,59 , 2322,14 , 2242,21 , 2263,59 , 2322,14 , 0,2 , 0,2 }, // Dutch/Belgium - { 31, 225, 46, 44, 59, 37, 48, 45, 43, 101, 507,6 , 35,15 , 18,7 , 25,15 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/UnitedStates - { 31, 4, 46, 44, 59, 37, 48, 45, 43, 101, 507,6 , 35,15 , 18,7 , 25,15 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/AmericanSamoa - { 31, 13, 46, 44, 59, 37, 48, 45, 43, 101, 500,7 , 136,14 , 18,7 , 25,15 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/Australia - { 31, 21, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 90,13 , 40,5 , 282,27 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/Belgium - { 31, 22, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 513,9 , 40,5 , 45,13 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/Belize - { 31, 28, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 76,14 , 18,7 , 25,15 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/Botswana - { 31, 38, 46, 44, 59, 37, 48, 45, 43, 101, 103,8 , 522,14 , 18,7 , 25,15 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/Canada - { 31, 89, 46, 44, 59, 37, 48, 45, 43, 101, 507,6 , 35,15 , 18,7 , 25,15 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/Guam - { 31, 97, 46, 44, 59, 37, 48, 45, 43, 101, 258,6 , 191,15 , 18,7 , 25,15 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/HongKong - { 31, 100, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 90,13 , 18,7 , 25,15 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/India - { 31, 104, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 90,13 , 40,5 , 45,13 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 49,4 , 49,4 }, // English/Ireland - { 31, 107, 46, 44, 59, 37, 48, 45, 43, 101, 258,6 , 35,15 , 18,7 , 25,15 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/Jamaica - { 31, 133, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 40,5 , 45,13 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/Malta - { 31, 134, 46, 44, 59, 37, 48, 45, 43, 101, 507,6 , 35,15 , 18,7 , 25,15 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/MarshallIslands - { 31, 137, 46, 44, 59, 37, 48, 45, 43, 101, 507,6 , 35,15 , 18,7 , 25,15 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/Mauritius - { 31, 148, 46, 44, 59, 37, 48, 45, 43, 101, 507,6 , 35,15 , 18,7 , 25,15 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/Namibia - { 31, 154, 46, 44, 59, 37, 48, 45, 43, 101, 500,7 , 136,14 , 18,7 , 25,15 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/NewZealand - { 31, 160, 46, 44, 59, 37, 48, 45, 43, 101, 507,6 , 35,15 , 18,7 , 25,15 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/NorthernMarianaIslands - { 31, 163, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 90,13 , 18,7 , 25,15 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/Pakistan - { 31, 170, 46, 44, 59, 37, 48, 45, 43, 101, 507,6 , 35,15 , 18,7 , 25,15 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/Philippines - { 31, 190, 46, 44, 59, 37, 48, 45, 43, 101, 258,6 , 35,15 , 18,7 , 25,15 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/Singapore - { 31, 195, 44, 160, 59, 37, 48, 45, 43, 101, 536,10 , 76,14 , 18,7 , 25,15 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/SouthAfrica - { 31, 215, 46, 44, 59, 37, 48, 45, 43, 101, 507,6 , 35,15 , 18,7 , 25,15 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/TrinidadAndTobago - { 31, 224, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 40,5 , 45,13 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/UnitedKingdom - { 31, 226, 46, 44, 59, 37, 48, 45, 43, 101, 507,6 , 35,15 , 18,7 , 25,15 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/UnitedStatesMinorOutlyingIslands - { 31, 234, 46, 44, 59, 37, 48, 45, 43, 101, 507,6 , 35,15 , 18,7 , 25,15 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/USVirginIslands - { 31, 240, 46, 44, 59, 37, 48, 45, 43, 101, 334,8 , 76,14 , 18,7 , 25,15 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/Zimbabwe - { 33, 68, 44, 160, 59, 37, 48, 45, 43, 101, 305,8 , 457,15 , 196,4 , 309,12 , 3741,59 , 3800,91 , 3891,24 , 3793,59 , 3852,91 , 3943,24 , 2336,14 , 2350,63 , 2336,14 , 2336,14 , 2350,63 , 2336,14 , 61,14 , 61,16 }, // Estonian/Estonia - { 34, 71, 44, 46, 59, 37, 48, 8722, 43, 101, 492,8 , 76,14 , 40,5 , 45,13 , 3915,48 , 3963,83 , 134,24 , 3967,48 , 4015,83 , 320,24 , 2413,28 , 2441,74 , 2515,14 , 2413,28 , 2441,74 , 2515,14 , 0,2 , 0,2 }, // Faroese/FaroeIslands - { 36, 73, 44, 160, 59, 37, 48, 45, 43, 101, 546,8 , 554,14 , 321,4 , 325,12 , 4046,69 , 4115,105 , 4220,24 , 4098,129 , 4098,129 , 4227,24 , 2529,21 , 2550,67 , 2617,14 , 2529,21 , 2631,81 , 2617,14 , 75,3 , 77,3 }, // Finnish/Finland - { 37, 74, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 90,13 , 40,5 , 45,13 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/France - { 37, 21, 44, 46, 59, 37, 48, 45, 43, 101, 500,7 , 90,13 , 40,5 , 337,26 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Belgium - { 37, 37, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 90,13 , 40,5 , 45,13 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Cameroon - { 37, 38, 44, 160, 59, 37, 48, 45, 43, 101, 103,8 , 90,13 , 40,5 , 282,27 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Canada - { 37, 41, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 90,13 , 40,5 , 45,13 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/CentralAfricanRepublic - { 37, 53, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 90,13 , 40,5 , 45,13 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/IvoryCoast - { 37, 88, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 90,13 , 40,5 , 45,13 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Guadeloupe - { 37, 91, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 90,13 , 40,5 , 45,13 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Guinea - { 37, 125, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 90,13 , 40,5 , 45,13 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Luxembourg - { 37, 128, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 90,13 , 40,5 , 45,13 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Madagascar - { 37, 132, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 90,13 , 40,5 , 45,13 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Mali - { 37, 135, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 90,13 , 40,5 , 45,13 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Martinique - { 37, 142, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 90,13 , 40,5 , 45,13 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Monaco - { 37, 156, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 90,13 , 40,5 , 45,13 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Niger - { 37, 176, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 90,13 , 40,5 , 45,13 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Reunion - { 37, 187, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 90,13 , 40,5 , 45,13 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Senegal - { 37, 206, 46, 39, 59, 37, 48, 45, 43, 101, 305,8 , 136,14 , 40,5 , 363,17 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Switzerland - { 37, 244, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 90,13 , 40,5 , 45,13 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Saint Barthelemy - { 37, 245, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 90,13 , 40,5 , 45,13 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Saint Martin - { 40, 197, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 76,14 , 40,5 , 45,13 , 4392,48 , 4440,87 , 4527,24 , 4399,48 , 4447,87 , 4534,24 , 2813,28 , 2841,49 , 2890,14 , 2813,28 , 2841,49 , 2890,14 , 0,2 , 0,2 }, // Galician/Spain - { 41, 81, 44, 46, 59, 37, 48, 45, 43, 101, 206,8 , 290,15 , 40,5 , 45,13 , 4551,48 , 4599,99 , 4698,24 , 4558,48 , 4606,99 , 4705,24 , 2904,28 , 2932,62 , 2994,14 , 2904,28 , 2932,62 , 2994,14 , 0,2 , 0,2 }, // Georgian/Georgia - { 42, 82, 44, 46, 59, 37, 48, 45, 43, 101, 305,8 , 457,15 , 40,5 , 45,13 , 4722,52 , 4774,83 , 134,24 , 4729,48 , 4777,83 , 320,24 , 3008,21 , 3029,60 , 3089,14 , 3103,28 , 3029,60 , 3089,14 , 0,2 , 0,2 }, // German/Germany - { 42, 14, 44, 46, 59, 37, 48, 45, 43, 101, 305,8 , 568,16 , 40,5 , 45,13 , 4722,52 , 4857,83 , 134,24 , 4860,48 , 4908,83 , 320,24 , 3008,21 , 3029,60 , 3089,14 , 3103,28 , 3029,60 , 3089,14 , 0,2 , 0,2 }, // German/Austria - { 42, 21, 44, 46, 59, 37, 48, 45, 43, 101, 500,7 , 90,13 , 40,5 , 282,27 , 4722,52 , 4774,83 , 134,24 , 4729,48 , 4777,83 , 320,24 , 3008,21 , 3029,60 , 3089,14 , 3131,28 , 3029,60 , 3089,14 , 0,2 , 0,2 }, // German/Belgium - { 42, 123, 46, 39, 59, 37, 48, 45, 43, 101, 305,8 , 457,15 , 40,5 , 45,13 , 4722,52 , 4774,83 , 134,24 , 4729,48 , 4777,83 , 320,24 , 3008,21 , 3029,60 , 3089,14 , 3103,28 , 3029,60 , 3089,14 , 0,2 , 0,2 }, // German/Liechtenstein - { 42, 125, 44, 46, 59, 37, 48, 45, 43, 101, 305,8 , 457,15 , 40,5 , 45,13 , 4722,52 , 4774,83 , 134,24 , 4729,48 , 4777,83 , 320,24 , 3008,21 , 3029,60 , 3089,14 , 3103,28 , 3029,60 , 3089,14 , 0,2 , 0,2 }, // German/Luxembourg - { 42, 206, 46, 39, 59, 37, 48, 45, 43, 101, 305,8 , 457,15 , 40,5 , 45,13 , 4722,52 , 4774,83 , 134,24 , 4729,48 , 4777,83 , 320,24 , 3008,21 , 3029,60 , 3089,14 , 3103,28 , 3029,60 , 3089,14 , 0,2 , 0,2 }, // German/Switzerland - { 43, 85, 44, 46, 44, 37, 48, 45, 43, 101, 258,6 , 136,14 , 18,7 , 25,15 , 4940,50 , 4990,115 , 5105,24 , 4991,50 , 5041,115 , 5156,24 , 3159,28 , 3187,55 , 3242,14 , 3159,28 , 3187,55 , 3242,14 , 78,4 , 80,4 }, // Greek/Greece - { 43, 56, 44, 46, 44, 37, 48, 45, 43, 101, 258,6 , 136,14 , 18,7 , 25,15 , 4940,50 , 4990,115 , 5105,24 , 4991,50 , 5041,115 , 5156,24 , 3159,28 , 3187,55 , 3242,14 , 3159,28 , 3187,55 , 3242,14 , 78,4 , 80,4 }, // Greek/Cyprus - { 44, 86, 44, 46, 59, 37, 48, 8722, 43, 101, 66,10 , 76,14 , 18,7 , 25,15 , 3473,48 , 5129,96 , 134,24 , 5180,48 , 5228,96 , 320,24 , 3256,28 , 3284,98 , 3382,14 , 3256,28 , 3284,98 , 3382,14 , 0,2 , 0,2 }, // Greenlandic/Greenland - { 46, 100, 46, 44, 59, 37, 48, 45, 43, 101, 584,7 , 191,15 , 380,8 , 388,16 , 5225,67 , 5292,87 , 5379,31 , 5324,67 , 5391,87 , 5478,31 , 3396,32 , 3428,53 , 3481,19 , 3396,32 , 3428,53 , 3481,19 , 82,14 , 84,14 }, // Gujarati/India - { 47, 83, 46, 44, 59, 37, 48, 45, 43, 101, 258,6 , 191,15 , 40,5 , 45,13 , 5410,48 , 5458,85 , 5543,24 , 5509,48 , 5557,85 , 5642,24 , 3500,21 , 3521,52 , 3573,14 , 3500,21 , 3521,52 , 3573,14 , 0,2 , 0,2 }, // Hausa/Ghana - { 47, 156, 46, 44, 59, 37, 48, 45, 43, 101, 258,6 , 191,15 , 40,5 , 45,13 , 5410,48 , 5458,85 , 5543,24 , 5509,48 , 5557,85 , 5642,24 , 3500,21 , 3521,52 , 3573,14 , 3500,21 , 3521,52 , 3573,14 , 0,2 , 0,2 }, // Hausa/Niger - { 47, 157, 46, 44, 59, 37, 48, 45, 43, 101, 258,6 , 191,15 , 40,5 , 45,13 , 5410,48 , 5458,85 , 5543,24 , 5509,48 , 5557,85 , 5642,24 , 3500,21 , 3521,52 , 3573,14 , 3500,21 , 3521,52 , 3573,14 , 0,2 , 0,2 }, // Hausa/Nigeria - { 47, 201, 46, 44, 59, 37, 48, 45, 43, 101, 258,6 , 191,15 , 40,5 , 45,13 , 5567,55 , 5622,99 , 5543,24 , 5666,55 , 5721,99 , 5642,24 , 3587,31 , 3618,57 , 3573,14 , 3587,31 , 3618,57 , 3573,14 , 0,2 , 0,2 }, // Hausa/Sudan - { 48, 105, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 591,15 , 40,5 , 45,13 , 5721,58 , 5779,72 , 1483,27 , 5820,48 , 5868,72 , 134,27 , 3675,46 , 3721,65 , 3786,14 , 3675,46 , 3721,65 , 3786,14 , 96,6 , 98,5 }, // Hebrew/Israel - { 49, 100, 46, 44, 59, 37, 2406, 45, 43, 101, 606,6 , 136,14 , 18,7 , 25,15 , 5851,75 , 5851,75 , 5926,30 , 5940,75 , 5940,75 , 6015,30 , 3800,38 , 3838,57 , 3895,19 , 3800,38 , 3838,57 , 3895,19 , 102,9 , 103,7 }, // Hindi/India - { 50, 98, 44, 160, 59, 37, 48, 45, 43, 101, 612,11 , 623,16 , 196,4 , 229,12 , 5956,64 , 6020,98 , 6118,25 , 6045,64 , 6109,98 , 6207,25 , 3914,19 , 3933,52 , 3985,17 , 3914,19 , 3933,52 , 3985,17 , 111,3 , 110,3 }, // Hungarian/Hungary - { 51, 99, 44, 46, 59, 37, 48, 8722, 43, 101, 546,8 , 457,15 , 40,5 , 45,13 , 6143,48 , 6191,82 , 6273,24 , 6232,48 , 6280,82 , 6362,24 , 4002,28 , 4030,81 , 4111,14 , 4002,28 , 4030,81 , 4125,14 , 114,4 , 113,4 }, // Icelandic/Iceland - { 52, 101, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 639,18 , 178,5 , 325,12 , 6297,48 , 6345,87 , 134,24 , 6386,48 , 6434,87 , 320,24 , 4139,28 , 4167,43 , 4210,14 , 4139,28 , 4167,43 , 4210,14 , 0,2 , 0,2 }, // Indonesian/Indonesia - { 57, 104, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 90,13 , 40,5 , 45,13 , 6432,62 , 6494,107 , 6601,24 , 6521,62 , 6583,107 , 6690,24 , 4224,37 , 4261,75 , 4336,14 , 4224,37 , 4261,75 , 4336,14 , 49,4 , 49,4 }, // Irish/Ireland - { 58, 106, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 90,13 , 40,5 , 45,13 , 6625,48 , 6673,94 , 6767,24 , 6714,48 , 6762,94 , 6856,24 , 4350,28 , 4378,57 , 4435,14 , 4350,28 , 4449,57 , 4435,14 , 118,2 , 117,2 }, // Italian/Italy - { 58, 206, 46, 39, 59, 37, 48, 45, 43, 101, 305,8 , 136,14 , 40,5 , 363,17 , 6625,48 , 6673,94 , 6767,24 , 6714,48 , 6762,94 , 6856,24 , 4350,28 , 4378,57 , 4435,14 , 4350,28 , 4449,57 , 4435,14 , 118,2 , 117,2 }, // Italian/Switzerland - { 59, 108, 46, 44, 59, 37, 48, 45, 43, 101, 206,8 , 393,10 , 196,4 , 404,13 , 3146,39 , 3146,39 , 1483,27 , 3170,39 , 3170,39 , 134,27 , 4506,14 , 4520,28 , 4506,14 , 4506,14 , 4520,28 , 4506,14 , 120,2 , 119,2 }, // Japanese/Japan - { 61, 100, 46, 44, 59, 37, 3302, 45, 43, 101, 606,6 , 90,13 , 380,8 , 388,16 , 6791,86 , 6791,86 , 6877,31 , 6880,86 , 6880,86 , 6966,31 , 4548,28 , 4576,53 , 4629,19 , 4548,28 , 4576,53 , 4629,19 , 122,2 , 121,2 }, // Kannada/India - { 63, 110, 44, 160, 59, 37, 48, 45, 43, 101, 305,8 , 657,19 , 40,5 , 45,13 , 6908,61 , 6969,83 , 1483,27 , 6997,61 , 7058,83 , 134,27 , 4648,28 , 4676,54 , 798,14 , 4648,28 , 4676,54 , 798,14 , 0,2 , 0,2 }, // Kazakh/Kazakhstan - { 64, 179, 44, 46, 59, 37, 48, 45, 43, 101, 206,8 , 290,15 , 40,5 , 45,13 , 7052,60 , 7112,101 , 1483,27 , 7141,60 , 7201,101 , 134,27 , 4730,35 , 4765,84 , 798,14 , 4730,35 , 4765,84 , 798,14 , 0,2 , 0,2 }, // Kinyarwanda/Rwanda - { 65, 116, 44, 160, 59, 37, 48, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 1483,27 , 1483,27 , 1483,27 , 134,27 , 134,27 , 134,27 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 0,2 , 0,2 }, // Kirghiz/Kyrgyzstan - { 66, 114, 46, 44, 59, 37, 48, 45, 43, 101, 676,9 , 685,13 , 417,7 , 424,16 , 7213,39 , 7213,39 , 7213,39 , 7302,39 , 7302,39 , 7302,39 , 4849,14 , 4863,28 , 4849,14 , 4849,14 , 4863,28 , 4849,14 , 124,2 , 123,2 }, // Korean/RepublicOfKorea - { 67, 102, 46, 44, 59, 37, 48, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 1483,27 , 1483,27 , 1483,27 , 134,27 , 134,27 , 134,27 , 4891,42 , 4891,42 , 4933,14 , 4891,42 , 4891,42 , 4933,14 , 0,2 , 0,2 }, // Kurdish/Iran - { 67, 103, 46, 44, 59, 37, 48, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 1483,27 , 1483,27 , 1483,27 , 134,27 , 134,27 , 134,27 , 4891,42 , 4891,42 , 4933,14 , 4891,42 , 4891,42 , 4933,14 , 0,2 , 0,2 }, // Kurdish/Iraq - { 67, 207, 46, 44, 59, 37, 48, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 7252,41 , 7293,51 , 7344,27 , 7341,41 , 7382,51 , 7433,27 , 4947,20 , 4967,39 , 5006,14 , 4947,20 , 4967,39 , 5006,14 , 0,2 , 0,2 }, // Kurdish/SyrianArabRepublic - { 67, 217, 46, 44, 59, 37, 48, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 7252,41 , 7293,51 , 7344,27 , 7341,41 , 7382,51 , 7433,27 , 4947,20 , 4967,39 , 5006,14 , 4947,20 , 4967,39 , 5006,14 , 0,2 , 0,2 }, // Kurdish/Turkey - { 69, 117, 46, 44, 59, 37, 48, 45, 43, 101, 334,8 , 698,17 , 196,4 , 440,24 , 7371,63 , 7434,75 , 1483,27 , 7460,63 , 7523,75 , 134,27 , 5020,24 , 5044,57 , 798,14 , 5020,24 , 5044,57 , 798,14 , 0,2 , 0,2 }, // Laothian/Lao - { 71, 118, 44, 160, 59, 37, 48, 8722, 43, 101, 305,8 , 715,23 , 40,5 , 45,13 , 7509,65 , 7574,101 , 134,24 , 7598,65 , 7663,101 , 320,24 , 5101,21 , 5122,72 , 5194,14 , 5101,21 , 5122,72 , 5194,14 , 126,14 , 125,11 }, // Latvian/Latvia - { 72, 49, 46, 44, 59, 37, 48, 45, 43, 101, 206,8 , 290,15 , 40,5 , 45,13 , 7675,39 , 7714,203 , 1483,27 , 7764,39 , 7803,203 , 134,27 , 5208,23 , 5231,98 , 798,14 , 5208,23 , 5231,98 , 798,14 , 0,2 , 0,2 }, // Lingala/DemocraticRepublicOfCongo - { 72, 50, 46, 44, 59, 37, 48, 45, 43, 101, 206,8 , 290,15 , 40,5 , 45,13 , 7675,39 , 7714,203 , 1483,27 , 7764,39 , 7803,203 , 134,27 , 5208,23 , 5231,98 , 798,14 , 5208,23 , 5231,98 , 798,14 , 0,2 , 0,2 }, // Lingala/PeoplesRepublicOfCongo - { 73, 124, 44, 46, 59, 37, 48, 8722, 43, 101, 66,10 , 738,23 , 40,5 , 45,13 , 7917,69 , 7986,96 , 8082,24 , 8006,48 , 8054,96 , 8150,24 , 5329,17 , 5346,89 , 5435,14 , 5449,21 , 5346,89 , 5435,14 , 140,9 , 136,6 }, // Lithuanian/Lithuania - { 74, 127, 44, 46, 59, 37, 48, 45, 43, 101, 761,7 , 111,15 , 40,5 , 45,13 , 8106,63 , 8169,85 , 8254,24 , 8174,63 , 8237,85 , 8322,24 , 5470,34 , 5504,54 , 1391,14 , 5470,34 , 5504,54 , 1391,14 , 149,10 , 142,8 }, // Macedonian/Macedonia - { 75, 128, 46, 44, 59, 37, 48, 45, 43, 101, 334,8 , 90,13 , 40,5 , 45,13 , 8278,48 , 8326,92 , 134,24 , 8346,48 , 8394,92 , 320,24 , 5558,34 , 5592,60 , 5652,14 , 5558,34 , 5592,60 , 5652,14 , 0,2 , 0,2 }, // Malagasy/Madagascar - { 76, 130, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 768,13 , 464,4 , 25,15 , 8418,49 , 8467,82 , 1483,27 , 8486,49 , 8535,82 , 134,27 , 5666,28 , 5694,43 , 798,14 , 5666,28 , 5694,43 , 798,14 , 0,2 , 0,2 }, // Malay/Malaysia - { 76, 32, 44, 46, 59, 37, 48, 45, 43, 101, 126,10 , 513,9 , 196,4 , 468,17 , 8418,49 , 8467,82 , 1483,27 , 8486,49 , 8535,82 , 134,27 , 5666,28 , 5694,43 , 798,14 , 5666,28 , 5694,43 , 798,14 , 0,2 , 0,2 }, // Malay/BruneiDarussalam - { 77, 100, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 781,15 , 18,7 , 25,15 , 8549,66 , 8615,101 , 8716,31 , 8617,66 , 8683,101 , 8784,31 , 5737,47 , 5784,70 , 5854,22 , 5737,47 , 5784,70 , 5854,22 , 159,6 , 150,10 }, // Malayalam/India - { 78, 133, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 796,20 , 40,5 , 45,13 , 8747,48 , 8795,86 , 8881,24 , 8815,48 , 8863,86 , 8949,24 , 5876,28 , 5904,63 , 5967,14 , 5876,28 , 5904,63 , 5967,14 , 165,2 , 160,2 }, // Maltese/Malta - { 79, 154, 46, 44, 59, 37, 48, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 8905,83 , 8905,83 , 1483,27 , 8973,83 , 8973,83 , 134,27 , 5981,48 , 5981,48 , 798,14 , 5981,48 , 5981,48 , 798,14 , 0,2 , 0,2 }, // Maori/NewZealand - { 80, 100, 46, 44, 59, 37, 2406, 45, 43, 101, 606,6 , 90,13 , 485,7 , 492,15 , 8988,86 , 8988,86 , 9074,32 , 9056,86 , 9056,86 , 9142,32 , 6029,32 , 6061,53 , 3895,19 , 6029,32 , 6061,53 , 3895,19 , 122,2 , 121,2 }, // Marathi/India - { 82, 44, 44, 160, 59, 37, 48, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 9106,48 , 9154,66 , 1483,27 , 9174,48 , 9222,66 , 134,27 , 6114,21 , 6135,43 , 798,14 , 6114,21 , 6135,43 , 798,14 , 0,2 , 0,2 }, // Mongolian/China - { 82, 143, 44, 160, 59, 37, 48, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 9106,48 , 9154,66 , 1483,27 , 9174,48 , 9222,66 , 134,27 , 6114,21 , 6135,43 , 798,14 , 6114,21 , 6135,43 , 798,14 , 0,2 , 0,2 }, // Mongolian/Mongolia - { 84, 100, 46, 44, 59, 37, 2406, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 9220,56 , 9276,80 , 9356,27 , 9288,56 , 9344,80 , 9424,27 , 6178,33 , 6211,54 , 6265,14 , 6178,33 , 6211,54 , 6265,14 , 102,9 , 103,7 }, // Nepali/India - { 84, 150, 46, 44, 59, 37, 2406, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 9220,56 , 9383,85 , 9356,27 , 9288,56 , 9451,85 , 9424,27 , 6178,33 , 6279,54 , 6265,14 , 6178,33 , 6279,54 , 6265,14 , 167,14 , 162,14 }, // Nepali/Nepal - { 85, 161, 44, 160, 59, 37, 48, 45, 43, 101, 305,8 , 554,14 , 40,5 , 507,19 , 9468,59 , 9527,83 , 134,24 , 9536,59 , 9595,83 , 320,24 , 6333,28 , 2177,51 , 2228,14 , 6361,35 , 2177,51 , 2228,14 , 0,2 , 0,2 }, // Norwegian/Norway - { 86, 74, 46, 44, 59, 37, 48, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 9610,83 , 9610,83 , 1483,27 , 9678,83 , 9678,83 , 134,27 , 6396,57 , 6396,57 , 798,14 , 6396,57 , 6396,57 , 798,14 , 0,2 , 0,2 }, // Occitan/France - { 87, 100, 46, 44, 59, 37, 2918, 45, 43, 101, 606,6 , 136,14 , 18,7 , 25,15 , 9693,89 , 9693,89 , 9782,32 , 9761,89 , 9761,89 , 9850,32 , 6453,33 , 6486,54 , 6540,18 , 6453,33 , 6486,54 , 6540,18 , 122,2 , 121,2 }, // Oriya/India - { 88, 1, 1643, 1644, 59, 1642, 1776, 8722, 43, 101, 816,8 , 824,17 , 196,4 , 526,14 , 9814,68 , 9814,68 , 1483,27 , 9882,68 , 9882,68 , 134,27 , 6558,49 , 6558,49 , 798,14 , 6558,49 , 6558,49 , 798,14 , 181,4 , 176,4 }, // Pashto/Afghanistan - { 89, 102, 1643, 1644, 1563, 1642, 1776, 8722, 43, 101, 507,6 , 35,15 , 196,4 , 526,14 , 9882,71 , 9953,70 , 10023,25 , 9950,71 , 10021,73 , 10094,25 , 6558,49 , 6558,49 , 6607,14 , 6558,49 , 6558,49 , 6607,14 , 185,10 , 180,10 }, // Persian/Iran - { 89, 1, 1643, 1644, 1563, 1642, 1776, 8722, 43, 101, 507,6 , 35,15 , 196,4 , 526,14 , 10048,63 , 9953,70 , 10111,24 , 10119,63 , 10182,68 , 10250,24 , 6558,49 , 6558,49 , 6607,14 , 6558,49 , 6558,49 , 6607,14 , 185,10 , 180,10 }, // Persian/Afghanistan - { 90, 172, 44, 160, 59, 37, 48, 45, 43, 101, 492,8 , 136,14 , 40,5 , 45,13 , 10135,48 , 10183,97 , 10280,24 , 10274,48 , 10322,99 , 10421,24 , 6621,34 , 6655,59 , 6714,14 , 6621,34 , 6655,59 , 6714,14 , 0,2 , 0,2 }, // Polish/Poland - { 91, 173, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 841,24 , 40,5 , 540,22 , 10304,48 , 10352,89 , 134,24 , 10445,48 , 10493,89 , 320,24 , 6728,28 , 6756,79 , 6835,14 , 6728,28 , 6756,79 , 6835,14 , 195,17 , 190,18 }, // Portuguese/Portugal - { 91, 30, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 841,24 , 40,5 , 540,22 , 10441,48 , 10489,89 , 134,24 , 10582,48 , 10630,89 , 320,24 , 6728,28 , 6849,79 , 6835,14 , 6728,28 , 6849,79 , 6835,14 , 0,2 , 0,2 }, // Portuguese/Brazil - { 91, 92, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 841,24 , 40,5 , 540,22 , 10441,48 , 10489,89 , 134,24 , 10582,48 , 10630,89 , 320,24 , 6728,28 , 6849,79 , 6835,14 , 6728,28 , 6849,79 , 6835,14 , 0,2 , 0,2 }, // Portuguese/GuineaBissau - { 91, 146, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 841,24 , 40,5 , 540,22 , 10441,48 , 10489,89 , 134,24 , 10582,48 , 10630,89 , 320,24 , 6728,28 , 6849,79 , 6835,14 , 6728,28 , 6849,79 , 6835,14 , 0,2 , 0,2 }, // Portuguese/Mozambique - { 92, 100, 46, 44, 59, 37, 2662, 45, 43, 101, 126,10 , 111,15 , 18,7 , 25,15 , 10578,68 , 10578,68 , 10646,27 , 10719,68 , 10719,68 , 10787,27 , 6928,38 , 6966,55 , 7021,23 , 6928,38 , 6966,55 , 7021,23 , 212,5 , 208,4 }, // Punjabi/India - { 92, 163, 46, 44, 59, 37, 2662, 45, 43, 101, 126,10 , 111,15 , 18,7 , 25,15 , 10673,67 , 10673,67 , 10646,27 , 10814,67 , 10814,67 , 10787,27 , 6928,38 , 7044,37 , 7021,23 , 6928,38 , 7044,37 , 7021,23 , 212,5 , 208,4 }, // Punjabi/Pakistan - { 94, 206, 46, 8217, 59, 37, 48, 8722, 43, 101, 305,8 , 457,15 , 40,5 , 45,13 , 10740,67 , 10807,92 , 10899,24 , 10881,67 , 10948,92 , 11040,24 , 7081,23 , 7104,56 , 7160,14 , 7081,23 , 7104,56 , 7160,14 , 122,2 , 212,2 }, // RhaetoRomance/Switzerland - { 95, 141, 44, 46, 59, 37, 48, 45, 43, 101, 865,10 , 136,14 , 40,5 , 45,13 , 10923,60 , 10983,98 , 11081,24 , 11064,60 , 11124,98 , 11222,24 , 7174,21 , 7195,48 , 2799,14 , 7174,21 , 7195,48 , 2799,14 , 0,2 , 0,2 }, // Romanian/Moldova - { 95, 177, 44, 46, 59, 37, 48, 45, 43, 101, 865,10 , 136,14 , 40,5 , 45,13 , 10923,60 , 10983,98 , 11081,24 , 11064,60 , 11124,98 , 11222,24 , 7174,21 , 7195,48 , 2799,14 , 7174,21 , 7195,48 , 2799,14 , 0,2 , 0,2 }, // Romanian/Romania - { 96, 178, 44, 160, 59, 37, 48, 45, 43, 101, 305,8 , 875,19 , 196,4 , 229,12 , 11105,62 , 11167,80 , 11247,24 , 11246,63 , 11309,82 , 11391,24 , 7243,21 , 7264,62 , 7326,14 , 7243,21 , 7340,62 , 7326,14 , 0,2 , 0,2 }, // Russian/RussianFederation - { 96, 141, 44, 160, 59, 37, 48, 45, 43, 101, 305,8 , 875,19 , 196,4 , 229,12 , 11105,62 , 11167,80 , 11247,24 , 11246,63 , 11309,82 , 11391,24 , 7243,21 , 7264,62 , 7326,14 , 7243,21 , 7340,62 , 7326,14 , 0,2 , 0,2 }, // Russian/Moldova - { 96, 222, 44, 160, 59, 37, 48, 45, 43, 101, 305,8 , 875,19 , 40,5 , 45,13 , 11105,62 , 11167,80 , 11247,24 , 11246,63 , 11309,82 , 11391,24 , 7243,21 , 7264,62 , 7326,14 , 7243,21 , 7340,62 , 7326,14 , 0,2 , 0,2 }, // Russian/Ukraine - { 98, 41, 44, 46, 59, 37, 48, 45, 43, 101, 334,8 , 90,13 , 40,5 , 45,13 , 11271,48 , 11319,91 , 11410,24 , 11415,48 , 11463,91 , 11554,24 , 7402,28 , 7430,66 , 7496,14 , 7402,28 , 7430,66 , 7496,14 , 217,2 , 214,2 }, // Sangho/CentralAfricanRepublic - { 99, 100, 46, 44, 59, 37, 2406, 45, 43, 101, 584,7 , 90,13 , 380,8 , 388,16 , 1483,27 , 1483,27 , 1483,27 , 134,27 , 134,27 , 134,27 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 0,2 , 0,2 }, // Sanskrit/India - { 100, 241, 46, 44, 59, 37, 48, 45, 43, 101, 894,7 , 901,17 , 178,5 , 183,13 , 11434,48 , 11482,81 , 8254,24 , 11578,48 , 11626,81 , 8322,24 , 7510,28 , 7538,52 , 7590,14 , 7510,28 , 7538,52 , 7590,14 , 219,9 , 216,7 }, // Serbian/SerbiaAndMontenegro - { 100, 27, 46, 44, 59, 37, 48, 45, 43, 101, 103,8 , 901,17 , 40,5 , 562,43 , 11434,48 , 11563,83 , 8254,24 , 11578,48 , 11707,83 , 8322,24 , 7604,28 , 7632,54 , 7590,14 , 7604,28 , 7632,54 , 7590,14 , 219,9 , 216,7 }, // Serbian/BosniaAndHerzegowina - { 100, 238, 46, 44, 59, 37, 48, 45, 43, 101, 894,7 , 901,17 , 178,5 , 183,13 , 11434,48 , 11482,81 , 8254,24 , 11578,48 , 11626,81 , 8322,24 , 7510,28 , 7538,52 , 7590,14 , 7510,28 , 7538,52 , 7590,14 , 219,9 , 216,7 }, // Serbian/Yugoslavia - { 100, 242, 46, 44, 59, 37, 48, 45, 43, 101, 894,7 , 901,17 , 178,5 , 183,13 , 11646,48 , 11694,81 , 11775,24 , 11790,48 , 11838,81 , 11919,24 , 7686,28 , 7714,54 , 2051,14 , 7686,28 , 7714,54 , 2051,14 , 228,9 , 223,7 }, // Serbian/Montenegro - { 100, 243, 46, 44, 59, 37, 48, 45, 43, 101, 894,7 , 901,17 , 178,5 , 183,13 , 11434,48 , 11482,81 , 8254,24 , 11578,48 , 11626,81 , 8322,24 , 7510,28 , 7538,52 , 7590,14 , 7510,28 , 7538,52 , 7590,14 , 219,9 , 216,7 }, // Serbian/Serbia - { 101, 241, 46, 44, 59, 37, 48, 45, 43, 101, 894,7 , 901,17 , 178,5 , 183,13 , 11646,48 , 11694,81 , 11775,24 , 11790,48 , 11838,81 , 11919,24 , 7686,28 , 7714,54 , 2051,14 , 7686,28 , 7714,54 , 2051,14 , 228,9 , 223,7 }, // SerboCroatian/SerbiaAndMontenegro - { 101, 27, 46, 44, 59, 37, 48, 45, 43, 101, 894,7 , 901,17 , 178,5 , 183,13 , 11646,48 , 11694,81 , 11775,24 , 11790,48 , 11838,81 , 11919,24 , 7686,28 , 7714,54 , 2051,14 , 7686,28 , 7714,54 , 2051,14 , 228,9 , 223,7 }, // SerboCroatian/BosniaAndHerzegowina - { 101, 238, 46, 44, 59, 37, 48, 45, 43, 101, 894,7 , 901,17 , 178,5 , 183,13 , 11646,48 , 11694,81 , 11775,24 , 11790,48 , 11838,81 , 11919,24 , 7686,28 , 7714,54 , 2051,14 , 7686,28 , 7714,54 , 2051,14 , 228,9 , 223,7 }, // SerboCroatian/Yugoslavia - { 102, 120, 44, 160, 59, 37, 48, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 11799,48 , 11847,105 , 1483,27 , 11943,48 , 11991,105 , 134,27 , 7768,27 , 7795,61 , 798,14 , 7768,27 , 7795,61 , 798,14 , 0,2 , 0,2 }, // Sesotho/Lesotho - { 102, 195, 44, 160, 59, 37, 48, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 11799,48 , 11847,105 , 1483,27 , 11943,48 , 11991,105 , 134,27 , 7768,27 , 7795,61 , 798,14 , 7768,27 , 7795,61 , 798,14 , 0,2 , 0,2 }, // Sesotho/SouthAfrica - { 103, 195, 44, 160, 59, 37, 48, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 11952,48 , 12000,117 , 1483,27 , 12096,48 , 12144,117 , 134,27 , 7856,27 , 7883,64 , 798,14 , 7856,27 , 7883,64 , 798,14 , 0,2 , 0,2 }, // Setswana/SouthAfrica - { 104, 240, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 12117,47 , 12164,100 , 12264,24 , 12261,47 , 12308,100 , 12408,24 , 7947,32 , 7979,55 , 8034,14 , 7947,32 , 7979,55 , 8034,14 , 0,2 , 0,2 }, // Shona/Zimbabwe - { 106, 198, 46, 44, 59, 37, 48, 45, 43, 101, 536,10 , 918,14 , 18,7 , 25,15 , 12288,54 , 12342,92 , 12434,32 , 12432,54 , 12486,92 , 12578,32 , 8048,30 , 8078,62 , 8140,19 , 8048,30 , 8078,62 , 8140,19 , 237,5 , 230,4 }, // Singhalese/SriLanka - { 107, 195, 44, 160, 59, 37, 48, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 12466,48 , 12514,114 , 1483,27 , 12610,48 , 12658,114 , 134,27 , 8159,27 , 8186,68 , 798,14 , 8159,27 , 8186,68 , 798,14 , 0,2 , 0,2 }, // Siswati/SouthAfrica - { 107, 204, 44, 160, 59, 37, 48, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 12466,48 , 12514,114 , 1483,27 , 12610,48 , 12658,114 , 134,27 , 8159,27 , 8186,68 , 798,14 , 8159,27 , 8186,68 , 798,14 , 0,2 , 0,2 }, // Siswati/Swaziland - { 108, 191, 44, 160, 59, 37, 48, 45, 43, 101, 546,8 , 457,15 , 196,4 , 229,12 , 12628,48 , 12676,82 , 11775,24 , 12772,48 , 12820,89 , 11919,24 , 8254,21 , 8275,52 , 8327,14 , 8254,21 , 8275,52 , 8327,14 , 242,10 , 234,9 }, // Slovak/Slovakia - { 109, 192, 44, 46, 59, 37, 48, 45, 43, 101, 932,9 , 568,16 , 40,5 , 45,13 , 11646,48 , 12758,86 , 11775,24 , 11790,48 , 12909,86 , 11919,24 , 8341,28 , 8369,52 , 8421,14 , 8341,28 , 8369,52 , 8421,14 , 53,4 , 243,4 }, // Slovenian/Slovenia - { 110, 194, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 50,16 , 18,7 , 25,15 , 12844,48 , 12892,189 , 13081,24 , 12995,48 , 13043,189 , 13232,24 , 8435,28 , 8463,47 , 8510,14 , 8435,28 , 8463,47 , 8510,14 , 252,3 , 247,3 }, // Somali/Somalia - { 110, 59, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 50,16 , 18,7 , 25,15 , 12844,48 , 12892,189 , 13081,24 , 12995,48 , 13043,189 , 13232,24 , 8435,28 , 8463,47 , 8510,14 , 8435,28 , 8463,47 , 8510,14 , 252,3 , 247,3 }, // Somali/Djibouti - { 110, 69, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 50,16 , 18,7 , 25,15 , 12844,48 , 12892,189 , 13081,24 , 12995,48 , 13043,189 , 13232,24 , 8435,28 , 8463,47 , 8510,14 , 8435,28 , 8463,47 , 8510,14 , 252,3 , 247,3 }, // Somali/Ethiopia - { 110, 111, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 50,16 , 18,7 , 25,15 , 12844,48 , 12892,189 , 13081,24 , 12995,48 , 13043,189 , 13232,24 , 8435,28 , 8463,47 , 8510,14 , 8435,28 , 8463,47 , 8510,14 , 252,3 , 247,3 }, // Somali/Kenya - { 111, 197, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 941,23 , 40,5 , 45,13 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/Spain - { 111, 10, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 941,23 , 40,5 , 605,17 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/Argentina - { 111, 26, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 941,23 , 40,5 , 45,13 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/Bolivia - { 111, 43, 44, 46, 59, 37, 48, 45, 43, 101, 492,8 , 941,23 , 196,4 , 45,13 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/Chile - { 111, 47, 44, 46, 59, 37, 48, 45, 43, 101, 500,7 , 941,23 , 196,4 , 45,13 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/Colombia - { 111, 52, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 941,23 , 40,5 , 45,13 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/CostaRica - { 111, 61, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 941,23 , 40,5 , 45,13 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/DominicanRepublic - { 111, 63, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 941,23 , 196,4 , 45,13 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/Ecuador - { 111, 65, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 941,23 , 40,5 , 45,13 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/ElSalvador - { 111, 66, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 941,23 , 40,5 , 45,13 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/EquatorialGuinea - { 111, 90, 46, 44, 59, 37, 48, 45, 43, 101, 500,7 , 941,23 , 40,5 , 45,13 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/Guatemala - { 111, 96, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 964,24 , 40,5 , 45,13 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/Honduras - { 111, 139, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 941,23 , 40,5 , 45,13 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/Mexico - { 111, 155, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 941,23 , 40,5 , 45,13 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/Nicaragua - { 111, 166, 46, 44, 59, 37, 48, 45, 43, 101, 175,8 , 941,23 , 40,5 , 45,13 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/Panama - { 111, 168, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 941,23 , 40,5 , 45,13 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/Paraguay - { 111, 169, 46, 44, 59, 37, 48, 45, 43, 101, 500,7 , 941,23 , 40,5 , 622,18 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/Peru - { 111, 174, 46, 44, 59, 37, 48, 45, 43, 101, 175,8 , 941,23 , 40,5 , 45,13 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/PuertoRico - { 111, 225, 46, 44, 59, 37, 48, 45, 43, 101, 507,6 , 941,23 , 18,7 , 25,15 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/UnitedStates - { 111, 227, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 941,23 , 40,5 , 45,13 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/Uruguay - { 111, 231, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 941,23 , 40,5 , 45,13 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/Venezuela - { 113, 111, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 13266,48 , 13314,84 , 134,24 , 13417,48 , 13465,84 , 320,24 , 8605,22 , 8627,60 , 8687,14 , 8605,22 , 8627,60 , 8687,14 , 255,7 , 250,7 }, // Swahili/Kenya - { 113, 210, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 13266,48 , 13314,84 , 134,24 , 13417,48 , 13465,84 , 320,24 , 8605,22 , 8627,60 , 8687,14 , 8605,22 , 8627,60 , 8687,14 , 255,7 , 250,7 }, // Swahili/Tanzania - { 114, 205, 44, 160, 59, 37, 48, 8722, 43, 101, 66,10 , 988,27 , 40,5 , 507,19 , 3473,48 , 13398,86 , 134,24 , 5180,48 , 13549,86 , 320,24 , 8701,29 , 8730,50 , 2228,14 , 8701,29 , 8730,50 , 2228,14 , 262,2 , 257,2 }, // Swedish/Sweden - { 114, 73, 44, 160, 59, 37, 48, 8722, 43, 101, 66,10 , 988,27 , 40,5 , 507,19 , 3473,48 , 13398,86 , 134,24 , 5180,48 , 13549,86 , 320,24 , 8701,29 , 8730,50 , 2228,14 , 8701,29 , 8730,50 , 2228,14 , 262,2 , 257,2 }, // Swedish/Finland - { 116, 209, 46, 44, 59, 37, 48, 45, 43, 101, 206,8 , 290,15 , 40,5 , 45,13 , 13484,48 , 13532,71 , 1483,27 , 13635,48 , 13683,71 , 134,27 , 8780,28 , 8808,55 , 798,14 , 8780,28 , 8808,55 , 798,14 , 0,2 , 0,2 }, // Tajik/Tajikistan - { 117, 100, 46, 44, 59, 37, 48, 45, 43, 101, 606,6 , 191,15 , 18,7 , 25,15 , 13603,58 , 13661,86 , 13747,31 , 13754,58 , 13812,86 , 13898,31 , 8863,20 , 8883,49 , 8863,20 , 8863,20 , 8883,49 , 8863,20 , 122,2 , 121,2 }, // Tamil/India - { 117, 198, 46, 44, 59, 37, 48, 45, 43, 101, 606,6 , 191,15 , 18,7 , 25,15 , 13603,58 , 13661,86 , 13747,31 , 13754,58 , 13812,86 , 13898,31 , 8863,20 , 8883,49 , 8863,20 , 8863,20 , 8883,49 , 8863,20 , 122,2 , 121,2 }, // Tamil/SriLanka - { 118, 178, 44, 160, 59, 37, 48, 45, 43, 101, 865,10 , 1015,8 , 196,4 , 25,15 , 1483,27 , 1483,27 , 1483,27 , 134,27 , 134,27 , 134,27 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 0,2 , 0,2 }, // Tatar/RussianFederation - { 119, 100, 46, 44, 59, 37, 48, 45, 43, 101, 492,8 , 90,13 , 18,7 , 25,15 , 13778,86 , 13778,86 , 13864,30 , 13929,86 , 13929,86 , 14015,30 , 8932,32 , 8964,60 , 9024,18 , 8932,32 , 8964,60 , 9024,18 , 0,2 , 0,2 }, // Telugu/India - { 120, 211, 46, 44, 59, 37, 48, 45, 43, 101, 334,8 , 1023,18 , 196,4 , 640,30 , 13894,63 , 13957,98 , 13894,63 , 14045,63 , 14108,98 , 14206,24 , 9042,23 , 9065,68 , 9133,14 , 9042,23 , 9065,68 , 9133,14 , 264,10 , 259,10 }, // Thai/Thailand - { 121, 44, 46, 44, 59, 37, 3872, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 14055,63 , 14118,158 , 1483,27 , 14230,63 , 14293,158 , 134,27 , 9147,49 , 9196,77 , 9273,21 , 9147,49 , 9196,77 , 9273,21 , 274,7 , 269,8 }, // Tibetan/China - { 121, 100, 46, 44, 59, 37, 3872, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 14055,63 , 14118,158 , 1483,27 , 14230,63 , 14293,158 , 134,27 , 9147,49 , 9196,77 , 9273,21 , 9147,49 , 9196,77 , 9273,21 , 274,7 , 269,8 }, // Tibetan/India - { 122, 67, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 1041,22 , 18,7 , 25,15 , 14276,46 , 14322,54 , 1034,24 , 14451,46 , 14497,54 , 1061,24 , 9294,29 , 9294,29 , 9323,14 , 9294,29 , 9294,29 , 9323,14 , 281,7 , 277,7 }, // Tigrinya/Eritrea - { 122, 69, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 1063,22 , 18,7 , 25,15 , 926,46 , 972,62 , 1034,24 , 953,46 , 999,62 , 1061,24 , 9337,29 , 9337,29 , 9323,14 , 9337,29 , 9337,29 , 9323,14 , 281,7 , 277,7 }, // Tigrinya/Ethiopia - { 123, 214, 46, 44, 59, 37, 48, 45, 43, 101, 258,6 , 90,13 , 40,5 , 45,13 , 14376,51 , 14427,87 , 14514,24 , 14551,51 , 14602,87 , 14689,24 , 9366,29 , 9395,60 , 9455,14 , 9366,29 , 9395,60 , 9455,14 , 0,2 , 0,2 }, // Tonga/Tonga - { 124, 195, 44, 160, 59, 37, 48, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 14538,48 , 14586,122 , 1483,27 , 14713,48 , 14761,122 , 134,27 , 9469,27 , 9496,72 , 798,14 , 9469,27 , 9496,72 , 798,14 , 0,2 , 0,2 }, // Tsonga/SouthAfrica - { 125, 217, 44, 46, 59, 37, 48, 45, 43, 101, 865,10 , 1085,14 , 40,5 , 45,13 , 14708,48 , 14756,75 , 14831,24 , 14883,48 , 14931,75 , 15006,24 , 9568,28 , 9596,54 , 9650,14 , 9568,28 , 9596,54 , 9650,14 , 0,2 , 0,2 }, // Turkish/Turkey - { 128, 44, 46, 44, 59, 37, 48, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 1483,27 , 1483,27 , 1483,27 , 134,27 , 134,27 , 134,27 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 0,2 , 0,2 }, // Uigur/China - { 129, 222, 44, 160, 59, 37, 48, 45, 43, 101, 305,8 , 1099,19 , 40,5 , 45,13 , 14855,48 , 14903,95 , 14998,24 , 15030,67 , 15097,87 , 15184,24 , 9664,21 , 9685,56 , 9741,14 , 9664,21 , 9685,56 , 9741,14 , 288,2 , 284,2 }, // Ukrainian/Ukraine - { 130, 100, 46, 44, 59, 37, 48, 45, 43, 101, 258,6 , 1118,15 , 18,7 , 25,15 , 15022,67 , 15022,67 , 10111,24 , 15208,67 , 15208,67 , 10250,24 , 9755,36 , 9755,36 , 9791,14 , 9755,36 , 9755,36 , 9791,14 , 0,2 , 0,2 }, // Urdu/India - { 130, 163, 46, 44, 59, 37, 48, 45, 43, 101, 258,6 , 1118,15 , 18,7 , 25,15 , 15022,67 , 15022,67 , 10111,24 , 15208,67 , 15208,67 , 10250,24 , 9755,36 , 9755,36 , 9791,14 , 9755,36 , 9755,36 , 9791,14 , 0,2 , 0,2 }, // Urdu/Pakistan - { 131, 228, 44, 160, 59, 37, 48, 45, 43, 101, 206,8 , 290,15 , 40,5 , 45,13 , 13484,48 , 15089,115 , 11247,24 , 13635,48 , 15275,115 , 11391,24 , 9805,28 , 9833,53 , 9886,14 , 9805,28 , 9833,53 , 9886,14 , 0,2 , 0,2 }, // Uzbek/Uzbekistan - { 131, 1, 44, 46, 59, 1642, 1776, 8722, 43, 101, 816,8 , 1133,30 , 196,4 , 526,14 , 15204,48 , 15252,68 , 11247,24 , 15390,48 , 10182,68 , 11391,24 , 9900,21 , 6558,49 , 9886,14 , 9900,21 , 6558,49 , 9886,14 , 0,2 , 0,2 }, // Uzbek/Afghanistan - { 132, 232, 44, 46, 59, 37, 48, 45, 43, 101, 126,10 , 1163,28 , 40,5 , 45,13 , 15320,75 , 15395,130 , 1483,27 , 15438,75 , 15513,130 , 134,27 , 9921,33 , 9954,55 , 10009,21 , 9921,33 , 9954,55 , 10009,21 , 290,2 , 286,2 }, // Vietnamese/VietNam - { 134, 224, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 111,15 , 18,7 , 25,15 , 15525,53 , 15578,87 , 15665,24 , 15643,62 , 15705,86 , 15791,24 , 10030,29 , 10059,77 , 10136,14 , 10150,30 , 10059,77 , 10136,14 , 0,2 , 0,2 }, // Welsh/UnitedKingdom - { 135, 187, 46, 44, 59, 37, 48, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 1483,27 , 1483,27 , 1483,27 , 134,27 , 134,27 , 134,27 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 0,2 , 0,2 }, // Wolof/Senegal - { 136, 195, 44, 160, 59, 37, 48, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 15689,48 , 15737,91 , 1483,27 , 15815,48 , 15863,91 , 134,27 , 10180,28 , 10208,61 , 798,14 , 10180,28 , 10208,61 , 798,14 , 0,2 , 0,2 }, // Xhosa/SouthAfrica - { 138, 157, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 15828,73 , 15901,121 , 1483,27 , 15954,73 , 16027,121 , 134,27 , 10269,44 , 10313,69 , 798,14 , 10269,44 , 10313,69 , 798,14 , 292,5 , 288,5 }, // Yoruba/Nigeria - { 140, 195, 44, 160, 59, 37, 48, 45, 43, 101, 66,10 , 76,14 , 18,7 , 25,15 , 16022,48 , 16070,104 , 134,24 , 16148,48 , 16196,90 , 320,24 , 10382,28 , 10410,68 , 10478,14 , 10382,28 , 10410,68 , 10478,14 , 0,2 , 0,2 }, // Zulu/SouthAfrica - { 141, 161, 44, 160, 59, 37, 48, 8722, 43, 101, 305,8 , 554,14 , 40,5 , 507,19 , 3915,48 , 9527,83 , 134,24 , 3967,48 , 9595,83 , 320,24 , 10492,28 , 10520,51 , 2228,14 , 10492,28 , 10520,51 , 2228,14 , 297,9 , 293,11 }, // Nynorsk/Norway - { 142, 27, 44, 46, 59, 37, 48, 45, 43, 101, 206,8 , 290,15 , 40,5 , 45,13 , 16174,48 , 16222,83 , 1483,27 , 16286,48 , 16334,83 , 134,27 , 10571,28 , 10599,58 , 798,14 , 10571,28 , 10599,58 , 798,14 , 0,2 , 0,2 }, // Bosnian/BosniaAndHerzegowina - { 143, 131, 46, 44, 44, 37, 48, 45, 43, 101, 606,6 , 90,13 , 380,8 , 388,16 , 1483,27 , 1483,27 , 1483,27 , 134,27 , 134,27 , 134,27 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 0,2 , 0,2 }, // Divehi/Maldives - { 144, 224, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 76,14 , 40,5 , 45,13 , 16305,102 , 16407,140 , 1483,27 , 16417,102 , 16519,140 , 134,27 , 10657,30 , 10687,57 , 798,14 , 10657,30 , 10687,57 , 798,14 , 49,4 , 49,4 }, // Manx/UnitedKingdom - { 145, 224, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 90,13 , 40,5 , 45,13 , 16547,46 , 16593,124 , 1483,27 , 16659,46 , 16705,124 , 134,27 , 10744,28 , 10772,60 , 798,14 , 10744,28 , 10772,60 , 798,14 , 49,4 , 49,4 }, // Cornish/UnitedKingdom - { 146, 83, 46, 160, 59, 37, 48, 45, 43, 101, 206,8 , 290,15 , 40,5 , 45,13 , 16717,48 , 16765,192 , 1483,27 , 16829,48 , 16877,192 , 134,27 , 10832,28 , 10860,49 , 10909,14 , 10832,28 , 10860,49 , 10909,14 , 306,2 , 304,2 }, // Akan/Ghana - { 147, 100, 46, 44, 59, 37, 48, 45, 43, 101, 606,6 , 90,13 , 18,7 , 25,15 , 16957,87 , 16957,87 , 1483,27 , 17069,87 , 17069,87 , 134,27 , 6029,32 , 10923,55 , 798,14 , 6029,32 , 10923,55 , 798,14 , 308,5 , 306,5 }, // Konkani/India - { 148, 83, 46, 44, 59, 37, 48, 45, 43, 101, 206,8 , 290,15 , 40,5 , 45,13 , 17044,48 , 17092,94 , 1483,27 , 17156,48 , 17204,94 , 134,27 , 10978,26 , 11004,34 , 798,14 , 10978,26 , 11004,34 , 798,14 , 0,2 , 0,2 }, // Ga/Ghana - { 149, 157, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 17186,48 , 17234,86 , 1483,27 , 17298,48 , 17346,86 , 134,27 , 11038,29 , 11067,57 , 798,14 , 11038,29 , 11067,57 , 798,14 , 313,4 , 311,4 }, // Igbo/Nigeria - { 150, 111, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 17320,48 , 17368,189 , 17557,24 , 17432,48 , 17480,189 , 17669,24 , 11124,28 , 11152,74 , 11226,14 , 11124,28 , 11152,74 , 11226,14 , 317,9 , 315,7 }, // Kamba/Kenya - { 151, 207, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 1191,10 , 464,4 , 25,15 , 17581,65 , 17581,65 , 1483,27 , 17693,65 , 17693,65 , 134,27 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 0,2 , 0,2 }, // Syriac/SyrianArabRepublic - { 152, 67, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 1201,21 , 18,7 , 25,15 , 17646,47 , 17693,77 , 17770,24 , 17758,47 , 17805,77 , 17882,24 , 11240,26 , 11266,43 , 11309,14 , 11240,26 , 11266,43 , 11309,14 , 0,2 , 0,2 }, // Blin/Eritrea - { 153, 67, 46, 4808, 59, 37, 48, 45, 43, 101, 27,8 , 1222,22 , 18,7 , 25,15 , 17794,49 , 17794,49 , 17843,24 , 17906,49 , 17906,49 , 17955,24 , 11323,29 , 11323,29 , 11352,14 , 11323,29 , 11323,29 , 11352,14 , 0,2 , 0,2 }, // Geez/Eritrea - { 153, 69, 46, 4808, 59, 37, 48, 45, 43, 101, 27,8 , 1222,22 , 18,7 , 25,15 , 17794,49 , 17794,49 , 17843,24 , 17906,49 , 17906,49 , 17955,24 , 11323,29 , 11323,29 , 11352,14 , 11323,29 , 11323,29 , 11352,14 , 0,2 , 0,2 }, // Geez/Ethiopia - { 154, 53, 46, 44, 59, 37, 48, 45, 43, 101, 206,8 , 290,15 , 40,5 , 45,13 , 17867,48 , 17915,124 , 1483,27 , 17979,48 , 18027,124 , 134,27 , 11366,28 , 11394,54 , 798,14 , 11366,28 , 11394,54 , 798,14 , 0,2 , 0,2 }, // Koro/IvoryCoast - { 155, 69, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 50,16 , 18,7 , 25,15 , 1483,27 , 1483,27 , 1483,27 , 134,27 , 134,27 , 134,27 , 11448,28 , 11476,51 , 11527,14 , 11448,28 , 11476,51 , 11527,14 , 0,2 , 0,2 }, // Sidamo/Ethiopia - { 156, 157, 46, 44, 59, 37, 48, 45, 43, 101, 206,8 , 290,15 , 40,5 , 45,13 , 18039,59 , 18098,129 , 1483,27 , 18151,59 , 18210,129 , 134,27 , 11541,35 , 11576,87 , 798,14 , 11541,35 , 11576,87 , 798,14 , 0,2 , 0,2 }, // Atsam/Nigeria - { 157, 67, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 1244,20 , 18,7 , 25,15 , 926,46 , 972,62 , 1034,24 , 953,46 , 999,62 , 1061,24 , 11663,27 , 11690,41 , 11731,14 , 11663,27 , 11690,41 , 11731,14 , 0,2 , 0,2 }, // Tigre/Eritrea - { 158, 157, 46, 44, 59, 37, 48, 45, 43, 101, 206,8 , 290,15 , 40,5 , 45,13 , 18227,57 , 18284,178 , 1483,27 , 18339,57 , 18396,178 , 134,27 , 11745,28 , 11773,44 , 798,14 , 11745,28 , 11773,44 , 798,14 , 0,2 , 0,2 }, // Jju/Nigeria - { 159, 106, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 1264,24 , 40,5 , 45,13 , 18462,48 , 18510,77 , 18587,24 , 18574,48 , 18622,77 , 18699,24 , 11817,28 , 11845,50 , 2799,14 , 11817,28 , 11845,50 , 2799,14 , 0,2 , 0,2 }, // Friulian/Italy - { 160, 195, 44, 160, 59, 37, 48, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 18611,48 , 18659,111 , 1483,27 , 18723,48 , 18771,111 , 134,27 , 11895,27 , 11922,70 , 798,14 , 11895,27 , 11922,70 , 798,14 , 0,2 , 0,2 }, // Venda/SouthAfrica - { 161, 83, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 18770,48 , 18818,87 , 18905,24 , 18882,48 , 18930,87 , 19017,24 , 11992,32 , 12024,44 , 12068,14 , 11992,32 , 12024,44 , 12068,14 , 306,2 , 304,2 }, // Ewe/Ghana - { 161, 212, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 18770,48 , 18818,87 , 18905,24 , 18882,48 , 18930,87 , 19017,24 , 11992,32 , 12024,44 , 12068,14 , 11992,32 , 12024,44 , 12068,14 , 306,2 , 304,2 }, // Ewe/Togo - { 162, 69, 46, 8217, 59, 37, 48, 45, 43, 101, 27,8 , 1288,21 , 18,7 , 25,15 , 926,46 , 972,62 , 1034,24 , 953,46 , 999,62 , 1061,24 , 12082,27 , 12082,27 , 12109,14 , 12082,27 , 12082,27 , 12109,14 , 0,2 , 0,2 }, // Walamo/Ethiopia - { 163, 225, 46, 44, 59, 37, 48, 45, 43, 101, 258,6 , 136,14 , 18,7 , 25,15 , 18929,59 , 18988,95 , 1483,27 , 19041,59 , 19100,95 , 134,27 , 12123,21 , 12144,57 , 798,14 , 12123,21 , 12144,57 , 798,14 , 0,2 , 0,2 }, // Hawaiian/UnitedStates - { 164, 157, 46, 44, 59, 37, 48, 45, 43, 101, 206,8 , 290,15 , 40,5 , 45,13 , 19083,48 , 19131,153 , 1483,27 , 19195,48 , 19243,153 , 134,27 , 12201,28 , 12229,42 , 798,14 , 12201,28 , 12229,42 , 798,14 , 0,2 , 0,2 }, // Tyap/Nigeria - { 165, 129, 46, 44, 59, 37, 48, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 19284,48 , 19332,91 , 1483,27 , 19396,48 , 19444,91 , 134,27 , 12271,28 , 12299,67 , 798,14 , 12271,28 , 12299,67 , 798,14 , 0,2 , 0,2 }, // Chewa/Malawi - { 166, 170, 46, 44, 59, 37, 48, 45, 43, 101, 507,6 , 1309,15 , 40,5 , 45,13 , 19423,48 , 19471,88 , 19559,24 , 19535,48 , 19583,88 , 19671,24 , 12366,28 , 12394,55 , 12449,14 , 12463,28 , 12394,55 , 12449,14 , 0,2 , 0,2 }, // Filipino/Philippines - { 167, 206, 46, 8217, 59, 37, 48, 8722, 43, 101, 305,8 , 457,15 , 40,5 , 45,13 , 19583,48 , 19631,86 , 134,24 , 4729,48 , 19695,86 , 320,24 , 12491,28 , 12519,63 , 3089,14 , 12491,28 , 12519,63 , 3089,14 , 326,5 , 322,4 }, // Swiss German/Switzerland - { 168, 44, 46, 44, 59, 37, 48, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 1483,27 , 19717,38 , 1483,27 , 134,27 , 19781,38 , 134,27 , 12582,21 , 12603,28 , 12631,14 , 12582,21 , 12603,28 , 12631,14 , 331,2 , 326,2 }, // Sichuan Yi/China - { 169, 91, 46, 44, 59, 37, 48, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 1483,27 , 1483,27 , 1483,27 , 134,27 , 134,27 , 134,27 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 0,2 , 0,2 }, // Kpelle/Guinea - { 169, 121, 46, 44, 59, 37, 48, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 1483,27 , 1483,27 , 1483,27 , 134,27 , 134,27 , 134,27 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 0,2 , 0,2 }, // Kpelle/Liberia - { 170, 82, 44, 46, 59, 37, 48, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 1483,27 , 1483,27 , 1483,27 , 134,27 , 134,27 , 134,27 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 0,2 , 0,2 }, // Low German/Germany - { 171, 195, 44, 160, 59, 37, 48, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 19755,48 , 19803,100 , 1483,27 , 19819,48 , 19867,100 , 134,27 , 12645,27 , 12672,66 , 798,14 , 12645,27 , 12672,66 , 798,14 , 0,2 , 0,2 }, // South Ndebele/SouthAfrica - { 172, 195, 44, 160, 59, 37, 48, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 19903,48 , 19951,94 , 1483,27 , 19967,48 , 20015,94 , 134,27 , 12738,27 , 12765,63 , 798,14 , 12738,27 , 12765,63 , 798,14 , 0,2 , 0,2 }, // Northern Sotho/SouthAfrica - { 173, 73, 44, 160, 59, 37, 48, 8722, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 20045,85 , 20130,145 , 20275,24 , 20109,85 , 20194,145 , 20339,24 , 12828,33 , 12861,65 , 12926,14 , 12828,33 , 12861,65 , 12926,14 , 0,2 , 0,2 }, // Northern Sami/Finland - { 173, 161, 44, 160, 59, 37, 48, 8722, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 20299,59 , 20130,145 , 20275,24 , 20363,59 , 20194,145 , 20339,24 , 12828,33 , 12940,75 , 13015,14 , 12828,33 , 12940,75 , 13015,14 , 0,2 , 0,2 }, // Northern Sami/Norway - { 174, 208, 46, 44, 59, 37, 48, 45, 43, 101, 66,10 , 290,15 , 40,5 , 45,13 , 20358,48 , 20406,142 , 20548,24 , 20422,48 , 20470,142 , 20612,24 , 13029,28 , 13057,172 , 13229,14 , 13029,28 , 13057,172 , 13229,14 , 0,2 , 0,2 }, // Taroko/Taiwan - { 175, 111, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 20572,48 , 20620,88 , 20708,24 , 20636,48 , 20684,88 , 20772,24 , 13243,28 , 13271,62 , 13333,14 , 13243,28 , 13271,62 , 13333,14 , 333,5 , 328,10 }, // Gusii/Kenya - { 176, 111, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 20732,48 , 20780,221 , 21001,24 , 20796,48 , 20844,221 , 21065,24 , 13347,28 , 13375,106 , 13481,14 , 13347,28 , 13375,106 , 13481,14 , 338,10 , 338,10 }, // Taita/Kenya - { 177, 187, 44, 160, 59, 37, 48, 45, 43, 101, 334,8 , 90,13 , 40,5 , 45,13 , 21025,48 , 21073,77 , 21150,24 , 21089,48 , 21137,77 , 21214,24 , 13495,28 , 13523,59 , 13582,14 , 13495,28 , 13523,59 , 13582,14 , 348,6 , 348,7 }, // Fulah/Senegal - { 178, 111, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 21174,48 , 21222,185 , 21407,24 , 21238,48 , 21286,185 , 21471,24 , 13596,28 , 13624,63 , 13687,14 , 13596,28 , 13624,63 , 13687,14 , 354,6 , 355,8 }, // Kikuyu/Kenya - { 179, 111, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 21431,48 , 21479,173 , 21652,24 , 21495,48 , 21543,173 , 21716,24 , 13701,28 , 13729,105 , 13834,14 , 13701,28 , 13729,105 , 13834,14 , 360,7 , 363,5 }, // Samburu/Kenya - { 180, 146, 44, 46, 59, 37, 48, 45, 43, 101, 334,8 , 841,24 , 40,5 , 45,13 , 21676,48 , 21724,88 , 134,24 , 21740,48 , 21788,88 , 320,24 , 13848,28 , 13876,55 , 13931,14 , 13848,28 , 13876,55 , 13931,14 , 0,2 , 0,2 }, // Sena/Mozambique - { 181, 240, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 21812,48 , 21860,112 , 21972,24 , 21876,48 , 21924,112 , 22036,24 , 13945,28 , 13973,50 , 14023,14 , 13945,28 , 13973,50 , 14023,14 , 0,2 , 0,2 }, // North Ndebele/Zimbabwe - { 182, 210, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 21996,39 , 22035,194 , 22229,24 , 22060,39 , 22099,194 , 22293,24 , 14037,28 , 14065,65 , 14130,14 , 14037,28 , 14065,65 , 14130,14 , 367,8 , 368,7 }, // Rombo/Tanzania - { 183, 145, 44, 160, 59, 37, 48, 45, 43, 101, 334,8 , 90,13 , 40,5 , 45,13 , 22253,48 , 22301,81 , 22382,24 , 22317,48 , 22365,81 , 22446,24 , 14144,30 , 14174,48 , 798,14 , 14144,30 , 14174,48 , 798,14 , 375,6 , 375,8 }, // Tachelhit/Morocco - { 184, 3, 44, 160, 59, 37, 48, 45, 43, 101, 334,8 , 90,13 , 40,5 , 45,13 , 22406,48 , 22454,84 , 22538,24 , 22470,48 , 22518,84 , 22602,24 , 14222,30 , 14252,51 , 14303,14 , 14222,30 , 14252,51 , 14303,14 , 381,7 , 383,9 }, // Kabyle/Algeria - { 185, 221, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 22562,48 , 22610,152 , 134,24 , 22626,48 , 22674,152 , 320,24 , 14317,28 , 14345,74 , 14419,14 , 14317,28 , 14345,74 , 14419,14 , 0,2 , 0,2 }, // Nyankole/Uganda - { 186, 210, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 22762,48 , 22810,254 , 23064,24 , 22826,48 , 22874,254 , 23128,24 , 14433,28 , 14461,82 , 14543,14 , 14433,28 , 14461,82 , 14543,14 , 388,7 , 392,7 }, // Bena/Tanzania - { 187, 210, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 13266,48 , 23088,87 , 134,24 , 13417,48 , 23152,87 , 320,24 , 14557,28 , 14585,62 , 14647,14 , 14557,28 , 14585,62 , 14647,14 , 395,5 , 399,9 }, // Vunjo/Tanzania - { 188, 132, 46, 44, 59, 37, 48, 45, 43, 101, 334,8 , 90,13 , 40,5 , 45,13 , 23175,47 , 23222,92 , 23314,24 , 23239,47 , 23286,92 , 23378,24 , 14661,28 , 14689,44 , 14733,14 , 14661,28 , 14689,44 , 14733,14 , 0,2 , 0,2 }, // Bambara/Mali - { 189, 111, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 23338,48 , 23386,207 , 23593,24 , 23402,48 , 23450,207 , 23657,24 , 14747,28 , 14775,64 , 14839,14 , 14747,28 , 14775,64 , 14839,14 , 400,2 , 408,2 }, // Embu/Kenya - { 190, 225, 46, 44, 59, 37, 48, 45, 43, 101, 507,6 , 35,15 , 18,7 , 25,15 , 23617,36 , 23653,58 , 23711,24 , 23681,36 , 23717,58 , 23775,24 , 14853,28 , 14881,49 , 14930,14 , 14853,28 , 14881,49 , 14930,14 , 402,3 , 410,6 }, // Cherokee/UnitedStates - { 191, 137, 46, 160, 59, 37, 48, 45, 43, 101, 334,8 , 90,13 , 40,5 , 45,13 , 23735,47 , 23782,68 , 23850,24 , 23799,47 , 23846,68 , 23914,24 , 14944,27 , 14971,48 , 15019,14 , 14944,27 , 14971,48 , 15019,14 , 0,2 , 0,2 }, // Morisyen/Mauritius - { 192, 210, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 13266,48 , 23874,264 , 134,24 , 13417,48 , 23938,264 , 320,24 , 15033,28 , 15061,133 , 14130,14 , 15033,28 , 15061,133 , 14130,14 , 405,4 , 416,5 }, // Makonde/Tanzania - { 193, 210, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 24138,83 , 24221,111 , 24332,24 , 24202,83 , 24285,111 , 24396,24 , 15194,36 , 15230,63 , 15293,14 , 15194,36 , 15230,63 , 15293,14 , 409,3 , 421,3 }, // Langi/Tanzania - { 194, 221, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 24356,48 , 24404,97 , 134,24 , 24420,48 , 24468,97 , 320,24 , 15307,28 , 15335,66 , 15401,14 , 15307,28 , 15335,66 , 15401,14 , 0,2 , 0,2 }, // Ganda/Uganda - { 195, 239, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 24501,48 , 24549,83 , 24632,24 , 24565,48 , 24613,83 , 24696,24 , 15415,80 , 15415,80 , 798,14 , 15415,80 , 15415,80 , 798,14 , 412,8 , 424,7 }, // Bemba/Zambia - { 196, 39, 44, 46, 59, 37, 48, 45, 43, 101, 334,8 , 841,24 , 40,5 , 45,13 , 24656,48 , 24704,86 , 134,24 , 24720,48 , 24768,86 , 320,24 , 15495,28 , 15523,73 , 15596,14 , 15495,28 , 15523,73 , 15596,14 , 122,2 , 121,2 }, // Kabuverdianu/CapeVerde - { 197, 111, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 24790,48 , 24838,86 , 24924,24 , 24854,48 , 24902,86 , 24988,24 , 15610,28 , 15638,51 , 15689,14 , 15610,28 , 15638,51 , 15689,14 , 420,2 , 431,2 }, // Meru/Kenya - { 198, 111, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 24948,48 , 24996,111 , 25107,24 , 25012,48 , 25060,111 , 25171,24 , 15703,28 , 15731,93 , 15824,14 , 15703,28 , 15731,93 , 15824,14 , 422,4 , 433,4 }, // Kalenjin/Kenya - { 199, 148, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 0,48 , 25131,136 , 134,24 , 0,48 , 25195,136 , 320,24 , 15838,23 , 15861,92 , 15953,14 , 15838,23 , 15861,92 , 15953,14 , 426,7 , 437,5 }, // Nama/Namibia - { 200, 210, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 13266,48 , 23088,87 , 134,24 , 13417,48 , 23152,87 , 320,24 , 14557,28 , 14585,62 , 14647,14 , 14557,28 , 14585,62 , 14647,14 , 395,5 , 399,9 }, // Machame/Tanzania - { 201, 82, 44, 160, 59, 37, 48, 8722, 43, 101, 1324,10 , 1334,20 , 40,5 , 45,13 , 25267,59 , 25326,87 , 134,24 , 25331,59 , 25390,87 , 320,24 , 15967,28 , 15995,72 , 3089,14 , 15967,28 , 15995,72 , 3089,14 , 0,2 , 0,2 }, // Colognian/Germany - { 202, 111, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 25413,51 , 25464,132 , 1483,27 , 25477,51 , 25528,132 , 134,27 , 14557,28 , 16067,58 , 14130,14 , 14557,28 , 16067,58 , 14130,14 , 433,9 , 442,6 }, // Masai/Kenya - { 202, 210, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 25413,51 , 25464,132 , 1483,27 , 25477,51 , 25528,132 , 134,27 , 14557,28 , 16067,58 , 14130,14 , 14557,28 , 16067,58 , 14130,14 , 433,9 , 442,6 }, // Masai/Tanzania - { 203, 221, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 24356,48 , 24404,97 , 134,24 , 24420,48 , 24468,97 , 320,24 , 16125,35 , 16160,65 , 16225,14 , 16125,35 , 16160,65 , 16225,14 , 442,6 , 448,6 }, // Soga/Uganda - { 204, 111, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 25596,48 , 13314,84 , 134,24 , 25660,48 , 13465,84 , 320,24 , 16239,21 , 16260,75 , 85,14 , 16239,21 , 16260,75 , 85,14 , 49,4 , 49,4 }, // Luyia/Kenya - { 205, 210, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 25644,48 , 13314,84 , 134,24 , 25708,48 , 13465,84 , 320,24 , 16335,28 , 8627,60 , 14647,14 , 16335,28 , 8627,60 , 14647,14 , 448,9 , 454,8 }, // Asu/Tanzania - { 206, 111, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 25692,48 , 25740,94 , 25834,24 , 25756,48 , 25804,94 , 25898,24 , 16363,28 , 16391,69 , 16460,14 , 16363,28 , 16391,69 , 16460,14 , 457,9 , 462,6 }, // Teso/Kenya - { 206, 221, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 25692,48 , 25740,94 , 25834,24 , 25756,48 , 25804,94 , 25898,24 , 16363,28 , 16391,69 , 16460,14 , 16363,28 , 16391,69 , 16460,14 , 457,9 , 462,6 }, // Teso/Uganda - { 207, 67, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 50,16 , 18,7 , 25,15 , 317,48 , 518,118 , 494,24 , 344,48 , 545,118 , 521,24 , 16474,28 , 16502,56 , 16558,14 , 16474,28 , 16502,56 , 16558,14 , 0,2 , 0,2 }, // Saho/Eritrea - { 208, 132, 46, 160, 59, 37, 48, 45, 43, 101, 334,8 , 90,13 , 40,5 , 45,13 , 25858,46 , 25904,88 , 25992,24 , 25922,46 , 25968,88 , 26056,24 , 16572,28 , 16600,53 , 16653,14 , 16572,28 , 16600,53 , 16653,14 , 466,6 , 468,6 }, // Koyra Chiini/Mali - { 209, 210, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 13266,48 , 23088,87 , 134,24 , 13417,48 , 23152,87 , 320,24 , 14557,28 , 14585,62 , 14647,14 , 14557,28 , 14585,62 , 14647,14 , 395,5 , 399,9 }, // Rwa/Tanzania - { 210, 111, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 26016,48 , 26064,186 , 26250,24 , 26080,48 , 26128,186 , 26314,24 , 16667,28 , 16695,69 , 16764,14 , 16667,28 , 16695,69 , 16764,14 , 472,2 , 474,2 }, // Luo/Kenya - { 211, 221, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 22562,48 , 22610,152 , 134,24 , 22626,48 , 22674,152 , 320,24 , 14317,28 , 14345,74 , 14419,14 , 14317,28 , 14345,74 , 14419,14 , 0,2 , 0,2 }, // Chiga/Uganda - { 212, 145, 44, 160, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 26274,48 , 26322,86 , 26408,24 , 26338,48 , 26386,86 , 26472,24 , 16778,28 , 16806,48 , 16854,14 , 16778,28 , 16806,48 , 16854,14 , 474,9 , 476,10 }, // Central Morocco Tamazight/Morocco - { 213, 132, 46, 160, 59, 37, 48, 45, 43, 101, 334,8 , 90,13 , 40,5 , 45,13 , 25858,46 , 25904,88 , 25992,24 , 25922,46 , 25968,88 , 26056,24 , 16868,28 , 16896,54 , 16653,14 , 16868,28 , 16896,54 , 16653,14 , 466,6 , 468,6 }, // Koyraboro Senni/Mali - { 214, 210, 46, 44, 59, 37, 48, 45, 43, 101, 126,10 , 136,14 , 18,7 , 25,15 , 13266,48 , 26432,84 , 134,24 , 13417,48 , 26496,84 , 320,24 , 16950,28 , 16978,63 , 8687,14 , 16950,28 , 16978,63 , 8687,14 , 483,5 , 486,8 }, // Shambala/Tanzania + { 3, 69, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 35,18 , 18,7 , 25,12 , 158,48 , 206,111 , 134,24 , 161,48 , 209,111 , 320,24 , 113,28 , 141,55 , 85,14 , 113,28 , 141,55 , 85,14 , 2,2 , 2,2 }, // Afan/Ethiopia + { 3, 111, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 35,18 , 18,7 , 25,12 , 158,48 , 206,111 , 134,24 , 161,48 , 209,111 , 320,24 , 113,28 , 141,55 , 85,14 , 113,28 , 141,55 , 85,14 , 2,2 , 2,2 }, // Afan/Kenya + { 4, 59, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 53,19 , 18,7 , 25,12 , 317,48 , 365,129 , 494,24 , 344,48 , 392,129 , 521,24 , 196,28 , 224,52 , 276,14 , 196,28 , 224,52 , 276,14 , 0,2 , 0,2 }, // Afar/Djibouti + { 4, 67, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 53,19 , 18,7 , 25,12 , 317,48 , 518,118 , 494,24 , 344,48 , 545,118 , 521,24 , 196,28 , 224,52 , 276,14 , 196,28 , 224,52 , 276,14 , 0,2 , 0,2 }, // Afar/Eritrea + { 4, 69, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 53,19 , 18,7 , 25,12 , 317,48 , 518,118 , 494,24 , 344,48 , 545,118 , 521,24 , 196,28 , 224,52 , 276,14 , 196,28 , 224,52 , 276,14 , 0,2 , 0,2 }, // Afar/Ethiopia + { 5, 195, 44, 160, 59, 37, 48, 45, 43, 101, 72,10 , 82,17 , 18,7 , 25,12 , 636,48 , 684,92 , 134,24 , 663,48 , 711,92 , 320,24 , 290,21 , 311,58 , 369,14 , 290,21 , 311,58 , 369,14 , 4,3 , 4,3 }, // Afrikaans/SouthAfrica + { 5, 148, 44, 160, 59, 37, 48, 45, 43, 101, 72,10 , 99,16 , 37,5 , 8,10 , 636,48 , 684,92 , 134,24 , 663,48 , 711,92 , 320,24 , 290,21 , 311,58 , 369,14 , 290,21 , 311,58 , 369,14 , 4,3 , 4,3 }, // Afrikaans/Namibia + { 6, 2, 44, 46, 59, 37, 48, 45, 43, 101, 115,8 , 123,18 , 42,7 , 49,12 , 776,48 , 824,78 , 902,24 , 803,48 , 851,78 , 929,24 , 383,28 , 411,58 , 469,14 , 383,28 , 411,58 , 469,14 , 7,2 , 7,2 }, // Albanian/Albania + { 7, 69, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 926,46 , 972,62 , 1034,24 , 953,46 , 999,62 , 1061,24 , 483,27 , 510,28 , 538,14 , 483,27 , 510,28 , 538,14 , 9,3 , 9,4 }, // Amharic/Ethiopia + { 8, 186, 1643, 1644, 1563, 1642, 1632, 45, 43, 101, 151,10 , 161,18 , 18,7 , 61,12 , 1058,75 , 1058,75 , 1133,24 , 1085,75 , 1085,75 , 1160,24 , 552,52 , 604,52 , 656,14 , 552,52 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/SaudiArabia + { 8, 3, 44, 46, 59, 37, 48, 45, 43, 101, 151,10 , 161,18 , 18,7 , 61,12 , 1058,75 , 1058,75 , 1133,24 , 1085,75 , 1085,75 , 1160,24 , 670,38 , 604,52 , 656,14 , 670,38 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/Algeria + { 8, 17, 1643, 1644, 1563, 1642, 1632, 45, 43, 101, 151,10 , 161,18 , 18,7 , 61,12 , 1058,75 , 1058,75 , 1133,24 , 1085,75 , 1085,75 , 1160,24 , 670,38 , 604,52 , 656,14 , 670,38 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/Bahrain + { 8, 64, 1643, 1644, 1563, 1642, 1632, 45, 43, 101, 151,10 , 161,18 , 18,7 , 61,12 , 1058,75 , 1058,75 , 1133,24 , 1085,75 , 1085,75 , 1160,24 , 670,38 , 604,52 , 656,14 , 670,38 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/Egypt + { 8, 103, 1643, 1644, 1563, 1642, 1632, 45, 43, 101, 151,10 , 161,18 , 18,7 , 61,12 , 1058,75 , 1058,75 , 1133,24 , 1085,75 , 1085,75 , 1160,24 , 670,38 , 604,52 , 656,14 , 670,38 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/Iraq + { 8, 109, 1643, 1644, 1563, 1642, 1632, 45, 43, 101, 151,10 , 161,18 , 18,7 , 61,12 , 1157,92 , 1157,92 , 1133,24 , 1184,92 , 1184,92 , 1160,24 , 552,52 , 604,52 , 656,14 , 552,52 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/Jordan + { 8, 115, 1643, 1644, 1563, 1642, 1632, 45, 43, 101, 151,10 , 161,18 , 18,7 , 61,12 , 1058,75 , 1058,75 , 1133,24 , 1085,75 , 1085,75 , 1160,24 , 670,38 , 604,52 , 656,14 , 670,38 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/Kuwait + { 8, 119, 1643, 1644, 1563, 1642, 1632, 45, 43, 101, 151,10 , 161,18 , 18,7 , 61,12 , 1249,92 , 1249,92 , 1133,24 , 1276,92 , 1276,92 , 1160,24 , 552,52 , 604,52 , 656,14 , 552,52 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/Lebanon + { 8, 122, 1643, 1644, 1563, 1642, 1632, 45, 43, 101, 151,10 , 161,18 , 18,7 , 61,12 , 1058,75 , 1058,75 , 1133,24 , 1085,75 , 1085,75 , 1160,24 , 670,38 , 604,52 , 656,14 , 670,38 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/LibyanArabJamahiriya + { 8, 145, 44, 46, 59, 37, 48, 45, 43, 101, 151,10 , 161,18 , 18,7 , 61,12 , 1058,75 , 1058,75 , 1133,24 , 1085,75 , 1085,75 , 1160,24 , 670,38 , 604,52 , 656,14 , 670,38 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/Morocco + { 8, 162, 1643, 1644, 1563, 1642, 1632, 45, 43, 101, 151,10 , 161,18 , 18,7 , 61,12 , 1058,75 , 1058,75 , 1133,24 , 1085,75 , 1085,75 , 1160,24 , 670,38 , 604,52 , 656,14 , 670,38 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/Oman + { 8, 175, 1643, 1644, 1563, 1642, 1632, 45, 43, 101, 151,10 , 161,18 , 18,7 , 61,12 , 1058,75 , 1058,75 , 1133,24 , 1085,75 , 1085,75 , 1160,24 , 552,52 , 604,52 , 656,14 , 552,52 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/Qatar + { 8, 201, 1643, 1644, 1563, 1642, 1632, 45, 43, 101, 151,10 , 161,18 , 18,7 , 61,12 , 1058,75 , 1058,75 , 1133,24 , 1085,75 , 1085,75 , 1160,24 , 670,38 , 604,52 , 656,14 , 670,38 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/Sudan + { 8, 207, 1643, 1644, 1563, 1642, 1632, 45, 43, 101, 151,10 , 161,18 , 18,7 , 61,12 , 1249,92 , 1249,92 , 1133,24 , 1276,92 , 1276,92 , 1160,24 , 552,52 , 604,52 , 656,14 , 552,52 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/SyrianArabRepublic + { 8, 216, 44, 46, 59, 37, 48, 45, 43, 101, 151,10 , 161,18 , 18,7 , 61,12 , 1058,75 , 1058,75 , 1133,24 , 1085,75 , 1085,75 , 1160,24 , 552,52 , 604,52 , 656,14 , 552,52 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/Tunisia + { 8, 223, 1643, 1644, 1563, 1642, 1632, 45, 43, 101, 151,10 , 161,18 , 18,7 , 61,12 , 1058,75 , 1058,75 , 1133,24 , 1085,75 , 1085,75 , 1160,24 , 670,38 , 604,52 , 656,14 , 670,38 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/UnitedArabEmirates + { 8, 237, 1643, 1644, 1563, 1642, 1632, 45, 43, 101, 151,10 , 161,18 , 18,7 , 61,12 , 1058,75 , 1058,75 , 1133,24 , 1085,75 , 1085,75 , 1160,24 , 552,52 , 604,52 , 656,14 , 552,52 , 604,52 , 656,14 , 12,1 , 13,1 }, // Arabic/Yemen + { 9, 11, 44, 46, 59, 37, 48, 45, 43, 101, 179,8 , 35,18 , 37,5 , 8,10 , 1341,48 , 1389,94 , 1483,27 , 1368,48 , 1416,94 , 134,27 , 708,28 , 736,62 , 798,14 , 708,28 , 736,62 , 798,14 , 13,3 , 14,3 }, // Armenian/Armenia + { 10, 100, 46, 44, 59, 37, 48, 45, 43, 101, 187,8 , 195,18 , 73,8 , 81,12 , 1510,62 , 1572,88 , 1483,27 , 1510,62 , 1572,88 , 134,27 , 812,37 , 849,58 , 798,14 , 812,37 , 849,58 , 798,14 , 16,9 , 17,7 }, // Assamese/India + { 12, 15, 44, 46, 59, 37, 48, 45, 43, 101, 213,8 , 221,19 , 37,5 , 8,10 , 1660,48 , 1708,77 , 1483,27 , 1660,48 , 1708,77 , 134,27 , 907,26 , 933,67 , 99,14 , 907,26 , 933,67 , 99,14 , 0,2 , 0,2 }, // Azerbaijani/Azerbaijan + { 12, 102, 44, 46, 59, 37, 48, 45, 43, 101, 213,8 , 221,19 , 37,5 , 8,10 , 1660,48 , 1708,77 , 1483,27 , 1660,48 , 1708,77 , 134,27 , 907,26 , 933,67 , 99,14 , 907,26 , 933,67 , 99,14 , 0,2 , 0,2 }, // Azerbaijani/Iran + { 14, 197, 44, 46, 59, 37, 48, 45, 43, 101, 72,10 , 240,31 , 37,5 , 8,10 , 1785,48 , 1833,93 , 1926,24 , 1785,48 , 1833,93 , 1926,24 , 1000,21 , 1021,68 , 798,14 , 1000,21 , 1021,68 , 798,14 , 0,2 , 0,2 }, // Basque/Spain + { 15, 18, 46, 44, 59, 37, 2534, 45, 43, 101, 271,6 , 195,18 , 18,7 , 25,12 , 1950,90 , 1950,90 , 2040,33 , 1950,90 , 1950,90 , 2040,33 , 1089,37 , 1126,58 , 1184,18 , 1089,37 , 1126,58 , 1184,18 , 25,9 , 24,7 }, // Bengali/Bangladesh + { 15, 100, 46, 44, 59, 37, 2534, 45, 43, 101, 271,6 , 195,18 , 18,7 , 25,12 , 1950,90 , 1950,90 , 2040,33 , 1950,90 , 1950,90 , 2040,33 , 1089,37 , 1126,58 , 1184,18 , 1089,37 , 1126,58 , 1184,18 , 25,9 , 24,7 }, // Bengali/India + { 16, 25, 46, 44, 59, 37, 48, 45, 43, 101, 72,10 , 277,29 , 93,22 , 115,35 , 2073,75 , 2148,205 , 1483,27 , 2073,75 , 2148,205 , 134,27 , 1202,34 , 1236,79 , 798,14 , 1202,34 , 1236,79 , 798,14 , 0,2 , 0,2 }, // Bhutani/Bhutan + { 19, 74, 46, 44, 59, 37, 48, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 1483,27 , 1483,27 , 1483,27 , 134,27 , 134,27 , 134,27 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 0,2 , 0,2 }, // Breton/France + { 20, 33, 44, 160, 59, 37, 48, 45, 43, 101, 324,8 , 332,18 , 37,5 , 8,10 , 2353,59 , 2412,82 , 2494,24 , 2353,59 , 2412,82 , 2494,24 , 1315,21 , 1336,55 , 1391,14 , 1315,21 , 1336,55 , 1391,14 , 0,2 , 0,2 }, // Bulgarian/Bulgaria + { 21, 147, 46, 44, 4170, 37, 4160, 45, 43, 101, 213,8 , 306,18 , 37,5 , 8,10 , 2518,43 , 2561,88 , 2649,24 , 2518,43 , 2561,88 , 2649,24 , 1405,25 , 1430,54 , 1484,14 , 1405,25 , 1430,54 , 1484,14 , 0,2 , 0,2 }, // Burmese/Myanmar + { 22, 20, 44, 160, 59, 37, 48, 45, 43, 101, 350,6 , 10,17 , 150,5 , 155,10 , 2673,48 , 2721,99 , 2820,24 , 2673,48 , 2721,95 , 2816,24 , 1498,21 , 1519,56 , 1575,14 , 1498,21 , 1519,56 , 1575,14 , 34,10 , 31,13 }, // Byelorussian/Belarus + { 23, 36, 44, 46, 59, 37, 48, 45, 43, 101, 356,8 , 364,30 , 165,4 , 169,26 , 2844,27 , 2871,71 , 1483,27 , 2840,27 , 2867,71 , 134,27 , 1589,19 , 1608,76 , 798,14 , 1589,19 , 1608,76 , 798,14 , 44,5 , 44,5 }, // Cambodian/Cambodia + { 24, 197, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 394,21 , 165,4 , 195,9 , 2942,60 , 3002,82 , 3084,24 , 2938,93 , 3031,115 , 3146,24 , 1684,21 , 1705,60 , 1765,14 , 1779,28 , 1807,60 , 1867,14 , 49,4 , 49,4 }, // Catalan/Spain + { 25, 44, 46, 44, 59, 37, 48, 45, 43, 101, 415,6 , 421,13 , 204,6 , 210,11 , 3108,38 , 3108,38 , 3146,39 , 3170,39 , 3170,39 , 3170,39 , 1881,21 , 1902,28 , 1930,14 , 1881,21 , 1902,28 , 1930,14 , 0,2 , 0,2 }, // Chinese/China + { 25, 97, 46, 44, 59, 37, 48, 45, 43, 101, 434,7 , 421,13 , 204,6 , 221,11 , 3108,38 , 3108,38 , 1483,27 , 3170,39 , 3170,39 , 134,27 , 1944,21 , 1902,28 , 1930,14 , 1944,21 , 1902,28 , 1930,14 , 0,2 , 0,2 }, // Chinese/HongKong + { 25, 126, 46, 44, 59, 37, 48, 45, 43, 101, 434,7 , 441,15 , 204,6 , 221,11 , 3108,38 , 3108,38 , 1483,27 , 3170,39 , 3170,39 , 134,27 , 1944,21 , 1902,28 , 1930,14 , 1944,21 , 1902,28 , 1930,14 , 0,2 , 0,2 }, // Chinese/Macau + { 25, 190, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 421,13 , 232,7 , 210,11 , 3108,38 , 3108,38 , 3146,39 , 3170,39 , 3170,39 , 3170,39 , 1881,21 , 1902,28 , 1930,14 , 1881,21 , 1902,28 , 1930,14 , 0,2 , 0,2 }, // Chinese/Singapore + { 25, 208, 46, 44, 59, 37, 48, 45, 43, 101, 456,6 , 421,13 , 204,6 , 221,11 , 3108,38 , 3108,38 , 1483,27 , 3170,39 , 3170,39 , 134,27 , 1944,21 , 1902,28 , 1930,14 , 1944,21 , 1902,28 , 1930,14 , 0,2 , 0,2 }, // Chinese/Taiwan + { 27, 54, 44, 46, 59, 37, 48, 45, 43, 101, 462,13 , 475,19 , 37,5 , 8,10 , 3185,49 , 3234,94 , 3328,39 , 3209,49 , 3258,98 , 3356,39 , 1965,28 , 1993,58 , 2051,14 , 1965,28 , 1993,58 , 2051,14 , 0,2 , 0,2 }, // Croatian/Croatia + { 28, 57, 44, 160, 59, 37, 48, 45, 43, 101, 350,6 , 494,18 , 165,4 , 195,9 , 3328,39 , 3367,82 , 3449,24 , 134,27 , 3395,84 , 3479,24 , 2065,21 , 2086,49 , 2135,14 , 2065,21 , 2086,49 , 2135,14 , 53,4 , 53,4 }, // Czech/CzechRepublic + { 29, 58, 44, 46, 44, 37, 48, 45, 43, 101, 27,8 , 512,23 , 150,5 , 155,10 , 3473,48 , 3521,84 , 134,24 , 3503,59 , 3562,84 , 320,24 , 2149,28 , 2177,51 , 2228,14 , 2149,28 , 2177,51 , 2228,14 , 57,4 , 57,4 }, // Danish/Denmark + { 30, 151, 44, 46, 59, 37, 48, 45, 43, 101, 535,8 , 99,16 , 37,5 , 8,10 , 3605,48 , 3653,88 , 134,24 , 3646,59 , 3705,88 , 320,24 , 2242,21 , 2263,59 , 2322,14 , 2242,21 , 2263,59 , 2322,14 , 0,2 , 0,2 }, // Dutch/Netherlands + { 30, 21, 44, 46, 59, 37, 48, 45, 43, 101, 543,7 , 99,16 , 37,5 , 8,10 , 3605,48 , 3653,88 , 134,24 , 3646,59 , 3705,88 , 320,24 , 2242,21 , 2263,59 , 2322,14 , 2242,21 , 2263,59 , 2322,14 , 0,2 , 0,2 }, // Dutch/Belgium + { 31, 225, 46, 44, 59, 37, 48, 45, 43, 101, 550,6 , 35,18 , 18,7 , 25,12 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/UnitedStates + { 31, 4, 46, 44, 59, 37, 48, 45, 43, 101, 550,6 , 35,18 , 18,7 , 25,12 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/AmericanSamoa + { 31, 13, 46, 44, 59, 37, 48, 45, 43, 101, 543,7 , 10,17 , 18,7 , 25,12 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/Australia + { 31, 21, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 99,16 , 37,5 , 239,24 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/Belgium + { 31, 22, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 556,12 , 37,5 , 8,10 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/Belize + { 31, 28, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 82,17 , 18,7 , 25,12 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/Botswana + { 31, 38, 46, 44, 59, 37, 48, 45, 43, 101, 115,8 , 568,17 , 18,7 , 25,12 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/Canada + { 31, 89, 46, 44, 59, 37, 48, 45, 43, 101, 550,6 , 35,18 , 18,7 , 25,12 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/Guam + { 31, 97, 46, 44, 59, 37, 48, 45, 43, 101, 271,6 , 195,18 , 18,7 , 25,12 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/HongKong + { 31, 100, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 99,16 , 18,7 , 25,12 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/India + { 31, 104, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 99,16 , 37,5 , 8,10 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 49,4 , 49,4 }, // English/Ireland + { 31, 107, 46, 44, 59, 37, 48, 45, 43, 101, 271,6 , 35,18 , 18,7 , 25,12 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/Jamaica + { 31, 133, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 37,5 , 8,10 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/Malta + { 31, 134, 46, 44, 59, 37, 48, 45, 43, 101, 550,6 , 35,18 , 18,7 , 25,12 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/MarshallIslands + { 31, 137, 46, 44, 59, 37, 48, 45, 43, 101, 550,6 , 35,18 , 18,7 , 25,12 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/Mauritius + { 31, 148, 46, 44, 59, 37, 48, 45, 43, 101, 550,6 , 35,18 , 18,7 , 25,12 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/Namibia + { 31, 154, 46, 44, 59, 37, 48, 45, 43, 101, 543,7 , 10,17 , 18,7 , 25,12 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/NewZealand + { 31, 160, 46, 44, 59, 37, 48, 45, 43, 101, 550,6 , 35,18 , 18,7 , 25,12 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/NorthernMarianaIslands + { 31, 163, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 99,16 , 18,7 , 25,12 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/Pakistan + { 31, 170, 46, 44, 59, 37, 48, 45, 43, 101, 550,6 , 35,18 , 18,7 , 25,12 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/Philippines + { 31, 190, 46, 44, 59, 37, 48, 45, 43, 101, 271,6 , 35,18 , 18,7 , 25,12 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/Singapore + { 31, 195, 44, 160, 59, 37, 48, 45, 43, 101, 585,10 , 82,17 , 18,7 , 25,12 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/SouthAfrica + { 31, 215, 46, 44, 59, 37, 48, 45, 43, 101, 550,6 , 35,18 , 18,7 , 25,12 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/TrinidadAndTobago + { 31, 224, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 37,5 , 8,10 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/UnitedKingdom + { 31, 226, 46, 44, 59, 37, 48, 45, 43, 101, 550,6 , 35,18 , 18,7 , 25,12 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/UnitedStatesMinorOutlyingIslands + { 31, 234, 46, 44, 59, 37, 48, 45, 43, 101, 550,6 , 35,18 , 18,7 , 25,12 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/USVirginIslands + { 31, 240, 46, 44, 59, 37, 48, 45, 43, 101, 356,8 , 82,17 , 18,7 , 25,12 , 0,48 , 48,86 , 134,24 , 0,48 , 48,86 , 320,24 , 0,28 , 28,57 , 85,14 , 0,28 , 28,57 , 85,14 , 0,2 , 0,2 }, // English/Zimbabwe + { 33, 68, 44, 160, 59, 37, 48, 45, 43, 101, 324,8 , 494,18 , 165,4 , 263,9 , 3741,59 , 3800,91 , 3891,24 , 3793,59 , 3852,91 , 3943,24 , 2336,14 , 2350,63 , 2336,14 , 2336,14 , 2350,63 , 2336,14 , 61,14 , 61,16 }, // Estonian/Estonia + { 34, 71, 44, 46, 59, 37, 48, 8722, 43, 101, 535,8 , 82,17 , 37,5 , 8,10 , 3915,48 , 3963,83 , 134,24 , 3967,48 , 4015,83 , 320,24 , 2413,28 , 2441,74 , 2515,14 , 2413,28 , 2441,74 , 2515,14 , 0,2 , 0,2 }, // Faroese/FaroeIslands + { 36, 73, 44, 160, 59, 37, 48, 45, 43, 101, 595,8 , 603,17 , 272,4 , 276,9 , 4046,69 , 4115,105 , 4220,24 , 4098,129 , 4098,129 , 4227,24 , 2529,21 , 2550,67 , 2617,14 , 2529,21 , 2631,81 , 2617,14 , 75,3 , 77,3 }, // Finnish/Finland + { 37, 74, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 99,16 , 37,5 , 8,10 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/France + { 37, 21, 44, 46, 59, 37, 48, 45, 43, 101, 543,7 , 99,16 , 37,5 , 285,23 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Belgium + { 37, 37, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 99,16 , 37,5 , 8,10 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Cameroon + { 37, 38, 44, 160, 59, 37, 48, 45, 43, 101, 115,8 , 99,16 , 37,5 , 239,24 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Canada + { 37, 41, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 99,16 , 37,5 , 8,10 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/CentralAfricanRepublic + { 37, 53, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 99,16 , 37,5 , 8,10 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/IvoryCoast + { 37, 88, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 99,16 , 37,5 , 8,10 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Guadeloupe + { 37, 91, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 99,16 , 37,5 , 8,10 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Guinea + { 37, 125, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 99,16 , 37,5 , 8,10 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Luxembourg + { 37, 128, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 99,16 , 37,5 , 8,10 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Madagascar + { 37, 132, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 99,16 , 37,5 , 8,10 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Mali + { 37, 135, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 99,16 , 37,5 , 8,10 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Martinique + { 37, 142, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 99,16 , 37,5 , 8,10 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Monaco + { 37, 156, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 99,16 , 37,5 , 8,10 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Niger + { 37, 176, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 99,16 , 37,5 , 8,10 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Reunion + { 37, 187, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 99,16 , 37,5 , 8,10 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Senegal + { 37, 206, 46, 39, 59, 37, 48, 45, 43, 101, 324,8 , 10,17 , 37,5 , 308,14 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Switzerland + { 37, 244, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 99,16 , 37,5 , 8,10 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Saint Barthelemy + { 37, 245, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 99,16 , 37,5 , 8,10 , 4244,63 , 4307,85 , 134,24 , 4251,63 , 4314,85 , 320,24 , 2712,35 , 2747,52 , 2799,14 , 2712,35 , 2747,52 , 2799,14 , 0,2 , 0,2 }, // French/Saint Martin + { 40, 197, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 82,17 , 37,5 , 8,10 , 4392,48 , 4440,87 , 4527,24 , 4399,48 , 4447,87 , 4534,24 , 2813,28 , 2841,49 , 2890,14 , 2813,28 , 2841,49 , 2890,14 , 0,2 , 0,2 }, // Galician/Spain + { 41, 81, 44, 46, 59, 37, 48, 45, 43, 101, 213,8 , 306,18 , 37,5 , 8,10 , 4551,48 , 4599,99 , 4698,24 , 4558,48 , 4606,99 , 4705,24 , 2904,28 , 2932,62 , 2994,14 , 2904,28 , 2932,62 , 2994,14 , 0,2 , 0,2 }, // Georgian/Georgia + { 42, 82, 44, 46, 59, 37, 48, 45, 43, 101, 324,8 , 494,18 , 37,5 , 8,10 , 4722,52 , 4774,83 , 134,24 , 4729,48 , 4777,83 , 320,24 , 3008,21 , 3029,60 , 3089,14 , 3103,28 , 3029,60 , 3089,14 , 0,2 , 0,2 }, // German/Germany + { 42, 14, 44, 46, 59, 37, 48, 45, 43, 101, 324,8 , 620,19 , 37,5 , 8,10 , 4722,52 , 4857,83 , 134,24 , 4860,48 , 4908,83 , 320,24 , 3008,21 , 3029,60 , 3089,14 , 3103,28 , 3029,60 , 3089,14 , 0,2 , 0,2 }, // German/Austria + { 42, 21, 44, 46, 59, 37, 48, 45, 43, 101, 543,7 , 99,16 , 37,5 , 239,24 , 4722,52 , 4774,83 , 134,24 , 4729,48 , 4777,83 , 320,24 , 3008,21 , 3029,60 , 3089,14 , 3131,28 , 3029,60 , 3089,14 , 0,2 , 0,2 }, // German/Belgium + { 42, 123, 46, 39, 59, 37, 48, 45, 43, 101, 324,8 , 494,18 , 37,5 , 8,10 , 4722,52 , 4774,83 , 134,24 , 4729,48 , 4777,83 , 320,24 , 3008,21 , 3029,60 , 3089,14 , 3103,28 , 3029,60 , 3089,14 , 0,2 , 0,2 }, // German/Liechtenstein + { 42, 125, 44, 46, 59, 37, 48, 45, 43, 101, 324,8 , 494,18 , 37,5 , 8,10 , 4722,52 , 4774,83 , 134,24 , 4729,48 , 4777,83 , 320,24 , 3008,21 , 3029,60 , 3089,14 , 3103,28 , 3029,60 , 3089,14 , 0,2 , 0,2 }, // German/Luxembourg + { 42, 206, 46, 39, 59, 37, 48, 45, 43, 101, 324,8 , 494,18 , 37,5 , 8,10 , 4722,52 , 4774,83 , 134,24 , 4729,48 , 4777,83 , 320,24 , 3008,21 , 3029,60 , 3089,14 , 3103,28 , 3029,60 , 3089,14 , 0,2 , 0,2 }, // German/Switzerland + { 43, 85, 44, 46, 44, 37, 48, 45, 43, 101, 271,6 , 10,17 , 18,7 , 25,12 , 4940,50 , 4990,115 , 5105,24 , 4991,50 , 5041,115 , 5156,24 , 3159,28 , 3187,55 , 3242,14 , 3159,28 , 3187,55 , 3242,14 , 78,4 , 80,4 }, // Greek/Greece + { 43, 56, 44, 46, 44, 37, 48, 45, 43, 101, 271,6 , 10,17 , 18,7 , 25,12 , 4940,50 , 4990,115 , 5105,24 , 4991,50 , 5041,115 , 5156,24 , 3159,28 , 3187,55 , 3242,14 , 3159,28 , 3187,55 , 3242,14 , 78,4 , 80,4 }, // Greek/Cyprus + { 44, 86, 44, 46, 59, 37, 48, 8722, 43, 101, 72,10 , 82,17 , 18,7 , 25,12 , 3473,48 , 5129,96 , 134,24 , 5180,48 , 5228,96 , 320,24 , 3256,28 , 3284,98 , 3382,14 , 3256,28 , 3284,98 , 3382,14 , 0,2 , 0,2 }, // Greenlandic/Greenland + { 46, 100, 46, 44, 59, 37, 48, 45, 43, 101, 639,7 , 195,18 , 322,8 , 330,13 , 5225,67 , 5292,87 , 5379,31 , 5324,67 , 5391,87 , 5478,31 , 3396,32 , 3428,53 , 3481,19 , 3396,32 , 3428,53 , 3481,19 , 82,14 , 84,14 }, // Gujarati/India + { 47, 83, 46, 44, 59, 37, 48, 45, 43, 101, 271,6 , 195,18 , 37,5 , 8,10 , 5410,48 , 5458,85 , 5543,24 , 5509,48 , 5557,85 , 5642,24 , 3500,21 , 3521,52 , 3573,14 , 3500,21 , 3521,52 , 3573,14 , 0,2 , 0,2 }, // Hausa/Ghana + { 47, 156, 46, 44, 59, 37, 48, 45, 43, 101, 271,6 , 195,18 , 37,5 , 8,10 , 5410,48 , 5458,85 , 5543,24 , 5509,48 , 5557,85 , 5642,24 , 3500,21 , 3521,52 , 3573,14 , 3500,21 , 3521,52 , 3573,14 , 0,2 , 0,2 }, // Hausa/Niger + { 47, 157, 46, 44, 59, 37, 48, 45, 43, 101, 271,6 , 195,18 , 37,5 , 8,10 , 5410,48 , 5458,85 , 5543,24 , 5509,48 , 5557,85 , 5642,24 , 3500,21 , 3521,52 , 3573,14 , 3500,21 , 3521,52 , 3573,14 , 0,2 , 0,2 }, // Hausa/Nigeria + { 47, 201, 46, 44, 59, 37, 48, 45, 43, 101, 271,6 , 195,18 , 37,5 , 8,10 , 5567,55 , 5622,99 , 5543,24 , 5666,55 , 5721,99 , 5642,24 , 3587,31 , 3618,57 , 3573,14 , 3587,31 , 3618,57 , 3573,14 , 0,2 , 0,2 }, // Hausa/Sudan + { 48, 105, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 646,18 , 37,5 , 8,10 , 5721,58 , 5779,72 , 1483,27 , 5820,48 , 5868,72 , 134,27 , 3675,46 , 3721,65 , 3786,14 , 3675,46 , 3721,65 , 3786,14 , 96,6 , 98,5 }, // Hebrew/Israel + { 49, 100, 46, 44, 59, 37, 2406, 45, 43, 101, 664,6 , 10,17 , 18,7 , 25,12 , 5851,75 , 5851,75 , 5926,30 , 5940,75 , 5940,75 , 6015,30 , 3800,38 , 3838,57 , 3895,19 , 3800,38 , 3838,57 , 3895,19 , 102,9 , 103,7 }, // Hindi/India + { 50, 98, 44, 160, 59, 37, 48, 45, 43, 101, 670,11 , 681,19 , 165,4 , 195,9 , 5956,64 , 6020,98 , 6118,25 , 6045,64 , 6109,98 , 6207,25 , 3914,19 , 3933,52 , 3985,17 , 3914,19 , 3933,52 , 3985,17 , 111,3 , 110,3 }, // Hungarian/Hungary + { 51, 99, 44, 46, 59, 37, 48, 8722, 43, 101, 595,8 , 494,18 , 37,5 , 8,10 , 6143,48 , 6191,82 , 6273,24 , 6232,48 , 6280,82 , 6362,24 , 4002,28 , 4030,81 , 4111,14 , 4002,28 , 4030,81 , 4125,14 , 114,4 , 113,4 }, // Icelandic/Iceland + { 52, 101, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 123,18 , 150,5 , 276,9 , 6297,48 , 6345,87 , 134,24 , 6386,48 , 6434,87 , 320,24 , 4139,28 , 4167,43 , 4210,14 , 4139,28 , 4167,43 , 4210,14 , 0,2 , 0,2 }, // Indonesian/Indonesia + { 57, 104, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 99,16 , 37,5 , 8,10 , 6432,62 , 6494,107 , 6601,24 , 6521,62 , 6583,107 , 6690,24 , 4224,37 , 4261,75 , 4336,14 , 4224,37 , 4261,75 , 4336,14 , 49,4 , 49,4 }, // Irish/Ireland + { 58, 106, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 99,16 , 37,5 , 8,10 , 6625,48 , 6673,94 , 6767,24 , 6714,48 , 6762,94 , 6856,24 , 4350,28 , 4378,57 , 4435,14 , 4350,28 , 4449,57 , 4435,14 , 118,2 , 117,2 }, // Italian/Italy + { 58, 206, 46, 39, 59, 37, 48, 45, 43, 101, 324,8 , 10,17 , 37,5 , 308,14 , 6625,48 , 6673,94 , 6767,24 , 6714,48 , 6762,94 , 6856,24 , 4350,28 , 4378,57 , 4435,14 , 4350,28 , 4449,57 , 4435,14 , 118,2 , 117,2 }, // Italian/Switzerland + { 59, 108, 46, 44, 59, 37, 48, 45, 43, 101, 213,8 , 421,13 , 165,4 , 343,10 , 3146,39 , 3146,39 , 1483,27 , 3170,39 , 3170,39 , 134,27 , 4506,14 , 4520,28 , 4506,14 , 4506,14 , 4520,28 , 4506,14 , 120,2 , 119,2 }, // Japanese/Japan + { 61, 100, 46, 44, 59, 37, 3302, 45, 43, 101, 664,6 , 99,16 , 322,8 , 330,13 , 6791,86 , 6791,86 , 6877,31 , 6880,86 , 6880,86 , 6966,31 , 4548,28 , 4576,53 , 4629,19 , 4548,28 , 4576,53 , 4629,19 , 122,2 , 121,2 }, // Kannada/India + { 63, 110, 44, 160, 59, 37, 48, 45, 43, 101, 324,8 , 700,22 , 37,5 , 8,10 , 6908,61 , 6969,83 , 1483,27 , 6997,61 , 7058,83 , 134,27 , 4648,28 , 4676,54 , 798,14 , 4648,28 , 4676,54 , 798,14 , 0,2 , 0,2 }, // Kazakh/Kazakhstan + { 64, 179, 44, 46, 59, 37, 48, 45, 43, 101, 213,8 , 306,18 , 37,5 , 8,10 , 7052,60 , 7112,101 , 1483,27 , 7141,60 , 7201,101 , 134,27 , 4730,35 , 4765,84 , 798,14 , 4730,35 , 4765,84 , 798,14 , 0,2 , 0,2 }, // Kinyarwanda/Rwanda + { 65, 116, 44, 160, 59, 37, 48, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 1483,27 , 1483,27 , 1483,27 , 134,27 , 134,27 , 134,27 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 0,2 , 0,2 }, // Kirghiz/Kyrgyzstan + { 66, 114, 46, 44, 59, 37, 48, 45, 43, 101, 722,9 , 731,16 , 353,7 , 360,13 , 7213,39 , 7213,39 , 7213,39 , 7302,39 , 7302,39 , 7302,39 , 4849,14 , 4863,28 , 4849,14 , 4849,14 , 4863,28 , 4849,14 , 124,2 , 123,2 }, // Korean/RepublicOfKorea + { 67, 102, 46, 44, 59, 37, 48, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 1483,27 , 1483,27 , 1483,27 , 134,27 , 134,27 , 134,27 , 4891,42 , 4891,42 , 4933,14 , 4891,42 , 4891,42 , 4933,14 , 0,2 , 0,2 }, // Kurdish/Iran + { 67, 103, 46, 44, 59, 37, 48, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 1483,27 , 1483,27 , 1483,27 , 134,27 , 134,27 , 134,27 , 4891,42 , 4891,42 , 4933,14 , 4891,42 , 4891,42 , 4933,14 , 0,2 , 0,2 }, // Kurdish/Iraq + { 67, 207, 46, 44, 59, 37, 48, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 7252,41 , 7293,51 , 7344,27 , 7341,41 , 7382,51 , 7433,27 , 4947,20 , 4967,39 , 5006,14 , 4947,20 , 4967,39 , 5006,14 , 0,2 , 0,2 }, // Kurdish/SyrianArabRepublic + { 67, 217, 46, 44, 59, 37, 48, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 7252,41 , 7293,51 , 7344,27 , 7341,41 , 7382,51 , 7433,27 , 4947,20 , 4967,39 , 5006,14 , 4947,20 , 4967,39 , 5006,14 , 0,2 , 0,2 }, // Kurdish/Turkey + { 69, 117, 46, 44, 59, 37, 48, 45, 43, 101, 356,8 , 747,18 , 165,4 , 373,21 , 7371,63 , 7434,75 , 1483,27 , 7460,63 , 7523,75 , 134,27 , 5020,24 , 5044,57 , 798,14 , 5020,24 , 5044,57 , 798,14 , 0,2 , 0,2 }, // Laothian/Lao + { 71, 118, 44, 160, 59, 37, 48, 8722, 43, 101, 324,8 , 765,26 , 37,5 , 8,10 , 7509,65 , 7574,101 , 134,24 , 7598,65 , 7663,101 , 320,24 , 5101,21 , 5122,72 , 5194,14 , 5101,21 , 5122,72 , 5194,14 , 126,14 , 125,11 }, // Latvian/Latvia + { 72, 49, 46, 44, 59, 37, 48, 45, 43, 101, 213,8 , 306,18 , 37,5 , 8,10 , 7675,39 , 7714,203 , 1483,27 , 7764,39 , 7803,203 , 134,27 , 5208,23 , 5231,98 , 798,14 , 5208,23 , 5231,98 , 798,14 , 0,2 , 0,2 }, // Lingala/DemocraticRepublicOfCongo + { 72, 50, 46, 44, 59, 37, 48, 45, 43, 101, 213,8 , 306,18 , 37,5 , 8,10 , 7675,39 , 7714,203 , 1483,27 , 7764,39 , 7803,203 , 134,27 , 5208,23 , 5231,98 , 798,14 , 5208,23 , 5231,98 , 798,14 , 0,2 , 0,2 }, // Lingala/PeoplesRepublicOfCongo + { 73, 124, 44, 46, 59, 37, 48, 8722, 43, 101, 72,10 , 791,26 , 37,5 , 8,10 , 7917,69 , 7986,96 , 8082,24 , 8006,48 , 8054,96 , 8150,24 , 5329,17 , 5346,89 , 5435,14 , 5449,21 , 5346,89 , 5435,14 , 140,9 , 136,6 }, // Lithuanian/Lithuania + { 74, 127, 44, 46, 59, 37, 48, 45, 43, 101, 817,7 , 123,18 , 37,5 , 8,10 , 8106,63 , 8169,85 , 8254,24 , 8174,63 , 8237,85 , 8322,24 , 5470,34 , 5504,54 , 1391,14 , 5470,34 , 5504,54 , 1391,14 , 149,10 , 142,8 }, // Macedonian/Macedonia + { 75, 128, 46, 44, 59, 37, 48, 45, 43, 101, 356,8 , 99,16 , 37,5 , 8,10 , 8278,48 , 8326,92 , 134,24 , 8346,48 , 8394,92 , 320,24 , 5558,34 , 5592,60 , 5652,14 , 5558,34 , 5592,60 , 5652,14 , 0,2 , 0,2 }, // Malagasy/Madagascar + { 76, 130, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 824,16 , 394,4 , 25,12 , 8418,49 , 8467,82 , 1483,27 , 8486,49 , 8535,82 , 134,27 , 5666,28 , 5694,43 , 798,14 , 5666,28 , 5694,43 , 798,14 , 0,2 , 0,2 }, // Malay/Malaysia + { 76, 32, 44, 46, 59, 37, 48, 45, 43, 101, 141,10 , 556,12 , 165,4 , 398,14 , 8418,49 , 8467,82 , 1483,27 , 8486,49 , 8535,82 , 134,27 , 5666,28 , 5694,43 , 798,14 , 5666,28 , 5694,43 , 798,14 , 0,2 , 0,2 }, // Malay/BruneiDarussalam + { 77, 100, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 840,18 , 18,7 , 25,12 , 8549,66 , 8615,101 , 8716,31 , 8617,66 , 8683,101 , 8784,31 , 5737,47 , 5784,70 , 5854,22 , 5737,47 , 5784,70 , 5854,22 , 159,6 , 150,10 }, // Malayalam/India + { 78, 133, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 858,23 , 37,5 , 8,10 , 8747,48 , 8795,86 , 8881,24 , 8815,48 , 8863,86 , 8949,24 , 5876,28 , 5904,63 , 5967,14 , 5876,28 , 5904,63 , 5967,14 , 165,2 , 160,2 }, // Maltese/Malta + { 79, 154, 46, 44, 59, 37, 48, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 8905,83 , 8905,83 , 1483,27 , 8973,83 , 8973,83 , 134,27 , 5981,48 , 5981,48 , 798,14 , 5981,48 , 5981,48 , 798,14 , 0,2 , 0,2 }, // Maori/NewZealand + { 80, 100, 46, 44, 59, 37, 2406, 45, 43, 101, 664,6 , 99,16 , 412,7 , 419,12 , 8988,86 , 8988,86 , 9074,32 , 9056,86 , 9056,86 , 9142,32 , 6029,32 , 6061,53 , 3895,19 , 6029,32 , 6061,53 , 3895,19 , 122,2 , 121,2 }, // Marathi/India + { 82, 44, 44, 160, 59, 37, 48, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 9106,48 , 9154,66 , 1483,27 , 9174,48 , 9222,66 , 134,27 , 6114,21 , 6135,43 , 798,14 , 6114,21 , 6135,43 , 798,14 , 0,2 , 0,2 }, // Mongolian/China + { 82, 143, 44, 160, 59, 37, 48, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 9106,48 , 9154,66 , 1483,27 , 9174,48 , 9222,66 , 134,27 , 6114,21 , 6135,43 , 798,14 , 6114,21 , 6135,43 , 798,14 , 0,2 , 0,2 }, // Mongolian/Mongolia + { 84, 100, 46, 44, 59, 37, 2406, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 9220,56 , 9276,80 , 9356,27 , 9288,56 , 9344,80 , 9424,27 , 6178,33 , 6211,54 , 6265,14 , 6178,33 , 6211,54 , 6265,14 , 102,9 , 103,7 }, // Nepali/India + { 84, 150, 46, 44, 59, 37, 2406, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 9220,56 , 9383,85 , 9356,27 , 9288,56 , 9451,85 , 9424,27 , 6178,33 , 6279,54 , 6265,14 , 6178,33 , 6279,54 , 6265,14 , 167,14 , 162,14 }, // Nepali/Nepal + { 85, 161, 44, 160, 59, 37, 48, 45, 43, 101, 324,8 , 603,17 , 37,5 , 431,16 , 9468,59 , 9527,83 , 134,24 , 9536,59 , 9595,83 , 320,24 , 6333,28 , 2177,51 , 2228,14 , 6361,35 , 2177,51 , 2228,14 , 0,2 , 0,2 }, // Norwegian/Norway + { 86, 74, 46, 44, 59, 37, 48, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 9610,83 , 9610,83 , 1483,27 , 9678,83 , 9678,83 , 134,27 , 6396,57 , 6396,57 , 798,14 , 6396,57 , 6396,57 , 798,14 , 0,2 , 0,2 }, // Occitan/France + { 87, 100, 46, 44, 59, 37, 2918, 45, 43, 101, 664,6 , 10,17 , 18,7 , 25,12 , 9693,89 , 9693,89 , 9782,32 , 9761,89 , 9761,89 , 9850,32 , 6453,33 , 6486,54 , 6540,18 , 6453,33 , 6486,54 , 6540,18 , 122,2 , 121,2 }, // Oriya/India + { 88, 1, 1643, 1644, 59, 1642, 1776, 8722, 43, 101, 881,8 , 889,20 , 165,4 , 447,11 , 9814,68 , 9814,68 , 1483,27 , 9882,68 , 9882,68 , 134,27 , 6558,49 , 6558,49 , 798,14 , 6558,49 , 6558,49 , 798,14 , 181,4 , 176,4 }, // Pashto/Afghanistan + { 89, 102, 1643, 1644, 1563, 1642, 1776, 8722, 43, 101, 550,6 , 35,18 , 165,4 , 447,11 , 9882,71 , 9953,70 , 10023,25 , 9950,71 , 10021,73 , 10094,25 , 6558,49 , 6558,49 , 6607,14 , 6558,49 , 6558,49 , 6607,14 , 185,10 , 180,10 }, // Persian/Iran + { 89, 1, 1643, 1644, 1563, 1642, 1776, 8722, 43, 101, 550,6 , 35,18 , 165,4 , 447,11 , 10048,63 , 9953,70 , 10111,24 , 10119,63 , 10182,68 , 10250,24 , 6558,49 , 6558,49 , 6607,14 , 6558,49 , 6558,49 , 6607,14 , 185,10 , 180,10 }, // Persian/Afghanistan + { 90, 172, 44, 160, 59, 37, 48, 45, 43, 101, 535,8 , 10,17 , 37,5 , 8,10 , 10135,48 , 10183,97 , 10280,24 , 10274,48 , 10322,99 , 10421,24 , 6621,34 , 6655,59 , 6714,14 , 6621,34 , 6655,59 , 6714,14 , 0,2 , 0,2 }, // Polish/Poland + { 91, 173, 44, 160, 59, 37, 48, 45, 43, 101, 27,8 , 909,27 , 37,5 , 458,19 , 10304,48 , 10352,89 , 134,24 , 10445,48 , 10493,89 , 320,24 , 6728,28 , 6756,79 , 6835,14 , 6728,28 , 6756,79 , 6835,14 , 195,17 , 190,18 }, // Portuguese/Portugal + { 91, 30, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 909,27 , 37,5 , 458,19 , 10441,48 , 10489,89 , 134,24 , 10582,48 , 10630,89 , 320,24 , 6728,28 , 6849,79 , 6835,14 , 6728,28 , 6849,79 , 6835,14 , 0,2 , 0,2 }, // Portuguese/Brazil + { 91, 92, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 909,27 , 37,5 , 458,19 , 10441,48 , 10489,89 , 134,24 , 10582,48 , 10630,89 , 320,24 , 6728,28 , 6849,79 , 6835,14 , 6728,28 , 6849,79 , 6835,14 , 0,2 , 0,2 }, // Portuguese/GuineaBissau + { 91, 146, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 909,27 , 37,5 , 458,19 , 10441,48 , 10489,89 , 134,24 , 10582,48 , 10630,89 , 320,24 , 6728,28 , 6849,79 , 6835,14 , 6728,28 , 6849,79 , 6835,14 , 0,2 , 0,2 }, // Portuguese/Mozambique + { 92, 100, 46, 44, 59, 37, 2662, 45, 43, 101, 141,10 , 123,18 , 18,7 , 25,12 , 10578,68 , 10578,68 , 10646,27 , 10719,68 , 10719,68 , 10787,27 , 6928,38 , 6966,55 , 7021,23 , 6928,38 , 6966,55 , 7021,23 , 212,5 , 208,4 }, // Punjabi/India + { 92, 163, 46, 44, 59, 37, 2662, 45, 43, 101, 141,10 , 123,18 , 18,7 , 25,12 , 10673,67 , 10673,67 , 10646,27 , 10814,67 , 10814,67 , 10787,27 , 6928,38 , 7044,37 , 7021,23 , 6928,38 , 7044,37 , 7021,23 , 212,5 , 208,4 }, // Punjabi/Pakistan + { 94, 206, 46, 8217, 59, 37, 48, 8722, 43, 101, 324,8 , 494,18 , 37,5 , 8,10 , 10740,67 , 10807,92 , 10899,24 , 10881,67 , 10948,92 , 11040,24 , 7081,23 , 7104,56 , 7160,14 , 7081,23 , 7104,56 , 7160,14 , 122,2 , 212,2 }, // RhaetoRomance/Switzerland + { 95, 141, 44, 46, 59, 37, 48, 45, 43, 101, 936,10 , 10,17 , 37,5 , 8,10 , 10923,60 , 10983,98 , 11081,24 , 11064,60 , 11124,98 , 11222,24 , 7174,21 , 7195,48 , 2799,14 , 7174,21 , 7195,48 , 2799,14 , 0,2 , 0,2 }, // Romanian/Moldova + { 95, 177, 44, 46, 59, 37, 48, 45, 43, 101, 936,10 , 10,17 , 37,5 , 8,10 , 10923,60 , 10983,98 , 11081,24 , 11064,60 , 11124,98 , 11222,24 , 7174,21 , 7195,48 , 2799,14 , 7174,21 , 7195,48 , 2799,14 , 0,2 , 0,2 }, // Romanian/Romania + { 96, 178, 44, 160, 59, 37, 48, 45, 43, 101, 324,8 , 946,22 , 165,4 , 195,9 , 11105,62 , 11167,80 , 11247,24 , 11246,63 , 11309,82 , 11391,24 , 7243,21 , 7264,62 , 7326,14 , 7243,21 , 7340,62 , 7326,14 , 0,2 , 0,2 }, // Russian/RussianFederation + { 96, 141, 44, 160, 59, 37, 48, 45, 43, 101, 324,8 , 946,22 , 165,4 , 195,9 , 11105,62 , 11167,80 , 11247,24 , 11246,63 , 11309,82 , 11391,24 , 7243,21 , 7264,62 , 7326,14 , 7243,21 , 7340,62 , 7326,14 , 0,2 , 0,2 }, // Russian/Moldova + { 96, 222, 44, 160, 59, 37, 48, 45, 43, 101, 324,8 , 946,22 , 37,5 , 8,10 , 11105,62 , 11167,80 , 11247,24 , 11246,63 , 11309,82 , 11391,24 , 7243,21 , 7264,62 , 7326,14 , 7243,21 , 7340,62 , 7326,14 , 0,2 , 0,2 }, // Russian/Ukraine + { 98, 41, 44, 46, 59, 37, 48, 45, 43, 101, 356,8 , 99,16 , 37,5 , 8,10 , 11271,48 , 11319,91 , 11410,24 , 11415,48 , 11463,91 , 11554,24 , 7402,28 , 7430,66 , 7496,14 , 7402,28 , 7430,66 , 7496,14 , 217,2 , 214,2 }, // Sangho/CentralAfricanRepublic + { 99, 100, 46, 44, 59, 37, 2406, 45, 43, 101, 639,7 , 99,16 , 322,8 , 330,13 , 1483,27 , 1483,27 , 1483,27 , 134,27 , 134,27 , 134,27 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 0,2 , 0,2 }, // Sanskrit/India + { 100, 241, 46, 44, 59, 37, 48, 45, 43, 101, 968,7 , 975,20 , 150,5 , 155,10 , 11434,48 , 11482,81 , 8254,24 , 11578,48 , 11626,81 , 8322,24 , 7510,28 , 7538,52 , 7590,14 , 7510,28 , 7538,52 , 7590,14 , 219,9 , 216,7 }, // Serbian/SerbiaAndMontenegro + { 100, 27, 46, 44, 59, 37, 48, 45, 43, 101, 115,8 , 975,20 , 37,5 , 477,40 , 11434,48 , 11563,83 , 8254,24 , 11578,48 , 11707,83 , 8322,24 , 7604,28 , 7632,54 , 7590,14 , 7604,28 , 7632,54 , 7590,14 , 219,9 , 216,7 }, // Serbian/BosniaAndHerzegowina + { 100, 238, 46, 44, 59, 37, 48, 45, 43, 101, 968,7 , 975,20 , 150,5 , 155,10 , 11434,48 , 11482,81 , 8254,24 , 11578,48 , 11626,81 , 8322,24 , 7510,28 , 7538,52 , 7590,14 , 7510,28 , 7538,52 , 7590,14 , 219,9 , 216,7 }, // Serbian/Yugoslavia + { 100, 242, 46, 44, 59, 37, 48, 45, 43, 101, 968,7 , 975,20 , 150,5 , 155,10 , 11646,48 , 11694,81 , 11775,24 , 11790,48 , 11838,81 , 11919,24 , 7686,28 , 7714,54 , 2051,14 , 7686,28 , 7714,54 , 2051,14 , 228,9 , 223,7 }, // Serbian/Montenegro + { 100, 243, 46, 44, 59, 37, 48, 45, 43, 101, 968,7 , 975,20 , 150,5 , 155,10 , 11434,48 , 11482,81 , 8254,24 , 11578,48 , 11626,81 , 8322,24 , 7510,28 , 7538,52 , 7590,14 , 7510,28 , 7538,52 , 7590,14 , 219,9 , 216,7 }, // Serbian/Serbia + { 101, 241, 46, 44, 59, 37, 48, 45, 43, 101, 968,7 , 975,20 , 150,5 , 155,10 , 11646,48 , 11694,81 , 11775,24 , 11790,48 , 11838,81 , 11919,24 , 7686,28 , 7714,54 , 2051,14 , 7686,28 , 7714,54 , 2051,14 , 228,9 , 223,7 }, // SerboCroatian/SerbiaAndMontenegro + { 101, 27, 46, 44, 59, 37, 48, 45, 43, 101, 968,7 , 975,20 , 150,5 , 155,10 , 11646,48 , 11694,81 , 11775,24 , 11790,48 , 11838,81 , 11919,24 , 7686,28 , 7714,54 , 2051,14 , 7686,28 , 7714,54 , 2051,14 , 228,9 , 223,7 }, // SerboCroatian/BosniaAndHerzegowina + { 101, 238, 46, 44, 59, 37, 48, 45, 43, 101, 968,7 , 975,20 , 150,5 , 155,10 , 11646,48 , 11694,81 , 11775,24 , 11790,48 , 11838,81 , 11919,24 , 7686,28 , 7714,54 , 2051,14 , 7686,28 , 7714,54 , 2051,14 , 228,9 , 223,7 }, // SerboCroatian/Yugoslavia + { 102, 120, 44, 160, 59, 37, 48, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 11799,48 , 11847,105 , 1483,27 , 11943,48 , 11991,105 , 134,27 , 7768,27 , 7795,61 , 798,14 , 7768,27 , 7795,61 , 798,14 , 0,2 , 0,2 }, // Sesotho/Lesotho + { 102, 195, 44, 160, 59, 37, 48, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 11799,48 , 11847,105 , 1483,27 , 11943,48 , 11991,105 , 134,27 , 7768,27 , 7795,61 , 798,14 , 7768,27 , 7795,61 , 798,14 , 0,2 , 0,2 }, // Sesotho/SouthAfrica + { 103, 195, 44, 160, 59, 37, 48, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 11952,48 , 12000,117 , 1483,27 , 12096,48 , 12144,117 , 134,27 , 7856,27 , 7883,64 , 798,14 , 7856,27 , 7883,64 , 798,14 , 0,2 , 0,2 }, // Setswana/SouthAfrica + { 104, 240, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 12117,47 , 12164,100 , 12264,24 , 12261,47 , 12308,100 , 12408,24 , 7947,32 , 7979,55 , 8034,14 , 7947,32 , 7979,55 , 8034,14 , 0,2 , 0,2 }, // Shona/Zimbabwe + { 106, 198, 46, 44, 59, 37, 48, 45, 43, 101, 585,10 , 995,17 , 18,7 , 25,12 , 12288,54 , 12342,92 , 12434,32 , 12432,54 , 12486,92 , 12578,32 , 8048,30 , 8078,62 , 8140,19 , 8048,30 , 8078,62 , 8140,19 , 237,5 , 230,4 }, // Singhalese/SriLanka + { 107, 195, 44, 160, 59, 37, 48, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 12466,48 , 12514,114 , 1483,27 , 12610,48 , 12658,114 , 134,27 , 8159,27 , 8186,68 , 798,14 , 8159,27 , 8186,68 , 798,14 , 0,2 , 0,2 }, // Siswati/SouthAfrica + { 107, 204, 44, 160, 59, 37, 48, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 12466,48 , 12514,114 , 1483,27 , 12610,48 , 12658,114 , 134,27 , 8159,27 , 8186,68 , 798,14 , 8159,27 , 8186,68 , 798,14 , 0,2 , 0,2 }, // Siswati/Swaziland + { 108, 191, 44, 160, 59, 37, 48, 45, 43, 101, 595,8 , 494,18 , 165,4 , 195,9 , 12628,48 , 12676,82 , 11775,24 , 12772,48 , 12820,89 , 11919,24 , 8254,21 , 8275,52 , 8327,14 , 8254,21 , 8275,52 , 8327,14 , 242,10 , 234,9 }, // Slovak/Slovakia + { 109, 192, 44, 46, 59, 37, 48, 45, 43, 101, 1012,9 , 620,19 , 37,5 , 8,10 , 11646,48 , 12758,86 , 11775,24 , 11790,48 , 12909,86 , 11919,24 , 8341,28 , 8369,52 , 8421,14 , 8341,28 , 8369,52 , 8421,14 , 53,4 , 243,4 }, // Slovenian/Slovenia + { 110, 194, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 53,19 , 18,7 , 25,12 , 12844,48 , 12892,189 , 13081,24 , 12995,48 , 13043,189 , 13232,24 , 8435,28 , 8463,47 , 8510,14 , 8435,28 , 8463,47 , 8510,14 , 252,3 , 247,3 }, // Somali/Somalia + { 110, 59, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 53,19 , 18,7 , 25,12 , 12844,48 , 12892,189 , 13081,24 , 12995,48 , 13043,189 , 13232,24 , 8435,28 , 8463,47 , 8510,14 , 8435,28 , 8463,47 , 8510,14 , 252,3 , 247,3 }, // Somali/Djibouti + { 110, 69, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 53,19 , 18,7 , 25,12 , 12844,48 , 12892,189 , 13081,24 , 12995,48 , 13043,189 , 13232,24 , 8435,28 , 8463,47 , 8510,14 , 8435,28 , 8463,47 , 8510,14 , 252,3 , 247,3 }, // Somali/Ethiopia + { 110, 111, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 53,19 , 18,7 , 25,12 , 12844,48 , 12892,189 , 13081,24 , 12995,48 , 13043,189 , 13232,24 , 8435,28 , 8463,47 , 8510,14 , 8435,28 , 8463,47 , 8510,14 , 252,3 , 247,3 }, // Somali/Kenya + { 111, 197, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 1021,26 , 37,5 , 8,10 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/Spain + { 111, 10, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 1021,26 , 37,5 , 517,14 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/Argentina + { 111, 26, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 1021,26 , 37,5 , 8,10 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/Bolivia + { 111, 43, 44, 46, 59, 37, 48, 45, 43, 101, 535,8 , 1021,26 , 165,4 , 8,10 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/Chile + { 111, 47, 44, 46, 59, 37, 48, 45, 43, 101, 543,7 , 1021,26 , 165,4 , 8,10 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/Colombia + { 111, 52, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 1021,26 , 37,5 , 8,10 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/CostaRica + { 111, 61, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 1021,26 , 37,5 , 8,10 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/DominicanRepublic + { 111, 63, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 1021,26 , 165,4 , 8,10 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/Ecuador + { 111, 65, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 1021,26 , 37,5 , 8,10 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/ElSalvador + { 111, 66, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 1021,26 , 37,5 , 8,10 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/EquatorialGuinea + { 111, 90, 46, 44, 59, 37, 48, 45, 43, 101, 543,7 , 1021,26 , 37,5 , 8,10 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/Guatemala + { 111, 96, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 1047,27 , 37,5 , 8,10 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/Honduras + { 111, 139, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 1021,26 , 37,5 , 8,10 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/Mexico + { 111, 155, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 1021,26 , 37,5 , 8,10 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/Nicaragua + { 111, 166, 46, 44, 59, 37, 48, 45, 43, 101, 179,8 , 1021,26 , 37,5 , 8,10 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/Panama + { 111, 168, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 1021,26 , 37,5 , 8,10 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/Paraguay + { 111, 169, 46, 44, 59, 37, 48, 45, 43, 101, 543,7 , 1021,26 , 37,5 , 531,15 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/Peru + { 111, 174, 46, 44, 59, 37, 48, 45, 43, 101, 179,8 , 1021,26 , 37,5 , 8,10 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/PuertoRico + { 111, 225, 46, 44, 59, 37, 48, 45, 43, 101, 550,6 , 1021,26 , 18,7 , 25,12 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/UnitedStates + { 111, 227, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 1021,26 , 37,5 , 8,10 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/Uruguay + { 111, 231, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 1021,26 , 37,5 , 8,10 , 13105,48 , 13153,89 , 13242,24 , 13256,48 , 13304,89 , 13393,24 , 8524,28 , 8552,53 , 2799,14 , 8524,28 , 8552,53 , 2799,14 , 49,4 , 49,4 }, // Spanish/Venezuela + { 113, 111, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 13266,48 , 13314,84 , 134,24 , 13417,48 , 13465,84 , 320,24 , 8605,22 , 8627,60 , 8687,14 , 8605,22 , 8627,60 , 8687,14 , 255,7 , 250,7 }, // Swahili/Kenya + { 113, 210, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 13266,48 , 13314,84 , 134,24 , 13417,48 , 13465,84 , 320,24 , 8605,22 , 8627,60 , 8687,14 , 8605,22 , 8627,60 , 8687,14 , 255,7 , 250,7 }, // Swahili/Tanzania + { 114, 205, 44, 160, 59, 37, 48, 8722, 43, 101, 72,10 , 1074,30 , 37,5 , 431,16 , 3473,48 , 13398,86 , 134,24 , 5180,48 , 13549,86 , 320,24 , 8701,29 , 8730,50 , 2228,14 , 8701,29 , 8730,50 , 2228,14 , 262,2 , 257,2 }, // Swedish/Sweden + { 114, 73, 44, 160, 59, 37, 48, 8722, 43, 101, 72,10 , 1074,30 , 37,5 , 431,16 , 3473,48 , 13398,86 , 134,24 , 5180,48 , 13549,86 , 320,24 , 8701,29 , 8730,50 , 2228,14 , 8701,29 , 8730,50 , 2228,14 , 262,2 , 257,2 }, // Swedish/Finland + { 116, 209, 46, 44, 59, 37, 48, 45, 43, 101, 213,8 , 306,18 , 37,5 , 8,10 , 13484,48 , 13532,71 , 1483,27 , 13635,48 , 13683,71 , 134,27 , 8780,28 , 8808,55 , 798,14 , 8780,28 , 8808,55 , 798,14 , 0,2 , 0,2 }, // Tajik/Tajikistan + { 117, 100, 46, 44, 59, 37, 48, 45, 43, 101, 664,6 , 195,18 , 18,7 , 25,12 , 13603,58 , 13661,86 , 13747,31 , 13754,58 , 13812,86 , 13898,31 , 8863,20 , 8883,49 , 8863,20 , 8863,20 , 8883,49 , 8863,20 , 122,2 , 121,2 }, // Tamil/India + { 117, 198, 46, 44, 59, 37, 48, 45, 43, 101, 664,6 , 195,18 , 18,7 , 25,12 , 13603,58 , 13661,86 , 13747,31 , 13754,58 , 13812,86 , 13898,31 , 8863,20 , 8883,49 , 8863,20 , 8863,20 , 8883,49 , 8863,20 , 122,2 , 121,2 }, // Tamil/SriLanka + { 118, 178, 44, 160, 59, 37, 48, 45, 43, 101, 936,10 , 1104,11 , 165,4 , 25,12 , 1483,27 , 1483,27 , 1483,27 , 134,27 , 134,27 , 134,27 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 0,2 , 0,2 }, // Tatar/RussianFederation + { 119, 100, 46, 44, 59, 37, 48, 45, 43, 101, 535,8 , 99,16 , 18,7 , 25,12 , 13778,86 , 13778,86 , 13864,30 , 13929,86 , 13929,86 , 14015,30 , 8932,32 , 8964,60 , 9024,18 , 8932,32 , 8964,60 , 9024,18 , 0,2 , 0,2 }, // Telugu/India + { 120, 211, 46, 44, 59, 37, 48, 45, 43, 101, 356,8 , 1115,19 , 165,4 , 546,27 , 13894,63 , 13957,98 , 13894,63 , 14045,63 , 14108,98 , 14206,24 , 9042,23 , 9065,68 , 9133,14 , 9042,23 , 9065,68 , 9133,14 , 264,10 , 259,10 }, // Thai/Thailand + { 121, 44, 46, 44, 59, 37, 3872, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 14055,63 , 14118,158 , 1483,27 , 14230,63 , 14293,158 , 134,27 , 9147,49 , 9196,77 , 9273,21 , 9147,49 , 9196,77 , 9273,21 , 274,7 , 269,8 }, // Tibetan/China + { 121, 100, 46, 44, 59, 37, 3872, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 14055,63 , 14118,158 , 1483,27 , 14230,63 , 14293,158 , 134,27 , 9147,49 , 9196,77 , 9273,21 , 9147,49 , 9196,77 , 9273,21 , 274,7 , 269,8 }, // Tibetan/India + { 122, 67, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 1134,23 , 18,7 , 25,12 , 14276,46 , 14322,54 , 1034,24 , 14451,46 , 14497,54 , 1061,24 , 9294,29 , 9294,29 , 9323,14 , 9294,29 , 9294,29 , 9323,14 , 281,7 , 277,7 }, // Tigrinya/Eritrea + { 122, 69, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 1157,23 , 18,7 , 25,12 , 926,46 , 972,62 , 1034,24 , 953,46 , 999,62 , 1061,24 , 9337,29 , 9337,29 , 9323,14 , 9337,29 , 9337,29 , 9323,14 , 281,7 , 277,7 }, // Tigrinya/Ethiopia + { 123, 214, 46, 44, 59, 37, 48, 45, 43, 101, 271,6 , 99,16 , 37,5 , 8,10 , 14376,51 , 14427,87 , 14514,24 , 14551,51 , 14602,87 , 14689,24 , 9366,29 , 9395,60 , 9455,14 , 9366,29 , 9395,60 , 9455,14 , 0,2 , 0,2 }, // Tonga/Tonga + { 124, 195, 44, 160, 59, 37, 48, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 14538,48 , 14586,122 , 1483,27 , 14713,48 , 14761,122 , 134,27 , 9469,27 , 9496,72 , 798,14 , 9469,27 , 9496,72 , 798,14 , 0,2 , 0,2 }, // Tsonga/SouthAfrica + { 125, 217, 44, 46, 59, 37, 48, 45, 43, 101, 936,10 , 1180,17 , 37,5 , 8,10 , 14708,48 , 14756,75 , 14831,24 , 14883,48 , 14931,75 , 15006,24 , 9568,28 , 9596,54 , 9650,14 , 9568,28 , 9596,54 , 9650,14 , 0,2 , 0,2 }, // Turkish/Turkey + { 128, 44, 46, 44, 59, 37, 48, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 1483,27 , 1483,27 , 1483,27 , 134,27 , 134,27 , 134,27 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 0,2 , 0,2 }, // Uigur/China + { 129, 222, 44, 160, 59, 37, 48, 45, 43, 101, 324,8 , 1197,22 , 37,5 , 8,10 , 14855,48 , 14903,95 , 14998,24 , 15030,67 , 15097,87 , 15184,24 , 9664,21 , 9685,56 , 9741,14 , 9664,21 , 9685,56 , 9741,14 , 288,2 , 284,2 }, // Ukrainian/Ukraine + { 130, 100, 46, 44, 59, 37, 48, 45, 43, 101, 271,6 , 1219,18 , 18,7 , 25,12 , 15022,67 , 15022,67 , 10111,24 , 15208,67 , 15208,67 , 10250,24 , 9755,36 , 9755,36 , 9791,14 , 9755,36 , 9755,36 , 9791,14 , 0,2 , 0,2 }, // Urdu/India + { 130, 163, 46, 44, 59, 37, 48, 45, 43, 101, 271,6 , 1219,18 , 18,7 , 25,12 , 15022,67 , 15022,67 , 10111,24 , 15208,67 , 15208,67 , 10250,24 , 9755,36 , 9755,36 , 9791,14 , 9755,36 , 9755,36 , 9791,14 , 0,2 , 0,2 }, // Urdu/Pakistan + { 131, 228, 44, 160, 59, 37, 48, 45, 43, 101, 213,8 , 306,18 , 37,5 , 8,10 , 13484,48 , 15089,115 , 11247,24 , 13635,48 , 15275,115 , 11391,24 , 9805,28 , 9833,53 , 9886,14 , 9805,28 , 9833,53 , 9886,14 , 0,2 , 0,2 }, // Uzbek/Uzbekistan + { 131, 1, 44, 46, 59, 1642, 1776, 8722, 43, 101, 881,8 , 1237,33 , 165,4 , 447,11 , 15204,48 , 15252,68 , 11247,24 , 15390,48 , 10182,68 , 11391,24 , 9900,21 , 6558,49 , 9886,14 , 9900,21 , 6558,49 , 9886,14 , 0,2 , 0,2 }, // Uzbek/Afghanistan + { 132, 232, 44, 46, 59, 37, 48, 45, 43, 101, 141,10 , 1270,31 , 37,5 , 8,10 , 15320,75 , 15395,130 , 1483,27 , 15438,75 , 15513,130 , 134,27 , 9921,33 , 9954,55 , 10009,21 , 9921,33 , 9954,55 , 10009,21 , 290,2 , 286,2 }, // Vietnamese/VietNam + { 134, 224, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 123,18 , 18,7 , 25,12 , 15525,53 , 15578,87 , 15665,24 , 15643,62 , 15705,86 , 15791,24 , 10030,29 , 10059,77 , 10136,14 , 10150,30 , 10059,77 , 10136,14 , 0,2 , 0,2 }, // Welsh/UnitedKingdom + { 135, 187, 46, 44, 59, 37, 48, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 1483,27 , 1483,27 , 1483,27 , 134,27 , 134,27 , 134,27 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 0,2 , 0,2 }, // Wolof/Senegal + { 136, 195, 44, 160, 59, 37, 48, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 15689,48 , 15737,91 , 1483,27 , 15815,48 , 15863,91 , 134,27 , 10180,28 , 10208,61 , 798,14 , 10180,28 , 10208,61 , 798,14 , 0,2 , 0,2 }, // Xhosa/SouthAfrica + { 138, 157, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 15828,73 , 15901,121 , 1483,27 , 15954,73 , 16027,121 , 134,27 , 10269,44 , 10313,69 , 798,14 , 10269,44 , 10313,69 , 798,14 , 292,5 , 288,5 }, // Yoruba/Nigeria + { 140, 195, 44, 160, 59, 37, 48, 45, 43, 101, 72,10 , 82,17 , 18,7 , 25,12 , 16022,48 , 16070,104 , 134,24 , 16148,48 , 16196,90 , 320,24 , 10382,28 , 10410,68 , 10478,14 , 10382,28 , 10410,68 , 10478,14 , 0,2 , 0,2 }, // Zulu/SouthAfrica + { 141, 161, 44, 160, 59, 37, 48, 8722, 43, 101, 324,8 , 603,17 , 37,5 , 431,16 , 3915,48 , 9527,83 , 134,24 , 3967,48 , 9595,83 , 320,24 , 10492,28 , 10520,51 , 2228,14 , 10492,28 , 10520,51 , 2228,14 , 297,9 , 293,11 }, // Nynorsk/Norway + { 142, 27, 44, 46, 59, 37, 48, 45, 43, 101, 213,8 , 306,18 , 37,5 , 8,10 , 16174,48 , 16222,83 , 1483,27 , 16286,48 , 16334,83 , 134,27 , 10571,28 , 10599,58 , 798,14 , 10571,28 , 10599,58 , 798,14 , 0,2 , 0,2 }, // Bosnian/BosniaAndHerzegowina + { 143, 131, 46, 44, 44, 37, 48, 45, 43, 101, 664,6 , 99,16 , 322,8 , 330,13 , 1483,27 , 1483,27 , 1483,27 , 134,27 , 134,27 , 134,27 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 0,2 , 0,2 }, // Divehi/Maldives + { 144, 224, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 82,17 , 37,5 , 8,10 , 16305,102 , 16407,140 , 1483,27 , 16417,102 , 16519,140 , 134,27 , 10657,30 , 10687,57 , 798,14 , 10657,30 , 10687,57 , 798,14 , 49,4 , 49,4 }, // Manx/UnitedKingdom + { 145, 224, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 99,16 , 37,5 , 8,10 , 16547,46 , 16593,124 , 1483,27 , 16659,46 , 16705,124 , 134,27 , 10744,28 , 10772,60 , 798,14 , 10744,28 , 10772,60 , 798,14 , 49,4 , 49,4 }, // Cornish/UnitedKingdom + { 146, 83, 46, 160, 59, 37, 48, 45, 43, 101, 213,8 , 306,18 , 37,5 , 8,10 , 16717,48 , 16765,192 , 1483,27 , 16829,48 , 16877,192 , 134,27 , 10832,28 , 10860,49 , 10909,14 , 10832,28 , 10860,49 , 10909,14 , 306,2 , 304,2 }, // Akan/Ghana + { 147, 100, 46, 44, 59, 37, 48, 45, 43, 101, 664,6 , 99,16 , 18,7 , 25,12 , 16957,87 , 16957,87 , 1483,27 , 17069,87 , 17069,87 , 134,27 , 6029,32 , 10923,55 , 798,14 , 6029,32 , 10923,55 , 798,14 , 308,5 , 306,5 }, // Konkani/India + { 148, 83, 46, 44, 59, 37, 48, 45, 43, 101, 213,8 , 306,18 , 37,5 , 8,10 , 17044,48 , 17092,94 , 1483,27 , 17156,48 , 17204,94 , 134,27 , 10978,26 , 11004,34 , 798,14 , 10978,26 , 11004,34 , 798,14 , 0,2 , 0,2 }, // Ga/Ghana + { 149, 157, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 17186,48 , 17234,86 , 1483,27 , 17298,48 , 17346,86 , 134,27 , 11038,29 , 11067,57 , 798,14 , 11038,29 , 11067,57 , 798,14 , 313,4 , 311,4 }, // Igbo/Nigeria + { 150, 111, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 17320,48 , 17368,189 , 17557,24 , 17432,48 , 17480,189 , 17669,24 , 11124,28 , 11152,74 , 11226,14 , 11124,28 , 11152,74 , 11226,14 , 317,9 , 315,7 }, // Kamba/Kenya + { 151, 207, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 1301,13 , 394,4 , 25,12 , 17581,65 , 17581,65 , 1483,27 , 17693,65 , 17693,65 , 134,27 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 0,2 , 0,2 }, // Syriac/SyrianArabRepublic + { 152, 67, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 1314,22 , 18,7 , 25,12 , 17646,47 , 17693,77 , 17770,24 , 17758,47 , 17805,77 , 17882,24 , 11240,26 , 11266,43 , 11309,14 , 11240,26 , 11266,43 , 11309,14 , 0,2 , 0,2 }, // Blin/Eritrea + { 153, 67, 46, 4808, 59, 37, 48, 45, 43, 101, 27,8 , 1336,23 , 18,7 , 25,12 , 17794,49 , 17794,49 , 17843,24 , 17906,49 , 17906,49 , 17955,24 , 11323,29 , 11323,29 , 11352,14 , 11323,29 , 11323,29 , 11352,14 , 0,2 , 0,2 }, // Geez/Eritrea + { 153, 69, 46, 4808, 59, 37, 48, 45, 43, 101, 27,8 , 1336,23 , 18,7 , 25,12 , 17794,49 , 17794,49 , 17843,24 , 17906,49 , 17906,49 , 17955,24 , 11323,29 , 11323,29 , 11352,14 , 11323,29 , 11323,29 , 11352,14 , 0,2 , 0,2 }, // Geez/Ethiopia + { 154, 53, 46, 44, 59, 37, 48, 45, 43, 101, 213,8 , 306,18 , 37,5 , 8,10 , 17867,48 , 17915,124 , 1483,27 , 17979,48 , 18027,124 , 134,27 , 11366,28 , 11394,54 , 798,14 , 11366,28 , 11394,54 , 798,14 , 0,2 , 0,2 }, // Koro/IvoryCoast + { 155, 69, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 53,19 , 18,7 , 25,12 , 1483,27 , 1483,27 , 1483,27 , 134,27 , 134,27 , 134,27 , 11448,28 , 11476,51 , 11527,14 , 11448,28 , 11476,51 , 11527,14 , 0,2 , 0,2 }, // Sidamo/Ethiopia + { 156, 157, 46, 44, 59, 37, 48, 45, 43, 101, 213,8 , 306,18 , 37,5 , 8,10 , 18039,59 , 18098,129 , 1483,27 , 18151,59 , 18210,129 , 134,27 , 11541,35 , 11576,87 , 798,14 , 11541,35 , 11576,87 , 798,14 , 0,2 , 0,2 }, // Atsam/Nigeria + { 157, 67, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 1359,21 , 18,7 , 25,12 , 926,46 , 972,62 , 1034,24 , 953,46 , 999,62 , 1061,24 , 11663,27 , 11690,41 , 11731,14 , 11663,27 , 11690,41 , 11731,14 , 0,2 , 0,2 }, // Tigre/Eritrea + { 158, 157, 46, 44, 59, 37, 48, 45, 43, 101, 213,8 , 306,18 , 37,5 , 8,10 , 18227,57 , 18284,178 , 1483,27 , 18339,57 , 18396,178 , 134,27 , 11745,28 , 11773,44 , 798,14 , 11745,28 , 11773,44 , 798,14 , 0,2 , 0,2 }, // Jju/Nigeria + { 159, 106, 44, 46, 59, 37, 48, 45, 43, 101, 27,8 , 1380,27 , 37,5 , 8,10 , 18462,48 , 18510,77 , 18587,24 , 18574,48 , 18622,77 , 18699,24 , 11817,28 , 11845,50 , 2799,14 , 11817,28 , 11845,50 , 2799,14 , 0,2 , 0,2 }, // Friulian/Italy + { 160, 195, 44, 160, 59, 37, 48, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 18611,48 , 18659,111 , 1483,27 , 18723,48 , 18771,111 , 134,27 , 11895,27 , 11922,70 , 798,14 , 11895,27 , 11922,70 , 798,14 , 0,2 , 0,2 }, // Venda/SouthAfrica + { 161, 83, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 18770,48 , 18818,87 , 18905,24 , 18882,48 , 18930,87 , 19017,24 , 11992,32 , 12024,44 , 12068,14 , 11992,32 , 12024,44 , 12068,14 , 306,2 , 304,2 }, // Ewe/Ghana + { 161, 212, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 18770,48 , 18818,87 , 18905,24 , 18882,48 , 18930,87 , 19017,24 , 11992,32 , 12024,44 , 12068,14 , 11992,32 , 12024,44 , 12068,14 , 306,2 , 304,2 }, // Ewe/Togo + { 162, 69, 46, 8217, 59, 37, 48, 45, 43, 101, 27,8 , 1407,22 , 18,7 , 25,12 , 926,46 , 972,62 , 1034,24 , 953,46 , 999,62 , 1061,24 , 12082,27 , 12082,27 , 12109,14 , 12082,27 , 12082,27 , 12109,14 , 0,2 , 0,2 }, // Walamo/Ethiopia + { 163, 225, 46, 44, 59, 37, 48, 45, 43, 101, 271,6 , 10,17 , 18,7 , 25,12 , 18929,59 , 18988,95 , 1483,27 , 19041,59 , 19100,95 , 134,27 , 12123,21 , 12144,57 , 798,14 , 12123,21 , 12144,57 , 798,14 , 0,2 , 0,2 }, // Hawaiian/UnitedStates + { 164, 157, 46, 44, 59, 37, 48, 45, 43, 101, 213,8 , 306,18 , 37,5 , 8,10 , 19083,48 , 19131,153 , 1483,27 , 19195,48 , 19243,153 , 134,27 , 12201,28 , 12229,42 , 798,14 , 12201,28 , 12229,42 , 798,14 , 0,2 , 0,2 }, // Tyap/Nigeria + { 165, 129, 46, 44, 59, 37, 48, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 19284,48 , 19332,91 , 1483,27 , 19396,48 , 19444,91 , 134,27 , 12271,28 , 12299,67 , 798,14 , 12271,28 , 12299,67 , 798,14 , 0,2 , 0,2 }, // Chewa/Malawi + { 166, 170, 46, 44, 59, 37, 48, 45, 43, 101, 550,6 , 1429,18 , 37,5 , 8,10 , 19423,48 , 19471,88 , 19559,24 , 19535,48 , 19583,88 , 19671,24 , 12366,28 , 12394,55 , 12449,14 , 12463,28 , 12394,55 , 12449,14 , 0,2 , 0,2 }, // Filipino/Philippines + { 167, 206, 46, 8217, 59, 37, 48, 8722, 43, 101, 324,8 , 494,18 , 37,5 , 8,10 , 19583,48 , 19631,86 , 134,24 , 4729,48 , 19695,86 , 320,24 , 12491,28 , 12519,63 , 3089,14 , 12491,28 , 12519,63 , 3089,14 , 326,5 , 322,4 }, // Swiss German/Switzerland + { 168, 44, 46, 44, 59, 37, 48, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 1483,27 , 19717,38 , 1483,27 , 134,27 , 19781,38 , 134,27 , 12582,21 , 12603,28 , 12631,14 , 12582,21 , 12603,28 , 12631,14 , 331,2 , 326,2 }, // Sichuan Yi/China + { 169, 91, 46, 44, 59, 37, 48, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 1483,27 , 1483,27 , 1483,27 , 134,27 , 134,27 , 134,27 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 0,2 , 0,2 }, // Kpelle/Guinea + { 169, 121, 46, 44, 59, 37, 48, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 1483,27 , 1483,27 , 1483,27 , 134,27 , 134,27 , 134,27 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 0,2 , 0,2 }, // Kpelle/Liberia + { 170, 82, 44, 46, 59, 37, 48, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 1483,27 , 1483,27 , 1483,27 , 134,27 , 134,27 , 134,27 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 798,14 , 0,2 , 0,2 }, // Low German/Germany + { 171, 195, 44, 160, 59, 37, 48, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 19755,48 , 19803,100 , 1483,27 , 19819,48 , 19867,100 , 134,27 , 12645,27 , 12672,66 , 798,14 , 12645,27 , 12672,66 , 798,14 , 0,2 , 0,2 }, // South Ndebele/SouthAfrica + { 172, 195, 44, 160, 59, 37, 48, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 19903,48 , 19951,94 , 1483,27 , 19967,48 , 20015,94 , 134,27 , 12738,27 , 12765,63 , 798,14 , 12738,27 , 12765,63 , 798,14 , 0,2 , 0,2 }, // Northern Sotho/SouthAfrica + { 173, 73, 44, 160, 59, 37, 48, 8722, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 20045,85 , 20130,145 , 20275,24 , 20109,85 , 20194,145 , 20339,24 , 12828,33 , 12861,65 , 12926,14 , 12828,33 , 12861,65 , 12926,14 , 0,2 , 0,2 }, // Northern Sami/Finland + { 173, 161, 44, 160, 59, 37, 48, 8722, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 20299,59 , 20130,145 , 20275,24 , 20363,59 , 20194,145 , 20339,24 , 12828,33 , 12940,75 , 13015,14 , 12828,33 , 12940,75 , 13015,14 , 0,2 , 0,2 }, // Northern Sami/Norway + { 174, 208, 46, 44, 59, 37, 48, 45, 43, 101, 72,10 , 306,18 , 37,5 , 8,10 , 20358,48 , 20406,142 , 20548,24 , 20422,48 , 20470,142 , 20612,24 , 13029,28 , 13057,172 , 13229,14 , 13029,28 , 13057,172 , 13229,14 , 0,2 , 0,2 }, // Taroko/Taiwan + { 175, 111, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 20572,48 , 20620,88 , 20708,24 , 20636,48 , 20684,88 , 20772,24 , 13243,28 , 13271,62 , 13333,14 , 13243,28 , 13271,62 , 13333,14 , 333,5 , 328,10 }, // Gusii/Kenya + { 176, 111, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 20732,48 , 20780,221 , 21001,24 , 20796,48 , 20844,221 , 21065,24 , 13347,28 , 13375,106 , 13481,14 , 13347,28 , 13375,106 , 13481,14 , 338,10 , 338,10 }, // Taita/Kenya + { 177, 187, 44, 160, 59, 37, 48, 45, 43, 101, 356,8 , 99,16 , 37,5 , 8,10 , 21025,48 , 21073,77 , 21150,24 , 21089,48 , 21137,77 , 21214,24 , 13495,28 , 13523,59 , 13582,14 , 13495,28 , 13523,59 , 13582,14 , 348,6 , 348,7 }, // Fulah/Senegal + { 178, 111, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 21174,48 , 21222,185 , 21407,24 , 21238,48 , 21286,185 , 21471,24 , 13596,28 , 13624,63 , 13687,14 , 13596,28 , 13624,63 , 13687,14 , 354,6 , 355,8 }, // Kikuyu/Kenya + { 179, 111, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 21431,48 , 21479,173 , 21652,24 , 21495,48 , 21543,173 , 21716,24 , 13701,28 , 13729,105 , 13834,14 , 13701,28 , 13729,105 , 13834,14 , 360,7 , 363,5 }, // Samburu/Kenya + { 180, 146, 44, 46, 59, 37, 48, 45, 43, 101, 356,8 , 909,27 , 37,5 , 8,10 , 21676,48 , 21724,88 , 134,24 , 21740,48 , 21788,88 , 320,24 , 13848,28 , 13876,55 , 13931,14 , 13848,28 , 13876,55 , 13931,14 , 0,2 , 0,2 }, // Sena/Mozambique + { 181, 240, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 21812,48 , 21860,112 , 21972,24 , 21876,48 , 21924,112 , 22036,24 , 13945,28 , 13973,50 , 14023,14 , 13945,28 , 13973,50 , 14023,14 , 0,2 , 0,2 }, // North Ndebele/Zimbabwe + { 182, 210, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 21996,39 , 22035,194 , 22229,24 , 22060,39 , 22099,194 , 22293,24 , 14037,28 , 14065,65 , 14130,14 , 14037,28 , 14065,65 , 14130,14 , 367,8 , 368,7 }, // Rombo/Tanzania + { 183, 145, 44, 160, 59, 37, 48, 45, 43, 101, 356,8 , 99,16 , 37,5 , 8,10 , 22253,48 , 22301,81 , 22382,24 , 22317,48 , 22365,81 , 22446,24 , 14144,30 , 14174,48 , 798,14 , 14144,30 , 14174,48 , 798,14 , 375,6 , 375,8 }, // Tachelhit/Morocco + { 184, 3, 44, 160, 59, 37, 48, 45, 43, 101, 356,8 , 99,16 , 37,5 , 8,10 , 22406,48 , 22454,84 , 22538,24 , 22470,48 , 22518,84 , 22602,24 , 14222,30 , 14252,51 , 14303,14 , 14222,30 , 14252,51 , 14303,14 , 381,7 , 383,9 }, // Kabyle/Algeria + { 185, 221, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 22562,48 , 22610,152 , 134,24 , 22626,48 , 22674,152 , 320,24 , 14317,28 , 14345,74 , 14419,14 , 14317,28 , 14345,74 , 14419,14 , 0,2 , 0,2 }, // Nyankole/Uganda + { 186, 210, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 22762,48 , 22810,254 , 23064,24 , 22826,48 , 22874,254 , 23128,24 , 14433,28 , 14461,82 , 14543,14 , 14433,28 , 14461,82 , 14543,14 , 388,7 , 392,7 }, // Bena/Tanzania + { 187, 210, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 13266,48 , 23088,87 , 134,24 , 13417,48 , 23152,87 , 320,24 , 14557,28 , 14585,62 , 14647,14 , 14557,28 , 14585,62 , 14647,14 , 395,5 , 399,9 }, // Vunjo/Tanzania + { 188, 132, 46, 44, 59, 37, 48, 45, 43, 101, 356,8 , 99,16 , 37,5 , 8,10 , 23175,47 , 23222,92 , 23314,24 , 23239,47 , 23286,92 , 23378,24 , 14661,28 , 14689,44 , 14733,14 , 14661,28 , 14689,44 , 14733,14 , 0,2 , 0,2 }, // Bambara/Mali + { 189, 111, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 23338,48 , 23386,207 , 23593,24 , 23402,48 , 23450,207 , 23657,24 , 14747,28 , 14775,64 , 14839,14 , 14747,28 , 14775,64 , 14839,14 , 400,2 , 408,2 }, // Embu/Kenya + { 190, 225, 46, 44, 59, 37, 48, 45, 43, 101, 550,6 , 35,18 , 18,7 , 25,12 , 23617,36 , 23653,58 , 23711,24 , 23681,36 , 23717,58 , 23775,24 , 14853,28 , 14881,49 , 14930,14 , 14853,28 , 14881,49 , 14930,14 , 402,3 , 410,6 }, // Cherokee/UnitedStates + { 191, 137, 46, 160, 59, 37, 48, 45, 43, 101, 356,8 , 99,16 , 37,5 , 8,10 , 23735,47 , 23782,68 , 23850,24 , 23799,47 , 23846,68 , 23914,24 , 14944,27 , 14971,48 , 15019,14 , 14944,27 , 14971,48 , 15019,14 , 0,2 , 0,2 }, // Morisyen/Mauritius + { 192, 210, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 13266,48 , 23874,264 , 134,24 , 13417,48 , 23938,264 , 320,24 , 15033,28 , 15061,133 , 14130,14 , 15033,28 , 15061,133 , 14130,14 , 405,4 , 416,5 }, // Makonde/Tanzania + { 193, 210, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 24138,83 , 24221,111 , 24332,24 , 24202,83 , 24285,111 , 24396,24 , 15194,36 , 15230,63 , 15293,14 , 15194,36 , 15230,63 , 15293,14 , 409,3 , 421,3 }, // Langi/Tanzania + { 194, 221, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 24356,48 , 24404,97 , 134,24 , 24420,48 , 24468,97 , 320,24 , 15307,28 , 15335,66 , 15401,14 , 15307,28 , 15335,66 , 15401,14 , 0,2 , 0,2 }, // Ganda/Uganda + { 195, 239, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 24501,48 , 24549,83 , 24632,24 , 24565,48 , 24613,83 , 24696,24 , 15415,80 , 15415,80 , 798,14 , 15415,80 , 15415,80 , 798,14 , 412,8 , 424,7 }, // Bemba/Zambia + { 196, 39, 44, 46, 59, 37, 48, 45, 43, 101, 356,8 , 909,27 , 37,5 , 8,10 , 24656,48 , 24704,86 , 134,24 , 24720,48 , 24768,86 , 320,24 , 15495,28 , 15523,73 , 15596,14 , 15495,28 , 15523,73 , 15596,14 , 122,2 , 121,2 }, // Kabuverdianu/CapeVerde + { 197, 111, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 24790,48 , 24838,86 , 24924,24 , 24854,48 , 24902,86 , 24988,24 , 15610,28 , 15638,51 , 15689,14 , 15610,28 , 15638,51 , 15689,14 , 420,2 , 431,2 }, // Meru/Kenya + { 198, 111, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 24948,48 , 24996,111 , 25107,24 , 25012,48 , 25060,111 , 25171,24 , 15703,28 , 15731,93 , 15824,14 , 15703,28 , 15731,93 , 15824,14 , 422,4 , 433,4 }, // Kalenjin/Kenya + { 199, 148, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 0,48 , 25131,136 , 134,24 , 0,48 , 25195,136 , 320,24 , 15838,23 , 15861,92 , 15953,14 , 15838,23 , 15861,92 , 15953,14 , 426,7 , 437,5 }, // Nama/Namibia + { 200, 210, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 13266,48 , 23088,87 , 134,24 , 13417,48 , 23152,87 , 320,24 , 14557,28 , 14585,62 , 14647,14 , 14557,28 , 14585,62 , 14647,14 , 395,5 , 399,9 }, // Machame/Tanzania + { 201, 82, 44, 160, 59, 37, 48, 8722, 43, 101, 1447,10 , 1457,23 , 37,5 , 8,10 , 25267,59 , 25326,87 , 134,24 , 25331,59 , 25390,87 , 320,24 , 15967,28 , 15995,72 , 3089,14 , 15967,28 , 15995,72 , 3089,14 , 0,2 , 0,2 }, // Colognian/Germany + { 202, 111, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 25413,51 , 25464,132 , 1483,27 , 25477,51 , 25528,132 , 134,27 , 14557,28 , 16067,58 , 14130,14 , 14557,28 , 16067,58 , 14130,14 , 433,9 , 442,6 }, // Masai/Kenya + { 202, 210, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 25413,51 , 25464,132 , 1483,27 , 25477,51 , 25528,132 , 134,27 , 14557,28 , 16067,58 , 14130,14 , 14557,28 , 16067,58 , 14130,14 , 433,9 , 442,6 }, // Masai/Tanzania + { 203, 221, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 24356,48 , 24404,97 , 134,24 , 24420,48 , 24468,97 , 320,24 , 16125,35 , 16160,65 , 16225,14 , 16125,35 , 16160,65 , 16225,14 , 442,6 , 448,6 }, // Soga/Uganda + { 204, 111, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 25596,48 , 13314,84 , 134,24 , 25660,48 , 13465,84 , 320,24 , 16239,21 , 16260,75 , 85,14 , 16239,21 , 16260,75 , 85,14 , 49,4 , 49,4 }, // Luyia/Kenya + { 205, 210, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 25644,48 , 13314,84 , 134,24 , 25708,48 , 13465,84 , 320,24 , 16335,28 , 8627,60 , 14647,14 , 16335,28 , 8627,60 , 14647,14 , 448,9 , 454,8 }, // Asu/Tanzania + { 206, 111, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 25692,48 , 25740,94 , 25834,24 , 25756,48 , 25804,94 , 25898,24 , 16363,28 , 16391,69 , 16460,14 , 16363,28 , 16391,69 , 16460,14 , 457,9 , 462,6 }, // Teso/Kenya + { 206, 221, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 25692,48 , 25740,94 , 25834,24 , 25756,48 , 25804,94 , 25898,24 , 16363,28 , 16391,69 , 16460,14 , 16363,28 , 16391,69 , 16460,14 , 457,9 , 462,6 }, // Teso/Uganda + { 207, 67, 46, 44, 59, 37, 48, 45, 43, 101, 27,8 , 53,19 , 18,7 , 25,12 , 317,48 , 518,118 , 494,24 , 344,48 , 545,118 , 521,24 , 16474,28 , 16502,56 , 16558,14 , 16474,28 , 16502,56 , 16558,14 , 0,2 , 0,2 }, // Saho/Eritrea + { 208, 132, 46, 160, 59, 37, 48, 45, 43, 101, 356,8 , 99,16 , 37,5 , 8,10 , 25858,46 , 25904,88 , 25992,24 , 25922,46 , 25968,88 , 26056,24 , 16572,28 , 16600,53 , 16653,14 , 16572,28 , 16600,53 , 16653,14 , 466,6 , 468,6 }, // Koyra Chiini/Mali + { 209, 210, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 13266,48 , 23088,87 , 134,24 , 13417,48 , 23152,87 , 320,24 , 14557,28 , 14585,62 , 14647,14 , 14557,28 , 14585,62 , 14647,14 , 395,5 , 399,9 }, // Rwa/Tanzania + { 210, 111, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 26016,48 , 26064,186 , 26250,24 , 26080,48 , 26128,186 , 26314,24 , 16667,28 , 16695,69 , 16764,14 , 16667,28 , 16695,69 , 16764,14 , 472,2 , 474,2 }, // Luo/Kenya + { 211, 221, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 22562,48 , 22610,152 , 134,24 , 22626,48 , 22674,152 , 320,24 , 14317,28 , 14345,74 , 14419,14 , 14317,28 , 14345,74 , 14419,14 , 0,2 , 0,2 }, // Chiga/Uganda + { 212, 145, 44, 160, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 26274,48 , 26322,86 , 26408,24 , 26338,48 , 26386,86 , 26472,24 , 16778,28 , 16806,48 , 16854,14 , 16778,28 , 16806,48 , 16854,14 , 474,9 , 476,10 }, // Central Morocco Tamazight/Morocco + { 213, 132, 46, 160, 59, 37, 48, 45, 43, 101, 356,8 , 99,16 , 37,5 , 8,10 , 25858,46 , 25904,88 , 25992,24 , 25922,46 , 25968,88 , 26056,24 , 16868,28 , 16896,54 , 16653,14 , 16868,28 , 16896,54 , 16653,14 , 466,6 , 468,6 }, // Koyraboro Senni/Mali + { 214, 210, 46, 44, 59, 37, 48, 45, 43, 101, 141,10 , 10,17 , 18,7 , 25,12 , 13266,48 , 26432,84 , 134,24 , 13417,48 , 26496,84 , 320,24 , 16950,28 , 16978,63 , 8687,14 , 16950,28 , 16978,63 , 8687,14 , 483,5 , 486,8 }, // Shambala/Tanzania { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0 } // trailing 0s }; static const ushort date_format_data[] = { 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x79, 0x79, 0x79, 0x64, 0x64, 0x64, 0x64, 0x2c, 0x20, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x79, 0x79, 0x79, 0x64, 0x64, 0x2f, 0x4d, 0x4d, 0x2f, 0x79, 0x79, 0x64, 0x64, 0x64, 0x64, 0x2c, -0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x64, 0x2c, 0x20, 0x79, 0x64, 0x64, 0x64, 0x64, 0x2c, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, -0x20, 0x64, 0x64, 0x2c, 0x20, 0x79, 0x79, 0x79, 0x79, 0x79, 0x2d, 0x4d, 0x4d, 0x2d, 0x64, 0x64, 0x64, 0x64, 0x64, 0x64, -0x20, 0x64, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x64, 0x64, 0x64, 0x64, 0x20, 0x64, 0x20, 0x4d, 0x4d, 0x4d, -0x4d, 0x20, 0x79, 0x79, 0x79, 0x2d, 0x4d, 0x4d, 0x2d, 0x64, 0x64, 0x64, 0x64, 0x64, 0x64, 0x2c, 0x20, 0x64, 0x64, 0x20, -0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x64, 0x64, 0x2f, 0x4d, 0x4d, 0x2f, 0x79, 0x79, 0x79, 0x79, 0x64, 0x64, 0x64, 0x64, -0x2c, 0x20, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x64, 0x200f, 0x2f, 0x4d, 0x200f, 0x2f, 0x79, 0x79, 0x79, 0x79, -0x64, 0x64, 0x64, 0x64, 0x60c, 0x20, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x60c, 0x20, 0x79, 0x4d, 0x4d, 0x2f, 0x64, 0x64, -0x2f, 0x79, 0x79, 0x64, 0x2d, 0x4d, 0x2d, 0x79, 0x79, 0x79, 0x79, 0x64, 0x64, 0x64, 0x64, 0x2c, 0x20, 0x64, 0x20, 0x4d, -0x4d, 0x4d, 0x4d, 0x2c, 0x20, 0x79, 0x79, 0x79, 0x2f, 0x4d, 0x4d, 0x2f, 0x64, 0x64, 0x64, 0x64, 0x64, 0x64, 0x2c, 0x20, -0x64, 0x2c, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x2c, 0x20, 0x79, 0x64, 0x64, 0x64, 0x64, 0x2c, 0x20, 0x79, 0x27, 0x65, 0x6b, -0x6f, 0x27, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x27, 0x72, 0x65, 0x6e, 0x27, 0x20, 0x64, 0x64, 0x27, 0x61, 0x27, 0x64, 0x2f, -0x4d, 0x2f, 0x79, 0x79, 0xf66, 0xfa4, 0xfb1, 0xf72, 0xf0b, 0xf63, 0xf7c, 0xf0b, 0x79, 0x20, 0xf5f, 0xfb3, 0xf0b, 0x20, 0x4d, 0x4d, -0x4d, 0x4d, 0x20, 0xf5a, 0xf7a, 0xf66, 0xf0b, 0x20, 0x64, 0x64, 0x64, 0x64, 0x64, 0x64, 0x2c, 0x20, 0x79, 0x20, 0x4d, 0x4d, -0x4d, 0x4d, 0x20, 0x64, 0x64, 0x64, 0x64, 0x2e, 0x4d, 0x4d, 0x2e, 0x79, 0x79, 0x64, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, -0x20, 0x79, 0x2c, 0x20, 0x64, 0x64, 0x64, 0x64, 0x64, 0x2e, 0x4d, 0x2e, 0x79, 0x79, 0x64, 0x2f, 0x4d, 0x2f, 0x79, 0x79, -0x79, 0x79, 0x64, 0x64, 0x64, 0x64, 0x20, 0x1790, 0x17d2, 0x1784, 0x17c3, 0x20, 0x64, 0x20, 0x1781, 0x17c2, 0x20, 0x4d, 0x4d, 0x4d, -0x4d, 0x20, 0x1786, 0x17d2, 0x1793, 0x17b6, 0x17c6, 0x20, 0x79, 0x64, 0x64, 0x64, 0x64, 0x20, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, -0x20, 0x27, 0x64, 0x65, 0x27, 0x20, 0x79, 0x79, 0x79, 0x2d, 0x4d, 0x2d, 0x64, 0x79, 0x5e74, 0x4d, 0x6708, 0x64, 0x65e5, 0x64, -0x64, 0x64, 0x64, 0x79, 0x79, 0x5e74, 0x4d, 0x6708, 0x64, 0x65e5, 0x79, 0x5e74, 0x4d, 0x4d, 0x6708, 0x64, 0x64, 0x65e5, 0x64, 0x64, -0x64, 0x64, 0x79, 0x79, 0x2f, 0x4d, 0x2f, 0x64, 0x64, 0x64, 0x2e, 0x20, 0x4d, 0x4d, 0x2e, 0x20, 0x79, 0x79, 0x79, 0x79, -0x2e, 0x64, 0x64, 0x64, 0x64, 0x2c, 0x20, 0x64, 0x2e, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x2e, 0x64, 0x64, 0x64, -0x64, 0x2c, 0x20, 0x64, 0x2e, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x64, 0x64, 0x64, 0x64, 0x20, 0x27, 0x64, 0x65, -0x6e, 0x27, 0x20, 0x64, 0x2e, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x64, 0x64, 0x2d, 0x4d, 0x4d, 0x2d, 0x79, 0x79, -0x64, 0x2f, 0x4d, 0x4d, 0x2f, 0x79, 0x79, 0x4d, 0x2f, 0x64, 0x2f, 0x79, 0x79, 0x64, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, -0x20, 0x79, 0x64, 0x64, 0x64, 0x64, 0x2c, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x2c, 0x20, 0x79, 0x79, 0x79, 0x79, 0x79, -0x2f, 0x4d, 0x4d, 0x2f, 0x64, 0x64, 0x64, 0x2e, 0x4d, 0x2e, 0x79, 0x79, 0x79, 0x79, 0x64, 0x64, 0x64, 0x64, 0x20, 0x64, -0x2e, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x64, 0x64, 0x64, 0x64, 0x2c, 0x20, 0x64, 0x64, 0x2e, 0x20, 0x4d, 0x4d, -0x4d, 0x4d, 0x20, 0x79, 0x64, 0x2d, 0x4d, 0x4d, 0x2d, 0x79, 0x79, 0x64, 0x64, 0x64, 0x64, 0x2c, 0x20, 0x64, 0x20, 0x5d1, -0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x64, 0x2d, 0x4d, 0x2d, 0x79, 0x79, 0x79, 0x79, 0x79, 0x79, 0x2e, 0x4d, 0x4d, 0x2e, -0x64, 0x64, 0x2e, 0x79, 0x2e, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x64, 0x2e, 0x2c, 0x20, 0x64, 0x64, 0x64, 0x64, 0x64, -0x64, 0x64, 0x64, 0x2c, 0x20, 0x64, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x79, 0x79, 0x79, 0x64, 0x64, 0x64, -0x64, 0x2c, 0x20, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x20, 0x27, 0x436, 0x27, 0x2e, 0x79, 0x79, 0x2e, 0x20, -0x4d, 0x2e, 0x20, 0x64, 0x2e, 0x79, 0xb144, 0x20, 0x4d, 0xc6d4, 0x20, 0x64, 0xc77c, 0x20, 0x64, 0x64, 0x64, 0x64, 0x64, 0x64, -0x64, 0x64, 0xe97, 0xeb5, 0x20, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x47, 0x20, 0x79, 0x64, 0x64, 0x64, 0x64, 0x2c, -0x20, 0x79, 0x2e, 0x20, 0x27, 0x67, 0x61, 0x64, 0x61, 0x27, 0x20, 0x64, 0x2e, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x79, 0x20, -0x27, 0x6d, 0x27, 0x2e, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x64, 0x20, 0x27, 0x64, 0x27, 0x2e, 0x2c, 0x64, 0x64, 0x64, -0x64, 0x64, 0x64, 0x2e, 0x4d, 0x2e, 0x79, 0x79, 0x64, 0x64, 0x64, 0x64, 0x20, 0x64, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x20, -0x79, 0x79, 0x2c, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x64, 0x2c, 0x20, 0x64, 0x64, 0x64, 0x64, 0x64, 0x64, 0x64, 0x64, -0x2c, 0x20, 0x64, 0x20, 0x27, 0x74, 0x61, 0x27, 0x2019, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x79, 0x79, 0x79, 0x79, -0x2f, 0x4d, 0x2f, 0x64, 0x64, 0x64, 0x64, 0x64, 0x20, 0x62f, 0x20, 0x79, 0x20, 0x62f, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, -0x64, 0x64, 0x64, 0x64, 0x64, 0x2c, 0x20, 0x64, 0x20, 0x27, 0x64, 0x65, 0x27, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x27, -0x64, 0x65, 0x27, 0x20, 0x79, 0x64, 0x64, 0x2e, 0x4d, 0x4d, 0x2e, 0x79, 0x79, 0x79, 0x79, 0x64, 0x64, 0x64, 0x64, 0x2c, -0x20, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0xa0, 0x27, 0x433, 0x27, 0x2e, 0x64, 0x2e, 0x4d, 0x2e, 0x79, 0x79, -0x2e, 0x64, 0x64, 0x64, 0x64, 0x2c, 0x20, 0x64, 0x64, 0x2e, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x2e, 0x64, 0x64, -0x64, 0x64, 0x2c, 0x20, 0x79, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x64, 0x64, 0x2e, 0x20, 0x4d, 0x4d, 0x2e, 0x20, 0x79, +0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x64, 0x2c, 0x20, 0x79, 0x79, 0x79, 0x79, 0x64, 0x64, 0x64, 0x64, 0x2c, 0x20, 0x4d, +0x4d, 0x4d, 0x4d, 0x20, 0x64, 0x64, 0x2c, 0x20, 0x79, 0x79, 0x79, 0x79, 0x79, 0x79, 0x79, 0x79, 0x2d, 0x4d, 0x4d, 0x2d, +0x64, 0x64, 0x64, 0x64, 0x64, 0x64, 0x20, 0x64, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x79, 0x79, 0x79, 0x64, +0x64, 0x64, 0x64, 0x20, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x79, 0x79, 0x79, 0x79, 0x79, 0x2d, 0x4d, 0x4d, +0x2d, 0x64, 0x64, 0x64, 0x64, 0x64, 0x64, 0x2c, 0x20, 0x64, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x79, 0x79, +0x79, 0x64, 0x64, 0x2f, 0x4d, 0x4d, 0x2f, 0x79, 0x79, 0x79, 0x79, 0x64, 0x200f, 0x2f, 0x4d, 0x200f, 0x2f, 0x79, 0x79, 0x79, +0x79, 0x64, 0x64, 0x64, 0x64, 0x60c, 0x20, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x60c, 0x20, 0x79, 0x79, 0x79, 0x79, 0x4d, +0x4d, 0x2f, 0x64, 0x64, 0x2f, 0x79, 0x79, 0x64, 0x2d, 0x4d, 0x2d, 0x79, 0x79, 0x79, 0x79, 0x64, 0x64, 0x64, 0x64, 0x2c, +0x20, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x2c, 0x20, 0x79, 0x79, 0x79, 0x79, 0x79, 0x79, 0x2f, 0x4d, 0x4d, 0x2f, 0x64, +0x64, 0x64, 0x64, 0x64, 0x64, 0x2c, 0x20, 0x64, 0x2c, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x2c, 0x20, 0x79, 0x79, 0x79, 0x79, +0x64, 0x64, 0x64, 0x64, 0x2c, 0x20, 0x79, 0x79, 0x79, 0x79, 0x27, 0x65, 0x6b, 0x6f, 0x27, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, +0x27, 0x72, 0x65, 0x6e, 0x27, 0x20, 0x64, 0x64, 0x27, 0x61, 0x27, 0x64, 0x2f, 0x4d, 0x2f, 0x79, 0x79, 0xf66, 0xfa4, 0xfb1, +0xf72, 0xf0b, 0xf63, 0xf7c, 0xf0b, 0x79, 0x79, 0x79, 0x79, 0x20, 0xf5f, 0xfb3, 0xf0b, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0xf5a, +0xf7a, 0xf66, 0xf0b, 0x20, 0x64, 0x64, 0x64, 0x64, 0x64, 0x64, 0x2c, 0x20, 0x79, 0x79, 0x79, 0x79, 0x20, 0x4d, 0x4d, 0x4d, +0x4d, 0x20, 0x64, 0x64, 0x64, 0x64, 0x2e, 0x4d, 0x4d, 0x2e, 0x79, 0x79, 0x64, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, +0x79, 0x79, 0x79, 0x79, 0x2c, 0x20, 0x64, 0x64, 0x64, 0x64, 0x64, 0x2e, 0x4d, 0x2e, 0x79, 0x79, 0x64, 0x2f, 0x4d, 0x2f, +0x79, 0x79, 0x79, 0x79, 0x64, 0x64, 0x64, 0x64, 0x20, 0x1790, 0x17d2, 0x1784, 0x17c3, 0x20, 0x64, 0x20, 0x1781, 0x17c2, 0x20, 0x4d, +0x4d, 0x4d, 0x4d, 0x20, 0x1786, 0x17d2, 0x1793, 0x17b6, 0x17c6, 0x20, 0x79, 0x79, 0x79, 0x79, 0x64, 0x64, 0x64, 0x64, 0x20, 0x64, +0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x27, 0x64, 0x65, 0x27, 0x20, 0x79, 0x79, 0x79, 0x79, 0x79, 0x79, 0x2d, 0x4d, 0x2d, +0x64, 0x79, 0x79, 0x79, 0x79, 0x5e74, 0x4d, 0x6708, 0x64, 0x65e5, 0x64, 0x64, 0x64, 0x64, 0x79, 0x79, 0x5e74, 0x4d, 0x6708, 0x64, +0x65e5, 0x79, 0x79, 0x79, 0x79, 0x5e74, 0x4d, 0x4d, 0x6708, 0x64, 0x64, 0x65e5, 0x64, 0x64, 0x64, 0x64, 0x79, 0x79, 0x2f, 0x4d, +0x2f, 0x64, 0x64, 0x64, 0x2e, 0x20, 0x4d, 0x4d, 0x2e, 0x20, 0x79, 0x79, 0x79, 0x79, 0x2e, 0x64, 0x64, 0x64, 0x64, 0x2c, +0x20, 0x64, 0x2e, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x79, 0x79, 0x79, 0x2e, 0x64, 0x64, 0x64, 0x64, 0x2c, 0x20, +0x64, 0x2e, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x79, 0x79, 0x79, 0x64, 0x64, 0x64, 0x64, 0x20, 0x27, 0x64, 0x65, +0x6e, 0x27, 0x20, 0x64, 0x2e, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x79, 0x79, 0x79, 0x64, 0x64, 0x2d, 0x4d, 0x4d, +0x2d, 0x79, 0x79, 0x64, 0x2f, 0x4d, 0x4d, 0x2f, 0x79, 0x79, 0x4d, 0x2f, 0x64, 0x2f, 0x79, 0x79, 0x64, 0x64, 0x20, 0x4d, +0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x79, 0x79, 0x79, 0x64, 0x64, 0x64, 0x64, 0x2c, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x2c, +0x20, 0x79, 0x79, 0x79, 0x79, 0x79, 0x79, 0x79, 0x79, 0x2f, 0x4d, 0x4d, 0x2f, 0x64, 0x64, 0x64, 0x2e, 0x4d, 0x2e, 0x79, +0x79, 0x79, 0x79, 0x64, 0x64, 0x64, 0x64, 0x20, 0x64, 0x2e, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x79, 0x79, 0x79, +0x64, 0x64, 0x64, 0x64, 0x2c, 0x20, 0x64, 0x64, 0x2e, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x79, 0x79, 0x79, 0x64, +0x2d, 0x4d, 0x4d, 0x2d, 0x79, 0x79, 0x64, 0x64, 0x64, 0x64, 0x2c, 0x20, 0x64, 0x20, 0x5d1, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, +0x79, 0x79, 0x79, 0x79, 0x64, 0x2d, 0x4d, 0x2d, 0x79, 0x79, 0x79, 0x79, 0x79, 0x79, 0x2e, 0x4d, 0x4d, 0x2e, 0x64, 0x64, +0x2e, 0x79, 0x79, 0x79, 0x79, 0x2e, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x64, 0x2e, 0x2c, 0x20, 0x64, 0x64, 0x64, 0x64, +0x64, 0x64, 0x64, 0x64, 0x2c, 0x20, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x79, 0x79, 0x79, 0x20, 0x27, 0x436, +0x27, 0x2e, 0x79, 0x79, 0x2e, 0x20, 0x4d, 0x2e, 0x20, 0x64, 0x2e, 0x79, 0x79, 0x79, 0x79, 0xb144, 0x20, 0x4d, 0xc6d4, 0x20, +0x64, 0xc77c, 0x20, 0x64, 0x64, 0x64, 0x64, 0x64, 0x64, 0x64, 0x64, 0xe97, 0xeb5, 0x20, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, +0x20, 0x79, 0x79, 0x79, 0x79, 0x64, 0x64, 0x64, 0x64, 0x2c, 0x20, 0x79, 0x79, 0x79, 0x79, 0x2e, 0x20, 0x27, 0x67, 0x61, +0x64, 0x61, 0x27, 0x20, 0x64, 0x2e, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x79, 0x79, 0x79, 0x79, 0x20, 0x27, 0x6d, 0x27, 0x2e, +0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x64, 0x20, 0x27, 0x64, 0x27, 0x2e, 0x2c, 0x64, 0x64, 0x64, 0x64, 0x64, 0x64, 0x2e, +0x4d, 0x2e, 0x79, 0x79, 0x64, 0x64, 0x64, 0x64, 0x20, 0x64, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x79, 0x79, 0x79, +0x79, 0x79, 0x79, 0x79, 0x2c, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x64, 0x2c, 0x20, 0x64, 0x64, 0x64, 0x64, 0x64, 0x64, +0x64, 0x64, 0x2c, 0x20, 0x64, 0x20, 0x27, 0x74, 0x61, 0x27, 0x2019, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x79, 0x79, +0x79, 0x79, 0x79, 0x79, 0x79, 0x2f, 0x4d, 0x2f, 0x64, 0x64, 0x64, 0x64, 0x64, 0x20, 0x62f, 0x20, 0x79, 0x79, 0x79, 0x79, +0x20, 0x62f, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x64, 0x64, 0x64, 0x64, 0x64, 0x2c, 0x20, 0x64, 0x20, 0x27, 0x64, 0x65, +0x27, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x27, 0x64, 0x65, 0x27, 0x20, 0x79, 0x79, 0x79, 0x79, 0x64, 0x64, 0x2e, 0x4d, +0x4d, 0x2e, 0x79, 0x79, 0x79, 0x79, 0x64, 0x64, 0x64, 0x64, 0x2c, 0x20, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, +0x79, 0x79, 0x79, 0xa0, 0x27, 0x433, 0x27, 0x2e, 0x64, 0x2e, 0x4d, 0x2e, 0x79, 0x79, 0x2e, 0x64, 0x64, 0x64, 0x64, 0x2c, +0x20, 0x64, 0x64, 0x2e, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x79, 0x79, 0x79, 0x2e, 0x64, 0x64, 0x64, 0x64, 0x2c, +0x20, 0x79, 0x79, 0x79, 0x79, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x64, 0x64, 0x2e, 0x20, 0x4d, 0x4d, 0x2e, 0x20, 0x79, 0x79, 0x64, 0x64, 0x64, 0x64, 0x20, 0x64, 0x20, 0x27, 0x64, 0x65, 0x27, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x27, 0x64, -0x65, 0x27, 0x20, 0x79, 0x64, 0x64, 0x64, 0x64, 0x20, 0x64, 0x64, 0x20, 0x27, 0x64, 0x65, 0x27, 0x20, 0x4d, 0x4d, 0x4d, -0x4d, 0x20, 0x27, 0x64, 0x65, 0x27, 0x20, 0x79, 0x64, 0x64, 0x64, 0x64, 0x27, 0x65, 0x6e, 0x27, 0x20, 0x27, 0x64, 0x65, -0x6e, 0x27, 0x20, 0x64, 0x3a, 0x27, 0x65, 0x27, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x64, 0x20, 0x4d, 0x4d, 0x4d, -0x4d, 0x20, 0x79, 0x64, 0x64, 0x64, 0x64, 0xe17, 0xe35, 0xe48, 0x20, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x47, 0x20, -0x79, 0x64, 0x64, 0x64, 0x64, 0x1361, 0x20, 0x64, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x1218, 0x12d3, 0x120d, 0x1272, 0x20, -0x79, 0x20, 0x47, 0x64, 0x64, 0x64, 0x64, 0x1363, 0x20, 0x64, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x1218, 0x12d3, 0x120d, -0x1272, 0x20, 0x79, 0x20, 0x47, 0x64, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x20, 0x64, 0x64, 0x64, 0x64, 0x64, -0x64, 0x64, 0x64, 0x2c, 0x20, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x20, 0x27, 0x440, 0x27, 0x2e, 0x64, 0x64, -0x64, 0x64, 0x2c, 0x20, 0x64, 0x2c, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x79, 0x20, 0x646, 0x686, 0x6cc, 0x20, 0x6cc, -0x6cc, 0x644, 0x20, 0x64, 0x20, 0x646, 0x686, 0x6cc, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x64, 0x64, 0x64, 0x64, 0x20, 0x6a9, -0x648, 0x646, 0x6cc, 0x64, 0x64, 0x64, 0x64, 0x2c, 0x20, 0x27, 0x6e, 0x67, 0xe0, 0x79, 0x27, 0x20, 0x64, 0x64, 0x20, 0x4d, -0x4d, 0x4d, 0x4d, 0x20, 0x27, 0x6e, 0x103, 0x6d, 0x27, 0x20, 0x79, 0x64, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x2c, 0x20, -0x79, 0x64, 0x64, 0x64, 0x64, 0x1361, 0x20, 0x64, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x130d, 0x122d, 0x130b, 0x20, 0x79, -0x20, 0x47, 0x64, 0x64, 0x64, 0x64, 0x1365, 0x20, 0x64, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x1218, 0x12d3, 0x120d, 0x1275, -0x20, 0x79, 0x20, 0x47, 0x64, 0x64, 0x64, 0x64, 0x1361, 0x20, 0x64, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x12ee, 0x121d, -0x20, 0x79, 0x20, 0x47, 0x64, 0x64, 0x64, 0x64, 0x20, 0x64, 0x20, 0x27, 0x64, 0x69, 0x27, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, -0x20, 0x27, 0x64, 0x61, 0x6c, 0x27, 0x20, 0x79, 0x64, 0x64, 0x64, 0x64, 0x1365, 0x20, 0x64, 0x64, 0x20, 0x4d, 0x4d, 0x4d, -0x4d, 0x20, 0x130b, 0x120b, 0x1233, 0x20, 0x79, 0x20, 0x47, 0x64, 0x64, 0x64, 0x64, 0x2c, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, -0x64, 0x64, 0x20, 0x79, 0x64, 0x2e, 0x20, 0x4d, 0x2e, 0x20, 0x79, 0x79, 0x79, 0x79, 0x64, 0x64, 0x64, 0x64, 0x2c, 0x20, -0x27, 0x64, 0xe4, 0x27, 0x20, 0x64, 0x2e, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79 +0x65, 0x27, 0x20, 0x79, 0x79, 0x79, 0x79, 0x64, 0x64, 0x64, 0x64, 0x20, 0x64, 0x64, 0x20, 0x27, 0x64, 0x65, 0x27, 0x20, +0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x27, 0x64, 0x65, 0x27, 0x20, 0x79, 0x79, 0x79, 0x79, 0x64, 0x64, 0x64, 0x64, 0x27, 0x65, +0x6e, 0x27, 0x20, 0x27, 0x64, 0x65, 0x6e, 0x27, 0x20, 0x64, 0x3a, 0x27, 0x65, 0x27, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, +0x79, 0x79, 0x79, 0x79, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x79, 0x79, 0x79, 0x64, 0x64, 0x64, 0x64, 0xe17, +0xe35, 0xe48, 0x20, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x79, 0x79, 0x79, 0x64, 0x64, 0x64, 0x64, 0x1361, 0x20, +0x64, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x1218, 0x12d3, 0x120d, 0x1272, 0x20, 0x79, 0x79, 0x79, 0x79, 0x64, 0x64, 0x64, +0x64, 0x1363, 0x20, 0x64, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x1218, 0x12d3, 0x120d, 0x1272, 0x20, 0x79, 0x79, 0x79, 0x79, +0x64, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x79, 0x79, 0x79, 0x20, 0x64, 0x64, 0x64, 0x64, 0x64, 0x64, 0x64, +0x64, 0x2c, 0x20, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x79, 0x79, 0x79, 0x20, 0x27, 0x440, 0x27, 0x2e, 0x64, +0x64, 0x64, 0x64, 0x2c, 0x20, 0x64, 0x2c, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x79, 0x79, 0x79, 0x79, 0x79, 0x79, +0x79, 0x20, 0x646, 0x686, 0x6cc, 0x20, 0x6cc, 0x6cc, 0x644, 0x20, 0x64, 0x20, 0x646, 0x686, 0x6cc, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, +0x20, 0x64, 0x64, 0x64, 0x64, 0x20, 0x6a9, 0x648, 0x646, 0x6cc, 0x64, 0x64, 0x64, 0x64, 0x2c, 0x20, 0x27, 0x6e, 0x67, 0xe0, +0x79, 0x27, 0x20, 0x64, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x27, 0x6e, 0x103, 0x6d, 0x27, 0x20, 0x79, 0x79, 0x79, +0x79, 0x64, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x2c, 0x20, 0x79, 0x79, 0x79, 0x79, 0x64, 0x64, 0x64, 0x64, 0x1361, 0x20, +0x64, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x130d, 0x122d, 0x130b, 0x20, 0x79, 0x79, 0x79, 0x79, 0x64, 0x64, 0x64, 0x64, +0x1365, 0x20, 0x64, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x1218, 0x12d3, 0x120d, 0x1275, 0x20, 0x79, 0x79, 0x79, 0x79, 0x64, +0x64, 0x64, 0x64, 0x1361, 0x20, 0x64, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x12ee, 0x121d, 0x20, 0x79, 0x79, 0x79, 0x79, +0x64, 0x64, 0x64, 0x64, 0x20, 0x64, 0x20, 0x27, 0x64, 0x69, 0x27, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x27, 0x64, 0x61, +0x6c, 0x27, 0x20, 0x79, 0x79, 0x79, 0x79, 0x64, 0x64, 0x64, 0x64, 0x1365, 0x20, 0x64, 0x64, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, +0x20, 0x130b, 0x120b, 0x1233, 0x20, 0x79, 0x79, 0x79, 0x79, 0x64, 0x64, 0x64, 0x64, 0x2c, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, +0x64, 0x64, 0x20, 0x79, 0x79, 0x79, 0x79, 0x64, 0x2e, 0x20, 0x4d, 0x2e, 0x20, 0x79, 0x79, 0x79, 0x79, 0x64, 0x64, 0x64, +0x64, 0x2c, 0x20, 0x27, 0x64, 0xe4, 0x27, 0x20, 0x64, 0x2e, 0x20, 0x4d, 0x4d, 0x4d, 0x4d, 0x20, 0x79, 0x79, 0x79, 0x79, + }; static const ushort time_format_data[] = { 0x48, 0x48, 0x3a, 0x6d, 0x6d, 0x3a, 0x73, 0x73, 0x48, 0x48, 0x3a, 0x6d, 0x6d, 0x3a, 0x73, 0x73, 0x20, 0x74, 0x68, 0x3a, -0x6d, 0x6d, 0x20, 0x41, 0x50, 0x68, 0x3a, 0x6d, 0x6d, 0x3a, 0x73, 0x73, 0x20, 0x41, 0x50, 0x20, 0x74, 0x74, 0x74, 0x74, -0x48, 0x48, 0x3a, 0x6d, 0x6d, 0x48, 0x48, 0x3a, 0x6d, 0x6d, 0x3a, 0x73, 0x73, 0x20, 0x74, 0x74, 0x74, 0x74, 0x68, 0x2e, -0x6d, 0x6d, 0x2e, 0x41, 0x50, 0x68, 0x2e, 0x6d, 0x6d, 0x2e, 0x73, 0x73, 0x2e, 0x41, 0x50, 0x20, 0x74, 0x74, 0x74, 0x74, -0x74, 0x74, 0x74, 0x74, 0x20, 0x68, 0x3a, 0x6d, 0x6d, 0x3a, 0x73, 0x73, 0x20, 0x41, 0x50, 0x68, 0x2e, 0x6d, 0x6d, 0x2e, -0x20, 0x41, 0x50, 0x68, 0x2e, 0x6d, 0x6d, 0x2e, 0x73, 0x73, 0x20, 0x41, 0x50, 0x20, 0x74, 0x74, 0x74, 0x74, 0xf46, 0xf74, -0xf0b, 0xf5a, 0xf7c, 0xf51, 0xf0b, 0x20, 0x68, 0x20, 0xf66, 0xf90, 0xf62, 0xf0b, 0xf58, 0xf0b, 0x20, 0x6d, 0x6d, 0x20, 0x41, 0x50, -0xf46, 0xf74, 0xf0b, 0xf5a, 0xf7c, 0xf51, 0xf0b, 0x20, 0x68, 0x20, 0xf66, 0xf90, 0xf62, 0xf0b, 0xf58, 0xf0b, 0x20, 0x6d, 0x6d, 0x20, -0xf66, 0xf90, 0xf62, 0xf0b, 0xf46, 0xf71, 0xf0b, 0x20, 0x73, 0x73, 0x20, 0x41, 0x50, 0x20, 0x74, 0x74, 0x74, 0x74, 0x48, 0x48, -0x2e, 0x6d, 0x6d, 0x48, 0x48, 0x2e, 0x6d, 0x6d, 0x2e, 0x73, 0x73, 0x20, 0x74, 0x74, 0x74, 0x74, 0x48, 0x3a, 0x6d, 0x6d, -0x48, 0x20, 0x1798, 0x17c9, 0x17c4, 0x1784, 0x20, 0x6d, 0x20, 0x1793, 0x17b6, 0x1791, 0x17b8, 0x20, 0x73, 0x73, 0x20, 0x179c, 0x17b7, 0x1793, -0x17b6, 0x1791, 0x17b8, 0x200b, 0x20, 0x74, 0x74, 0x74, 0x74, 0x48, 0x3a, 0x6d, 0x6d, 0x3a, 0x73, 0x73, 0x20, 0x74, 0x74, 0x74, -0x74, 0x41, 0x50, 0x68, 0x3a, 0x6d, 0x6d, 0x74, 0x74, 0x74, 0x74, 0x41, 0x50, 0x68, 0x65f6, 0x6d, 0x6d, 0x5206, 0x73, 0x73, -0x79d2, 0x74, 0x74, 0x74, 0x74, 0x41, 0x50, 0x68, 0x6642, 0x6d, 0x6d, 0x5206, 0x73, 0x73, 0x79d2, 0x41, 0x50, 0x68, 0x68, 0x3a, -0x6d, 0x6d, 0x48, 0x48, 0x20, 0x27, 0x68, 0x27, 0x20, 0x6d, 0x6d, 0x20, 0x27, 0x6d, 0x69, 0x6e, 0x27, 0x20, 0x73, 0x73, -0x20, 0x27, 0x73, 0x27, 0x20, 0x74, 0x74, 0x74, 0x74, 0x48, 0x3a, 0x6d, 0x6d, 0x2e, 0x73, 0x73, 0x20, 0x74, 0x74, 0x74, -0x74, 0x48, 0x2e, 0x6d, 0x6d, 0x48, 0x2e, 0x6d, 0x6d, 0x2e, 0x73, 0x73, 0x20, 0x74, 0x74, 0x74, 0x74, 0x48, 0x20, 0x27, -0x68, 0x27, 0x20, 0x6d, 0x6d, 0x20, 0x27, 0x6d, 0x69, 0x6e, 0x27, 0x20, 0x73, 0x73, 0x20, 0x27, 0x73, 0x27, 0x20, 0x74, -0x74, 0x74, 0x74, 0x48, 0x48, 0x2e, 0x6d, 0x6d, 0x3a, 0x73, 0x73, 0x20, 0x27, 0x68, 0x27, 0x20, 0x74, 0x74, 0x74, 0x74, -0x68, 0x68, 0x3a, 0x6d, 0x6d, 0x20, 0x41, 0x50, 0x68, 0x68, 0x3a, 0x6d, 0x6d, 0x3a, 0x73, 0x73, 0x20, 0x41, 0x50, 0x20, -0x74, 0x74, 0x74, 0x74, 0x48, 0x6642, 0x6d, 0x6d, 0x5206, 0x73, 0x73, 0x79d2, 0x20, 0x74, 0x74, 0x74, 0x74, 0x41, 0x50, 0x20, -0x68, 0x3a, 0x6d, 0x6d, 0x41, 0x50, 0x20, 0x68, 0xc2dc, 0x20, 0x6d, 0xbd84, 0x20, 0x73, 0xcd08, 0x20, 0x74, 0x74, 0x74, 0x74, -0x48, 0xec2, 0xea1, 0xe87, 0x20, 0x6d, 0xe99, 0xeb2, 0xe97, 0xeb5, 0x20, 0x73, 0x73, 0x20, 0xea7, 0xeb4, 0xe99, 0xeb2, 0xe97, 0xeb5, -0x74, 0x74, 0x74, 0x74, 0x68, 0x3a, 0x6d, 0x6d, 0x68, 0x3a, 0x6d, 0x6d, 0x3a, 0x73, 0x73, 0x20, 0x41, 0x50, 0x41, 0x50, -0x20, 0x74, 0x74, 0x74, 0x74, 0x68, 0x2d, 0x6d, 0x6d, 0x20, 0x41, 0x50, 0x68, 0x2d, 0x6d, 0x6d, 0x2d, 0x73, 0x73, 0x20, -0x41, 0x50, 0x20, 0x74, 0x74, 0x74, 0x74, 0x27, 0x6b, 0x6c, 0x27, 0x2e, 0x20, 0x48, 0x48, 0x3a, 0x6d, 0x6d, 0x3a, 0x73, -0x73, 0x20, 0x74, 0x74, 0x74, 0x74, 0x48, 0x3a, 0x6d, 0x6d, 0x3a, 0x73, 0x73, 0x20, 0x28, 0x74, 0x74, 0x74, 0x74, 0x29, -0x48, 0x48, 0x27, 0x68, 0x27, 0x6d, 0x6d, 0x27, 0x6d, 0x69, 0x6e, 0x27, 0x73, 0x73, 0x27, 0x73, 0x27, 0x20, 0x74, 0x74, -0x74, 0x74, 0x48, 0x48, 0x20, 0x27, 0x447, 0x430, 0x441, 0x43e, 0x432, 0x430, 0x27, 0x2c, 0x20, 0x6d, 0x6d, 0x20, 0x27, 0x43c, -0x438, 0x43d, 0x443, 0x442, 0x430, 0x27, 0x2c, 0x20, 0x73, 0x73, 0x20, 0x27, 0x441, 0x435, 0x43a, 0x443, 0x43d, 0x434, 0x438, 0x27, -0x20, 0x74, 0x74, 0x74, 0x74, 0x48, 0x48, 0x27, 0x68, 0x27, 0x27, 0x27, 0x6d, 0x6d, 0x3a, 0x73, 0x73, 0x20, 0x74, 0x74, -0x74, 0x74, 0x48, 0x48, 0x27, 0x48, 0x27, 0x6d, 0x6d, 0x27, 0x27, 0x73, 0x73, 0x27, 0x27, 0x20, 0x74, 0x74, 0x74, 0x74, -0x48, 0x20, 0xe19, 0xe32, 0xe2c, 0xe34, 0xe01, 0xe32, 0x20, 0x6d, 0x20, 0xe19, 0xe32, 0xe17, 0xe35, 0x20, 0x73, 0x73, 0x20, 0xe27, -0xe34, 0xe19, 0xe32, 0xe17, 0xe35, 0x20, 0x74, 0x74, 0x74, 0x74 +0x6d, 0x6d, 0x20, 0x41, 0x50, 0x68, 0x3a, 0x6d, 0x6d, 0x3a, 0x73, 0x73, 0x20, 0x41, 0x50, 0x20, 0x74, 0x48, 0x48, 0x3a, +0x6d, 0x6d, 0x68, 0x2e, 0x6d, 0x6d, 0x2e, 0x41, 0x50, 0x68, 0x2e, 0x6d, 0x6d, 0x2e, 0x73, 0x73, 0x2e, 0x41, 0x50, 0x20, +0x74, 0x74, 0x20, 0x68, 0x3a, 0x6d, 0x6d, 0x3a, 0x73, 0x73, 0x20, 0x41, 0x50, 0x68, 0x2e, 0x6d, 0x6d, 0x2e, 0x20, 0x41, +0x50, 0x68, 0x2e, 0x6d, 0x6d, 0x2e, 0x73, 0x73, 0x20, 0x41, 0x50, 0x20, 0x74, 0xf46, 0xf74, 0xf0b, 0xf5a, 0xf7c, 0xf51, 0xf0b, +0x20, 0x68, 0x20, 0xf66, 0xf90, 0xf62, 0xf0b, 0xf58, 0xf0b, 0x20, 0x6d, 0x6d, 0x20, 0x41, 0x50, 0xf46, 0xf74, 0xf0b, 0xf5a, 0xf7c, +0xf51, 0xf0b, 0x20, 0x68, 0x20, 0xf66, 0xf90, 0xf62, 0xf0b, 0xf58, 0xf0b, 0x20, 0x6d, 0x6d, 0x20, 0xf66, 0xf90, 0xf62, 0xf0b, 0xf46, +0xf71, 0xf0b, 0x20, 0x73, 0x73, 0x20, 0x41, 0x50, 0x20, 0x74, 0x48, 0x48, 0x2e, 0x6d, 0x6d, 0x48, 0x48, 0x2e, 0x6d, 0x6d, +0x2e, 0x73, 0x73, 0x20, 0x74, 0x48, 0x3a, 0x6d, 0x6d, 0x48, 0x20, 0x1798, 0x17c9, 0x17c4, 0x1784, 0x20, 0x6d, 0x20, 0x1793, 0x17b6, +0x1791, 0x17b8, 0x20, 0x73, 0x73, 0x20, 0x179c, 0x17b7, 0x1793, 0x17b6, 0x1791, 0x17b8, 0x200b, 0x20, 0x74, 0x48, 0x3a, 0x6d, 0x6d, 0x3a, +0x73, 0x73, 0x20, 0x74, 0x41, 0x50, 0x68, 0x3a, 0x6d, 0x6d, 0x74, 0x41, 0x50, 0x68, 0x65f6, 0x6d, 0x6d, 0x5206, 0x73, 0x73, +0x79d2, 0x74, 0x41, 0x50, 0x68, 0x6642, 0x6d, 0x6d, 0x5206, 0x73, 0x73, 0x79d2, 0x41, 0x50, 0x68, 0x68, 0x3a, 0x6d, 0x6d, 0x48, +0x48, 0x20, 0x27, 0x68, 0x27, 0x20, 0x6d, 0x6d, 0x20, 0x27, 0x6d, 0x69, 0x6e, 0x27, 0x20, 0x73, 0x73, 0x20, 0x27, 0x73, +0x27, 0x20, 0x74, 0x48, 0x3a, 0x6d, 0x6d, 0x2e, 0x73, 0x73, 0x20, 0x74, 0x48, 0x2e, 0x6d, 0x6d, 0x48, 0x2e, 0x6d, 0x6d, +0x2e, 0x73, 0x73, 0x20, 0x74, 0x48, 0x20, 0x27, 0x68, 0x27, 0x20, 0x6d, 0x6d, 0x20, 0x27, 0x6d, 0x69, 0x6e, 0x27, 0x20, +0x73, 0x73, 0x20, 0x27, 0x73, 0x27, 0x20, 0x74, 0x48, 0x48, 0x2e, 0x6d, 0x6d, 0x3a, 0x73, 0x73, 0x20, 0x27, 0x68, 0x27, +0x20, 0x74, 0x68, 0x68, 0x3a, 0x6d, 0x6d, 0x20, 0x41, 0x50, 0x68, 0x68, 0x3a, 0x6d, 0x6d, 0x3a, 0x73, 0x73, 0x20, 0x41, +0x50, 0x20, 0x74, 0x48, 0x6642, 0x6d, 0x6d, 0x5206, 0x73, 0x73, 0x79d2, 0x20, 0x74, 0x41, 0x50, 0x20, 0x68, 0x3a, 0x6d, 0x6d, +0x41, 0x50, 0x20, 0x68, 0xc2dc, 0x20, 0x6d, 0xbd84, 0x20, 0x73, 0xcd08, 0x20, 0x74, 0x48, 0xec2, 0xea1, 0xe87, 0x20, 0x6d, 0xe99, +0xeb2, 0xe97, 0xeb5, 0x20, 0x73, 0x73, 0x20, 0xea7, 0xeb4, 0xe99, 0xeb2, 0xe97, 0xeb5, 0x74, 0x68, 0x3a, 0x6d, 0x6d, 0x68, 0x3a, +0x6d, 0x6d, 0x3a, 0x73, 0x73, 0x20, 0x41, 0x50, 0x41, 0x50, 0x20, 0x74, 0x68, 0x2d, 0x6d, 0x6d, 0x20, 0x41, 0x50, 0x68, +0x2d, 0x6d, 0x6d, 0x2d, 0x73, 0x73, 0x20, 0x41, 0x50, 0x20, 0x74, 0x27, 0x6b, 0x6c, 0x27, 0x2e, 0x20, 0x48, 0x48, 0x3a, +0x6d, 0x6d, 0x3a, 0x73, 0x73, 0x20, 0x74, 0x48, 0x3a, 0x6d, 0x6d, 0x3a, 0x73, 0x73, 0x20, 0x28, 0x74, 0x29, 0x48, 0x48, +0x27, 0x68, 0x27, 0x6d, 0x6d, 0x27, 0x6d, 0x69, 0x6e, 0x27, 0x73, 0x73, 0x27, 0x73, 0x27, 0x20, 0x74, 0x48, 0x48, 0x20, +0x27, 0x447, 0x430, 0x441, 0x43e, 0x432, 0x430, 0x27, 0x2c, 0x20, 0x6d, 0x6d, 0x20, 0x27, 0x43c, 0x438, 0x43d, 0x443, 0x442, 0x430, +0x27, 0x2c, 0x20, 0x73, 0x73, 0x20, 0x27, 0x441, 0x435, 0x43a, 0x443, 0x43d, 0x434, 0x438, 0x27, 0x20, 0x74, 0x48, 0x48, 0x27, +0x68, 0x27, 0x27, 0x27, 0x6d, 0x6d, 0x3a, 0x73, 0x73, 0x20, 0x74, 0x48, 0x48, 0x27, 0x48, 0x27, 0x6d, 0x6d, 0x27, 0x27, +0x73, 0x73, 0x27, 0x27, 0x20, 0x74, 0x48, 0x20, 0xe19, 0xe32, 0xe2c, 0xe34, 0xe01, 0xe32, 0x20, 0x6d, 0x20, 0xe19, 0xe32, 0xe17, +0xe35, 0x20, 0x73, 0x73, 0x20, 0xe27, 0xe34, 0xe19, 0xe32, 0xe17, 0xe35, 0x20, 0x74 }; static const ushort months_data[] = { diff --git a/util/local_database/cldr2qlocalexml.py b/util/local_database/cldr2qlocalexml.py index ede7763..fa9ab47 100755 --- a/util/local_database/cldr2qlocalexml.py +++ b/util/local_database/cldr2qlocalexml.py @@ -45,6 +45,7 @@ import sys import enumdata import xpathlite from xpathlite import DraftResolution +from dateconverter import convert_date import re findEntry = xpathlite.findEntry @@ -144,10 +145,10 @@ def generateLocaleInfo(path): result['exp'] = get_number_in_system(path, "numbers/symbols/exponential", numbering_system).lower() result['am'] = findEntry(path, "dates/calendars/calendar[gregorian]/dayPeriods/dayPeriodContext[format]/dayPeriodWidth[wide]/dayPeriod[am]", draft) result['pm'] = findEntry(path, "dates/calendars/calendar[gregorian]/dayPeriods/dayPeriodContext[format]/dayPeriodWidth[wide]/dayPeriod[pm]", draft) - result['longDateFormat'] = findEntry(path, "dates/calendars/calendar[gregorian]/dateFormats/dateFormatLength[full]/dateFormat/pattern") - result['shortDateFormat'] = findEntry(path, "dates/calendars/calendar[gregorian]/dateFormats/dateFormatLength[short]/dateFormat/pattern") - result['longTimeFormat'] = findEntry(path, "dates/calendars/calendar[gregorian]/timeFormats/timeFormatLength[full]/timeFormat/pattern") - result['shortTimeFormat'] = findEntry(path, "dates/calendars/calendar[gregorian]/timeFormats/timeFormatLength[short]/timeFormat/pattern") + result['longDateFormat'] = convert_date(findEntry(path, "dates/calendars/calendar[gregorian]/dateFormats/dateFormatLength[full]/dateFormat/pattern")) + result['shortDateFormat'] = convert_date(findEntry(path, "dates/calendars/calendar[gregorian]/dateFormats/dateFormatLength[short]/dateFormat/pattern")) + result['longTimeFormat'] = convert_date(findEntry(path, "dates/calendars/calendar[gregorian]/timeFormats/timeFormatLength[full]/timeFormat/pattern")) + result['shortTimeFormat'] = convert_date(findEntry(path, "dates/calendars/calendar[gregorian]/timeFormats/timeFormatLength[short]/timeFormat/pattern")) standalone_long_month_path = "dates/calendars/calendar[gregorian]/months/monthContext[stand-alone]/monthWidth[wide]/month" result['standaloneLongMonths'] \ diff --git a/util/local_database/dateconverter.py b/util/local_database/dateconverter.py new file mode 100755 index 0000000..3fe94a2 --- /dev/null +++ b/util/local_database/dateconverter.py @@ -0,0 +1,120 @@ +#!/usr/bin/env python +############################################################################# +## +## 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$ +## +############################################################################# + +import re + +def _convert_pattern(pattern): + # patterns from http://www.unicode.org/reports/tr35/#Date_Format_Patterns + qt_regexps = { + r"yyy{3,}" : "yyyy", # more that three digits hence convert to four-digit year + r"L" : "M", # stand-alone month names. not supported. + r"g{1,}": "", # modified julian day. not supported. + r"S{1,}" : "", # fractional seconds. not supported. + r"A{1,}" : "" # milliseconds in day. not supported. + } + qt_patterns = { + "G" : "", "GG" : "", "GGG" : "", "GGGG" : "", "GGGGG" : "", # Era. not supported. + "y" : "yyyy", # four-digit year without leading zeroes + "Q" : "", "QQ" : "", "QQQ" : "", "QQQQ" : "", # quarter. not supported. + "q" : "", "qq" : "", "qqq" : "", "qqqq" : "", # quarter. not supported. + "MMMMM" : "MMM", # narrow month name. + "LLLLL" : "MMM", # stand-alone narrow month name. + "l" : "", # special symbol for chinese leap month. not supported. + "w" : "", "W" : "", # week of year/month. not supported. + "D" : "", "DD" : "", "DDD" : "", # day of year. not supported. + "F" : "", # day of week in month. not supported. + "E" : "ddd", "EE" : "ddd", "EEE" : "ddd", "EEEEE" : "ddd", "EEEE" : "dddd", # day of week + "e" : "ddd", "ee" : "ddd", "eee" : "ddd", "eeeee" : "ddd", "eeee" : "dddd", # local day of week + "c" : "ddd", "cc" : "ddd", "ccc" : "ddd", "ccccc" : "ddd", "cccc" : "dddd", # stand-alone local day of week + "a" : "AP", # AM/PM + "K" : "h", # Hour 0-11 + "k" : "H", # Hour 1-24 + "j" : "", # special reserved symbol. + "z" : "t", "zz" : "t", "zzz" : "t", "zzzz" : "t", # timezone + "Z" : "t", "ZZ" : "t", "ZZZ" : "t", "ZZZZ" : "t", # timezone + "v" : "t", "vv" : "t", "vvv" : "t", "vvvv" : "t", # timezone + "V" : "t", "VV" : "t", "VVV" : "t", "VVVV" : "t" # timezone + } + if qt_patterns.has_key(pattern): + return qt_patterns[pattern] + for r,v in qt_regexps.items(): + pattern = re.sub(r, v, pattern) + return pattern + +def convert_date(input): + result = "" + patterns = "GyYuQqMLlwWdDFgEecahHKkjmsSAzZvV" + last = "" + inquote = 0 + chars_to_strip = " -" + for c in input: + if c == "'": + inquote = inquote + 1 + if inquote % 2 == 0: + if c in patterns: + if not last: + last = c + else: + if c in last: + last += c + else: + # pattern changed + converted = _convert_pattern(last) + result += converted + if not converted: + result = result.rstrip(chars_to_strip) + last = c + continue + if last: + # pattern ended + converted = _convert_pattern(last) + result += converted + if not converted: + result = result.rstrip(chars_to_strip) + last = "" + result += c + if last: + converted = _convert_pattern(last) + result += converted + if not converted: + result = result.rstrip(chars_to_strip) + return result.lstrip(chars_to_strip) -- cgit v0.12 From cb65d5a354bf0eb2be6a3f24a8352874a4aaf877 Mon Sep 17 00:00:00 2001 From: Denis Dzyubenko Date: Fri, 16 Apr 2010 12:47:03 +0200 Subject: Document the time format pattern for timezone info. Apparently Qt already supports a format pattern for the timezone info, so it should be mentioned in the doc. Reviewed-by: Thiago --- src/corelib/tools/qdatetime.cpp | 1 + 1 file changed, 1 insertion(+) diff --git a/src/corelib/tools/qdatetime.cpp b/src/corelib/tools/qdatetime.cpp index 459d76a..c12095f 100644 --- a/src/corelib/tools/qdatetime.cpp +++ b/src/corelib/tools/qdatetime.cpp @@ -1611,6 +1611,7 @@ QString QTime::toString(Qt::DateFormat format) const \i use AM/PM display. \e AP will be replaced by either "AM" or "PM". \row \i ap or a \i use am/pm display. \e ap will be replaced by either "am" or "pm". + \row \i t \i the timezone (for example "CEST") \endtable All other input characters will be ignored. Any sequence of characters that -- cgit v0.12 From 515edc27b0f9738fb3a95f0bb61633b6091fdd5e Mon Sep 17 00:00:00 2001 From: Thiago Macieira Date: Wed, 14 Apr 2010 16:38:48 +0200 Subject: Add a TCP stress-test test --- .../auto/qtcpsocket_stresstest/minihttpserver.cpp | 214 + tests/auto/qtcpsocket_stresstest/minihttpserver.h | 99 + .../qtcpsocket_stresstest.pro | 11 + tests/auto/qtcpsocket_stresstest/qtest/bigfile | 17980 +++++++++++++++++++ .../tst_qtcpsocket_stresstest.cpp | 109 + tests/auto/qtcpsocket_stresstest/wwwfiles.qrc | 5 + 6 files changed, 18418 insertions(+) create mode 100644 tests/auto/qtcpsocket_stresstest/minihttpserver.cpp create mode 100644 tests/auto/qtcpsocket_stresstest/minihttpserver.h create mode 100644 tests/auto/qtcpsocket_stresstest/qtcpsocket_stresstest.pro create mode 100644 tests/auto/qtcpsocket_stresstest/qtest/bigfile create mode 100644 tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp create mode 100644 tests/auto/qtcpsocket_stresstest/wwwfiles.qrc diff --git a/tests/auto/qtcpsocket_stresstest/minihttpserver.cpp b/tests/auto/qtcpsocket_stresstest/minihttpserver.cpp new file mode 100644 index 0000000..3630674 --- /dev/null +++ b/tests/auto/qtcpsocket_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 +#include +#include +#include +#include + +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(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/auto/qtcpsocket_stresstest/minihttpserver.h b/tests/auto/qtcpsocket_stresstest/minihttpserver.h new file mode 100644 index 0000000..9fcc8fc --- /dev/null +++ b/tests/auto/qtcpsocket_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 +#include +#include + +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/auto/qtcpsocket_stresstest/qtcpsocket_stresstest.pro b/tests/auto/qtcpsocket_stresstest/qtcpsocket_stresstest.pro new file mode 100644 index 0000000..2f67535 --- /dev/null +++ b/tests/auto/qtcpsocket_stresstest/qtcpsocket_stresstest.pro @@ -0,0 +1,11 @@ +load(qttest_p4) + +QT = core network + +SOURCES += tst_qtcpsocket_stresstest.cpp \ + minihttpserver.cpp + +HEADERS += \ + minihttpserver.h + +RESOURCES += wwwfiles.qrc diff --git a/tests/auto/qtcpsocket_stresstest/qtest/bigfile b/tests/auto/qtcpsocket_stresstest/qtest/bigfile new file mode 100644 index 0000000..cb114a2 --- /dev/null +++ b/tests/auto/qtcpsocket_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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp b/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp new file mode 100644 index 0000000..aeada4c --- /dev/null +++ b/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp @@ -0,0 +1,109 @@ +/**************************************************************************** +** +** 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 +#include +#include +#include +#include + +#include "minihttpserver.h" +#include "../network-settings.h" + +class tst_QTcpSocket_stresstest : public QObject +{ + Q_OBJECT +public: + tst_QTcpSocket_stresstest(); + MiniHttpServer server; + +public slots: + void initTestCase_data(); + +private Q_SLOTS: + void blockingConnectDisconnect(); +}; + +tst_QTcpSocket_stresstest::tst_QTcpSocket_stresstest() +{ +} + +void tst_QTcpSocket_stresstest::initTestCase_data() +{ + QTest::addColumn("isLocalhost"); + QTest::addColumn("hostname"); + QTest::addColumn("port"); + + QTest::newRow("localhost") << false << "localhost" << server.port(); + QTest::newRow("remote") << true << QtNetworkSettings::serverName() << 80; +} + +void tst_QTcpSocket_stresstest::blockingConnectDisconnect() +{ + QFETCH_GLOBAL(QString, hostname); + QFETCH_GLOBAL(int, port); + + for (int i = 0; i < 50; ++i) { + qDebug("Attempt %d", i); + 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"); + + QElapsedTimer timeout; + timeout.start(); + while (socket.state() == QAbstractSocket::ConnectedState && !timeout.hasExpired(10000)) { + socket.waitForReadyRead(); + socket.readAll(); // discard + } + } +} + +QTEST_MAIN(tst_QTcpSocket_stresstest); + +#include "tst_qtcpsocket_stresstest.moc" diff --git a/tests/auto/qtcpsocket_stresstest/wwwfiles.qrc b/tests/auto/qtcpsocket_stresstest/wwwfiles.qrc new file mode 100644 index 0000000..b1d4be6 --- /dev/null +++ b/tests/auto/qtcpsocket_stresstest/wwwfiles.qrc @@ -0,0 +1,5 @@ + + + qtest + + -- cgit v0.12 From 94119f30748e21440275535f3d681e45e28183e4 Mon Sep 17 00:00:00 2001 From: Thiago Macieira Date: Wed, 14 Apr 2010 17:20:57 +0200 Subject: Add two more blocking tests --- .../tst_qtcpsocket_stresstest.cpp | 99 +++++++++++++++++++++- 1 file changed, 98 insertions(+), 1 deletion(-) diff --git a/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp b/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp index aeada4c..1763158 100644 --- a/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp +++ b/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp @@ -52,6 +52,7 @@ class tst_QTcpSocket_stresstest : public QObject { Q_OBJECT public: + enum { AttemptCount = 100 }; tst_QTcpSocket_stresstest(); MiniHttpServer server; @@ -60,6 +61,8 @@ public slots: private Q_SLOTS: void blockingConnectDisconnect(); + void blockingPipelined(); + void blockingMultipleRequests(); }; tst_QTcpSocket_stresstest::tst_QTcpSocket_stresstest() @@ -81,7 +84,7 @@ void tst_QTcpSocket_stresstest::blockingConnectDisconnect() QFETCH_GLOBAL(QString, hostname); QFETCH_GLOBAL(int, port); - for (int i = 0; i < 50; ++i) { + for (int i = 0; i < AttemptCount; ++i) { qDebug("Attempt %d", i); QTcpSocket socket; socket.connectToHost(hostname, port); @@ -104,6 +107,100 @@ void tst_QTcpSocket_stresstest::blockingConnectDisconnect() } } +void tst_QTcpSocket_stresstest::blockingPipelined() +{ + QFETCH_GLOBAL(QString, hostname); + QFETCH_GLOBAL(int, port); + + for (int i = 0; i < AttemptCount / 2; ++i) { + QTcpSocket socket; + socket.connectToHost(hostname, port); + QVERIFY2(socket.waitForConnected(), "Timeout"); + + for (int j = 0 ; j < 3; ++j) { + 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"); + } + + QElapsedTimer timeout; + timeout.start(); + while (socket.state() == QAbstractSocket::ConnectedState && !timeout.hasExpired(10000)) { + socket.waitForReadyRead(); + socket.readAll(); // discard + } + } +} + +void tst_QTcpSocket_stresstest::blockingMultipleRequests() +{ + QFETCH_GLOBAL(QString, hostname); + QFETCH_GLOBAL(int, port); + + 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) { + qDebug("Attempt %d", i * 5 + j); + + 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"); + + QElapsedTimer timeout; + timeout.start(); + + qint64 bytesRead = 0; + qint64 bytesExpected = -1; + QByteArray buffer; + while (socket.state() == QAbstractSocket::ConnectedState && !timeout.hasExpired(10000)) { + socket.waitForReadyRead(); + buffer += socket.readAll(); + int pos = buffer.indexOf("\r\n\r\n"); + if (pos == -1) + continue; + + bytesRead = buffer.length() - pos - 1; + + buffer.truncate(pos); + buffer = buffer.toLower(); + pos = buffer.indexOf("\r\ncontent-length: "); + if (pos == -1) + break; + pos += strlen("\r\ncontent-length: "); + + int eol = buffer.indexOf("\r\n", pos + 2); + if (eol == -1) + break; + + bytesExpected = buffer.mid(pos, eol - pos).toLongLong(); + break; + } + QVERIFY2(!timeout.hasExpired(10000), "Timeout"); + + while (socket.state() == QAbstractSocket::ConnectedState && !timeout.hasExpired(10000) && bytesExpected > bytesRead) { + socket.waitForReadyRead(); + bytesRead += socket.read(bytesExpected - bytesRead).length(); // discard + } + QVERIFY2(!timeout.hasExpired(10000), "Timeout"); + } + + socket.disconnectFromHost(); + QVERIFY(socket.state() == QAbstractSocket::UnconnectedState); + } +} + QTEST_MAIN(tst_QTcpSocket_stresstest); #include "tst_qtcpsocket_stresstest.moc" -- cgit v0.12 From 46faa5d37e2dbe30f7683ae9e4f70b1c8723da96 Mon Sep 17 00:00:00 2001 From: Thiago Macieira Date: Wed, 14 Apr 2010 17:24:53 +0200 Subject: Add a simple event-loop based test --- .../tst_qtcpsocket_stresstest.cpp | 26 ++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp b/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp index 1763158..6a57d20 100644 --- a/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp +++ b/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp @@ -63,6 +63,7 @@ private Q_SLOTS: void blockingConnectDisconnect(); void blockingPipelined(); void blockingMultipleRequests(); + void connectDisconnect(); }; tst_QTcpSocket_stresstest::tst_QTcpSocket_stresstest() @@ -201,6 +202,31 @@ void tst_QTcpSocket_stresstest::blockingMultipleRequests() } } +void tst_QTcpSocket_stresstest::connectDisconnect() +{ + QFETCH_GLOBAL(QString, hostname); + QFETCH_GLOBAL(int, port); + + for (int i = 0; i < AttemptCount; ++i) { + qDebug("Attempt %d", i); + QTcpSocket socket; + socket.connectToHost(hostname, port); + QTestEventLoop::instance().connect(&socket, SIGNAL(connected()), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(30); + QVERIFY2(!QTestEventLoop::instance().timeout(), "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"); + + QTestEventLoop::instance().connect(&socket, SIGNAL(disconnected()), SLOT(exitLoop())); + QTestEventLoop::instance().enterLoop(30); + QVERIFY2(!QTestEventLoop::instance().timeout(), "Timeout"); + } +} + QTEST_MAIN(tst_QTcpSocket_stresstest); #include "tst_qtcpsocket_stresstest.moc" -- cgit v0.12 From 3f0a30213925932acbff0db697378ca2135f0998 Mon Sep 17 00:00:00 2001 From: Thiago Macieira Date: Wed, 14 Apr 2010 17:30:14 +0200 Subject: Add an event-loop based test that does parallel fetches --- .../tst_qtcpsocket_stresstest.cpp | 39 ++++++++++++++++++++-- 1 file changed, 36 insertions(+), 3 deletions(-) diff --git a/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp b/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp index 6a57d20..b706b7f 100644 --- a/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp +++ b/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp @@ -64,6 +64,7 @@ private Q_SLOTS: void blockingPipelined(); void blockingMultipleRequests(); void connectDisconnect(); + void parallelConnectDisconnect(); }; tst_QTcpSocket_stresstest::tst_QTcpSocket_stresstest() @@ -211,9 +212,6 @@ void tst_QTcpSocket_stresstest::connectDisconnect() qDebug("Attempt %d", i); QTcpSocket socket; socket.connectToHost(hostname, port); - QTestEventLoop::instance().connect(&socket, SIGNAL(connected()), SLOT(exitLoop())); - QTestEventLoop::instance().enterLoop(30); - QVERIFY2(!QTestEventLoop::instance().timeout(), "Timeout"); socket.write("GET /qtest/bigfile HTTP/1.1\r\n" "Connection: close\r\n" @@ -227,6 +225,41 @@ void tst_QTcpSocket_stresstest::connectDisconnect() } } +void tst_QTcpSocket_stresstest::parallelConnectDisconnect() +{ + QFETCH_GLOBAL(QString, hostname); + QFETCH_GLOBAL(int, port); + + for (int i = 0; i < AttemptCount/4; ++i) { + qDebug("Attempt %d", i); + const int parallelAttempts = 6; + QTcpSocket socket[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"); + + QTestEventLoop::instance().connect(&socket[j], SIGNAL(disconnected()), SLOT(exitLoop())); + } + + QElapsedTimer timeout; + timeout.start(); + while (!timeout.hasExpired(10000)) { + 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; + } + QVERIFY2(!timeout.hasExpired(10000), "Timeout"); + } +} + QTEST_MAIN(tst_QTcpSocket_stresstest); #include "tst_qtcpsocket_stresstest.moc" -- cgit v0.12 From 1bcf16555604ed3f030e685da4c7a7257338c3cc Mon Sep 17 00:00:00 2001 From: Thiago Macieira Date: Wed, 14 Apr 2010 17:34:35 +0200 Subject: Update the parallel test to do different counts of parallel tests --- .../tst_qtcpsocket_stresstest.cpp | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp b/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp index b706b7f..aabadf7 100644 --- a/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp +++ b/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp @@ -64,6 +64,7 @@ private Q_SLOTS: void blockingPipelined(); void blockingMultipleRequests(); void connectDisconnect(); + void parallelConnectDisconnect_data(); void parallelConnectDisconnect(); }; @@ -225,15 +226,26 @@ void tst_QTcpSocket_stresstest::connectDisconnect() } } +void tst_QTcpSocket_stresstest::parallelConnectDisconnect_data() +{ + QTest::addColumn("parallelAttempts"); + QTest::newRow("1") << 1; + QTest::newRow("2") << 2; + QTest::newRow("4") << 4; + QTest::newRow("5") << 5; + QTest::newRow("10") << 10; + QTest::newRow("25") << 25; +} + void tst_QTcpSocket_stresstest::parallelConnectDisconnect() { QFETCH_GLOBAL(QString, hostname); QFETCH_GLOBAL(int, port); + QFETCH(int, parallelAttempts); - for (int i = 0; i < AttemptCount/4; ++i) { + for (int i = 0; i < AttemptCount/qMax(2, parallelAttempts/4); ++i) { qDebug("Attempt %d", i); - const int parallelAttempts = 6; - QTcpSocket socket[parallelAttempts]; + QTcpSocket *socket = new QTcpSocket[parallelAttempts]; for (int j = 0; j < parallelAttempts; ++j) { socket[j].connectToHost(hostname, port); @@ -256,6 +268,7 @@ void tst_QTcpSocket_stresstest::parallelConnectDisconnect() if (done == parallelAttempts) break; } + delete[] socket; QVERIFY2(!timeout.hasExpired(10000), "Timeout"); } } -- cgit v0.12 From d7a2c6b051f08b71f439e8fa91ff5316fbdd4be1 Mon Sep 17 00:00:00 2001 From: Thiago Macieira Date: Wed, 14 Apr 2010 18:16:14 +0200 Subject: Make sure we read the data, to avoid keeping it all on RAM --- tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp b/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp index aabadf7..a4d5096 100644 --- a/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp +++ b/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp @@ -59,6 +59,8 @@ public: public slots: void initTestCase_data(); + void slotReadAll() { static_cast(sender())->readAll(); } + private Q_SLOTS: void blockingConnectDisconnect(); void blockingPipelined(); @@ -219,6 +221,7 @@ void tst_QTcpSocket_stresstest::connectDisconnect() "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); @@ -235,6 +238,7 @@ void tst_QTcpSocket_stresstest::parallelConnectDisconnect_data() QTest::newRow("5") << 5; QTest::newRow("10") << 10; QTest::newRow("25") << 25; + QTest::newRow("100") << 100; } void tst_QTcpSocket_stresstest::parallelConnectDisconnect() @@ -254,13 +258,14 @@ void tst_QTcpSocket_stresstest::parallelConnectDisconnect() "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())); } QElapsedTimer timeout; timeout.start(); - while (!timeout.hasExpired(10000)) { + while (!timeout.hasExpired(30000)) { QTestEventLoop::instance().enterLoop(10); int done = 0; for (int j = 0; j < parallelAttempts; ++j) @@ -269,7 +274,8 @@ void tst_QTcpSocket_stresstest::parallelConnectDisconnect() break; } delete[] socket; - QVERIFY2(!timeout.hasExpired(10000), "Timeout"); + QVERIFY2(!timeout.hasExpired(30000), "Timeout"); + //qDebug() << "Run-time was" << timeout.elapsed(); } } -- cgit v0.12 From 212febae195d5842d62087ac24c43fb2db979393 Mon Sep 17 00:00:00 2001 From: Thiago Macieira Date: Wed, 14 Apr 2010 18:22:03 +0200 Subject: Add the test to the testsuite, but disabled --- tests/auto/network.pro | 2 ++ tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp | 7 +++++++ 2 files changed, 9 insertions(+) diff --git a/tests/auto/network.pro b/tests/auto/network.pro index 4f205fe..7aa4313 100644 --- a/tests/auto/network.pro +++ b/tests/auto/network.pro @@ -34,6 +34,8 @@ SUBDIRS=\ qsslerror \ qsslkey \ qsslsocket \ + qtcpsocket_stresstest \ + contains(QT_CONFIG, private_tests): SUBDIRS -= \ qhttpnetworkconnection \ diff --git a/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp b/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp index a4d5096..d8c71e6 100644 --- a/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp +++ b/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp @@ -58,6 +58,7 @@ public: public slots: void initTestCase_data(); + void init(); void slotReadAll() { static_cast(sender())->readAll(); } @@ -84,6 +85,12 @@ void tst_QTcpSocket_stresstest::initTestCase_data() QTest::newRow("remote") << true << QtNetworkSettings::serverName() << 80; } +void tst_QTcpSocket_stresstest::init() +{ + if (qgetenv("QTCPSOCKET_STRESSTEST").toInt() == 0) + QSKIP("Stress test disabled", SkipAll); +} + void tst_QTcpSocket_stresstest::blockingConnectDisconnect() { QFETCH_GLOBAL(QString, hostname); -- cgit v0.12 From c9d2b51d27a2a836053ce450fc6e0ba277dc9068 Mon Sep 17 00:00:00 2001 From: Thiago Macieira Date: Thu, 15 Apr 2010 13:07:11 +0200 Subject: Add some statistics in the transfer rate --- .../tst_qtcpsocket_stresstest.cpp | 117 +++++++++++++++------ 1 file changed, 87 insertions(+), 30 deletions(-) diff --git a/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp b/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp index d8c71e6..47bf854 100644 --- a/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp +++ b/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp @@ -56,11 +56,13 @@ public: tst_QTcpSocket_stresstest(); MiniHttpServer server; + qint64 byteCounter; + public slots: void initTestCase_data(); void init(); - void slotReadAll() { static_cast(sender())->readAll(); } + void slotReadAll() { byteCounter += static_cast(sender())->readAll().size(); } private Q_SLOTS: void blockingConnectDisconnect(); @@ -81,8 +83,8 @@ void tst_QTcpSocket_stresstest::initTestCase_data() QTest::addColumn("hostname"); QTest::addColumn("port"); - QTest::newRow("localhost") << false << "localhost" << server.port(); - QTest::newRow("remote") << true << QtNetworkSettings::serverName() << 80; + QTest::newRow("localhost") << true << "localhost" << server.port(); + QTest::newRow("remote") << false << QtNetworkSettings::serverName() << 80; } void tst_QTcpSocket_stresstest::init() @@ -96,13 +98,17 @@ void tst_QTcpSocket_stresstest::blockingConnectDisconnect() QFETCH_GLOBAL(QString, hostname); QFETCH_GLOBAL(int, port); + double avg = 0; for (int i = 0; i < AttemptCount; ++i) { - qDebug("Attempt %d", 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" + socket.write("GET /qtest/mediumfile HTTP/1.1\r\n" "Connection: close\r\n" "User-Agent: tst_QTcpSocket_stresstest/1.0\r\n" "Host: " + hostname.toLatin1() + "\r\n" @@ -110,13 +116,16 @@ void tst_QTcpSocket_stresstest::blockingConnectDisconnect() while (socket.bytesToWrite()) QVERIFY2(socket.waitForBytesWritten(), "Timeout"); - QElapsedTimer timeout; - timeout.start(); while (socket.state() == QAbstractSocket::ConnectedState && !timeout.hasExpired(10000)) { socket.waitForReadyRead(); - socket.readAll(); // discard + byteCounter += socket.readAll().size(); // discard } + double rate = (byteCounter / timeout.elapsed()); + avg = (i * avg + rate) / (i + 1); + qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" + << (rate / 1024.0 / 1024 * 1000) << "MB/s"; } + qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; } void tst_QTcpSocket_stresstest::blockingPipelined() @@ -124,14 +133,19 @@ void tst_QTcpSocket_stresstest::blockingPipelined() QFETCH_GLOBAL(QString, hostname); QFETCH_GLOBAL(int, port); + double avg = 0; 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) { qDebug("Attempt %d%c", i, 'a' + j); - socket.write("GET /qtest/bigfile HTTP/1.1\r\n" + socket.write("GET /qtest/mediumfile 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" @@ -140,13 +154,17 @@ void tst_QTcpSocket_stresstest::blockingPipelined() QVERIFY2(socket.waitForBytesWritten(), "Timeout"); } - QElapsedTimer timeout; - timeout.start(); while (socket.state() == QAbstractSocket::ConnectedState && !timeout.hasExpired(10000)) { socket.waitForReadyRead(); - socket.readAll(); // discard + byteCounter += socket.readAll().size(); // discard } + + double rate = (byteCounter / timeout.elapsed()); + avg = (i * avg + rate) / (i + 1); + qDebug() << byteCounter << "bytes in" << timeout.elapsed() << "ms:" + << (rate / 1024.0 / 1024 * 1000) << "MB/s"; } + qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; } void tst_QTcpSocket_stresstest::blockingMultipleRequests() @@ -154,15 +172,18 @@ void tst_QTcpSocket_stresstest::blockingMultipleRequests() QFETCH_GLOBAL(QString, hostname); QFETCH_GLOBAL(int, port); + double avg = 0; 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) { - qDebug("Attempt %d", i * 5 + j); + QElapsedTimer timeout; + byteCounter = 0; + timeout.start(); - socket.write("GET /qtest/bigfile HTTP/1.1\r\n" + socket.write("GET /qtest/mediumfile HTTP/1.1\r\n" "Connection: keep-alive\r\n" "User-Agent: tst_QTcpSocket_stresstest/1.0\r\n" "Host: " + hostname.toLatin1() + "\r\n" @@ -170,47 +191,59 @@ void tst_QTcpSocket_stresstest::blockingMultipleRequests() while (socket.bytesToWrite()) QVERIFY2(socket.waitForBytesWritten(), "Timeout"); - QElapsedTimer timeout; - timeout.start(); - 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 - 1; + bytesRead = buffer.length() - pos - 4; - buffer.truncate(pos); + buffer.truncate(pos + 2); buffer = buffer.toLower(); pos = buffer.indexOf("\r\ncontent-length: "); - if (pos == -1) + 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) + 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(); - bytesRead += socket.read(bytesExpected - bytesRead).length(); // discard + int blocklen = socket.read(bytesExpected - bytesRead).length(); // discard + bytesRead += blocklen; + byteCounter += blocklen; } QVERIFY2(!timeout.hasExpired(10000), "Timeout"); + QCOMPARE(bytesRead, bytesExpected); + + double rate = (byteCounter / timeout.elapsed()); + avg = (i * avg + rate) / (i + 1); + qDebug() << i * 5 + j << 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" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; } void tst_QTcpSocket_stresstest::connectDisconnect() @@ -218,12 +251,16 @@ void tst_QTcpSocket_stresstest::connectDisconnect() QFETCH_GLOBAL(QString, hostname); QFETCH_GLOBAL(int, port); + double avg = 0; for (int i = 0; i < AttemptCount; ++i) { - qDebug("Attempt %d", i); + QElapsedTimer timeout; + byteCounter = 0; + timeout.start(); + QTcpSocket socket; socket.connectToHost(hostname, port); - socket.write("GET /qtest/bigfile HTTP/1.1\r\n" + socket.write("GET /qtest/mediumfile HTTP/1.1\r\n" "Connection: close\r\n" "User-Agent: tst_QTcpSocket_stresstest/1.0\r\n" "Host: " + hostname.toLatin1() + "\r\n" @@ -233,7 +270,12 @@ void tst_QTcpSocket_stresstest::connectDisconnect() QTestEventLoop::instance().connect(&socket, SIGNAL(disconnected()), SLOT(exitLoop())); QTestEventLoop::instance().enterLoop(30); QVERIFY2(!QTestEventLoop::instance().timeout(), "Timeout"); + double rate = (byteCounter / timeout.elapsed()); + avg = (i * avg + rate) / (i + 1); + qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" + << (rate / 1024.0 / 1024 * 1000) << "MB/s"; } + qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; } void tst_QTcpSocket_stresstest::parallelConnectDisconnect_data() @@ -243,9 +285,12 @@ void tst_QTcpSocket_stresstest::parallelConnectDisconnect_data() 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_QTcpSocket_stresstest::parallelConnectDisconnect() @@ -254,13 +299,23 @@ void tst_QTcpSocket_stresstest::parallelConnectDisconnect() QFETCH_GLOBAL(int, port); QFETCH(int, parallelAttempts); - for (int i = 0; i < AttemptCount/qMax(2, parallelAttempts/4); ++i) { - qDebug("Attempt %d", i); + if (parallelAttempts > 100) { + QFETCH_GLOBAL(bool, isLocalhost); + if (!isLocalhost) + QSKIP("Localhost-only test", SkipSingle); + } + + double avg = 0; + 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" + socket[j].write("GET /qtest/mediumfile HTTP/1.1\r\n" "Connection: close\r\n" "User-Agent: tst_QTcpSocket_stresstest/1.0\r\n" "Host: " + hostname.toLatin1() + "\r\n" @@ -270,8 +325,6 @@ void tst_QTcpSocket_stresstest::parallelConnectDisconnect() QTestEventLoop::instance().connect(&socket[j], SIGNAL(disconnected()), SLOT(exitLoop())); } - QElapsedTimer timeout; - timeout.start(); while (!timeout.hasExpired(30000)) { QTestEventLoop::instance().enterLoop(10); int done = 0; @@ -282,8 +335,12 @@ void tst_QTcpSocket_stresstest::parallelConnectDisconnect() } delete[] socket; QVERIFY2(!timeout.hasExpired(30000), "Timeout"); - //qDebug() << "Run-time was" << timeout.elapsed(); + double rate = (byteCounter / timeout.elapsed()); + avg = (i * avg + rate) / (i + 1); + qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" + << (rate / 1024.0 / 1024 * 1000) << "MB/s"; } + qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; } QTEST_MAIN(tst_QTcpSocket_stresstest); -- cgit v0.12 From b441cb1fbcbc8ea38a56d1f44972d16d136cb9f6 Mon Sep 17 00:00:00 2001 From: Thiago Macieira Date: Thu, 15 Apr 2010 13:07:24 +0200 Subject: Add a native test to compare with --- .../tst_qtcpsocket_stresstest.cpp | 126 +++++++++++++++++++++ 1 file changed, 126 insertions(+) diff --git a/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp b/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp index 47bf854..0184bfe 100644 --- a/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp +++ b/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp @@ -48,6 +48,17 @@ #include "minihttpserver.h" #include "../network-settings.h" +#include +#ifdef Q_OS_UNIX +# include +# include +# include +# include +# include +#elif defined(Q_OS_WIN) +# include +#endif + class tst_QTcpSocket_stresstest : public QObject { Q_OBJECT @@ -65,6 +76,7 @@ public slots: void slotReadAll() { byteCounter += static_cast(sender())->readAll().size(); } private Q_SLOTS: + void nativeBlockingConnectDisconnect(); void blockingConnectDisconnect(); void blockingPipelined(); void blockingMultipleRequests(); @@ -75,6 +87,12 @@ private Q_SLOTS: tst_QTcpSocket_stresstest::tst_QTcpSocket_stresstest() { +#ifdef Q_OS_WIN + WSAData wsadata; + + // IPv6 requires Winsock v2.0 or better. + WSAStartup(MAKEWORD(2,0), &wsadata); +#endif } void tst_QTcpSocket_stresstest::initTestCase_data() @@ -93,6 +111,114 @@ void tst_QTcpSocket_stresstest::init() QSKIP("Stress test disabled", SkipAll); } +void tst_QTcpSocket_stresstest::nativeBlockingConnectDisconnect() +{ + QFETCH_GLOBAL(QString, hostname); + QFETCH_GLOBAL(int, port); + + double avg = 0; + for (int i = 0; i < AttemptCount; ++i) { + QElapsedTimer timeout; + byteCounter = 0; + timeout.start(); + + // look up the host +#ifdef Q_OS_WIN + SOCKET fd; +#else + int fd; +#endif + { +#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); + QCOMPARE(result, 0); + + // connect loop + fd = -1; + for (addrinfo *node = res; fd == -1 && node; node = node->ai_next) { + fd = ::socket(node->ai_family, node->ai_socktype, node->ai_protocol); + if (fd == -1) + continue; + if (::connect(fd, node->ai_addr, node->ai_addrlen) == -1) { + ::close(fd); + fd = -1; + } else { + break; + } + } + QVERIFY(fd != -1); +#else + hostent *result = gethostbyname(QUrl::toAce(hostname).constData()); + QVERIFY(result); + QCOMPARE(result->h_addrtype, AF_INET); + struct sockaddr_in s; + QT_SOCKLEN_T len = sizeof s; + s.sin_family = AF_INET; + + fd = ::socket(AF_INET, SOCK_STREAM, 0); +# ifdef Q_OS_WIN + QVERIFY(fd != INVALID_SOCKET); + + WSAHtons(fd, port, &(s.sin_port)); + s.sin_addr.s_addr = *(u_long *) result->h_addr_list[0] + + QVERIFY(::connect(fd, (sockaddr*)&s, len) != SOCKET_ERROR); +# else + QVERIFY(fd != -1); + + s.sin_port = htons(port); + s.sin_addr = *(struct in_addr *) result->h_addr_list[0]; + + QVERIFY(::connect(fd, (sockaddr*)&s, len) == 0); +#endif +#endif + } + + // send request + { + QByteArray request = "GET /qtest/mediumfile 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 = ::write(fd, request.constData() + bytesWritten, request.size() - bytesWritten); + if (ret == -1) { + ::close(fd); + QFAIL("Timeout"); + } + bytesWritten += ret; + } + } + + // receive reply + char buf[16384]; + while (true) { + qint64 ret = ::read(fd, buf, sizeof buf); + if (ret == -1) { + ::close(fd); + QFAIL("Timeout"); + } else if (ret == 0) { + break; // EOF + } + byteCounter += ret; + } + ::close(fd); + + double rate = (byteCounter / timeout.elapsed()); + avg = (i * avg + rate) / (i + 1); + qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" + << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + } + qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; +} + void tst_QTcpSocket_stresstest::blockingConnectDisconnect() { QFETCH_GLOBAL(QString, hostname); -- cgit v0.12 From cd28233911dd068a29f12a35fce010136c4d3ff0 Mon Sep 17 00:00:00 2001 From: Thiago Macieira Date: Thu, 15 Apr 2010 13:15:35 +0200 Subject: Move the code around into a function and add an alarm(2) on Unix --- .../tst_qtcpsocket_stresstest.cpp | 120 +++++++++++---------- 1 file changed, 66 insertions(+), 54 deletions(-) diff --git a/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp b/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp index 0184bfe..f3fac26 100644 --- a/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp +++ b/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp @@ -54,7 +54,13 @@ # include # include # include +# include # include + +typedef int SOCKET; +# define INVALID_SOCKET -1 +# define SOCKET_ERROR -1 + #elif defined(Q_OS_WIN) # include #endif @@ -92,6 +98,8 @@ tst_QTcpSocket_stresstest::tst_QTcpSocket_stresstest() // 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 } @@ -111,6 +119,53 @@ void tst_QTcpSocket_stresstest::init() QSKIP("Stress test disabled", SkipAll); } + +void nativeConnect(SOCKET &fd, const char *hostname, int port) +{ +#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); + QCOMPARE(result, 0); + + // connect loop + fd = -1; + for (addrinfo *node = res; fd == -1 && node; node = node->ai_next) { + fd = ::socket(node->ai_family, node->ai_socktype, node->ai_protocol); + if (fd == -1) + continue; + if (::connect(fd, node->ai_addr, node->ai_addrlen) == -1) { + ::close(fd); + fd = -1; + } else { + break; + } + } + QVERIFY(fd != -1); +#else + hostent *result = gethostbyname(hostname); + QVERIFY(result); + QCOMPARE(result->h_addrtype, AF_INET); + struct sockaddr_in s; + QT_SOCKLEN_T len = sizeof s; + s.sin_family = AF_INET; + + fd = ::socket(AF_INET, SOCK_STREAM, 0); + QVERIFY(fd != INVALID_SOCKET); +# ifdef Q_OS_WIN + WSAHtons(fd, port, &(s.sin_port)); + s.sin_addr.s_addr = *(u_long *) result->h_addr_list[0]; +# else + s.sin_port = htons(port); + s.sin_addr = *(struct in_addr *) result->h_addr_list[0]; +#endif + QVERIFY(::connect(fd, (sockaddr*)&s, len) != SOCKET_ERROR); +#endif +} + void tst_QTcpSocket_stresstest::nativeBlockingConnectDisconnect() { QFETCH_GLOBAL(QString, hostname); @@ -122,62 +177,15 @@ void tst_QTcpSocket_stresstest::nativeBlockingConnectDisconnect() byteCounter = 0; timeout.start(); - // look up the host -#ifdef Q_OS_WIN - SOCKET fd; -#else - int fd; +#if defined(Q_OS_UNIX) && !defined(Q_OS_SYMBIAN) + alarm(10); #endif - { -#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); - QCOMPARE(result, 0); - - // connect loop - fd = -1; - for (addrinfo *node = res; fd == -1 && node; node = node->ai_next) { - fd = ::socket(node->ai_family, node->ai_socktype, node->ai_protocol); - if (fd == -1) - continue; - if (::connect(fd, node->ai_addr, node->ai_addrlen) == -1) { - ::close(fd); - fd = -1; - } else { - break; - } - } - QVERIFY(fd != -1); -#else - hostent *result = gethostbyname(QUrl::toAce(hostname).constData()); - QVERIFY(result); - QCOMPARE(result->h_addrtype, AF_INET); - struct sockaddr_in s; - QT_SOCKLEN_T len = sizeof s; - s.sin_family = AF_INET; - - fd = ::socket(AF_INET, SOCK_STREAM, 0); -# ifdef Q_OS_WIN - QVERIFY(fd != INVALID_SOCKET); - - WSAHtons(fd, port, &(s.sin_port)); - s.sin_addr.s_addr = *(u_long *) result->h_addr_list[0] - - QVERIFY(::connect(fd, (sockaddr*)&s, len) != SOCKET_ERROR); -# else - QVERIFY(fd != -1); - - s.sin_port = htons(port); - s.sin_addr = *(struct in_addr *) result->h_addr_list[0]; - - QVERIFY(::connect(fd, (sockaddr*)&s, len) == 0); -#endif -#endif - } + // look up the host + SOCKET fd; + nativeConnect(fd, QUrl::toAce(hostname).constData(), port); + if (fd == INVALID_SOCKET) + return; // send request { @@ -217,6 +225,10 @@ void tst_QTcpSocket_stresstest::nativeBlockingConnectDisconnect() << (rate / 1024.0 / 1024 * 1000) << "MB/s"; } qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; + +#if defined(Q_OS_UNIX) && !defined(Q_OS_SYMBIAN) + alarm(0); +#endif } void tst_QTcpSocket_stresstest::blockingConnectDisconnect() -- cgit v0.12 From bf81038a4e676c228757070028b06114a9fde2f4 Mon Sep 17 00:00:00 2001 From: Thiago Macieira Date: Thu, 15 Apr 2010 14:15:01 +0200 Subject: Add a non-blocking native function too --- .../tst_qtcpsocket_stresstest.cpp | 195 +++++++++++++++++---- 1 file changed, 162 insertions(+), 33 deletions(-) diff --git a/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp b/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp index f3fac26..bc2681a 100644 --- a/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp +++ b/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp @@ -52,10 +52,13 @@ #ifdef Q_OS_UNIX # include # include +# include # include +# include # include # include # include +# include typedef int SOCKET; # define INVALID_SOCKET -1 @@ -83,6 +86,7 @@ public slots: private Q_SLOTS: void nativeBlockingConnectDisconnect(); + void nativeNonBlockingConnectDisconnect(); void blockingConnectDisconnect(); void blockingPipelined(); void blockingMultipleRequests(); @@ -119,8 +123,7 @@ void tst_QTcpSocket_stresstest::init() QSKIP("Stress test disabled", SkipAll); } - -void nativeConnect(SOCKET &fd, const char *hostname, int port) +bool nativeLookup(const char *hostname, int port, QByteArray &buf) { #if !defined(QT_NO_GETADDRINFO) && 0 addrinfo *res = 0; @@ -129,41 +132,54 @@ void nativeConnect(SOCKET &fd, const char *hostname, int port) hints.ai_family = PF_UNSPEC; int result = getaddrinfo(QUrl::toAce(hostname).constData(), QByteArray::number(port).constData(), &hints, &res); - QCOMPARE(result, 0); - - // connect loop - fd = -1; - for (addrinfo *node = res; fd == -1 && node; node = node->ai_next) { - fd = ::socket(node->ai_family, node->ai_socktype, node->ai_protocol); - if (fd == -1) - continue; - if (::connect(fd, node->ai_addr, node->ai_addrlen) == -1) { - ::close(fd); - fd = -1; - } else { + 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; } } - QVERIFY(fd != -1); + freeaddrinfo(res); #else hostent *result = gethostbyname(hostname); - QVERIFY(result); - QCOMPARE(result->h_addrtype, AF_INET); + if (!result || result->h_addrtype != AF_INET) + return false; + struct sockaddr_in s; - QT_SOCKLEN_T len = sizeof s; s.sin_family = AF_INET; - - fd = ::socket(AF_INET, SOCK_STREAM, 0); - QVERIFY(fd != INVALID_SOCKET); -# ifdef Q_OS_WIN - WSAHtons(fd, port, &(s.sin_port)); - s.sin_addr.s_addr = *(u_long *) result->h_addr_list[0]; -# else s.sin_port = htons(port); s.sin_addr = *(struct in_addr *) result->h_addr_list[0]; + + buf = QByteArray((char *)&s, sizeof s); #endif - QVERIFY(::connect(fd, (sockaddr*)&s, len) != SOCKET_ERROR); -#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_QTcpSocket_stresstest::nativeBlockingConnectDisconnect() @@ -182,10 +198,14 @@ void tst_QTcpSocket_stresstest::nativeBlockingConnectDisconnect() #endif // look up the host - SOCKET fd; - nativeConnect(fd, QUrl::toAce(hostname).constData(), port); - if (fd == INVALID_SOCKET) - return; + 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 { @@ -196,7 +216,7 @@ void tst_QTcpSocket_stresstest::nativeBlockingConnectDisconnect() "\r\n"; qint64 bytesWritten = 0; while (bytesWritten < request.size()) { - qint64 ret = ::write(fd, request.constData() + bytesWritten, request.size() - bytesWritten); + qint64 ret = ::send(fd, request.constData() + bytesWritten, request.size() - bytesWritten, 0); if (ret == -1) { ::close(fd); QFAIL("Timeout"); @@ -208,7 +228,7 @@ void tst_QTcpSocket_stresstest::nativeBlockingConnectDisconnect() // receive reply char buf[16384]; while (true) { - qint64 ret = ::read(fd, buf, sizeof buf); + qint64 ret = ::recv(fd, buf, sizeof buf, 0); if (ret == -1) { ::close(fd); QFAIL("Timeout"); @@ -231,6 +251,115 @@ void tst_QTcpSocket_stresstest::nativeBlockingConnectDisconnect() #endif } +void tst_QTcpSocket_stresstest::nativeNonBlockingConnectDisconnect() +{ + QFETCH_GLOBAL(QString, hostname); + QFETCH_GLOBAL(int, port); + + double avg = 0; + 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/mediumfile 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); + + double rate = (byteCounter / timeout.elapsed()); + avg = (i * avg + rate) / (i + 1); + qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" + << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + } + qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; +} + void tst_QTcpSocket_stresstest::blockingConnectDisconnect() { QFETCH_GLOBAL(QString, hostname); -- cgit v0.12 From 062b2b04ffab7261704ea4ca28963af08d86df61 Mon Sep 17 00:00:00 2001 From: Thiago Macieira Date: Thu, 15 Apr 2010 16:54:17 +0200 Subject: Add a QNetworkAccessManager stresstest --- .../qtcpsocket_stresstest.pro | 1 + .../tst_qtcpsocket_stresstest.cpp | 158 ++++++++++++++++++--- 2 files changed, 142 insertions(+), 17 deletions(-) diff --git a/tests/auto/qtcpsocket_stresstest/qtcpsocket_stresstest.pro b/tests/auto/qtcpsocket_stresstest/qtcpsocket_stresstest.pro index 2f67535..47b2682 100644 --- a/tests/auto/qtcpsocket_stresstest/qtcpsocket_stresstest.pro +++ b/tests/auto/qtcpsocket_stresstest/qtcpsocket_stresstest.pro @@ -9,3 +9,4 @@ HEADERS += \ minihttpserver.h RESOURCES += wwwfiles.qrc +QMAKE_RESOURCE_FLAGS += -no-compress diff --git a/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp b/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp index bc2681a..20ae9c0 100644 --- a/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp +++ b/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp @@ -43,7 +43,15 @@ #include #include #include +#include +#include #include +#include +#include + +#ifdef QT_BUILD_INTERNAL +# include +#endif #include "minihttpserver.h" #include "../network-settings.h" @@ -77,12 +85,17 @@ public: MiniHttpServer server; qint64 byteCounter; + QNetworkAccessManager manager; + bool intermediateDebug; + +private: + void clearManager(); public slots: void initTestCase_data(); void init(); - void slotReadAll() { byteCounter += static_cast(sender())->readAll().size(); } + void slotReadAll() { byteCounter += static_cast(sender())->readAll().size(); } private Q_SLOTS: void nativeBlockingConnectDisconnect(); @@ -93,9 +106,12 @@ private Q_SLOTS: void connectDisconnect(); void parallelConnectDisconnect_data(); void parallelConnectDisconnect(); + void namGet_data(); + void namGet(); }; tst_QTcpSocket_stresstest::tst_QTcpSocket_stresstest() + : intermediateDebug(qgetenv("QTCPSOCKET_STRESSTEST").toInt() > 1) { #ifdef Q_OS_WIN WSAData wsadata; @@ -114,13 +130,28 @@ void tst_QTcpSocket_stresstest::initTestCase_data() QTest::addColumn("port"); QTest::newRow("localhost") << true << "localhost" << server.port(); - QTest::newRow("remote") << false << QtNetworkSettings::serverName() << 80; +// QTest::newRow("remote") << false << QtNetworkSettings::serverName() << 80; } void tst_QTcpSocket_stresstest::init() { if (qgetenv("QTCPSOCKET_STRESSTEST").toInt() == 0) QSKIP("Stress test disabled", SkipAll); + + // clear the internal cache +#ifndef QT_BUILD_INTERNAL + if (strncmp(QTest::currentTestFunction(), "nam") == 0) + QSKIP("QNetworkAccessManager tests disabled", SkipAll); +#endif +} + +void tst_QTcpSocket_stresstest::clearManager() +{ +#ifdef QT_BUILD_INTERNAL + QNetworkAccessManagerPrivate::clearCache(&manager); + manager.setProxy(QNetworkProxy()); + manager.setCache(0); +#endif } bool nativeLookup(const char *hostname, int port, QByteArray &buf) @@ -241,8 +272,9 @@ void tst_QTcpSocket_stresstest::nativeBlockingConnectDisconnect() double rate = (byteCounter / timeout.elapsed()); avg = (i * avg + rate) / (i + 1); - qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" - << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + if (intermediateDebug) + qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" + << (rate / 1024.0 / 1024 * 1000) << "MB/s"; } qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; @@ -354,8 +386,9 @@ void tst_QTcpSocket_stresstest::nativeNonBlockingConnectDisconnect() double rate = (byteCounter / timeout.elapsed()); avg = (i * avg + rate) / (i + 1); - qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" - << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + if (intermediateDebug) + qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" + << (rate / 1024.0 / 1024 * 1000) << "MB/s"; } qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; } @@ -389,8 +422,9 @@ void tst_QTcpSocket_stresstest::blockingConnectDisconnect() } double rate = (byteCounter / timeout.elapsed()); avg = (i * avg + rate) / (i + 1); - qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" - << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + if (intermediateDebug) + qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" + << (rate / 1024.0 / 1024 * 1000) << "MB/s"; } qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; } @@ -411,7 +445,8 @@ void tst_QTcpSocket_stresstest::blockingPipelined() QVERIFY2(socket.waitForConnected(), "Timeout"); for (int j = 0 ; j < 3; ++j) { - qDebug("Attempt %d%c", i, 'a' + j); + if (intermediateDebug) + qDebug("Attempt %d%c", i, 'a' + j); socket.write("GET /qtest/mediumfile HTTP/1.1\r\n" "Connection: " + QByteArray(j == 2 ? "close" : "keep-alive") + "\r\n" "User-Agent: tst_QTcpSocket_stresstest/1.0\r\n" @@ -428,8 +463,9 @@ void tst_QTcpSocket_stresstest::blockingPipelined() double rate = (byteCounter / timeout.elapsed()); avg = (i * avg + rate) / (i + 1); - qDebug() << byteCounter << "bytes in" << timeout.elapsed() << "ms:" - << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + if (intermediateDebug) + qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" + << (rate / 1024.0 / 1024 * 1000) << "MB/s"; } qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; } @@ -503,8 +539,9 @@ void tst_QTcpSocket_stresstest::blockingMultipleRequests() double rate = (byteCounter / timeout.elapsed()); avg = (i * avg + rate) / (i + 1); - qDebug() << i * 5 + j << byteCounter << "bytes in" << timeout.elapsed() << "ms:" - << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + if (intermediateDebug) + qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" + << (rate / 1024.0 / 1024 * 1000) << "MB/s"; } socket.disconnectFromHost(); @@ -539,8 +576,9 @@ void tst_QTcpSocket_stresstest::connectDisconnect() QVERIFY2(!QTestEventLoop::instance().timeout(), "Timeout"); double rate = (byteCounter / timeout.elapsed()); avg = (i * avg + rate) / (i + 1); - qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" - << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + if (intermediateDebug) + qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" + << (rate / 1024.0 / 1024 * 1000) << "MB/s"; } qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; } @@ -604,8 +642,94 @@ void tst_QTcpSocket_stresstest::parallelConnectDisconnect() QVERIFY2(!timeout.hasExpired(30000), "Timeout"); double rate = (byteCounter / timeout.elapsed()); avg = (i * avg + rate) / (i + 1); - qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" - << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + if (intermediateDebug) + qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" + << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + } + qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; +} + +void tst_QTcpSocket_stresstest::namGet_data() +{ + QTest::addColumn("parallelAttempts"); + QTest::addColumn("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_QTcpSocket_stresstest::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); + } + + double avg = 0; + 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/mediumfile"); + QNetworkRequest req(url); + req.setAttribute(QNetworkRequest::HttpPipeliningAllowedAttribute, pipelineAllowed); + + QVector > 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(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"); + double rate = (byteCounter / timeout.elapsed()); + avg = (i * avg + rate) / (i + 1); + if (intermediateDebug) + qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" + << (rate / 1024.0 / 1024 * 1000) << "MB/s"; } qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; } -- cgit v0.12 From 14e5bf2963cc48e48b1a9c4c3650df8162d59c09 Mon Sep 17 00:00:00 2001 From: Thiago Macieira Date: Fri, 16 Apr 2010 10:30:41 +0200 Subject: Move these tests to tests/manual. --- tests/auto/network.pro | 2 - .../auto/qtcpsocket_stresstest/minihttpserver.cpp | 214 - tests/auto/qtcpsocket_stresstest/minihttpserver.h | 99 - .../qtcpsocket_stresstest.pro | 12 - tests/auto/qtcpsocket_stresstest/qtest/bigfile | 17980 ------------------- .../tst_qtcpsocket_stresstest.cpp | 739 - tests/auto/qtcpsocket_stresstest/wwwfiles.qrc | 5 - tests/manual/network_stresstest/minihttpserver.cpp | 214 + tests/manual/network_stresstest/minihttpserver.h | 99 + .../network_stresstest/qtcpsocket_stresstest.pro | 12 + tests/manual/network_stresstest/qtest/bigfile | 17980 +++++++++++++++++++ .../tst_qtcpsocket_stresstest.cpp | 739 + tests/manual/network_stresstest/wwwfiles.qrc | 5 + 13 files changed, 19049 insertions(+), 19051 deletions(-) delete mode 100644 tests/auto/qtcpsocket_stresstest/minihttpserver.cpp delete mode 100644 tests/auto/qtcpsocket_stresstest/minihttpserver.h delete mode 100644 tests/auto/qtcpsocket_stresstest/qtcpsocket_stresstest.pro delete mode 100644 tests/auto/qtcpsocket_stresstest/qtest/bigfile delete mode 100644 tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp delete mode 100644 tests/auto/qtcpsocket_stresstest/wwwfiles.qrc create mode 100644 tests/manual/network_stresstest/minihttpserver.cpp create mode 100644 tests/manual/network_stresstest/minihttpserver.h create mode 100644 tests/manual/network_stresstest/qtcpsocket_stresstest.pro create mode 100644 tests/manual/network_stresstest/qtest/bigfile create mode 100644 tests/manual/network_stresstest/tst_qtcpsocket_stresstest.cpp create mode 100644 tests/manual/network_stresstest/wwwfiles.qrc diff --git a/tests/auto/network.pro b/tests/auto/network.pro index 7aa4313..4f205fe 100644 --- a/tests/auto/network.pro +++ b/tests/auto/network.pro @@ -34,8 +34,6 @@ SUBDIRS=\ qsslerror \ qsslkey \ qsslsocket \ - qtcpsocket_stresstest \ - contains(QT_CONFIG, private_tests): SUBDIRS -= \ qhttpnetworkconnection \ diff --git a/tests/auto/qtcpsocket_stresstest/minihttpserver.cpp b/tests/auto/qtcpsocket_stresstest/minihttpserver.cpp deleted file mode 100644 index 3630674..0000000 --- a/tests/auto/qtcpsocket_stresstest/minihttpserver.cpp +++ /dev/null @@ -1,214 +0,0 @@ -/**************************************************************************** -** -** 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 -#include -#include -#include -#include - -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(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/auto/qtcpsocket_stresstest/minihttpserver.h b/tests/auto/qtcpsocket_stresstest/minihttpserver.h deleted file mode 100644 index 9fcc8fc..0000000 --- a/tests/auto/qtcpsocket_stresstest/minihttpserver.h +++ /dev/null @@ -1,99 +0,0 @@ -/**************************************************************************** -** -** 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 -#include -#include - -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/auto/qtcpsocket_stresstest/qtcpsocket_stresstest.pro b/tests/auto/qtcpsocket_stresstest/qtcpsocket_stresstest.pro deleted file mode 100644 index 47b2682..0000000 --- a/tests/auto/qtcpsocket_stresstest/qtcpsocket_stresstest.pro +++ /dev/null @@ -1,12 +0,0 @@ -load(qttest_p4) - -QT = core network - -SOURCES += tst_qtcpsocket_stresstest.cpp \ - minihttpserver.cpp - -HEADERS += \ - minihttpserver.h - -RESOURCES += wwwfiles.qrc -QMAKE_RESOURCE_FLAGS += -no-compress diff --git a/tests/auto/qtcpsocket_stresstest/qtest/bigfile b/tests/auto/qtcpsocket_stresstest/qtest/bigfile deleted file mode 100644 index cb114a2..0000000 --- a/tests/auto/qtcpsocket_stresstest/qtest/bigfile +++ /dev/null @@ -1,17980 +0,0 @@ - - - - - - -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: - - - - -
- - - - - - - - - - - - - - - -
- - - - -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 header - as well as the declaration. - -3.2. Example Datagram - - The following is an example TCPoXML datagram with an empty payload: - - - - - - - - - - - - - - - - - - - - - - - - -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 header - as well as the declaration. - -4.2. Example Datagram - - The following is an example UDPoXML datagram with an empty payload: - - - - - - - - - - - - - - -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 (" - --> - - - - -Kennedy Informational [Page 7] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 9] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 10] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - -7.2. TCPoXML DTD - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 11] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 12] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - -7.3. UDPoXML DTD - - - - - - - - - - - - - - - -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: - - - - -
- - - - - - - - - - - - - - - -
- - - - -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 header - as well as the declaration. - -3.2. Example Datagram - - The following is an example TCPoXML datagram with an empty payload: - - - - - - - - - - - - - - - - - - - - - - - - -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 header - as well as the declaration. - -4.2. Example Datagram - - The following is an example UDPoXML datagram with an empty payload: - - - - - - - - - - - - - - -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 (" - --> - - - - -Kennedy Informational [Page 7] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 9] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 10] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - -7.2. TCPoXML DTD - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 11] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 12] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - -7.3. UDPoXML DTD - - - - - - - - - - - - - - - -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: - - - - -
- - - - - - - - - - - - - - - -
- - - - -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 header - as well as the declaration. - -3.2. Example Datagram - - The following is an example TCPoXML datagram with an empty payload: - - - - - - - - - - - - - - - - - - - - - - - - -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 header - as well as the declaration. - -4.2. Example Datagram - - The following is an example UDPoXML datagram with an empty payload: - - - - - - - - - - - - - - -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 (" - --> - - - - -Kennedy Informational [Page 7] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 9] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 10] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - -7.2. TCPoXML DTD - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 11] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 12] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - -7.3. UDPoXML DTD - - - - - - - - - - - - - - - -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: - - - - -
- - - - - - - - - - - - - - - -
- - - - -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 header - as well as the declaration. - -3.2. Example Datagram - - The following is an example TCPoXML datagram with an empty payload: - - - - - - - - - - - - - - - - - - - - - - - - -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 header - as well as the declaration. - -4.2. Example Datagram - - The following is an example UDPoXML datagram with an empty payload: - - - - - - - - - - - - - - -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 (" - --> - - - - -Kennedy Informational [Page 7] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 9] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 10] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - -7.2. TCPoXML DTD - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 11] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 12] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - -7.3. UDPoXML DTD - - - - - - - - - - - - - - - -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: - - - - -
- - - - - - - - - - - - - - - -
- - - - -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 header - as well as the declaration. - -3.2. Example Datagram - - The following is an example TCPoXML datagram with an empty payload: - - - - - - - - - - - - - - - - - - - - - - - - -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 header - as well as the declaration. - -4.2. Example Datagram - - The following is an example UDPoXML datagram with an empty payload: - - - - - - - - - - - - - - -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 (" - --> - - - - -Kennedy Informational [Page 7] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 9] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 10] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - -7.2. TCPoXML DTD - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 11] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 12] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - -7.3. UDPoXML DTD - - - - - - - - - - - - - - - -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: - - - - -
- - - - - - - - - - - - - - - -
- - - - -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 header - as well as the declaration. - -3.2. Example Datagram - - The following is an example TCPoXML datagram with an empty payload: - - - - - - - - - - - - - - - - - - - - - - - - -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 header - as well as the declaration. - -4.2. Example Datagram - - The following is an example UDPoXML datagram with an empty payload: - - - - - - - - - - - - - - -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 (" - --> - - - - -Kennedy Informational [Page 7] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 9] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 10] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - -7.2. TCPoXML DTD - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 11] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 12] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - -7.3. UDPoXML DTD - - - - - - - - - - - - - - - -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: - - - - -
- - - - - - - - - - - - - - - -
- - - - -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 header - as well as the declaration. - -3.2. Example Datagram - - The following is an example TCPoXML datagram with an empty payload: - - - - - - - - - - - - - - - - - - - - - - - - -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 header - as well as the declaration. - -4.2. Example Datagram - - The following is an example UDPoXML datagram with an empty payload: - - - - - - - - - - - - - - -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 (" - --> - - - - -Kennedy Informational [Page 7] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 9] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 10] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - -7.2. TCPoXML DTD - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 11] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 12] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - -7.3. UDPoXML DTD - - - - - - - - - - - - - - - -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: - - - - -
- - - - - - - - - - - - - - - -
- - - - -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 header - as well as the declaration. - -3.2. Example Datagram - - The following is an example TCPoXML datagram with an empty payload: - - - - - - - - - - - - - - - - - - - - - - - - -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 header - as well as the declaration. - -4.2. Example Datagram - - The following is an example UDPoXML datagram with an empty payload: - - - - - - - - - - - - - - -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 (" - --> - - - - -Kennedy Informational [Page 7] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 9] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 10] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - -7.2. TCPoXML DTD - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 11] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 12] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - -7.3. UDPoXML DTD - - - - - - - - - - - - - - - -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: - - - - -
- - - - - - - - - - - - - - - -
- - - - -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 header - as well as the declaration. - -3.2. Example Datagram - - The following is an example TCPoXML datagram with an empty payload: - - - - - - - - - - - - - - - - - - - - - - - - -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 header - as well as the declaration. - -4.2. Example Datagram - - The following is an example UDPoXML datagram with an empty payload: - - - - - - - - - - - - - - -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 (" - --> - - - - -Kennedy Informational [Page 7] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 9] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 10] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - -7.2. TCPoXML DTD - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 11] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 12] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - -7.3. UDPoXML DTD - - - - - - - - - - - - - - - -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: - - - - -
- - - - - - - - - - - - - - - -
- - - - -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 header - as well as the declaration. - -3.2. Example Datagram - - The following is an example TCPoXML datagram with an empty payload: - - - - - - - - - - - - - - - - - - - - - - - - -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 header - as well as the declaration. - -4.2. Example Datagram - - The following is an example UDPoXML datagram with an empty payload: - - - - - - - - - - - - - - -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 (" - --> - - - - -Kennedy Informational [Page 7] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 9] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 10] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - -7.2. TCPoXML DTD - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 11] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 12] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - -7.3. UDPoXML DTD - - - - - - - - - - - - - - - -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: - - - - -
- - - - - - - - - - - - - - - -
- - - - -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 header - as well as the declaration. - -3.2. Example Datagram - - The following is an example TCPoXML datagram with an empty payload: - - - - - - - - - - - - - - - - - - - - - - - - -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 header - as well as the declaration. - -4.2. Example Datagram - - The following is an example UDPoXML datagram with an empty payload: - - - - - - - - - - - - - - -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 (" - --> - - - - -Kennedy Informational [Page 7] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 9] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 10] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - -7.2. TCPoXML DTD - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 11] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 12] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - -7.3. UDPoXML DTD - - - - - - - - - - - - - - - -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: - - - - -
- - - - - - - - - - - - - - - -
- - - - -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 header - as well as the declaration. - -3.2. Example Datagram - - The following is an example TCPoXML datagram with an empty payload: - - - - - - - - - - - - - - - - - - - - - - - - -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 header - as well as the declaration. - -4.2. Example Datagram - - The following is an example UDPoXML datagram with an empty payload: - - - - - - - - - - - - - - -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 (" - --> - - - - -Kennedy Informational [Page 7] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 9] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 10] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - -7.2. TCPoXML DTD - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 11] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 12] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - -7.3. UDPoXML DTD - - - - - - - - - - - - - - - -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: - - - - -
- - - - - - - - - - - - - - - -
- - - - -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 header - as well as the declaration. - -3.2. Example Datagram - - The following is an example TCPoXML datagram with an empty payload: - - - - - - - - - - - - - - - - - - - - - - - - -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 header - as well as the declaration. - -4.2. Example Datagram - - The following is an example UDPoXML datagram with an empty payload: - - - - - - - - - - - - - - -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 (" - --> - - - - -Kennedy Informational [Page 7] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 9] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 10] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - -7.2. TCPoXML DTD - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 11] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 12] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - -7.3. UDPoXML DTD - - - - - - - - - - - - - - - -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: - - - - -
- - - - - - - - - - - - - - - -
- - - - -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 header - as well as the declaration. - -3.2. Example Datagram - - The following is an example TCPoXML datagram with an empty payload: - - - - - - - - - - - - - - - - - - - - - - - - -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 header - as well as the declaration. - -4.2. Example Datagram - - The following is an example UDPoXML datagram with an empty payload: - - - - - - - - - - - - - - -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 (" - --> - - - - -Kennedy Informational [Page 7] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 9] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 10] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - -7.2. TCPoXML DTD - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 11] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 12] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - -7.3. UDPoXML DTD - - - - - - - - - - - - - - - -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: - - - - -
- - - - - - - - - - - - - - - -
- - - - -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 header - as well as the declaration. - -3.2. Example Datagram - - The following is an example TCPoXML datagram with an empty payload: - - - - - - - - - - - - - - - - - - - - - - - - -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 header - as well as the declaration. - -4.2. Example Datagram - - The following is an example UDPoXML datagram with an empty payload: - - - - - - - - - - - - - - -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 (" - --> - - - - -Kennedy Informational [Page 7] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 9] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 10] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - -7.2. TCPoXML DTD - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 11] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 12] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - -7.3. UDPoXML DTD - - - - - - - - - - - - - - - -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: - - - - -
- - - - - - - - - - - - - - - -
- - - - -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 header - as well as the declaration. - -3.2. Example Datagram - - The following is an example TCPoXML datagram with an empty payload: - - - - - - - - - - - - - - - - - - - - - - - - -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 header - as well as the declaration. - -4.2. Example Datagram - - The following is an example UDPoXML datagram with an empty payload: - - - - - - - - - - - - - - -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 (" - --> - - - - -Kennedy Informational [Page 7] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 9] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 10] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - -7.2. TCPoXML DTD - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 11] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 12] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - -7.3. UDPoXML DTD - - - - - - - - - - - - - - - -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: - - - - -
- - - - - - - - - - - - - - - -
- - - - -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 header - as well as the declaration. - -3.2. Example Datagram - - The following is an example TCPoXML datagram with an empty payload: - - - - - - - - - - - - - - - - - - - - - - - - -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 header - as well as the declaration. - -4.2. Example Datagram - - The following is an example UDPoXML datagram with an empty payload: - - - - - - - - - - - - - - -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 (" - --> - - - - -Kennedy Informational [Page 7] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 9] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 10] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - -7.2. TCPoXML DTD - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 11] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 12] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - -7.3. UDPoXML DTD - - - - - - - - - - - - - - - -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: - - - - -
- - - - - - - - - - - - - - - -
- - - - -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 header - as well as the declaration. - -3.2. Example Datagram - - The following is an example TCPoXML datagram with an empty payload: - - - - - - - - - - - - - - - - - - - - - - - - -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 header - as well as the declaration. - -4.2. Example Datagram - - The following is an example UDPoXML datagram with an empty payload: - - - - - - - - - - - - - - -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 (" - --> - - - - -Kennedy Informational [Page 7] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 9] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 10] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - -7.2. TCPoXML DTD - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 11] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 12] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - -7.3. UDPoXML DTD - - - - - - - - - - - - - - - -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: - - - - -
- - - - - - - - - - - - - - - -
- - - - -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 header - as well as the declaration. - -3.2. Example Datagram - - The following is an example TCPoXML datagram with an empty payload: - - - - - - - - - - - - - - - - - - - - - - - - -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 header - as well as the declaration. - -4.2. Example Datagram - - The following is an example UDPoXML datagram with an empty payload: - - - - - - - - - - - - - - -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 (" - --> - - - - -Kennedy Informational [Page 7] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 9] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 10] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - -7.2. TCPoXML DTD - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 11] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 12] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - -7.3. UDPoXML DTD - - - - - - - - - - - - - - - -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: - - - - -
- - - - - - - - - - - - - - - -
- - - - -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 header - as well as the declaration. - -3.2. Example Datagram - - The following is an example TCPoXML datagram with an empty payload: - - - - - - - - - - - - - - - - - - - - - - - - -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 header - as well as the declaration. - -4.2. Example Datagram - - The following is an example UDPoXML datagram with an empty payload: - - - - - - - - - - - - - - -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 (" - --> - - - - -Kennedy Informational [Page 7] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 9] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 10] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - -7.2. TCPoXML DTD - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 11] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kennedy Informational [Page 12] - -RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 - - - - - - - - - - - - - - - - - - - - -7.3. UDPoXML DTD - - - - - - - - - - - - - - - -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/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp b/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp deleted file mode 100644 index 20ae9c0..0000000 --- a/tests/auto/qtcpsocket_stresstest/tst_qtcpsocket_stresstest.cpp +++ /dev/null @@ -1,739 +0,0 @@ -/**************************************************************************** -** -** 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 -#include -#include -#include -#include -#include -#include -#include -#include - -#ifdef QT_BUILD_INTERNAL -# include -#endif - -#include "minihttpserver.h" -#include "../network-settings.h" - -#include -#ifdef Q_OS_UNIX -# include -# include -# include -# include -# include -# include -# include -# include -# include - -typedef int SOCKET; -# define INVALID_SOCKET -1 -# define SOCKET_ERROR -1 - -#elif defined(Q_OS_WIN) -# include -#endif - -class tst_QTcpSocket_stresstest : public QObject -{ - Q_OBJECT -public: - enum { AttemptCount = 100 }; - tst_QTcpSocket_stresstest(); - MiniHttpServer server; - - qint64 byteCounter; - QNetworkAccessManager manager; - bool intermediateDebug; - -private: - void clearManager(); - -public slots: - void initTestCase_data(); - void init(); - - void slotReadAll() { byteCounter += static_cast(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_QTcpSocket_stresstest::tst_QTcpSocket_stresstest() - : intermediateDebug(qgetenv("QTCPSOCKET_STRESSTEST").toInt() > 1) -{ -#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_QTcpSocket_stresstest::initTestCase_data() -{ - QTest::addColumn("isLocalhost"); - QTest::addColumn("hostname"); - QTest::addColumn("port"); - - QTest::newRow("localhost") << true << "localhost" << server.port(); -// QTest::newRow("remote") << false << QtNetworkSettings::serverName() << 80; -} - -void tst_QTcpSocket_stresstest::init() -{ - if (qgetenv("QTCPSOCKET_STRESSTEST").toInt() == 0) - QSKIP("Stress test disabled", SkipAll); - - // clear the internal cache -#ifndef QT_BUILD_INTERNAL - if (strncmp(QTest::currentTestFunction(), "nam") == 0) - QSKIP("QNetworkAccessManager tests disabled", SkipAll); -#endif -} - -void tst_QTcpSocket_stresstest::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_QTcpSocket_stresstest::nativeBlockingConnectDisconnect() -{ - QFETCH_GLOBAL(QString, hostname); - QFETCH_GLOBAL(int, port); - - double avg = 0; - 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/mediumfile 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); - - double rate = (byteCounter / timeout.elapsed()); - avg = (i * avg + rate) / (i + 1); - if (intermediateDebug) - qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" - << (rate / 1024.0 / 1024 * 1000) << "MB/s"; - } - qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; - -#if defined(Q_OS_UNIX) && !defined(Q_OS_SYMBIAN) - alarm(0); -#endif -} - -void tst_QTcpSocket_stresstest::nativeNonBlockingConnectDisconnect() -{ - QFETCH_GLOBAL(QString, hostname); - QFETCH_GLOBAL(int, port); - - double avg = 0; - 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/mediumfile 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); - - double rate = (byteCounter / timeout.elapsed()); - avg = (i * avg + rate) / (i + 1); - if (intermediateDebug) - qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" - << (rate / 1024.0 / 1024 * 1000) << "MB/s"; - } - qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; -} - -void tst_QTcpSocket_stresstest::blockingConnectDisconnect() -{ - QFETCH_GLOBAL(QString, hostname); - QFETCH_GLOBAL(int, port); - - double avg = 0; - 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/mediumfile 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 - } - double rate = (byteCounter / timeout.elapsed()); - avg = (i * avg + rate) / (i + 1); - if (intermediateDebug) - qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" - << (rate / 1024.0 / 1024 * 1000) << "MB/s"; - } - qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; -} - -void tst_QTcpSocket_stresstest::blockingPipelined() -{ - QFETCH_GLOBAL(QString, hostname); - QFETCH_GLOBAL(int, port); - - double avg = 0; - 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/mediumfile 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 - } - - double rate = (byteCounter / timeout.elapsed()); - avg = (i * avg + rate) / (i + 1); - if (intermediateDebug) - qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" - << (rate / 1024.0 / 1024 * 1000) << "MB/s"; - } - qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; -} - -void tst_QTcpSocket_stresstest::blockingMultipleRequests() -{ - QFETCH_GLOBAL(QString, hostname); - QFETCH_GLOBAL(int, port); - - double avg = 0; - 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/mediumfile 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); - - double rate = (byteCounter / timeout.elapsed()); - avg = (i * avg + rate) / (i + 1); - if (intermediateDebug) - 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" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; -} - -void tst_QTcpSocket_stresstest::connectDisconnect() -{ - QFETCH_GLOBAL(QString, hostname); - QFETCH_GLOBAL(int, port); - - double avg = 0; - for (int i = 0; i < AttemptCount; ++i) { - QElapsedTimer timeout; - byteCounter = 0; - timeout.start(); - - QTcpSocket socket; - socket.connectToHost(hostname, port); - - socket.write("GET /qtest/mediumfile 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"); - double rate = (byteCounter / timeout.elapsed()); - avg = (i * avg + rate) / (i + 1); - if (intermediateDebug) - qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" - << (rate / 1024.0 / 1024 * 1000) << "MB/s"; - } - qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; -} - -void tst_QTcpSocket_stresstest::parallelConnectDisconnect_data() -{ - QTest::addColumn("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_QTcpSocket_stresstest::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); - } - - double avg = 0; - 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/mediumfile 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"); - double rate = (byteCounter / timeout.elapsed()); - avg = (i * avg + rate) / (i + 1); - if (intermediateDebug) - qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" - << (rate / 1024.0 / 1024 * 1000) << "MB/s"; - } - qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; -} - -void tst_QTcpSocket_stresstest::namGet_data() -{ - QTest::addColumn("parallelAttempts"); - QTest::addColumn("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_QTcpSocket_stresstest::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); - } - - double avg = 0; - 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/mediumfile"); - QNetworkRequest req(url); - req.setAttribute(QNetworkRequest::HttpPipeliningAllowedAttribute, pipelineAllowed); - - QVector > 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(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"); - double rate = (byteCounter / timeout.elapsed()); - avg = (i * avg + rate) / (i + 1); - if (intermediateDebug) - qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" - << (rate / 1024.0 / 1024 * 1000) << "MB/s"; - } - qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; -} - -QTEST_MAIN(tst_QTcpSocket_stresstest); - -#include "tst_qtcpsocket_stresstest.moc" diff --git a/tests/auto/qtcpsocket_stresstest/wwwfiles.qrc b/tests/auto/qtcpsocket_stresstest/wwwfiles.qrc deleted file mode 100644 index b1d4be6..0000000 --- a/tests/auto/qtcpsocket_stresstest/wwwfiles.qrc +++ /dev/null @@ -1,5 +0,0 @@ - - - qtest - - 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 +#include +#include +#include +#include + +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(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 +#include +#include + +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/qtcpsocket_stresstest.pro b/tests/manual/network_stresstest/qtcpsocket_stresstest.pro new file mode 100644 index 0000000..47b2682 --- /dev/null +++ b/tests/manual/network_stresstest/qtcpsocket_stresstest.pro @@ -0,0 +1,12 @@ +load(qttest_p4) + +QT = core network + +SOURCES += tst_qtcpsocket_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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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: + + + + +
+ + + + + + + + + + + + + + + +
+ + + + +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 header + as well as the declaration. + +3.2. Example Datagram + + The following is an example TCPoXML datagram with an empty payload: + + + + + + + + + + + + + + + + + + + + + + + + +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 header + as well as the declaration. + +4.2. Example Datagram + + The following is an example UDPoXML datagram with an empty payload: + + + + + + + + + + + + + + +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 (" + --> + + + + +Kennedy Informational [Page 7] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 9] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 10] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + +7.2. TCPoXML DTD + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 11] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kennedy Informational [Page 12] + +RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 + + + + + + + + + + + + + + + + + + + + +7.3. UDPoXML DTD + + + + + + + + + + + + + + + +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_qtcpsocket_stresstest.cpp b/tests/manual/network_stresstest/tst_qtcpsocket_stresstest.cpp new file mode 100644 index 0000000..20ae9c0 --- /dev/null +++ b/tests/manual/network_stresstest/tst_qtcpsocket_stresstest.cpp @@ -0,0 +1,739 @@ +/**************************************************************************** +** +** 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 +#include +#include +#include +#include +#include +#include +#include +#include + +#ifdef QT_BUILD_INTERNAL +# include +#endif + +#include "minihttpserver.h" +#include "../network-settings.h" + +#include +#ifdef Q_OS_UNIX +# include +# include +# include +# include +# include +# include +# include +# include +# include + +typedef int SOCKET; +# define INVALID_SOCKET -1 +# define SOCKET_ERROR -1 + +#elif defined(Q_OS_WIN) +# include +#endif + +class tst_QTcpSocket_stresstest : public QObject +{ + Q_OBJECT +public: + enum { AttemptCount = 100 }; + tst_QTcpSocket_stresstest(); + MiniHttpServer server; + + qint64 byteCounter; + QNetworkAccessManager manager; + bool intermediateDebug; + +private: + void clearManager(); + +public slots: + void initTestCase_data(); + void init(); + + void slotReadAll() { byteCounter += static_cast(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_QTcpSocket_stresstest::tst_QTcpSocket_stresstest() + : intermediateDebug(qgetenv("QTCPSOCKET_STRESSTEST").toInt() > 1) +{ +#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_QTcpSocket_stresstest::initTestCase_data() +{ + QTest::addColumn("isLocalhost"); + QTest::addColumn("hostname"); + QTest::addColumn("port"); + + QTest::newRow("localhost") << true << "localhost" << server.port(); +// QTest::newRow("remote") << false << QtNetworkSettings::serverName() << 80; +} + +void tst_QTcpSocket_stresstest::init() +{ + if (qgetenv("QTCPSOCKET_STRESSTEST").toInt() == 0) + QSKIP("Stress test disabled", SkipAll); + + // clear the internal cache +#ifndef QT_BUILD_INTERNAL + if (strncmp(QTest::currentTestFunction(), "nam") == 0) + QSKIP("QNetworkAccessManager tests disabled", SkipAll); +#endif +} + +void tst_QTcpSocket_stresstest::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_QTcpSocket_stresstest::nativeBlockingConnectDisconnect() +{ + QFETCH_GLOBAL(QString, hostname); + QFETCH_GLOBAL(int, port); + + double avg = 0; + 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/mediumfile 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); + + double rate = (byteCounter / timeout.elapsed()); + avg = (i * avg + rate) / (i + 1); + if (intermediateDebug) + qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" + << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + } + qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; + +#if defined(Q_OS_UNIX) && !defined(Q_OS_SYMBIAN) + alarm(0); +#endif +} + +void tst_QTcpSocket_stresstest::nativeNonBlockingConnectDisconnect() +{ + QFETCH_GLOBAL(QString, hostname); + QFETCH_GLOBAL(int, port); + + double avg = 0; + 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/mediumfile 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); + + double rate = (byteCounter / timeout.elapsed()); + avg = (i * avg + rate) / (i + 1); + if (intermediateDebug) + qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" + << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + } + qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; +} + +void tst_QTcpSocket_stresstest::blockingConnectDisconnect() +{ + QFETCH_GLOBAL(QString, hostname); + QFETCH_GLOBAL(int, port); + + double avg = 0; + 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/mediumfile 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 + } + double rate = (byteCounter / timeout.elapsed()); + avg = (i * avg + rate) / (i + 1); + if (intermediateDebug) + qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" + << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + } + qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; +} + +void tst_QTcpSocket_stresstest::blockingPipelined() +{ + QFETCH_GLOBAL(QString, hostname); + QFETCH_GLOBAL(int, port); + + double avg = 0; + 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/mediumfile 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 + } + + double rate = (byteCounter / timeout.elapsed()); + avg = (i * avg + rate) / (i + 1); + if (intermediateDebug) + qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" + << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + } + qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; +} + +void tst_QTcpSocket_stresstest::blockingMultipleRequests() +{ + QFETCH_GLOBAL(QString, hostname); + QFETCH_GLOBAL(int, port); + + double avg = 0; + 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/mediumfile 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); + + double rate = (byteCounter / timeout.elapsed()); + avg = (i * avg + rate) / (i + 1); + if (intermediateDebug) + 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" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; +} + +void tst_QTcpSocket_stresstest::connectDisconnect() +{ + QFETCH_GLOBAL(QString, hostname); + QFETCH_GLOBAL(int, port); + + double avg = 0; + for (int i = 0; i < AttemptCount; ++i) { + QElapsedTimer timeout; + byteCounter = 0; + timeout.start(); + + QTcpSocket socket; + socket.connectToHost(hostname, port); + + socket.write("GET /qtest/mediumfile 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"); + double rate = (byteCounter / timeout.elapsed()); + avg = (i * avg + rate) / (i + 1); + if (intermediateDebug) + qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" + << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + } + qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; +} + +void tst_QTcpSocket_stresstest::parallelConnectDisconnect_data() +{ + QTest::addColumn("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_QTcpSocket_stresstest::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); + } + + double avg = 0; + 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/mediumfile 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"); + double rate = (byteCounter / timeout.elapsed()); + avg = (i * avg + rate) / (i + 1); + if (intermediateDebug) + qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" + << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + } + qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; +} + +void tst_QTcpSocket_stresstest::namGet_data() +{ + QTest::addColumn("parallelAttempts"); + QTest::addColumn("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_QTcpSocket_stresstest::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); + } + + double avg = 0; + 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/mediumfile"); + QNetworkRequest req(url); + req.setAttribute(QNetworkRequest::HttpPipeliningAllowedAttribute, pipelineAllowed); + + QVector > 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(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"); + double rate = (byteCounter / timeout.elapsed()); + avg = (i * avg + rate) / (i + 1); + if (intermediateDebug) + qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" + << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + } + qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; +} + +QTEST_MAIN(tst_QTcpSocket_stresstest); + +#include "tst_qtcpsocket_stresstest.moc" diff --git a/tests/manual/network_stresstest/wwwfiles.qrc b/tests/manual/network_stresstest/wwwfiles.qrc new file mode 100644 index 0000000..b1d4be6 --- /dev/null +++ b/tests/manual/network_stresstest/wwwfiles.qrc @@ -0,0 +1,5 @@ + + + qtest + + -- cgit v0.12 From 36de36e5695744e3c5d7dc839011b7b593737be5 Mon Sep 17 00:00:00 2001 From: Thiago Macieira Date: Fri, 16 Apr 2010 10:34:35 +0200 Subject: Finish renaming --- .../network_stresstest/network_stresstest.pro | 12 + .../network_stresstest/qtcpsocket_stresstest.pro | 12 - .../network_stresstest/tst_network_stresstest.cpp | 736 ++++++++++++++++++++ .../tst_qtcpsocket_stresstest.cpp | 739 --------------------- 4 files changed, 748 insertions(+), 751 deletions(-) create mode 100644 tests/manual/network_stresstest/network_stresstest.pro delete mode 100644 tests/manual/network_stresstest/qtcpsocket_stresstest.pro create mode 100644 tests/manual/network_stresstest/tst_network_stresstest.cpp delete mode 100644 tests/manual/network_stresstest/tst_qtcpsocket_stresstest.cpp 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/qtcpsocket_stresstest.pro b/tests/manual/network_stresstest/qtcpsocket_stresstest.pro deleted file mode 100644 index 47b2682..0000000 --- a/tests/manual/network_stresstest/qtcpsocket_stresstest.pro +++ /dev/null @@ -1,12 +0,0 @@ -load(qttest_p4) - -QT = core network - -SOURCES += tst_qtcpsocket_stresstest.cpp \ - minihttpserver.cpp - -HEADERS += \ - minihttpserver.h - -RESOURCES += wwwfiles.qrc -QMAKE_RESOURCE_FLAGS += -no-compress 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..7c94972 --- /dev/null +++ b/tests/manual/network_stresstest/tst_network_stresstest.cpp @@ -0,0 +1,736 @@ +/**************************************************************************** +** +** 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 +#include +#include +#include +#include +#include +#include +#include +#include + +#ifdef QT_BUILD_INTERNAL +# include +#endif + +#include "minihttpserver.h" +#include "../../auto/network-settings.h" + +#include +#ifdef Q_OS_UNIX +# include +# include +# include +# include +# include +# include +# include +# include +# include + +typedef int SOCKET; +# define INVALID_SOCKET -1 +# define SOCKET_ERROR -1 + +#elif defined(Q_OS_WIN) +# include +#endif + +class tst_QTcpSocket_stresstest : public QObject +{ + Q_OBJECT +public: + enum { AttemptCount = 100 }; + tst_QTcpSocket_stresstest(); + MiniHttpServer server; + + qint64 byteCounter; + QNetworkAccessManager manager; + bool intermediateDebug; + +private: + void clearManager(); + +public slots: + void initTestCase_data(); + void init(); + + void slotReadAll() { byteCounter += static_cast(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_QTcpSocket_stresstest::tst_QTcpSocket_stresstest() + : 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_QTcpSocket_stresstest::initTestCase_data() +{ + QTest::addColumn("isLocalhost"); + QTest::addColumn("hostname"); + QTest::addColumn("port"); + + QTest::newRow("localhost") << true << "localhost" << server.port(); +// QTest::newRow("remote") << false << QtNetworkSettings::serverName() << 80; +} + +void tst_QTcpSocket_stresstest::init() +{ + // clear the internal cache +#ifndef QT_BUILD_INTERNAL + if (strncmp(QTest::currentTestFunction(), "nam") == 0) + QSKIP("QNetworkAccessManager tests disabled", SkipAll); +#endif +} + +void tst_QTcpSocket_stresstest::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_QTcpSocket_stresstest::nativeBlockingConnectDisconnect() +{ + QFETCH_GLOBAL(QString, hostname); + QFETCH_GLOBAL(int, port); + + double avg = 0; + 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/mediumfile 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); + + double rate = (byteCounter / timeout.elapsed()); + avg = (i * avg + rate) / (i + 1); + if (intermediateDebug) + qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" + << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + } + qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; + +#if defined(Q_OS_UNIX) && !defined(Q_OS_SYMBIAN) + alarm(0); +#endif +} + +void tst_QTcpSocket_stresstest::nativeNonBlockingConnectDisconnect() +{ + QFETCH_GLOBAL(QString, hostname); + QFETCH_GLOBAL(int, port); + + double avg = 0; + 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/mediumfile 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); + + double rate = (byteCounter / timeout.elapsed()); + avg = (i * avg + rate) / (i + 1); + if (intermediateDebug) + qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" + << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + } + qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; +} + +void tst_QTcpSocket_stresstest::blockingConnectDisconnect() +{ + QFETCH_GLOBAL(QString, hostname); + QFETCH_GLOBAL(int, port); + + double avg = 0; + 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/mediumfile 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 + } + double rate = (byteCounter / timeout.elapsed()); + avg = (i * avg + rate) / (i + 1); + if (intermediateDebug) + qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" + << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + } + qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; +} + +void tst_QTcpSocket_stresstest::blockingPipelined() +{ + QFETCH_GLOBAL(QString, hostname); + QFETCH_GLOBAL(int, port); + + double avg = 0; + 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/mediumfile 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 + } + + double rate = (byteCounter / timeout.elapsed()); + avg = (i * avg + rate) / (i + 1); + if (intermediateDebug) + qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" + << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + } + qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; +} + +void tst_QTcpSocket_stresstest::blockingMultipleRequests() +{ + QFETCH_GLOBAL(QString, hostname); + QFETCH_GLOBAL(int, port); + + double avg = 0; + 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/mediumfile 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); + + double rate = (byteCounter / timeout.elapsed()); + avg = (i * avg + rate) / (i + 1); + if (intermediateDebug) + 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" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; +} + +void tst_QTcpSocket_stresstest::connectDisconnect() +{ + QFETCH_GLOBAL(QString, hostname); + QFETCH_GLOBAL(int, port); + + double avg = 0; + for (int i = 0; i < AttemptCount; ++i) { + QElapsedTimer timeout; + byteCounter = 0; + timeout.start(); + + QTcpSocket socket; + socket.connectToHost(hostname, port); + + socket.write("GET /qtest/mediumfile 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"); + double rate = (byteCounter / timeout.elapsed()); + avg = (i * avg + rate) / (i + 1); + if (intermediateDebug) + qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" + << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + } + qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; +} + +void tst_QTcpSocket_stresstest::parallelConnectDisconnect_data() +{ + QTest::addColumn("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_QTcpSocket_stresstest::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); + } + + double avg = 0; + 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/mediumfile 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"); + double rate = (byteCounter / timeout.elapsed()); + avg = (i * avg + rate) / (i + 1); + if (intermediateDebug) + qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" + << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + } + qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; +} + +void tst_QTcpSocket_stresstest::namGet_data() +{ + QTest::addColumn("parallelAttempts"); + QTest::addColumn("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_QTcpSocket_stresstest::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); + } + + double avg = 0; + 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/mediumfile"); + QNetworkRequest req(url); + req.setAttribute(QNetworkRequest::HttpPipeliningAllowedAttribute, pipelineAllowed); + + QVector > 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(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"); + double rate = (byteCounter / timeout.elapsed()); + avg = (i * avg + rate) / (i + 1); + if (intermediateDebug) + qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" + << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + } + qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; +} + +QTEST_MAIN(tst_QTcpSocket_stresstest); + +#include "tst_network_stresstest.moc" diff --git a/tests/manual/network_stresstest/tst_qtcpsocket_stresstest.cpp b/tests/manual/network_stresstest/tst_qtcpsocket_stresstest.cpp deleted file mode 100644 index 20ae9c0..0000000 --- a/tests/manual/network_stresstest/tst_qtcpsocket_stresstest.cpp +++ /dev/null @@ -1,739 +0,0 @@ -/**************************************************************************** -** -** 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 -#include -#include -#include -#include -#include -#include -#include -#include - -#ifdef QT_BUILD_INTERNAL -# include -#endif - -#include "minihttpserver.h" -#include "../network-settings.h" - -#include -#ifdef Q_OS_UNIX -# include -# include -# include -# include -# include -# include -# include -# include -# include - -typedef int SOCKET; -# define INVALID_SOCKET -1 -# define SOCKET_ERROR -1 - -#elif defined(Q_OS_WIN) -# include -#endif - -class tst_QTcpSocket_stresstest : public QObject -{ - Q_OBJECT -public: - enum { AttemptCount = 100 }; - tst_QTcpSocket_stresstest(); - MiniHttpServer server; - - qint64 byteCounter; - QNetworkAccessManager manager; - bool intermediateDebug; - -private: - void clearManager(); - -public slots: - void initTestCase_data(); - void init(); - - void slotReadAll() { byteCounter += static_cast(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_QTcpSocket_stresstest::tst_QTcpSocket_stresstest() - : intermediateDebug(qgetenv("QTCPSOCKET_STRESSTEST").toInt() > 1) -{ -#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_QTcpSocket_stresstest::initTestCase_data() -{ - QTest::addColumn("isLocalhost"); - QTest::addColumn("hostname"); - QTest::addColumn("port"); - - QTest::newRow("localhost") << true << "localhost" << server.port(); -// QTest::newRow("remote") << false << QtNetworkSettings::serverName() << 80; -} - -void tst_QTcpSocket_stresstest::init() -{ - if (qgetenv("QTCPSOCKET_STRESSTEST").toInt() == 0) - QSKIP("Stress test disabled", SkipAll); - - // clear the internal cache -#ifndef QT_BUILD_INTERNAL - if (strncmp(QTest::currentTestFunction(), "nam") == 0) - QSKIP("QNetworkAccessManager tests disabled", SkipAll); -#endif -} - -void tst_QTcpSocket_stresstest::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_QTcpSocket_stresstest::nativeBlockingConnectDisconnect() -{ - QFETCH_GLOBAL(QString, hostname); - QFETCH_GLOBAL(int, port); - - double avg = 0; - 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/mediumfile 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); - - double rate = (byteCounter / timeout.elapsed()); - avg = (i * avg + rate) / (i + 1); - if (intermediateDebug) - qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" - << (rate / 1024.0 / 1024 * 1000) << "MB/s"; - } - qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; - -#if defined(Q_OS_UNIX) && !defined(Q_OS_SYMBIAN) - alarm(0); -#endif -} - -void tst_QTcpSocket_stresstest::nativeNonBlockingConnectDisconnect() -{ - QFETCH_GLOBAL(QString, hostname); - QFETCH_GLOBAL(int, port); - - double avg = 0; - 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/mediumfile 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); - - double rate = (byteCounter / timeout.elapsed()); - avg = (i * avg + rate) / (i + 1); - if (intermediateDebug) - qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" - << (rate / 1024.0 / 1024 * 1000) << "MB/s"; - } - qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; -} - -void tst_QTcpSocket_stresstest::blockingConnectDisconnect() -{ - QFETCH_GLOBAL(QString, hostname); - QFETCH_GLOBAL(int, port); - - double avg = 0; - 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/mediumfile 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 - } - double rate = (byteCounter / timeout.elapsed()); - avg = (i * avg + rate) / (i + 1); - if (intermediateDebug) - qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" - << (rate / 1024.0 / 1024 * 1000) << "MB/s"; - } - qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; -} - -void tst_QTcpSocket_stresstest::blockingPipelined() -{ - QFETCH_GLOBAL(QString, hostname); - QFETCH_GLOBAL(int, port); - - double avg = 0; - 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/mediumfile 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 - } - - double rate = (byteCounter / timeout.elapsed()); - avg = (i * avg + rate) / (i + 1); - if (intermediateDebug) - qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" - << (rate / 1024.0 / 1024 * 1000) << "MB/s"; - } - qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; -} - -void tst_QTcpSocket_stresstest::blockingMultipleRequests() -{ - QFETCH_GLOBAL(QString, hostname); - QFETCH_GLOBAL(int, port); - - double avg = 0; - 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/mediumfile 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); - - double rate = (byteCounter / timeout.elapsed()); - avg = (i * avg + rate) / (i + 1); - if (intermediateDebug) - 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" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; -} - -void tst_QTcpSocket_stresstest::connectDisconnect() -{ - QFETCH_GLOBAL(QString, hostname); - QFETCH_GLOBAL(int, port); - - double avg = 0; - for (int i = 0; i < AttemptCount; ++i) { - QElapsedTimer timeout; - byteCounter = 0; - timeout.start(); - - QTcpSocket socket; - socket.connectToHost(hostname, port); - - socket.write("GET /qtest/mediumfile 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"); - double rate = (byteCounter / timeout.elapsed()); - avg = (i * avg + rate) / (i + 1); - if (intermediateDebug) - qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" - << (rate / 1024.0 / 1024 * 1000) << "MB/s"; - } - qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; -} - -void tst_QTcpSocket_stresstest::parallelConnectDisconnect_data() -{ - QTest::addColumn("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_QTcpSocket_stresstest::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); - } - - double avg = 0; - 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/mediumfile 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"); - double rate = (byteCounter / timeout.elapsed()); - avg = (i * avg + rate) / (i + 1); - if (intermediateDebug) - qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" - << (rate / 1024.0 / 1024 * 1000) << "MB/s"; - } - qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; -} - -void tst_QTcpSocket_stresstest::namGet_data() -{ - QTest::addColumn("parallelAttempts"); - QTest::addColumn("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_QTcpSocket_stresstest::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); - } - - double avg = 0; - 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/mediumfile"); - QNetworkRequest req(url); - req.setAttribute(QNetworkRequest::HttpPipeliningAllowedAttribute, pipelineAllowed); - - QVector > 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(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"); - double rate = (byteCounter / timeout.elapsed()); - avg = (i * avg + rate) / (i + 1); - if (intermediateDebug) - qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" - << (rate / 1024.0 / 1024 * 1000) << "MB/s"; - } - qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; -} - -QTEST_MAIN(tst_QTcpSocket_stresstest); - -#include "tst_qtcpsocket_stresstest.moc" -- cgit v0.12 From e2ef78accc7d3c0ccbc222b68bf14c0fd38254e1 Mon Sep 17 00:00:00 2001 From: Thiago Macieira Date: Fri, 16 Apr 2010 10:51:13 +0200 Subject: Change the way we calculate the average transfer rates. The previous way was prone to division by zero if the file was too small --- .../network_stresstest/tst_network_stresstest.cpp | 133 +++++++++++++-------- 1 file changed, 84 insertions(+), 49 deletions(-) diff --git a/tests/manual/network_stresstest/tst_network_stresstest.cpp b/tests/manual/network_stresstest/tst_network_stresstest.cpp index 7c94972..9979914 100644 --- a/tests/manual/network_stresstest/tst_network_stresstest.cpp +++ b/tests/manual/network_stresstest/tst_network_stresstest.cpp @@ -130,7 +130,7 @@ void tst_QTcpSocket_stresstest::initTestCase_data() QTest::addColumn("port"); QTest::newRow("localhost") << true << "localhost" << server.port(); -// QTest::newRow("remote") << false << QtNetworkSettings::serverName() << 80; + QTest::newRow("remote") << false << QtNetworkSettings::serverName() << 80; } void tst_QTcpSocket_stresstest::init() @@ -215,7 +215,10 @@ void tst_QTcpSocket_stresstest::nativeBlockingConnectDisconnect() QFETCH_GLOBAL(QString, hostname); QFETCH_GLOBAL(int, port); - double avg = 0; + qint64 totalBytes = 0; + QElapsedTimer outerTimer; + outerTimer.start(); + for (int i = 0; i < AttemptCount; ++i) { QElapsedTimer timeout; byteCounter = 0; @@ -237,7 +240,7 @@ void tst_QTcpSocket_stresstest::nativeBlockingConnectDisconnect() // send request { - QByteArray request = "GET /qtest/mediumfile HTTP/1.1\r\n" + 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" @@ -267,13 +270,14 @@ void tst_QTcpSocket_stresstest::nativeBlockingConnectDisconnect() } ::close(fd); - double rate = (byteCounter / timeout.elapsed()); - avg = (i * avg + rate) / (i + 1); - if (intermediateDebug) + totalBytes += byteCounter; + if (intermediateDebug) { + double rate = (byteCounter / timeout.elapsed()); qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + } } - qDebug() << "Average transfer rate was" << (avg / 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); @@ -285,7 +289,10 @@ void tst_QTcpSocket_stresstest::nativeNonBlockingConnectDisconnect() QFETCH_GLOBAL(QString, hostname); QFETCH_GLOBAL(int, port); - double avg = 0; + qint64 totalBytes = 0; + QElapsedTimer outerTimer; + outerTimer.start(); + for (int i = 0; i < AttemptCount; ++i) { QElapsedTimer timeout; byteCounter = 0; @@ -344,7 +351,7 @@ void tst_QTcpSocket_stresstest::nativeNonBlockingConnectDisconnect() // send request { - QByteArray request = "GET /qtest/mediumfile HTTP/1.1\r\n" + 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" @@ -381,13 +388,14 @@ void tst_QTcpSocket_stresstest::nativeNonBlockingConnectDisconnect() } ::close(fd); - double rate = (byteCounter / timeout.elapsed()); - avg = (i * avg + rate) / (i + 1); - if (intermediateDebug) + totalBytes += byteCounter; + if (intermediateDebug) { + double rate = (byteCounter / timeout.elapsed()); qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + } } - qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; + qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s"; } void tst_QTcpSocket_stresstest::blockingConnectDisconnect() @@ -395,7 +403,10 @@ void tst_QTcpSocket_stresstest::blockingConnectDisconnect() QFETCH_GLOBAL(QString, hostname); QFETCH_GLOBAL(int, port); - double avg = 0; + qint64 totalBytes = 0; + QElapsedTimer outerTimer; + outerTimer.start(); + for (int i = 0; i < AttemptCount; ++i) { QElapsedTimer timeout; byteCounter = 0; @@ -405,7 +416,7 @@ void tst_QTcpSocket_stresstest::blockingConnectDisconnect() socket.connectToHost(hostname, port); QVERIFY2(socket.waitForConnected(), "Timeout"); - socket.write("GET /qtest/mediumfile HTTP/1.1\r\n" + 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" @@ -417,13 +428,15 @@ void tst_QTcpSocket_stresstest::blockingConnectDisconnect() socket.waitForReadyRead(); byteCounter += socket.readAll().size(); // discard } - double rate = (byteCounter / timeout.elapsed()); - avg = (i * avg + rate) / (i + 1); - if (intermediateDebug) + + totalBytes += byteCounter; + if (intermediateDebug) { + double rate = (byteCounter / timeout.elapsed()); qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + } } - qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; + qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s"; } void tst_QTcpSocket_stresstest::blockingPipelined() @@ -431,7 +444,10 @@ void tst_QTcpSocket_stresstest::blockingPipelined() QFETCH_GLOBAL(QString, hostname); QFETCH_GLOBAL(int, port); - double avg = 0; + qint64 totalBytes = 0; + QElapsedTimer outerTimer; + outerTimer.start(); + for (int i = 0; i < AttemptCount / 2; ++i) { QElapsedTimer timeout; byteCounter = 0; @@ -444,7 +460,7 @@ void tst_QTcpSocket_stresstest::blockingPipelined() for (int j = 0 ; j < 3; ++j) { if (intermediateDebug) qDebug("Attempt %d%c", i, 'a' + j); - socket.write("GET /qtest/mediumfile HTTP/1.1\r\n" + 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" @@ -458,13 +474,14 @@ void tst_QTcpSocket_stresstest::blockingPipelined() byteCounter += socket.readAll().size(); // discard } - double rate = (byteCounter / timeout.elapsed()); - avg = (i * avg + rate) / (i + 1); - if (intermediateDebug) + totalBytes += byteCounter; + if (intermediateDebug) { + double rate = (byteCounter / timeout.elapsed()); qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + } } - qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; + qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s"; } void tst_QTcpSocket_stresstest::blockingMultipleRequests() @@ -472,7 +489,10 @@ void tst_QTcpSocket_stresstest::blockingMultipleRequests() QFETCH_GLOBAL(QString, hostname); QFETCH_GLOBAL(int, port); - double avg = 0; + qint64 totalBytes = 0; + QElapsedTimer outerTimer; + outerTimer.start(); + for (int i = 0; i < AttemptCount / 5; ++i) { QTcpSocket socket; socket.connectToHost(hostname, port); @@ -483,7 +503,7 @@ void tst_QTcpSocket_stresstest::blockingMultipleRequests() byteCounter = 0; timeout.start(); - socket.write("GET /qtest/mediumfile HTTP/1.1\r\n" + 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" @@ -534,17 +554,18 @@ void tst_QTcpSocket_stresstest::blockingMultipleRequests() QVERIFY2(!timeout.hasExpired(10000), "Timeout"); QCOMPARE(bytesRead, bytesExpected); - double rate = (byteCounter / timeout.elapsed()); - avg = (i * avg + rate) / (i + 1); - if (intermediateDebug) + totalBytes += byteCounter; + if (intermediateDebug) { + double rate = (byteCounter / 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" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; + qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s"; } void tst_QTcpSocket_stresstest::connectDisconnect() @@ -552,7 +573,10 @@ void tst_QTcpSocket_stresstest::connectDisconnect() QFETCH_GLOBAL(QString, hostname); QFETCH_GLOBAL(int, port); - double avg = 0; + qint64 totalBytes = 0; + QElapsedTimer outerTimer; + outerTimer.start(); + for (int i = 0; i < AttemptCount; ++i) { QElapsedTimer timeout; byteCounter = 0; @@ -561,7 +585,7 @@ void tst_QTcpSocket_stresstest::connectDisconnect() QTcpSocket socket; socket.connectToHost(hostname, port); - socket.write("GET /qtest/mediumfile HTTP/1.1\r\n" + 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" @@ -571,13 +595,15 @@ void tst_QTcpSocket_stresstest::connectDisconnect() QTestEventLoop::instance().connect(&socket, SIGNAL(disconnected()), SLOT(exitLoop())); QTestEventLoop::instance().enterLoop(30); QVERIFY2(!QTestEventLoop::instance().timeout(), "Timeout"); - double rate = (byteCounter / timeout.elapsed()); - avg = (i * avg + rate) / (i + 1); - if (intermediateDebug) + + totalBytes += byteCounter; + if (intermediateDebug) { + double rate = (byteCounter / timeout.elapsed()); qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + } } - qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; + qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s"; } void tst_QTcpSocket_stresstest::parallelConnectDisconnect_data() @@ -607,7 +633,10 @@ void tst_QTcpSocket_stresstest::parallelConnectDisconnect() QSKIP("Localhost-only test", SkipSingle); } - double avg = 0; + qint64 totalBytes = 0; + QElapsedTimer outerTimer; + outerTimer.start(); + for (int i = 0; i < qMax(2, AttemptCount/qMax(2, parallelAttempts/4)); ++i) { QElapsedTimer timeout; byteCounter = 0; @@ -617,7 +646,7 @@ void tst_QTcpSocket_stresstest::parallelConnectDisconnect() for (int j = 0; j < parallelAttempts; ++j) { socket[j].connectToHost(hostname, port); - socket[j].write("GET /qtest/mediumfile HTTP/1.1\r\n" + 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" @@ -637,13 +666,15 @@ void tst_QTcpSocket_stresstest::parallelConnectDisconnect() } delete[] socket; QVERIFY2(!timeout.hasExpired(30000), "Timeout"); - double rate = (byteCounter / timeout.elapsed()); - avg = (i * avg + rate) / (i + 1); - if (intermediateDebug) + + totalBytes += byteCounter; + if (intermediateDebug) { + double rate = (byteCounter / timeout.elapsed()); qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + } } - qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; + qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s"; } void tst_QTcpSocket_stresstest::namGet_data() @@ -686,7 +717,10 @@ void tst_QTcpSocket_stresstest::namGet() QSKIP("Localhost-only test", SkipSingle); } - double avg = 0; + qint64 totalBytes = 0; + QElapsedTimer outerTimer; + outerTimer.start(); + for (int i = 0; i < qMax(2, AttemptCount/qMax(2, parallelAttempts/4)); ++i) { QElapsedTimer timeout; byteCounter = 0; @@ -696,7 +730,7 @@ void tst_QTcpSocket_stresstest::namGet() url.setScheme("http"); url.setHost(hostname); url.setPort(port); - url.setEncodedPath("/qtest/mediumfile"); + url.setEncodedPath("/qtest/bigfile"); QNetworkRequest req(url); req.setAttribute(QNetworkRequest::HttpPipeliningAllowedAttribute, pipelineAllowed); @@ -722,13 +756,14 @@ void tst_QTcpSocket_stresstest::namGet() replies.clear(); QVERIFY2(!timeout.hasExpired(30000), "Timeout"); - double rate = (byteCounter / timeout.elapsed()); - avg = (i * avg + rate) / (i + 1); - if (intermediateDebug) + totalBytes += byteCounter; + if (intermediateDebug) { + double rate = (byteCounter / timeout.elapsed()); qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" << (rate / 1024.0 / 1024 * 1000) << "MB/s"; + } } - qDebug() << "Average transfer rate was" << (avg / 1024.0 / 1024 * 1000) << "MB/s"; + qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s"; } QTEST_MAIN(tst_QTcpSocket_stresstest); -- cgit v0.12 From ef48cfd6cc1b2989b33ae3709634a732a1c81668 Mon Sep 17 00:00:00 2001 From: Thiago Macieira Date: Fri, 16 Apr 2010 11:22:09 +0200 Subject: Add tests for remote hosts --- .../network_stresstest/tst_network_stresstest.cpp | 264 ++++++++++++++++++++- tests/manual/network_stresstest/url-list.txt | 64 +++++ tests/manual/network_stresstest/wwwfiles.qrc | 3 +- 3 files changed, 322 insertions(+), 9 deletions(-) create mode 100644 tests/manual/network_stresstest/url-list.txt diff --git a/tests/manual/network_stresstest/tst_network_stresstest.cpp b/tests/manual/network_stresstest/tst_network_stresstest.cpp index 9979914..d3b007a 100644 --- a/tests/manual/network_stresstest/tst_network_stresstest.cpp +++ b/tests/manual/network_stresstest/tst_network_stresstest.cpp @@ -86,6 +86,7 @@ public: qint64 byteCounter; QNetworkAccessManager manager; + QVector httpUrls; bool intermediateDebug; private: @@ -108,6 +109,13 @@ private Q_SLOTS: void parallelConnectDisconnect(); void namGet_data(); void namGet(); + + void blockingSequentialRemoteHosts(); + void sequentialRemoteHosts(); + void parallelRemoteHosts_data(); + void parallelRemoteHosts(); + void namRemoteGet_data(); + void namRemoteGet(); }; tst_QTcpSocket_stresstest::tst_QTcpSocket_stresstest() @@ -121,6 +129,18 @@ tst_QTcpSocket_stresstest::tst_QTcpSocket_stresstest() #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; + } + } + + httpUrls << httpUrls; } void tst_QTcpSocket_stresstest::initTestCase_data() @@ -272,7 +292,7 @@ void tst_QTcpSocket_stresstest::nativeBlockingConnectDisconnect() totalBytes += byteCounter; if (intermediateDebug) { - double rate = (byteCounter / timeout.elapsed()); + double rate = (byteCounter * 1.0 / timeout.elapsed()); qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" << (rate / 1024.0 / 1024 * 1000) << "MB/s"; } @@ -390,7 +410,7 @@ void tst_QTcpSocket_stresstest::nativeNonBlockingConnectDisconnect() totalBytes += byteCounter; if (intermediateDebug) { - double rate = (byteCounter / timeout.elapsed()); + double rate = (byteCounter * 1.0 / timeout.elapsed()); qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" << (rate / 1024.0 / 1024 * 1000) << "MB/s"; } @@ -431,7 +451,7 @@ void tst_QTcpSocket_stresstest::blockingConnectDisconnect() totalBytes += byteCounter; if (intermediateDebug) { - double rate = (byteCounter / timeout.elapsed()); + double rate = (byteCounter * 1.0 / timeout.elapsed()); qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" << (rate / 1024.0 / 1024 * 1000) << "MB/s"; } @@ -476,7 +496,7 @@ void tst_QTcpSocket_stresstest::blockingPipelined() totalBytes += byteCounter; if (intermediateDebug) { - double rate = (byteCounter / timeout.elapsed()); + double rate = (byteCounter * 1.0 / timeout.elapsed()); qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" << (rate / 1024.0 / 1024 * 1000) << "MB/s"; } @@ -556,7 +576,7 @@ void tst_QTcpSocket_stresstest::blockingMultipleRequests() totalBytes += byteCounter; if (intermediateDebug) { - double rate = (byteCounter / timeout.elapsed()); + double rate = (byteCounter * 1.0 / timeout.elapsed()); qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" << (rate / 1024.0 / 1024 * 1000) << "MB/s"; } @@ -598,7 +618,7 @@ void tst_QTcpSocket_stresstest::connectDisconnect() totalBytes += byteCounter; if (intermediateDebug) { - double rate = (byteCounter / timeout.elapsed()); + double rate = (byteCounter * 1.0 / timeout.elapsed()); qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" << (rate / 1024.0 / 1024 * 1000) << "MB/s"; } @@ -669,7 +689,7 @@ void tst_QTcpSocket_stresstest::parallelConnectDisconnect() totalBytes += byteCounter; if (intermediateDebug) { - double rate = (byteCounter / timeout.elapsed()); + double rate = (byteCounter * 1.0 / timeout.elapsed()); qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" << (rate / 1024.0 / 1024 * 1000) << "MB/s"; } @@ -758,7 +778,7 @@ void tst_QTcpSocket_stresstest::namGet() QVERIFY2(!timeout.hasExpired(30000), "Timeout"); totalBytes += byteCounter; if (intermediateDebug) { - double rate = (byteCounter / timeout.elapsed()); + double rate = (byteCounter * 1.0 / timeout.elapsed()); qDebug() << i << byteCounter << "bytes in" << timeout.elapsed() << "ms:" << (rate / 1024.0 / 1024 * 1000) << "MB/s"; } @@ -766,6 +786,234 @@ void tst_QTcpSocket_stresstest::namGet() qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s"; } +void tst_QTcpSocket_stresstest::blockingSequentialRemoteHosts() +{ + QFETCH_GLOBAL(bool, isLocalhost); + if (isLocalhost) + return; + + qint64 totalBytes = 0; + QElapsedTimer outerTimer; + outerTimer.start(); + + for (int i = 0; i < httpUrls.size(); ++i) { + const QUrl &url = httpUrls.at(i); + QElapsedTimer timeout; + byteCounter = 0; + timeout.start(); + + QTcpSocket socket; + socket.connectToHost(url.host(), url.port(80)); + QVERIFY2(socket.waitForConnected(10000), "Timeout connecting"); + + 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"); + + while (socket.state() == QAbstractSocket::ConnectedState && !timeout.hasExpired(10000)) { + socket.waitForReadyRead(10000); + byteCounter += socket.readAll().size(); // discard + } + QVERIFY2(!timeout.hasExpired(10000), "Timeout reading"); + + 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_QTcpSocket_stresstest::sequentialRemoteHosts() +{ + QFETCH_GLOBAL(bool, isLocalhost); + if (isLocalhost) + return; + + qint64 totalBytes = 0; + QElapsedTimer outerTimer; + outerTimer.start(); + + for (int i = 0; i < httpUrls.size(); ++i) { + const QUrl &url = httpUrls.at(i); + QElapsedTimer timeout; + byteCounter = 0; + timeout.start(); + + QTcpSocket socket; + 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, 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 << 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_QTcpSocket_stresstest::parallelRemoteHosts_data() +{ + QTest::addColumn("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_QTcpSocket_stresstest::parallelRemoteHosts() +{ + QFETCH_GLOBAL(bool, isLocalhost); + if (isLocalhost) + return; + + QFETCH(int, parallelAttempts); + + qint64 totalBytes = 0; + QElapsedTimer outerTimer; + outerTimer.start(); + + QVector::ConstIterator it = httpUrls.constBegin(); + while (it != httpUrls.constEnd()) { + QElapsedTimer timeout; + byteCounter = 0; + timeout.start(); + + QVector > sockets; + sockets.reserve(parallelAttempts); + for (int j = 0; j < parallelAttempts && it != httpUrls.constEnd(); ++j, ++it) { + const QUrl &url = *it; + QTcpSocket *socket = new QTcpSocket; + 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, SIGNAL(readyRead()), SLOT(slotReadAll())); + QTestEventLoop::instance().connect(socket, SIGNAL(disconnected()), SLOT(exitLoop())); + + sockets.append(QSharedPointer(socket)); + } + + while (!timeout.hasExpired(30000)) { + 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; + } + + 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_QTcpSocket_stresstest::namRemoteGet_data() +{ + QTest::addColumn("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_QTcpSocket_stresstest::namRemoteGet() +{ + QFETCH_GLOBAL(bool, isLocalhost); + if (isLocalhost) + return; + + QFETCH(int, parallelAttempts); + bool pipelineAllowed = false;// QFETCH(bool, pipelineAllowed); + + if (parallelAttempts > 100) { + QFETCH_GLOBAL(bool, isLocalhost); + if (!isLocalhost) + QSKIP("Localhost-only test", SkipSingle); + } + + qint64 totalBytes = 0; + QElapsedTimer outerTimer; + outerTimer.start(); + + QVector::ConstIterator it = httpUrls.constBegin(); + while (it != httpUrls.constEnd()) { + QElapsedTimer timeout; + byteCounter = 0; + timeout.start(); + + QNetworkRequest req; + req.setAttribute(QNetworkRequest::HttpPipeliningAllowedAttribute, pipelineAllowed); + + QVector > replies; + replies.reserve(parallelAttempts); + for (int j = 0; j < parallelAttempts && it != httpUrls.constEnd(); ++j) { + req.setUrl(*it++); + QNetworkReply *r = manager.get(req); + + connect(r, SIGNAL(readyRead()), SLOT(slotReadAll())); + QTestEventLoop::instance().connect(r, SIGNAL(finished()), SLOT(exitLoop())); + + replies.append(QSharedPointer(r)); + } + + while (!timeout.hasExpired(30000)) { + QTestEventLoop::instance().enterLoop(10); + int done = 0; + for (int j = 0; j < replies.size(); ++j) + done += replies[j]->isFinished() ? 1 : 0; + if (done == replies.size()) + break; + } + replies.clear(); + + QVERIFY2(!timeout.hasExpired(30000), "Timeout"); + 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_QTcpSocket_stresstest); #include "tst_network_stresstest.moc" diff --git a/tests/manual/network_stresstest/url-list.txt b/tests/manual/network_stresstest/url-list.txt new file mode 100644 index 0000000..3d6d7a9 --- /dev/null +++ b/tests/manual/network_stresstest/url-list.txt @@ -0,0 +1,64 @@ +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://public.wisekey.com/crt/owgrgaca.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://www.certicamara.com/ac_offline_raiz_certicamara.crt +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/wwwfiles.qrc b/tests/manual/network_stresstest/wwwfiles.qrc index b1d4be6..2290861 100644 --- a/tests/manual/network_stresstest/wwwfiles.qrc +++ b/tests/manual/network_stresstest/wwwfiles.qrc @@ -1,5 +1,6 @@ - qtest + qtest + url-list.txt -- cgit v0.12 From 4b684fb390c0bb63c8a68b6281fd5a77629a94d2 Mon Sep 17 00:00:00 2001 From: Thiago Macieira Date: Fri, 16 Apr 2010 12:13:57 +0200 Subject: Split the remote and the local tests in two, in preparation for SSL tests --- .../network_remote_stresstest.pro | 8 + .../tst_network_remote_stresstest.cpp | 435 +++++++++++++++++++++ .../manual/network_remote_stresstest/url-list.qrc | 5 + .../manual/network_remote_stresstest/url-list.txt | 64 +++ .../network_stresstest/tst_network_stresstest.cpp | 282 +------------ tests/manual/network_stresstest/url-list.txt | 64 --- tests/manual/network_stresstest/wwwfiles.qrc | 1 - 7 files changed, 529 insertions(+), 330 deletions(-) create mode 100644 tests/manual/network_remote_stresstest/network_remote_stresstest.pro create mode 100644 tests/manual/network_remote_stresstest/tst_network_remote_stresstest.cpp create mode 100644 tests/manual/network_remote_stresstest/url-list.qrc create mode 100644 tests/manual/network_remote_stresstest/url-list.txt delete mode 100644 tests/manual/network_stresstest/url-list.txt 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..dca09c1 --- /dev/null +++ b/tests/manual/network_remote_stresstest/tst_network_remote_stresstest.cpp @@ -0,0 +1,435 @@ +/**************************************************************************** +** +** 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 +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#ifdef QT_BUILD_INTERNAL +# include +#endif + +#include +#ifdef Q_OS_UNIX +# include +# include +# include +# include +# include +# include +# include +# include +# include + +typedef int SOCKET; +# define INVALID_SOCKET -1 +# define SOCKET_ERROR -1 + +#elif defined(Q_OS_WIN) +# include +#endif + +Q_DECLARE_METATYPE(QVector) + +class tst_NetworkRemoteStressTest : public QObject +{ + Q_OBJECT +public: + enum { AttemptCount = 100 }; + tst_NetworkRemoteStressTest(); + + qint64 byteCounter; + QNetworkAccessManager manager; + QVector httpUrls; + bool intermediateDebug; + +private: + void clearManager(); + +public slots: + void initTestCase_data(); + void init(); + + void slotReadAll() { byteCounter += static_cast(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; + } + } + + httpUrls << httpUrls; +} + +void tst_NetworkRemoteStressTest::initTestCase_data() +{ + QTest::addColumn >("urlList"); + + QTest::newRow("no-ssl") << httpUrls; +} + +void tst_NetworkRemoteStressTest::init() +{ + // clear the internal cache +#ifndef QT_BUILD_INTERNAL + if (strncmp(QTest::currentTestFunction(), "nam") == 0) + QSKIP("QNetworkAccessManager tests disabled", SkipAll); +#endif + qDebug() << QTest::currentTestFunction() << QTest::currentDataTag(); +} + +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, urlList); + + qint64 totalBytes = 0; + QElapsedTimer outerTimer; + outerTimer.start(); + + for (int i = 0; i < urlList.size(); ++i) { + const QUrl &url = urlList.at(i); + QElapsedTimer timeout; + byteCounter = 0; + timeout.start(); + + QTcpSocket socket; + socket.connectToHost(url.host(), url.port(80)); + QVERIFY2(socket.waitForConnected(10000), "Timeout connecting"); + + 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"); + + while (socket.state() == QAbstractSocket::ConnectedState && !timeout.hasExpired(10000)) { + socket.waitForReadyRead(10000); + byteCounter += socket.readAll().size(); // discard + } + QVERIFY2(!timeout.hasExpired(10000), "Timeout reading"); + + 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, urlList); + + qint64 totalBytes = 0; + QElapsedTimer outerTimer; + outerTimer.start(); + + for (int i = 0; i < urlList.size(); ++i) { + const QUrl &url = urlList.at(i); + QElapsedTimer timeout; + byteCounter = 0; + timeout.start(); + + QTcpSocket socket; + 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, 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 << 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("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, urlList); + + QFETCH(int, parallelAttempts); + + qint64 totalBytes = 0; + QElapsedTimer outerTimer; + outerTimer.start(); + + QVector::ConstIterator it = urlList.constBegin(); + while (it != urlList.constEnd()) { + QElapsedTimer timeout; + byteCounter = 0; + timeout.start(); + + QVector > sockets; + sockets.reserve(parallelAttempts); + for (int j = 0; j < parallelAttempts && it != urlList.constEnd(); ++j, ++it) { + const QUrl &url = *it; + QTcpSocket *socket = new QTcpSocket; + 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, SIGNAL(readyRead()), SLOT(slotReadAll())); + QTestEventLoop::instance().connect(socket, SIGNAL(disconnected()), SLOT(exitLoop())); + + sockets.append(QSharedPointer(socket)); + } + + while (!timeout.hasExpired(30000)) { + 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; + } + + 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("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, urlList); + + QFETCH(int, parallelAttempts); + bool pipelineAllowed = false;// QFETCH(bool, pipelineAllowed); + + qint64 totalBytes = 0; + QElapsedTimer outerTimer; + outerTimer.start(); + + QVector::ConstIterator it = urlList.constBegin(); + while (it != urlList.constEnd()) { + QElapsedTimer timeout; + byteCounter = 0; + timeout.start(); + + QNetworkRequest req; + req.setAttribute(QNetworkRequest::HttpPipeliningAllowedAttribute, pipelineAllowed); + + QVector > replies; + replies.reserve(parallelAttempts); + for (int j = 0; j < parallelAttempts && it != urlList.constEnd(); ++j) { + req.setUrl(*it++); + QNetworkReply *r = manager.get(req); + + connect(r, SIGNAL(readyRead()), SLOT(slotReadAll())); + QTestEventLoop::instance().connect(r, SIGNAL(finished()), SLOT(exitLoop())); + + replies.append(QSharedPointer(r)); + } + + while (!timeout.hasExpired(30000)) { + QTestEventLoop::instance().enterLoop(10); + int done = 0; + for (int j = 0; j < replies.size(); ++j) + done += replies[j]->isFinished() ? 1 : 0; + if (done == replies.size()) + break; + } + replies.clear(); + + QVERIFY2(!timeout.hasExpired(30000), "Timeout"); + 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 @@ + + + url-list.txt + + 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..3d6d7a9 --- /dev/null +++ b/tests/manual/network_remote_stresstest/url-list.txt @@ -0,0 +1,64 @@ +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://public.wisekey.com/crt/owgrgaca.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://www.certicamara.com/ac_offline_raiz_certicamara.crt +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/tst_network_stresstest.cpp b/tests/manual/network_stresstest/tst_network_stresstest.cpp index d3b007a..34d83e1 100644 --- a/tests/manual/network_stresstest/tst_network_stresstest.cpp +++ b/tests/manual/network_stresstest/tst_network_stresstest.cpp @@ -76,17 +76,16 @@ typedef int SOCKET; # include #endif -class tst_QTcpSocket_stresstest : public QObject +class tst_NetworkStressTest : public QObject { Q_OBJECT public: enum { AttemptCount = 100 }; - tst_QTcpSocket_stresstest(); + tst_NetworkStressTest(); MiniHttpServer server; qint64 byteCounter; QNetworkAccessManager manager; - QVector httpUrls; bool intermediateDebug; private: @@ -109,16 +108,9 @@ private Q_SLOTS: void parallelConnectDisconnect(); void namGet_data(); void namGet(); - - void blockingSequentialRemoteHosts(); - void sequentialRemoteHosts(); - void parallelRemoteHosts_data(); - void parallelRemoteHosts(); - void namRemoteGet_data(); - void namRemoteGet(); }; -tst_QTcpSocket_stresstest::tst_QTcpSocket_stresstest() +tst_NetworkStressTest::tst_NetworkStressTest() : intermediateDebug(qgetenv("STRESSDEBUG").toInt() > 0) { #ifdef Q_OS_WIN @@ -129,21 +121,9 @@ tst_QTcpSocket_stresstest::tst_QTcpSocket_stresstest() #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; - } - } - - httpUrls << httpUrls; } -void tst_QTcpSocket_stresstest::initTestCase_data() +void tst_NetworkStressTest::initTestCase_data() { QTest::addColumn("isLocalhost"); QTest::addColumn("hostname"); @@ -153,7 +133,7 @@ void tst_QTcpSocket_stresstest::initTestCase_data() QTest::newRow("remote") << false << QtNetworkSettings::serverName() << 80; } -void tst_QTcpSocket_stresstest::init() +void tst_NetworkStressTest::init() { // clear the internal cache #ifndef QT_BUILD_INTERNAL @@ -162,7 +142,7 @@ void tst_QTcpSocket_stresstest::init() #endif } -void tst_QTcpSocket_stresstest::clearManager() +void tst_NetworkStressTest::clearManager() { #ifdef QT_BUILD_INTERNAL QNetworkAccessManagerPrivate::clearCache(&manager); @@ -230,7 +210,7 @@ bool nativeSelect(int fd, int timeout, bool selectForWrite) return ret != 0; } -void tst_QTcpSocket_stresstest::nativeBlockingConnectDisconnect() +void tst_NetworkStressTest::nativeBlockingConnectDisconnect() { QFETCH_GLOBAL(QString, hostname); QFETCH_GLOBAL(int, port); @@ -304,7 +284,7 @@ void tst_QTcpSocket_stresstest::nativeBlockingConnectDisconnect() #endif } -void tst_QTcpSocket_stresstest::nativeNonBlockingConnectDisconnect() +void tst_NetworkStressTest::nativeNonBlockingConnectDisconnect() { QFETCH_GLOBAL(QString, hostname); QFETCH_GLOBAL(int, port); @@ -418,7 +398,7 @@ void tst_QTcpSocket_stresstest::nativeNonBlockingConnectDisconnect() qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s"; } -void tst_QTcpSocket_stresstest::blockingConnectDisconnect() +void tst_NetworkStressTest::blockingConnectDisconnect() { QFETCH_GLOBAL(QString, hostname); QFETCH_GLOBAL(int, port); @@ -459,7 +439,7 @@ void tst_QTcpSocket_stresstest::blockingConnectDisconnect() qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s"; } -void tst_QTcpSocket_stresstest::blockingPipelined() +void tst_NetworkStressTest::blockingPipelined() { QFETCH_GLOBAL(QString, hostname); QFETCH_GLOBAL(int, port); @@ -504,7 +484,7 @@ void tst_QTcpSocket_stresstest::blockingPipelined() qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s"; } -void tst_QTcpSocket_stresstest::blockingMultipleRequests() +void tst_NetworkStressTest::blockingMultipleRequests() { QFETCH_GLOBAL(QString, hostname); QFETCH_GLOBAL(int, port); @@ -588,7 +568,7 @@ void tst_QTcpSocket_stresstest::blockingMultipleRequests() qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s"; } -void tst_QTcpSocket_stresstest::connectDisconnect() +void tst_NetworkStressTest::connectDisconnect() { QFETCH_GLOBAL(QString, hostname); QFETCH_GLOBAL(int, port); @@ -626,7 +606,7 @@ void tst_QTcpSocket_stresstest::connectDisconnect() qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s"; } -void tst_QTcpSocket_stresstest::parallelConnectDisconnect_data() +void tst_NetworkStressTest::parallelConnectDisconnect_data() { QTest::addColumn("parallelAttempts"); QTest::newRow("1") << 1; @@ -641,7 +621,7 @@ void tst_QTcpSocket_stresstest::parallelConnectDisconnect_data() QTest::newRow("500") << 500; } -void tst_QTcpSocket_stresstest::parallelConnectDisconnect() +void tst_NetworkStressTest::parallelConnectDisconnect() { QFETCH_GLOBAL(QString, hostname); QFETCH_GLOBAL(int, port); @@ -697,7 +677,7 @@ void tst_QTcpSocket_stresstest::parallelConnectDisconnect() qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s"; } -void tst_QTcpSocket_stresstest::namGet_data() +void tst_NetworkStressTest::namGet_data() { QTest::addColumn("parallelAttempts"); QTest::addColumn("pipelineAllowed"); @@ -724,7 +704,7 @@ void tst_QTcpSocket_stresstest::namGet_data() QTest::newRow("500p") << 500 << true; } -void tst_QTcpSocket_stresstest::namGet() +void tst_NetworkStressTest::namGet() { QFETCH_GLOBAL(QString, hostname); QFETCH_GLOBAL(int, port); @@ -786,234 +766,6 @@ void tst_QTcpSocket_stresstest::namGet() qDebug() << "Average transfer rate was" << (totalBytes / 1024.0 / 1024 * 1000 / outerTimer.elapsed()) << "MB/s"; } -void tst_QTcpSocket_stresstest::blockingSequentialRemoteHosts() -{ - QFETCH_GLOBAL(bool, isLocalhost); - if (isLocalhost) - return; - - qint64 totalBytes = 0; - QElapsedTimer outerTimer; - outerTimer.start(); - - for (int i = 0; i < httpUrls.size(); ++i) { - const QUrl &url = httpUrls.at(i); - QElapsedTimer timeout; - byteCounter = 0; - timeout.start(); - - QTcpSocket socket; - socket.connectToHost(url.host(), url.port(80)); - QVERIFY2(socket.waitForConnected(10000), "Timeout connecting"); - - 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"); - - while (socket.state() == QAbstractSocket::ConnectedState && !timeout.hasExpired(10000)) { - socket.waitForReadyRead(10000); - byteCounter += socket.readAll().size(); // discard - } - QVERIFY2(!timeout.hasExpired(10000), "Timeout reading"); - - 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_QTcpSocket_stresstest::sequentialRemoteHosts() -{ - QFETCH_GLOBAL(bool, isLocalhost); - if (isLocalhost) - return; - - qint64 totalBytes = 0; - QElapsedTimer outerTimer; - outerTimer.start(); - - for (int i = 0; i < httpUrls.size(); ++i) { - const QUrl &url = httpUrls.at(i); - QElapsedTimer timeout; - byteCounter = 0; - timeout.start(); - - QTcpSocket socket; - 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, 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 << 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_QTcpSocket_stresstest::parallelRemoteHosts_data() -{ - QTest::addColumn("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_QTcpSocket_stresstest::parallelRemoteHosts() -{ - QFETCH_GLOBAL(bool, isLocalhost); - if (isLocalhost) - return; - - QFETCH(int, parallelAttempts); - - qint64 totalBytes = 0; - QElapsedTimer outerTimer; - outerTimer.start(); - - QVector::ConstIterator it = httpUrls.constBegin(); - while (it != httpUrls.constEnd()) { - QElapsedTimer timeout; - byteCounter = 0; - timeout.start(); - - QVector > sockets; - sockets.reserve(parallelAttempts); - for (int j = 0; j < parallelAttempts && it != httpUrls.constEnd(); ++j, ++it) { - const QUrl &url = *it; - QTcpSocket *socket = new QTcpSocket; - 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, SIGNAL(readyRead()), SLOT(slotReadAll())); - QTestEventLoop::instance().connect(socket, SIGNAL(disconnected()), SLOT(exitLoop())); - - sockets.append(QSharedPointer(socket)); - } - - while (!timeout.hasExpired(30000)) { - 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; - } - - 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_QTcpSocket_stresstest::namRemoteGet_data() -{ - QTest::addColumn("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_QTcpSocket_stresstest::namRemoteGet() -{ - QFETCH_GLOBAL(bool, isLocalhost); - if (isLocalhost) - return; - - QFETCH(int, parallelAttempts); - bool pipelineAllowed = false;// QFETCH(bool, pipelineAllowed); - - if (parallelAttempts > 100) { - QFETCH_GLOBAL(bool, isLocalhost); - if (!isLocalhost) - QSKIP("Localhost-only test", SkipSingle); - } - - qint64 totalBytes = 0; - QElapsedTimer outerTimer; - outerTimer.start(); - - QVector::ConstIterator it = httpUrls.constBegin(); - while (it != httpUrls.constEnd()) { - QElapsedTimer timeout; - byteCounter = 0; - timeout.start(); - - QNetworkRequest req; - req.setAttribute(QNetworkRequest::HttpPipeliningAllowedAttribute, pipelineAllowed); - - QVector > replies; - replies.reserve(parallelAttempts); - for (int j = 0; j < parallelAttempts && it != httpUrls.constEnd(); ++j) { - req.setUrl(*it++); - QNetworkReply *r = manager.get(req); - - connect(r, SIGNAL(readyRead()), SLOT(slotReadAll())); - QTestEventLoop::instance().connect(r, SIGNAL(finished()), SLOT(exitLoop())); - - replies.append(QSharedPointer(r)); - } - - while (!timeout.hasExpired(30000)) { - QTestEventLoop::instance().enterLoop(10); - int done = 0; - for (int j = 0; j < replies.size(); ++j) - done += replies[j]->isFinished() ? 1 : 0; - if (done == replies.size()) - break; - } - replies.clear(); - - QVERIFY2(!timeout.hasExpired(30000), "Timeout"); - 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_QTcpSocket_stresstest); +QTEST_MAIN(tst_NetworkStressTest); #include "tst_network_stresstest.moc" diff --git a/tests/manual/network_stresstest/url-list.txt b/tests/manual/network_stresstest/url-list.txt deleted file mode 100644 index 3d6d7a9..0000000 --- a/tests/manual/network_stresstest/url-list.txt +++ /dev/null @@ -1,64 +0,0 @@ -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://public.wisekey.com/crt/owgrgaca.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://www.certicamara.com/ac_offline_raiz_certicamara.crt -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/wwwfiles.qrc b/tests/manual/network_stresstest/wwwfiles.qrc index 2290861..4d602a1 100644 --- a/tests/manual/network_stresstest/wwwfiles.qrc +++ b/tests/manual/network_stresstest/wwwfiles.qrc @@ -1,6 +1,5 @@ qtest - url-list.txt -- cgit v0.12 From 26b9ca7189676b6afd055ec64fc211afaf652f7f Mon Sep 17 00:00:00 2001 From: Thiago Macieira Date: Fri, 16 Apr 2010 13:31:06 +0200 Subject: Add SSL remote host tests --- .../tst_network_remote_stresstest.cpp | 129 +++++++++++++++------ 1 file changed, 95 insertions(+), 34 deletions(-) diff --git a/tests/manual/network_remote_stresstest/tst_network_remote_stresstest.cpp b/tests/manual/network_remote_stresstest/tst_network_remote_stresstest.cpp index dca09c1..542147c 100644 --- a/tests/manual/network_remote_stresstest/tst_network_remote_stresstest.cpp +++ b/tests/manual/network_remote_stresstest/tst_network_remote_stresstest.cpp @@ -85,7 +85,7 @@ public: qint64 byteCounter; QNetworkAccessManager manager; - QVector httpUrls; + QVector httpUrls, httpsUrls, mixedUrls; bool intermediateDebug; private: @@ -125,17 +125,26 @@ tst_NetworkRemoteStressTest::tst_NetworkRemoteStressTest() QUrl url = QUrl::fromEncoded(line); if (url.scheme() == "http") httpUrls << url; + else if (url.scheme() == "https") + httpsUrls << url; + mixedUrls << url; } } httpUrls << httpUrls; + httpsUrls << httpsUrls; } void tst_NetworkRemoteStressTest::initTestCase_data() { QTest::addColumn >("urlList"); + QTest::addColumn("useSslSocket"); - QTest::newRow("no-ssl") << httpUrls; +// 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() @@ -145,7 +154,6 @@ void tst_NetworkRemoteStressTest::init() if (strncmp(QTest::currentTestFunction(), "nam") == 0) QSKIP("QNetworkAccessManager tests disabled", SkipAll); #endif - qDebug() << QTest::currentTestFunction() << QTest::currentDataTag(); } void tst_NetworkRemoteStressTest::clearManager() @@ -219,6 +227,7 @@ bool nativeSelect(int fd, int timeout, bool selectForWrite) void tst_NetworkRemoteStressTest::blockingSequentialRemoteHosts() { QFETCH_GLOBAL(QVector, urlList); + QFETCH_GLOBAL(bool, useSslSocket); qint64 totalBytes = 0; QElapsedTimer outerTimer; @@ -226,27 +235,41 @@ void tst_NetworkRemoteStressTest::blockingSequentialRemoteHosts() 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(); - QTcpSocket socket; - socket.connectToHost(url.host(), url.port(80)); - QVERIFY2(socket.waitForConnected(10000), "Timeout connecting"); - - 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"); - - while (socket.state() == QAbstractSocket::ConnectedState && !timeout.hasExpired(10000)) { - socket.waitForReadyRead(10000); - byteCounter += socket.readAll().size(); // discard + QSharedPointer socket; + if (useSslSocket || isHttps) { + socket = QSharedPointer(new QSslSocket); + } else { + socket = QSharedPointer(new QTcpSocket); } - QVERIFY2(!timeout.hasExpired(10000), "Timeout reading"); + + socket->connectToHost(url.host(), url.port(isHttps ? 443 : 80)); + QVERIFY2(socket->waitForConnected(10000), "Timeout connecting to " + url.encodedHost()); + + if (isHttps) { + static_cast(socket.data())->setProtocol(QSsl::TlsV1); + static_cast(socket.data())->startClientEncryption(); + static_cast(socket.data())->ignoreSslErrors(); + QVERIFY2(static_cast(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) { @@ -261,6 +284,7 @@ void tst_NetworkRemoteStressTest::blockingSequentialRemoteHosts() void tst_NetworkRemoteStressTest::sequentialRemoteHosts() { QFETCH_GLOBAL(QVector, urlList); + QFETCH_GLOBAL(bool, useSslSocket); qint64 totalBytes = 0; QElapsedTimer outerTimer; @@ -268,23 +292,35 @@ void tst_NetworkRemoteStressTest::sequentialRemoteHosts() 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(); - QTcpSocket socket; - socket.connectToHost(url.host(), url.port(80)); + QSharedPointer socket; + if (useSslSocket || isHttps) { + socket = QSharedPointer(new QSslSocket); + } else { + socket = QSharedPointer(new QTcpSocket); + } + socket->connectToHost(url.host(), url.port(isHttps ? 443 : 80)); + if (isHttps) { + static_cast(socket.data())->setProtocol(QSsl::TlsV1); + static_cast(socket.data())->startClientEncryption(); + static_cast(socket.data())->ignoreSslErrors(); + } - 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())); + 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, SIGNAL(disconnected()), SLOT(exitLoop())); + QTestEventLoop::instance().connect(socket.data(), SIGNAL(disconnected()), SLOT(exitLoop())); QTestEventLoop::instance().enterLoop(30); - QVERIFY2(!QTestEventLoop::instance().timeout(), "Timeout"); + QVERIFY2(!QTestEventLoop::instance().timeout(), "Timeout with " + url.encodedHost() + "; " + + QByteArray::number(socket->bytesToWrite()) + " bytes to write"); totalBytes += byteCounter; if (intermediateDebug) { @@ -313,6 +349,7 @@ void tst_NetworkRemoteStressTest::parallelRemoteHosts_data() void tst_NetworkRemoteStressTest::parallelRemoteHosts() { QFETCH_GLOBAL(QVector, urlList); + QFETCH_GLOBAL(bool, useSslSocket); QFETCH(int, parallelAttempts); @@ -330,8 +367,18 @@ void tst_NetworkRemoteStressTest::parallelRemoteHosts() sockets.reserve(parallelAttempts); for (int j = 0; j < parallelAttempts && it != urlList.constEnd(); ++j, ++it) { const QUrl &url = *it; - QTcpSocket *socket = new QTcpSocket; - socket->connectToHost(url.host(), url.port(80)); + bool isHttps = url.scheme() == "https"; + QTcpSocket *socket; + if (useSslSocket || isHttps) + socket = new QSslSocket; + else + socket = new QTcpSocket; + socket->connectToHost(url.host(), url.port(isHttps ? 443 : 80)); + if (isHttps) { + static_cast(socket)->setProtocol(QSsl::TlsV1); + static_cast(socket)->startClientEncryption(); + static_cast(socket)->ignoreSslErrors(); + } socket->write("GET " + url.toEncoded(QUrl::RemoveScheme | QUrl::RemoveAuthority | QUrl::RemoveFragment) + " HTTP/1.0\r\n" "Connection: close\r\n" @@ -340,11 +387,12 @@ void tst_NetworkRemoteStressTest::parallelRemoteHosts() "\r\n"); connect(socket, SIGNAL(readyRead()), SLOT(slotReadAll())); QTestEventLoop::instance().connect(socket, SIGNAL(disconnected()), SLOT(exitLoop())); + socket->setProperty("remoteUrl", url); sockets.append(QSharedPointer(socket)); } - while (!timeout.hasExpired(30000)) { + while (!timeout.hasExpired(10000)) { QTestEventLoop::instance().enterLoop(10); int done = 0; for (int j = 0; j < sockets.size(); ++j) @@ -352,6 +400,13 @@ void tst_NetworkRemoteStressTest::parallelRemoteHosts() if (done == sockets.size()) break; } + if (timeout.hasExpired(10000)) { + 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) { @@ -402,6 +457,7 @@ void tst_NetworkRemoteStressTest::namRemoteGet() 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())); @@ -409,7 +465,7 @@ void tst_NetworkRemoteStressTest::namRemoteGet() replies.append(QSharedPointer(r)); } - while (!timeout.hasExpired(30000)) { + while (!timeout.hasExpired(10000)) { QTestEventLoop::instance().enterLoop(10); int done = 0; for (int j = 0; j < replies.size(); ++j) @@ -417,9 +473,14 @@ void tst_NetworkRemoteStressTest::namRemoteGet() if (done == replies.size()) break; } + if (timeout.hasExpired(10000)) { + for (int j = 0; j < replies.size(); ++j) + if (!replies[j]->isFinished()) + qDebug() << "Request" << replies[j]->url() << "not finished"; + QFAIL("Timed out"); + } replies.clear(); - QVERIFY2(!timeout.hasExpired(30000), "Timeout"); totalBytes += byteCounter; if (intermediateDebug) { double rate = (byteCounter * 1.0 / timeout.elapsed()); -- cgit v0.12 From e2c776862cb9bdf5b651c15934f7e92fe11b989b Mon Sep 17 00:00:00 2001 From: Fabien Freling Date: Fri, 16 Apr 2010 14:27:57 +0200 Subject: Fix menu bar visibility. We no longer show the menu bar if it is not native and doesn't have a parent widget. --- src/gui/widgets/qmenubar.cpp | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/gui/widgets/qmenubar.cpp b/src/gui/widgets/qmenubar.cpp index a13a2fa..ef37fd1 100644 --- a/src/gui/widgets/qmenubar.cpp +++ b/src/gui/widgets/qmenubar.cpp @@ -1931,9 +1931,9 @@ void QMenuBar::setNativeMenuBar(bool nativeMenuBar) d->macCreateMenuBar(parentWidget()); } macUpdateMenuBar(); - updateGeometry(); - setVisible(false); - setVisible(true); + updateGeometry(); + if (!d->nativeMenuBar && parentWidget()) + setVisible(true); #endif } } -- cgit v0.12 From dc0d84ac8f797eaf1d74cd82cda1aab04b0e5f87 Mon Sep 17 00:00:00 2001 From: Thiago Macieira Date: Fri, 16 Apr 2010 14:31:13 +0200 Subject: Make sure we don't try URLs that aren't HTTP or HTTPS --- .../network_remote_stresstest/tst_network_remote_stresstest.cpp | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/tests/manual/network_remote_stresstest/tst_network_remote_stresstest.cpp b/tests/manual/network_remote_stresstest/tst_network_remote_stresstest.cpp index 542147c..c35cdeb 100644 --- a/tests/manual/network_remote_stresstest/tst_network_remote_stresstest.cpp +++ b/tests/manual/network_remote_stresstest/tst_network_remote_stresstest.cpp @@ -123,11 +123,13 @@ tst_NetworkRemoteStressTest::tst_NetworkRemoteStressTest() while (!urlList.atEnd()) { QByteArray line = urlList.readLine().trimmed(); QUrl url = QUrl::fromEncoded(line); - if (url.scheme() == "http") + if (url.scheme() == "http") { httpUrls << url; - else if (url.scheme() == "https") + mixedUrls << url; + } else if (url.scheme() == "https") { httpsUrls << url; - mixedUrls << url; + mixedUrls << url; + } } } -- cgit v0.12 From 5c48202a1a3618e71a56d957f0170827543dd3f3 Mon Sep 17 00:00:00 2001 From: Thiago Macieira Date: Fri, 16 Apr 2010 14:31:58 +0200 Subject: Fix SSL connection problem. You can't do connectToHost followed by startClientEncryption followed by write. --- .../tst_network_remote_stresstest.cpp | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/tests/manual/network_remote_stresstest/tst_network_remote_stresstest.cpp b/tests/manual/network_remote_stresstest/tst_network_remote_stresstest.cpp index c35cdeb..f9f2730 100644 --- a/tests/manual/network_remote_stresstest/tst_network_remote_stresstest.cpp +++ b/tests/manual/network_remote_stresstest/tst_network_remote_stresstest.cpp @@ -305,11 +305,12 @@ void tst_NetworkRemoteStressTest::sequentialRemoteHosts() } else { socket = QSharedPointer(new QTcpSocket); } - socket->connectToHost(url.host(), url.port(isHttps ? 443 : 80)); if (isHttps) { static_cast(socket.data())->setProtocol(QSsl::TlsV1); - static_cast(socket.data())->startClientEncryption(); + static_cast(socket.data())->connectToHostEncrypted(url.host(), url.port(443)); static_cast(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" @@ -375,11 +376,12 @@ void tst_NetworkRemoteStressTest::parallelRemoteHosts() socket = new QSslSocket; else socket = new QTcpSocket; - socket->connectToHost(url.host(), url.port(isHttps ? 443 : 80)); if (isHttps) { static_cast(socket)->setProtocol(QSsl::TlsV1); - static_cast(socket)->startClientEncryption(); + static_cast(socket)->connectToHostEncrypted(url.host(), url.port(443)); static_cast(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" -- cgit v0.12 From b31559b05ad50a228a4a2670034a8a99681722da Mon Sep 17 00:00:00 2001 From: Thiago Macieira Date: Fri, 16 Apr 2010 14:32:27 +0200 Subject: Other fixes to the remote network stresstester --- .../tst_network_remote_stresstest.cpp | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/tests/manual/network_remote_stresstest/tst_network_remote_stresstest.cpp b/tests/manual/network_remote_stresstest/tst_network_remote_stresstest.cpp index f9f2730..2f0bc2c 100644 --- a/tests/manual/network_remote_stresstest/tst_network_remote_stresstest.cpp +++ b/tests/manual/network_remote_stresstest/tst_network_remote_stresstest.cpp @@ -142,7 +142,7 @@ void tst_NetworkRemoteStressTest::initTestCase_data() QTest::addColumn >("urlList"); QTest::addColumn("useSslSocket"); -// QTest::newRow("no-ssl") << httpUrls << false; + QTest::newRow("no-ssl") << httpUrls << false; // QTest::newRow("no-ssl-in-sslsocket") << httpUrls << true; QTest::newRow("ssl") << httpsUrls << true; QTest::newRow("mixed") << mixedUrls << false; @@ -404,13 +404,12 @@ void tst_NetworkRemoteStressTest::parallelRemoteHosts() if (done == sockets.size()) break; } - if (timeout.hasExpired(10000)) { - 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"); - } + 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) { -- cgit v0.12 From ab5d841e76d52cb06946e7ddab33509e7ba48292 Mon Sep 17 00:00:00 2001 From: Martin Smith Date: Fri, 16 Apr 2010 15:32:24 +0200 Subject: qdoc: Output TOC for more class ref pages. --- tools/qdoc3/htmlgenerator.cpp | 16 ++++++---------- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git a/tools/qdoc3/htmlgenerator.cpp b/tools/qdoc3/htmlgenerator.cpp index 6922ef8..a5dc7b7 100644 --- a/tools/qdoc3/htmlgenerator.cpp +++ b/tools/qdoc3/htmlgenerator.cpp @@ -1473,7 +1473,7 @@ void HtmlGenerator::generateFakeNode(const FakeNode *fake, CodeMarker *marker) Don't generate a TOC for the home page. */ if (fake->name() != QString("index.html")) - generateTableOfContents(fake,marker); + generateTableOfContents(fake,marker,0); generateTitle(fullTitle, Text() << fake->subTitle(), @@ -2033,15 +2033,11 @@ void HtmlGenerator::generateTableOfContents(const Node *node, CodeMarker *marker, QList
* sections) { - if (!node->doc().hasTableOfContents()) { - if (node->subType() != Node::Module) - return; - } - QList toc = node->doc().tableOfContents(); - if (toc.isEmpty()) { - if (node->subType() != Node::Module) - return; - } + QList toc; + if (node->doc().hasTableOfContents()) + toc = node->doc().tableOfContents(); + if (toc.isEmpty() && !sections && (node->subType() != Node::Module)) + return; QStringList sectionNumber; int detailsBase = 0; -- cgit v0.12 From 1632befae9b7c5faf5912923915d85ae1480b9e6 Mon Sep 17 00:00:00 2001 From: Thiago Macieira Date: Fri, 16 Apr 2010 16:01:20 +0200 Subject: Remove unstable hosts from the list --- tests/manual/network_remote_stresstest/url-list.txt | 2 -- 1 file changed, 2 deletions(-) diff --git a/tests/manual/network_remote_stresstest/url-list.txt b/tests/manual/network_remote_stresstest/url-list.txt index 3d6d7a9..edbf7e1 100644 --- a/tests/manual/network_remote_stresstest/url-list.txt +++ b/tests/manual/network_remote_stresstest/url-list.txt @@ -37,13 +37,11 @@ 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://public.wisekey.com/crt/owgrgaca.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://www.certicamara.com/ac_offline_raiz_certicamara.crt http://fedir.comsign.co.il/cacert/ComsignCA.crt http://fedir.comsign.co.il/cacert/ComsignSecuredCA.crt http://crl.pki.wellsfargo.com/wsprca.crt -- cgit v0.12 From bd7da8cebf1eabb99a80a5de90bfc1aa15a9e5b9 Mon Sep 17 00:00:00 2001 From: Thiago Macieira Date: Fri, 16 Apr 2010 16:18:38 +0200 Subject: Increase the timeout for the QNAM getter test to 30 seconds --- .../network_remote_stresstest/tst_network_remote_stresstest.cpp | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tests/manual/network_remote_stresstest/tst_network_remote_stresstest.cpp b/tests/manual/network_remote_stresstest/tst_network_remote_stresstest.cpp index 2f0bc2c..90a95e7 100644 --- a/tests/manual/network_remote_stresstest/tst_network_remote_stresstest.cpp +++ b/tests/manual/network_remote_stresstest/tst_network_remote_stresstest.cpp @@ -468,15 +468,15 @@ void tst_NetworkRemoteStressTest::namRemoteGet() replies.append(QSharedPointer(r)); } - while (!timeout.hasExpired(10000)) { - QTestEventLoop::instance().enterLoop(10); + 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(10000)) { + if (timeout.hasExpired(30000)) { for (int j = 0; j < replies.size(); ++j) if (!replies[j]->isFinished()) qDebug() << "Request" << replies[j]->url() << "not finished"; -- cgit v0.12 From 10078e4593c369a460a170bef1bc74a55ba3b2e2 Mon Sep 17 00:00:00 2001 From: Oswald Buddenhagen Date: Wed, 7 Apr 2010 10:53:37 +0200 Subject: don't add -unix to the qmake command line it is redundant now and causes warnings from qmake Reviewed-by: mariusSO --- tools/configure/configureapp.cpp | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/configure/configureapp.cpp b/tools/configure/configureapp.cpp index dfd1196..687f8a1 100644 --- a/tools/configure/configureapp.cpp +++ b/tools/configure/configureapp.cpp @@ -1527,7 +1527,6 @@ void Configure::applySpecSpecifics() dictionary[ "QT_ICONV" ] = "no"; dictionary["DECORATIONS"] = "default windows styled"; - dictionary[ "QMAKEADDITIONALARGS" ] = "-unix"; } } -- cgit v0.12 From d7bfacf05545c409943a745a75051839747c87ca Mon Sep 17 00:00:00 2001 From: Oswald Buddenhagen Date: Fri, 9 Apr 2010 15:05:49 +0200 Subject: remove ability to use break() a block outside any loop it is a completely bizarre feature which is nowhere documented and no justification for it is provided anywhere. Reviewed-by: mariusSO --- qmake/project.cpp | 2 -- 1 file changed, 2 deletions(-) diff --git a/qmake/project.cpp b/qmake/project.cpp index 764264f..249ea67 100644 --- a/qmake/project.cpp +++ b/qmake/project.cpp @@ -2516,8 +2516,6 @@ QMakeProject::doProjectTest(QString func, QList args_list, QMapcause_break = true; - else if(!scope_blocks.isEmpty()) - scope_blocks.top().ignore = true; else fprintf(stderr, "%s:%d unexpected break()\n", parser.file.toLatin1().constData(), parser.line_no); -- cgit v0.12 From 7ebc1a7a3f5212c7426c1c9e6a1275bb293e628c Mon Sep 17 00:00:00 2001 From: Oswald Buddenhagen Date: Wed, 7 Apr 2010 11:53:49 +0200 Subject: do not expand variables in read()'s file name it is positively backwards to apply any expansions at such a low level - they have already been applied where necessary. Reviewed-by: mariusSO --- qmake/project.cpp | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/qmake/project.cpp b/qmake/project.cpp index 249ea67..b604453 100644 --- a/qmake/project.cpp +++ b/qmake/project.cpp @@ -1245,8 +1245,7 @@ QMakeProject::read(const QString &file, QMap &place) reset(); const QString oldpwd = qmake_getpwd(); - QString filename = Option::fixPathToLocalOS(file); - doVariableReplace(filename, place); + QString filename = Option::fixPathToLocalOS(file, false); bool ret = false, using_stdin = false; QFile qfile; if(!strcmp(filename.toLatin1(), "-")) { -- cgit v0.12 From 0ab8fabe3d36f752ce7fdcc0d7e9fe9a4f03e928 Mon Sep 17 00:00:00 2001 From: Thiago Macieira Date: Sat, 17 Apr 2010 12:20:16 +0200 Subject: Fix mismatched import declarations --- src/script/api/qscriptengine.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/script/api/qscriptengine.cpp b/src/script/api/qscriptengine.cpp index 13d863e..7e83277 100644 --- a/src/script/api/qscriptengine.cpp +++ b/src/script/api/qscriptengine.cpp @@ -1511,7 +1511,7 @@ void QScriptEnginePrivate::detachAllRegisteredScriptStrings() #ifndef QT_NO_REGEXP -extern QString qt_regexp_toCanonical(const QString &, QRegExp::PatternSyntax); +Q_DECL_IMPORT extern QString qt_regexp_toCanonical(const QString &, QRegExp::PatternSyntax); JSC::JSValue QScriptEnginePrivate::newRegExp(JSC::ExecState *exec, const QRegExp ®exp) { -- cgit v0.12 From affd317ed4f527e9fe80b084d0c4379d842526c8 Mon Sep 17 00:00:00 2001 From: Thiago Macieira Date: Sat, 17 Apr 2010 12:24:24 +0200 Subject: Autotest: update to the new values for the locale --- tests/auto/qlocale/tst_qlocale.cpp | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) 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() -- cgit v0.12 From 14845c8f3bba8437a89fa0843a884a5bdd2ad07f Mon Sep 17 00:00:00 2001 From: Thiago Macieira Date: Sat, 17 Apr 2010 12:36:54 +0200 Subject: Autotest: increase wait time to 3s on Windows to bypass 2s-granularity limitation --- tests/auto/qfileinfo/tst_qfileinfo.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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; -- cgit v0.12