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