From nobody Tue Apr 1 14:47:19 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6704E1A0A13 for ; Tue, 1 Apr 2014 14:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6s0GbNmzGbUl for ; Tue, 1 Apr 2014 14:47:06 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) by ietfa.amsl.com (Postfix) with ESMTP id 81BEA1A089A for ; Tue, 1 Apr 2014 14:47:06 -0700 (PDT) X-ASG-Debug-ID: 1396388818-06daaa1bd8b9e90001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id kde1g9EInsUE8APK for ; Tue, 01 Apr 2014 17:46:58 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Apr 2014 17:47:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CF4DF3.F4C3F120" Date: Tue, 1 Apr 2014 17:47:18 -0400 X-ASG-Orig-Subj: RE: [core] draft-rahman-core-sleepy-05 Message-ID: In-Reply-To: <5FFC27BC1AFF41EF9FECCCAAA09DDA8F@WeiGengyuPC> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] draft-rahman-core-sleepy-05 Thread-Index: Ac9NwyHJfTd8HxCQTvad+qOg3XjXygAMAJVQ References: <146BA183A28B4C6DBF8EA90D49B5724C@WeiGengyuPC> <24D85E520FCE4FD0AF1A451A102FA5FB@WeiGengyuPC> <5FFC27BC1AFF41EF9FECCCAAA09DDA8F@WeiGengyuPC> From: "Rahman, Akbar" To: "weigengyu" X-OriginalArrivalTime: 01 Apr 2014 21:47:19.0741 (UTC) FILETIME=[F4DADED0:01CF4DF3] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1396388818 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.4497 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: http://mailarchive.ietf.org/arch/msg/core/vyYnnHBMBXgOv6Iua5KTHfKm7p8 Cc: core@ietf.org Subject: Re: [core] draft-rahman-core-sleepy-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 21:47:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CF4DF3.F4C3F120 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR2VuZ3l1LA0KDQogDQoNCiANCg0KVGhhbmsgeW91IGZvciB5b3VyIGZlZWRiYWNrLiAgDQoN CiANCg0KIA0KDQo+SWYgdGhlIHNlbnNvciBoYXMgcmVnaXN0ZXJlZCBpdHMgc2xlZXB5IG1vZGUs IHRoZSBwcm94eSBjb3VsZCBnaXZlIHRoaXMga25vd2xlZGdlIHRvIHRoZSBjbGllbnQgaW4gdGhl IHJlc3BvbnNlLiANCg0KPlRoZSBDb250ZW50IHdpdGhpbiB0aGUgcmVzcG9uc2UgbWF5IGJlIGV4 dGVuZGVkIHRvIGNvdmVyIHRocmVlLXN0YXRlIHNlcnZlci4NCg0KIA0KDQpPa2F5LCBidXQgSSBz dGlsbCBkb27igJl0IHNlZSB0aGUgdmFsdWUgb2YgdGhlIHRoaXJkIHN0YXRlIChyZWNlaXZlLW9u bHkpIGZyb20gYSBDb0FQIHBvaW50IG9mIHZpZXc/ICBJIGRvIHVuZGVyc3RhbmQgaXQgZnJvbSBh IHJhZGlvIHBvaW50IG9mIHZpZXcsIGJ1dCB0aGF0IHNob3VsZCBwZXJoYXBzIGJlIGRlY291cGxl ZCBmcm9tIENvQVAgYXBwbGljYXRpb24gaWYgdGhlcmUgaXMgbm90aGluZyBpbiBDb0FQIHRoYXQg aXMgZXhwbGljaXRseSBpbXBhY3RlZC4NCg0KIA0KDQogDQoNCkFrYmFyDQoNCiANCg0KIA0KDQpG cm9tOiB3ZWlnZW5neXUgW21haWx0bzp3ZWlnZW5neXVAYnVwdC5lZHUuY25dIA0KU2VudDogVHVl c2RheSwgQXByaWwgMDEsIDIwMTQgMTE6NTcgQU0NClRvOiBSYWhtYW4sIEFrYmFyDQpTdWJqZWN0 OiBSZTogW2NvcmVdIGRyYWZ0LXJhaG1hbi1jb3JlLXNsZWVweS0wNQ0KDQogDQoNCkhpIEFrYmFy LCANCg0KIA0KDQo+PkluIG91ciByZXNlYXJjaGluZyB3b3JrLCB0aGUgQ29BUCBzZXJ2ZXIgaGFz IHRocmVlIHdvcmtpbmcgbW9kZXM6IGFjdGl2ZSwgcmVjZWl2ZS1vbmx5LCBhbmQgc2xlZXAuDQoN Cj4+YWN0aXZlIG1vZGU6IHRoZSBzZXJ2ZXIgY2FuIHNlbmQgYW5kIHJlY2VpdjsNCg0KPj5yZWNl aXZlLW9ubHkgbW9kZTogdGhlIHNlcnZlciBjYW4gcmVjZWl2ZSwgbm90IHNlbmQ7DQoNCj4+c2xl ZXAgbW9kZTogdGhlIHNlcnZlciBjYW4gbmVpdGhlciBzZW5kIG5vciByZWNlaXZlLg0KDQogDQoN Cj5UaGlzIGlzIGludGVyZXN0aW5nLiAgQnV0LCB3aGF0IGlzIHRoZSBtYWluIGJlbmVmaXQgb2Yg dGhlIHJlY2VpdmUtb25seSBtb2RlPyAgDQoNCkkgaGF2ZSBqdXN0IGdvdCB0aGUgcmVxdWlyZW1l bnRzIG9mIHR3by1zdGF0ZSBzZXJ2ZXIgYW5kIHRocmVlLXN0YXRlIHNlcnZlci4gDQoNClRoZSBy ZWNlaXZlLW9ubHkgbWF5IHNhdmUgcG93ZXIgY29tcGFyZWQgdG8gYWN0aXZlIG1vZGUuDQoNClRo ZSBzZW5zb3Igd29ya3MgaW4gYSBmaXhlZCBpbnRlcnZhbCBhbmQgY2FuIGdpdmUgcmVzcG9uc2Vz IGF0IGEgdGltZS4gIA0KDQogDQoNCiANCg0KPlRoYXQgaXMsIHNpbmNlIHRoZSBDb0FQIG1vZGVs IGlzIHJlcXVlc3QvcmVzcG9uc2UsIHdoYXQgaXMgdGhlIHZhbHVlIG9mIGJlaW5nIGFibGUgdG8g c2VuZCB0aGUgcmVxdWVzdCAoZS5nLiBHRVQpIHdpdGhvdXQga25vd2luZyB0aGUgcmVzcG9uc2U/ DQoNClRoZSBmaXJzdCByZXF1ZXN0IGZyb20gdGhlIGNsaWVudCBkb2VzIG5vdCBrbm93IHRoaXMu IFRoZSBjbGllbnQgc2VuZCDigJxHRVTigJ0gYXMgdXN1YWwuDQoNCiANCg0KV2l0aG91dCB0aGUg c2Vuc29ycyByZWdpc3RyYXRpb24gaW5mb3JtYXRpb24sIHRoZSBwcm94eSB0cmVhdCBpdCBhcyBh IG1vcm1hbCByZXF1ZXN0Lg0KDQpJZiB0aGUgc2Vuc29yIGhhcyByZWdpc3RlcmVkIGl0cyBzbGVl cHkgbW9kZSwgdGhlIHByb3h5IGNvdWxkIGdpdmUgdGhpcyBrbm93bGVkZ2UgdG8gdGhlIGNsaWVu dCBpbiB0aGUgcmVzcG9uc2UuIA0KDQpUaGUgQ29udGVudCB3aXRoaW4gdGhlIHJlc3BvbnNlIG1h eSBiZSBleHRlbmRlZCB0byBjb3ZlciB0aHJlZS1zdGF0ZSBzZXJ2ZXIuDQoNCiANCg0KPj5Tbywg aW4gdGhlIHNpdHVhdGlvbiB3aGVuIHRoZSBDb0FQIHNlcnZlciBpcyBpbiByZWNlaXZlLW9ubHkg bW9kZSwgdGhlIHByb3h5IHNob3VsZCBmb3J3YXJkIHRoZSByZXF1ZXN0IHRvIHRoZSBzZXJ2ZXIu IA0KDQo+PlRoZSBDb0FQIHNlcnZlciBjb3VsZCByZWNlaXZlIHRoZSByZXF1ZXN0IGFuZCBnaXZl IGEgIHJlc3BvbnNlIGFmdGVyIGEgd2hpbGUuIA0KDQo+PlRoZSBwcm94eSBuZWVkIHRvIHJldHVy biDigJxXYWl0aW5nIGZvciBhIHdoaWxl4oCdIGluc3RlYWQgb2Yg4oCcVGhlIFJldHJ5IOKAk0Fm dGVy4oCdLiANCg0KIA0KDQo+SXMg4oCcV2FpdGluZyBmb3IgYSB3aGlsZeKAnSBhIG5ldyBDb0FQ IFJlc3BvbnNlIGNvZGUgdGhhdCBuZWVkcyB0byBiZSBkZWZpbmVkPw0KDQogDQoNCkkgdGhpbmsg 4oCcVGhlIFJldHJ5IC1BZnRlcuKAnSBtZWFucyDigJx3YWl0IGZvciBhIHdoaWxlIGFuZCB0aGVu IHJldHJ5LuKAnSANCg0KU28sIHRoZSBleHRlbnNpb24gaXMgdG8gcHJvdmlkZSB3aGV0aGVyIOKA nHdhaXQgZm9yIGEgd2hpbGXigJ0gb3Ig4oCcd2FpdCBmb3IgYSB3aGlsZSBhbmQgdGhlbiByZXRy eS7igJ0gDQoNCkl0IGNvdWxkIGJlIGEgbmV3IHJlc3BvbnNlIGNvZGUuIA0KDQogDQoNClJlZ2Fy ZHMsIA0KDQogDQoNCkdlbmd5dQ0KDQogDQoNCk5ldHdvcmsgVGVjaG5vbG9neSBDZW50ZXINCg0K U2Nob29sIG9mIENvbXB1dGVyDQoNCkJlaWppbmcgVW5pdmVyc2l0eSBvZiBQb3N0cyBhbmQgVGVs ZWNvbW11bmljYXRpb25zDQoNCiANCg0KIA0KDQpGcm9tOiBSYWhtYW4sIEFrYmFyIDxtYWlsdG86 QWtiYXIuUmFobWFuQEludGVyRGlnaXRhbC5jb20+ICANCg0KU2VudDogTW9uZGF5LCBNYXJjaCAz MSwgMjAxNCA4OjI3IFBNDQoNClRvOiB3ZWlnZW5neXUgPG1haWx0bzp3ZWlnZW5neXVAYnVwdC5l ZHUuY24+ICANCg0KQ2M6IGNvcmVAaWV0Zi5vcmcgDQoNClN1YmplY3Q6IFJFOiBbY29yZV0gZHJh ZnQtcmFobWFuLWNvcmUtc2xlZXB5LTA1DQoNCiANCg0KSGkgV2VpZ2VuZ3l1LA0KDQogDQoNCiAN Cg0KIA0KDQpUaGFuayB5b3UgZm9yIHRoZSBnb29kIHF1ZXN0aW9ucy4gIEZvbGxvd2luZyBpcyBt eSBmZWVkYmFjazoNCg0KIA0KDQogDQoNCj5TbywgaW4gdGhlIHNpdHVhdGlvbiB3aGVuIHRoZSBD b0FQIHNlcnZlciBpcyBpbiByZWNlaXZlLW9ubHkgbW9kZSwgdGhlIHByb3h5IHNob3VsZCBmb3J3 YXJkIHRoZSByZXF1ZXN0IHRvIHRoZSBzZXJ2ZXIuIA0KDQo+VGhlIENvQVAgc2VydmVyIGNvdWxk IHJlY2VpdmUgdGhlIHJlcXVlc3QgYW5kIGdpdmUgYSAgcmVzcG9uc2UgYWZ0ZXIgYSB3aGlsZS4g DQoNCj5UaGUgcHJveHkgbmVlZCB0byByZXR1cm4g4oCcV2FpdGluZyBmb3IgYSB3aGlsZeKAnSBp bnN0ZWFkIG9mIOKAnFRoZSBSZXRyeSDigJNBZnRlcuKAnS4gDQoNCiANCg0KSXMg4oCcV2FpdGlu ZyBmb3IgYSB3aGlsZeKAnSBhIG5ldyBDb0FQIFJlc3BvbnNlIGNvZGUgdGhhdCBuZWVkcyB0byBi ZSBkZWZpbmVkPw0KDQogDQoNCiANCg0KIA0KDQo+SW4gb3VyIHJlc2VhcmNoaW5nIHdvcmssIHRo ZSBDb0FQIHNlcnZlciBoYXMgdGhyZWUgd29ya2luZyBtb2RlczogYWN0aXZlLCByZWNlaXZlLW9u bHksIGFuZCBzbGVlcC4NCg0KPmFjdGl2ZSBtb2RlOiB0aGUgc2VydmVyIGNhbiBzZW5kIGFuZCBy ZWNlaXY7DQoNCj5yZWNlaXZlLW9ubHkgbW9kZTogdGhlIHNlcnZlciBjYW4gcmVjZWl2ZSwgbm90 IHNlbmQ7DQoNCj5zbGVlcCBtb2RlOiB0aGUgc2VydmVyIGNhbiBuZWl0aGVyIHNlbmQgbm9yIHJl Y2VpdmUuDQoNCiANCg0KVGhpcyBpcyBpbnRlcmVzdGluZy4gIEJ1dCwgd2hhdCBpcyB0aGUgbWFp biBiZW5lZml0IG9mIHRoZSByZWNlaXZlLW9ubHkgbW9kZT8gIFRoYXQgaXMsIHNpbmNlIHRoZSBD b0FQIG1vZGVsIGlzIHJlcXVlc3QvcmVzcG9uc2UsIHdoYXQgaXMgdGhlIHZhbHVlIG9mIGJlaW5n IGFibGUgdG8gc2VuZCB0aGUgcmVxdWVzdCAoZS5nLiBHRVQpIHdpdGhvdXQga25vd2luZyB0aGUg cmVzcG9uc2U/DQoNCiANCg0KIA0KDQogDQoNCkJlc3QgUmVnYXJkcywNCg0KIA0KDQogDQoNCkFr YmFyDQoNCiANCg0KIA0KDQogDQoNCkZyb206IHdlaWdlbmd5dSBbbWFpbHRvOndlaWdlbmd5dUBi dXB0LmVkdS5jbl0gDQpTZW50OiBNb25kYXksIE1hcmNoIDMxLCAyMDE0IDU6NTcgQU0NClRvOiBS YWhtYW4sIEFrYmFyDQpDYzogY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtjb3JlXSBkcmFm dC1yYWhtYW4tY29yZS1zbGVlcHktMDUNCg0KIA0KDQpIaSBBa2JhaSwgDQoNCiANCg0KSSB3b3Vs ZCBsaWtlIHRvIG1ha2UgbXkgcXVlc3Rpb24gY2xlYXIuDQoNCiANCg0KSW4geW91ciB3b3JrLCDi gJxFbmhhbmNlZCBTbGVlcHkgTm9kZSBTdXBwb3J0IGZvciBDb0FQIElFVEYgODcsIEp1bHkgMjAx MywgU2xlZXB5IE5vZGUgUGVyZm9ybWFuY2UgQW5hbHlzaXPigJ0NCg0KaW4gdGhlIFBQVCBwYWdl IG9mIOKAnFJldmVyc2UgUHJveHkgRmVhdHVyZXMgZm9yIFNsZWVweSBOb2RlIFN1cHBvcnTigJ0g DQoNCnRoZXJlIGFyZSBmb2xsb3dpbmcgZGVzY3JpcHRpb25zOiANCg0K4oCcU2xlZXAtYXdhcmUg Q29BUCA1LjAzIFJlc3BvbnNlIENhcGFiaWxpdHkgDQoNCklmIENvQVAgcmVxdWVzdCB0byBhIHNs ZWVwaW5nIHNlcnZlciBpcyByZWNlaXZlZCAoYW5kIHRoZXJlIGlzIG5vIHZhbGlkIGNhY2hlIGZv ciB0aGF0IHJlcXVlc3QpLCBwcm94eSByZXR1cm5zIGEg4oCYNS4wMyBSZXRyeS1BZnRlcuKAmSBy ZXNwb25zZSB0byBjbGllbnQgIA0KDQo1LjAzIGNvbnRhaW5zIGEgdGltZXN0YW1wIGluZGljYXRp bmcgd2hlbiB0aGUgc2V2ZXIgd2lsbCB3YWtlIGJhY2sgdXAgKHRpbWVzdGFtcCBkZWxpdmVyZWQg aW4gQ29BUCBtYXhBZ2Ugb3B0aW9uKSDigJwgDQoNCiANCg0KSW4gb3VyIHJlc2VhcmNoaW5nIHdv cmssIHRoZSBDb0FQIHNlcnZlciBoYXMgdGhyZWUgd29ya2luZyBtb2RlczogYWN0aXZlLCByZWNl aXZlLW9ubHksIGFuZCBzbGVlcC4NCg0KYWN0aXZlIG1vZGU6IHRoZSBzZXJ2ZXIgY2FuIHNlbmQg YW5kIHJlY2VpdjsNCg0KcmVjZWl2ZS1vbmx5IG1vZGU6IHRoZSBzZXJ2ZXIgY2FuIHJlY2VpdmUs IG5vdCBzZW5kOw0KDQpzbGVlcCBtb2RlOiB0aGUgc2VydmVyIGNhbiBuZWl0aGVyIHNlbmQgbm9y IHJlY2VpdmUuDQoNCiANCg0KU28sIGluIHRoZSBzaXR1YXRpb24gd2hlbiB0aGUgQ29BUCBzZXJ2 ZXIgaXMgaW4gcmVjZWl2ZS1vbmx5IG1vZGUsIHRoZSBwcm94eSBzaG91bGQgZm9yd2FyZCB0aGUg cmVxdWVzdCB0byB0aGUgc2VydmVyLiANCg0KVGhlIENvQVAgc2VydmVyIGNvdWxkIHJlY2VpdmUg dGhlIHJlcXVlc3QgYW5kIGdpdmUgYSAgcmVzcG9uc2UgYWZ0ZXIgYSB3aGlsZS4gDQoNClRoZSBw cm94eSBuZWVkIHRvIHJldHVybiDigJxXYWl0aW5nIGZvciBhIHdoaWxl4oCdIGluc3RlYWQgb2Yg 4oCcVGhlIFJldHJ5IOKAk0FmdGVy4oCdLiANCg0KIA0KDQpUaGlzIG1heSBiZSBkdWUgdG8gaG93 IHdlIGRlZmluZSB0aGUgc2xlZXB5IG5vZGUuIA0KDQpBbmQsIHRoZSByZXF1aXJlbWVudCBpcyB0 byBjb25zaWRlciB0aHJlZSB3b3JraW5nIG1vZGVzIG9mIENvQVAgc2VydmVyIHdoZW4gaGFuZGxp bmcgc2xlZXB5IG5vZGVzLiANCg0KIA0KDQppZiB0aGUgQ29BUCBDbGllbnQgZ2V0IHRoaXMga25v d2xlZGdlIGl0IG1heSBiZSBnb29kIHRvIGdldCBiZXR0ZXIgdGhlIGNvbW11bmljYXRpb24gZWZm aWNpZW5jeSBpbiBDb1JFIG5ldHdvcmtzLg0KDQogDQoNClJlZ2FyZHMsIA0KDQogDQoNCkdlbmd5 dSANCg0KIA0KDQpOZXR3b3JrIFRlY2hvbm9sZ3kgQ2VudGVyDQoNClNjaG9vbCBvZiBDb21wdXRl cg0KDQpCZWlqaW5nIFVuaXZlcnNpdHkgb2YgUG9zdHMgYW5kIFRlbGVjb21tdW5pY2F0aW9ucw0K DQogDQoNCkZyb206IHdlaWdlbmd5dSA8bWFpbHRvOndlaWdlbmd5dUBidXB0LmVkdS5jbj4gIA0K DQpTZW50OiBGcmlkYXksIE1hcmNoIDI4LCAyMDE0IDExOjAzIEFNDQoNClRvOiBBa2Jhci5SYWht YW5ASW50ZXJEaWdpdGFsLmNvbSANCg0KQ2M6IGNvcmVAaWV0Zi5vcmcgDQoNClN1YmplY3Q6IFJl OiBbY29yZV0gZHJhZnQtcmFobWFuLWNvcmUtc2xlZXB5LTA1DQoNCiANCg0KSGkgQWtiYXIsDQoN CiANCg0KQWJvdXQgZHJhZnQtcmFobWFuLWNvcmUtc2xlZXB5LTA1IEVuaGFuY2VkIFNsZWVweSBO b2RlIFN1cHBvcnQgZm9yIENvQVAsIEkgaGF2ZSBhIHF1ZXN0aW9uLiANCg0KIA0KDQpEZWZpbmlu ZyBTbGVlcCBQYXJhIHRvIHRhY2tsZSBzbGVlcCBub2RlcyBpbiBDb1JFIG5ldHdvcmtzIGlzIGFu IGVzc2VudGlhbCB3b3JrIGFuZCBpbXBvcnRhbnQuIA0KDQogDQoNCkJ5IHRoZSBGaWd1cmUgMzog UHJvdG90eXBlIENvbmZpZ3VyYXRpb24sDQoNCnlvdSBwcm9wb3NlIHRvIGFkZCBSRCBTbGVlcCBQ YXJhIGludG8gcHJveHkgKENvQVAgUmV2ZXJzZSBQcm94eSkuIA0KDQogDQoNCklzIGl0IHBvc3Np YmxlIHRvIHRyYW5zZmVyIFNsZWVwIFBhcmEgaW50byBDb0FQIENsaWVudD8gDQoNCkl0IGlzIHRo ZSBDb0FQIENsaWVudCB0byBpbnRpYWwgZWFjaCBDb0FQIHJlcXVlc3QsICANCg0KYW5kIHRoZSBD b0FQIENsaWVudCBtYXkgZ2V0IHRoZSBpbmZvbWF0aW9ucyBhYm91dCB0aGUgcmVzb3VyY2VzIGZy b20gdGhlIEFDSyBvZiB0aGUgZmlyc3QgYWNjZXNzLCBpZiBwb3NzaWJsZS4gDQoNCiANCg0KV2l0 aCB0aGlzIGtub3dsZWRnZSwgdGhlIENvQVAgY2xpZW50IGNvdWxkIGNob29zZSB0aGUgYWRxdWF0 ZSBjaGFuY2UgdG8gc2VuZCByZXF1ZXN0LCANCg0KYW5kIGVzdGltYXRlIHRoZSBkdXJhdGlvbiB0 byB3YWl0IGZvciByZXNwb25zZS4gIA0KDQogDQoNCiANCg0KUmVnYXJkcywNCg0KIA0KDQpHZW5n eXUNCg0KIA0KDQpOZXR3b3JrIFRlY2hub2xvZ3kgQ2VudGVyDQoNClNjaG9vbCBvZiBDb21wdXRl cg0KDQpCZWlqaW5nIFVuaXZlcnNpdHkgb2YgUG9zdHMgYW5kIFRlbGVjb21tdW5pY2F0aW9ucy4N Cg0KIA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY29yZSBtYWlsaW5nIGxpc3QNCmNv cmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0K DQo= ------_=_NextPart_001_01CF4DF3.F4C3F120 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2VudHVyeTsNCglwYW5vc2UtMToyIDQgNiA0IDUgNSA1IDIgMyA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2VudHVyeTsNCglwYW5vc2UtMToyIDQgNiA0IDUg NSA1IDIgMyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2Ut MToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9t YTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBT dHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05v cm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OlNpbVN1bjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D Tjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OlNpbVN1bjsNCgltc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4 LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ047fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi Ow0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVT IGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SGkgR2VuZ3l1LDxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPlRoYW5rIHlvdSBmb3IgeW91ciBmZWVkYmFjay7CoCA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMnPiZndDtJZiB0aGUgc2Vuc29yIGhhcyBy ZWdpc3RlcmVkIGl0cyBzbGVlcHkgbW9kZSwgdGhlIHByb3h5IGNvdWxkIGdpdmUgdGhpcyBrbm93 bGVkZ2UgdG8gdGhlIGNsaWVudCBpbiB0aGUgcmVzcG9uc2UuIDwvc3Bhbj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6 YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMnPiZndDtUaGUg Q29udGVudCB3aXRoaW4gdGhlIHJlc3BvbnNlIG1heSBiZSBleHRlbmRlZCB0byBjb3ZlciB0aHJl ZS1zdGF0ZSBzZXJ2ZXIuPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Pa2F5LCBidXQgSSBzdGlsbCBkb27igJl0 IHNlZSB0aGUgdmFsdWUgb2YgdGhlIHRoaXJkIHN0YXRlIChyZWNlaXZlLW9ubHkpIGZyb20gYSBD b0FQIHBvaW50IG9mIHZpZXc/wqAgSSBkbyB1bmRlcnN0YW5kIGl0IGZyb20gYSByYWRpbyBwb2lu dCBvZiB2aWV3LCBidXQgdGhhdCBzaG91bGQgcGVyaGFwcyBiZSBkZWNvdXBsZWQgZnJvbSBDb0FQ IGFwcGxpY2F0aW9uIGlmIHRoZXJlIGlzIG5vdGhpbmcgaW4gQ29BUCB0aGF0IGlzIGV4cGxpY2l0 bHkgaW1wYWN0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QWtiYXI8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9 J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTJz4gd2VpZ2VuZ3l1IFttYWlsdG86d2VpZ2VuZ3l1QGJ1cHQuZWR1LmNuXSA8YnI+PGI+ U2VudDo8L2I+IFR1ZXNkYXksIEFwcmlsIDAxLCAyMDE0IDExOjU3IEFNPGJyPjxiPlRvOjwvYj4g UmFobWFuLCBBa2Jhcjxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtjb3JlXSBkcmFmdC1yYWhtYW4t Y29yZS1zbGVlcHktMDU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyc+SGkgQWtiYXIsIDxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjazttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjpibGFjayc+Jmd0OyZndDtJbiBvdXIgcmVzZWFyY2hpbmcgd29yaywgdGhlIENv QVAgc2VydmVyIGhhcyB0aHJlZSB3b3JraW5nIG1vZGVzOiBhY3RpdmUsIHJlY2VpdmUtb25seSwg YW5kIHNsZWVwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiZn dDsmZ3Q7YWN0aXZlIG1vZGU6IHRoZSBzZXJ2ZXIgY2FuIHNlbmQgYW5kIHJlY2Vpdjs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4mZ3Q7Jmd0O3JlY2VpdmUtb25s eSBtb2RlOiB0aGUgc2VydmVyIGNhbiByZWNlaXZlLCBub3Qgc2VuZDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4mZ3Q7Jmd0O3NsZWVwIG1vZGU6IHRoZSBzZXJ2 ZXIgY2FuIG5laXRoZXIgc2VuZCBub3IgcmVjZWl2ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMnPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMzc2MDky O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTJz4mZ3Q7VGhpcyBpcyBpbnRlcmVzdGluZy4mbmJz cDsgQnV0LCB3aGF0IGlzIHRoZSBtYWluIGJlbmVmaXQgb2YgdGhlIHJlY2VpdmUtb25seSBtb2Rl PyZuYnNwOyA8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMnPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjazttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyc+SSBoYXZlIGp1c3QgZ290IHRoZSByZXF1aXJlbWVudHMgb2YgdHdvLXN0 YXRlIHNlcnZlciBhbmQgdGhyZWUtc3RhdGUgc2VydmVyLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMnPlRoZSByZWNlaXZlLW9ubHkgbWF5IHNhdmUgcG93ZXIgY29tcGFyZWQgdG8gYWN0aXZlIG1v ZGUuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNr O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTJz5UaGUgc2Vuc29yIHdvcmtzIGluIGEgZml4ZWQg aW50ZXJ2YWwgYW5kIGNhbiBnaXZlIHJlc3BvbnNlcyBhdCBhIHRpbWUuJm5ic3A7IDxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjazttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTJz4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzM3NjA5Mjtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyc+Jmd0O1RoYXQgaXMsIHNpbmNlIHRoZSBDb0FQIG1v ZGVsIGlzIHJlcXVlc3QvcmVzcG9uc2UsIHdoYXQgaXMgdGhlIHZhbHVlIG9mIGJlaW5nIGFibGUg dG8gc2VuZCB0aGUgcmVxdWVzdCAoZS5nLiBHRVQpIHdpdGhvdXQga25vd2luZyB0aGUgcmVzcG9u c2U/PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTJz48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTJz5UaGUgZmlyc3QgcmVxdWVzdCBmcm9tIHRoZSBjbGllbnQgZG9l cyBub3Qga25vdyB0aGlzLiBUaGUgY2xpZW50IHNlbmQg4oCcR0VU4oCdIGFzIHVzdWFsLjwvc3Bh bj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMnPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6 YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMnPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyc+V2l0aG91dCB0aGUgc2Vuc29ycyByZWdpc3RyYXRpb24gaW5mb3JtYXRpb24sIHRo ZSBwcm94eSB0cmVhdCBpdCBhcyBhIG1vcm1hbCByZXF1ZXN0Ljwvc3Bhbj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6 YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V Uyc+SWYgdGhlIHNlbnNvciBoYXMgcmVnaXN0ZXJlZCBpdHMgc2xlZXB5IG1vZGUsIHRoZSBwcm94 eSBjb3VsZCBnaXZlIHRoaXMga25vd2xlZGdlIHRvIHRoZSBjbGllbnQgaW4gdGhlIHJlc3BvbnNl LiA8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9t YSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTJz48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2s7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMnPlRoZSBDb250ZW50IHdpdGhpbiB0aGUgcmVzcG9uc2Ug bWF5IGJlIGV4dGVuZGVkIHRvIGNvdmVyIHRocmVlLXN0YXRlIHNlcnZlci48L3NwYW4+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTJz48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4mZ3Q7Jmd0O1NvLCBpbiB0aGUgc2l0dWF0aW9uIHdo ZW4gdGhlIENvQVAgc2VydmVyIGlzIGluIHJlY2VpdmUtb25seSBtb2RlLCB0aGUgcHJveHkgc2hv dWxkIGZvcndhcmQgdGhlIHJlcXVlc3QgdG8gdGhlIHNlcnZlci4gPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+Jmd0OyZndDtUaGUgQ29BUCBzZXJ2ZXIgY291bGQg cmVjZWl2ZSB0aGUgcmVxdWVzdCBhbmQgZ2l2ZSBhJm5ic3A7IHJlc3BvbnNlIGFmdGVyIGEgd2hp bGUuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiZndDsmZ3Q7 VGhlIHByb3h5IG5lZWQgdG8gcmV0dXJuIDwvc3Bhbj48c3BhbiBsYW5nPVpILUNOIHN0eWxlPSdj b2xvcjpibGFjayc+4oCcPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5XYWl0aW5nIGZvciBhIHdoaWxlPC9zcGFuPjxzcGFu IGxhbmc9WkgtQ04gc3R5bGU9J2NvbG9yOmJsYWNrJz7igJ08L3NwYW4+PHNwYW4gc3R5bGU9J2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiBpbnN0ZWFkIG9m IDwvc3Bhbj48c3BhbiBsYW5nPVpILUNOIHN0eWxlPSdjb2xvcjpibGFjayc+4oCcPC9zcGFuPjxz cGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNr Jz5UaGUgUmV0cnkgPC9zcGFuPjxzcGFuIGxhbmc9WkgtQ04gc3R5bGU9J2NvbG9yOmJsYWNrJz7i gJM8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6YmxhY2snPkFmdGVyPC9zcGFuPjxzcGFuIGxhbmc9WkgtQ04gc3R5bGU9J2NvbG9yOmJs YWNrJz7igJ08L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6YmxhY2snPi4gPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMzc2 MDkyJz4mZ3Q7SXMgPC9zcGFuPjxzcGFuIGxhbmc9WkgtQ04gc3R5bGU9J2NvbG9yOiMzNzYwOTIn PuKAnDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMzc2MDkyJz5XYWl0aW5nIGZvciBhIHdoaWxlPC9zcGFuPjxzcGFuIGxhbmc9Wkgt Q04gc3R5bGU9J2NvbG9yOiMzNzYwOTInPuKAnTwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMzc2MDkyJz4gYSBuZXcgQ29BUCBSZXNw b25zZSBjb2RlIHRoYXQgbmVlZHMgdG8gYmUgZGVmaW5lZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMnPkkgdGhpbmsg4oCc VGhlIFJldHJ5IC1BZnRlcuKAnSBtZWFucyDigJx3YWl0IGZvciBhIHdoaWxlIGFuZCB0aGVuIHJl dHJ5LuKAnSA8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymxh Y2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMnPlNvLCB0aGUgZXh0ZW5zaW9uIGlzIHRvIHBy b3ZpZGUgd2hldGhlciDigJx3YWl0IGZvciBhIHdoaWxl4oCdIG9yIOKAnHdhaXQgZm9yIGEgd2hp bGUgYW5kIHRoZW4gcmV0cnku4oCdIDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2s7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyc+SXQgY291bGQgYmUg YSBuZXcgcmVzcG9uc2UgY29kZS4gPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjazttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V Uyc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTJz5SZWdhcmRzLCA8L3NwYW4+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTJz48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMn Pkdlbmd5dTwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiI7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMnPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjazttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyc+TmV0d29yayBUZWNobm9sb2d5IENlbnRlcjwvc3Bhbj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMnPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyc+U2Nob29sIG9mIENvbXB1dGVyPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjaztt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTJz5CZWlq aW5nIFVuaXZlcnNpdHkgb2YgUG9zdHMgYW5kIFRlbGVjb21tdW5pY2F0aW9uczwvc3Bhbj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMnPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2s7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMnPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2s7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMnPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlc21va2UnPjxi PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyc+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyc+IDxh IGhyZWY9Im1haWx0bzpBa2Jhci5SYWhtYW5ASW50ZXJEaWdpdGFsLmNvbSIgdGl0bGU9IkFrYmFy LlJhaG1hbkBJbnRlckRpZ2l0YWwuY29tIj5SYWhtYW4sIEFrYmFyPC9hPiA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6 d2hpdGVzbW9rZSc+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTJz5TZW50Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTJz4gTW9uZGF5LCBNYXJjaCAzMSwgMjAxNCA4OjI3IFBNPG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndo aXRlc21va2UnPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V Uyc+VG86PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMnPiA8YSBocmVmPSJtYWlsdG86d2VpZ2VuZ3l1QGJ1cHQuZWR1LmNuIiB0aXRsZT0id2Vp Z2VuZ3l1QGJ1cHQuZWR1LmNuIj53ZWlnZW5neXU8L2E+IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZXNtb2tl Jz48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiI7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMnPkNjOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9t YSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTJz4g PGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciIHRpdGxlPSJjb3JlQGlldGYub3JnIj5jb3Jl QGlldGYub3JnPC9hPiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGVzbW9rZSc+PGI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJs YWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTJz5TdWJqZWN0Ojwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTJz4gUkU6IFtjb3JlXSBkcmFm dC1yYWhtYW4tY29yZS1zbGVlcHktMDU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMnPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkhpIFdlaWdlbmd5dSw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhhbmsgeW91IGZvciB0aGUgZ29vZCBxdWVzdGlvbnMuJm5i c3A7IEZvbGxvd2luZyBpcyBteSBmZWVkYmFjazo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiZndDtT bywgaW4gdGhlIHNpdHVhdGlvbiB3aGVuIHRoZSBDb0FQIHNlcnZlciBpcyBpbiByZWNlaXZlLW9u bHkgbW9kZSwgdGhlIHByb3h5IHNob3VsZCBmb3J3YXJkIHRoZSByZXF1ZXN0IHRvIHRoZSBzZXJ2 ZXIuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiZndDtUaGUg Q29BUCBzZXJ2ZXIgY291bGQgcmVjZWl2ZSB0aGUgcmVxdWVzdCBhbmQgZ2l2ZSBhJm5ic3A7IHJl c3BvbnNlIGFmdGVyIGEgd2hpbGUuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6YmxhY2snPiZndDtUaGUgcHJveHkgbmVlZCB0byByZXR1cm4g4oCcV2FpdGluZyBmb3IgYSB3 aGlsZeKAnSBpbnN0ZWFkIG9mIOKAnFRoZSBSZXRyeSDigJNBZnRlcuKAnS4gPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMzc2MDkyJz5JcyDigJxXYWl0aW5nIGZvciBhIHdoaWxl4oCd IGEgbmV3IENvQVAgUmVzcG9uc2UgY29kZSB0aGF0IG5lZWRzIHRvIGJlIGRlZmluZWQ/PG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0n Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+PG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpi bGFjayc+Jmd0O0luIG91ciByZXNlYXJjaGluZyB3b3JrLCB0aGUgQ29BUCBzZXJ2ZXIgaGFzIHRo cmVlIHdvcmtpbmcgbW9kZXM6IGFjdGl2ZSwgcmVjZWl2ZS1vbmx5LCBhbmQgc2xlZXAuPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+Jmd0O2FjdGl2ZSBtb2RlOiB0 aGUgc2VydmVyIGNhbiBzZW5kIGFuZCByZWNlaXY7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjpibGFjayc+Jmd0O3JlY2VpdmUtb25seSBtb2RlOiB0aGUgc2VydmVyIGNhbiBy ZWNlaXZlLCBub3Qgc2VuZDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJs YWNrJz4mZ3Q7c2xlZXAgbW9kZTogdGhlIHNlcnZlciBjYW4gbmVpdGhlciBzZW5kIG5vciByZWNl aXZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzM3NjA5Mic+VGhpcyBpcyBpbnRlcmVzdGluZy4mbmJzcDsgQnV0LCB3aGF0 IGlzIHRoZSBtYWluIGJlbmVmaXQgb2YgdGhlIHJlY2VpdmUtb25seSBtb2RlPyZuYnNwOyBUaGF0 IGlzLCBzaW5jZSB0aGUgQ29BUCBtb2RlbCBpcyByZXF1ZXN0L3Jlc3BvbnNlLCB3aGF0IGlzIHRo ZSB2YWx1ZSBvZiBiZWluZyBhYmxlIHRvIHNlbmQgdGhlIHJlcXVlc3QgKGUuZy4gR0VUKSB3aXRo b3V0IGtub3dpbmcgdGhlIHJlc3BvbnNlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzM3NjA5Mic+PG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMzc2MDkyJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMzNzYwOTInPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzM3NjA5Mic+QmVzdCBSZWdhcmRz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzM3NjA5Mic+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMzc2MDky Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMzNzYwOTInPkFrYmFyPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+PGRpdiBzdHls ZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2sn PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiB3ZWlnZW5neXUgWzxhIGhyZWY9 Im1haWx0bzp3ZWlnZW5neXVAYnVwdC5lZHUuY24iPm1haWx0bzp3ZWlnZW5neXVAYnVwdC5lZHUu Y248L2E+XSA8YnI+PGI+U2VudDo8L2I+IE1vbmRheSwgTWFyY2ggMzEsIDIwMTQgNTo1NyBBTTxi cj48Yj5Ubzo8L2I+IFJhaG1hbiwgQWtiYXI8YnI+PGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86 Y29yZUBpZXRmLm9yZyI+Y29yZUBpZXRmLm9yZzwvYT48YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBb Y29yZV0gZHJhZnQtcmFobWFuLWNvcmUtc2xlZXB5LTA1PG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 YmxhY2snPkhpIEFrYmFpLCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjpibGFjayc+SSB3b3VsZCBsaWtlIHRvIG1ha2UgbXkgcXVlc3Rpb24gY2xl YXIuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNr Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 YmxhY2snPkluIHlvdXIgd29yaywg4oCcRW5oYW5jZWQgU2xlZXB5IE5vZGUgU3VwcG9ydCBmb3Ig Q29BUCBJRVRGIDg3LCBKdWx5IDIwMTMsIFNsZWVweSBOb2RlIFBlcmZvcm1hbmNlIEFuYWx5c2lz 4oCdPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNr Jz5pbiB0aGUgUFBUIHBhZ2Ugb2Yg4oCcUmV2ZXJzZSBQcm94eSBGZWF0dXJlcyBmb3IgU2xlZXB5 IE5vZGUgU3VwcG9ydOKAnSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6YmxhY2snPnRoZXJlIGFyZSBmb2xsb3dpbmcgZGVzY3JpcHRpb25zOiA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPuKAnFNsZWVw LWF3YXJlIENvQVAgNS4wMyBSZXNwb25zZSBDYXBhYmlsaXR5IDxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+SWYgQ29BUCByZXF1ZXN0IHRvIGEg c2xlZXBpbmcgc2VydmVyIGlzIHJlY2VpdmVkIChhbmQgdGhlcmUgaXMgbm8gdmFsaWQgY2FjaGUg Zm9yIHRoYXQgcmVxdWVzdCksIHByb3h5IHJldHVybnMgYSDigJg1LjAzIFJldHJ5LUFmdGVy4oCZ IHJlc3BvbnNlIHRvIGNsaWVudCZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjUuMDMgY29udGFpbnMgYSB0aW1lc3RhbXAgaW5kaWNh dGluZyB3aGVuIHRoZSBzZXZlciB3aWxsIHdha2UgYmFjayB1cCAodGltZXN0YW1wIGRlbGl2ZXJl ZCBpbiBDb0FQIG1heEFnZSBvcHRpb24pIOKAnCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+SW4gb3VyIHJlc2VhcmNoaW5nIHdvcmss IHRoZSBDb0FQIHNlcnZlciBoYXMgdGhyZWUgd29ya2luZyBtb2RlczogYWN0aXZlLCByZWNlaXZl LW9ubHksIGFuZCBzbGVlcC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6YmxhY2snPmFjdGl2ZSBtb2RlOiB0aGUgc2VydmVyIGNhbiBzZW5kIGFuZCByZWNl aXY7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNr Jz5yZWNlaXZlLW9ubHkgbW9kZTogdGhlIHNlcnZlciBjYW4gcmVjZWl2ZSwgbm90IHNlbmQ7PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5zbGVl cCBtb2RlOiB0aGUgc2VydmVyIGNhbiBuZWl0aGVyIHNlbmQgbm9yIHJlY2VpdmUuPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPlNvLCBp biB0aGUgc2l0dWF0aW9uIHdoZW4gdGhlIENvQVAgc2VydmVyIGlzIGluIHJlY2VpdmUtb25seSBt b2RlLCB0aGUgcHJveHkgc2hvdWxkIGZvcndhcmQgdGhlIHJlcXVlc3QgdG8gdGhlIHNlcnZlci4g PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5U aGUgQ29BUCBzZXJ2ZXIgY291bGQgcmVjZWl2ZSB0aGUgcmVxdWVzdCBhbmQgZ2l2ZSBhJm5ic3A7 IHJlc3BvbnNlIGFmdGVyIGEgd2hpbGUuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjpibGFjayc+VGhlIHByb3h5IG5lZWQgdG8gcmV0dXJuIOKAnFdhaXRp bmcgZm9yIGEgd2hpbGXigJ0gaW5zdGVhZCBvZiDigJxUaGUgUmV0cnkg4oCTQWZ0ZXLigJ0uIDxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNr Jz5UaGlzIG1heSBiZSBkdWUgdG8gaG93IHdlIGRlZmluZSB0aGUgc2xlZXB5IG5vZGUuIDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+QW5kLCB0 aGUgcmVxdWlyZW1lbnQgaXMgdG8gY29uc2lkZXIgdGhyZWUgd29ya2luZyBtb2RlcyBvZiBDb0FQ IHNlcnZlciB3aGVuIGhhbmRsaW5nIHNsZWVweSBub2Rlcy4gPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPmlmIHRoZSBDb0FQIENsaWVu dCBnZXQgdGhpcyBrbm93bGVkZ2UgaXQgbWF5IGJlIGdvb2QgdG8gZ2V0IGJldHRlciB0aGUgY29t bXVuaWNhdGlvbiBlZmZpY2llbmN5IGluIENvUkUgbmV0d29ya3MuPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPlJlZ2FyZHMsIDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5H ZW5neXUgPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+TmV0d29yayBUZWNob25vbGd5IENl bnRlcjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+U2Nob29sIG9mIENvbXB1dGVyPC9zcGFuPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIjtjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOmJsYWNrJz5CZWlqaW5nIFVuaXZlcnNpdHkgb2YgUG9zdHMgYW5kIFRlbGVjb21t dW5pY2F0aW9uczwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlc21va2UnPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+IDxhIGhyZWY9Im1haWx0bzp3ZWlnZW5n eXVAYnVwdC5lZHUuY24iIHRpdGxlPSJ3ZWlnZW5neXVAYnVwdC5lZHUuY24iPndlaWdlbmd5dTwv YT4gPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdiYWNrZ3JvdW5kOndoaXRlc21va2UnPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+U2VudDo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+IEZyaWRheSwgTWFyY2ggMjgsIDIwMTQgMTE6 MDMgQU08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J2JhY2tncm91bmQ6d2hpdGVzbW9rZSc+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5Ubzo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+IDxhIGhyZWY9Im1haWx0bzpBa2Jhci5SYWht YW5ASW50ZXJEaWdpdGFsLmNvbSIgdGl0bGU9IkFrYmFyLlJhaG1hbkBJbnRlckRpZ2l0YWwuY29t Ij5Ba2Jhci5SYWhtYW5ASW50ZXJEaWdpdGFsLmNvbTwvYT4gPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlc21v a2UnPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+Q2M6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymxh Y2snPiA8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyIgdGl0bGU9ImNvcmVAaWV0Zi5vcmci PmNvcmVAaWV0Zi5vcmc8L2E+IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZXNtb2tlJz48Yj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29s b3I6YmxhY2snPlN1YmplY3Q6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiBSZTogW2Nv cmVdIGRyYWZ0LXJhaG1hbi1jb3JlLXNsZWVweS0wNTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2VudHVyeSIsInNlcmlmIjtjb2xvcjpi bGFjayc+SGkgQWtiYXIsPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNlbnR1 cnkiLCJzZXJpZiI7Y29sb3I6YmxhY2snPkFib3V0IGRyYWZ0LXJhaG1hbi1jb3JlLXNsZWVweS0w NSBFbmhhbmNlZCBTbGVlcHkgTm9kZSBTdXBwb3J0IGZvciBDb0FQLCBJIGhhdmUgYSBxdWVzdGlv bi4gPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNlbnR1cnkiLCJzZXJpZiI7 Y29sb3I6YmxhY2snPkRlZmluaW5nIFNsZWVwIFBhcmEgdG8gdGFja2xlIHNsZWVwIG5vZGVzIGlu IENvUkUgbmV0d29ya3MgaXMgYW4gZXNzZW50aWFsIHdvcmsgYW5kIGltcG9ydGFudC4gPC9zcGFu PjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJs YWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymxh Y2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNlbnR1cnkiLCJzZXJpZiI7Y29sb3I6Ymxh Y2snPkJ5IHRoZSBGaWd1cmUgMzogUHJvdG90eXBlIENvbmZpZ3VyYXRpb24sPC9zcGFuPjxzcGFu IHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtZmFtaWx5OiJDZW50dXJ5Iiwic2VyaWYiO2NvbG9yOmJsYWNrJz55b3UgcHJv cG9zZSB0byBhZGQgUkQgU2xlZXAgUGFyYSBpbnRvIHByb3h5IChDb0FQIFJldmVyc2UgUHJveHkp LiA8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2VudHVyeSIsInNlcmlmIjtj b2xvcjpibGFjayc+SXMgaXQgcG9zc2libGUgdG8gdHJhbnNmZXIgU2xlZXAgUGFyYSBpbnRvIENv QVAgQ2xpZW50PyA8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNlbnR1cnkiLCJzZXJp ZiI7Y29sb3I6YmxhY2snPkl0IGlzIHRoZSBDb0FQIENsaWVudCB0byBpbnRpYWwgZWFjaCBDb0FQ IHJlcXVlc3QsJm5ic3A7IDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2VudHVyeSIs InNlcmlmIjtjb2xvcjpibGFjayc+YW5kIHRoZSBDb0FQIENsaWVudCBtYXkgZ2V0IHRoZSBpbmZv bWF0aW9ucyBhYm91dCB0aGUgcmVzb3VyY2VzIGZyb20gdGhlIEFDSyBvZiB0aGUgZmlyc3QgYWNj ZXNzLCBpZiBwb3NzaWJsZS4gPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNl bnR1cnkiLCJzZXJpZiI7Y29sb3I6YmxhY2snPldpdGggdGhpcyBrbm93bGVkZ2UsIHRoZSBDb0FQ IGNsaWVudCBjb3VsZCBjaG9vc2UgdGhlIGFkcXVhdGUgY2hhbmNlIHRvIHNlbmQgcmVxdWVzdCwg PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDZW50dXJ5Iiwic2VyaWYiO2NvbG9yOmJs YWNrJz5hbmQgZXN0aW1hdGUgdGhlIGR1cmF0aW9uIHRvIHdhaXQgZm9yIHJlc3BvbnNlLiA8L3Nw YW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDZW50dXJ5Iiwic2Vy aWYiO2NvbG9yOmJsYWNrJz5SZWdhcmRzLDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFt aWx5OiJDZW50dXJ5Iiwic2VyaWYiO2NvbG9yOmJsYWNrJz5HZW5neXU8L3NwYW4+PHNwYW4gc3R5 bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LWZhbWlseToiQ2VudHVyeSIsInNlcmlmIjtjb2xvcjpibGFjayc+TmV0d29y ayBUZWNobm9sb2d5IENlbnRlcjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2VudHVy eSIsInNlcmlmIjtjb2xvcjpibGFjayc+U2Nob29sIG9mIENvbXB1dGVyPC9zcGFuPjxzcGFuIHN0 eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtZmFtaWx5OiJDZW50dXJ5Iiwic2VyaWYiO2NvbG9yOmJsYWNrJz5CZWlqaW5nIFVu aXZlcnNpdHkgb2YgUG9zdHMgYW5kIFRlbGVjb21tdW5pY2F0aW9ucy48L3NwYW4+PHNwYW4gc3R5 bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjxkaXYgY2xhc3M9TXNvTm9y bWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxzcGFuIHN0eWxlPSdm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48aHIgc2l6ZT0y IHdpZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXI+PC9zcGFuPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjpi bGFjayc+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ Y29yZSBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciPmNvcmVA aWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY29yZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlPC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rp dj48L2Rpdj48L2JvZHk+PC9odG1sPg== ------_=_NextPart_001_01CF4DF3.F4C3F120-- From nobody Wed Apr 2 00:59:26 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7117A1A00CF for ; Wed, 2 Apr 2014 00:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DRUGS_MUSCLE=0.01, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3r_9cyZdqMH9 for ; Wed, 2 Apr 2014 00:59:19 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 5297F1A0165 for ; Wed, 2 Apr 2014 00:59:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,778,1389724200"; d="scan'208";a="519050853" X-DISCLAIMER: FALSE Received: from INKOLSALDLPMTA1.india.tcs.com (unknown [127.0.0.1]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 4A658DAC02; Wed, 2 Apr 2014 13:28:58 +0530 (IST) Received: from InKolM02.tcs.com (unknown [172.18.18.104]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 0355ADAC1D; Wed, 2 Apr 2014 13:28:58 +0530 (IST) In-Reply-To: References: To: "Rahman, Akbar" MIME-Version: 1.0 X-KeepSent: AE7F0382:456EFF3B-65257CAE:00245213; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0 March 08, 2013 From: Abhijan Bhattacharyya Message-ID: Date: Wed, 2 Apr 2014 12:52:13 +0530 X-MIMETrack: Serialize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 04/02/2014 12:52:15, Serialize complete at 04/02/2014 12:52:15, Serialize by Router on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 04/02/2014 13:28:57, Serialize complete at 04/02/2014 13:28:57 Content-Type: multipart/alternative; boundary="=_alternative 00287C2965257CAE_=" Archived-At: http://mailarchive.ietf.org/arch/msg/core/iVRznhn7tIZIGnzTd7SKpr6uAmA Cc: Arijit Ukil , Arpan Pal , core@ietf.org, Tulika Bose Subject: Re: [core] Fw: New Version Notification for draft-bhattacharyya-core-coap-lite-auth-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 07:59:23 -0000 This is a multipart message in MIME format. --=_alternative 00287C2965257CAE_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi Akbar, First of all, thank you very much for sparing some time for the draft. Answers in line: If you carry the Authentication payload in the POST (e.g. Figure 2) does=20 that mean it is carried in clear text? Or do you actually already have a = DTLS session underneath CoAP? The sequence of events is not clear to me. Other than the initial HELLO payload in rest of the exchanges are=20 encrypted. That is why the payload is represented within 'AES(....)'. There is no DTLS session assumed. Actually the authentication and key=20 establishment mechanism is thought of as an alternative to what happens=20 with DTLS-PSK. May be we can integrate this scheme with DTLS in future. We = are actually working with several possible options using this scheme that=20 can either provide a light weight scheme to establish an authenticated and = secured scheme specific to CoAP or may lead to some dimension that might=20 modify DTLS itself to create a lightweight alternative within the DTLS=20 framework. Did you consider taking your draft to DICE (=20 http://datatracker.ietf.org/wg/dice/charter/ ) where it seems to fit the=20 charter much better than CORE? We had a bit of dilemma regarding which mailing list should we submit this = draft to - CoRE or Dice. But we decided to stick to CoRE for the time=20 being as the draft at present proposes a generic solution with=20 implementation details specific to CoAP which should be best understood by = people in CoRE. Dice is mostly dealing with optimization of DTLS. However, = we may transfer to Dice if , as mentioned earlier, we manage to bring in=20 some modification into DTLS based on the proposed scheme.=20 As a second thought, should this one be a better candidate for ACE?=20 Although ACE is presently zeroing in on some specific architecture while=20 it is going through the formative stage of preparing the charter, but may=20 be open to options, as discussed during the meetings, for some special=20 alternatives in future. Editorial: What was the ?WIP? in the title referring to? WIP stands for Work In Progress. We thought, it would be a standard way of = representation. Apologies for the confusion. Could have easily expanded=20 it. Any further comments/ concerns will be highly appreciated. Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Experience certainty. IT Services Business Solutions Consulting =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F From: "Rahman, Akbar" To: "Abhijan Bhattacharyya" Cc: Date: 03/28/2014 03:48 AM Subject: RE: [core] Fw: New Version Notification for=20 draft-bhattacharyya-core-coap-lite-auth-00 Hi Abhijan, =20 =20 I had a chance to read your interesting draft, and had some initial=20 questions: =20 =20 =B7 If you carry the Authentication payload in the POST (e.g. Figur= e=20 2) does that mean it is carried in clear text? Or do you actually=20 already have a DTLS session underneath CoAP? The sequence of events is=20 not clear to me. =20 =B7 Did you consider taking your draft to DICE (=20 http://datatracker.ietf.org/wg/dice/charter/ ) where it seems to fit the=20 charter much better than CORE? =B7 Editorial: What was the ?WIP? in the title referring to? =20 =20 Thanks, =20 =20 Akbar =20 =20 =20 From: core [mailto:core-bounces@ietf.org] On Behalf Of Abhijan=20 Bhattacharyya Sent: Monday, March 03, 2014 9:04 AM To: core@ietf.org WG Subject: [core] Fw: New Version Notification for=20 draft-bhattacharyya-core-coap-lite-auth-00 =20 Dear All, We have uploaded a proposal on a lightweight application-layer mutual=20 authentication scheme for CoAP. Since this was specific to CoAP we have=20 uploaded in CoRE. Not sure if ACE would have been a suitable place. But,=20 ACE is yet come up with a concrete problem definition. So, keeping it in=20 CoRE so that at least the proposal could be publicly accessed if=20 considered as a potential solution to some requirements. =20 The draft is part of a larger work in progress with some promising=20 results.=20 =20 Comments, suggestions are welcome. Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Experience certainty. IT Services Business Solutions Consulting =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F -----Forwarded by Abhijan Bhattacharyya/KOL/TCS on 03/03/2014 07:23PM=20 ----- To: Soma Bandyopadhyay , "Soma Bandyopadhyay"=20 , "Abhijan Bhattacharyya" < abhijan.bhattacharyya@tcs.com>, "Arijit Ukil" ,=20 Arijit Ukil , Arpan Pal , "Arpan=20 Pal" , "Tulika Bose" , Abhijan=20 Bhattacharyya , Tulika Bose < tulika.bose@tcs.com> From: internet-drafts@ietf.org Date: 03/03/2014 07:07PM Subject: New Version Notification for=20 draft-bhattacharyya-core-coap-lite-auth-00.txt A new version of I-D, draft-bhattacharyya-core-coap-lite-auth-00.txt has been successfully submitted by Abhijan Bhattacharyya and posted to the IETF repository. Name: draft-bhattacharyya-core-coap-lite-auth Revision: 00 Title: Lightweight mutual authentication for CoAP (WIP) Document date: 2014-03-03 Group: Individual Submission Pages: 11 URL: =20 http://www.ietf.org/internet-drafts/draft-bhattacharyya-core-coap-lite-auth= -00.txt Status: =20 https://datatracker.ietf.org/doc/draft-bhattacharyya-core-coap-lite-auth/ Htmlized: =20 http://tools.ietf.org/html/draft-bhattacharyya-core-coap-lite-auth-00 Abstract: This draft presents a work-in-progress on a challenge-response based lightweight authentication scheme to mutually authenticate CoAP client and server for establishing a secure unicast communication channel. The draft discusses the generic idea behind the proposed authentication scheme, as well as presents its CoAP specific adoption. The proposed scheme has low communication overhead and can be a robust alternative against the usual DTLS based connection initiation scheme with PSK. =20 Please note that it may take a couple of minutes from the time of=20 submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain=20 confidential or privileged information. If you are=20 not the intended recipient, any dissemination, use,=20 review, distribution, printing or copying of the=20 information contained in this e-mail message=20 and/or attachments to it are strictly prohibited. If=20 you have received this communication in error,=20 please notify us by reply e-mail or telephone and=20 immediately and permanently delete the message=20 and any attachments. Thank you --=_alternative 00287C2965257CAE_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi Akbar,
First of all, thank you very much for sparing some time for the draft.
Answers in line:

 If you carry the Authentication payload in the POST (e.g. Figure 2) does that mean it is carried in clear text?  Or do  you actually already have a DTLS session underneath CoAP?  The sequence of events is not clear to me.

Other than the initial HELLO payload in rest of the exchanges are encrypted. That is why the payload is represen= ted within 'AES(....)'.
There is no DTLS session assumed. Ac= tually the authentication and key establishment mechanism is thought of as an alternative to what happens with DTLS-PSK. May be we can integrate this scheme with DTLS in future. We are actually working with several possible options using this scheme that can either provide a light weight scheme to establish an authenticated and secured scheme specific to CoAP or may lead to some dimension that might modify DTLS itself to create a lightweight alternative within the DTLS framework.

Did you consider taking= your draft to DICE ( http://datatracker.ietf.= org/wg/dice/charter/ ) where it seems to fit the charter much better than CORE?

We had a bit of dilemma regarding wh= ich mailing list should we submit this draft to - CoRE or Dice. But we decided to stick to CoRE for the time being as the draft at present proposes a generic solution with implementation details specific to CoAP which should be best understood by people in CoRE. Dice is mostly dealing with optimizat= ion of DTLS. However, we may transfer to Dice if , as mentioned earlier, we manage to bring in some modification into DTLS based on the proposed scheme.
As a second thought, should this one be a better candidate for ACE? Although ACE is presently zeroing in on some specific architecture while it is going through the formative stage of preparing the charter, but may be open to options, as discussed during the meetings, for some special alternatives in future.

Editorial: What was the= “WIP” in the title referring to?

WIP stands for Work In Progress. We thought, it would be a standard way of representation. Apologies for the confusion. Could have easily expanded it.

Any further comments/ concerns will be highly appreciated.

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services Limited
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Experience certainty.        IT Services
                       Business Solutions
                       Consulting
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F


From: "Rahman, Akbar" <Akbar.Rahman@InterDigital.com>
To: "Abhijan Bhattacharyya" <abhijan.bhattacharyya@tcs.com>
Cc: <core@ietf.o= rg>
Date: 03/28/2014 03:48 AM
Subject: RE: [core] Fw: New Version Notification for draft-bhattacharyya-core-coap-lite-= auth-00




Hi Abhijan,
 
 
I had a chance to read = your interesting draft, and had some initial questions:
 
 
=B7      =   If you carry the Aut= hentication payload in the POST (e.g. Figure 2) does that mean it is carried in clear text?  Or do  you actually already have a DTLS session underneath CoAP?  The sequence of events is not clear to me.
 
=B7      =   Did you consider tak= ing your draft to DICE ( http://datatracker.= ietf.org/wg/dice/charter/ ) where it seems to fit the charter much better than CORE?
=B7      =   Editorial: What was = the “WIP” in the title referring to?
 
 
Thanks,
 
 
Akbar
 
 
 
From: core [mailto:core-bounc= es@ietf.org] On Behalf Of Abhijan Bhattacharyya
Sent: Monday, March 03, 2014 9:04 AM
To: core@ietf.org WG
Subject: [core] Fw: New Version Notification for draft-bhattacharyya-co= re-coap-lite-auth-00
 
Dear All,
We have uploaded a proposal on a lightw= eight application-layer mutual authentication scheme for CoAP. Since this was specific to CoAP we have uploaded in CoRE. Not sure if ACE would have been a suitable place. But, ACE is yet come up with a concrete problem definitio= n. So, keeping it in CoRE so that at least the proposal could be publicly accessed if considered as a potential solution to some requirements.
 
The draft is part of a larger work in p= rogress with some promising results.  
 
Comments, suggestions are welcome.


Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services Limited
Mailto: abhijan.bhattacharyya@tcs.com=
Website: http://www.tcs.com
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Experience certainty. IT Services
Business Solutions
Consulting
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F


-----Forwarded by Abhijan Bhattacharyya/KOL/TCS on 03/03/2014 07:23PM -----=
To: Soma Bandyopadhyay <soma.bandyopadhyay@tcs.com>, "Soma Bandyopadhyay" <soma.bandyopadhy= ay@tcs.com>, "Abhijan Bhattacharyya" <abhijan.bh= attacharyya@tcs.com>, "Arijit Ukil" <arijit.ukil@tcs.com= >, Arijit Ukil <arijit.ukil@tcs.com>, Arpan Pal <arpan.pal@tcs.com>, "Arpan Pal" <arpan.pal@tcs.com>, "Tulika Bose" <tulika.bose@tcs.com= >, Abhijan Bhattacharyya <abhijan.bhattacharyya@= tcs.com>, Tulika Bose <tulika.bose@tcs.com>
From: internet-drafts@ietf.org
Date: 03/03/2014 07:07PM
Subject: New Version Notification for draft-bhattacharyya-core-coap-lite-au= th-00.txt
A new version of I-D, draft-bhattac= haryya-core-coap-lite-auth-00.txt
has been successfully submitted by Abhijan Bhattacharyya and posted to the
IETF repository.

Name: draft-bhattacharyya-core-coap-lite-auth
Revision: 00
Title: Lightweight mutual authentication for CoAP (WIP)
Document date: 2014-03-03
Group: Individual Submission
Pages: 11
URL:            http://www.ietf.org/inter= net-drafts/draft-bhattacharyya-core-coap-lite-auth-00.txt
Status:         https://datatracker.ietf.org/doc/draft-bhat= tacharyya-core-coap-lite-auth/
Htmlized:       http://tools.ietf.org/html/draft-bhattacharyya-core-c= oap-lite-auth-00


Abstract:
  This draft presents a work-in-progress on a challenge-response based
  lightweight authentication scheme to mutually authenticate CoAP
  client and server for establishing a secure unicast communication   channel. The draft discusses the generic idea behind the proposed   authentication scheme, as well as presents its CoAP specific
  adoption. The proposed scheme has low communication overhead and can
  be a robust alternative against the usual DTLS based connection
  initiation scheme with PSK.

                                                                                 


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

=3D=3D=3D=3D=3D-----=3D=3D=3D=3D= =3D-----=3D=3D=3D=3D=3D
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

--=_alternative 00287C2965257CAE_=-- From nobody Sat Apr 5 00:20:18 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777C61A0355 for ; Sat, 5 Apr 2014 00:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbF25yQ35F2S for ; Sat, 5 Apr 2014 00:20:13 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5906F1A0352 for ; Sat, 5 Apr 2014 00:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s357K3ip004770 for ; Sat, 5 Apr 2014 09:20:03 +0200 (CEST) Received: from [192.168.217.105] (p54891515.dip0.t-ipconnect.de [84.137.21.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41B06E70; Sat, 5 Apr 2014 09:20:03 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: <1A63F14A-ABF7-4206-A925-3EB965BB03C2@tzi.org> Date: Sat, 5 Apr 2014 09:20:00 +0200 X-Mao-Original-Outgoing-Id: 418375200.318082-d928c24fe420dfb53e5d3385e60a2ff3 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52B459DE.2050706@pabigot.com> <1A63F14A-ABF7-4206-A925-3EB965BB03C2@tzi.org> To: core X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/core/B-sZTJRU-gYMyf5XVc9URufxJBY Subject: Re: [core] core-coap RFC status X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 07:20:17 -0000 On 08 Feb 2014, at 13:55, Carsten Bormann wrote: > We are still waiting for draft-mcgrew-tls-aes-ccm-ecc (which had been = approved a month earlier, on 2013-10-24) to move from = =93Approved-announcement to be sent::Point Raised - writeup needed=94 to = the RFC editor queue. (And then, of course, the RFC editor needs to do = their work.) It may be worth pointing out that not only is this draft in the RFC = editor queue now (happened during IETF89), we now also have the IANA = assignment of the cipher suite identifier for the cipher suite = TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 (our MTI for CoAP in RawPublicKey = mode): 0xC0,0xAE, as set down in = http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-pa= rameters-4 so we can stop inventing identifiers for interop testing. Next step on the way to an RFC number: completion of the RFC editor=92s = editing work. (There are currently 64 documents in EDIT stage, so this might take = another couple of weeks.) Gr=FC=DFe, Carsten From nobody Sat Apr 5 10:35:42 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B671A0422 for ; Sat, 5 Apr 2014 10:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RF5LQK2eoxxu for ; Sat, 5 Apr 2014 10:35:34 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) by ietfa.amsl.com (Postfix) with ESMTP id 9843A1A0228 for ; Sat, 5 Apr 2014 10:35:34 -0700 (PDT) X-ASG-Debug-ID: 1396719328-06daaa1bd910e320001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id pZaty0pXtWFzqXV1 for ; Sat, 05 Apr 2014 13:35:28 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 5 Apr 2014 13:35:40 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CF50F5.6C3C52FD" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 5 Apr 2014 13:35:23 -0400 X-ASG-Orig-Subj: RE: [core] core-coap RFC status Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] core-coap RFC status Thread-Index: Ac9Qn88QE+JKJv58TKaVh+u6GmRrSwAVZ0Sr References: From: "Rahman, Akbar" To: "Carsten Bormann" , "core" X-OriginalArrivalTime: 05 Apr 2014 17:35:40.0104 (UTC) FILETIME=[766C1C80:01CF50F5] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1396719328 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.4596 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: http://mailarchive.ietf.org/arch/msg/core/SYjJHlTo4ZvgjZ0geJzhaYy1oE8 Subject: Re: [core] core-coap RFC status X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 17:35:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CF50F5.6C3C52FD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 R3JlYXQgbmV3cywgQ2Fyc3RlbiEgSXQgd2lsbCBiZSB3b25kZXJmdWwgd2hlbiB0aGUgQ29BUCBS RkMgaXMgcHVibGlzaGVkIChob3BlZnVsbHkgYmVmb3JlIFRvcm9udG8gSUVURikuDQoNCg0KDQoN Cg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQ2Fyc3RlbiBCb3JtYW5uIFtj YWJvQHR6aS5vcmddDQpTZW50OiBTYXR1cmRheSwgQXByaWwgMDUsIDIwMTQgMDM6MjIgQU0gRWFz dGVybiBTdGFuZGFyZCBUaW1lDQpUbzogY29yZQ0KU3ViamVjdDogUmU6IFtjb3JlXSBjb3JlLWNv YXAgUkZDIHN0YXR1cw0KDQoNCg0KT24gMDggRmViIDIwMTQsIGF0IDEzOjU1LCBDYXJzdGVuIEJv cm1hbm4gPGNhYm9AdHppLm9yZz4gd3JvdGU6DQoNCj4gV2UgYXJlIHN0aWxsIHdhaXRpbmcgZm9y IGRyYWZ0LW1jZ3Jldy10bHMtYWVzLWNjbS1lY2MgKHdoaWNoIGhhZCBiZWVuIGFwcHJvdmVkIGEg bW9udGggZWFybGllciwgb24gMjAxMy0xMC0yNCkgdG8gbW92ZSBmcm9tIOKAnEFwcHJvdmVkLWFu bm91bmNlbWVudCB0byBiZSBzZW50OjpQb2ludCBSYWlzZWQgLSB3cml0ZXVwIG5lZWRlZOKAnSB0 byB0aGUgUkZDIGVkaXRvciBxdWV1ZS4gIChBbmQgdGhlbiwgb2YgY291cnNlLCB0aGUgUkZDIGVk aXRvciBuZWVkcyB0byBkbyB0aGVpciB3b3JrLikNCg0KSXQgbWF5IGJlIHdvcnRoIHBvaW50aW5n IG91dCB0aGF0IG5vdCBvbmx5IGlzIHRoaXMgZHJhZnQgaW4gdGhlIFJGQyBlZGl0b3IgcXVldWUg bm93IChoYXBwZW5lZCBkdXJpbmcgSUVURjg5KSwgd2Ugbm93IGFsc28gaGF2ZSB0aGUgSUFOQSBh c3NpZ25tZW50IG9mIHRoZSBjaXBoZXIgc3VpdGUgaWRlbnRpZmllciBmb3IgdGhlIGNpcGhlciBz dWl0ZSBUTFNfRUNESEVfRUNEU0FfV0lUSF9BRVNfMTI4X0NDTV84IChvdXIgTVRJIGZvciBDb0FQ IGluIFJhd1B1YmxpY0tleSBtb2RlKTogMHhDMCwweEFFLCBhcyBzZXQgZG93biBpbg0KDQpodHRw Oi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3Rscy1wYXJhbWV0ZXJzL3Rscy1wYXJhbWV0ZXJz LnhodG1sI3Rscy1wYXJhbWV0ZXJzLTQNCg0Kc28gd2UgY2FuIHN0b3AgaW52ZW50aW5nIGlkZW50 aWZpZXJzIGZvciBpbnRlcm9wIHRlc3RpbmcuDQoNCk5leHQgc3RlcCBvbiB0aGUgd2F5IHRvIGFu IFJGQyBudW1iZXI6IGNvbXBsZXRpb24gb2YgdGhlIFJGQyBlZGl0b3LigJlzIGVkaXRpbmcgd29y ay4NCihUaGVyZSBhcmUgY3VycmVudGx5IDY0IGRvY3VtZW50cyBpbiBFRElUIHN0YWdlLCBzbyB0 aGlzIG1pZ2h0IHRha2UgYW5vdGhlciBjb3VwbGUgb2Ygd2Vla3MuKQ0KDQpHcsO8w59lLCBDYXJz dGVuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpj b3JlIG1haWxpbmcgbGlzdA0KY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9jb3JlDQoNCg0K ------_=_NextPart_001_01CF50F5.6C3C52FD Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPGh0bWw+ DQo8aGVhZD4NCjxtZXRhIG5hbWU9ImdlbmVyYXRvciIgY29udGVudD0iSFRNTCBUaWR5IGZvciBX aW5kb3dzICh2ZXJzIDI1IE1hcmNoIDIwMDkpLCBzZWUgd3d3LnczLm9yZyI+DQo8bWV0YSBodHRw LWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+ DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1TIEV4Y2hhbmdlIFNlcnZlciB2ZXJz aW9uIDYuNS43NjU0LjEyIj4NCjx0aXRsZT5SZTogW2NvcmVdIGNvcmUtY29hcCBSRkMgc3RhdHVz PC90aXRsZT4NCjwvaGVhZD4NCjxib2R5Pg0KR3JlYXQgbmV3cywgQ2Fyc3RlbiEgSXQgd2lsbCBi ZSB3b25kZXJmdWwgd2hlbiB0aGUgQ29BUCBSRkMgaXMgcHVibGlzaGVkIChob3BlZnVsbHkgYmVm b3JlIFRvcm9udG8gSUVURikuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQo8Yj5Gcm9tOiZuYnNwOzwvYj5DYXJz dGVuIEJvcm1hbm4gWzxhIGhyZWY9Im1haWx0bzpjYWJvQHR6aS5vcmciPmNhYm9AdHppLm9yZzwv YT5dPGJyPg0KPGI+U2VudDombmJzcDs8L2I+U2F0dXJkYXksIEFwcmlsIDA1LCAyMDE0IDAzOjIy IEFNIEVhc3Rlcm4gU3RhbmRhcmQgVGltZTxicj4NCjxiPlRvOiZuYnNwOzwvYj5jb3JlPGJyPg0K PGI+U3ViamVjdDombmJzcDs8L2I+UmU6IFtjb3JlXSBjb3JlLWNvYXAgUkZDIHN0YXR1czxicj4N Cjxicj4NCjwhLS0gQ29udmVydGVkIGZyb20gdGV4dC9wbGFpbiBmb3JtYXQgLS0+DQo8cD48Zm9u dCBzaXplPSIyIj5PbiAwOCBGZWIgMjAxNCwgYXQgMTM6NTUsIENhcnN0ZW4gQm9ybWFubiAmbHQ7 Y2Fib0B0emkub3JnJmd0OyB3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7IFdlIGFyZSBzdGlsbCB3YWl0 aW5nIGZvciBkcmFmdC1tY2dyZXctdGxzLWFlcy1jY20tZWNjICh3aGljaCBoYWQgYmVlbiBhcHBy b3ZlZCBhIG1vbnRoIGVhcmxpZXIsIG9uIDIwMTMtMTAtMjQpIHRvIG1vdmUgZnJvbSDigJxBcHBy b3ZlZC1hbm5vdW5jZW1lbnQgdG8gYmUgc2VudDo6UG9pbnQgUmFpc2VkIC0gd3JpdGV1cCBuZWVk ZWTigJ0gdG8gdGhlIFJGQyBlZGl0b3IgcXVldWUuJm5ic3A7IChBbmQgdGhlbiwgb2YgY291cnNl LCB0aGUgUkZDIGVkaXRvciBuZWVkcyB0byBkbyB0aGVpciB3b3JrLik8YnI+DQo8YnI+DQpJdCBt YXkgYmUgd29ydGggcG9pbnRpbmcgb3V0IHRoYXQgbm90IG9ubHkgaXMgdGhpcyBkcmFmdCBpbiB0 aGUgUkZDIGVkaXRvciBxdWV1ZSBub3cgKGhhcHBlbmVkIGR1cmluZyBJRVRGODkpLCB3ZSBub3cg YWxzbyBoYXZlIHRoZSBJQU5BIGFzc2lnbm1lbnQgb2YgdGhlIGNpcGhlciBzdWl0ZSBpZGVudGlm aWVyIGZvciB0aGUgY2lwaGVyIHN1aXRlIFRMU19FQ0RIRV9FQ0RTQV9XSVRIX0FFU18xMjhfQ0NN XzggKG91ciBNVEkgZm9yIENvQVAgaW4gUmF3UHVibGljS2V5IG1vZGUpOiAweEMwLDB4QUUsIGFz IHNldCBkb3duIGluPGJyPg0KPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5pYW5hLm9yZy9hc3Np Z25tZW50cy90bHMtcGFyYW1ldGVycy90bHMtcGFyYW1ldGVycy54aHRtbCN0bHMtcGFyYW1ldGVy cy00Ij5odHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3Rscy1wYXJhbWV0ZXJzL3Rscy1w YXJhbWV0ZXJzLnhodG1sI3Rscy1wYXJhbWV0ZXJzLTQ8L2E+PGJyPg0KPGJyPg0Kc28gd2UgY2Fu IHN0b3AgaW52ZW50aW5nIGlkZW50aWZpZXJzIGZvciBpbnRlcm9wIHRlc3RpbmcuPGJyPg0KPGJy Pg0KTmV4dCBzdGVwIG9uIHRoZSB3YXkgdG8gYW4gUkZDIG51bWJlcjogY29tcGxldGlvbiBvZiB0 aGUgUkZDIGVkaXRvcuKAmXMgZWRpdGluZyB3b3JrLjxicj4NCihUaGVyZSBhcmUgY3VycmVudGx5 IDY0IGRvY3VtZW50cyBpbiBFRElUIHN0YWdlLCBzbyB0aGlzIG1pZ2h0IHRha2UgYW5vdGhlciBj b3VwbGUgb2Ygd2Vla3MuKTxicj4NCjxicj4NCkdyw7zDn2UsIENhcnN0ZW48YnI+DQo8YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmNvcmUg bWFpbGluZyBsaXN0PGJyPg0KY29yZUBpZXRmLm9yZzxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9jb3JlPC9hPjxicj48L2ZvbnQ+PC9wPg0KPC9ib2R5Pg0KPC9odG1sPg0K ------_=_NextPart_001_01CF50F5.6C3C52FD-- From nobody Mon Apr 7 19:35:03 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFDB71A007B for ; Mon, 7 Apr 2014 19:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VY7hrJy05ulC for ; Mon, 7 Apr 2014 19:34:52 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 55A111A006F for ; Mon, 7 Apr 2014 19:34:51 -0700 (PDT) Received: from WeiGengyuPC (unknown [10.103.240.114]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 13ED519F372; Tue, 8 Apr 2014 10:34:43 +0800 (HKT) Message-ID: <6BA0E5AA1F98454FA81B90FC1D213906@WeiGengyuPC> From: "weigengyu" To: "Rahman, Akbar" References: <146BA183A28B4C6DBF8EA90D49B5724C@WeiGengyuPC> <24D85E520FCE4FD0AF1A451A102FA5FB@WeiGengyuPC> <5FFC27BC1AFF41EF9FECCCAAA09DDA8F@WeiGengyuPC> In-Reply-To: Date: Tue, 8 Apr 2014 10:34:41 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C3_01CF5316.26ADE430" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Archived-At: http://mailarchive.ietf.org/arch/msg/core/NFSekrkZ3BubTj1vJ8_CEMsfs_g Cc: core@ietf.org Subject: Re: [core] draft-rahman-core-sleepy-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 02:34:58 -0000 这是一封 MIME 格式的多方邮件。 ------=_NextPart_000_00C3_01CF5316.26ADE430 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Akabr,=20 > Okay, but I still don=E2=80=99t see the value of the third state = (receive-only) from a CoAP point of view?=20 Undestanding the benefit of receive-only state is not so difficult, the = receiver can send one response in a bundle to a few requests if the = protocol support.=20 > I do understand it from a radio point of view, but that should perhaps = be decoupled from CoAP application if there is nothing in CoAP that is = explicitly impacted. What I mean is that the current works related to sleepy nodes in CoAP WG = considered only two mode.=20 There are another working model in which the sleepy nodes have three = modes.=20 Leave it to the applicatoin is an alternative, but seem not to be good = one. Regards,=20 Gengyu Network Technology Center School of Computer Beijing University of Posts and Telecommunications From: Rahman, Akbar=20 Sent: Wednesday, April 02, 2014 5:47 AM To: weigengyu=20 Cc: core@ietf.org=20 Subject: RE: [core] draft-rahman-core-sleepy-05 Hi Gengyu, =20 =20 Thank you for your feedback. =20 =20 =20 >If the sensor has registered its sleepy mode, the proxy could give this = knowledge to the client in the response.=20 >The Content within the response may be extended to cover three-state = server. =20 Okay, but I still don=E2=80=99t see the value of the third state = (receive-only) from a CoAP point of view? I do understand it from a = radio point of view, but that should perhaps be decoupled from CoAP = application if there is nothing in CoAP that is explicitly impacted. =20 =20 Akbar =20 =20 From: weigengyu [mailto:weigengyu@bupt.edu.cn]=20 Sent: Tuesday, April 01, 2014 11:57 AM To: Rahman, Akbar Subject: Re: [core] draft-rahman-core-sleepy-05 =20 Hi Akbar,=20 =20 >>In our researching work, the CoAP server has three working modes: = active, receive-only, and sleep. >>active mode: the server can send and receiv; >>receive-only mode: the server can receive, not send; >>sleep mode: the server can neither send nor receive. =20 >This is interesting. But, what is the main benefit of the receive-only = mode? =20 I have just got the requirements of two-state server and three-state = server.=20 The receive-only may save power compared to active mode. The sensor works in a fixed interval and can give responses at a time. =20 =20 =20 >That is, since the CoAP model is request/response, what is the value of = being able to send the request (e.g. GET) without knowing the response? The first request from the client does not know this. The client send = =E2=80=9CGET=E2=80=9D as usual. =20 Without the sensors registration information, the proxy treat it as a = mormal request. If the sensor has registered its sleepy mode, the proxy could give this = knowledge to the client in the response.=20 The Content within the response may be extended to cover three-state = server. =20 >>So, in the situation when the CoAP server is in receive-only mode, the = proxy should forward the request to the server.=20 >>The CoAP server could receive the request and give a response after a = while.=20 >>The proxy need to return =E2=80=9CWaiting for a while=E2=80=9D instead = of =E2=80=9CThe Retry =E2=80=93After=E2=80=9D.=20 =20 >Is =E2=80=9CWaiting for a while=E2=80=9D a new CoAP Response code that = needs to be defined? =20 I think =E2=80=9CThe Retry -After=E2=80=9D means =E2=80=9Cwait for a = while and then retry.=E2=80=9D=20 So, the extension is to provide whether =E2=80=9Cwait for a = while=E2=80=9D or =E2=80=9Cwait for a while and then retry.=E2=80=9D=20 It could be a new response code.=20 =20 Regards,=20 =20 Gengyu =20 Network Technology Center School of Computer Beijing University of Posts and Telecommunications =20 =20 From: Rahman, Akbar=20 Sent: Monday, March 31, 2014 8:27 PM To: weigengyu=20 Cc: core@ietf.org=20 Subject: RE: [core] draft-rahman-core-sleepy-05 =20 Hi Weigengyu, =20 =20 =20 Thank you for the good questions. Following is my feedback: =20 =20 >So, in the situation when the CoAP server is in receive-only mode, the = proxy should forward the request to the server.=20 >The CoAP server could receive the request and give a response after a = while.=20 >The proxy need to return =E2=80=9CWaiting for a while=E2=80=9D instead = of =E2=80=9CThe Retry =E2=80=93After=E2=80=9D.=20 =20 Is =E2=80=9CWaiting for a while=E2=80=9D a new CoAP Response code that = needs to be defined? =20 =20 =20 >In our researching work, the CoAP server has three working modes: = active, receive-only, and sleep. >active mode: the server can send and receiv; >receive-only mode: the server can receive, not send; >sleep mode: the server can neither send nor receive. =20 This is interesting. But, what is the main benefit of the receive-only = mode? That is, since the CoAP model is request/response, what is the = value of being able to send the request (e.g. GET) without knowing the = response? =20 =20 =20 Best Regards, =20 =20 Akbar =20 =20 =20 From: weigengyu [mailto:weigengyu@bupt.edu.cn]=20 Sent: Monday, March 31, 2014 5:57 AM To: Rahman, Akbar Cc: core@ietf.org Subject: Re: [core] draft-rahman-core-sleepy-05 =20 Hi Akbai,=20 =20 I would like to make my question clear. =20 In your work, =E2=80=9CEnhanced Sleepy Node Support for CoAP IETF 87, = July 2013, Sleepy Node Performance Analysis=E2=80=9D in the PPT page of =E2=80=9CReverse Proxy Features for Sleepy Node = Support=E2=80=9D=20 there are following descriptions:=20 =E2=80=9CSleep-aware CoAP 5.03 Response Capability=20 If CoAP request to a sleeping server is received (and there is no valid = cache for that request), proxy returns a =E2=80=985.03 = Retry-After=E2=80=99 response to client =20 5.03 contains a timestamp indicating when the sever will wake back up = (timestamp delivered in CoAP maxAge option) =E2=80=9C=20 =20 In our researching work, the CoAP server has three working modes: = active, receive-only, and sleep. active mode: the server can send and receiv; receive-only mode: the server can receive, not send; sleep mode: the server can neither send nor receive. =20 So, in the situation when the CoAP server is in receive-only mode, the = proxy should forward the request to the server.=20 The CoAP server could receive the request and give a response after a = while.=20 The proxy need to return =E2=80=9CWaiting for a while=E2=80=9D instead = of =E2=80=9CThe Retry =E2=80=93After=E2=80=9D.=20 =20 This may be due to how we define the sleepy node.=20 And, the requirement is to consider three working modes of CoAP server = when handling sleepy nodes.=20 =20 if the CoAP Client get this knowledge it may be good to get better the = communication efficiency in CoRE networks. =20 Regards,=20 =20 Gengyu=20 =20 Network Techonolgy Center School of Computer Beijing University of Posts and Telecommunications =20 From: weigengyu=20 Sent: Friday, March 28, 2014 11:03 AM To: Akbar.Rahman@InterDigital.com=20 Cc: core@ietf.org=20 Subject: Re: [core] draft-rahman-core-sleepy-05 =20 Hi Akbar, =20 About draft-rahman-core-sleepy-05 Enhanced Sleepy Node Support for CoAP, = I have a question.=20 =20 Defining Sleep Para to tackle sleep nodes in CoRE networks is an = essential work and important.=20 =20 By the Figure 3: Prototype Configuration, you propose to add RD Sleep Para into proxy (CoAP Reverse Proxy).=20 =20 Is it possible to transfer Sleep Para into CoAP Client?=20 It is the CoAP Client to intial each CoAP request, =20 and the CoAP Client may get the infomations about the resources from the = ACK of the first access, if possible.=20 =20 With this knowledge, the CoAP client could choose the adquate chance to = send request,=20 and estimate the duration to wait for response. =20 =20 =20 Regards, =20 Gengyu =20 Network Technology Center School of Computer Beijing University of Posts and Telecommunications. =20 -------------------------------------------------------------------------= ------- _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------=_NextPart_000_00C3_01CF5316.26ADE430 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Akabr,
 
> Okay, but I still don=E2=80=99t see the value of = the third state=20 (receive-only) from a CoAP point of view?
Undestanding the benefit of receive-only state is not so difficult, = the=20 receiver can send one response in a bundle to a few requests if the = protocol=20 support.
 
> I do = understand it from a=20 radio point of view, but that should perhaps be decoupled from CoAP = application=20 if there is nothing in CoAP that is explicitly impacted.
What I mean is that the current works = related to=20 sleepy nodes in CoAP WG considered only two mode.
There are another working model in = which the=20 sleepy nodes have three modes.
 
Leave it to  the applicatoin is = an=20 alternative, but seem  not to be good one.
 
Regards,
 
Gengyu
 
Network Technology = Center
School of Computer
Beijing University of Posts and=20 Telecommunications
 
From: Rahman, Akbar
Sent: Wednesday, April 02, 2014 5:47 AM
Subject: RE: [core] = draft-rahman-core-sleepy-05
 

Hi=20 Gengyu,

 

 

Thank=20 you for your feedback. 

 

 

>If=20 the sensor has registered its sleepy mode, the proxy could give this = knowledge=20 to the client in the response.

>The=20 Content within the response may be extended to cover three-state=20 server.

 

Okay,=20 but I still don=E2=80=99t see the value of the third state = (receive-only) from a CoAP=20 point of view?  I do understand it from a radio point of view, but = that=20 should perhaps be decoupled from CoAP application if there is nothing in = CoAP=20 that is explicitly impacted.

 

 

Akbar

 

 

From:=20 weigengyu [mailto:weigengyu@bupt.edu.cn]
Sent: Tuesday, April = 01,=20 2014 11:57 AM
To: Rahman, Akbar
Subject: Re: [core]=20 draft-rahman-core-sleepy-05

 

Hi=20 Akbar,

 

>>In = our=20 researching work, the CoAP server has three working modes: active, = receive-only,=20 and sleep.

>>active mode:=20 the server can send and receiv;

>>receive-only=20 mode: the server can receive, not send;

>>sleep mode:=20 the server can neither send nor receive.

 

>This=20 is interesting.  But, what is the main benefit of the receive-only=20 mode? 

I=20 have just got the requirements of two-state server and three-state = server.=20

The=20 receive-only may save power compared to active = mode.

The=20 sensor works in a fixed interval and can give responses at a time.  =

 

 

>That=20 is, since the CoAP model is request/response, what is the value of being = able to=20 send the request (e.g. GET) without knowing the response?

The=20 first request from the client does not know this. The client send = =E2=80=9CGET=E2=80=9D as=20 usual.

 

Without=20 the sensors registration information, the proxy treat it as a mormal=20 request.

If=20 the sensor has registered its sleepy mode, the proxy could give this = knowledge=20 to the client in the response.

The=20 Content within the response may be extended to cover three-state=20 server.

 

>>So, = in the=20 situation when the CoAP server is in receive-only mode, the proxy should = forward=20 the request to the server.

>>The = CoAP=20 server could receive the request and give a  response after a = while.=20

>>The = proxy need=20 to return =E2=80=9CWaiting for = a=20 while=E2=80=9D instead of=20 =E2=80=9CThe Retry = =E2=80=93After=E2=80=9D.=20

 

>Is = =E2=80=9CWaiting = for a=20 while=E2=80=9D a new = CoAP Response=20 code that needs to be defined?

 

I=20 think =E2=80=9CThe Retry -After=E2=80=9D means =E2=80=9Cwait for a while = and then retry.=E2=80=9D

So,=20 the extension is to provide whether =E2=80=9Cwait for a while=E2=80=9D = or =E2=80=9Cwait for a while and=20 then retry.=E2=80=9D

It=20 could be a new response code.

 

Regards,=20

 

Gengyu

 

Network=20 Technology Center

School=20 of Computer

Beijing=20 University of Posts and Telecommunications

 

 

From:=20 Rahman, Akbar=20

Sent:=20 Monday, March 31, 2014 8:27 PM

To:=20 weigengyu=20

Cc:=20 core@ietf.org =

Subject:=20 RE: [core] = draft-rahman-core-sleepy-05

 

Hi=20 Weigengyu,

 

 

 

Thank=20 you for the good questions.  Following is my=20 feedback:

 

 

>So, in = the=20 situation when the CoAP server is in receive-only mode, the proxy should = forward=20 the request to the server.

>The CoAP = server=20 could receive the request and give a  response after a while.=20

>The = proxy need to=20 return =E2=80=9CWaiting for a while=E2=80=9D instead of =E2=80=9CThe = Retry =E2=80=93After=E2=80=9D.=20

 

Is = =E2=80=9CWaiting for a=20 while=E2=80=9D a new CoAP Response code that needs to be = defined?

 

 

 

>In our = researching=20 work, the CoAP server has three working modes: active, receive-only, and = sleep.

>active = mode: the=20 server can send and receiv;

>receive-only mode:=20 the server can receive, not send;

>sleep = mode: the=20 server can neither send nor receive.

 

This is=20 interesting.  But, what is the main benefit of the receive-only = mode? =20 That is, since the CoAP model is request/response, what is the value of = being=20 able to send the request (e.g. GET) without knowing the=20 response?

 

 

 

Best=20 Regards,

 

 

Akbar

 

 

 

From:=20 weigengyu [mailto:weigengyu@bupt.edu.cn]=20
Sent: Monday, March 31, 2014 5:57 AM
To: Rahman,=20 Akbar
Cc: core@ietf.org
Subject: Re: = [core]=20 draft-rahman-core-sleepy-05

 

Hi Akbai,=20

 

I would like = to make=20 my question clear.

 

In your = work,=20 =E2=80=9CEnhanced Sleepy Node Support for CoAP IETF 87, July 2013, = Sleepy Node=20 Performance Analysis=E2=80=9D

in the PPT = page of=20 =E2=80=9CReverse Proxy Features for Sleepy Node Support=E2=80=9D =

there are = following=20 descriptions:

=E2=80=9CSleep-aware CoAP 5.03=20 Response Capability

If CoAP = request to a=20 sleeping server is received (and there is no valid cache for that = request),=20 proxy returns a =E2=80=985.03 Retry-After=E2=80=99 response to = client =20

5.03 = contains a=20 timestamp indicating when the sever will wake back up (timestamp = delivered in=20 CoAP maxAge option) =E2=80=9C

 

In our = researching=20 work, the CoAP server has three working modes: active, receive-only, and = sleep.

active mode: = the=20 server can send and receiv;

receive-only = mode: the=20 server can receive, not send;

sleep mode: = the server=20 can neither send nor receive.

 

So, in the = situation=20 when the CoAP server is in receive-only mode, the proxy should forward = the=20 request to the server.

The CoAP = server could=20 receive the request and give a  response after a while.=20

The proxy = need to=20 return =E2=80=9CWaiting for a while=E2=80=9D instead of =E2=80=9CThe = Retry =E2=80=93After=E2=80=9D.=20

 

This may be = due to how=20 we define the sleepy node.

And, the = requirement=20 is to consider three working modes of CoAP server when handling sleepy = nodes.=20

 

if the CoAP = Client get=20 this knowledge it may be good to get better the communication efficiency = in CoRE=20 networks.

 

Regards,=20

 

Gengyu=20

 

Network = Techonolgy=20 Center

School of=20 Computer

Beijing = University of=20 Posts and Telecommunications

 

From: weigengyu=20

Sent:=20 Friday, March 28, 2014 11:03 AM

To: Akbar.Rahman@InterDigital.c= om=20

Cc: core@ietf.org=20

Subject: Re:=20 [core] = draft-rahman-core-sleepy-05

 

Hi=20 Akbar,

 

About=20 draft-rahman-core-sleepy-05 Enhanced Sleepy Node Support for CoAP, I = have a=20 question.

 

Defining Sleep = Para to=20 tackle sleep nodes in CoRE networks is an essential work and important.=20

 

By=20 the Figure 3: Prototype Configuration,

you propose to = add RD Sleep=20 Para into proxy (CoAP Reverse Proxy).

 

Is=20 it possible to transfer Sleep Para into CoAP Client?

It=20 is the CoAP Client to intial each CoAP request, 

and the CoAP = Client may get=20 the infomations about the resources from the ACK of the first access, if = possible.

 

With this = knowledge, the=20 CoAP client could choose the adquate chance to send request, =

and estimate the = duration=20 to wait for response.  

 

 

Regards,

 

Gengyu

 

Network = Technology=20 Center

School of=20 Computer

Beijing = University of Posts=20 and Telecommunications.

 

_______________________________________________
core=20 mailing list
core@ietf.org
https://www.ietf.org/= mailman/listinfo/core

------=_NextPart_000_00C3_01CF5316.26ADE430-- From nobody Thu Apr 10 06:40:54 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 770D51A0136; Thu, 10 Apr 2014 06:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNcqW_zwBchK; Thu, 10 Apr 2014 06:40:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5EA1A021F; Thu, 10 Apr 2014 06:40:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140410134036.31650.91479.idtracker@ietfa.amsl.com> Date: Thu, 10 Apr 2014 06:40:36 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/core/bhRnrnpbwiiZWQqeky-EVL6yaH0 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-observe-13.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 13:40:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments Working Group of the IETF. Title : Observing Resources in CoAP Author : Klaus Hartke Filename : draft-ietf-core-observe-13.txt Pages : 32 Date : 2014-04-10 Abstract: CoAP is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best- effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-observe/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-observe-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-core-observe-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 14 05:43:48 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674D01A043E for ; Mon, 14 Apr 2014 05:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.071 X-Spam-Level: X-Spam-Status: No, score=-1.071 tagged_above=-999 required=5 tests=[BAYES_60=1.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1_v4Utc2Bgde for ; Mon, 14 Apr 2014 05:43:45 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 5368D1A043C for ; Mon, 14 Apr 2014 05:43:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,857,1389724200"; d="scan'208";a="522966802" Received: from INKOLSALDLPMTA1.india.tcs.com (unknown [127.0.0.1]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id C8598DAC12 for ; Mon, 14 Apr 2014 18:13:39 +0530 (IST) Received: from InKolM02.tcs.com (unknown [172.18.18.104]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 9EBF2DAC02 for ; Mon, 14 Apr 2014 18:13:39 +0530 (IST) To: core@ietf.org MIME-Version: 1.0 X-KeepSent: 9E00143C:03625C33-65257CBA:004282B1; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0 March 08, 2013 From: Abhijan Bhattacharyya Message-ID: Date: Mon, 14 Apr 2014 18:13:37 +0530 X-MIMETrack: Serialize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 04/14/2014 18:13:39, Serialize complete at 04/14/2014 18:13:39, Serialize by Router on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 04/14/2014 18:13:39 Content-Type: multipart/alternative; boundary="=_alternative 0045E11865257CBA_=" Archived-At: http://mailarchive.ietf.org/arch/msg/core/VWHACcvX90MbDD5X_0DzoE7Un0I Subject: [core] Handling tokens for No-response X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 12:43:47 -0000 This is a multipart message in MIME format. --=_alternative 0045E11865257CBA_= Content-Type: text/plain; charset="US-ASCII" Hi All, A comment received on the No-response option during the London meeting was on to clarify how to handle the tokens for requests that are not going to get any matching response. Specifically, concern was raised regarding the reuse of a token. A token is used to match the response with the corresponding request. Now, since no response is suppressing the request from the server so a token in the request is never matched with any response. Under such circumstance how to decide when to reuse a token. The point was raised by Carsten. I had a very brief off-the-meeting discussion with him on this and getting opinion on this matter in the mailing list was suggested. So, here are some specific questions to the mailing list: 1. Is the problem statement above really important enough to be dealt with in the draft or should it be left upon the application developer to handle? (The following ones are relevant if the answer to the above is an 'yes' for proposing a solution. ) 2. Assuming that we need a precise direction in the draft to handle this, would it be a good idea to suggest to use a zero-length token while using No-response? (Of course, this cannot be a MUST considering the fact that if someone wants use No-response with a GET request for observe cancellation then the token must be there to identify the correspondence with the original observe-GET. Please note: No-response is not defined for GET in the present draft but it will be included in the next version keeping the observe cancellation solution in mind ) 3. Any other idea? Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you --=_alternative 0045E11865257CBA_= Content-Type: text/html; charset="US-ASCII" Hi All,
A comment received on the No-response option during the London meeting was on to clarify how to handle the tokens for requests that are not going to get any matching response. Specifically, concern was raised regarding the reuse of a token. A token is used to match the response with the corresponding request. Now, since no response is suppressing the request from the server so a token in the request is never matched with any response. Under such circumstance how to decide when to reuse a token.

The point was raised by Carsten. I had a very brief off-the-meeting discussion with him on this and getting opinion on this matter in the mailing list was suggested.
So, here are some specific questions to the mailing list:

1. Is the problem statement above really important enough to be dealt with in the draft or should it be left upon the application developer to handle?

(The following ones are relevant if the answer to the above is an 'yes' for proposing a solution. )
2. Assuming that we need a precise direction in the draft to handle this, would it be a good idea to suggest to use a zero-length token while using No-response? (Of course, this cannot be a MUST considering the fact that if someone wants use No-response with a GET request for observe cancellation then the token must be there to identify the correspondence with the original observe-GET. Please note:  No-response is not defined for GET in the present draft but it will be included in the next version keeping the observe cancellation solution in mind )

3. Any other idea?

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services Limited
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Consulting
____________________________________________

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

--=_alternative 0045E11865257CBA_=-- From nobody Tue Apr 15 22:20:20 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951A51A002F for ; Tue, 15 Apr 2014 22:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.529 X-Spam-Level: X-Spam-Status: No, score=0.529 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jI73n409tP1U for ; Tue, 15 Apr 2014 22:20:15 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) by ietfa.amsl.com (Postfix) with ESMTP id BF7EA1A0027 for ; Tue, 15 Apr 2014 22:20:15 -0700 (PDT) X-ASG-Debug-ID: 1397625610-06daaa10f16ae00001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id q7FvQfbb2xIJjklo for ; Wed, 16 Apr 2014 01:20:10 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Apr 2014 01:20:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CF5932.EB723C4F" Date: Wed, 16 Apr 2014 01:15:45 -0400 X-ASG-Orig-Subj: RE: [core] Handling tokens for No-response Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Handling tokens for No-response Thread-Index: Ac9X30hdouOSjvTlTmewUrYjUI+WwABUsmpQ References: From: "Rahman, Akbar" To: "Abhijan Bhattacharyya" X-OriginalArrivalTime: 16 Apr 2014 05:20:07.0378 (UTC) FILETIME=[87CFCB20:01CF5933] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1397625610 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.4960 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: http://mailarchive.ietf.org/arch/msg/core/I2ou7X5ZCYs-pjt8zz5zGlLMmVc Cc: core@ietf.org Subject: Re: [core] Handling tokens for No-response X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 05:20:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CF5932.EB723C4F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Abhijan, =20 =20 I would prefer that the no-response token handling be left up to the implementer to handle. This is because there is already a few other cases where a response may be suppressed by the server especially for congestion control and multicast response suppression. See for example: =20 http://tools.ietf.org/html/draft-ietf-core-groupcomm-18#section-2.8 =20 =20 Best Regards, =20 =20 Akbar =20 =20 From: core [mailto:core-bounces@ietf.org] On Behalf Of Abhijan Bhattacharyya Sent: Monday, April 14, 2014 8:44 AM To: core@ietf.org Subject: [core] Handling tokens for No-response =20 Hi All,=20 A comment received on the No-response option during the London meeting was on to clarify how to handle the tokens for requests that are not going to get any matching response. Specifically, concern was raised regarding the reuse of a token. A token is used to match the response with the corresponding request. Now, since no response is suppressing the request from the server so a token in the request is never matched with any response. Under such circumstance how to decide when to reuse a token.=20 The point was raised by Carsten. I had a very brief off-the-meeting discussion with him on this and getting opinion on this matter in the mailing list was suggested.=20 So, here are some specific questions to the mailing list:=20 1. Is the problem statement above really important enough to be dealt with in the draft or should it be left upon the application developer to handle?=20 (The following ones are relevant if the answer to the above is an 'yes' for proposing a solution. )=20 2. Assuming that we need a precise direction in the draft to handle this, would it be a good idea to suggest to use a zero-length token while using No-response? (Of course, this cannot be a MUST considering the fact that if someone wants use No-response with a GET request for observe cancellation then the token must be there to identify the correspondence with the original observe-GET. Please note: No-response is not defined for GET in the present draft but it will be included in the next version keeping the observe cancellation solution in mind )=20 3. Any other idea?=20 Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com =20 ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain=20 confidential or privileged information. If you are=20 not the intended recipient, any dissemination, use,=20 review, distribution, printing or copying of the=20 information contained in this e-mail message=20 and/or attachments to it are strictly prohibited. If=20 you have received this communication in error,=20 please notify us by reply e-mail or telephone and=20 immediately and permanently delete the message=20 and any attachments. Thank you ------_=_NextPart_001_01CF5932.EB723C4F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Abhijan,

 

 

I would prefer that the no-response token handling be left up to the = implementer to handle.  This is because there is already a few = other cases where a response may be suppressed by the server especially = for congestion control and multicast response suppression.  See for = example:

 

http://tools.ietf.org/html/draft-ietf-core-groupcomm-18#section-2.8

 

 

Best Regards,

 

 

Akbar

 

 

From:= = core [mailto:core-bounces@ietf.org] On Behalf Of Abhijan = Bhattacharyya
Sent: Monday, April 14, 2014 8:44 = AM
To: core@ietf.org
Subject: [core] Handling tokens = for No-response

 

Hi = All,
A comment = received on the No-response option during the London meeting was on to = clarify how to handle the tokens for requests that are not going to get = any matching response. Specifically, concern was raised regarding the = reuse of a token. A token is used to match the response with the = corresponding request. Now, since no response is suppressing the request = from the server so a token in the request is never matched with any = response. Under such circumstance how to decide when to reuse a = token.

The point = was raised by Carsten. I had a very brief off-the-meeting discussion = with him on this and getting opinion on this matter in the mailing list = was suggested.
So, here are = some specific questions to the mailing list:

1. Is the = problem statement above really important enough to be dealt with in the = draft or should it be left upon the application developer to = handle?

(The = following ones are relevant if the answer to the above is an 'yes' for = proposing a solution. )
2. Assuming = that we need a precise direction in the draft to handle this, would it = be a good idea to suggest to use a zero-length token while using = No-response? (Of course, this cannot be a MUST considering the fact that = if someone wants use No-response with a GET request for observe = cancellation then the token must be there to identify the correspondence = with the original observe-GET. Please note:  No-response is not = defined for GET in the present draft but it will be included in the next = version keeping the observe cancellation solution in mind ) =

3. Any other = idea?

RegardsAbhijan Bhattacharyya
Associate Consultant
Scientist, Innovation = Lab, Kolkata, India
Tata Consultancy Services Limited
Mailto: abhijan.bhattacharyya@tcs.c= om
Website: http://www.tc= s.com
_________= ___________________________________
Experience certainty.   =      IT Services
          =              Business = Solutions
                =       =  Consulting
____________________________________________

=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3DNotice: The information contained in this e-mail
message and/or = attachments to it may contain
confidential or privileged = information. If you are
not the intended recipient, any = dissemination, use,
review, distribution, printing or copying of the =
information contained in this e-mail message
and/or attachments = to it are strictly prohibited. If
you have received this = communication in error,
please notify us by reply e-mail or = telephone and
immediately and permanently delete the message
and = any attachments. Thank you

------_=_NextPart_001_01CF5932.EB723C4F-- From nobody Tue Apr 15 23:55:20 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD901A006B for ; Tue, 15 Apr 2014 23:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNCLL_fEBI10 for ; Tue, 15 Apr 2014 23:55:12 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4231A0095 for ; Tue, 15 Apr 2014 23:55:12 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id t61so10283113wes.2 for ; Tue, 15 Apr 2014 23:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=WNqzp7nhWngSVsFMlo80QwvNv5Gx42b0y/IlRqk4xdk=; b=VXBSQzJdyeHMDO/96DNmKDKX0Y6RKx9OlHlF8W++fTaI7gCi35XzKYHUClGePwdsVO 2TmtNihlc1pcUwNgxMHYfbpkn1ICQMCYT1Bg02nnUqwG9JM3t2B5WR7Ps2j6WWsXPZ7A 2RiS7s7lPf3F2zvGk9LTuPebiA76d8d39lnOt1/hGLrufKFYCRHdfJxfYWn/DnlQxr1k lYG+koGuVTKPmoyIr7pfKoXQfhHyH7ciqcOOu8mhzowf+/uLerOKR4so1tKKgHlAQRlR nTuk3n9GTAxmM2KwwW/s4cUvo2Ex7JHZJdRF6FY8/Wm3AEyd0UVCFR6CrybCDMqJ9yLX CfUA== MIME-Version: 1.0 X-Received: by 10.194.122.6 with SMTP id lo6mr5360485wjb.38.1397631308635; Tue, 15 Apr 2014 23:55:08 -0700 (PDT) Received: by 10.216.158.197 with HTTP; Tue, 15 Apr 2014 23:55:08 -0700 (PDT) Date: Wed, 16 Apr 2014 12:25:08 +0530 Message-ID: From: Indtiny S To: core@ietf.org Content-Type: multipart/alternative; boundary=089e0117643dada46804f72365a7 Archived-At: http://mailarchive.ietf.org/arch/msg/core/XujRuigS5M56iG7jytKAcXVIrpQ Subject: [core] CoAP optional header field fill X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 06:55:17 -0000 --089e0117643dada46804f72365a7 Content-Type: text/plain; charset=UTF-8 Hi All, I need some information for the opetinal field for CoAP headers. | 9 | Critical | Uri-Path | string | 1-270 B | (none) | | 15| Critical | Uri-Query | string | 1-270 B | (none) | Length: in the optimal header has only 4 bits so we can represents 0 to 14 bytes, but optional filed Uri-Path has size from 1 to 270 Bytes . How to mention this filed length if it is more than 14 bytes? And also Can somebody suggest how the option number value generated for all optional fields? like Content-Type :: 1 Max-Age :: 2 Proxy-Uri :: 3 ETag :: 4 Rgds Chethan --089e0117643dada46804f72365a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi All,

I need some information for the opetinal field for CoAP headers.


=C2=A0| 9 | Critical | Ur=
i-Path | string | 1-270 B | (none) |


|  15| Critical | Uri=
-Query      | string |  1-270 B | (none)      |



 Length: in the optimal header has only 4 bits so we can represents


0 to 14 bytes, but optional filed Uri-Path has size from 1 to 270 Bytes .

How to mention this filed length if it is more than 14 bytes?

And also Can somebody suggest how the option number value ge= nerated for all optional fields?=C2=A0

like =C2=A0

=C2=A0 =C2=A0Content-Type =C2=A0:: 1

=C2=A0 =C2=A0Max-Age =C2=A0 :: 2

=C2=A0 =C2=A0Proxy-Uri :: 3

=C2=A0 =C2=A0ETag =C2=A0:: 4

=C2=A0 =C2=A0

Rgds

Chethan=C2=A0

--089e0117643dada46804f72365a7-- From nobody Wed Apr 16 02:42:33 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3401A00F4 for ; Wed, 16 Apr 2014 02:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLLVfPw0rD9t for ; Wed, 16 Apr 2014 02:42:26 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 171411A004C for ; Wed, 16 Apr 2014 02:42:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,871,1389724200"; d="scan'208";a="523708976" X-DISCLAIMER: FALSE Received: from INKOLSALDLPMTA1.india.tcs.com (unknown [127.0.0.1]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 5AB07DAC12; Wed, 16 Apr 2014 15:12:18 +0530 (IST) Received: from InKolM02.tcs.com (unknown [172.18.18.104]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 2783EDAC02; Wed, 16 Apr 2014 15:12:18 +0530 (IST) In-Reply-To: References: To: "Rahman, Akbar" MIME-Version: 1.0 X-KeepSent: 855A25E8:B6A83917-65257CBC:00343045; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0 March 08, 2013 From: Abhijan Bhattacharyya Message-ID: Date: Wed, 16 Apr 2014 15:12:16 +0530 X-MIMETrack: Serialize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 04/16/2014 15:12:17, Serialize complete at 04/16/2014 15:12:17, Serialize by Router on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 04/16/2014 15:12:17, Serialize complete at 04/16/2014 15:12:18, Serialize by Router on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 04/16/2014 15:12:18 Content-Type: multipart/alternative; boundary="=_alternative 003541EC65257CBC_=" Archived-At: http://mailarchive.ietf.org/arch/msg/core/9O706oi0Sq9vOLBlI7WXIOD3KvE Cc: core@ietf.org Subject: Re: [core] Handling tokens for No-response X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 09:42:31 -0000 This is a multipart message in MIME format. --=_alternative 003541EC65257CBC_= Content-Type: text/plain; charset="US-ASCII" Hi Akbar, Thank you very much for sharing your views. Yes, both the situations are logically similar excepting the fact that in the multicast case the decision is taken by the server and in the later case client explicitly expresses the disinterest in responses. Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ From: "Rahman, Akbar" To: "Abhijan Bhattacharyya" Cc: Date: 04/16/2014 10:50 AM Subject: RE: [core] Handling tokens for No-response Hi Abhijan, I would prefer that the no-response token handling be left up to the implementer to handle. This is because there is already a few other cases where a response may be suppressed by the server especially for congestion control and multicast response suppression. See for example: http://tools.ietf.org/html/draft-ietf-core-groupcomm-18#section-2.8 Best Regards, Akbar From: core [mailto:core-bounces@ietf.org] On Behalf Of Abhijan Bhattacharyya Sent: Monday, April 14, 2014 8:44 AM To: core@ietf.org Subject: [core] Handling tokens for No-response Hi All, A comment received on the No-response option during the London meeting was on to clarify how to handle the tokens for requests that are not going to get any matching response. Specifically, concern was raised regarding the reuse of a token. A token is used to match the response with the corresponding request. Now, since no response is suppressing the request from the server so a token in the request is never matched with any response. Under such circumstance how to decide when to reuse a token. The point was raised by Carsten. I had a very brief off-the-meeting discussion with him on this and getting opinion on this matter in the mailing list was suggested. So, here are some specific questions to the mailing list: 1. Is the problem statement above really important enough to be dealt with in the draft or should it be left upon the application developer to handle? (The following ones are relevant if the answer to the above is an 'yes' for proposing a solution. ) 2. Assuming that we need a precise direction in the draft to handle this, would it be a good idea to suggest to use a zero-length token while using No-response? (Of course, this cannot be a MUST considering the fact that if someone wants use No-response with a GET request for observe cancellation then the token must be there to identify the correspondence with the original observe-GET. Please note: No-response is not defined for GET in the present draft but it will be included in the next version keeping the observe cancellation solution in mind ) 3. Any other idea? Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you --=_alternative 003541EC65257CBC_= Content-Type: text/html; charset="US-ASCII" Hi Akbar,
Thank you very much for sharing your views. Yes, both the situations are logically similar excepting the fact that in the multicast case the decision is taken by the server and in the later case client explicitly expresses the disinterest in responses.


Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services Limited
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Consulting
____________________________________________


From: "Rahman, Akbar" <Akbar.Rahman@InterDigital.com>
To: "Abhijan Bhattacharyya" <abhijan.bhattacharyya@tcs.com>
Cc: <core@ietf.org>
Date: 04/16/2014 10:50 AM
Subject: RE: [core] Handling tokens for No-response




Hi Abhijan,
 
 
I would prefer that the no-response token handling be left up to the implementer to handle.  This is because there is already a few other cases where a response may be suppressed by the server especially for congestion control and multicast response suppression.  See for example:
 
http://tools.ietf.org/html/draft-ietf-core-groupcomm-18#section-2.8
 
 
Best Regards,
 
 
Akbar
 
 
From: core [mailto:core-bounces@ietf.org] On Behalf Of Abhijan Bhattacharyya
Sent: Monday, April 14, 2014 8:44 AM
To: core@ietf.org
Subject: [core] Handling tokens for No-response
 
Hi All,
A comment received on the No-response option during the London meeting was on to clarify how to handle the tokens for requests that are not going to get any matching response. Specifically, concern was raised regarding the reuse of a token. A token is used to match the response with the corresponding request. Now, since no response is suppressing the request from the server so a token in the request is never matched with any response. Under such circumstance how to decide when to reuse a token.

The point was raised by Carsten. I had a very brief off-the-meeting discussion with him on this and getting opinion on this matter in the mailing list was suggested.
So, here are some specific questions to the mailing list:

1. Is the problem statement above really important enough to be dealt with in the draft or should it be left upon the application developer to handle?

(The following ones are relevant if the answer to the above is an 'yes' for proposing a solution. )
2. Assuming that we need a precise direction in the draft to handle this, would it be a good idea to suggest to use a zero-length token while using No-response? (Of course, this cannot be a MUST considering the fact that if someone wants use No-response with a GET request for observe cancellation then the token must be there to identify the correspondence with the original observe-GET. Please note:  No-response is not defined for GET in the present draft but it will be included in the next version keeping the observe cancellation solution in mind )

3. Any other idea?

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services Limited
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                      Business Solutions
                      Consulting
____________________________________________

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

--=_alternative 003541EC65257CBC_=-- From nobody Wed Apr 16 06:05:36 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4AF1A015F for ; Wed, 16 Apr 2014 06:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.247 X-Spam-Level: X-Spam-Status: No, score=-0.247 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNRESOLVED_TEMPLATE=1.252] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6y7qiRZHG78 for ; Wed, 16 Apr 2014 06:05:28 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1771A0179 for ; Wed, 16 Apr 2014 06:05:27 -0700 (PDT) Received: from mail107-co9-R.bigfish.com (10.236.132.240) by CO9EHSOBE026.bigfish.com (10.236.130.89) with Microsoft SMTP Server id 14.1.225.22; Wed, 16 Apr 2014 13:04:43 +0000 Received: from mail107-co9 (localhost [127.0.0.1]) by mail107-co9-R.bigfish.com (Postfix) with ESMTP id 7F5233C0373; Wed, 16 Apr 2014 13:04:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:206.191.242.69; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:error; EFVD:FOP X-SpamScore: -35 X-BigFish: VPS-35(zzbb2dI15d6O9371Ic85fhe0eah11f6N9251I14ffI217bIdd85kzz1f42h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068h1954cbhz2dh109h2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1bceh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25f6h2605h268bh26d3h1155h) Received: from mail107-co9 (localhost.localdomain [127.0.0.1]) by mail107-co9 (MessageSwitch) id 139765348176899_17244; Wed, 16 Apr 2014 13:04:41 +0000 (UTC) Received: from CO9EHSMHS016.bigfish.com (unknown [10.236.132.250]) by mail107-co9.bigfish.com (Postfix) with ESMTP id 0E8E4720203; Wed, 16 Apr 2014 13:04:41 +0000 (UTC) Received: from mail.philips.com (206.191.242.69) by CO9EHSMHS016.bigfish.com (10.236.130.26) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 16 Apr 2014 13:04:40 +0000 Received: from AMSPRD9003MB066.MGDPHG.emi.philips.com ([169.254.5.172]) by AMSPRD9003HT003.MGDPHG.emi.philips.com ([141.251.33.80]) with mapi id 14.16.0423.000; Wed, 16 Apr 2014 13:04:49 +0000 From: "Dijk, Esko" To: Abhijan Bhattacharyya , "Rahman, Akbar" Thread-Topic: [core] Handling tokens for No-response Thread-Index: AQHPV98vDTgRdHJfpkqigWMEJ8EFKZsTthiAgABKdwCAADR9UA== Date: Wed, 16 Apr 2014 13:04:48 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED61816A146F1@AMSPRD9003MB066.MGDPHG.emi.philips.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.106] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED61816A146F1AMSPRD9003MB066_" MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%INTERDIGITAL.COM$RO%1$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/core/u9yTCUlWGO4ks3wnaohcOCeSW6A Cc: "core@ietf.org" Subject: Re: [core] Handling tokens for No-response X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 13:05:33 -0000 --_000_031DD135F9160444ABBE3B0C36CED61816A146F1AMSPRD9003MB066_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Abhijan, Akbar, just thinking how a client would decide on Token re-use : there seem to be = 3 cases. 1. When sending a unicast CON request and no response is given or the clien= t asks for No-Response, I would think that the Token can be re-used after E= XCHANGE_LIFETIME. Is that right? 2. When sending a unicast NON request and no response is given or the clien= t asks for No-Response,I would assume Token can be re-used after MAX_RTT. 3. When sending a multicast NON request, the Token can be re-used after MAX= _RTT in any case, even if some responses are already received. (There could= always be coming more responses within MAX_RTT so the request is still 'ac= tive' in this sense.) To make this simpler we could also say that Tokens can be safely re-used af= ter EXCHANGE_LIFETIME since always EXCHANGE_LIFETIME >=3D MAX_RTT. So I feel that this Token lifetime question is relevant for a wider context= than just related to the No-Response Option; like Akbar said also. Suppose we would advise to use a zero-length (default) Token for such reque= sts - wouldn't there be the same problem of Token re-use? I.e. I can only r= e-use the 0 Token after EXCHANGE_LIFETIME time has passed. regards Esko From: core [mailto:core-bounces@ietf.org] On Behalf Of Abhijan Bhattacharyy= a Sent: Wednesday, April 16, 2014 11:42 To: Rahman, Akbar Cc: core@ietf.org Subject: Re: [core] Handling tokens for No-response Hi Akbar, Thank you very much for sharing your views. Yes, both the situations are lo= gically similar excepting the fact that in the multicast case the decision = is taken by the server and in the later case client explicitly expresses th= e disinterest in responses. Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ From: "Rahman, Akbar" > To: "Abhijan Bhattacharyya" > Cc: > Date: 04/16/2014 10:50 AM Subject: RE: [core] Handling tokens for No-response ________________________________ Hi Abhijan, I would prefer that the no-response token handling be left up to the implem= enter to handle. This is because there is already a few other cases where = a response may be suppressed by the server especially for congestion contro= l and multicast response suppression. See for example: http://tools.ietf.org/html/draft-ietf-core-groupcomm-18#section-2.8 Best Regards, Akbar From: core [mailto:core-bounces@ietf.org] On Behalf Of Abhijan Bhattacharyy= a Sent: Monday, April 14, 2014 8:44 AM To: core@ietf.org Subject: [core] Handling tokens for No-response Hi All, A comment received on the No-response option during the London meeting was = on to clarify how to handle the tokens for requests that are not going to g= et any matching response. Specifically, concern was raised regarding the re= use of a token. A token is used to match the response with the correspondin= g request. Now, since no response is suppressing the request from the serve= r so a token in the request is never matched with any response. Under such = circumstance how to decide when to reuse a token. The point was raised by Carsten. I had a very brief off-the-meeting discuss= ion with him on this and getting opinion on this matter in the mailing list= was suggested. So, here are some specific questions to the mailing list: 1. Is the problem statement above really important enough to be dealt with = in the draft or should it be left upon the application developer to handle? (The following ones are relevant if the answer to the above is an 'yes' for= proposing a solution. ) 2. Assuming that we need a precise direction in the draft to handle this, w= ould it be a good idea to suggest to use a zero-length token while using No= -response? (Of course, this cannot be a MUST considering the fact that if s= omeone wants use No-response with a GET request for observe cancellation th= en the token must be there to identify the correspondence with the original= observe-GET. Please note: No-response is not defined for GET in the prese= nt draft but it will be included in the next version keeping the observe ca= ncellation solution in mind ) 3. Any other idea? Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_031DD135F9160444ABBE3B0C36CED61816A146F1AMSPRD9003MB066_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Abhijan, Akbar,

 <= /p>

just thinking how a clien= t would decide on Token re-use : there seem to be 3 cases.

 <= /p>

1. When sending a unicast= CON request and no response is given or the client asks for No-Response, I= would think that the Token can be re-used after EXCHANGE_LIFETIME. Is that right?

2. When sending a unicast= NON request and no response is given or the client asks for No-Response,I = would assume Token can be re-used after MAX_RTT.

3. When sending a multica= st NON request, the Token can be re-used after MAX_RTT in any case, even if= some responses are already received. (There could always be coming more responses within MAX_RTT so the request is still ‘act= ive’ in this sense.)

 <= /p>

To make this simpler we c= ould also say that Tokens can be safely re-used after EXCHANGE_LIFETIME sin= ce always EXCHANGE_LIFETIME >=3D MAX_RTT.

So I feel that this Token= lifetime question is relevant for a wider context than just related to the= No-Response Option; like Akbar said also.

 <= /p>

Suppose we would advise t= o use a zero-length (default) Token for such requests – wouldn’= t there be the same problem of Token re-use? I.e. I can only re-use the 0 Token after EXCHANGE_LIFETIME time has passed.

 <= /p>

regards=

Esko

 <= /p>

From: core [ma= ilto:core-bounces@ietf.org] On Behalf Of Abhijan Bhattacharyya
Sent: Wednesday, April 16, 2014 11:42
To: Rahman, Akbar
Cc: core@ietf.org
Subject: Re: [core] Handling tokens for No-response

 

Hi Akbar,<= /span>
Thank you very much for sharing your views. Yes, both the situat= ions are logically similar excepting the fact that in the multicast case th= e decision is taken by the server and in the later case client explicitly expresses the disinterest in responses.


Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services Limited
Mailto: abhijan.bhattachar= yya@tcs.com
Website: http://www.tcs.c= om
____________________________________________
Experience certainty.        IT Services
                     = ;  Business Solutions
                     = ;  Consulting
____________________________________________

From:

"= Rahman, Akbar" <Ak= bar.Rahman@InterDigital.com>

To:

"= Abhijan Bhattacharyya" <abhijan.bhattacharyya@tcs.com>

Cc:

<core@ietf.org>

Date:

04/16/= 2014 10:50 AM

Subject:

RE: [c= ore] Handling tokens for No-response

 




Hi Abhijan,
 
 
I would prefer that the no-response token handli= ng be left up to the implementer to handle.  This is because there is = already a few other cases where a response may be suppressed by the server especially for congestion control and multicast response sup= pression.  See for example:
 
http://tools.ietf.org/html/draft-ietf-core-groupcomm-18#s= ection-2.8
 
 
Best Regards,
 
 
Akbar
 
 
From: core [mailto:core-bounces@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">] On Behalf Of Abhijan Bhattacharyya
Sent: Monday, April 14, 2014 8:44 AM
To: core@ietf.org
Subject: [core] Handling tokens for No-response
 
Hi All,
A comment received on the No-response option during the London meeting was = on to clarify how to handle the tokens for requests that are not going to g= et any matching response. Specifically, concern was raised regarding the re= use of a token. A token is used to match the response with the corresponding request. Now, since no respon= se is suppressing the request from the server so a token in the request is = never matched with any response. Under such circumstance how to decide when= to reuse a token.

The point was raised by Carsten. I had a very brief off-the-meeting discuss= ion with him on this and getting opinion on this matter in the mailing list= was suggested.
So, here are some specific questions to the mailing list:

1. Is the problem statement above really important enough to be dealt with = in the draft or should it be left upon the application developer to handle?=

(The following ones are relevant if the answer to the above is an 'yes' for= proposing a solution. )
2. Assuming that we need a precise direction in the draft to handle this, w= ould it be a good idea to suggest to use a zero-length token while using No= -response? (Of course, this cannot be a MUST considering the fact that if s= omeone wants use No-response with a GET request for observe cancellation then the token must be there to ide= ntify the correspondence with the original observe-GET. Please note:  = No-response is not defined for GET in the present draft but it will be incl= uded in the next version keeping the observe cancellation solution in mind )

3. Any other idea?

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services Limited
Mailto: = abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.c= om
____________________________________________
Experience certainty.        IT Services
                     = ; Business Solutions
                     = ; Consulting
____________________________________________

=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_031DD135F9160444ABBE3B0C36CED61816A146F1AMSPRD9003MB066_-- From nobody Wed Apr 16 12:03:24 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9507F1A025C for ; Wed, 16 Apr 2014 12:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFF0HMg-MUGQ for ; Wed, 16 Apr 2014 12:03:18 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) by ietfa.amsl.com (Postfix) with ESMTP id EF2E01A0213 for ; Wed, 16 Apr 2014 12:03:17 -0700 (PDT) X-ASG-Debug-ID: 1397674990-06daaa10f37bd30001-aa7cYp Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id 4pYImjFh34Jqc6Em for ; Wed, 16 Apr 2014 15:03:10 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Apr 2014 15:03:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CF59A5.B828757E" Date: Wed, 16 Apr 2014 14:57:30 -0400 X-ASG-Orig-Subj: RE: [core] Handling tokens for No-response Message-ID: In-Reply-To: <031DD135F9160444ABBE3B0C36CED61816A146F1@AMSPRD9003MB066.MGDPHG.emi.philips.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Handling tokens for No-response Thread-Index: AQHPV98vDTgRdHJfpkqigWMEJ8EFKZsTthiAgABKdwCAADR9UIAAZc4g References: <031DD135F9160444ABBE3B0C36CED61816A146F1@AMSPRD9003MB066.MGDPHG.emi.philips.com> From: "Rahman, Akbar" To: "Dijk, Esko" X-OriginalArrivalTime: 16 Apr 2014 19:03:07.0737 (UTC) FILETIME=[80CC9C90:01CF59A6] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1397674990 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.4977 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: http://mailarchive.ietf.org/arch/msg/core/nO3W2Dw1_Vzg_I0pVS7XvGMGlgE Cc: Abhijan Bhattacharyya , core@ietf.org Subject: Re: [core] Handling tokens for No-response X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 19:03:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CF59A5.B828757E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Esko, =20 =20 > 1. When sending a unicast CON request and no response is given or the client asks for No-Response, I would think that the Token can be re-used after EXCHANGE_LIFETIME. Is that right? =20 Yes, that would be my interpretation as well. =20 =20 > Suppose we would advise to use a zero-length (default) Token for such requests - wouldn't there be the same problem of Token re-use? I.e. I can only re-use the 0 Token after EXCHANGE_LIFETIME time has passed. =20 Yes, good point! =20 =20 =20 /Akbar =20 =20 =20 =20 From: Dijk, Esko [mailto:esko.dijk@philips.com]=20 Sent: Wednesday, April 16, 2014 9:05 AM To: Abhijan Bhattacharyya; Rahman, Akbar Cc: core@ietf.org Subject: RE: [core] Handling tokens for No-response =20 Hello Abhijan, Akbar, =20 just thinking how a client would decide on Token re-use : there seem to be 3 cases. =20 1. When sending a unicast CON request and no response is given or the client asks for No-Response, I would think that the Token can be re-used after EXCHANGE_LIFETIME. Is that right? 2. When sending a unicast NON request and no response is given or the client asks for No-Response,I would assume Token can be re-used after MAX_RTT. 3. When sending a multicast NON request, the Token can be re-used after MAX_RTT in any case, even if some responses are already received. (There could always be coming more responses within MAX_RTT so the request is still 'active' in this sense.) =20 To make this simpler we could also say that Tokens can be safely re-used after EXCHANGE_LIFETIME since always EXCHANGE_LIFETIME >=3D MAX_RTT. So I feel that this Token lifetime question is relevant for a wider context than just related to the No-Response Option; like Akbar said also. =20 Suppose we would advise to use a zero-length (default) Token for such requests - wouldn't there be the same problem of Token re-use? I.e. I can only re-use the 0 Token after EXCHANGE_LIFETIME time has passed. =20 regards Esko =20 From: core [mailto:core-bounces@ietf.org] On Behalf Of Abhijan Bhattacharyya Sent: Wednesday, April 16, 2014 11:42 To: Rahman, Akbar Cc: core@ietf.org Subject: Re: [core] Handling tokens for No-response =20 Hi Akbar,=20 Thank you very much for sharing your views. Yes, both the situations are logically similar excepting the fact that in the multicast case the decision is taken by the server and in the later case client explicitly expresses the disinterest in responses.=20 Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com =20 ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________=20 From:=20 "Rahman, Akbar" =20 To:=20 "Abhijan Bhattacharyya" =20 Cc:=20 =20 Date:=20 04/16/2014 10:50 AM=20 Subject:=20 RE: [core] Handling tokens for No-response =20 ________________________________ Hi Abhijan,=20 =20 =20 I would prefer that the no-response token handling be left up to the implementer to handle. This is because there is already a few other cases where a response may be suppressed by the server especially for congestion control and multicast response suppression. See for example: =20 http://tools.ietf.org/html/draft-ietf-core-groupcomm-18#section-2.8 =20 =20 =20 Best Regards,=20 =20 =20 Akbar=20 =20 =20 From: core [mailto:core-bounces@ietf.org ] On Behalf Of Abhijan Bhattacharyya Sent: Monday, April 14, 2014 8:44 AM To: core@ietf.org Subject: [core] Handling tokens for No-response=20 =20 Hi All,=20 A comment received on the No-response option during the London meeting was on to clarify how to handle the tokens for requests that are not going to get any matching response. Specifically, concern was raised regarding the reuse of a token. A token is used to match the response with the corresponding request. Now, since no response is suppressing the request from the server so a token in the request is never matched with any response. Under such circumstance how to decide when to reuse a token.=20 The point was raised by Carsten. I had a very brief off-the-meeting discussion with him on this and getting opinion on this matter in the mailing list was suggested.=20 So, here are some specific questions to the mailing list:=20 1. Is the problem statement above really important enough to be dealt with in the draft or should it be left upon the application developer to handle?=20 (The following ones are relevant if the answer to the above is an 'yes' for proposing a solution. )=20 2. Assuming that we need a precise direction in the draft to handle this, would it be a good idea to suggest to use a zero-length token while using No-response? (Of course, this cannot be a MUST considering the fact that if someone wants use No-response with a GET request for observe cancellation then the token must be there to identify the correspondence with the original observe-GET. Please note: No-response is not defined for GET in the present draft but it will be included in the next version keeping the observe cancellation solution in mind )=20 3. Any other idea?=20 Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com =20 Website: http://www.tcs.com =20 ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________=20 =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain=20 confidential or privileged information. If you are=20 not the intended recipient, any dissemination, use,=20 review, distribution, printing or copying of the=20 information contained in this e-mail message=20 and/or attachments to it are strictly prohibited. If=20 you have received this communication in error,=20 please notify us by reply e-mail or telephone and=20 immediately and permanently delete the message=20 and any attachments. Thank you=20 =20 ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. ------_=_NextPart_001_01CF59A5.B828757E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Esko,

 

 

> 1. When sending a unicast CON request and no response is given or the = client asks for No-Response, I would think that the Token can be re-used = after EXCHANGE_LIFETIME. Is that right?

 

Yes, that would be my interpretation as well.

 

 

> Suppose we would advise to use a zero-length (default) Token for such = requests – wouldn’t there be the same problem of Token = re-use? I.e. I can only re-use the 0 Token after EXCHANGE_LIFETIME time = has passed.

 

Yes, good point!

 

 

 

/Akbar

 

 

 

 

From:= = Dijk, Esko [mailto:esko.dijk@philips.com]
Sent: Wednesday, = April 16, 2014 9:05 AM
To: Abhijan Bhattacharyya; Rahman, = Akbar
Cc: core@ietf.org
Subject: RE: [core] Handling = tokens for No-response

 

Hello Abhijan, Akbar,

 

just thinking how a client would decide on Token re-use : there seem = to be 3 cases.

 

1. When sending a unicast CON request and no response is given or the = client asks for No-Response, I would think that the Token can be re-used = after EXCHANGE_LIFETIME. Is that right?

2. When sending a unicast NON request and no response is given or the = client asks for No-Response,I would assume Token can be re-used after = MAX_RTT.

3. When sending a multicast NON request, the Token can be re-used = after MAX_RTT in any case, even if some responses are already received. = (There could always be coming more responses within MAX_RTT so the = request is still ‘active’ in this = sense.)

 

To make this simpler we could also say that Tokens can be safely = re-used after EXCHANGE_LIFETIME since always EXCHANGE_LIFETIME >=3D = MAX_RTT.

So I feel that this Token lifetime question is relevant for a wider = context than just related to the No-Response Option; like Akbar said = also.

 

Suppose we would advise to use a zero-length (default) Token for such = requests – wouldn’t there be the same problem of Token = re-use? I.e. I can only re-use the 0 Token after EXCHANGE_LIFETIME time = has passed.

 

regards

Esko

 

From:= = core [mailto:core-bounces@ietf.org] = On Behalf Of Abhijan Bhattacharyya
Sent: Wednesday, = April 16, 2014 11:42
To: Rahman, Akbar
Cc: core@ietf.org
Subject: Re: = [core] Handling tokens for No-response

 

Hi = Akbar,
Thank you = very much for sharing your views. Yes, both the situations are logically = similar excepting the fact that in the multicast case the decision is = taken by the server and in the later case client explicitly expresses = the disinterest in responses.


RegardsAbhijan Bhattacharyya
Associate Consultant
Scientist, Innovation = Lab, Kolkata, India
Tata Consultancy Services Limited
Mailto: abhijan.bhattacharyya@tcs.c= om
Website: http://www.tc= s.com
_________= ___________________________________
Experience certainty.   =      IT Services
          =              Business = Solutions
                =       =  Consulting
____________________________________________ =

= From:

"Rahman, = Akbar" <Akbar.Rahman@InterDigital.c= om>

= To:

"Abhijan = Bhattacharyya" <abhijan.bhattacharyya@tcs.c= om>

= Cc:

<core@ietf.org> =

= Date:

04/16/2014 = 10:50 AM

= Subject:

RE: [core] = Handling tokens for = No-response

 




Hi Abhijan,
 
 
I would prefer that the no-response token handling be left up to the = implementer to handle.  This is because there is already a few = other cases where a response may be suppressed by the server especially = for congestion control and multicast response suppression.  See for = example:
 
http://tool= s.ietf.org/html/draft-ietf-core-groupcomm-18#section-2.8 =
 
 
Best Regards,
 
 
Akbar
 
 
From:= = core [mailto:core-= bounces@ietf.org] On = Behalf Of Abhijan Bhattacharyya
Sent: Monday, April 14, = 2014 8:44 AM
To: core@ietf.org
Subject: = [core] Handling tokens for No-response
 
Hi = All,
A = comment received on the No-response option during the London meeting was = on to clarify how to handle the tokens for requests that are not going = to get any matching response. Specifically, concern was raised regarding = the reuse of a token. A token is used to match the response with the = corresponding request. Now, since no response is suppressing the request = from the server so a token in the request is never matched with any = response. Under such circumstance how to decide when to reuse a = token.

The = point was raised by Carsten. I had a very brief off-the-meeting = discussion with him on this and getting opinion on this matter in the = mailing list was suggested.
So, here = are some specific questions to the mailing list:

1. Is = the problem statement above really important enough to be dealt with in = the draft or should it be left upon the application developer to = handle?

(The = following ones are relevant if the answer to the above is an 'yes' for = proposing a solution. )
2. = Assuming that we need a precise direction in the draft to handle this, = would it be a good idea to suggest to use a zero-length token while = using No-response? (Of course, this cannot be a MUST considering the = fact that if someone wants use No-response with a GET request for = observe cancellation then the token must be there to identify the = correspondence with the original observe-GET. Please note: =  No-response is not defined for GET in the present draft but it = will be included in the next version keeping the observe cancellation = solution in mind )

3. Any = other idea?

Regards
Abhijan Bhattacharyya
Associate = Consultant
Scientist, Innovation Lab, Kolkata, India
Tata = Consultancy Services Limited
Mailto: abhijan.bhatt= acharyya@tcs.com
Website: = http://www.tc= s.com
_________= ___________________________________
Experience certainty.   =      IT Services
          =             Business Solutions
  =                     = Consulting
____________________________________________ =

=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D=
Notice: The information contained in this e-mail
message and/or = attachments to it may contain
confidential or privileged = information. If you are
not the intended recipient, any = dissemination, use,
review, distribution, printing or copying of the =
information contained in this e-mail message
and/or attachments = to it are strictly prohibited. If
you have received this = communication in error,
please notify us by reply e-mail or = telephone and
immediately and permanently delete the message
and = any attachments. Thank you

 

The= information contained in this message may be confidential and legally = protected under applicable law. The message is intended solely for the = addressee(s). If you are not the intended recipient, you are hereby = notified that any use, forwarding, dissemination, or reproduction of = this message is strictly prohibited and may be unlawful. If you are not = the intended recipient, please contact the sender by return e-mail and = destroy all copies of the original = message.

------_=_NextPart_001_01CF59A5.B828757E-- From nobody Thu Apr 17 03:15:08 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4F91A0090 for ; Thu, 17 Apr 2014 03:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.273 X-Spam-Level: X-Spam-Status: No, score=-0.273 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sY2_T9u7cRA for ; Thu, 17 Apr 2014 03:14:59 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 641581A001F for ; Thu, 17 Apr 2014 03:14:57 -0700 (PDT) Received: from WeiGengyuPC (unknown [10.103.240.20]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 0B5FC19F383; Thu, 17 Apr 2014 18:14:50 +0800 (HKT) Message-ID: From: "weigengyu" To: "Rahman, Akbar" , "Dijk, Esko" References: <031DD135F9160444ABBE3B0C36CED61816A146F1@AMSPRD9003MB066.MGDPHG.emi.philips.com> In-Reply-To: Date: Thu, 17 Apr 2014 18:14:51 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F1_01CF5A68.ECF595D0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Archived-At: http://mailarchive.ietf.org/arch/msg/core/YPKuf_dBo0Td_D-i7VvqvsX0KKw Cc: Abhijan Bhattacharyya , core@ietf.org Subject: Re: [core] Handling tokens for No-response X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 10:15:04 -0000 这是一封 MIME 格式的多方邮件。 ------=_NextPart_000_00F1_01CF5A68.ECF595D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi=EF=BC=8C=20 No response option seems to be a request/response (transaction) sublayer = staff.=20 A CON request with No Response option will also invoke a message = sublayer ack accoring to CoAP semantics,=20 so the traffic of message does not affect.=20 And I do not think that using Zero length Token is a good way to use . In some existing protocols, the transaction requestes are classified = into command request and not command and it is identified by one-bit.=20 My suggestion is to add one bit definition instead of using Zero length = Token.=20 And the significant time of Token should not change whether the No = Resopnse option is used.=20 Regards, Gengyu Network Technology Center School of Computer Beijing University of Posts and Telecommunications From: Rahman, Akbar=20 Sent: Thursday, April 17, 2014 2:57 AM To: Dijk, Esko=20 Cc: Abhijan Bhattacharyya ; core@ietf.org=20 Subject: Re: [core] Handling tokens for No-response Hi Esko, =20 =20 > 1. When sending a unicast CON request and no response is given or the = client asks for No-Response, I would think that the Token can be re-used = after EXCHANGE_LIFETIME. Is that right? =20 Yes, that would be my interpretation as well. =20 =20 > Suppose we would advise to use a zero-length (default) Token for such = requests =E2=80=93 wouldn=E2=80=99t there be the same problem of Token = re-use? I.e. I can only re-use the 0 Token after EXCHANGE_LIFETIME time = has passed. =20 Yes, good point! =20 =20 =20 /Akbar =20 =20 =20 =20 From: Dijk, Esko [mailto:esko.dijk@philips.com]=20 Sent: Wednesday, April 16, 2014 9:05 AM To: Abhijan Bhattacharyya; Rahman, Akbar Cc: core@ietf.org Subject: RE: [core] Handling tokens for No-response =20 Hello Abhijan, Akbar, =20 just thinking how a client would decide on Token re-use : there seem to = be 3 cases. =20 1. When sending a unicast CON request and no response is given or the = client asks for No-Response, I would think that the Token can be re-used = after EXCHANGE_LIFETIME. Is that right? 2. When sending a unicast NON request and no response is given or the = client asks for No-Response,I would assume Token can be re-used after = MAX_RTT. 3. When sending a multicast NON request, the Token can be re-used after = MAX_RTT in any case, even if some responses are already received. (There = could always be coming more responses within MAX_RTT so the request is = still =E2=80=98active=E2=80=99 in this sense.) =20 To make this simpler we could also say that Tokens can be safely re-used = after EXCHANGE_LIFETIME since always EXCHANGE_LIFETIME >=3D MAX_RTT. So I feel that this Token lifetime question is relevant for a wider = context than just related to the No-Response Option; like Akbar said = also. =20 Suppose we would advise to use a zero-length (default) Token for such = requests =E2=80=93 wouldn=E2=80=99t there be the same problem of Token = re-use? I.e. I can only re-use the 0 Token after EXCHANGE_LIFETIME time = has passed. =20 regards Esko =20 From: core [mailto:core-bounces@ietf.org] On Behalf Of Abhijan = Bhattacharyya Sent: Wednesday, April 16, 2014 11:42 To: Rahman, Akbar Cc: core@ietf.org Subject: Re: [core] Handling tokens for No-response =20 Hi Akbar,=20 Thank you very much for sharing your views. Yes, both the situations are = logically similar excepting the fact that in the multicast case the = decision is taken by the server and in the later case client explicitly = expresses the disinterest in responses.=20 Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________=20 From:=20 "Rahman, Akbar" =20 =20 To:=20 "Abhijan Bhattacharyya" =20 =20 Cc:=20 =20 =20 Date:=20 04/16/2014 10:50 AM=20 =20 Subject:=20 RE: [core] Handling tokens for No-response =20 =20 -------------------------------------------------------------------------= ------- Hi Abhijan,=20 =20 =20 I would prefer that the no-response token handling be left up to the = implementer to handle. This is because there is already a few other = cases where a response may be suppressed by the server especially for = congestion control and multicast response suppression. See for example: = =20 http://tools.ietf.org/html/draft-ietf-core-groupcomm-18#section-2.8=20 =20 =20 Best Regards,=20 =20 =20 Akbar=20 =20 =20 From: core [mailto:core-bounces@ietf.org] On Behalf Of Abhijan = Bhattacharyya Sent: Monday, April 14, 2014 8:44 AM To: core@ietf.org Subject: [core] Handling tokens for No-response=20 =20 Hi All,=20 A comment received on the No-response option during the London meeting = was on to clarify how to handle the tokens for requests that are not = going to get any matching response. Specifically, concern was raised = regarding the reuse of a token. A token is used to match the response = with the corresponding request. Now, since no response is suppressing = the request from the server so a token in the request is never matched = with any response. Under such circumstance how to decide when to reuse a = token.=20 The point was raised by Carsten. I had a very brief off-the-meeting = discussion with him on this and getting opinion on this matter in the = mailing list was suggested.=20 So, here are some specific questions to the mailing list:=20 1. Is the problem statement above really important enough to be dealt = with in the draft or should it be left upon the application developer to = handle?=20 (The following ones are relevant if the answer to the above is an 'yes' = for proposing a solution. )=20 2. Assuming that we need a precise direction in the draft to handle = this, would it be a good idea to suggest to use a zero-length token = while using No-response? (Of course, this cannot be a MUST considering = the fact that if someone wants use No-response with a GET request for = observe cancellation then the token must be there to identify the = correspondence with the original observe-GET. Please note: No-response = is not defined for GET in the present draft but it will be included in = the next version keeping the observe cancellation solution in mind )=20 3. Any other idea?=20 Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________=20 =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain=20 confidential or privileged information. If you are=20 not the intended recipient, any dissemination, use,=20 review, distribution, printing or copying of the=20 information contained in this e-mail message=20 and/or attachments to it are strictly prohibited. If=20 you have received this communication in error,=20 please notify us by reply e-mail or telephone and=20 immediately and permanently delete the message=20 and any attachments. Thank you=20 =20 -------------------------------------------------------------------------= ------- The information contained in this message may be confidential and = legally protected under applicable law. The message is intended solely = for the addressee(s). If you are not the intended recipient, you are = hereby notified that any use, forwarding, dissemination, or reproduction = of this message is strictly prohibited and may be unlawful. If you are = not the intended recipient, please contact the sender by return e-mail = and destroy all copies of the original message. -------------------------------------------------------------------------= ------- _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------=_NextPart_000_00F1_01CF5A68.ECF595D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Hi=EF=BC=8C
 
No response option seems to be a request/response (transaction) = sublayer=20 staff.
A CON request with No Response option will also invoke a message = sublayer=20 ack accoring to CoAP semantics,
so the traffic of message does not affect.
 
And I do not think that using Zero length Token is a good way to = use=20 .
In some existing protocols, the transaction requestes are = classified into=20 command request and not command and it is identified by one-bit.
 
My suggestion is to add one bit definition instead of using Zero = length=20 Token.
And the significant time of Token should not change whether the No = Resopnse=20 option is used.
 
 
Regards,
 
Gengyu
 
Network Technology = Center
School of Computer
Beijing University of Posts and=20 Telecommunications
 
From: Rahman, Akbar
Sent: Thursday, April 17, 2014 2:57 AM
Cc: Abhijan Bhattacharyya = ; core@ietf.org =
Subject: Re: [core] Handling tokens for=20 No-response
 

Hi=20 Esko,

 

 

>=20 1.=20 When sending a unicast CON request and no response is given or the = client asks=20 for No-Response, I would think that the Token can be re-used after=20 EXCHANGE_LIFETIME. Is that right?

 

Yes,=20 that would be my interpretation as well.

 

 

>=20 Suppose=20 we would advise to use a zero-length (default) Token for such requests = =E2=80=93=20 wouldn=E2=80=99t there be the same problem of Token re-use? I.e. I can = only re-use the 0=20 Token after EXCHANGE_LIFETIME time has passed.

 

Yes,=20 good point!

 

 

 

/Akbar

 

 

 

 

From: Dijk, = Esko=20 [mailto:esko.dijk@philips.com]
Sent: Wednesday, April 16, = 2014 9:05=20 AM
To: Abhijan Bhattacharyya; Rahman, Akbar
Cc:=20 core@ietf.org
Subject: RE: [core] Handling tokens for=20 No-response

 

Hello=20 Abhijan, Akbar,

 

just=20 thinking how a client would decide on Token re-use : there seem to be 3=20 cases.

 

1.=20 When sending a unicast CON request and no response is given or the = client asks=20 for No-Response, I would think that the Token can be re-used after=20 EXCHANGE_LIFETIME. Is that right?

2.=20 When sending a unicast NON request and no response is given or the = client asks=20 for No-Response,I would assume Token can be re-used after=20 MAX_RTT.

3.=20 When sending a multicast NON request, the Token can be re-used after = MAX_RTT in=20 any case, even if some responses are already received. (There could = always be=20 coming more responses within MAX_RTT so the request is still = =E2=80=98active=E2=80=99 in this=20 sense.)

 

To=20 make this simpler we could also say that Tokens can be safely re-used = after=20 EXCHANGE_LIFETIME since always EXCHANGE_LIFETIME >=3D=20 MAX_RTT.

So=20 I feel that this Token lifetime question is relevant for a wider context = than=20 just related to the No-Response Option; like Akbar said=20 also.

 

Suppose=20 we would advise to use a zero-length (default) Token for such requests = =E2=80=93=20 wouldn=E2=80=99t there be the same problem of Token re-use? I.e. I can = only re-use the 0=20 Token after EXCHANGE_LIFETIME time has passed.

 

regards

Esko

 

From: core [mailto:core-bounces@ietf.org] = On=20 Behalf Of Abhijan Bhattacharyya
Sent: Wednesday, April 16, = 2014=20 11:42
To: Rahman, Akbar
Cc: core@ietf.org
Subject: Re: = [core]=20 Handling tokens for No-response

 

Hi = Akbar,=20
Thank you=20 very much for sharing your views. Yes, both the situations are logically = similar=20 excepting the fact that in the multicast case the decision is taken by = the=20 server and in the later case client explicitly expresses the disinterest = in=20 responses.


Regards
Abhijan=20 Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, = Kolkata,=20 India
Tata Consultancy Services Limited
Mailto: abhijan.bhattacharyya@tcs.c= om
Website:=20 http://www.tcs.com
____________________________________________Experience=20 certainty.        IT=20 Services
          &= nbsp;           =20 Business=20 Solutions
          =              = Consulting
____________________________________________=20

From:=20

"Rahman,=20 Akbar" <Akbar.Rahman@InterDigital.c= om>=20

To:=20

"Abhijan=20 Bhattacharyya" <abhijan.bhattacharyya@tcs.c= om>=20

Cc:=20

<core@ietf.org>=20

Date:=20

04/16/2014=20 10:50 AM

Subject:=20

RE: = [core]=20 Handling tokens for = No-response

 




Hi=20 Abhijan,
 =20
 =20
I=20 would prefer that the no-response token handling be left up to the = implementer=20 to handle.  This is because there is already a few other cases = where a=20 response may be suppressed by the server especially for congestion = control and=20 multicast response suppression.  See for example:
 =20
http://tools.ietf.org/html/draft-ietf-core-groupc= omm-18#section-2.8=20
 =20
 =20
Best=20 Regards,
 =20
 =20
Akbar=20
 =20
 =20
From: core = [mailto:core-bounces@ietf.org] On = Behalf Of=20 Abhijan Bhattacharyya
Sent: Monday, April 14, 2014 8:44=20 AM
To: core@ietf.org
Subject: = [core] Handling=20 tokens for No-response
 
Hi = All,
A = comment=20 received on the No-response option during the London meeting was on to = clarify=20 how to handle the tokens for requests that are not going to get any = matching=20 response. Specifically, concern was raised regarding the reuse of a = token. A=20 token is used to match the response with the corresponding request. Now, = since=20 no response is suppressing the request from the server so a token in the = request=20 is never matched with any response. Under such circumstance how to = decide when=20 to reuse a token.

The = point was=20 raised by Carsten. I had a very brief off-the-meeting discussion with = him on=20 this and getting opinion on this matter in the mailing list was=20 suggested.
So, = here are some=20 specific questions to the mailing list:

1. Is = the problem=20 statement above really important enough to be dealt with in the draft or = should=20 it be left upon the application developer to handle?

(The = following=20 ones are relevant if the answer to the above is an 'yes' for proposing a = solution. )
2. = Assuming that=20 we need a precise direction in the draft to handle this, would it be a = good idea=20 to suggest to use a zero-length token while using No-response? (Of = course, this=20 cannot be a MUST considering the fact that if someone wants use = No-response with=20 a GET request for observe cancellation then the token must be there to = identify=20 the correspondence with the original observe-GET. Please note:  = No-response=20 is not defined for GET in the present draft but it will be included in = the next=20 version keeping the observe cancellation solution in mind ) =

3. Any = other=20 idea?

Regards
Abhijan Bhattacharyya
Associate=20 Consultant
Scientist, Innovation Lab, Kolkata, India
Tata = Consultancy=20 Services Limited
Mailto: abhijan.bhattacharyya@tcs.com
Website:=20 http://www.tcs.com
____________________________________________Experience=20 certainty.        IT=20 Services
          &= nbsp;          =20 Business=20 Solutions
          =            =20 Consulting
____________________________________________=20

=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
Notice: = The information contained in this=20 e-mail
message and/or attachments to it may contain
confidential = or=20 privileged information. If you are
not the intended recipient, any=20 dissemination, use,
review, distribution, printing or copying of the =
information contained in this e-mail message
and/or attachments = to it=20 are strictly prohibited. If
you have received this communication in = error,=20
please notify us by reply e-mail or telephone and
immediately = and=20 permanently delete the message
and any attachments. Thank you=20

 

The=20 information contained in this message may be confidential and legally = protected=20 under applicable law. The message is intended solely for the = addressee(s). If=20 you are not the intended recipient, you are hereby notified that any = use,=20 forwarding, dissemination, or reproduction of this message is strictly=20 prohibited and may be unlawful. If you are not the intended recipient, = please=20 contact the sender by return e-mail and destroy all copies of the = original=20 message.

_______________________________________________
core mailing=20 list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
------=_NextPart_000_00F1_01CF5A68.ECF595D0-- From nobody Thu Apr 17 05:22:37 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723BE1A012B for ; Thu, 17 Apr 2014 05:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IObLOziBN7_L for ; Thu, 17 Apr 2014 05:22:28 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF4B1A0118 for ; Thu, 17 Apr 2014 05:22:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,879,1389724200"; d="scan'208";a="524215967" X-DISCLAIMER: FALSE Received: from INKOLSALDLPMTA1.india.tcs.com (unknown [127.0.0.1]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 46E5FDAC12; Thu, 17 Apr 2014 17:52:18 +0530 (IST) Received: from InKolM02.tcs.com (unknown [172.18.18.104]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 03F15DAC02; Thu, 17 Apr 2014 17:52:18 +0530 (IST) In-Reply-To: References: <031DD135F9160444ABBE3B0C36CED61816A146F1@AMSPRD9003MB066.MGDPHG.emi.philips.com> To: "weigengyu" , "Dijk, Esko" , "Rahman, Akbar" MIME-Version: 1.0 X-KeepSent: DC0CC0CF:898F2B17-65257CBD:003F6700; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0 March 08, 2013 From: Abhijan Bhattacharyya Message-ID: Date: Thu, 17 Apr 2014 17:52:15 +0530 X-MIMETrack: Serialize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 04/17/2014 17:52:17, Serialize complete at 04/17/2014 17:52:17, Serialize by Router on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 04/17/2014 17:52:17 Content-Type: multipart/alternative; boundary="=_alternative 0043DD3C65257CBD_=" Archived-At: http://mailarchive.ietf.org/arch/msg/core/Mp2mI2bXxQrdxbxms_dsgHWiG88 Cc: core@ietf.org Subject: Re: [core] Handling tokens for No-response X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 12:22:33 -0000 This is a multipart message in MIME format. --=_alternative 0043DD3C65257CBD_= Content-Type: text/plain; charset="ISO-2022-JP" Hi Akbar, Esko, Gengyu, Thanks for sharing your thoughts. The No-response option is currently defined only for NON requests. As rightly pointed out by Gengyu, using No-response for CON does not really save us on the traffic, etc. However, it might be useful to use No-response with CON for separate-response. But, that is not included in the draft as we did not envision a fitting use case for such a use of No-response. We cannot, as a general proposition, get rid of tokens while using No-response considering potential use of this option with a GET for proactive cancellation of an observe session (Ref: <1> section 3.8 of draft-ietf-core-observe-13 and <2> http://www.ietf.org/mail-archive/web/core/current/msg05331.html). A GET request to cancel an observe session must carry a token to associate itself with the existing observe session. So, as elaborated by Esko, possibly it would be good to suggest some time-out (so its a MAY and not a MUST to give flexibility to the application developer as pointed out by Akbar ). The present draft adapts the definition of NON_LIFETIME as the reuse interval for message IDs. Would it be a good idea to adapt the same definition as the re-use interval for tokens also? The definition of NON_LIFETIME encompasses EXCHANGE_LIFETIME as well. Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ From: "weigengyu" To: "Rahman, Akbar" , "Dijk, Esko" Cc: "Abhijan Bhattacharyya" , Date: 04/17/2014 03:44 PM Subject: Re: [core] Handling tokens for No-response Hi$B!$(B No response option seems to be a request/response (transaction) sublayer staff. A CON request with No Response option will also invoke a message sublayer ack accoring to CoAP semantics, so the traffic of message does not affect. And I do not think that using Zero length Token is a good way to use . In some existing protocols, the transaction requestes are classified into command request and not command and it is identified by one-bit. My suggestion is to add one bit definition instead of using Zero length Token. And the significant time of Token should not change whether the No Resopnse option is used. Regards, Gengyu Network Technology Center School of Computer Beijing University of Posts and Telecommunications From: Rahman, Akbar Sent: Thursday, April 17, 2014 2:57 AM To: Dijk, Esko Cc: Abhijan Bhattacharyya ; core@ietf.org Subject: Re: [core] Handling tokens for No-response Hi Esko, > 1. When sending a unicast CON request and no response is given or the client asks for No-Response, I would think that the Token can be re-used after EXCHANGE_LIFETIME. Is that right? Yes, that would be my interpretation as well. > Suppose we would advise to use a zero-length (default) Token for such requests $B!>(B wouldn$B!G(Bt there be the same problem of Token re-use? I.e. I can only re-use the 0 Token after EXCHANGE_LIFETIME time has passed. Yes, good point! /Akbar From: Dijk, Esko [mailto:esko.dijk@philips.com] Sent: Wednesday, April 16, 2014 9:05 AM To: Abhijan Bhattacharyya; Rahman, Akbar Cc: core@ietf.org Subject: RE: [core] Handling tokens for No-response Hello Abhijan, Akbar, just thinking how a client would decide on Token re-use : there seem to be 3 cases. 1. When sending a unicast CON request and no response is given or the client asks for No-Response, I would think that the Token can be re-used after EXCHANGE_LIFETIME. Is that right? 2. When sending a unicast NON request and no response is given or the client asks for No-Response,I would assume Token can be re-used after MAX_RTT. 3. When sending a multicast NON request, the Token can be re-used after MAX_RTT in any case, even if some responses are already received. (There could always be coming more responses within MAX_RTT so the request is still $B!F(Bactive$B!G(B in this sense.) To make this simpler we could also say that Tokens can be safely re-used after EXCHANGE_LIFETIME since always EXCHANGE_LIFETIME >= MAX_RTT. So I feel that this Token lifetime question is relevant for a wider context than just related to the No-Response Option; like Akbar said also. Suppose we would advise to use a zero-length (default) Token for such requests $B!>(B wouldn$B!G(Bt there be the same problem of Token re-use? I.e. I can only re-use the 0 Token after EXCHANGE_LIFETIME time has passed. regards Esko From: core [mailto:core-bounces@ietf.org] On Behalf Of Abhijan Bhattacharyya Sent: Wednesday, April 16, 2014 11:42 To: Rahman, Akbar Cc: core@ietf.org Subject: Re: [core] Handling tokens for No-response Hi Akbar, Thank you very much for sharing your views. Yes, both the situations are logically similar excepting the fact that in the multicast case the decision is taken by the server and in the later case client explicitly expresses the disinterest in responses. Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ From: "Rahman, Akbar" To: "Abhijan Bhattacharyya" Cc: Date: 04/16/2014 10:50 AM Subject: RE: [core] Handling tokens for No-response Hi Abhijan, I would prefer that the no-response token handling be left up to the implementer to handle. This is because there is already a few other cases where a response may be suppressed by the server especially for congestion control and multicast response suppression. See for example: http://tools.ietf.org/html/draft-ietf-core-groupcomm-18#section-2.8 Best Regards, Akbar From: core [mailto:core-bounces@ietf.org] On Behalf Of Abhijan Bhattacharyya Sent: Monday, April 14, 2014 8:44 AM To: core@ietf.org Subject: [core] Handling tokens for No-response Hi All, A comment received on the No-response option during the London meeting was on to clarify how to handle the tokens for requests that are not going to get any matching response. Specifically, concern was raised regarding the reuse of a token. A token is used to match the response with the corresponding request. Now, since no response is suppressing the request from the server so a token in the request is never matched with any response. Under such circumstance how to decide when to reuse a token. The point was raised by Carsten. I had a very brief off-the-meeting discussion with him on this and getting opinion on this matter in the mailing list was suggested. So, here are some specific questions to the mailing list: 1. Is the problem statement above really important enough to be dealt with in the draft or should it be left upon the application developer to handle? (The following ones are relevant if the answer to the above is an 'yes' for proposing a solution. ) 2. Assuming that we need a precise direction in the draft to handle this, would it be a good idea to suggest to use a zero-length token while using No-response? (Of course, this cannot be a MUST considering the fact that if someone wants use No-response with a GET request for observe cancellation then the token must be there to identify the correspondence with the original observe-GET. Please note: No-response is not defined for GET in the present draft but it will be included in the next version keeping the observe cancellation solution in mind ) 3. Any other idea? Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core --=_alternative 0043DD3C65257CBD_= Content-Type: text/html; charset="ISO-2022-JP" Hi Akbar, Esko, Gengyu,

Thanks for sharing your thoughts.
The No-response option is currently defined only for NON requests. As rightly pointed out by Gengyu, using No-response for CON does not really save us on the traffic, etc. However, it might be useful to use No-response with CON for separate-response. But, that is not included in the draft as we did not envision a fitting use case for such a use of No-response.

We cannot, as a general proposition, get rid of tokens while using No-response considering potential use of this option with a GET  for proactive cancellation of an observe session (Ref: <1> section 3.8 of draft-ietf-core-observe-13 and <2> http://www.ietf.org/mail-archive/web/core/current/msg05331.html).  A GET request to cancel an observe session must carry a token to associate itself with the existing observe session.

So, as elaborated by Esko, possibly it would be good to suggest some time-out (so its a MAY and not a MUST to give flexibility to the application developer as pointed out by Akbar ). The present draft adapts the definition of NON_LIFETIME as the reuse interval for message IDs. Would it be a good idea to adapt the same definition as the re-use interval for tokens also? The definition of NON_LIFETIME encompasses EXCHANGE_LIFETIME as well.


Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services Limited
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Consulting
____________________________________________


From: "weigengyu" <weigengyu@bupt.edu.cn>
To: "Rahman, Akbar" <Akbar.Rahman@InterDigital.com>, "Dijk, Esko" <esko.dijk@philips.com>
Cc: "Abhijan Bhattacharyya" <abhijan.bhattacharyya@tcs.com>, <core@ietf.org>
Date: 04/17/2014 03:44 PM
Subject: Re: [core] Handling tokens for No-response




Hi$B!$(B
 
No response option seems to be a request/response (transaction) sublayer staff.
A CON request with No Response option will also invoke a message sublayer ack accoring to CoAP semantics,
so the traffic of message does not affect.
 
And I do not think that using Zero length Token is a good way to use .
In some existing protocols, the transaction requestes are classified into command request and not command and it is identified by one-bit.
 
My suggestion is to add one bit definition instead of using Zero length Token.
And the significant time of Token should not change whether the No Resopnse option is used.
 
 
Regards,
 
Gengyu
 
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
 
From: Rahman, Akbar
Sent: Thursday, April 17, 2014 2:57 AM
To: Dijk, Esko
Cc: Abhijan Bhattacharyya ; core@ietf.org
Subject: Re: [core] Handling tokens for No-response
 
Hi Esko,
 
 
> 1. When sending a unicast CON request and no response is given or the client asks for No-Response, I would think that the Token can be re-used after EXCHANGE_LIFETIME. Is that right?
 
Yes, that would be my interpretation as well.
 
 
> Suppose we would advise to use a zero-length (default) Token for such requests $B!>(B wouldn$B!G(Bt there be the same problem of Token re-use? I.e. I can only re-use the 0 Token after EXCHANGE_LIFETIME time has passed.
 
Yes, good point!
 
 
 
/Akbar
 
 
 
 
From: Dijk, Esko [mailto:esko.dijk@philips.com]
Sent: Wednesday, April 16, 2014 9:05 AM
To: Abhijan Bhattacharyya; Rahman, Akbar
Cc: core@ietf.org
Subject: RE: [core] Handling tokens for No-response
 
Hello Abhijan, Akbar,
 
just thinking how a client would decide on Token re-use : there seem to be 3 cases.
 
1. When sending a unicast CON request and no response is given or the client asks for No-Response, I would think that the Token can be re-used after EXCHANGE_LIFETIME. Is that right?
2. When sending a unicast NON request and no response is given or the client asks for No-Response,I would assume Token can be re-used after MAX_RTT.
3. When sending a multicast NON request, the Token can be re-used after MAX_RTT in any case, even if some responses are already received. (There could always be coming more responses within MAX_RTT so the request is still $B!F(Bactive$B!G(B in this sense.)
 
To make this simpler we could also say that Tokens can be safely re-used after EXCHANGE_LIFETIME since always EXCHANGE_LIFETIME >= MAX_RTT.
So I feel that this Token lifetime question is relevant for a wider context than just related to the No-Response Option; like Akbar said also.
 
Suppose we would advise to use a zero-length (default) Token for such requests $B!>(B wouldn$B!G(Bt there be the same problem of Token re-use? I.e. I can only re-use the 0 Token after EXCHANGE_LIFETIME time has passed.
 
regards
Esko
 
From: core [mailto:core-bounces@ietf.org] On Behalf Of Abhijan Bhattacharyya
Sent: Wednesday, April 16, 2014 11:42
To: Rahman, Akbar
Cc: core@ietf.org
Subject: Re: [core] Handling tokens for No-response
 
Hi Akbar,
Thank you very much for sharing your views. Yes, both the situations are logically similar excepting the fact that in the multicast case the decision is taken by the server and in the later case client explicitly expresses the disinterest in responses.


Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services Limited
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                      Business Solutions
                      Consulting
____________________________________________

From: "Rahman, Akbar" <Akbar.Rahman@InterDigital.com>
To: "Abhijan Bhattacharyya" <abhijan.bhattacharyya@tcs.com>
Cc: <core@ietf.org>
Date: 04/16/2014 10:50 AM
Subject: RE: [core] Handling tokens for No-response

 





Hi Abhijan,
 
 
I would prefer that the no-response token handling be left up to the implementer to handle.  This is because there is already a few other cases where a response may be suppressed by the server especially for congestion control and multicast response suppression.  See for example:
 
http://tools.ietf.org/html/draft-ietf-core-groupcomm-18#section-2.8
 
 
Best Regards,
 
 
Akbar
 
 
From: core [mailto:core-bounces@ietf.org] On Behalf Of Abhijan Bhattacharyya
Sent: Monday, April 14, 2014 8:44 AM
To: core@ietf.org
Subject: [core] Handling tokens for No-response
 
Hi All,
A comment received on the No-response option during the London meeting was on to clarify how to handle the tokens for requests that are not going to get any matching response. Specifically, concern was raised regarding the reuse of a token. A token is used to match the response with the corresponding request. Now, since no response is suppressing the request from the server so a token in the request is never matched with any response. Under such circumstance how to decide when to reuse a token.

The point was raised by Carsten. I had a very brief off-the-meeting discussion with him on this and getting opinion on this matter in the mailing list was suggested.
So, here are some specific questions to the mailing list:

1. Is the problem statement above really important enough to be dealt with in the draft or should it be left upon the application developer to handle?

(The following ones are relevant if the answer to the above is an 'yes' for proposing a solution. )
2. Assuming that we need a precise direction in the draft to handle this, would it be a good idea to suggest to use a zero-length token while using No-response? (Of course, this cannot be a MUST considering the fact that if someone wants use No-response with a GET request for observe cancellation then the token must be there to identify the correspondence with the original observe-GET. Please note:  No-response is not defined for GET in the present draft but it will be included in the next version keeping the observe cancellation solution in mind )

3. Any other idea?

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services Limited
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                     Business Solutions
                     Consulting
____________________________________________

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
 


The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

--=_alternative 0043DD3C65257CBD_=-- From nobody Thu Apr 17 06:08:49 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73201A0144 for ; Thu, 17 Apr 2014 06:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoKJsUoQMRM6 for ; Thu, 17 Apr 2014 06:08:43 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id C4E4C1A013C for ; Thu, 17 Apr 2014 06:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s3HD8Snx000678; Thu, 17 Apr 2014 15:08:28 +0200 (CEST) Received: from [192.168.217.148] (p5489293D.dip0.t-ipconnect.de [84.137.41.61]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B68261563; Thu, 17 Apr 2014 15:08:25 +0200 (CEST) Content-Type: text/plain; charset=iso-2022-jp-2 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Carsten Bormann In-Reply-To: Date: Thu, 17 Apr 2014 15:08:23 +0200 X-Mao-Original-Outgoing-Id: 419432903.302807-2e411cc84b555c23d00a1f235a0cab0b Content-Transfer-Encoding: quoted-printable Message-Id: References: <031DD135F9160444ABBE3B0C36CED61816A146F1@AMSPRD9003MB066.MGDPHG.emi.philips.com> To: Abhijan Bhattacharyya X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/core/bWL0ZAFUGtUharSAxonAeW_m8_k Cc: core@ietf.org Subject: Re: [core] Handling tokens for No-response X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 13:08:47 -0000 On 17 Apr 2014, at 14:22, Abhijan Bhattacharyya = wrote: > We cannot, as a general proposition, get rid of tokens while using = No-response considering potential use of this option with a GET for = proactive cancellation of an observe session (Ref: <1> section 3.8 of = draft-ietf-core-observe-13 and = <2>http://www.ietf.org/mail-archive/web/core/current/msg05331.html). A = GET request to cancel an observe session must carry a token to associate = itself with the existing observe session.=20 While this is true, this is not the point that I was making. I was pointing out that a request that is defined in such a way that it = MAY elicit a response (depending on some condition unknown to the client = at the time) generates hardship for the client, because in the absence = of a response it does not know whether it can retire the token or still = has to expect a response for that. Now if the client does not care about whether any response coming back = is related back to the right request, it can reuse tokens at liberty. (Including the zero-length token, which is in no way special, except = that it is indeed shorter than any other token.) > So, as elaborated by Esko, possibly it would be good to suggest some = time-out (so its a MAY and not a MUST to give flexibility to the = application developer as pointed out by Akbar ). The present draft = adapts the definition of NON_LIFETIME as the reuse interval for message = IDs. Would it be a good idea to adapt the same definition as the re-use = interval for tokens also? The definition of NON_LIFETIME encompasses = EXCHANGE_LIFETIME as well.=20 In CoAP, we have timers at the message layer, not at the = request/response layer. Most clients will have a =1B$B!H=1B(Bpatience=1B$B!I=1B(B up to which = they will expect a response, but we currently do not expose this at the = protocol level. (With some new option, the client could pose a deadline to the server, = or the server could promise a deadline to the client. http://tools.ietf.org/html/draft-bormann-coap-misc-26#appendix-B.4 has = more about that.) Gr=1B.A=1BN|=1BN_e, Carsten From nobody Thu Apr 17 08:51:30 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677C21A024E for ; Thu, 17 Apr 2014 08:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.055 X-Spam-Level: * X-Spam-Status: No, score=1.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M_IAl2UhsxOM for ; Thu, 17 Apr 2014 08:51:22 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE481A013F for ; Thu, 17 Apr 2014 08:51:21 -0700 (PDT) Received: from WeiGengyuPC (unknown [222.131.10.27]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id B397919F374; Thu, 17 Apr 2014 23:51:15 +0800 (HKT) Message-ID: From: "weigengyu" To: "Carsten Bormann" , "Abhijan Bhattacharyya" References: <031DD135F9160444ABBE3B0C36CED61816A146F1@AMSPRD9003MB066.MGDPHG.emi.philips.com> In-Reply-To: Date: Thu, 17 Apr 2014 23:51:15 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="gb2312"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Archived-At: http://mailarchive.ietf.org/arch/msg/core/HPpANG1Eb_IadNzosqlT24HAuWs Cc: core@ietf.org Subject: Re: [core] Handling tokens for No-response X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 15:51:26 -0000 Hi all, In CoAP -18, page 34. " An empty token value is appropriate e.g. when no other tokens are in use to a destination, or when requests are made serially per destination and receive piggy-backed responses. There are however multiple possible implementation strategies to fulfill this." Does "An empty token value" mean "zero token length"? Do it try to overload "no other tokens are in use to a destination" by No Response option? Regards, Gengyu Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Carsten Bormann Sent: Thursday, April 17, 2014 9:08 PM To: Abhijan Bhattacharyya Cc: weigengyu ; Dijk, Esko ; Rahman, Akbar ; core@ietf.org Subject: Re: [core] Handling tokens for No-response On 17 Apr 2014, at 14:22, Abhijan Bhattacharyya wrote: > We cannot, as a general proposition, get rid of tokens while using > No-response considering potential use of this option with a GET for > proactive cancellation of an observe session (Ref: <1> section 3.8 of > draft-ietf-core-observe-13 and > <2>http://www.ietf.org/mail-archive/web/core/current/msg05331.html). A > GET request to cancel an observe session must carry a token to associate > itself with the existing observe session. While this is true, this is not the point that I was making. I was pointing out that a request that is defined in such a way that it MAY elicit a response (depending on some condition unknown to the client at the time) generates hardship for the client, because in the absence of a response it does not know whether it can retire the token or still has to expect a response for that. Now if the client does not care about whether any response coming back is related back to the right request, it can reuse tokens at liberty. (Including the zero-length token, which is in no way special, except that it is indeed shorter than any other token.) > So, as elaborated by Esko, possibly it would be good to suggest some > time-out (so its a MAY and not a MUST to give flexibility to the > application developer as pointed out by Akbar ). The present draft adapts > the definition of NON_LIFETIME as the reuse interval for message IDs. > Would it be a good idea to adapt the same definition as the re-use > interval for tokens also? The definition of NON_LIFETIME encompasses > EXCHANGE_LIFETIME as well. In CoAP, we have timers at the message layer, not at the request/response layer. Most clients will have a $B!H(Bpatience$B!I(B up to which they will expect a response, but we currently do not expose this at the protocol level. (With some new option, the client could pose a deadline to the server, or the server could promise a deadline to the client. http://tools.ietf.org/html/draft-bormann-coap-misc-26#appendix-B.4 has more about that.) Gr.AN|N_e, Carsten From nobody Mon Apr 21 23:53:48 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D051A00D8 for ; Mon, 21 Apr 2014 23:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4z7ZLTgabbKu for ; Mon, 21 Apr 2014 23:53:42 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2A51A00BF for ; Mon, 21 Apr 2014 23:53:40 -0700 (PDT) Received: from mail142-ch1-R.bigfish.com (10.43.68.251) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.22; Tue, 22 Apr 2014 06:52:38 +0000 Received: from mail142-ch1 (localhost [127.0.0.1]) by mail142-ch1-R.bigfish.com (Postfix) with ESMTP id 372994C0354; Tue, 22 Apr 2014 06:52:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:206.191.242.69; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:error; EFVD:FOP X-SpamScore: -28 X-BigFish: VPS-28(zz98dI15d6O542I9251I217bIdd85kzz1f42h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2dh109h2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25f6h2605h262fh268bh26d3h1155h) Received: from mail142-ch1 (localhost.localdomain [127.0.0.1]) by mail142-ch1 (MessageSwitch) id 1398149556408365_16463; Tue, 22 Apr 2014 06:52:36 +0000 (UTC) Received: from CH1EHSMHS029.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.239]) by mail142-ch1.bigfish.com (Postfix) with ESMTP id 5F6284006B; Tue, 22 Apr 2014 06:52:36 +0000 (UTC) Received: from mail.philips.com (206.191.242.69) by CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 22 Apr 2014 06:52:34 +0000 Received: from AMSPRD9003MB066.MGDPHG.emi.philips.com ([169.254.5.172]) by AMSPRD9003HT002.MGDPHG.emi.philips.com ([141.251.33.79]) with mapi id 14.16.0423.000; Tue, 22 Apr 2014 06:53:30 +0000 From: "Dijk, Esko" To: Carsten Bormann , Abhijan Bhattacharyya Thread-Topic: [core] Handling tokens for No-response Thread-Index: AQHPV98vDTgRdHJfpkqigWMEJ8EFKZsTthiAgABKdwCAADR9UIAAZc4ggAEBJICAACOYgIAADOSAgAdvEHA= Date: Tue, 22 Apr 2014 06:53:29 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED61816A14E84@AMSPRD9003MB066.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED61816A146F1@AMSPRD9003MB066.MGDPHG.emi.philips.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [88.128.80.103] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/core/2IB4Ay8jm7ajcZtLdwUfYjQbBIk Cc: "core@ietf.org" Subject: Re: [core] Handling tokens for No-response X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 06:53:47 -0000 Hi, if there's no time limit that can be defined for Token re-use, what time wo= uld an implementer of a client need to choose? (I know we chose not to de= fine 'patience' in CoAP, but an implementer would still need to make a sane= choice here.) Can we argue that Patience i.e. max response delay will be "= a few minutes" and hence Token can be re-used safely after a time far longe= r than that, say 15 minutes? For those cases where the implementer of the CoAP client knows that a respo= nse may take very long (e.g. see OMA LWM2M case, "queue mode" function, whe= re a response could take e.g. one day) he could adapt the Patience to somet= hing much longer. Would that be a feasible approach? I feel that it would be beneficial if the No-Response draft would say somet= hing about this Token re-use for unicast and multicast NON requests. If se= veral people in the CoRE WG saw it wrong, it may be worth pointing out as w= ell to a non-CoRE audience ;) Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Thursday, April 17, 2014 15:08 To: Abhijan Bhattacharyya Cc: weigengyu; Dijk, Esko; Rahman, Akbar; core@ietf.org Subject: Re: [core] Handling tokens for No-response On 17 Apr 2014, at 14:22, Abhijan Bhattacharyya wrote: > We cannot, as a general proposition, get rid of tokens while using No-res= ponse considering potential use of this option with a GET for proactive ca= ncellation of an observe session (Ref: <1> section 3.8 of draft-ietf-core-o= bserve-13 and <2>http://www.ietf.org/mail-archive/web/core/current/msg05331= .html). A GET request to cancel an observe session must carry a token to a= ssociate itself with the existing observe session. While this is true, this is not the point that I was making. I was pointing out that a request that is defined in such a way that it MAY= elicit a response (depending on some condition unknown to the client at th= e time) generates hardship for the client, because in the absence of a resp= onse it does not know whether it can retire the token or still has to expec= t a response for that. Now if the client does not care about whether any response coming back is r= elated back to the right request, it can reuse tokens at liberty. (Including the zero-length token, which is in no way special, except that i= t is indeed shorter than any other token.) > So, as elaborated by Esko, possibly it would be good to suggest some time= -out (so its a MAY and not a MUST to give flexibility to the application de= veloper as pointed out by Akbar ). The present draft adapts the definition = of NON_LIFETIME as the reuse interval for message IDs. Would it be a good i= dea to adapt the same definition as the re-use interval for tokens also? Th= e definition of NON_LIFETIME encompasses EXCHANGE_LIFETIME as well. In CoAP, we have timers at the message layer, not at the request/response l= ayer. Most clients will have a "patience" up to which they will expect a response= , but we currently do not expose this at the protocol level. (With some new option, the client could pose a deadline to the server, or t= he server could promise a deadline to the client. http://tools.ietf.org/html/draft-bormann-coap-misc-26#appendix-B.4 has more= about that.) Gr=1B.A=1BN|=1BN_e, Carsten ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From nobody Tue Apr 22 02:34:33 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660501A01B2 for ; Tue, 22 Apr 2014 02:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f15G8BZA0BtD for ; Tue, 22 Apr 2014 02:34:28 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 50E2D1A004E for ; Tue, 22 Apr 2014 02:34:28 -0700 (PDT) Received: from mail109-ch1-R.bigfish.com (10.43.68.254) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.22; Tue, 22 Apr 2014 09:33:24 +0000 Received: from mail109-ch1 (localhost [127.0.0.1]) by mail109-ch1-R.bigfish.com (Postfix) with ESMTP id 9490F100327; Tue, 22 Apr 2014 09:33:24 +0000 (UTC) X-Forefront-Antispam-Report: CIP:206.191.242.69; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:error; EFVD:FOP X-SpamScore: -28 X-BigFish: VPS-28(zz98dI15d6O542I9251I217bIdd85kzz1f42h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2dh109h2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25f6h2605h262fh268bh26d3h1155h) Received: from mail109-ch1 (localhost.localdomain [127.0.0.1]) by mail109-ch1 (MessageSwitch) id 1398159202404903_20878; Tue, 22 Apr 2014 09:33:22 +0000 (UTC) Received: from CH1EHSMHS031.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.227]) by mail109-ch1.bigfish.com (Postfix) with ESMTP id 544ED4E008B; Tue, 22 Apr 2014 09:33:22 +0000 (UTC) Received: from mail.philips.com (206.191.242.69) by CH1EHSMHS031.bigfish.com (10.43.70.31) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 22 Apr 2014 09:33:22 +0000 Received: from AMSPRD9003MB066.MGDPHG.emi.philips.com ([169.254.5.172]) by AMSPRD9003HT001.MGDPHG.emi.philips.com ([141.251.33.78]) with mapi id 14.16.0423.000; Tue, 22 Apr 2014 09:34:16 +0000 From: "Dijk, Esko" To: Abhijan Bhattacharyya Thread-Topic: [core] Handling tokens for No-response Thread-Index: AQHPV98vDTgRdHJfpkqigWMEJ8EFKZsTthiAgABKdwCAADR9UIAAZc4ggAEBJICAACOYgIAADOSAgAdvEHCAAC9sYA== Date: Tue, 22 Apr 2014 09:34:15 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED61816A1507A@AMSPRD9003MB066.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED61816A146F1@AMSPRD9003MB066.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED61816A14E84@AMSPRD9003MB066.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED61816A14E84@AMSPRD9003MB066.MGDPHG.emi.philips.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/core/OYojKLDFxhQ5402ntoHSvR13kqU Cc: "core@ietf.org" Subject: Re: [core] Handling tokens for No-response X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 09:34:32 -0000 Hello Abhijan, I forgot to mention that using the No-Response Option is not a guarantee t= hat no response will come. It actually MAY come since the Option is electiv= e. That is something that needs to be taken into account by a client in its To= ken re-use strategy. If not it leads to interoperability issues, or not? E= .g. "client expects no answer to its request with Token=3D0, so it sends ou= t a new request with Token=3D0, but server does not recognize No-Response o= ption, and sends a response, then the client receives the old delayed respo= nse with Token=3D0 instead of the newer response with same Token". Esko -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Dijk, Esko Sent: Tuesday, April 22, 2014 08:53 To: Carsten Bormann; Abhijan Bhattacharyya Cc: core@ietf.org Subject: Re: [core] Handling tokens for No-response Hi, if there's no time limit that can be defined for Token re-use, what time wo= uld an implementer of a client need to choose? (I know we chose not to de= fine 'patience' in CoAP, but an implementer would still need to make a sane= choice here.) Can we argue that Patience i.e. max response delay will be "= a few minutes" and hence Token can be re-used safely after a time far longe= r than that, say 15 minutes? For those cases where the implementer of the CoAP client knows that a respo= nse may take very long (e.g. see OMA LWM2M case, "queue mode" function, whe= re a response could take e.g. one day) he could adapt the Patience to somet= hing much longer. Would that be a feasible approach? I feel that it would be beneficial if the No-Response draft would say somet= hing about this Token re-use for unicast and multicast NON requests. If se= veral people in the CoRE WG saw it wrong, it may be worth pointing out as w= ell to a non-CoRE audience ;) Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Thursday, April 17, 2014 15:08 To: Abhijan Bhattacharyya Cc: weigengyu; Dijk, Esko; Rahman, Akbar; core@ietf.org Subject: Re: [core] Handling tokens for No-response On 17 Apr 2014, at 14:22, Abhijan Bhattacharyya wrote: > We cannot, as a general proposition, get rid of tokens while using No-res= ponse considering potential use of this option with a GET for proactive ca= ncellation of an observe session (Ref: <1> section 3.8 of draft-ietf-core-o= bserve-13 and <2>http://www.ietf.org/mail-archive/web/core/current/msg05331= .html). A GET request to cancel an observe session must carry a token to a= ssociate itself with the existing observe session. While this is true, this is not the point that I was making. I was pointing out that a request that is defined in such a way that it MAY= elicit a response (depending on some condition unknown to the client at th= e time) generates hardship for the client, because in the absence of a resp= onse it does not know whether it can retire the token or still has to expec= t a response for that. Now if the client does not care about whether any response coming back is r= elated back to the right request, it can reuse tokens at liberty. (Including the zero-length token, which is in no way special, except that i= t is indeed shorter than any other token.) > So, as elaborated by Esko, possibly it would be good to suggest some time= -out (so its a MAY and not a MUST to give flexibility to the application de= veloper as pointed out by Akbar ). The present draft adapts the definition = of NON_LIFETIME as the reuse interval for message IDs. Would it be a good i= dea to adapt the same definition as the re-use interval for tokens also? Th= e definition of NON_LIFETIME encompasses EXCHANGE_LIFETIME as well. In CoAP, we have timers at the message layer, not at the request/response l= ayer. Most clients will have a "patience" up to which they will expect a response= , but we currently do not expose this at the protocol level. (With some new option, the client could pose a deadline to the server, or t= he server could promise a deadline to the client. http://tools.ietf.org/html/draft-bormann-coap-misc-26#appendix-B.4 has more= about that.) Gr=1B.A=1BN|=1BN_e, Carsten ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Tue Apr 22 04:34:41 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3EB1A03B3 for ; Tue, 22 Apr 2014 04:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNkDrX6BnkL3 for ; Tue, 22 Apr 2014 04:34:27 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1711A03A9 for ; Tue, 22 Apr 2014 04:34:19 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id z2so3081570wiv.6 for ; Tue, 22 Apr 2014 04:34:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/w9eHODw/LArBhxURTdGKpVzflbEAR1yE3XtWrj6lzc=; b=Fgt/KBt6gSN1funhsei/C6jI7pCk9Nx4A1gmfFeGmBWHDwB019OLaiDtHZMrEkvlUf b8AS0Dp3re6hm/9hBROEenIlSOh5WAlBcy5D9S69KVmZVqieCnWb5uRmGY0a8u1QJJ/Y dsmrSioRTYQoOPetI0KbmfV7TfhWpL1yKqsyXrNQyNYr45C0IFwqJuwKhUHmhahgYAq3 a+N3eq1xRS3Sq6Gz+6Ep51SE1nDLGP0LelvoxLffPo4EyiXBKniNkEfSh2jUlkgfUFcr 58YIqXVHyBdFbSII/sT/t9UwSHdXtm1leuYVFtv9sV87M2OBZSga2wJpCnAgxAu/QAg3 ObbQ== MIME-Version: 1.0 X-Received: by 10.180.94.8 with SMTP id cy8mr18302961wib.29.1398166453355; Tue, 22 Apr 2014 04:34:13 -0700 (PDT) Received: by 10.216.158.197 with HTTP; Tue, 22 Apr 2014 04:34:13 -0700 (PDT) Date: Tue, 22 Apr 2014 17:04:13 +0530 Message-ID: From: Indtiny S To: Contiki developer mailing list , core@ietf.org Content-Type: multipart/alternative; boundary=f46d0434c0caca096f04f79ffeb2 Archived-At: http://mailarchive.ietf.org/arch/msg/core/aw9KzZ0wXBB7pztzU6i20YbfxOU Subject: [core] Opensource CoAP security for Contiki X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 11:34:32 -0000 --f46d0434c0caca096f04f79ffeb2 Content-Type: text/plain; charset=UTF-8 Hi All, I need security for my CoAP based application which will be running my application on Contiki . I came to know that Contiki is using tinyDTLS but tinyDTLS has only preshared key support i.e only TLS_PSK_WITH_AES_128_CCM_8 support . but CoAP manadates the both TLS PSK WITH AES 128 CCM 8 and TLS ECDHE ECDSA WITH AES 128 CCM 8 . Is it possible to add the other chiper TLS ECDHE ECDSA WITH AES 128 CCM 8 easily to the tinyDTLS or is there any other 'c' based opesource which has both support ..? Rgds Indra --f46d0434c0caca096f04f79ffeb2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi All,

I need security for my CoAP bas= ed application which will be running my application on Contiki .
=
I came to know that Contiki is using tinyDTLS but tinyDTLS h= as only preshared key support i.e only TLS_PSK_WITH_AES_128_CCM_8 support .=

but CoAP manadates the both TLS PSK WITH AES 128 CCM 8 = =C2=A0and
TLS ECDHE ECDSA WITH AES 128 CCM 8 .

Is it possible to add the other chiper TLS ECDHE ECDSA WITH AES 128 = CCM 8 easily to the tinyDTLS or is there any other 'c' based opesou= rce which has both support ..?


Rgds
Indra


--f46d0434c0caca096f04f79ffeb2-- From nobody Tue Apr 22 12:44:10 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146361A025C for ; Tue, 22 Apr 2014 12:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFEO1PL8jJE8 for ; Tue, 22 Apr 2014 12:44:03 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 11B951A0258 for ; Tue, 22 Apr 2014 12:43:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,905,1389724200"; d="scan'208";a="525816093" Received: from INKOLSALDLPMTA1.india.tcs.com (unknown [127.0.0.1]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id A130ADAC12; Wed, 23 Apr 2014 01:13:18 +0530 (IST) Received: from InKolM02.tcs.com (unknown [172.18.18.104]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 65C60DAC02; Wed, 23 Apr 2014 01:13:18 +0530 (IST) MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: <031DD135F9160444ABBE3B0C36CED61816A1507A@AMSPRD9003MB066.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED61816A1507A@AMSPRD9003MB066.MGDPHG.emi.philips.com>, <031DD135F9160444ABBE3B0C36CED61816A146F1@AMSPRD9003MB066.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED61816A14E84@AMSPRD9003MB066.MGDPHG.emi.philips.com> From: Abhijan Bhattacharyya To: "Dijk, Esko" Message-ID: Date: Wed, 23 Apr 2014 01:13:17 +0530 X-Mailer: Lotus Domino Web Server Release 9.0HF507 August 20, 2013 X-MIMETrack: Serialize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 04/23/2014 01:13:17, Serialize complete at 04/23/2014 01:13:17, Itemize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 04/23/2014 01:13:17, Serialize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 04/23/2014 01:13:18, Serialize complete at 04/23/2014 01:13:18, Serialize by Router on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 04/23/2014 01:13:18 Content-Type: multipart/alternative; boundary="=_alternative 006C552765257CC2_=" Archived-At: http://mailarchive.ietf.org/arch/msg/core/DJH2w548r7CBHivweK7ClxIR2b4 Cc: "core@ietf.org" Subject: Re: [core] Handling tokens for No-response X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 19:44:09 -0000 --=_alternative 006C552765257CC2_= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Esko, You are absolutely right. No-response is just to indicate the dis-interest = of client about the response from server and if No-response is not implemen= ted in server then it will always send a response. But this response should= not have any importance to the client since the client is not interested i= n getting response. Now, coming to your example, probably the consecutive responses should not = matter much to the client if both the requests are made with No-response. H= owever, say, if the first request is with No-response and the second reques= t, with same token, is without No-response then a delayed response to the f= irst one may be interpreted as a response to the second request (client nee= ds a response in this case) if the gap between use of the same token is not= enough. >From the discussions so far, it seems we indeed need to define some timing = value based on something like 'patience' or some 'promised deadline' as poi= nted out by Carsten. But, none of these are included into/ defined for the = present main CoAP spec. Also, handling this issue may vary case to case dep= ending the application feature. So, would it not be a good idea to leave the token reuse to be handled by t= he application developer and to keep a note in the No-response draft which = would effectively summarise the different technical aspects that we have be= en discussing on this topic. Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ -----"Dijk, Esko" wrote: ----- To: Abhijan Bhattacharyya From: "Dijk, Esko" Date: 04/22/2014 03:05PM Cc: "core@ietf.org" Subject: RE: [core] Handling tokens for No-response Hello Abhijan, I forgot to mention that using =A0the No-Response Option is not a guarantee= that no response will come. It actually MAY come since the Option is elect= ive. That is something that needs to be taken into account by a client in its To= ken re-use strategy. If not it leads to interoperability issues, or not? = =A0E.g. "client expects no answer to its request with Token=3D0, so it send= s out a new request with Token=3D0, but server does not recognize No-Respon= se option, and sends a response, then the client receives the old delayed r= esponse with Token=3D0 instead of the newer response with same Token". Esko -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Dijk, Esko Sent: Tuesday, April 22, 2014 08:53 To: Carsten Bormann; Abhijan Bhattacharyya Cc: core@ietf.org Subject: Re: [core] Handling tokens for No-response Hi, if there's no time limit that can be defined for Token re-use, what time wo= uld an implementer of a client need to choose? =A0 (I know we chose not to = define 'patience' in CoAP, but an implementer would still need to make a sa= ne choice here.) Can we argue that Patience i.e. max response delay will be= "a few minutes" and hence Token can be re-used safely after a time far lon= ger than that, say 15 minutes? For those cases where the implementer of the CoAP client knows that a respo= nse may take very long (e.g. see OMA LWM2M case, "queue mode" function, whe= re a response could take e.g. one day) he could adapt the Patience to somet= hing much longer. Would that be a feasible approach? I feel that it would be beneficial if the No-Response draft would say somet= hing about this Token re-use for unicast and multicast NON requests. =A0If = several people in the CoRE WG saw it wrong, it may be worth pointing out as= well to a non-CoRE audience ;) Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Thursday, April 17, 2014 15:08 To: Abhijan Bhattacharyya Cc: weigengyu; Dijk, Esko; Rahman, Akbar; core@ietf.org Subject: Re: [core] Handling tokens for No-response On 17 Apr 2014, at 14:22, Abhijan Bhattacharyya wrote: > We cannot, as a general proposition, get rid of tokens while using No-res= ponse considering potential use of this option with a GET =A0for proactive = cancellation of an observe session (Ref: <1> section 3.8 of draft-ietf-core= -observe-13 and <2>http://www.ietf.org/mail-archive/web/core/current/msg053= 31.html). =A0A GET request to cancel an observe session must carry a token = to associate itself with the existing observe session. While this is true, this is not the point that I was making. I was pointing out that a request that is defined in such a way that it MAY= elicit a response (depending on some condition unknown to the client at th= e time) generates hardship for the client, because in the absence of a resp= onse it does not know whether it can retire the token or still has to expec= t a response for that. Now if the client does not care about whether any response coming back is r= elated back to the right request, it can reuse tokens at liberty. (Including the zero-length token, which is in no way special, except that i= t is indeed shorter than any other token.) > So, as elaborated by Esko, possibly it would be good to suggest some time= -out (so its a MAY and not a MUST to give flexibility to the application de= veloper as pointed out by Akbar ). The present draft adapts the definition = of NON_LIFETIME as the reuse interval for message IDs. Would it be a good i= dea to adapt the same definition as the re-use interval for tokens also? Th= e definition of NON_LIFETIME encompasses EXCHANGE_LIFETIME as well. In CoAP, we have timers at the message layer, not at the request/response l= ayer. Most clients will have a "patience" up to which they will expect a response= , but we currently do not expose this at the protocol level. (With some new option, the client could pose a deadline to the server, or t= he server could promise a deadline to the client. http://tools.ietf.org/html/draft-bormann-coap-misc-26#appendix-B.4=FFhas mo= re about that.) Gr=0F;.A=0F;N|=0F;N_e, Carsten ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain = confidential or privileged information. If you are = not the intended recipient, any dissemination, use, = review, distribution, printing or copying of the = information contained in this e-mail message = and/or attachments to it are strictly prohibited. If = you have received this communication in error, = please notify us by reply e-mail or telephone and = immediately and permanently delete the message = and any attachments. Thank you --=_alternative 006C552765257CC2_= Content-ID: <> MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Esko,
You are absolutely right. No-response is jus= t to indicate the dis-interest of client about the response from server and= if No-response is not implemented in server then it will always send a res= ponse. But this response should not have any importance to the client since= the client is not interested in getting response.

Now, coming to your example, probably the consecutive responses should not= matter much to the client if both the requests are made with No-response. = However, say, if the first request is with No-response and the second reque= st, with same token, is without No-response then a delayed response to the = first one may be interpreted as a response to the second request (client ne= eds a response in this case) if the gap between use of the same token is no= t enough.

From the discussions so far, it seems we= indeed need to define some timing value based on something like 'patience'= or some 'promised deadline' as pointed out by Carsten. But, none of these = are included into/ defined for the present main CoAP spec. Also, handling t= his issue may vary case to case depending the application feature.

So, would it not be a good idea to leave the token reuse t= o be handled by the application developer and to keep a note in the No-resp= onse draft which would effectively summarise the different technical aspect= s that we have been discussing on this topic.


Regards
Abhijan= Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkat= a, India
Tata Consultancy Services Limited
Mailto: abhijan.bhattacharyya@tcs.com
Website= : http://www.tcs.com
________________= ____________________________
Experience certainty. IT Services
Bus= iness Solutions
Consulting
_______________________________________= _____


-----"Dijk, Esko" <esko.dijk@= philips.com> wrote: -----
To: Abhijan Bhattacharyya <abhijan.bhattacharyya@tc= s.com>
From: "Dijk, Esko" <esko.dijk@philips.com>
Date: 04/2= 2/2014 03:05PM
Cc: "core@ietf.org" <core@ietf.org>
Subject: RE:= [core] Handling tokens for No-response

Hello Abhijan,

I forgot to mention = that using  the No-Response Option is not a guarantee that no response= will come. It actually MAY come since the Option is elective.
That is s= omething that needs to be taken into account by a client in its Token re-us= e strategy. If not it leads to interoperability issues, or not?  E.g. = "client expects no answer to its request with Token=3D0, so it sends out a = new request with Token=3D0, but server does not recognize No-Response optio= n, and sends a response, then the client receives the old delayed response = with Token=3D0 instead of the newer response with same Token".

Esko<= br>
-----Original Message-----
From: core [mailto:core-bounces@ietf.org] On Behalf Of Dijk, EskoSent: Tuesday, April 22, 2014 08:53
To: Carsten Bormann; Abhijan Bhatta= charyya
Cc: core@ietf.org
Subject: Re: [core] Handling tokens for No-= response

Hi,

if there's no time limit that can be defined for= Token re-use, what time would an implementer of a client need to choose? &= nbsp; (I know we chose not to define 'patience' in CoAP, but an implementer= would still need to make a sane choice here.) Can we argue that Patience i= .e. max response delay will be "a few minutes" and hence Token can be re-us= ed safely after a time far longer than that, say 15 minutes?

For tho= se cases where the implementer of the CoAP client knows that a response may= take very long (e.g. see OMA LWM2M case, "queue mode" function, where a re= sponse could take e.g. one day) he could adapt the Patience to something mu= ch longer.

Would that be a feasible approach?
I feel that it woul= d be beneficial if the No-Response draft would say something about this Tok= en re-use for unicast and multicast NON requests.  If several people i= n the CoRE WG saw it wrong, it may be worth pointing out as well to a non-C= oRE audience ;)

Esko

-----Original Message-----
From: Cars= ten Bormann [mailto:cabo@tzi.org]
Se= nt: Thursday, April 17, 2014 15:08
To: Abhijan Bhattacharyya
Cc: weig= engyu; Dijk, Esko; Rahman, Akbar; core@ietf.org
Subject: Re: [core] Hand= ling tokens for No-response

On 17 Apr 2014, at 14:22, Abhijan Bhatta= charyya <abhijan.bhattacharyya@tcs.com> wrote:

> We cannot,= as a general proposition, get rid of tokens while using No-response consid= ering potential use of this option with a GET  for proactive cancellat= ion of an observe session (Ref: <1> section 3.8 of draft-ietf-core-ob= serve-13 and <2>http://www.ietf.org/mail-archive/web/core/current/ms= g05331.html).  A GET request to cancel an observe session must car= ry a token to associate itself with the existing observe session.

Wh= ile this is true, this is not the point that I was making.
I was pointin= g out that a request that is defined in such a way that it MAY elicit a res= ponse (depending on some condition unknown to the client at the time) gener= ates hardship for the client, because in the absence of a response it does = not know whether it can retire the token or still has to expect a response = for that.

Now if the client does not care about whether any response= coming back is related back to the right request, it can reuse tokens at l= iberty.
(Including the zero-length token, which is in no way special, ex= cept that it is indeed shorter than any other token.)

> So, as el= aborated by Esko, possibly it would be good to suggest some time-out (so it= s a MAY and not a MUST to give flexibility to the application developer as = pointed out by Akbar ). The present draft adapts the definition of NON_LIFE= TIME as the reuse interval for message IDs. Would it be a good idea to adap= t the same definition as the re-use interval for tokens also? The definitio= n of NON_LIFETIME encompasses EXCHANGE_LIFETIME as well.

In CoAP, we= have timers at the message layer, not at the request/response layer.
Mo= st clients will have a "patience" up to which they will expect a response, = but we currently do not expose this at the protocol level.
(With some ne= w option, the client could pose a deadline to the server, or the server cou= ld promise a deadline to the client.
http://tools.ietf.org/html/draf= t-bormann-coap-misc-26#appendix-B.4 has more about that.)

G= r=1B.A=1BN|=1BN_e, Carsten


________________________________
T= he information contained in this message may be confidential and legally pr= otected under applicable law. The message is intended solely for the addres= see(s). If you are not the intended recipient, you are hereby notified that= any use, forwarding, dissemination, or reproduction of this message is str= ictly prohibited and may be unlawful. If you are not the intended recipient= , please contact the sender by return e-mail and destroy all copies of the = original message.

_______________________________________________core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----= =3D=3D=3D=3D=3D
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

--=_alternative 006C552765257CC2_=-- From nobody Tue Apr 22 17:47:31 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6C01A02C4 for ; Tue, 22 Apr 2014 17:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VA2dNpi-1kge for ; Tue, 22 Apr 2014 17:47:26 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 549781A02B4 for ; Tue, 22 Apr 2014 17:47:25 -0700 (PDT) Received: from WeiGengyuPC (unknown [10.103.241.231]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 203B819F3A0; Wed, 23 Apr 2014 08:47:17 +0800 (HKT) Message-ID: <403D1CF4497D40529FC2E6138311A813@WeiGengyuPC> From: "weigengyu" To: "Dijk, Esko" , "Abhijan Bhattacharyya" References: <031DD135F9160444ABBE3B0C36CED61816A146F1@AMSPRD9003MB066.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED61816A14E84@AMSPRD9003MB066.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED61816A1507A@AMSPRD9003MB066.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED61816A1507A@AMSPRD9003MB066.MGDPHG.emi.philips.com> Date: Wed, 23 Apr 2014 08:47:17 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Archived-At: http://mailarchive.ietf.org/arch/msg/core/6Q_TZXEdM69vtN8npfL2WGT73ds Cc: core@ietf.org Subject: Re: [core] Handling tokens for No-response X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 00:47:30 -0000 Hi all, I agree that No-Response may need for some situations. But the different between zero length of token and the value of token being zeron should be clear. Could anyone help to tell what does "An empty token value" in CoAP -18 mean? Is it the zero length token or the value of token being zero? Regards, Gengyu Network Technogy Center School of Computer Beijing University of Posts and Telecommunications -----鍘熷閭欢----- From: Dijk, Esko Sent: Tuesday, April 22, 2014 5:34 PM To: Abhijan Bhattacharyya Cc: core@ietf.org Subject: Re: [core] Handling tokens for No-response Hello Abhijan, I forgot to mention that using the No-Response Option is not a guarantee that no response will come. It actually MAY come since the Option is elective. That is something that needs to be taken into account by a client in its Token re-use strategy. If not it leads to interoperability issues, or not? E.g. "client expects no answer to its request with Token=0, so it sends out a new request with Token=0, but server does not recognize No-Response option, and sends a response, then the client receives the old delayed response with Token=0 instead of the newer response with same Token". Esko -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Dijk, Esko Sent: Tuesday, April 22, 2014 08:53 To: Carsten Bormann; Abhijan Bhattacharyya Cc: core@ietf.org Subject: Re: [core] Handling tokens for No-response Hi, if there's no time limit that can be defined for Token re-use, what time would an implementer of a client need to choose? (I know we chose not to define 'patience' in CoAP, but an implementer would still need to make a sane choice here.) Can we argue that Patience i.e. max response delay will be "a few minutes" and hence Token can be re-used safely after a time far longer than that, say 15 minutes? For those cases where the implementer of the CoAP client knows that a response may take very long (e.g. see OMA LWM2M case, "queue mode" function, where a response could take e.g. one day) he could adapt the Patience to something much longer. Would that be a feasible approach? I feel that it would be beneficial if the No-Response draft would say something about this Token re-use for unicast and multicast NON requests. If several people in the CoRE WG saw it wrong, it may be worth pointing out as well to a non-CoRE audience ;) Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Thursday, April 17, 2014 15:08 To: Abhijan Bhattacharyya Cc: weigengyu; Dijk, Esko; Rahman, Akbar; core@ietf.org Subject: Re: [core] Handling tokens for No-response On 17 Apr 2014, at 14:22, Abhijan Bhattacharyya wrote: > We cannot, as a general proposition, get rid of tokens while using > No-response considering potential use of this option with a GET for > proactive cancellation of an observe session (Ref: <1> section 3.8 of > draft-ietf-core-observe-13 and > <2>http://www.ietf.org/mail-archive/web/core/current/msg05331.html). A > GET request to cancel an observe session must carry a token to associate > itself with the existing observe session. While this is true, this is not the point that I was making. I was pointing out that a request that is defined in such a way that it MAY elicit a response (depending on some condition unknown to the client at the time) generates hardship for the client, because in the absence of a response it does not know whether it can retire the token or still has to expect a response for that. Now if the client does not care about whether any response coming back is related back to the right request, it can reuse tokens at liberty. (Including the zero-length token, which is in no way special, except that it is indeed shorter than any other token.) > So, as elaborated by Esko, possibly it would be good to suggest some > time-out (so its a MAY and not a MUST to give flexibility to the > application developer as pointed out by Akbar ). The present draft adapts > the definition of NON_LIFETIME as the reuse interval for message IDs. > Would it be a good idea to adapt the same definition as the re-use > interval for tokens also? The definition of NON_LIFETIME encompasses > EXCHANGE_LIFETIME as well. In CoAP, we have timers at the message layer, not at the request/response layer. Most clients will have a "patience" up to which they will expect a response, but we currently do not expose this at the protocol level. (With some new option, the client could pose a deadline to the server, or the server could promise a deadline to the client. http://tools.ietf.org/html/draft-bormann-coap-misc-26#appendix-B.4 has more about that.) Gr.AN|N_e, Carsten ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Tue Apr 22 17:57:58 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5BDA1A02C2 for ; Tue, 22 Apr 2014 17:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNY7jnS_rKuA for ; Tue, 22 Apr 2014 17:57:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 02E5A1A02B4 for ; Tue, 22 Apr 2014 17:57:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFY57416; Wed, 23 Apr 2014 00:57:40 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Apr 2014 01:56:44 +0100 Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Apr 2014 01:57:38 +0100 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.158]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Wed, 23 Apr 2014 08:57:31 +0800 From: Likepeng To: weigengyu , "Dijk, Esko" , Abhijan Bhattacharyya Thread-Topic: [core] Handling tokens for No-response Thread-Index: AQHPV98wMk72MR7gF0im1hGW5O55IJsTL/yAgABKdgCAADiXAIAAYosAgAEAToCAACOYgIAADOSAgAdy6YCAACzrgIAA/xmAgACH+7A= Date: Wed, 23 Apr 2014 00:57:30 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252B22B60@SZXEMA501-MBS.china.huawei.com> References: <031DD135F9160444ABBE3B0C36CED61816A146F1@AMSPRD9003MB066.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED61816A14E84@AMSPRD9003MB066.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED61816A1507A@AMSPRD9003MB066.MGDPHG.emi.philips.com> <403D1CF4497D40529FC2E6138311A813@WeiGengyuPC> In-Reply-To: <403D1CF4497D40529FC2E6138311A813@WeiGengyuPC> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/core/_ctrKKX1iPOYn6WqNJSJAITxrGo Cc: "core@ietf.org" Subject: Re: [core] Handling tokens for No-response X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 00:57:55 -0000 PiBDb3VsZCBhbnlvbmUgaGVscCB0byB0ZWxsIHdoYXQgZG9lcyAiQW4gZW1wdHkgdG9rZW4gdmFs dWUiIGluIENvQVAgLTE4IG1lYW4/DQo+IElzIGl0IHRoZSB6ZXJvIGxlbmd0aCB0b2tlbiBvciB0 aGUgdmFsdWUgb2YgdG9rZW4gYmVpbmcgemVybz8NCg0KSW4gbXkgdW5kZXJzdGFuZGluZywgImVt cHR5IHRva2VuIHZhbHVlIiBtZWFucyB6ZXJvLWxlbmd0aCB0b2tlbi4NCg0KS2luZCBSZWdhcmRz DQpLZXBlbmcNCg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogY29yZSBb bWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIHdlaWdlbmd5dQ0KPiDlj5HpgIHm l7bpl7Q6IDIwMTTlubQ05pyIMjPml6UgODo0Nw0KPiDmlLbku7bkuro6IERpamssIEVza287IEFi aGlqYW4gQmhhdHRhY2hhcnl5YQ0KPiDmioTpgIE6IGNvcmVAaWV0Zi5vcmcNCj4g5Li76aKYOiBS ZTogW2NvcmVdIEhhbmRsaW5nIHRva2VucyBmb3IgTm8tcmVzcG9uc2UNCj4gDQo+IEhpIGFsbCwN Cj4gDQo+IEkgYWdyZWUgdGhhdCBOby1SZXNwb25zZSBtYXkgbmVlZCBmb3Igc29tZSBzaXR1YXRp b25zLg0KPiANCj4gQnV0IHRoZSBkaWZmZXJlbnQgYmV0d2VlbiB6ZXJvIGxlbmd0aCBvZiB0b2tl biBhbmQgdGhlIHZhbHVlIG9mICB0b2tlbiBiZWluZw0KPiB6ZXJvbiBzaG91bGQgYmUgY2xlYXIu DQo+IA0KPiBDb3VsZCBhbnlvbmUgaGVscCB0byB0ZWxsIHdoYXQgZG9lcyAiQW4gZW1wdHkgdG9r ZW4gdmFsdWUiIGluIENvQVAgLTE4DQo+IG1lYW4/DQo+IElzIGl0ICB0aGUgemVybyBsZW5ndGgg dG9rZW4gb3IgdGhlIHZhbHVlIG9mIHRva2VuIGJlaW5nIHplcm8/DQo+IA0KPiBSZWdhcmRzLA0K PiANCj4gR2VuZ3l1DQo+IE5ldHdvcmsgVGVjaG5vZ3kgQ2VudGVyDQo+IFNjaG9vbCBvZiBDb21w dXRlcg0KPiBCZWlqaW5nIFVuaXZlcnNpdHkgb2YgUG9zdHMgYW5kIFRlbGVjb21tdW5pY2F0aW9u cw0KPiANCj4gLS0tLS3ljp/lp4vpgq7ku7YtLS0tLQ0KPiBGcm9tOiBEaWprLCBFc2tvDQo+IFNl bnQ6IFR1ZXNkYXksIEFwcmlsIDIyLCAyMDE0IDU6MzQgUE0NCj4gVG86IEFiaGlqYW4gQmhhdHRh Y2hhcnl5YQ0KPiBDYzogY29yZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2NvcmVdIEhhbmRs aW5nIHRva2VucyBmb3IgTm8tcmVzcG9uc2UNCj4gDQo+IEhlbGxvIEFiaGlqYW4sDQo+IA0KPiBJ IGZvcmdvdCB0byBtZW50aW9uIHRoYXQgdXNpbmcgIHRoZSBOby1SZXNwb25zZSBPcHRpb24gaXMg bm90IGEgZ3VhcmFudGVlDQo+IHRoYXQgbm8gcmVzcG9uc2Ugd2lsbCBjb21lLiBJdCBhY3R1YWxs eSBNQVkgY29tZSBzaW5jZSB0aGUgT3B0aW9uIGlzIGVsZWN0aXZlLg0KPiBUaGF0IGlzIHNvbWV0 aGluZyB0aGF0IG5lZWRzIHRvIGJlIHRha2VuIGludG8gYWNjb3VudCBieSBhIGNsaWVudCBpbiBp dHMgVG9rZW4NCj4gcmUtdXNlIHN0cmF0ZWd5LiBJZiBub3QgaXQgbGVhZHMgdG8gaW50ZXJvcGVy YWJpbGl0eSBpc3N1ZXMsIG9yIG5vdD8NCj4gRS5nLiAiY2xpZW50IGV4cGVjdHMgbm8gYW5zd2Vy IHRvIGl0cyByZXF1ZXN0IHdpdGggVG9rZW49MCwgc28gaXQgc2VuZHMgb3V0IGENCj4gbmV3IHJl cXVlc3Qgd2l0aCBUb2tlbj0wLCBidXQgc2VydmVyIGRvZXMgbm90IHJlY29nbml6ZSBOby1SZXNw b25zZSBvcHRpb24sDQo+IGFuZCBzZW5kcyBhIHJlc3BvbnNlLCB0aGVuIHRoZSBjbGllbnQgcmVj ZWl2ZXMgdGhlIG9sZCBkZWxheWVkIHJlc3BvbnNlIHdpdGgNCj4gVG9rZW49MCBpbnN0ZWFkIG9m IHRoZSBuZXdlciByZXNwb25zZSB3aXRoIHNhbWUgVG9rZW4iLg0KPiANCj4gRXNrbw0KPiANCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogY29yZSBbbWFpbHRvOmNvcmUtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERpamssIEVza28NCj4gU2VudDogVHVlc2RheSwg QXByaWwgMjIsIDIwMTQgMDg6NTMNCj4gVG86IENhcnN0ZW4gQm9ybWFubjsgQWJoaWphbiBCaGF0 dGFjaGFyeXlhDQo+IENjOiBjb3JlQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbY29yZV0gSGFu ZGxpbmcgdG9rZW5zIGZvciBOby1yZXNwb25zZQ0KPiANCj4gSGksDQo+IA0KPiBpZiB0aGVyZSdz IG5vIHRpbWUgbGltaXQgdGhhdCBjYW4gYmUgZGVmaW5lZCBmb3IgVG9rZW4gcmUtdXNlLCB3aGF0 IHRpbWUNCj4gd291bGQgYW4gaW1wbGVtZW50ZXIgb2YgYSBjbGllbnQgbmVlZCB0byBjaG9vc2U/ ICAgKEkga25vdyB3ZSBjaG9zZSBub3QgdG8NCj4gZGVmaW5lICdwYXRpZW5jZScgaW4gQ29BUCwg YnV0IGFuIGltcGxlbWVudGVyIHdvdWxkIHN0aWxsIG5lZWQgdG8gbWFrZSBhIHNhbmUNCj4gY2hv aWNlIGhlcmUuKSBDYW4gd2UgYXJndWUgdGhhdCBQYXRpZW5jZSBpLmUuIG1heCByZXNwb25zZSBk ZWxheSB3aWxsIGJlICJhIGZldw0KPiBtaW51dGVzIiBhbmQgaGVuY2UgVG9rZW4gY2FuIGJlIHJl LXVzZWQgc2FmZWx5IGFmdGVyIGEgdGltZSBmYXIgbG9uZ2VyIHRoYW4NCj4gdGhhdCwgc2F5IDE1 IG1pbnV0ZXM/DQo+IA0KPiBGb3IgdGhvc2UgY2FzZXMgd2hlcmUgdGhlIGltcGxlbWVudGVyIG9m IHRoZSBDb0FQIGNsaWVudCBrbm93cyB0aGF0IGENCj4gcmVzcG9uc2UgbWF5IHRha2UgdmVyeSBs b25nIChlLmcuIHNlZSBPTUEgTFdNMk0gY2FzZSwgInF1ZXVlIG1vZGUiDQo+IGZ1bmN0aW9uLCB3 aGVyZSBhIHJlc3BvbnNlIGNvdWxkIHRha2UgZS5nLiBvbmUgZGF5KSBoZSBjb3VsZCBhZGFwdCB0 aGUNCj4gUGF0aWVuY2UgdG8gc29tZXRoaW5nIG11Y2ggbG9uZ2VyLg0KPiANCj4gV291bGQgdGhh dCBiZSBhIGZlYXNpYmxlIGFwcHJvYWNoPw0KPiBJIGZlZWwgdGhhdCBpdCB3b3VsZCBiZSBiZW5l ZmljaWFsIGlmIHRoZSBOby1SZXNwb25zZSBkcmFmdCB3b3VsZCBzYXkgc29tZXRoaW5nDQo+IGFi b3V0IHRoaXMgVG9rZW4gcmUtdXNlIGZvciB1bmljYXN0IGFuZCBtdWx0aWNhc3QgTk9OIHJlcXVl c3RzLg0KPiBJZiBzZXZlcmFsIHBlb3BsZSBpbiB0aGUgQ29SRSBXRyBzYXcgaXQgd3JvbmcsIGl0 IG1heSBiZSB3b3J0aCBwb2ludGluZyBvdXQgYXMNCj4gd2VsbCB0byBhIG5vbi1Db1JFIGF1ZGll bmNlIDspDQo+IA0KPiBFc2tvDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBDYXJzdGVuIEJvcm1hbm4gW21haWx0bzpjYWJvQHR6aS5vcmddDQo+IFNlbnQ6IFRodXJz ZGF5LCBBcHJpbCAxNywgMjAxNCAxNTowOA0KPiBUbzogQWJoaWphbiBCaGF0dGFjaGFyeXlhDQo+ IENjOiB3ZWlnZW5neXU7IERpamssIEVza287IFJhaG1hbiwgQWtiYXI7IGNvcmVAaWV0Zi5vcmcN Cj4gU3ViamVjdDogUmU6IFtjb3JlXSBIYW5kbGluZyB0b2tlbnMgZm9yIE5vLXJlc3BvbnNlDQo+ IA0KPiBPbiAxNyBBcHIgMjAxNCwgYXQgMTQ6MjIsIEFiaGlqYW4gQmhhdHRhY2hhcnl5YQ0KPiA8 YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb20+IHdyb3RlOg0KPiANCj4gPiBXZSBjYW5ub3Qs IGFzIGEgZ2VuZXJhbCBwcm9wb3NpdGlvbiwgZ2V0IHJpZCBvZiB0b2tlbnMgd2hpbGUgdXNpbmcN Cj4gPiBOby1yZXNwb25zZSBjb25zaWRlcmluZyBwb3RlbnRpYWwgdXNlIG9mIHRoaXMgb3B0aW9u IHdpdGggYSBHRVQgIGZvcg0KPiA+IHByb2FjdGl2ZSBjYW5jZWxsYXRpb24gb2YgYW4gb2JzZXJ2 ZSBzZXNzaW9uIChSZWY6IDwxPiBzZWN0aW9uIDMuOCBvZg0KPiA+IGRyYWZ0LWlldGYtY29yZS1v YnNlcnZlLTEzIGFuZA0KPiA+IDwyPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9jb3JlL2N1cnJlbnQvbXNnMDUzMzEuaHRtbCkuDQo+ID4gQSBHRVQgcmVxdWVzdCB0byBjYW5j ZWwgYW4gb2JzZXJ2ZSBzZXNzaW9uIG11c3QgY2FycnkgYSB0b2tlbiB0bw0KPiA+IGFzc29jaWF0 ZSBpdHNlbGYgd2l0aCB0aGUgZXhpc3Rpbmcgb2JzZXJ2ZSBzZXNzaW9uLg0KPiANCj4gV2hpbGUg dGhpcyBpcyB0cnVlLCB0aGlzIGlzIG5vdCB0aGUgcG9pbnQgdGhhdCBJIHdhcyBtYWtpbmcuDQo+ IEkgd2FzIHBvaW50aW5nIG91dCB0aGF0IGEgcmVxdWVzdCB0aGF0IGlzIGRlZmluZWQgaW4gc3Vj aCBhIHdheSB0aGF0IGl0IE1BWSBlbGljaXQNCj4gYSByZXNwb25zZSAoZGVwZW5kaW5nIG9uIHNv bWUgY29uZGl0aW9uIHVua25vd24gdG8gdGhlIGNsaWVudCBhdCB0aGUNCj4gdGltZSkgZ2VuZXJh dGVzIGhhcmRzaGlwIGZvciB0aGUgY2xpZW50LCBiZWNhdXNlIGluIHRoZSBhYnNlbmNlIG9mIGEg cmVzcG9uc2UgaXQNCj4gZG9lcyBub3Qga25vdyB3aGV0aGVyIGl0IGNhbiByZXRpcmUgdGhlIHRv a2VuIG9yIHN0aWxsIGhhcyB0byBleHBlY3QgYSByZXNwb25zZQ0KPiBmb3IgdGhhdC4NCj4gDQo+ IE5vdyBpZiB0aGUgY2xpZW50IGRvZXMgbm90IGNhcmUgYWJvdXQgd2hldGhlciBhbnkgcmVzcG9u c2UgY29taW5nIGJhY2sgaXMNCj4gcmVsYXRlZCBiYWNrIHRvIHRoZSByaWdodCByZXF1ZXN0LCBp dCBjYW4gcmV1c2UgdG9rZW5zIGF0IGxpYmVydHkuDQo+IChJbmNsdWRpbmcgdGhlIHplcm8tbGVu Z3RoIHRva2VuLCB3aGljaCBpcyBpbiBubyB3YXkgc3BlY2lhbCwgZXhjZXB0IHRoYXQgaXQgaXMN Cj4gaW5kZWVkIHNob3J0ZXIgdGhhbiBhbnkgb3RoZXIgdG9rZW4uKQ0KPiANCj4gPiBTbywgYXMg ZWxhYm9yYXRlZCBieSBFc2tvLCBwb3NzaWJseSBpdCB3b3VsZCBiZSBnb29kIHRvIHN1Z2dlc3Qg c29tZQ0KPiA+IHRpbWUtb3V0IChzbyBpdHMgYSBNQVkgYW5kIG5vdCBhIE1VU1QgdG8gZ2l2ZSBm bGV4aWJpbGl0eSB0byB0aGUNCj4gPiBhcHBsaWNhdGlvbiBkZXZlbG9wZXIgYXMgcG9pbnRlZCBv dXQgYnkgQWtiYXIgKS4gVGhlIHByZXNlbnQgZHJhZnQNCj4gPiBhZGFwdHMgdGhlIGRlZmluaXRp b24gb2YgTk9OX0xJRkVUSU1FIGFzIHRoZSByZXVzZSBpbnRlcnZhbCBmb3IgbWVzc2FnZSBJRHMu DQo+ID4gV291bGQgaXQgYmUgYSBnb29kIGlkZWEgdG8gYWRhcHQgdGhlIHNhbWUgZGVmaW5pdGlv biBhcyB0aGUgcmUtdXNlDQo+ID4gaW50ZXJ2YWwgZm9yIHRva2VucyBhbHNvPyBUaGUgZGVmaW5p dGlvbiBvZiBOT05fTElGRVRJTUUgZW5jb21wYXNzZXMNCj4gPiBFWENIQU5HRV9MSUZFVElNRSBh cyB3ZWxsLg0KPiANCj4gSW4gQ29BUCwgd2UgaGF2ZSB0aW1lcnMgYXQgdGhlIG1lc3NhZ2UgbGF5 ZXIsIG5vdCBhdCB0aGUgcmVxdWVzdC9yZXNwb25zZQ0KPiBsYXllci4NCj4gTW9zdCBjbGllbnRz IHdpbGwgaGF2ZSBhICJwYXRpZW5jZSIgdXAgdG8gd2hpY2ggdGhleSB3aWxsIGV4cGVjdCBhIHJl c3BvbnNlLCBidXQNCj4gd2UgY3VycmVudGx5IGRvIG5vdCBleHBvc2UgdGhpcyBhdCB0aGUgcHJv dG9jb2wgbGV2ZWwuDQo+IChXaXRoIHNvbWUgbmV3IG9wdGlvbiwgdGhlIGNsaWVudCBjb3VsZCBw b3NlIGEgZGVhZGxpbmUgdG8gdGhlIHNlcnZlciwgb3IgdGhlDQo+IHNlcnZlciBjb3VsZCBwcm9t aXNlIGEgZGVhZGxpbmUgdG8gdGhlIGNsaWVudC4NCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtYm9ybWFubi1jb2FwLW1pc2MtMjYjYXBwZW5kaXgtQi40IGhhcw0KPiBtb3JlIGFi b3V0IHRoYXQuKQ0KPiANCj4gR3IbLkEbTnwbTl9lLCBDYXJzdGVuDQo+IA0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBp biB0aGlzIG1lc3NhZ2UgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVnYWxseQ0KPiBwcm90ZWN0 ZWQgdW5kZXIgYXBwbGljYWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBm b3IgdGhlDQo+IGFkZHJlc3NlZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQNCj4gdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5n LCBkaXNzZW1pbmF0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGlzDQo+IHN0 cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCwNCj4gcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1 cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMgb2YgdGhlDQo+IG9yaWdpbmFsIG1lc3Nh Z2UuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBjb3JlIG1haWxpbmcgbGlzdA0KPiBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gY29yZSBtYWlsaW5nIGxpc3QNCj4gY29yZUBp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCj4g DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGNv cmUgbWFpbGluZyBsaXN0DQo+IGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jb3JlDQo= From nobody Tue Apr 22 22:34:06 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534B91A0307 for ; Tue, 22 Apr 2014 22:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcPVALDakRJw for ; Tue, 22 Apr 2014 22:34:00 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6F32A1A005A for ; Tue, 22 Apr 2014 22:33:57 -0700 (PDT) Received: from mail148-va3-R.bigfish.com (10.7.14.242) by VA3EHSOBE014.bigfish.com (10.7.40.64) with Microsoft SMTP Server id 14.1.225.22; Wed, 23 Apr 2014 05:32:51 +0000 Received: from mail148-va3 (localhost [127.0.0.1]) by mail148-va3-R.bigfish.com (Postfix) with ESMTP id 274974E00F8; Wed, 23 Apr 2014 05:32:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:206.191.242.69; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:error; EFVD:FOP X-SpamScore: -32 X-BigFish: VPS-32(zz98dI15d6O9371Ic89bh1be0I542I1432I9251I14ffI217bIdd85kzz1f42h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzd9hz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2dh109h2a8h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25f6h2605h268bh26d3h1155h) Received: from mail148-va3 (localhost.localdomain [127.0.0.1]) by mail148-va3 (MessageSwitch) id 1398231168551775_2188; Wed, 23 Apr 2014 05:32:48 +0000 (UTC) Received: from VA3EHSMHS028.bigfish.com (unknown [10.7.14.232]) by mail148-va3.bigfish.com (Postfix) with ESMTP id 7178524004F; Wed, 23 Apr 2014 05:32:48 +0000 (UTC) Received: from mail.philips.com (206.191.242.69) by VA3EHSMHS028.bigfish.com (10.7.99.38) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 23 Apr 2014 05:32:46 +0000 Received: from AMSPRD9003MB066.MGDPHG.emi.philips.com ([169.254.5.172]) by AMSPRD9003HT003.MGDPHG.emi.philips.com ([141.251.33.80]) with mapi id 14.16.0423.000; Wed, 23 Apr 2014 05:33:44 +0000 From: "Dijk, Esko" To: Likepeng , weigengyu , Abhijan Bhattacharyya Thread-Topic: [core] Handling tokens for No-response Thread-Index: AQHPV98vDTgRdHJfpkqigWMEJ8EFKZsTthiAgABKdwCAADR9UIAAZc4ggAEBJICAACOYgIAADOSAgAdvEHCAAC9sYIABAHKAgAAC2gCAAEl1gA== Date: Wed, 23 Apr 2014 05:33:43 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED61816A15292@AMSPRD9003MB066.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED61816A146F1@AMSPRD9003MB066.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED61816A14E84@AMSPRD9003MB066.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED61816A1507A@AMSPRD9003MB066.MGDPHG.emi.philips.com> <403D1CF4497D40529FC2E6138311A813@WeiGengyuPC> <34966E97BE8AD64EAE9D3D6E4DEE36F252B22B60@SZXEMA501-MBS.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F252B22B60@SZXEMA501-MBS.china.huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [88.128.80.112] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/core/_T0O1XLBCpZDUqBZz5sxOFp_TQM Cc: "core@ietf.org" Subject: Re: [core] Handling tokens for No-response X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 05:34:04 -0000 PiBJbiBteSB1bmRlcnN0YW5kaW5nLCAiZW1wdHkgdG9rZW4gdmFsdWUiIG1lYW5zIHplcm8tbGVu Z3RoIHRva2VuLg0KWWVzLCB0aGlzIGlzIHNwZWNpZmllZCBpbiBTZWN0aW9uIDMuMi4gLSBpdCBk ZWZpbmVzICJlbXB0eSBvcHRpb24gdmFsdWUiIGFuZCBzaW5jZSBUb2tlbiBpcyBhbiBvcHRpb24s IGVtcHR5IFRva2VuIGlzIGVxdWFsIHRvIGEgemVyby1sZW5ndGggVG9rZW4uIEFuZCB6ZXJvLWxl bmd0aCBlbmNvZGVzIHRoZSBudW1iZXIgMCBzbyB0aGF0IGlzIHRoZSBzYW1lIHRoaW5nIGFzIGEg VG9rZW4gd2l0aCBhbiBleHBsaWNpdCB6ZXJvIHZhbHVlIHB1dCBpbi4NCg0KRXNrbw0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTGlrZXBlbmcgW21haWx0bzpsaWtlcGVuZ0Bo dWF3ZWkuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAyMywgMjAxNCAwMjo1OA0KVG86IHdl aWdlbmd5dTsgRGlqaywgRXNrbzsgQWJoaWphbiBCaGF0dGFjaGFyeXlhDQpDYzogY29yZUBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtjb3JlXSBIYW5kbGluZyB0b2tlbnMgZm9yIE5vLXJlc3BvbnNl DQoNCj4gQ291bGQgYW55b25lIGhlbHAgdG8gdGVsbCB3aGF0IGRvZXMgIkFuIGVtcHR5IHRva2Vu IHZhbHVlIiBpbiBDb0FQIC0xOCBtZWFuPw0KPiBJcyBpdCB0aGUgemVybyBsZW5ndGggdG9rZW4g b3IgdGhlIHZhbHVlIG9mIHRva2VuIGJlaW5nIHplcm8/DQoNCkluIG15IHVuZGVyc3RhbmRpbmcs ICJlbXB0eSB0b2tlbiB2YWx1ZSIgbWVhbnMgemVyby1sZW5ndGggdG9rZW4uDQoNCktpbmQgUmVn YXJkcw0KS2VwZW5nDQoNCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IGNv cmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCB3ZWlnZW5neXUNCj4g5Y+R 6YCB5pe26Ze0OiAyMDE05bm0NOaciDIz5pelIDg6NDcNCj4g5pS25Lu25Lq6OiBEaWprLCBFc2tv OyBBYmhpamFuIEJoYXR0YWNoYXJ5eWENCj4g5oqE6YCBOiBjb3JlQGlldGYub3JnDQo+IOS4u+mi mDogUmU6IFtjb3JlXSBIYW5kbGluZyB0b2tlbnMgZm9yIE5vLXJlc3BvbnNlDQo+DQo+IEhpIGFs bCwNCj4NCj4gSSBhZ3JlZSB0aGF0IE5vLVJlc3BvbnNlIG1heSBuZWVkIGZvciBzb21lIHNpdHVh dGlvbnMuDQo+DQo+IEJ1dCB0aGUgZGlmZmVyZW50IGJldHdlZW4gemVybyBsZW5ndGggb2YgdG9r ZW4gYW5kIHRoZSB2YWx1ZSBvZiAgdG9rZW4NCj4gYmVpbmcgemVyb24gc2hvdWxkIGJlIGNsZWFy Lg0KPg0KPiBDb3VsZCBhbnlvbmUgaGVscCB0byB0ZWxsIHdoYXQgZG9lcyAiQW4gZW1wdHkgdG9r ZW4gdmFsdWUiIGluIENvQVAgLTE4DQo+IG1lYW4/DQo+IElzIGl0ICB0aGUgemVybyBsZW5ndGgg dG9rZW4gb3IgdGhlIHZhbHVlIG9mIHRva2VuIGJlaW5nIHplcm8/DQo+DQo+IFJlZ2FyZHMsDQo+ DQo+IEdlbmd5dQ0KPiBOZXR3b3JrIFRlY2hub2d5IENlbnRlcg0KPiBTY2hvb2wgb2YgQ29tcHV0 ZXINCj4gQmVpamluZyBVbml2ZXJzaXR5IG9mIFBvc3RzIGFuZCBUZWxlY29tbXVuaWNhdGlvbnMN Cj4NCj4gLS0tLS3ljp/lp4vpgq7ku7YtLS0tLQ0KPiBGcm9tOiBEaWprLCBFc2tvDQo+IFNlbnQ6 IFR1ZXNkYXksIEFwcmlsIDIyLCAyMDE0IDU6MzQgUE0NCj4gVG86IEFiaGlqYW4gQmhhdHRhY2hh cnl5YQ0KPiBDYzogY29yZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2NvcmVdIEhhbmRsaW5n IHRva2VucyBmb3IgTm8tcmVzcG9uc2UNCj4NCj4gSGVsbG8gQWJoaWphbiwNCj4NCj4gSSBmb3Jn b3QgdG8gbWVudGlvbiB0aGF0IHVzaW5nICB0aGUgTm8tUmVzcG9uc2UgT3B0aW9uIGlzIG5vdCBh DQo+IGd1YXJhbnRlZSB0aGF0IG5vIHJlc3BvbnNlIHdpbGwgY29tZS4gSXQgYWN0dWFsbHkgTUFZ IGNvbWUgc2luY2UgdGhlIE9wdGlvbiBpcyBlbGVjdGl2ZS4NCj4gVGhhdCBpcyBzb21ldGhpbmcg dGhhdCBuZWVkcyB0byBiZSB0YWtlbiBpbnRvIGFjY291bnQgYnkgYSBjbGllbnQgaW4NCj4gaXRz IFRva2VuIHJlLXVzZSBzdHJhdGVneS4gSWYgbm90IGl0IGxlYWRzIHRvIGludGVyb3BlcmFiaWxp dHkgaXNzdWVzLCBvciBub3Q/DQo+IEUuZy4gImNsaWVudCBleHBlY3RzIG5vIGFuc3dlciB0byBp dHMgcmVxdWVzdCB3aXRoIFRva2VuPTAsIHNvIGl0DQo+IHNlbmRzIG91dCBhIG5ldyByZXF1ZXN0 IHdpdGggVG9rZW49MCwgYnV0IHNlcnZlciBkb2VzIG5vdCByZWNvZ25pemUNCj4gTm8tUmVzcG9u c2Ugb3B0aW9uLCBhbmQgc2VuZHMgYSByZXNwb25zZSwgdGhlbiB0aGUgY2xpZW50IHJlY2VpdmVz IHRoZQ0KPiBvbGQgZGVsYXllZCByZXNwb25zZSB3aXRoDQo+IFRva2VuPTAgaW5zdGVhZCBvZiB0 aGUgbmV3ZXIgcmVzcG9uc2Ugd2l0aCBzYW1lIFRva2VuIi4NCj4NCj4gRXNrbw0KPg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGlqaywgRXNrbw0KPiBTZW50OiBUdWVzZGF5LCBBcHJp bCAyMiwgMjAxNCAwODo1Mw0KPiBUbzogQ2Fyc3RlbiBCb3JtYW5uOyBBYmhpamFuIEJoYXR0YWNo YXJ5eWENCj4gQ2M6IGNvcmVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtjb3JlXSBIYW5kbGlu ZyB0b2tlbnMgZm9yIE5vLXJlc3BvbnNlDQo+DQo+IEhpLA0KPg0KPiBpZiB0aGVyZSdzIG5vIHRp bWUgbGltaXQgdGhhdCBjYW4gYmUgZGVmaW5lZCBmb3IgVG9rZW4gcmUtdXNlLCB3aGF0IHRpbWUN Cj4gd291bGQgYW4gaW1wbGVtZW50ZXIgb2YgYSBjbGllbnQgbmVlZCB0byBjaG9vc2U/ICAgKEkg a25vdyB3ZSBjaG9zZSBub3QgdG8NCj4gZGVmaW5lICdwYXRpZW5jZScgaW4gQ29BUCwgYnV0IGFu IGltcGxlbWVudGVyIHdvdWxkIHN0aWxsIG5lZWQgdG8gbWFrZQ0KPiBhIHNhbmUgY2hvaWNlIGhl cmUuKSBDYW4gd2UgYXJndWUgdGhhdCBQYXRpZW5jZSBpLmUuIG1heCByZXNwb25zZQ0KPiBkZWxh eSB3aWxsIGJlICJhIGZldyBtaW51dGVzIiBhbmQgaGVuY2UgVG9rZW4gY2FuIGJlIHJlLXVzZWQg c2FmZWx5DQo+IGFmdGVyIGEgdGltZSBmYXIgbG9uZ2VyIHRoYW4gdGhhdCwgc2F5IDE1IG1pbnV0 ZXM/DQo+DQo+IEZvciB0aG9zZSBjYXNlcyB3aGVyZSB0aGUgaW1wbGVtZW50ZXIgb2YgdGhlIENv QVAgY2xpZW50IGtub3dzIHRoYXQgYQ0KPiByZXNwb25zZSBtYXkgdGFrZSB2ZXJ5IGxvbmcgKGUu Zy4gc2VlIE9NQSBMV00yTSBjYXNlLCAicXVldWUgbW9kZSINCj4gZnVuY3Rpb24sIHdoZXJlIGEg cmVzcG9uc2UgY291bGQgdGFrZSBlLmcuIG9uZSBkYXkpIGhlIGNvdWxkIGFkYXB0IHRoZQ0KPiBQ YXRpZW5jZSB0byBzb21ldGhpbmcgbXVjaCBsb25nZXIuDQo+DQo+IFdvdWxkIHRoYXQgYmUgYSBm ZWFzaWJsZSBhcHByb2FjaD8NCj4gSSBmZWVsIHRoYXQgaXQgd291bGQgYmUgYmVuZWZpY2lhbCBp ZiB0aGUgTm8tUmVzcG9uc2UgZHJhZnQgd291bGQgc2F5DQo+IHNvbWV0aGluZyBhYm91dCB0aGlz IFRva2VuIHJlLXVzZSBmb3IgdW5pY2FzdCBhbmQgbXVsdGljYXN0IE5PTiByZXF1ZXN0cy4NCj4g SWYgc2V2ZXJhbCBwZW9wbGUgaW4gdGhlIENvUkUgV0cgc2F3IGl0IHdyb25nLCBpdCBtYXkgYmUg d29ydGgNCj4gcG9pbnRpbmcgb3V0IGFzIHdlbGwgdG8gYSBub24tQ29SRSBhdWRpZW5jZSA7KQ0K Pg0KPiBFc2tvDQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IENhcnN0 ZW4gQm9ybWFubiBbbWFpbHRvOmNhYm9AdHppLm9yZ10NCj4gU2VudDogVGh1cnNkYXksIEFwcmls IDE3LCAyMDE0IDE1OjA4DQo+IFRvOiBBYmhpamFuIEJoYXR0YWNoYXJ5eWENCj4gQ2M6IHdlaWdl bmd5dTsgRGlqaywgRXNrbzsgUmFobWFuLCBBa2JhcjsgY29yZUBpZXRmLm9yZw0KPiBTdWJqZWN0 OiBSZTogW2NvcmVdIEhhbmRsaW5nIHRva2VucyBmb3IgTm8tcmVzcG9uc2UNCj4NCj4gT24gMTcg QXByIDIwMTQsIGF0IDE0OjIyLCBBYmhpamFuIEJoYXR0YWNoYXJ5eWENCj4gPGFiaGlqYW4uYmhh dHRhY2hhcnl5YUB0Y3MuY29tPiB3cm90ZToNCj4NCj4gPiBXZSBjYW5ub3QsIGFzIGEgZ2VuZXJh bCBwcm9wb3NpdGlvbiwgZ2V0IHJpZCBvZiB0b2tlbnMgd2hpbGUgdXNpbmcNCj4gPiBOby1yZXNw b25zZSBjb25zaWRlcmluZyBwb3RlbnRpYWwgdXNlIG9mIHRoaXMgb3B0aW9uIHdpdGggYSBHRVQg IGZvcg0KPiA+IHByb2FjdGl2ZSBjYW5jZWxsYXRpb24gb2YgYW4gb2JzZXJ2ZSBzZXNzaW9uIChS ZWY6IDwxPiBzZWN0aW9uIDMuOA0KPiA+IG9mDQo+ID4gZHJhZnQtaWV0Zi1jb3JlLW9ic2VydmUt MTMgYW5kDQo+ID4gPDI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2NvcmUv Y3VycmVudC9tc2cwNTMzMS5odG1sKS4NCj4gPiBBIEdFVCByZXF1ZXN0IHRvIGNhbmNlbCBhbiBv YnNlcnZlIHNlc3Npb24gbXVzdCBjYXJyeSBhIHRva2VuIHRvDQo+ID4gYXNzb2NpYXRlIGl0c2Vs ZiB3aXRoIHRoZSBleGlzdGluZyBvYnNlcnZlIHNlc3Npb24uDQo+DQo+IFdoaWxlIHRoaXMgaXMg dHJ1ZSwgdGhpcyBpcyBub3QgdGhlIHBvaW50IHRoYXQgSSB3YXMgbWFraW5nLg0KPiBJIHdhcyBw b2ludGluZyBvdXQgdGhhdCBhIHJlcXVlc3QgdGhhdCBpcyBkZWZpbmVkIGluIHN1Y2ggYSB3YXkg dGhhdA0KPiBpdCBNQVkgZWxpY2l0IGEgcmVzcG9uc2UgKGRlcGVuZGluZyBvbiBzb21lIGNvbmRp dGlvbiB1bmtub3duIHRvIHRoZQ0KPiBjbGllbnQgYXQgdGhlDQo+IHRpbWUpIGdlbmVyYXRlcyBo YXJkc2hpcCBmb3IgdGhlIGNsaWVudCwgYmVjYXVzZSBpbiB0aGUgYWJzZW5jZSBvZiBhDQo+IHJl c3BvbnNlIGl0IGRvZXMgbm90IGtub3cgd2hldGhlciBpdCBjYW4gcmV0aXJlIHRoZSB0b2tlbiBv ciBzdGlsbCBoYXMNCj4gdG8gZXhwZWN0IGEgcmVzcG9uc2UgZm9yIHRoYXQuDQo+DQo+IE5vdyBp ZiB0aGUgY2xpZW50IGRvZXMgbm90IGNhcmUgYWJvdXQgd2hldGhlciBhbnkgcmVzcG9uc2UgY29t aW5nIGJhY2sNCj4gaXMgcmVsYXRlZCBiYWNrIHRvIHRoZSByaWdodCByZXF1ZXN0LCBpdCBjYW4g cmV1c2UgdG9rZW5zIGF0IGxpYmVydHkuDQo+IChJbmNsdWRpbmcgdGhlIHplcm8tbGVuZ3RoIHRv a2VuLCB3aGljaCBpcyBpbiBubyB3YXkgc3BlY2lhbCwgZXhjZXB0DQo+IHRoYXQgaXQgaXMgaW5k ZWVkIHNob3J0ZXIgdGhhbiBhbnkgb3RoZXIgdG9rZW4uKQ0KPg0KPiA+IFNvLCBhcyBlbGFib3Jh dGVkIGJ5IEVza28sIHBvc3NpYmx5IGl0IHdvdWxkIGJlIGdvb2QgdG8gc3VnZ2VzdCBzb21lDQo+ ID4gdGltZS1vdXQgKHNvIGl0cyBhIE1BWSBhbmQgbm90IGEgTVVTVCB0byBnaXZlIGZsZXhpYmls aXR5IHRvIHRoZQ0KPiA+IGFwcGxpY2F0aW9uIGRldmVsb3BlciBhcyBwb2ludGVkIG91dCBieSBB a2JhciApLiBUaGUgcHJlc2VudCBkcmFmdA0KPiA+IGFkYXB0cyB0aGUgZGVmaW5pdGlvbiBvZiBO T05fTElGRVRJTUUgYXMgdGhlIHJldXNlIGludGVydmFsIGZvciBtZXNzYWdlIElEcy4NCj4gPiBX b3VsZCBpdCBiZSBhIGdvb2QgaWRlYSB0byBhZGFwdCB0aGUgc2FtZSBkZWZpbml0aW9uIGFzIHRo ZSByZS11c2UNCj4gPiBpbnRlcnZhbCBmb3IgdG9rZW5zIGFsc28/IFRoZSBkZWZpbml0aW9uIG9m IE5PTl9MSUZFVElNRSBlbmNvbXBhc3Nlcw0KPiA+IEVYQ0hBTkdFX0xJRkVUSU1FIGFzIHdlbGwu DQo+DQo+IEluIENvQVAsIHdlIGhhdmUgdGltZXJzIGF0IHRoZSBtZXNzYWdlIGxheWVyLCBub3Qg YXQgdGhlDQo+IHJlcXVlc3QvcmVzcG9uc2UgbGF5ZXIuDQo+IE1vc3QgY2xpZW50cyB3aWxsIGhh dmUgYSAicGF0aWVuY2UiIHVwIHRvIHdoaWNoIHRoZXkgd2lsbCBleHBlY3QgYQ0KPiByZXNwb25z ZSwgYnV0IHdlIGN1cnJlbnRseSBkbyBub3QgZXhwb3NlIHRoaXMgYXQgdGhlIHByb3RvY29sIGxl dmVsLg0KPiAoV2l0aCBzb21lIG5ldyBvcHRpb24sIHRoZSBjbGllbnQgY291bGQgcG9zZSBhIGRl YWRsaW5lIHRvIHRoZSBzZXJ2ZXIsDQo+IG9yIHRoZSBzZXJ2ZXIgY291bGQgcHJvbWlzZSBhIGRl YWRsaW5lIHRvIHRoZSBjbGllbnQuDQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWJvcm1hbm4tY29hcC1taXNjLTI2I2FwcGVuZGl4LUIuNCBoYXMNCj4gbW9yZSBhYm91dCB0aGF0 LikNCj4NCj4gR3IbLkEbTnwbTl9lLCBDYXJzdGVuDQo+DQo+DQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNz YWdlIG1heSBiZSBjb25maWRlbnRpYWwgYW5kDQo+IGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFw cGxpY2FibGUgbGF3LiBUaGUgbWVzc2FnZSBpcyBpbnRlbmRlZCBzb2xlbHkNCj4gZm9yIHRoZSBh ZGRyZXNzZWUocykuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBh cmUNCj4gaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHVzZSwgZm9yd2FyZGluZywgZGlzc2VtaW5h dGlvbiwgb3INCj4gcmVwcm9kdWN0aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJpY3RseSBwcm9o aWJpdGVkIGFuZCBtYXkgYmUNCj4gdW5sYXdmdWwuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZQ0KPiBzZW5kZXIgYnkgcmV0dXJuIGUtbWFp bCBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlLg0KPg0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBjb3JlIG1h aWxpbmcgbGlzdA0KPiBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vY29yZQ0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBjb3JlIG1haWxpbmcgbGlzdA0KPiBjb3JlQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KPg0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBjb3JlIG1haWxpbmcgbGlz dA0KPiBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vY29yZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVGhlIGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVn YWxseSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGljYWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVu ZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdXNlLCBmb3J3 YXJkaW5nLCBkaXNzZW1pbmF0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGlz IHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1 cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2Uu DQo= From nobody Tue Apr 22 23:43:42 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B5B1A009E for ; Tue, 22 Apr 2014 23:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c01N4pJbBhnd for ; Tue, 22 Apr 2014 23:43:35 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE021A0329 for ; Tue, 22 Apr 2014 23:43:33 -0700 (PDT) Received: from mail69-co9-R.bigfish.com (10.236.132.225) by CO9EHSOBE036.bigfish.com (10.236.130.99) with Microsoft SMTP Server id 14.1.225.22; Wed, 23 Apr 2014 06:42:27 +0000 Received: from mail69-co9 (localhost [127.0.0.1]) by mail69-co9-R.bigfish.com (Postfix) with ESMTP id 634013203A3; Wed, 23 Apr 2014 06:42:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:206.191.242.69; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:error; EFVD:FOP X-SpamScore: -29 X-BigFish: VPS-29(zzbb2dI98dI15d6Oc85fh542Ie0eah9251I217bIdd85kzz1f42h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068h1954cbhz2dh109h2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1bceh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25f6h2605h268bh26d3h1155h) Received: from mail69-co9 (localhost.localdomain [127.0.0.1]) by mail69-co9 (MessageSwitch) id 1398235345192034_17681; Wed, 23 Apr 2014 06:42:25 +0000 (UTC) Received: from CO9EHSMHS025.bigfish.com (unknown [10.236.132.239]) by mail69-co9.bigfish.com (Postfix) with ESMTP id 297B230009E; Wed, 23 Apr 2014 06:42:25 +0000 (UTC) Received: from mail.philips.com (206.191.242.69) by CO9EHSMHS025.bigfish.com (10.236.130.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 23 Apr 2014 06:42:25 +0000 Received: from AMSPRD9003MB066.MGDPHG.emi.philips.com ([169.254.5.172]) by AMSPRD9003HT001.MGDPHG.emi.philips.com ([141.251.33.78]) with mapi id 14.16.0423.000; Wed, 23 Apr 2014 06:43:20 +0000 From: "Dijk, Esko" To: Abhijan Bhattacharyya Thread-Topic: [core] Handling tokens for No-response Thread-Index: AQHPV98vDTgRdHJfpkqigWMEJ8EFKZsTthiAgABKdwCAADR9UIAAZc4ggAEBJICAACOYgIAADOSAgAdvEHCAAC9sYIAAq4KAgAC09YA= Date: Wed, 23 Apr 2014 06:43:19 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED61816A152D4@AMSPRD9003MB066.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED61816A1507A@AMSPRD9003MB066.MGDPHG.emi.philips.com>, <031DD135F9160444ABBE3B0C36CED61816A146F1@AMSPRD9003MB066.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED61816A14E84@AMSPRD9003MB066.MGDPHG.emi.philips.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.106] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED61816A152D4AMSPRD9003MB066_" MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/core/jO80BAei0aAKI9m87xE8vmr98bk Cc: "core@ietf.org" Subject: Re: [core] Handling tokens for No-response X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 06:43:40 -0000 --_000_031DD135F9160444ABBE3B0C36CED61816A152D4AMSPRD9003MB066_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Indeed, a short summary of attention points would be good in my view. And w= e can avoid stating specific timing values. Esko From: Abhijan Bhattacharyya [mailto:abhijan.bhattacharyya@tcs.com] Sent: Tuesday, April 22, 2014 21:43 To: Dijk, Esko Cc: core@ietf.org Subject: RE: [core] Handling tokens for No-response Hi Esko, You are absolutely right. No-response is just to indicate the dis-interest = of client about the response from server and if No-response is not implemen= ted in server then it will always send a response. But this response should= not have any importance to the client since the client is not interested i= n getting response. Now, coming to your example, probably the consecutive responses should not = matter much to the client if both the requests are made with No-response. H= owever, say, if the first request is with No-response and the second reques= t, with same token, is without No-response then a delayed response to the f= irst one may be interpreted as a response to the second request (client nee= ds a response in this case) if the gap between use of the same token is not= enough. >From the discussions so far, it seems we indeed need to define some timing = value based on something like 'patience' or some 'promised deadline' as poi= nted out by Carsten. But, none of these are included into/ defined for the = present main CoAP spec. Also, handling this issue may vary case to case dep= ending the application feature. So, would it not be a good idea to leave the token reuse to be handled by t= he application developer and to keep a note in the No-response draft which = would effectively summarise the different technical aspects that we have be= en discussing on this topic. Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ -----"Dijk, Esko" > wro= te: ----- To: Abhijan Bhattacharyya > From: "Dijk, Esko" > Date: 04/22/2014 03:05PM Cc: "core@ietf.org" > Subject: RE: [core] Handling tokens for No-response Hello Abhijan, I forgot to mention that using the No-Response Option is not a guarantee t= hat no response will come. It actually MAY come since the Option is electiv= e. That is something that needs to be taken into account by a client in its To= ken re-use strategy. If not it leads to interoperability issues, or not? E= .g. "client expects no answer to its request with Token=3D0, so it sends ou= t a new request with Token=3D0, but server does not recognize No-Response o= ption, and sends a response, then the client receives the old delayed respo= nse with Token=3D0 instead of the newer response with same Token". Esko -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Dijk, Esko Sent: Tuesday, April 22, 2014 08:53 To: Carsten Bormann; Abhijan Bhattacharyya Cc: core@ietf.org Subject: Re: [core] Handling tokens for No-response Hi, if there's no time limit that can be defined for Token re-use, what time wo= uld an implementer of a client need to choose? (I know we chose not to de= fine 'patience' in CoAP, but an implementer would still need to make a sane= choice here.) Can we argue that Patience i.e. max response delay will be "= a few minutes" and hence Token can be re-used safely after a time far longe= r than that, say 15 minutes? For those cases where the implementer of the CoAP client knows that a respo= nse may take very long (e.g. see OMA LWM2M case, "queue mode" function, whe= re a response could take e.g. one day) he could adapt the Patience to somet= hing much longer. Would that be a feasible approach? I feel that it would be beneficial if the No-Response draft would say somet= hing about this Token re-use for unicast and multicast NON requests. If se= veral people in the CoRE WG saw it wrong, it may be worth pointing out as w= ell to a non-CoRE audience ;) Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Thursday, April 17, 2014 15:08 To: Abhijan Bhattacharyya Cc: weigengyu; Dijk, Esko; Rahman, Akbar; core@ietf.org Subject: Re: [core] Handling tokens for No-response On 17 Apr 2014, at 14:22, Abhijan Bhattacharyya > wrote: > We cannot, as a general proposition, get rid of tokens while using No-res= ponse considering potential use of this option with a GET for proactive ca= ncellation of an observe session (Ref: <1> section 3.8 of draft-ietf-core-o= bserve-13 and <2>http://www.ietf.org/mail-archive/web/core/current/msg05331= .html). A GET request to cancel an observe session must carry a token to a= ssociate itself with the existing observe session. While this is true, this is not the point that I was making. I was pointing out that a request that is defined in such a way that it MAY= elicit a response (depending on some condition unknown to the client at th= e time) generates hardship for the client, because in the absence of a resp= onse it does not know whether it can retire the token or still has to expec= t a response for that. Now if the client does not care about whether any response coming back is r= elated back to the right request, it can reuse tokens at liberty. (Including the zero-length token, which is in no way special, except that i= t is indeed shorter than any other token.) > So, as elaborated by Esko, possibly it would be good to suggest some time= -out (so its a MAY and not a MUST to give flexibility to the application de= veloper as pointed out by Akbar ). The present draft adapts the definition = of NON_LIFETIME as the reuse interval for message IDs. Would it be a good i= dea to adapt the same definition as the re-use interval for tokens also? Th= e definition of NON_LIFETIME encompasses EXCHANGE_LIFETIME as well. In CoAP, we have timers at the message layer, not at the request/response l= ayer. Most clients will have a "patience" up to which they will expect a response= , but we currently do not expose this at the protocol level. (With some new option, the client could pose a deadline to the server, or t= he server could promise a deadline to the client. http://tools.ietf.org/html/draft-bormann-coap-misc-26#appendix-B.4 has more= about that.) Gr.AN|N_e, Carsten ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you --_000_031DD135F9160444ABBE3B0C36CED61816A152D4AMSPRD9003MB066_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Indeed, a short summary o= f attention points would be good in my view. And we can avoid stating speci= fic timing values.

 <= /p>

Esko

 <= /p>

From: Abhijan = Bhattacharyya [mailto:abhijan.bhattacharyya@tcs.com]
Sent: Tuesday, April 22, 2014 21:43
To: Dijk, Esko
Cc: core@ietf.org
Subject: RE: [core] Handling tokens for No-response

 

Hi Esko,

You are absolutely right. No-response i= s just to indicate the dis-interest of client about the response from serve= r and if No-response is not implemented in server then it will always send a response. But this response should not have any importa= nce to the client since the client is not interested in getting response.

 

Now, coming to your example, probably t= he consecutive responses should not matter much to the client if both the r= equests are made with No-response. However, say, if the first request is with No-response and the second request, with same token,= is without No-response then a delayed response to the first one may be int= erpreted as a response to the second request (client needs a response in th= is case) if the gap between use of the same token is not enough.

 

From the discussions so far, it seems w= e indeed need to define some timing value based on something like 'patience= ' or some 'promised deadline' as pointed out by Carsten. But, none of these are included into/ defined for the present main CoAP sp= ec. Also, handling this issue may vary case to case depending the applicati= on feature.

 

So, would it not be a good idea to leav= e the token reuse to be handled by the application developer and to keep a = note in the No-response draft which would effectively summarise the different technical aspects that we have been discussing on this topic= .


Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services Limited
Mailto: abhijan.bhattachar= yya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Consulting
____________________________________________



-----"Dijk, Esko" <esko.dijk@philips.com> wrote: -----

To: Abhi= jan Bhattacharyya <abhi= jan.bhattacharyya@tcs.com>
From: "Dijk, Esko" <e= sko.dijk@philips.com>
Date: 04/22/2014 03:05PM
Cc: "core@ietf.org" <core@ietf.org>
Subject: RE: [core] Handling tokens for No-response

Hello Abhijan,

I forgot to mention that using  the No-Response Option is not a guaran= tee that no response will come. It actually MAY come since the Option is el= ective.
That is something that needs to be taken into account by a client in its To= ken re-use strategy. If not it leads to interoperability issues, or not? &n= bsp;E.g. "client expects no answer to its request with Token=3D0, so i= t sends out a new request with Token=3D0, but server does not recognize No-Response option, and sends a response, then t= he client receives the old delayed response with Token=3D0 instead of the n= ewer response with same Token".

Esko

-----Original Message-----
From: core [mailto:core-bounces@ie= tf.org] On Behalf Of Dijk, Esko
Sent: Tuesday, April 22, 2014 08:53
To: Carsten Bormann; Abhijan Bhattacharyya
Cc: core@ietf.org
Subject: Re: [core] Handling tokens for No-response

Hi,

if there's no time limit that can be defined for Token re-use, what time wo= uld an implementer of a client need to choose?   (I know we chose not = to define 'patience' in CoAP, but an implementer would still need to make a= sane choice here.) Can we argue that Patience i.e. max response delay will be "a few minutes" and hen= ce Token can be re-used safely after a time far longer than that, say 15 mi= nutes?

For those cases where the implementer of the CoAP client knows that a respo= nse may take very long (e.g. see OMA LWM2M case, "queue mode" fun= ction, where a response could take e.g. one day) he could adapt the Patienc= e to something much longer.

Would that be a feasible approach?
I feel that it would be beneficial if the No-Response draft would say somet= hing about this Token re-use for unicast and multicast NON requests.  = If several people in the CoRE WG saw it wrong, it may be worth pointing out= as well to a non-CoRE audience ;)

Esko

-----Original Message-----
From: Carsten Bormann [mailto:cabo@tzi.org<= /a>]
Sent: Thursday, April 17, 2014 15:08
To: Abhijan Bhattacharyya
Cc: weigengyu; Dijk, Esko; Rahman, Akbar; = core@ietf.org
Subject: Re: [core] Handling tokens for No-response

On 17 Apr 2014, at 14:22, Abhijan Bhattacharyya <abhijan.bhattacharyya@tcs.com> wrote:

> We cannot, as a general proposition, get rid of tokens while using No-= response considering potential use of this option with a GET  for proa= ctive cancellation of an observe session (Ref: <1> section 3.8 of dra= ft-ietf-core-observe-13 and <2>http://www.ietf.org/mail-archive/web/= core/current/msg05331.html).  A GET request to cancel an observe session must carry a token to ass= ociate itself with the existing observe session.

While this is true, this is not the point that I was making.
I was pointing out that a request that is defined in such a way that it MAY= elicit a response (depending on some condition unknown to the client at th= e time) generates hardship for the client, because in the absence of a resp= onse it does not know whether it can retire the token or still has to expect a response for that.

Now if the client does not care about whether any response coming back is r= elated back to the right request, it can reuse tokens at liberty.
(Including the zero-length token, which is in no way special, except that i= t is indeed shorter than any other token.)

> So, as elaborated by Esko, possibly it would be good to suggest some t= ime-out (so its a MAY and not a MUST to give flexibility to the application= developer as pointed out by Akbar ). The present draft adapts the definiti= on of NON_LIFETIME as the reuse interval for message IDs. Would it be a good idea to adapt the same definition as t= he re-use interval for tokens also? The definition of NON_LIFETIME encompas= ses EXCHANGE_LIFETIME as well.

In CoAP, we have timers at the message layer, not at the request/response l= ayer.
Most clients will have a "patience" up to which they will expect = a response, but we currently do not expose this at the protocol level.
(With some new option, the client could pose a deadline to the server, or t= he server could promise a deadline to the client.
http://tools.ietf.org/html/draft-bormann-coap-misc-26#appendix-B.4&= nbsp;has more about that.)

Gr.AN|N_e, Carsten


________________________________
The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful= . If you are not the intended recipient, please contact the sender by retur= n e-mail and destroy all copies of the original message.

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org= /mailman/listinfo/core

=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

--_000_031DD135F9160444ABBE3B0C36CED61816A152D4AMSPRD9003MB066_-- From nobody Tue Apr 22 23:49:46 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59CAE1A0089 for ; Tue, 22 Apr 2014 23:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeVsFSFTl6nw for ; Tue, 22 Apr 2014 23:49:38 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id B48EC1A0052 for ; Tue, 22 Apr 2014 23:49:38 -0700 (PDT) Received: from localhost ([127.0.0.1]:52692 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WcqzH-00067Z-54; Wed, 23 Apr 2014 08:48:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Wed, 23 Apr 2014 06:48:53 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/366#comment:1 Message-ID: <075.5b31ab59039db94e54cc8767c9c81bf1@trac.tools.ietf.org> References: <060.d08ddf762931f56b1e0855733864e9d9@trac.tools.ietf.org> X-Trac-Ticket-ID: 366 In-Reply-To: <060.d08ddf762931f56b1e0855733864e9d9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-http-mapping@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, angelo@castellani.net, esko.dijk@philips.com, salvatore.loreto@ericsson.com, thomas.fossati@alcatel-lucent.com Archived-At: http://mailarchive.ietf.org/arch/msg/core/ELo2D3psYzfId33xlV5oAtPfB5I Cc: core@ietf.org Subject: Re: [core] #366 (http-mapping): Mapping of Link Format payloads to be valid in HTTP domain X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 06:49:44 -0000 #366: Mapping of Link Format payloads to be valid in HTTP domain Comment (by esko.dijk@philips.com): If modification is desirable - Another option is that the HC Proxy modifies /.well-known/core entries into HTTP-accessible links that can be accessed via the HC Proxy itself. For example (taking the temp sensor case in previous comment): ;rt="temperature-c";if="sensor" -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-http- esko.dijk@philips.com | mapping@tools.ietf.org Type: protocol | Status: new enhancement | Milestone: Priority: major | Version: Component: http- | Resolution: mapping | Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From nobody Wed Apr 23 01:11:01 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95ECC1A00E7 for ; Wed, 23 Apr 2014 01:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7gXcF4444TI for ; Wed, 23 Apr 2014 01:10:54 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 51E911A00CF for ; Wed, 23 Apr 2014 01:10:53 -0700 (PDT) Received: from WeiGengyuPC (unknown [10.103.241.231]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id D7BB519F383; Wed, 23 Apr 2014 16:10:46 +0800 (HKT) Message-ID: <18852522B6D344088ABE3A62ECC832C6@WeiGengyuPC> From: "weigengyu" To: "Dijk, Esko" , "Likepeng" , "Abhijan Bhattacharyya" References: <031DD135F9160444ABBE3B0C36CED61816A146F1@AMSPRD9003MB066.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED61816A14E84@AMSPRD9003MB066.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED61816A1507A@AMSPRD9003MB066.MGDPHG.emi.philips.com> <403D1CF4497D40529FC2E6138311A813@WeiGengyuPC> <34966E97BE8AD64EAE9D3D6E4DEE36F252B22B60@SZXEMA501-MBS.china.huawei.com> <031DD135F9160444ABBE3B0C36CED61816A15292@AMSPRD9003MB066.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED61816A15292@AMSPRD9003MB066.MGDPHG.emi.philips.com> Date: Wed, 23 Apr 2014 16:10:46 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Archived-At: http://mailarchive.ietf.org/arch/msg/core/3ZsJJpWchOzMyEBjdh9SisMA0p0 Cc: core@ietf.org Subject: Re: [core] Handling tokens for No-response X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 08:10:59 -0000 HI, Thanks Kepeng and Esko for your answers. If the token length is ZERO, then there is no token. So the token is empty. If the token length is one, for example, the value of the token could be from 0 to 255. In this case, when the value of token is 0, the token is not empty. As the sematics of Zero length token is defined in CoAP -18, when No-Response is identified by Zeron length token, it can not get an effect. It seems better to make No-Response explicit and clear. And, "Token re-use strategy" is required for the implementation. We name it as token significant time, token is regard as being used within this time interval. But it is different from Patience, and is longer than Patience. Regards, Gengyu Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----鍘熷閭欢----- From: Dijk, Esko Sent: Wednesday, April 23, 2014 1:33 PM To: Likepeng ; weigengyu ; Abhijan Bhattacharyya Cc: core@ietf.org Subject: RE: [core] Handling tokens for No-response > In my understanding, "empty token value" means zero-length token. Yes, this is specified in Section 3.2. - it defines "empty option value" and since Token is an option, empty Token is equal to a zero-length Token. And zero-length encodes the number 0 so that is the same thing as a Token with an explicit zero value put in. Esko -----Original Message----- From: Likepeng [mailto:likepeng@huawei.com] Sent: Wednesday, April 23, 2014 02:58 To: weigengyu; Dijk, Esko; Abhijan Bhattacharyya Cc: core@ietf.org Subject: Re: [core] Handling tokens for No-response > Could anyone help to tell what does "An empty token value" in CoAP -18 > mean? > Is it the zero length token or the value of token being zero? In my understanding, "empty token value" means zero-length token. Kind Regards Kepeng > -----閭欢鍘熶欢----- > 鍙戜欢浜: core [mailto:core-bounces@ietf.org] 浠ｈ〃 weigengyu > 鍙戦佹椂闂: 2014骞4鏈23鏃 8:47 > 鏀朵欢浜: Dijk, Esko; Abhijan Bhattacharyya > 鎶勯: core@ietf.org > 涓婚: Re: [core] Handling tokens for No-response > > Hi all, > > I agree that No-Response may need for some situations. > > But the different between zero length of token and the value of token > being zeron should be clear. > > Could anyone help to tell what does "An empty token value" in CoAP -18 > mean? > Is it the zero length token or the value of token being zero? > > Regards, > > Gengyu > Network Technogy Center > School of Computer > Beijing University of Posts and Telecommunications > > -----鍘熷閭欢----- > From: Dijk, Esko > Sent: Tuesday, April 22, 2014 5:34 PM > To: Abhijan Bhattacharyya > Cc: core@ietf.org > Subject: Re: [core] Handling tokens for No-response > > Hello Abhijan, > > I forgot to mention that using the No-Response Option is not a > guarantee that no response will come. It actually MAY come since the > Option is elective. > That is something that needs to be taken into account by a client in > its Token re-use strategy. If not it leads to interoperability issues, or > not? > E.g. "client expects no answer to its request with Token=0, so it > sends out a new request with Token=0, but server does not recognize > No-Response option, and sends a response, then the client receives the > old delayed response with > Token=0 instead of the newer response with same Token". > > Esko > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Dijk, Esko > Sent: Tuesday, April 22, 2014 08:53 > To: Carsten Bormann; Abhijan Bhattacharyya > Cc: core@ietf.org > Subject: Re: [core] Handling tokens for No-response > > Hi, > > if there's no time limit that can be defined for Token re-use, what time > would an implementer of a client need to choose? (I know we chose not to > define 'patience' in CoAP, but an implementer would still need to make > a sane choice here.) Can we argue that Patience i.e. max response > delay will be "a few minutes" and hence Token can be re-used safely > after a time far longer than that, say 15 minutes? > > For those cases where the implementer of the CoAP client knows that a > response may take very long (e.g. see OMA LWM2M case, "queue mode" > function, where a response could take e.g. one day) he could adapt the > Patience to something much longer. > > Would that be a feasible approach? > I feel that it would be beneficial if the No-Response draft would say > something about this Token re-use for unicast and multicast NON requests. > If several people in the CoRE WG saw it wrong, it may be worth > pointing out as well to a non-CoRE audience ;) > > Esko > > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Thursday, April 17, 2014 15:08 > To: Abhijan Bhattacharyya > Cc: weigengyu; Dijk, Esko; Rahman, Akbar; core@ietf.org > Subject: Re: [core] Handling tokens for No-response > > On 17 Apr 2014, at 14:22, Abhijan Bhattacharyya > wrote: > > > We cannot, as a general proposition, get rid of tokens while using > > No-response considering potential use of this option with a GET for > > proactive cancellation of an observe session (Ref: <1> section 3.8 > > of > > draft-ietf-core-observe-13 and > > <2>http://www.ietf.org/mail-archive/web/core/current/msg05331.html). > > A GET request to cancel an observe session must carry a token to > > associate itself with the existing observe session. > > While this is true, this is not the point that I was making. > I was pointing out that a request that is defined in such a way that > it MAY elicit a response (depending on some condition unknown to the > client at the > time) generates hardship for the client, because in the absence of a > response it does not know whether it can retire the token or still has > to expect a response for that. > > Now if the client does not care about whether any response coming back > is related back to the right request, it can reuse tokens at liberty. > (Including the zero-length token, which is in no way special, except > that it is indeed shorter than any other token.) > > > So, as elaborated by Esko, possibly it would be good to suggest some > > time-out (so its a MAY and not a MUST to give flexibility to the > > application developer as pointed out by Akbar ). The present draft > > adapts the definition of NON_LIFETIME as the reuse interval for message > > IDs. > > Would it be a good idea to adapt the same definition as the re-use > > interval for tokens also? The definition of NON_LIFETIME encompasses > > EXCHANGE_LIFETIME as well. > > In CoAP, we have timers at the message layer, not at the > request/response layer. > Most clients will have a "patience" up to which they will expect a > response, but we currently do not expose this at the protocol level. > (With some new option, the client could pose a deadline to the server, > or the server could promise a deadline to the client. > http://tools.ietf.org/html/draft-bormann-coap-misc-26#appendix-B.4 has > more about that.) > > Gr.AN|N_e, Carsten > > > ________________________________ > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original message. > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From nobody Wed Apr 23 01:23:02 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95BAC1A00CF for ; Wed, 23 Apr 2014 01:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W66nbKPnvT9D for ; Wed, 23 Apr 2014 01:22:59 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1F83D1A0113 for ; Wed, 23 Apr 2014 01:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s3N8Mbvr021220; Wed, 23 Apr 2014 10:22:37 +0200 (CEST) Received: from [192.168.217.105] (p548928E2.dip0.t-ipconnect.de [84.137.40.226]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1C2A313C4; Wed, 23 Apr 2014 10:22:35 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann X-Priority: 3 In-Reply-To: <18852522B6D344088ABE3A62ECC832C6@WeiGengyuPC> Date: Wed, 23 Apr 2014 10:22:35 +0200 X-Mao-Original-Outgoing-Id: 419934155.635271-612c1e83bbc0ed0beccaf91661edb70d Content-Transfer-Encoding: quoted-printable Message-Id: <7E67612B-AAB6-4611-BD3C-A9FBA3884344@tzi.org> References: <031DD135F9160444ABBE3B0C36CED61816A146F1@AMSPRD9003MB066.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED61816A14E84@AMSPRD9003MB066.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED61816A1507A@AMSPRD9003MB066.MGDPHG.emi.philips.com> <403D1CF4497D40529FC2E6138311A813@WeiGengyuPC> <34966E97BE8AD64EAE9D3D6E4DEE36F252B22B60@SZXEMA501-MBS.china.huawei.com> <031DD135F9160444ABBE3B0C36CED61816A15292@AMSPRD9003MB066.MGDPHG.emi.philips.com> <18852522B6D344088ABE3A62ECC832C6@WeiGengyuPC> To: weigengyu X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/core/oEbwLdyQWW7JibKzt8ffoFJO1MM Cc: Abhijan Bhattacharyya , core@ietf.org Subject: Re: [core] Handling tokens for No-response X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 08:23:00 -0000 A number of clarifications about =93empty tokens": > If the token length is ZERO, then there is no token. So the token is = empty. If the token length is zero, there still is a token, it is just of = length zero. There is nothing special about this token value; I have no idea why this = is discussed as if it were. > If the token length is one, for example, the value of the token could = be from 0 to 255. The token is an opaque byte string (for a one-byte token, the value of = the first and only byte would indeed be between 0 and 255). > In this case, when the value of token is 0, the token is not empty. Indeed, what you mean seems to be just another token value, a byte = string of length 1 with a zero byte. > As the sematics of Zero length token is defined in CoAP -18, Zero length tokens do not have any special semantics as defined in the = CoAP specification. > when No-Response is identified by Zeron length token, it can not get = an effect. Non sequitur. The discussion of how to choose token values, including when a = previously used token can be used again, is quite relevant for a client = implementation (and I would expect the LWIG document to gain some = substance here in the next revision), but there is nothing special about = the zero-length token value in this discussion. Gr=FC=DFe, Carsten From nobody Wed Apr 23 03:43:26 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C336E1A01D1 for ; Wed, 23 Apr 2014 03:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdCxZLpRY88H for ; Wed, 23 Apr 2014 03:43:19 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 3708E1A032E for ; Wed, 23 Apr 2014 03:43:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,911,1389724200"; d="scan'208";a="526061884" Received: from INKOLSALDLPMTA1.india.tcs.com (unknown [127.0.0.1]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 34C48DAC17; Wed, 23 Apr 2014 16:13:05 +0530 (IST) Received: from InKolM02.tcs.com (unknown [172.18.18.104]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id EC871DAC14; Wed, 23 Apr 2014 16:13:04 +0530 (IST) In-Reply-To: <7E67612B-AAB6-4611-BD3C-A9FBA3884344@tzi.org> References: <031DD135F9160444ABBE3B0C36CED61816A146F1@AMSPRD9003MB066.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED61816A14E84@AMSPRD9003MB066.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED61816A1507A@AMSPRD9003MB066.MGDPHG.emi.philips.com> <403D1CF4497D40529FC2E6138311A813@WeiGengyuPC> <34966E97BE8AD64EAE9D3D6E4DEE36F252B22B60@SZXEMA501-MBS.china.huawei.com> <031D <7E67612B-AAB6-4611-BD3C-A9FBA3884344@tzi.org> To: Carsten Bormann MIME-Version: 1.0 X-KeepSent: C0F1162C:1BB4722E-65257CC3:00363C8B; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0 March 08, 2013 From: Abhijan Bhattacharyya Message-ID: Date: Wed, 23 Apr 2014 16:12:41 +0530 X-MIMETrack: Serialize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 04/23/2014 16:12:42, Serialize complete at 04/23/2014 16:12:42, Serialize by Router on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 04/23/2014 16:13:04, Serialize complete at 04/23/2014 16:13:04 Content-Type: multipart/alternative; boundary="=_alternative 003AD5A965257CC3_=" Archived-At: http://mailarchive.ietf.org/arch/msg/core/qtT75ZDJABxEguY0CDseH-HdjVc Cc: core@ietf.org Subject: Re: [core] Handling tokens for No-response X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 10:43:23 -0000 This is a multipart message in MIME format. --=_alternative 003AD5A965257CC3_= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Carsten, > The discussion of how to choose token values, including when a = > previously used token can be used again, is quite relevant for a = > client implementation (and I would expect the LWIG document to gain = > some substance here in the next revision) If I have understood correctly, by LWIG document you are referring to the = LWIG draft on CoAP implementation guidance. Possibly, it can have one more = subsection "2.4.3. Tokens for No-Response/ unidirectional request" or = something like that. The problem is, tokens are conceptualized with a = matching criteria. Section 2.4 of draft-kovatsch-lwig-coap-03 reads: "This = begins when being assigned to a request and ends when the open request is = closed by receiving and matching the final response". Unidirectional = requests basically deviates from this primary concept of token usage. And = we would need to define some timing at the request/response layer if we = have to give some specific direction in the draft. Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ Carsten Bormann wrote on 04/23/2014 01:52:35 PM: > From: > = > Carsten Bormann > = > To: > = > weigengyu > = > Cc: > = > "Dijk, Esko" , Likepeng = > , Abhijan Bhattacharyya = > , core@ietf.org > = > Date: > = > 04/23/2014 01:52 PM > = > Subject: > = > Re: [core] Handling tokens for No-response > = > A number of clarifications about ?empty tokens": > = > > If the token length is ZERO, then there is no token. So the token is = empty. > = > If the token length is zero, there still is a token, it is just of = > length zero. > There is nothing special about this token value; I have no idea why = > this is discussed as if it were. > = > > If the token length is one, for example, the value of the token = > could be from 0 to 255. > = > The token is an opaque byte string (for a one-byte token, the value = > of the first and only byte would indeed be between 0 and 255). > = > > In this case, when the value of token is 0, the token is not empty. > = > Indeed, what you mean seems to be just another token value, a byte = > string of length 1 with a zero byte. > = > > As the sematics of Zero length token is defined in CoAP -18, > = > Zero length tokens do not have any special semantics as defined in = > the CoAP specification. > = > > when No-Response is identified by Zeron length token, it can not = > get an effect. > = > Non sequitur. > = > The discussion of how to choose token values, including when a = > previously used token can be used again, is quite relevant for a = > client implementation (and I would expect the LWIG document to gain = > some substance here in the next revision), but there is nothing = > special about the zero-length token value in this discussion. > = > Gr=FC=DFe, Carsten > = =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain = confidential or privileged information. If you are = not the intended recipient, any dissemination, use, = review, distribution, printing or copying of the = information contained in this e-mail message = and/or attachments to it are strictly prohibited. If = you have received this communication in error, = please notify us by reply e-mail or telephone and = immediately and permanently delete the message = and any attachments. Thank you --=_alternative 003AD5A965257CC3_= MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Carsten,

> The discussion of how to choose token values, including when a
> previously used token can be used again, is quite relevant for a
> client implementation (and I would expect the LWIG document to gain
> some substance here in the next revision)

If I have understood correctly, by LWIG document you are referring to the LWIG draft on CoAP implementation guidance. Possibly, it can have one more subsection "2.4.3. Tokens for No-Response/ unidir= ectional request" or something like that. The problem is, tokens are conceptual= ized with a matching criteria. Section 2.4 of draft-kovatsch-lwig-coap-03 reads: "This begins when being assigned to a request and ends when the open request is closed by receiving and matching the final response". Unidi= rectional requests basically deviates from this primary concept of token usage. And we would need to define some timing at the request/response layer if we have to give some specific direction in the draft.

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services Limited
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Consulting
____________________________________________

Carsten Bormann <cabo@tzi.org> wrote on 04/23/= 2014 01:52:35 PM:

> From:
>
> Carsten Bormann <cabo@tzi.org>
>
> To:
>
> weigengyu <weigengyu@bupt.edu.cn>
>
> Cc:
>
> "Dijk, Esko" <esko.dijk@philips.com>, Likepeng
> <likepeng@huawei.com>, Abhijan Bhattacharyya
> <abhijan.bhattacharyya@tcs.com>, core@ietf.org
>
> Date:
>
> 04/23/2014 01:52 PM
>
> Subject:
>
> Re: [core] Handling tokens for No-response
>
> A number of clarifications about “empty tokens":
>
> > If the token length is ZERO, then there is no token. So the token is empty.
>
> If the token length is zero, there still is a token, it is just of
> length zero.
> There is nothing special about this token value; I have no idea why
> this is discussed as if it were.
>
> > If the token length is one, for example, the value of the token
> could be from 0 to 255.
>
> The token is an opaque byte string (for a one-byte token, the value
> of the first and only byte would indeed be between 0 and 255).
>
> >  In this case, when the value of token is 0, the token is not empty.
>
> Indeed, what you mean seems to be just another token value, a byte
> string of length 1 with a zero byte.
>
> > As the sematics of Zero length token is defined in CoAP -18,
>
> Zero length tokens do not have any special semantics as defined in
> the CoAP specification.
>
> > when No-Response is identified by Zeron length token, it can not
> get an effect.
>
> Non sequitur.
>
> The discussion of how to choose token values, including when a
> previously used token can be used again, is quite relevant for a
> client implementation (and I would expect the LWIG document to gain
> some substance here in the next revision), but there is nothing
> special about the zero-length token value in this discussion.
>
> Gr=FC=DFe, Carsten
>

=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

--=_alternative 003AD5A965257CC3_=-- From nobody Wed Apr 23 06:19:15 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C151A03A5 for ; Wed, 23 Apr 2014 06:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLelxPEXfduS for ; Wed, 23 Apr 2014 06:19:09 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id AE4551A0362 for ; Wed, 23 Apr 2014 06:19:08 -0700 (PDT) Received: from WeiGengyuPC (unknown [221.218.46.77]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 540AA19F36A; Wed, 23 Apr 2014 21:19:02 +0800 (HKT) Message-ID: From: "weigengyu" To: "Carsten Bormann" References: <031DD135F9160444ABBE3B0C36CED61816A146F1@AMSPRD9003MB066.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED61816A14E84@AMSPRD9003MB066.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED61816A1507A@AMSPRD9003MB066.MGDPHG.emi.philips.com> <403D1CF4497D40529FC2E6138311A813@WeiGengyuPC> <34966E97BE8AD64EAE9D3D6E4DEE36F252B22B60@SZXEMA501-MBS.china.huawei.com> <031DD135F9160444ABBE3B0C36CED61816A15292@AMSPRD9003MB066.MGDPHG.emi.philips.com> <18852522B6D344088ABE3A62ECC832C6@WeiGengyuPC> <7E67612B-AAB6-4611-BD3C-A9FBA3884344@tzi.org> In-Reply-To: <7E67612B-AAB6-4611-BD3C-A9FBA3884344@tzi.org> Date: Wed, 23 Apr 2014 21:19:00 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Archived-At: http://mailarchive.ietf.org/arch/msg/core/jg-gf8QFmx87hSjmqw6RGPUHGoE Cc: Abhijan Bhattacharyya , core@ietf.org Subject: Re: [core] Handling tokens for No-response X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 13:19:12 -0000 Hi, I think the following sentence need being clarified: In CoAP -18 page 34, "The client SHOULD generate tokens in such a way that tokens currently in use for a given source/destination endpoint pair are unique. (Note that a client implementation can use the same token for any request if it uses a different endpoint each time, e.g. a different source port number.) An empty token value is appropriate e.g. when no other tokens are in use to a destination, or when requests are made serially per destination and receive piggy-backed responses. There are however multiple possible implementation strategies to fulfill this. " By this, zero length token is a token, it can be used the same way as other tokens. If the request is with zero token, the response should adopt the zero token too. Angthing wrong? Regards, Network Technology Center School of Computer Beijing University of Posts and Telecommunications. -----鍘熷閭欢----- From: Carsten Bormann Sent: Wednesday, April 23, 2014 4:22 PM To: weigengyu Cc: Dijk, Esko ; Likepeng ; Abhijan Bhattacharyya ; core@ietf.org Subject: Re: [core] Handling tokens for No-response A number of clarifications about 鈥渆mpty tokens": > If the token length is ZERO, then there is no token. So the token is > empty. If the token length is zero, there still is a token, it is just of length zero. There is nothing special about this token value; I have no idea why this is discussed as if it were. > If the token length is one, for example, the value of the token could be > from 0 to 255. The token is an opaque byte string (for a one-byte token, the value of the first and only byte would indeed be between 0 and 255). > In this case, when the value of token is 0, the token is not empty. Indeed, what you mean seems to be just another token value, a byte string of length 1 with a zero byte. > As the sematics of Zero length token is defined in CoAP -18, Zero length tokens do not have any special semantics as defined in the CoAP specification. > when No-Response is identified by Zeron length token, it can not get an > effect. Non sequitur. The discussion of how to choose token values, including when a previously used token can be used again, is quite relevant for a client implementation (and I would expect the LWIG document to gain some substance here in the next revision), but there is nothing special about the zero-length token value in this discussion. Gr眉脽e, Carsten From nobody Wed Apr 23 06:46:17 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 298EC1A020F for ; Wed, 23 Apr 2014 06:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SJwwFdjd5_n for ; Wed, 23 Apr 2014 06:46:14 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 92A201A03A5 for ; Wed, 23 Apr 2014 06:46:12 -0700 (PDT) Received: from WeiGengyuPC (unknown [221.218.46.77]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id DC9F519F36A; Wed, 23 Apr 2014 21:46:05 +0800 (HKT) Message-ID: From: "weigengyu" To: "Carsten Bormann" Date: Wed, 23 Apr 2014 21:46:04 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Archived-At: http://mailarchive.ietf.org/arch/msg/core/xEm9biHQVqoYqGC5xUeWB7x5LVo Cc: Abhijan Bhattacharyya , core@ietf.org Subject: Re: [core] Handling tokens for No-response X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 13:46:16 -0000 >> As the sematics of Zero length token is defined in CoAP -18, >Zero length tokens do not have any special semantics as defined in the CoAP >specification. CoAP -18 defines the Zero length token the same as other tokens, so Zero length token has sematics already. No words say "any special semantics". One alternative of No-Response trys to give Zero length token one "special semantics". By current CoAP -18, using Zero length token as No-response option will not get effect. Regards, Gengyu Network Techonology Center School of Computer Beijing University of Posts and Telecommunications. -----鍘熷閭欢----- From: weigengyu Sent: Wednesday, April 23, 2014 9:19 PM To: Carsten Bormann Cc: Dijk, Esko ; Likepeng ; Abhijan Bhattacharyya ; core@ietf.org Subject: Re: [core] Handling tokens for No-response Hi, I think the following sentence need being clarified: In CoAP -18 page 34, "The client SHOULD generate tokens in such a way that tokens currently in use for a given source/destination endpoint pair are unique. (Note that a client implementation can use the same token for any request if it uses a different endpoint each time, e.g. a different source port number.) An empty token value is appropriate e.g. when no other tokens are in use to a destination, or when requests are made serially per destination and receive piggy-backed responses. There are however multiple possible implementation strategies to fulfill this. " By this, zero length token is a token, it can be used the same way as other tokens. If the request is with zero token, the response should adopt the zero token too. Angthing wrong? Regards, Network Technology Center School of Computer Beijing University of Posts and Telecommunications. -----鍘熷閭欢----- From: Carsten Bormann Sent: Wednesday, April 23, 2014 4:22 PM To: weigengyu Cc: Dijk, Esko ; Likepeng ; Abhijan Bhattacharyya ; core@ietf.org Subject: Re: [core] Handling tokens for No-response A number of clarifications about 鈥渆mpty tokens": > If the token length is ZERO, then there is no token. So the token is > empty. If the token length is zero, there still is a token, it is just of length zero. There is nothing special about this token value; I have no idea why this is discussed as if it were. > If the token length is one, for example, the value of the token could be > from 0 to 255. The token is an opaque byte string (for a one-byte token, the value of the first and only byte would indeed be between 0 and 255). > In this case, when the value of token is 0, the token is not empty. Indeed, what you mean seems to be just another token value, a byte string of length 1 with a zero byte. > As the sematics of Zero length token is defined in CoAP -18, Zero length tokens do not have any special semantics as defined in the CoAP specification. > when No-Response is identified by Zeron length token, it can not get an > effect. Non sequitur. The discussion of how to choose token values, including when a previously used token can be used again, is quite relevant for a client implementation (and I would expect the LWIG document to gain some substance here in the next revision), but there is nothing special about the zero-length token value in this discussion. Gr眉脽e, Carsten From nobody Wed Apr 23 12:27:17 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACAE11A049A for ; Wed, 23 Apr 2014 12:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.471 X-Spam-Level: X-Spam-Status: No, score=-4.471 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZ8JF-j0B6sO for ; Wed, 23 Apr 2014 12:27:08 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id A37791A0552 for ; Wed, 23 Apr 2014 12:27:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,913,1389724200"; d="scan'208";a="526286497" Received: from INKOLSALDLPMTA1.india.tcs.com (unknown [127.0.0.1]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 432F2DAC12; Thu, 24 Apr 2014 00:56:58 +0530 (IST) Received: from InKolM02.tcs.com (unknown [172.18.18.104]) by INKOLSALDLPMTA1.india.tcs.com (Service) with ESMTP id 0E293DAC02; Thu, 24 Apr 2014 00:56:58 +0530 (IST) MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: From: Abhijan Bhattacharyya To: "weigengyu" Message-ID: Date: Thu, 24 Apr 2014 00:56:55 +0530 X-Mailer: Lotus Domino Web Server Release 9.0HF507 August 20, 2013 X-MIMETrack: Serialize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 04/24/2014 00:56:55, Serialize complete at 04/24/2014 00:56:55, Itemize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 04/24/2014 00:56:55, Serialize by Notes Server on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 04/24/2014 00:56:56, Serialize complete at 04/24/2014 00:56:56, Serialize by Router on InKolM02/TCS(Release 9.0HF507 | August 20, 2013) at 04/24/2014 00:56:57, Serialize complete at 04/24/2014 00:56:57 Content-Type: multipart/alternative; boundary="=_alternative 006AD5E465257CC3_=" Archived-At: http://mailarchive.ietf.org/arch/msg/core/O7CYlBZUbbGkyUpAzlgNTumikQ4 Cc: core@ietf.org Subject: Re: [core] Handling tokens for No-response X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 19:27:13 -0000 --=_alternative 006AD5E465257CC3_= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi=A0Gengyu, >One alternative of No-Response trys to give Zero length token one >"special=A0 >semantics". Your comment is not really clear to me.=A0I am not sure if I understand wha= t you mean by 'one alternative of No-response'. =A0 The present draft on No-response does not mention anything about token and = that is why we are carrying out this discussion to bridge the gap. Use of z= ero length token came up as part of the discussion. However, the confusions= have already been cleared by Carsten and Esko. No-response is not at all t= rying to give any special semantics to anything.=A0 Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ -----"weigengyu" wrote: ----- >To: "Carsten Bormann" >From: "weigengyu" >Date: 04/23/2014 07:16PM >Cc: "Dijk, Esko" , "Likepeng" >, "Abhijan Bhattacharyya" >, >Subject: Re: [core] Handling tokens for No-response > >>> As the sematics of Zero length token is defined in CoAP -18, >>Zero length tokens do not have any special semantics as defined in >the CoAP = >>specification. > >CoAP -18 defines the Zero length token the same as other tokens, >so Zero length token has sematics already. >No words say "any special semantics". > >One alternative of No-Response trys to give Zero length token one >"special = >semantics". >By current CoAP -18, using Zero length token as No-response option >will not = >get effect. > >Regards, > >Gengyu >Network Techonology Center >School of Computer >Beijing University of Posts and Telecommunications. > >-----原始邮件----- = >From: weigengyu >Sent: Wednesday, April 23, 2014 9:19 PM >To: Carsten Bormann >Cc: Dijk, Esko ; Likepeng ; Abhijan Bhattacharyya ; core@ietf.org >Subject: Re: [core] Handling tokens for No-response > >Hi, > >I think the following sentence need being clarified: > >In CoAP -18 page 34, >"The client SHOULD generate tokens in such a way that tokens >currently >in use for a given source/destination endpoint pair are unique. >(Note that a client implementation can use the same token for any >request if it uses a different endpoint each time, e.g. a different >source port number.) An empty token value is appropriate e.g. when >no other tokens are in use to a destination, or when requests are >made serially per destination and receive piggy-backed responses. >There are however multiple possible implementation strategies to >fulfill this. " > >By this, zero length token is a token, it can be used the same way as >other >tokens. >If the request is with zero token, the response should adopt the zero >token >too. > >Angthing wrong? > >Regards, > >Network Technology Center >School of Computer >Beijing University of Posts and Telecommunications. > > >-----原始邮件----- = >From: Carsten Bormann >Sent: Wednesday, April 23, 2014 4:22 PM >To: weigengyu >Cc: Dijk, Esko ; Likepeng ; Abhijan Bhattacharyya ; core@ietf.org >Subject: Re: [core] Handling tokens for No-response > >A number of clarifications about “empty tokens": > >> If the token length is ZERO, then there is no token. So the token >is = >> empty. > >If the token length is zero, there still is a token, it is just of >length >zero. >There is nothing special about this token value; I have no idea why >this is >discussed as if it were. > >> If the token length is one, for example, the value of the token >could be = >> from 0 to 255. > >The token is an opaque byte string (for a one-byte token, the value >of the >first and only byte would indeed be between 0 and 255). > >> In this case, when the value of token is 0, the token is not >empty. > >Indeed, what you mean seems to be just another token value, a byte >string of >length 1 with a zero byte. > >> As the sematics of Zero length token is defined in CoAP -18, > >Zero length tokens do not have any special semantics as defined in >the CoAP >specification. > >> when No-Response is identified by Zeron length token, it can not >get an = >> effect. > >Non sequitur. > >The discussion of how to choose token values, including when a >previously >used token can be used again, is quite relevant for a client >implementation >(and I would expect the LWIG document to gain some substance here in >the >next revision), but there is nothing special about the zero-length >token >value in this discussion. > >Gr=FC=DFe, Carsten = > > =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain = confidential or privileged information. If you are = not the intended recipient, any dissemination, use, = review, distribution, printing or copying of the = information contained in this e-mail message = and/or attachments to it are strictly prohibited. If = you have received this communication in error, = please notify us by reply e-mail or telephone and = immediately and permanently delete the message = and any attachments. Thank you --=_alternative 006AD5E465257CC3_= Content-ID: <> MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Gengyu,
>One alternative of No-Response trys to giv= e Zero length token one
>"special 
>semantics".
=
Your comment is not really clear to me. I am not sure if I understand w= hat you mean by 'one alternative of No-response'.  
T= he present draft on No-response does not mention anything about token and t= hat is why we are carrying out this discussion to bridge the gap. Use of ze= ro length token came up as part of the discussion. However, the confusions = have already been cleared by Carsten and Esko. No-response is not at all tr= ying to give any special semantics to anything. 


RegardsAbhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab= , Kolkata, India
Tata Consultancy Services Limited
Mailto: abhijan.bhattacharyya@tcs.comWebsite: http://www.tcs.com
________= ____________________________________
Experience certainty. IT Services Business Solutions
Consulting
_______________________________= _____________


-----"weigengyu" <wei= gengyu@bupt.edu.cn> wrote: -----

>To: "Carsten Bormann"= <cabo@tzi.org>
>From: "weigengyu" <weigengyu@bupt.edu.cn>= ;
>Date: 04/23/2014 07:16PM
>Cc: "Dijk, Esko" <esko.dijk@phi= lips.com>, "Likepeng"
><likepeng@huawei.com>, "Abhijan Bhatt= acharyya"
><abhijan.bhattacharyya@tcs.com>, <core@ietf.org&g= t;
>Subject: Re: [core] Handling tokens for No-response
>
&g= t;>> As the sematics of Zero length token is defined in CoAP -18,
= >>Zero length tokens do not have any special semantics as defined in<= br>>the CoAP
>>specification.
>
>CoAP -18 defines = the Zero length token the same as other tokens,
>so Zero length token= has sematics already.
>No words say "any special semantics".
>=
>One alternative of No-Response trys to give Zero length token one>"special
>semantics".
>By current CoAP -18, using Zero l= ength token as No-response option
>will not
>get effect.
&g= t;
>Regards,
>
>Gengyu
>Network Techonology Center<= br>>School of Computer
>Beijing University of Posts and Telecommun= ications.
>
>-----原始邮件-----
>= ;From: weigengyu
>Sent: Wednesday, April 23, 2014 9:19 PM
>To: = Carsten Bormann
>Cc: Dijk, Esko ; Likepeng ; Abhijan Bhattacharyya ; = core@ietf.org
>Subject: Re: [core] Handling tokens for No-response>
>Hi,
>
>I think the following sentence need being c= larified:
>
>In CoAP -18 page 34,
>"The client SHOULD gen= erate tokens in such a way that tokens
>currently
>in use for a= given source/destination endpoint pair are unique.
>(Note that a cli= ent implementation can use the same token for any
>request if it uses= a different endpoint each time, e.g. a different
>source port number= .) An empty token value is appropriate e.g. when
>no other tokens are= in use to a destination, or when requests are
>made serially per des= tination and receive piggy-backed responses.
>There are however multi= ple possible implementation strategies to
>fulfill this. "
>>By this, zero length token is a token, it can be used the same way as<= br>>other
>tokens.
>If the request is with zero token, the r= esponse should adopt the zero
>token
>too.
>
>Angth= ing wrong?
>
>Regards,
>
>Network Technology Center=
>School of Computer
>Beijing University of Posts and Telecommu= nications.
>
>
>-----原始邮件----= -
>From: Carsten Bormann
>Sent: Wednesday, April 23, 2014 4:22= PM
>To: weigengyu
>Cc: Dijk, Esko ; Likepeng ; Abhijan Bhattac= haryya ; core@ietf.org
>Subject: Re: [core] Handling tokens for No-re= sponse
>
>A number of clarifications about “empty tokens"= :
>
>> If the token length is ZERO, then there is no token. = So the token
>is
>> empty.
>
>If the token leng= th is zero, there still is a token, it is just of
>length
>zero= .
>There is nothing special about this token value; I have no idea wh= y
>this is
>discussed as if it were.
>
>> If the= token length is one, for example, the value of the token
>could be <= br>>> from 0 to 255.
>
>The token is an opaque byte strin= g (for a one-byte token, the value
>of the
>first and only byte= would indeed be between 0 and 255).
>
>> In this case, whe= n the value of token is 0, the token is not
>empty.
>
>In= deed, what you mean seems to be just another token value, a byte
>str= ing of
>length 1 with a zero byte.
>
>> As the sematic= s of Zero length token is defined in CoAP -18,
>
>Zero length t= okens do not have any special semantics as defined in
>the CoAP
&g= t;specification.
>
>> when No-Response is identified by Zero= n length token, it can not
>get an
>> effect.
>
&g= t;Non sequitur.
>
>The discussion of how to choose token values= , including when a
>previously
>used token can be used again, i= s quite relevant for a client
>implementation
>(and I would exp= ect the LWIG document to gain some substance here in
>the
>next= revision), but there is nothing special about the zero-length
>token=
>value in this discussion.
>
>Gr=FC=DFe, Carsten
>= ;
>

=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D<= br> Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

--=_alternative 006AD5E465257CC3_=-- From nobody Wed Apr 23 18:46:56 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C4A1A02D3 for ; Wed, 23 Apr 2014 18:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqCd1amTqDsx for ; Wed, 23 Apr 2014 18:46:51 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4BC1A02D2 for ; Wed, 23 Apr 2014 18:46:49 -0700 (PDT) Received: from WeiGengyuPC (unknown [10.103.241.241]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 9BE1F19F383; Thu, 24 Apr 2014 09:46:40 +0800 (HKT) Message-ID: <9B08076D2BF34B1F8D7BED718A2EF49E@WeiGengyuPC> From: "weigengyu" To: "Abhijan Bhattacharyya" References: In-Reply-To: Date: Thu, 24 Apr 2014 09:46:39 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007B_01CF5FA2.176F1410" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Archived-At: http://mailarchive.ietf.org/arch/msg/core/ji0KAElBPbOSnPcQxCNZlgGyjJM Cc: core@ietf.org Subject: Re: [core] Handling tokens for No-response X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 01:46:55 -0000 这是一封 MIME 格式的多方邮件。 ------=_NextPart_000_007B_01CF5FA2.176F1410 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Abhijan=EF=BC=8C I know your draft proposed No-Respose, and did not say anything about = Zero Length Token.=20 My comments are about the following email in which Zero length token may = be adviced for No-response.=20 { From: Rahman, Akbar=20 Sent: Thursday, April 17, 2014 2:57 AM To: Dijk, Esko=20 Cc: Abhijan Bhattacharyya ; core@ietf.org=20 Subject: Re: [core] Handling tokens for No-response Hi Esko, > 1. When sending a unicast CON request and no response is given or the = client asks for No-Response, I would think that the Token can be re-used = after EXCHANGE_LIFETIME. Is that right? Yes, that would be my interpretation as well. =20 > Suppose we would advise to use a zero-length (default) Token for such = requests =E2=80=93 wouldn=E2=80=99t there be the same problem of Token = re-use? I.e. I can only re-use the 0 Token after EXCHANGE_LIFETIME time = has passed. Yes, good point! /Akbar } Regards,=20 =20 From: Abhijan Bhattacharyya=20 Sent: Thursday, April 24, 2014 3:26 AM To: weigengyu=20 Cc: Carsten Bormann ; core@ietf.org ; Dijk, Esko ; Likepeng=20 Subject: Re: Re: [core] Handling tokens for No-response Hi Gengyu, >One alternative of No-Response trys to give Zero length token one >"special=20 >semantics". Your comment is not really clear to me. I am not sure if I understand = what you mean by 'one alternative of No-response'. =20 The present draft on No-response does not mention anything about token = and that is why we are carrying out this discussion to bridge the gap. = Use of zero length token came up as part of the discussion. However, the = confusions have already been cleared by Carsten and Esko. No-response is = not at all trying to give any special semantics to anything.=20 Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ -----"weigengyu" wrote: ----- >To: "Carsten Bormann" >From: "weigengyu" >Date: 04/23/2014 07:16PM >Cc: "Dijk, Esko" , "Likepeng" >, "Abhijan Bhattacharyya" >, >Subject: Re: [core] Handling tokens for No-response > >>> As the sematics of Zero length token is defined in CoAP -18, >>Zero length tokens do not have any special semantics as defined in >the CoAP=20 >>specification. > >CoAP -18 defines the Zero length token the same as other tokens, >so Zero length token has sematics already. >No words say "any special semantics". > >One alternative of No-Response trys to give Zero length token one >"special=20 >semantics". >By current CoAP -18, using Zero length token as No-response option >will not=20 >get effect. > >Regards, > >Gengyu >Network Techonology Center >School of Computer >Beijing University of Posts and Telecommunications. > >-----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6-----=20 >From: weigengyu >Sent: Wednesday, April 23, 2014 9:19 PM >To: Carsten Bormann >Cc: Dijk, Esko ; Likepeng ; Abhijan Bhattacharyya ; core@ietf.org >Subject: Re: [core] Handling tokens for No-response > >Hi, > >I think the following sentence need being clarified: > >In CoAP -18 page 34, >"The client SHOULD generate tokens in such a way that tokens >currently >in use for a given source/destination endpoint pair are unique. >(Note that a client implementation can use the same token for any >request if it uses a different endpoint each time, e.g. a different >source port number) An empty token value is appropriate e.g. when >no other tokens are in use to a destination, or when requests are >made serially per destination and receive piggy-backed responses. >There are however multiple possible implementation strategies to >fulfill this. " > >By this, zero length token is a token, it can be used the same way as >other >tokens. >If the request is with zero token, the response should adopt the zero >token >too. > >Angthing wrong? > >Regards, > >Network Technology Center >School of Computer >Beijing University of Posts and Telecommunications. > > >-----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6-----=20 >From: Carsten Bormann >Sent: Wednesday, April 23, 2014 4:22 PM >To: weigengyu >Cc: Dijk, Esko ; Likepeng ; Abhijan Bhattacharyya ; core@ietf.org >Subject: Re: [core] Handling tokens for No-response > >A number of clarifications about =E2=80=9Cempty tokens": > >> If the token length is ZERO, then there is no token. So the token >is=20 >> empty. > >If the token length is zero, there still is a token, it is just of >length >zero >There is nothing special about this token value; I have no idea why >this is >discussed as if it were. > >> If the token length is one, for example, the value of the token >could be=20 >> from 0 to 255. > >The token is an opaque byte string (for a one-byte token, the value >of the >first and only byte would indeed be between 0 and 255). > >> In this case, when the value of token is 0, the token is not >empty. > >Indeed, what you mean seems to be just another token value, a byte >string of >length 1 with a zero byte. > >> As the sematics of Zero length token is defined in CoAP -18, > >Zero length tokens do not have any special semantics as defined in >the CoAP >specification. > >> when No-Response is identified by Zeron length token, it can not >get an=20 >> effect. > >Non sequitur. > >The discussion of how to choose token values, including when a >previously >used token can be used again, is quite relevant for a client >implementation >(and I would expect the LWIG document to gain some substance here in >the >next revision), but there is nothing special about the zero-length >token >value in this discussion. > >Gr=C3=BC=C3=9Fe, Carsten=20 > >=20 =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain=20 confidential or privileged information. If you are=20 not the intended recipient, any dissemination, use,=20 review, distribution, printing or copying of the=20 information contained in this e-mail message=20 and/or attachments to it are strictly prohibited. If=20 you have received this communication in error,=20 please notify us by reply e-mail or telephone and=20 immediately and permanently delete the message=20 and any attachments. Thank you ------=_NextPart_000_007B_01CF5FA2.176F1410 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Hi Abhijan=EF=BC=8C
 
I know your draft proposed = No-Respose, and did=20 not say anything about Zero Length Token.
My comments are about the following = email in=20 which Zero length token may be adviced for No-response.
 
{
From:=20 Rahman, = Akbar =
Sent: Thursday,=20 April 17, 2014 2:57 AM
To: = Dijk, Esko
Cc: = Abhijan = Bhattacharyya ; core@ietf.org
Subject: Re:=20 [core] Handling tokens for No-response
 

Hi Esko,

> 1. When = sending a=20 unicast CON request and no response is given or the client asks for = No-Response,=20 I would think that the Token can be re-used after EXCHANGE_LIFETIME. Is = that=20 right?

Yes, that would be my interpretation as=20 well.

 

> Suppose = we would=20 advise to use a zero-length (default) Token for such requests =E2=80=93 = wouldn=E2=80=99t there=20 be the same problem of Token re-use? I.e. I can only re-use the 0 Token = after=20 EXCHANGE_LIFETIME time has passed.

Yes, good = point!

 

/Akbar

}
 
 
Regards,
 
 
 
 
From: Abhijan Bhattacharyya =
Sent: Thursday, April 24, 2014 3:26 AM
Subject: Re: Re: [core] Handling tokens for=20 No-response
 
Hi Gengyu,
>One alternative of No-Response trys to give Zero length token=20 one
>"special
>semantics".
 
Your comment is not really clear to me. I am not sure if I = understand=20 what you mean by 'one alternative of No-response'. 
The present draft on No-response does not mention anything about = token and=20 that is why we are carrying out this discussion to bridge the gap. Use = of zero=20 length token came up as part of the discussion. However, the confusions = have=20 already been cleared by Carsten and Esko. No-response is not at all = trying to=20 give any special semantics to anything.


Regards
Abhijan=20 Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, = Kolkata,=20 India
Tata Consultancy Services Limited
Mailto: abhijan.bhattacharyya@tcs.c= om
Website:=20 http://www.tcs.com
___________________= _________________________
Experience=20 certainty. IT Services
Business=20 Solutions
Consulting
____________________________________________

-----"weigengyu" <weigengyu@bupt.edu.cn> wrote:=20 -----

>To: "Carsten Bormann" = <cabo@tzi.org>
>From:=20 "weigengyu" <weigengyu@bupt.edu.cn>
>Date: 04/23/2014=20 07:16PM
>Cc: "Dijk, Esko" <esko.dijk@philips.com>,=20 "Likepeng"
><likepeng@huawei.com>, "Abhijan=20 Bhattacharyya"
><abhijan.bhattacharyya@tcs.com>,=20 <core@ietf.org>
>Subject: Re: [core] Handling tokens for=20 No-response
>
>>> As the sematics of Zero length token = is=20 defined in CoAP -18,
>>Zero length tokens do not have any = special=20 semantics as defined in
>the CoAP=20
>>specification.
>
>CoAP -18 defines the Zero = length token=20 the same as other tokens,
>so Zero length token has sematics=20 already.
>No words say "any special semantics".
>
>One = alternative of No-Response trys to give Zero length token = one
>"special=20
>semantics".
>By current CoAP -18, using Zero length token = as=20 No-response option
>will not
>get=20 effect.
>
>Regards,
>
>Gengyu
>Network = Techonology=20 Center
>School of Computer
>Beijing University of Posts and=20 Telecommunications.
>
>-----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB= =B6-----
>From:=20 weigengyu
>Sent: Wednesday, April 23, 2014 9:19 PM
>To: = Carsten=20 Bormann
>Cc: Dijk, Esko ; Likepeng ; Abhijan Bhattacharyya ;=20 core@ietf.org
>Subject: Re: [core] Handling tokens for=20 No-response
>
>Hi,
>
>I think the following = sentence=20 need being clarified:
>
>In CoAP -18 page 34,
>"The = client=20 SHOULD generate tokens in such a way that = tokens
>currently
>in use=20 for a given source/destination endpoint pair are unique.
>(Note = that a=20 client implementation can use the same token for any
>request if = it uses a=20 different endpoint each time, e.g. a different
>source port = number) An=20 empty token value is appropriate e.g. when
>no other tokens are in = use to=20 a destination, or when requests are
>made serially per destination = and=20 receive piggy-backed responses.
>There are however multiple = possible=20 implementation strategies to
>fulfill this. "
>
>By = this, zero=20 length token is a token, it can be used the same way=20 as
>other
>tokens.
>If the request is with zero token, = the=20 response should adopt the = zero
>token
>too.
>
>Angthing=20 wrong?
>
>Regards,
>
>Network Technology=20 Center
>School of Computer
>Beijing University of Posts and=20 Telecommunications.
>
>
>-----=E5=8E=9F=E5=A7=8B=E9=82=AE= =E4=BB=B6-----
>From: Carsten=20 Bormann
>Sent: Wednesday, April 23, 2014 4:22 PM
>To:=20 weigengyu
>Cc: Dijk, Esko ; Likepeng ; Abhijan Bhattacharyya ;=20 core@ietf.org
>Subject: Re: [core] Handling tokens for=20 No-response
>
>A number of clarifications about = =E2=80=9Cempty=20 tokens":
>
>> If the token length is ZERO, then there is = no=20 token. So the token
>is
>> empty.
>
>If the = token=20 length is zero, there still is a token, it is just=20 of
>length
>zero
>There is nothing special about this = token=20 value; I have no idea why
>this is
>discussed as if it=20 were.
>
>> If the token length is one, for example, the = value of=20 the token
>could be
>> from 0 to 255.
>
>The = token=20 is an opaque byte string (for a one-byte token, the value
>of=20 the
>first and only byte would indeed be between 0 and=20 255).
>
>> In this case, when the value of token is 0, = the token=20 is not
>empty.
>
>Indeed, what you mean seems to be = just=20 another token value, a byte
>string of
>length 1 with a zero = byte.
>
>> As the sematics of Zero length token is = defined in=20 CoAP -18,
>
>Zero length tokens do not have any special = semantics as=20 defined in
>the CoAP
>specification.
>
>> = when=20 No-Response is identified by Zeron length token, it can not
>get = an=20
>> effect.
>
>Non sequitur.
>
>The = discussion=20 of how to choose token values, including when = a
>previously
>used=20 token can be used again, is quite relevant for a=20 client
>implementation
>(and I would expect the LWIG = document to=20 gain some substance here in
>the
>next revision), but there = is=20 nothing special about the zero-length
>token
>value in this=20 discussion.
>
>Gr=C3=BC=C3=9Fe, Carsten =
>
>=20

=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
Notice: = The information contained in this=20 e-mail
message and/or attachments to it may contain
confidential = or=20 privileged information. If you are
not the intended recipient, any=20 dissemination, use,
review, distribution, printing or copying of the =
information contained in this e-mail message
and/or attachments = to it=20 are strictly prohibited. If
you have received this communication in = error,=20
please notify us by reply e-mail or telephone and
immediately = and=20 permanently delete the message
and any attachments. Thank=20 you

------=_NextPart_000_007B_01CF5FA2.176F1410-- From nobody Wed Apr 23 18:49:23 2014 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C861A02CF for ; Wed, 23 Apr 2014 18:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hsEnNIIwYm2 for ; Wed, 23 Apr 2014 18:49:18 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id C062A1A02D2 for ; Wed, 23 Apr 2014 18:49:17 -0700 (PDT) Received: from WeiGengyuPC (unknown [10.103.241.241]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 60D3C19F36A; Thu, 24 Apr 2014 09:49:11 +0800 (HKT) Message-ID: <45C3003C9D314E3793F4EEA2C71B1FC6@WeiGengyuPC> From: "weigengyu" To: "Abhijan Bhattacharyya" References: <9B08076D2BF34B1F8D7BED718A2EF49E@WeiGengyuPC> In-Reply-To: <9B08076D2BF34B1F8D7BED718A2EF49E@WeiGengyuPC> Date: Thu, 24 Apr 2014 09:49:10 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01CF5FA2.714A2920" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Archived-At: http://mailarchive.ietf.org/arch/msg/core/VvtEvncZVV0vTcmjR6oZPeOT3Ls Cc: core@ietf.org Subject: Re: [core] Handling tokens for No-response X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 01:49:21 -0000 这是一封 MIME 格式的多方邮件。 ------=_NextPart_000_0010_01CF5FA2.714A2920 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Abhijan=EF=BC=8C I know your draft proposed No-Respose, and did not say anything about = Zero Length Token.=20 My comments are about the following email in which Zero length token may = be adviced for No-response.=20 { From: Rahman, Akbar=20 Sent: Thursday, April 17, 2014 2:57 AM To: Dijk, Esko=20 Cc: Abhijan Bhattacharyya ; core@ietf.org=20 Subject: Re: [core] Handling tokens for No-response Hi Esko, > 1. When sending a unicast CON request and no response is given or the = client asks for No-Response, I would think that the Token can be re-used = after EXCHANGE_LIFETIME. Is that right? Yes, that would be my interpretation as well. =20 > Suppose we would advise to use a zero-length (default) Token for such = requests =E2=80=93 wouldn=E2=80=99t there be the same problem of Token = re-use? I.e. I can only re-use the 0 Token after EXCHANGE_LIFETIME time = has passed. Yes, good point! /Akbar } Regards,=20 Gengyu=20 Network Technology Center School of Computer Beijing Univerisity of Posts and Telecommunications.=20 =20 From: Abhijan Bhattacharyya=20 Sent: Thursday, April 24, 2014 3:26 AM To: weigengyu=20 Cc: Carsten Bormann ; core@ietf.org ; Dijk, Esko ; Likepeng=20 Subject: Re: Re: [core] Handling tokens for No-response Hi Gengyu, >One alternative of No-Response trys to give Zero length token one >"special=20 >semantics". Your comment is not really clear to me. I am not sure if I understand = what you mean by 'one alternative of No-response'. =20 The present draft on No-response does not mention anything about token = and that is why we are carrying out this discussion to bridge the gap. = Use of zero length token came up as part of the discussion. However, the = confusions have already been cleared by Carsten and Esko. No-response is = not at all trying to give any special semantics to anything.=20 Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Limited Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ -----"weigengyu" wrote: ----- >To: "Carsten Bormann" >From: "weigengyu" >Date: 04/23/2014 07:16PM >Cc: "Dijk, Esko" , "Likepeng" >, "Abhijan Bhattacharyya" >, >Subject: Re: [core] Handling tokens for No-response > >>> As the sematics of Zero length token is defined in CoAP -18, >>Zero length tokens do not have any special semantics as defined in >the CoAP=20 >>specification. > >CoAP -18 defines the Zero length token the same as other tokens, >so Zero length token has sematics already. >No words say "any special semantics". > >One alternative of No-Response trys to give Zero length token one >"special=20 >semantics". >By current CoAP -18, using Zero length token as No-response option >will not=20 >get effect. > >Regards, > >Gengyu >Network Techonology Center >School of Computer >Beijing University of Posts and Telecommunications. > >-----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6-----=20 >From: weigengyu >Sent: Wednesday, April 23, 2014 9:19 PM >To: Carsten Bormann >Cc: Dijk, Esko ; Likepeng ; Abhijan Bhattacharyya ; core@ietf.org >Subject: Re: [core] Handling tokens for No-response > >Hi, > >I think the following sentence need being clarified: > >In CoAP -18 page 34, >"The client SHOULD generate tokens in such a way that tokens >currently >in use for a given source/destination endpoint pair are unique. >(Note that a client implementation can use the same token for any >request if it uses a different endpoint each time, e.g. a different >source port number) An empty token value is appropriate e.g. when >no other tokens are in use to a destination, or when requests are >made serially per destination and receive piggy-backed responses. >There are however multiple possible implementation strategies to >fulfill this. " > >By this, zero length token is a token, it can be used the same way as >other >tokens. >If the request is with zero token, the response should adopt the zero >token >too. > >Angthing wrong? > >Regards, > >Network Technology Center >School of Computer >Beijing University of Posts and Telecommunications. > > >-----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6-----=20 >From: Carsten Bormann >Sent: Wednesday, April 23, 2014 4:22 PM >To: weigengyu >Cc: Dijk, Esko ; Likepeng ; Abhijan Bhattacharyya ; core@ietf.org >Subject: Re: [core] Handling tokens for No-response > >A number of clarifications about =E2=80=9Cempty tokens": > >> If the token length is ZERO, then there is no token. So the token >is=20 >> empty. > >If the token length is zero, there still is a token, it is just of >length >zero >There is nothing special about this token value; I have no idea why >this is >discussed as if it were. > >> If the token length is one, for example, the value of the token >could be=20 >> from 0 to 255. > >The token is an opaque byte string (for a one-byte token, the value >of the >first and only byte would indeed be between 0 and 255). > >> In this case, when the value of token is 0, the token is not >empty. > >Indeed, what you mean seems to be just another token value, a byte >string of >length 1 with a zero byte. > >> As the sematics of Zero length token is defined in CoAP -18, > >Zero length tokens do not have any special semantics as defined in >the CoAP >specification. > >> when No-Response is identified by Zeron length token, it can not >get an=20 >> effect. > >Non sequitur. > >The discussion of how to choose token values, including when a >previously >used token can be used again, is quite relevant for a client >implementation >(and I would expect the LWIG document to gain some substance here in >the >next revision), but there is nothing special about the zero-length >token >value in this discussion. > >Gr=C3=BC=C3=9Fe, Carsten=20 > >=20 =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain=20 confidential or privileged information. If you are=20 not the intended recipient, any dissemination, use,=20 review, distribution, printing or copying of the=20 information contained in this e-mail message=20 and/or attachments to it are strictly prohibited. If=20 you have received this communication in error,=20 please notify us by reply e-mail or telephone and=20 immediately and permanently delete the message=20 and any attachments. Thank you -------------------------------------------------------------------------= ------- _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------=_NextPart_000_0010_01CF5FA2.714A2920 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Hi=20 Abhijan=EF=BC=8C
 
I know your draft proposed = No-Respose, and did=20 not say anything about Zero Length Token.
My comments are about the following = email in=20 which Zero length token may be adviced for No-response.
 
{
From:=20 Rahman, = Akbar =
Sent: Thursday,=20 April 17, 2014 2:57 AM
To: = Dijk, Esko
Cc: = Abhijan = Bhattacharyya ; core@ietf.org
Subject: Re:=20 [core] Handling tokens for No-response
 

Hi Esko,

> 1. When = sending a=20 unicast CON request and no response is given or the client asks for = No-Response,=20 I would think that the Token can be re-used after EXCHANGE_LIFETIME. Is = that=20 right?

Yes, that would be my interpretation as=20 well.

 

> Suppose = we would=20 advise to use a zero-length (default) Token for such requests =E2=80=93 = wouldn=E2=80=99t there=20 be the same problem of Token re-use? I.e. I can only re-use the 0 Token = after=20 EXCHANGE_LIFETIME time has passed.

Yes, good = point!

 

/Akbar

}
 
 
Regards,
 
Gengyu
 
Network Technology = Center
School of Computer
Beijing Univerisity of Posts and=20 Telecommunications. 
 
 
From: Abhijan Bhattacharyya =
Sent: Thursday, April 24, 2014 3:26 AM
Subject: Re: Re: [core] Handling tokens for=20 No-response
 
Hi Gengyu,
>One alternative of No-Response trys to give Zero length token=20 one
>"special
>semantics".
 
Your comment is not really clear to me. I am not sure if I = understand=20 what you mean by 'one alternative of No-response'. 
The present draft on No-response does not mention anything about = token and=20 that is why we are carrying out this discussion to bridge the gap. Use = of zero=20 length token came up as part of the discussion. However, the confusions = have=20 already been cleared by Carsten and Esko. No-response is not at all = trying to=20 give any special semantics to anything.


Regards
Abhijan=20 Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, = Kolkata,=20 India
Tata Consultancy Services Limited
Mailto: abhijan.bhattacharyya@tcs.c= om
Website:=20 http://www.tcs.com
___________________= _________________________
Experience=20 certainty. IT Services
Business=20 Solutions
Consulting
____________________________________________

-----"weigengyu" <weigengyu@bupt.edu.cn> wrote:=20 -----

>To: "Carsten Bormann" = <cabo@tzi.org>
>From:=20 "weigengyu" <weigengyu@bupt.edu.cn>
>Date: 04/23/2014=20 07:16PM
>Cc: "Dijk, Esko" <esko.dijk@philips.com>,=20 "Likepeng"
><likepeng@huawei.com>, "Abhijan=20 Bhattacharyya"
><abhijan.bhattacharyya@tcs.com>,=20 <core@ietf.org>
>Subject: Re: [core] Handling tokens for=20 No-response
>
>>> As the sematics of Zero length token = is=20 defined in CoAP -18,
>>Zero length tokens do not have any = special=20 semantics as defined in
>the CoAP=20
>>specification.
>
>CoAP -18 defines the Zero = length token=20 the same as other tokens,
>so Zero length token has sematics=20 already.
>No words say "any special semantics".
>
>One = alternative of No-Response trys to give Zero length token = one
>"special=20
>semantics".
>By current CoAP -18, using Zero length token = as=20 No-response option
>will not
>get=20 effect.
>
>Regards,
>
>Gengyu
>Network = Techonology=20 Center
>School of Computer
>Beijing University of Posts and=20 Telecommunications.
>
>-----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB= =B6-----
>From:=20 weigengyu
>Sent: Wednesday, April 23, 2014 9:19 PM
>To: = Carsten=20 Bormann
>Cc: Dijk, Esko ; Likepeng ; Abhijan Bhattacharyya ;=20 core@ietf.org
>Subject: Re: [core] Handling tokens for=20 No-response
>
>Hi,
>
>I think the following = sentence=20 need being clarified:
>
>In CoAP -18 page 34,
>"The = client=20 SHOULD generate tokens in such a way that = tokens
>currently
>in use=20 for a given source/destination endpoint pair are unique.
>(Note = that a=20 client implementation can use the same token for any
>request if = it uses a=20 different endpoint each time, e.g. a different
>source port = number) An=20 empty token value is appropriate e.g. when
>no other tokens are in = use to=20 a destination, or when requests are
>made serially per destination = and=20 receive piggy-backed responses.
>There are however multiple = possible=20 implementation strategies to
>fulfill this. "
>
>By = this, zero=20 length token is a token, it can be used the same way=20 as
>other
>tokens.
>If the request is with zero token, = the=20 response should adopt the = zero
>token
>too.
>
>Angthing=20 wrong?
>
>Regards,
>
>Network Technology=20 Center
>School of Computer
>Beijing University of Posts and=20 Telecommunications.
>
>
>-----=E5=8E=9F=E5=A7=8B=E9=82=AE= =E4=BB=B6-----
>From: Carsten=20 Bormann
>Sent: Wednesday, April 23, 2014 4:22 PM
>To:=20 weigengyu
>Cc: Dijk, Esko ; Likepeng ; Abhijan Bhattacharyya ;=20 core@ietf.org
>Subject: Re: [core] Handling tokens for=20 No-response
>
>A number of clarifications about = =E2=80=9Cempty=20 tokens":
>
>> If the token length is ZERO, then there is = no=20 token. So the token
>is
>> empty.
>
>If the = token=20 length is zero, there still is a token, it is just=20 of
>length
>zero
>There is nothing special about this = token=20 value; I have no idea why
>this is
>discussed as if it=20 were.
>
>> If the token length is one, for example, the = value of=20 the token
>could be
>> from 0 to 255.
>
>The = token=20 is an opaque byte string (for a one-byte token, the value
>of=20 the
>first and only byte would indeed be between 0 and=20 255).
>
>> In this case, when the value of token is 0, = the token=20 is not
>empty.
>
>Indeed, what you mean seems to be = just=20 another token value, a byte
>string of
>length 1 with a zero = byte.
>
>> As the sematics of Zero length token is = defined in=20 CoAP -18,
>
>Zero length tokens do not have any special = semantics as=20 defined in
>the CoAP
>specification.
>
>> = when=20 No-Response is identified by Zeron length token, it can not
>get = an=20
>> effect.
>
>Non sequitur.
>
>The = discussion=20 of how to choose token values, including when = a
>previously
>used=20 token can be used again, is quite relevant for a=20 client
>implementation
>(and I would expect the LWIG = document to=20 gain some substance here in
>the
>next revision), but there = is=20 nothing special about the zero-length
>token
>value in this=20 discussion.
>
>Gr=C3=BC=C3=9Fe, Carsten =
>
>=20

=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
Notice: = The information contained in this=20 e-mail
message and/or attachments to it may contain
confidential = or=20 privileged information. If you are
not the intended recipient, any=20 dissemination, use,
review, distribution, printing or copying of the =
information contained in this e-mail message
and/or attachments = to it=20 are strictly prohibited. If
you have received this communication in = error,=20
please notify us by reply e-mail or telephone and
immediately = and=20 permanently delete the message
and any attachments. Thank=20 you

_______________________________________________
core mailing=20 list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
------=_NextPart_000_0010_01CF5FA2.714A2920--