From esko.dijk@philips.com Fri Apr 1 01:32:30 2011 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C3683A6452 for ; Fri, 1 Apr 2011 01:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.732 X-Spam-Level: X-Spam-Status: No, score=-5.732 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZP6ZNfKll7EN for ; Fri, 1 Apr 2011 01:32:29 -0700 (PDT) Received: from TX2EHSOBE005.bigfish.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by core3.amsl.com (Postfix) with ESMTP id 76E4E3A635F for ; Fri, 1 Apr 2011 01:32:29 -0700 (PDT) Received: from mail28-tx2-R.bigfish.com (10.9.14.249) by TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id 14.1.225.8; Fri, 1 Apr 2011 08:34:09 +0000 Received: from mail28-tx2 (localhost.localdomain [127.0.0.1]) by mail28-tx2-R.bigfish.com (Postfix) with ESMTP id 4E80511B81C2; Fri, 1 Apr 2011 08:34:09 +0000 (UTC) X-SpamScore: -53 X-BigFish: VPS-53(zz15d6O9251J542N1418M1432N98dK217bLzz1202hzz1033IL8275dhz2dh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI Received: from mail28-tx2 (localhost.localdomain [127.0.0.1]) by mail28-tx2 (MessageSwitch) id 1301646849131479_25777; Fri, 1 Apr 2011 08:34:09 +0000 (UTC) Received: from TX2EHSMHS009.bigfish.com (unknown [10.9.14.254]) by mail28-tx2.bigfish.com (Postfix) with ESMTP id 12E1C4D004F; Fri, 1 Apr 2011 08:34:09 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by TX2EHSMHS009.bigfish.com (10.9.99.109) with Microsoft SMTP Server (TLS) id 14.1.225.8; Fri, 1 Apr 2011 08:34:09 +0000 Received: from nlamsexh03.connect1.local (172.16.153.24) by connect1.philips.com (172.16.156.153) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 1 Apr 2011 10:32:49 +0200 Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by nlamsexh03.connect1.local ([172.16.153.24]) with mapi; Fri, 1 Apr 2011 10:32:47 +0200 From: "Dijk, Esko" To: "Angelo P. Castellani" , Guido Moritz Date: Fri, 1 Apr 2011 10:32:41 +0200 Thread-Topic: [core] Comments on Observer-02 Thread-Index: AcvtTnWrcb3I3moBTW+uydQTu9W4gAC+CnXA Message-ID: References: <000b01cbed2b$e0608670$a1219350$@uni-rostock.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: core Subject: Re: [core] Comments on Observer-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 01 Apr 2011 08:32:30 -0000 Dear Angelo, Guido, I think that Observe-02 already defines the "obs" attribute (6.3), that sho= uld be enough to check whether a server supports it? Better to keep the Obs= erve Option elective in that case. best regards, Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Ang= elo P. Castellani Sent: Monday 28 March 2011 15:45 To: Guido Moritz Cc: core Subject: Re: [core] Comments on Observer-02 +1 Probably to solve this could be better to have Observe option critical. Best, Angelo On Mon, Mar 28, 2011 at 11:38, Guido Moritz w= rote: > Section 3.1.: If the server ignores the subscription, is there a response > code or any other indication for the client why this happened? It might b= e a > nice feature to indicate whether the server does not support observe at a= ll > or if the client might retry it again later. > > Guido > > > > _______________________________________________ > 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 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 likepeng@huawei.com Fri Apr 1 02:45:26 2011 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6378D3A6774 for ; Fri, 1 Apr 2011 02:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.267 X-Spam-Level: X-Spam-Status: No, score=-0.267 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SH98GpT049NM for ; Fri, 1 Apr 2011 02:45:25 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CB6733A63C9 for ; Fri, 1 Apr 2011 02:45:20 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIY00JTNWHNCN@szxga04-in.huawei.com> for core@ietf.org; Fri, 01 Apr 2011 17:46:35 +0800 (CST) Received: from szxeml204-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIY001ALWHNNI@szxga04-in.huawei.com> for core@ietf.org; Fri, 01 Apr 2011 17:46:35 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml204-edg.china.huawei.com (172.24.2.56) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 01 Apr 2011 17:46:27 +0800 Received: from SZXEML506-MBX.china.huawei.com ([169.254.4.200]) by SZXEML402-HUB.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Fri, 01 Apr 2011 17:46:34 +0800 Date: Fri, 01 Apr 2011 09:46:33 +0000 From: Likepeng In-reply-to: X-Originating-IP: [172.24.2.40] To: "Dijk, Esko" , "Angelo P. Castellani" , Guido Moritz Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F226FA13@szxeml506-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [core] Comments on Observer-02 Thread-index: AcvtK9YrhcWD4eUiS+G1xqcqr2jVa///vumAgAXyCYCAAJT8Ng== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <000b01cbed2b$e0608670$a1219350$@uni-rostock.de> Cc: core Subject: Re: [core] Comments on Observer-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 01 Apr 2011 09:45:26 -0000 PiBJIHRoaW5rIHRoYXQgT2JzZXJ2ZS0wMiBhbHJlYWR5IGRlZmluZXMgdGhlICJvYnMiIGF0dHJp YnV0ZSAoNi4zKSwgdGhhdCBzaG91bGQgYmUgZW5vdWdoIHRvIGNoZWNrIHdoZXRoZXIgYSBzZXJ2 ZXIgc3VwcG9ydHMgaXQ/DQoNCk5vdCByZWFsbHkuICJPYnMiIGlzIGZvciBvbmUgUmVzb3VyY2Ug VVJJLCBpdCBpcyBub3QgZm9yIHRoZSB3aG9sZSBzZXJ2ZXIuIFNvLCB3ZSBoYXZlIHR3byBkaWZm ZXJlbnQgY2FzZXM6ICgxKSB0aGUgc2VydmVyIGRvZXMgbm90IHN1cHBvcnQgdGhlIG9ic2VydmF0 aW9uIGZlYXR1cmU7ICgyKSB0aGlzIHJlc291cmNlIGNhbid0IGJlIG9ic2VydmVkLCBidXQgb3Ro ZXIgcmVzb3VyY2UgY2FuIGJlIG9ic2VydmVkIG9uIHRoaXMgc2VydmVyLiBUaGlzIGtpbmQgb2Yg aW5mb3JtYXRpb24gY2FuJ3QgYmUgaW5kaWNhdGVkIGJ5IHRoZSAib2JzIiBhdHRyaWJ1dGUuIA0K DQo+IEJldHRlciB0byBrZWVwIHRoZSBPYnNlcnZlIE9wdGlvbiBlbGVjdGl2ZSBpbiB0aGF0IGNh c2UuDQoNCklmIGl0IGlzIGVsZWN0aXZlLCB0aGVyZSBpcyBubyB3YXkgdG8gZGlmZmVyZW50aWF0 ZSB0aGUgdHdvIGNhc2VzIGFib3ZlLiBBY2NvcmRpbmcgdG8gdGhlIGN1cnJlbnQgT2JzZXJ2ZSBk cmFmdCwgaWYgdGhlIHNlcnZlciBkb2VzIG5vdCBzdXBwb3J0IE9ic2VydmUsIGl0IHR1cm5zIHRv IGEgYmFzaWMgR2V0LCBhbmQgc2VydmVyIHdpbGwgcmV0dXJuIDIuMDUgIkNvbnRlbnQiLiBCdXQg aWYgd2UgY2hhbmdlIGl0IHRvIENyaXRpY2lhbCwgdGhlIHNlcnZlciBoYXMgdG8gcmV0dXJuIDQu MDIgIkJhZCBPcHRpb24iLiBUaGVuIHRoZSBjbGllbnQgd2lsbCBzZW5kIGFub3RoZXIgR2V0IHJl cXVlc3Qgd2l0aG91dCBPYnNlcnZlIE9wdGlvbi4NCg0KU28sIGluIG15IG9waW5pb24sIENyaXRp Y2lhbCB3aWxsIGJlIGJldHRlci4NCg0KSSBqdXN0IGhhdmUgYW5vdGhlciBwcm9wb3NhbCwgZG9l cyBpdCByZWFzb25hYmxlIHRvIGRlZmluZSBhIG1lY2hhbmlzbSB0byBkaXNjb3ZlciB0aGUgc2Vy dmVyIGNhcGFiaWxpdHk/IEZvciBleGFtcGxlLCB3aGV0aGVyIG9yIG5vdCB0aGUgc2VydmVyIHN1 cHBvcnRzIEJsb2NrLCBPYnNlcnZhdGlvbiwgQ29tcHJlc3Npb24sIGV0Yy4NCg0KSW4gNmxvd3Bh biwgQ2FzdGVuIGhhcyBhIGRyYWZ0IHRvIGluZGljYXRlIHdoZXRoZXIgb3Igbm90IHRoZSBuZWln aGJvcnMgaW1wbGVtZW50IHRoZSBjb21wcmVzc2lvbjoNCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtYm9ybWFubi02bG93cGFuLWdoYy8NCg0KU28gSSBhbSB3b25kZXJpbmcg aWYgd2UgY2FuIGJvcnJvdyB0aGlzIGtpbmQgb2YgbWVjaGFuaXNtIGluIENvQVAuDQoNCktpbmQg UmVnYXJkcw0KS2VwZW5nDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQq3orz+yMs6IGNvcmUtYm91bmNlc0BpZXRmLm9yZyBbY29yZS1ib3VuY2VzQGlldGYub3JnXSC0 +rHtIERpamssIEVza28gW2Vza28uZGlqa0BwaGlsaXBzLmNvbV0NCreiy83KsbzkOiAyMDExxOo0 1MIxyNUgMTY6MzINCrW9OiBBbmdlbG8gUC4gQ2FzdGVsbGFuaTsgR3VpZG8gTW9yaXR6DQpDYzog Y29yZQ0K1vfM4jogUmU6IFtjb3JlXSBDb21tZW50cyBvbiBPYnNlcnZlci0wMg0KDQpEZWFyIEFu Z2VsbywgR3VpZG8sDQoNCkkgdGhpbmsgdGhhdCBPYnNlcnZlLTAyIGFscmVhZHkgZGVmaW5lcyB0 aGUgIm9icyIgYXR0cmlidXRlICg2LjMpLCB0aGF0IHNob3VsZCBiZSBlbm91Z2ggdG8gY2hlY2sg d2hldGhlciBhIHNlcnZlciBzdXBwb3J0cyBpdD8gQmV0dGVyIHRvIGtlZXAgdGhlIE9ic2VydmUg T3B0aW9uIGVsZWN0aXZlIGluIHRoYXQgY2FzZS4NCg0KYmVzdCByZWdhcmRzLA0KRXNrbw0KDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmdlbG8gUC4gQ2Fz dGVsbGFuaQ0KU2VudDogTW9uZGF5IDI4IE1hcmNoIDIwMTEgMTU6NDUNClRvOiBHdWlkbyBNb3Jp dHoNCkNjOiBjb3JlDQpTdWJqZWN0OiBSZTogW2NvcmVdIENvbW1lbnRzIG9uIE9ic2VydmVyLTAy DQoNCisxDQoNClByb2JhYmx5IHRvIHNvbHZlIHRoaXMgY291bGQgYmUgYmV0dGVyIHRvIGhhdmUg T2JzZXJ2ZSBvcHRpb24gY3JpdGljYWwuDQoNCkJlc3QsDQpBbmdlbG8NCg0KT24gTW9uLCBNYXIg MjgsIDIwMTEgYXQgMTE6MzgsIEd1aWRvIE1vcml0eiA8Z3VpZG8ubW9yaXR6QHVuaS1yb3N0b2Nr LmRlPiB3cm90ZToNCj4gU2VjdGlvbiAzLjEuOiBJZiB0aGUgc2VydmVyIGlnbm9yZXMgdGhlIHN1 YnNjcmlwdGlvbiwgaXMgdGhlcmUgYSByZXNwb25zZQ0KPiBjb2RlIG9yIGFueSBvdGhlciBpbmRp Y2F0aW9uIGZvciB0aGUgY2xpZW50IHdoeSB0aGlzIGhhcHBlbmVkPyBJdCBtaWdodCBiZSBhDQo+ IG5pY2UgZmVhdHVyZSB0byBpbmRpY2F0ZSB3aGV0aGVyIHRoZSBzZXJ2ZXIgZG9lcyBub3Qgc3Vw cG9ydCBvYnNlcnZlIGF0IGFsbA0KPiBvciBpZiB0aGUgY2xpZW50IG1pZ2h0IHJldHJ5IGl0IGFn YWluIGxhdGVyLg0KPg0KPiBHdWlkbw0KPg== From esko.dijk@philips.com Fri Apr 1 02:57:35 2011 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56E7C3A67B0 for ; Fri, 1 Apr 2011 02:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=-2.821, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZGyEVlOsd39 for ; Fri, 1 Apr 2011 02:57:34 -0700 (PDT) Received: from DB3EHSOBE005.bigfish.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by core3.amsl.com (Postfix) with ESMTP id 085C73A6783 for ; Fri, 1 Apr 2011 02:57:33 -0700 (PDT) Received: from mail82-db3-R.bigfish.com (10.3.81.244) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.8; Fri, 1 Apr 2011 09:59:13 +0000 Received: from mail82-db3 (localhost.localdomain [127.0.0.1]) by mail82-db3-R.bigfish.com (Postfix) with ESMTP id 7F26C13F0329; Fri, 1 Apr 2011 09:59:13 +0000 (UTC) X-SpamScore: -62 X-BigFish: VPS-62(zz15d6O9251J1be0L1441M542N1418M1432N98dK217bLzz1202hzz1033IL8275dhz2dh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI Received: from mail82-db3 (localhost.localdomain [127.0.0.1]) by mail82-db3 (MessageSwitch) id 1301651952921834_8316; Fri, 1 Apr 2011 09:59:12 +0000 (UTC) Received: from DB3EHSMHS010.bigfish.com (unknown [10.3.81.244]) by mail82-db3.bigfish.com (Postfix) with ESMTP id D56F519D0051; Fri, 1 Apr 2011 09:59:12 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by DB3EHSMHS010.bigfish.com (10.3.87.110) with Microsoft SMTP Server (TLS) id 14.1.225.8; Fri, 1 Apr 2011 09:59:08 +0000 Received: from NLHILEXH04.connect1.local (172.16.153.45) by connect1.philips.com (172.16.156.41) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 1 Apr 2011 11:59:12 +0200 Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by NLHILEXH04.connect1.local ([172.16.153.45]) with mapi; Fri, 1 Apr 2011 11:58:33 +0200 From: "Dijk, Esko" To: Likepeng , "Angelo P. Castellani" , Guido Moritz Date: Fri, 1 Apr 2011 11:58:27 +0200 Thread-Topic: [core] Comments on Observer-02 Thread-Index: AcvtK9YrhcWD4eUiS+G1xqcqr2jVa///vumAgAXyCYCAAJT8Nv//+Unw Message-ID: References: <000b01cbed2b$e0608670$a1219350$@uni-rostock.de> <34966E97BE8AD64EAE9D3D6E4DEE36F226FA13@szxeml506-mbx.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F226FA13@szxeml506-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: core Subject: Re: [core] Comments on Observer-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 01 Apr 2011 09:57:35 -0000 RGVhciBLZXBlbmcsDQoNCnlvdSdyZSByaWdodCB0aGF0IHRoZXJlIGlzIG5vIHdheSB0byBjaGVj ayBjdXJyZW50bHkgd2hldGhlciB0aGUgc2VydmVyIGludHJpbnNpY2FsbHkgc3VwcG9ydHMgb2Jz ZXJ2YXRpb24uIE15IGN1cnJlbnQgdGhpbmtpbmcgaXMgdGhhdCBmb3IgYSBjbGllbnQsIGludGVy ZXN0ZWQgdG8gb2JzZXJ2ZSBhIHNwZWNpZmljIHJlc291cmNlLCB0aGlzIG1heSBub3QgYmUgcmVs ZXZhbnQgLSB0aGUgY2xpZW50IG9ubHkgbWF5IG5lZWQgdG8ga25vdyB3aGV0aGVyIHRoZSByZXNv dXJjZSBvZiBpbnRlcmVzdCBpcyBvYnNlcnZhYmxlIG9yIG5vdC4NCg0KSWYgcG9zc2libGUgY291 bGQgeW91IHNoYXJlIGEgdXNlIGNhc2Ugd2hlcmUgdGhlIGNsaWVudCBuZWVkcyB0byBrbm93IHRo YXQgYSBzZXJ2ZXIgc3VwcG9ydHMgb2JzZXJ2YXRpb24/DQoNClRoYW5rcw0KRXNrbw0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTGlrZXBlbmcgW21haWx0bzpsaWtlcGVuZ0Bo dWF3ZWkuY29tXQ0KU2VudDogRnJpZGF5IDEgQXByaWwgMjAxMSAxMTo0Nw0KVG86IERpamssIEVz a287IEFuZ2VsbyBQLiBDYXN0ZWxsYW5pOyBHdWlkbyBNb3JpdHoNCkNjOiBjb3JlDQpTdWJqZWN0 OiBSZTogW2NvcmVdIENvbW1lbnRzIG9uIE9ic2VydmVyLTAyDQoNCj4gSSB0aGluayB0aGF0IE9i c2VydmUtMDIgYWxyZWFkeSBkZWZpbmVzIHRoZSAib2JzIiBhdHRyaWJ1dGUgKDYuMyksIHRoYXQg c2hvdWxkIGJlIGVub3VnaCB0byBjaGVjayB3aGV0aGVyIGEgc2VydmVyIHN1cHBvcnRzIGl0Pw0K DQpOb3QgcmVhbGx5LiAiT2JzIiBpcyBmb3Igb25lIFJlc291cmNlIFVSSSwgaXQgaXMgbm90IGZv ciB0aGUgd2hvbGUgc2VydmVyLiBTbywgd2UgaGF2ZSB0d28gZGlmZmVyZW50IGNhc2VzOiAoMSkg dGhlIHNlcnZlciBkb2VzIG5vdCBzdXBwb3J0IHRoZSBvYnNlcnZhdGlvbiBmZWF0dXJlOyAoMikg dGhpcyByZXNvdXJjZSBjYW4ndCBiZSBvYnNlcnZlZCwgYnV0IG90aGVyIHJlc291cmNlIGNhbiBi ZSBvYnNlcnZlZCBvbiB0aGlzIHNlcnZlci4gVGhpcyBraW5kIG9mIGluZm9ybWF0aW9uIGNhbid0 IGJlIGluZGljYXRlZCBieSB0aGUgIm9icyIgYXR0cmlidXRlLg0KDQo+IEJldHRlciB0byBrZWVw IHRoZSBPYnNlcnZlIE9wdGlvbiBlbGVjdGl2ZSBpbiB0aGF0IGNhc2UuDQoNCklmIGl0IGlzIGVs ZWN0aXZlLCB0aGVyZSBpcyBubyB3YXkgdG8gZGlmZmVyZW50aWF0ZSB0aGUgdHdvIGNhc2VzIGFi b3ZlLiBBY2NvcmRpbmcgdG8gdGhlIGN1cnJlbnQgT2JzZXJ2ZSBkcmFmdCwgaWYgdGhlIHNlcnZl ciBkb2VzIG5vdCBzdXBwb3J0IE9ic2VydmUsIGl0IHR1cm5zIHRvIGEgYmFzaWMgR2V0LCBhbmQg c2VydmVyIHdpbGwgcmV0dXJuIDIuMDUgIkNvbnRlbnQiLiBCdXQgaWYgd2UgY2hhbmdlIGl0IHRv IENyaXRpY2lhbCwgdGhlIHNlcnZlciBoYXMgdG8gcmV0dXJuIDQuMDIgIkJhZCBPcHRpb24iLiBU aGVuIHRoZSBjbGllbnQgd2lsbCBzZW5kIGFub3RoZXIgR2V0IHJlcXVlc3Qgd2l0aG91dCBPYnNl cnZlIE9wdGlvbi4NCg0KU28sIGluIG15IG9waW5pb24sIENyaXRpY2lhbCB3aWxsIGJlIGJldHRl ci4NCg0KSSBqdXN0IGhhdmUgYW5vdGhlciBwcm9wb3NhbCwgZG9lcyBpdCByZWFzb25hYmxlIHRv IGRlZmluZSBhIG1lY2hhbmlzbSB0byBkaXNjb3ZlciB0aGUgc2VydmVyIGNhcGFiaWxpdHk/IEZv ciBleGFtcGxlLCB3aGV0aGVyIG9yIG5vdCB0aGUgc2VydmVyIHN1cHBvcnRzIEJsb2NrLCBPYnNl cnZhdGlvbiwgQ29tcHJlc3Npb24sIGV0Yy4NCg0KSW4gNmxvd3BhbiwgQ2FzdGVuIGhhcyBhIGRy YWZ0IHRvIGluZGljYXRlIHdoZXRoZXIgb3Igbm90IHRoZSBuZWlnaGJvcnMgaW1wbGVtZW50IHRo ZSBjb21wcmVzc2lvbjoNCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYm9y bWFubi02bG93cGFuLWdoYy8NCg0KU28gSSBhbSB3b25kZXJpbmcgaWYgd2UgY2FuIGJvcnJvdyB0 aGlzIGtpbmQgb2YgbWVjaGFuaXNtIGluIENvQVAuDQoNCktpbmQgUmVnYXJkcw0KS2VwZW5nDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IGNvcmUtYm91 bmNlc0BpZXRmLm9yZyBbY29yZS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIERpamssIEVza28gW2Vz a28uZGlqa0BwaGlsaXBzLmNvbV0NCreiy83KsbzkOiAyMDExxOo01MIxyNUgMTY6MzINCrW9OiBB bmdlbG8gUC4gQ2FzdGVsbGFuaTsgR3VpZG8gTW9yaXR6DQpDYzogY29yZQ0K1vfM4jogUmU6IFtj b3JlXSBDb21tZW50cyBvbiBPYnNlcnZlci0wMg0KDQpEZWFyIEFuZ2VsbywgR3VpZG8sDQoNCkkg dGhpbmsgdGhhdCBPYnNlcnZlLTAyIGFscmVhZHkgZGVmaW5lcyB0aGUgIm9icyIgYXR0cmlidXRl ICg2LjMpLCB0aGF0IHNob3VsZCBiZSBlbm91Z2ggdG8gY2hlY2sgd2hldGhlciBhIHNlcnZlciBz dXBwb3J0cyBpdD8gQmV0dGVyIHRvIGtlZXAgdGhlIE9ic2VydmUgT3B0aW9uIGVsZWN0aXZlIGlu IHRoYXQgY2FzZS4NCg0KYmVzdCByZWdhcmRzLA0KRXNrbw0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjb3JlLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmdlbG8gUC4gQ2FzdGVsbGFuaQ0KU2VudDogTW9u ZGF5IDI4IE1hcmNoIDIwMTEgMTU6NDUNClRvOiBHdWlkbyBNb3JpdHoNCkNjOiBjb3JlDQpTdWJq ZWN0OiBSZTogW2NvcmVdIENvbW1lbnRzIG9uIE9ic2VydmVyLTAyDQoNCisxDQoNClByb2JhYmx5 IHRvIHNvbHZlIHRoaXMgY291bGQgYmUgYmV0dGVyIHRvIGhhdmUgT2JzZXJ2ZSBvcHRpb24gY3Jp dGljYWwuDQoNCkJlc3QsDQpBbmdlbG8NCg0KT24gTW9uLCBNYXIgMjgsIDIwMTEgYXQgMTE6Mzgs IEd1aWRvIE1vcml0eiA8Z3VpZG8ubW9yaXR6QHVuaS1yb3N0b2NrLmRlPiB3cm90ZToNCj4gU2Vj dGlvbiAzLjEuOiBJZiB0aGUgc2VydmVyIGlnbm9yZXMgdGhlIHN1YnNjcmlwdGlvbiwgaXMgdGhl cmUgYSByZXNwb25zZQ0KPiBjb2RlIG9yIGFueSBvdGhlciBpbmRpY2F0aW9uIGZvciB0aGUgY2xp ZW50IHdoeSB0aGlzIGhhcHBlbmVkPyBJdCBtaWdodCBiZSBhDQo+IG5pY2UgZmVhdHVyZSB0byBp bmRpY2F0ZSB3aGV0aGVyIHRoZSBzZXJ2ZXIgZG9lcyBub3Qgc3VwcG9ydCBvYnNlcnZlIGF0IGFs bA0KPiBvciBpZiB0aGUgY2xpZW50IG1pZ2h0IHJldHJ5IGl0IGFnYWluIGxhdGVyLg0KPg0KPiBH dWlkbw0KPg0KDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkg YmUgY29uZmlkZW50aWFsIGFuZCBsZWdhbGx5IHByb3RlY3RlZCB1bmRlciBhcHBsaWNhYmxlIGxh dy4gVGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2VlKHMpLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3Rp ZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24sIG9yIHJlcHJvZHVj dGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVu bGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29u dGFjdCB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBv ZiB0aGUgb3JpZ2luYWwgbWVzc2FnZS4NCg== From zach@sensinode.com Fri Apr 1 04:26:20 2011 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A1B53A6824 for ; Fri, 1 Apr 2011 04:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npbMBCZ+NwB2 for ; Fri, 1 Apr 2011 04:26:19 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 7AE9A3A6823 for ; Fri, 1 Apr 2011 04:26:18 -0700 (PDT) Received: from [192.168.1.44] (a91-156-92-242.elisa-laajakaista.fi [91.156.92.242]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p31BRsns009316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Apr 2011 14:27:55 +0300 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-196--919954658; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Fri, 1 Apr 2011 14:27:56 +0300 Message-Id: References: <000b01cbed2b$e0608670$a1219350$@uni-rostock.de> <34966E97BE8AD64EAE9D3D6E4DEE36F226FA13@szxeml506-mbx.china.huawei.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1082) Cc: core WG Subject: Re: [core] Comments on Observer-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 01 Apr 2011 11:26:20 -0000 --Apple-Mail-196--919954658 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 1, 2011, at 12:58 PM, Dijk, Esko wrote: > you're right that there is no way to check currently whether the = server intrinsically supports observation. My current thinking is that = for a client, interested to observe a specific resource, this may not be = relevant - the client only may need to know whether the resource of = interest is observable or not. +1, in my opinion what we have is already sufficient.=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-196--919954658 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQwMTExMjc1 NlowIwYJKoZIhvcNAQkEMRYEFJCVDeLqg5az7BHjV/cOYw64zDD8MIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAHjfOUvxv7nXoBGdNIr+nOM+788UxRkvyop4ZCitH6gGbt5c546OsTmU Wthg3+rAReffusbWz2HxIY6rcup19aa8EGz9sLf20SQoJwLMpDfLy+Pod1rcUgzXQYpaTCgrqzKG xe2/t7xW5KbBD3FCuhXKxlFFQbkP68MjxkEgrAZM4KaVGH6xVkAl5Kmc7b1iCu4JYVS5KgPDzdEo 5iWgs4tOZxdJP1RVQRQ8jZvl+h7PMhtTvBFtx1EUEA/mG0rQ2/qIwWYwJ3cJbTGBX64PN8CsOBb2 2U0BNL0jl5Q8Fbt7vy352XggHEsD8jFV9iNvTpNC6tgjZnpc1odetVkVHdoAAAAAAAA= --Apple-Mail-196--919954658-- From cabo@tzi.org Fri Apr 1 04:29:36 2011 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4323E3A681B for ; Fri, 1 Apr 2011 04:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isM1ZRh+Aztq for ; Fri, 1 Apr 2011 04:29:35 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by core3.amsl.com (Postfix) with ESMTP id 32FF63A681A for ; Fri, 1 Apr 2011 04:29:34 -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.3/8.14.3) with ESMTP id p31BVCZg009687 for ; Fri, 1 Apr 2011 13:31:12 +0200 (CEST) Received: from dhcp-9066.meeting.ietf.org (unknown [130.129.8.102]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6A58374; Fri, 1 Apr 2011 13:31:12 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Apr 2011 13:31:11 +0200 To: core WG Message-Id: <2BC829A4-FA38-4273-875A-37E100633325@tzi.org> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [core] More Options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 01 Apr 2011 11:29:36 -0000 I just had a good discussion with Kepeng about his two drafts. They introduce two options (response-mode and size) that sound useful. It is, however, hard to judge at this point whether there are usecases = that actually require them. This reminded me of draft-bormann-coap-misc: The whole point of that document is to collect information about options = some of which sound useful and about which we don't have sufficient = usecase information at this point. So we agreed that it might be a good idea to continue this process of = collecting fully fleshed out option proposals (whether focused in a = single coap-misc document or distributed over several individual = documents isn't important). This way, we -- get a better view of the landscape of proposed options, so that we = sometimes may be able to find a simpler, more general approach to more = than one of the problems. -- can discuss the design of the option between interested parties = without getting entangled in a "do we really need this" discussion each = time, -- can actually implement a couple of the options in some systems and do = interop testing so we know how well the design works, and thus -- have the options ready to be pulled out into a WG document once we do = have the deployment experience that would justify their standardization. I propose that this become the default mode of working on new options = for CoAP for the near future. Gruesse, Carsten From rgm@labs.htt-consult.com Tue Apr 5 03:42:01 2011 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B05928C0E1 for ; Tue, 5 Apr 2011 03:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5woS8P9-4Bcw for ; Tue, 5 Apr 2011 03:42:00 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id BD9E328C0F2 for ; Tue, 5 Apr 2011 03:41:59 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 3849962A32; Tue, 5 Apr 2011 10:43:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtHiENQRa5z5; Tue, 5 Apr 2011 06:43:01 -0400 (EDT) Received: from nc2400.htt-consult.com (81-226-165-23-o1034.telia.com [81.226.165.23]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id 530F362A6A; Tue, 5 Apr 2011 06:43:00 -0400 (EDT) Message-ID: <4D9AF230.6020805@labs.htt-consult.com> Date: Tue, 05 Apr 2011 12:42:56 +0200 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9 MIME-Version: 1.0 To: core@ietf.org References: <057.ca63b30ac3e3ffdf9aad52c02fa3ebc8@trac.tools.ietf.org> In-Reply-To: <057.ca63b30ac3e3ffdf9aad52c02fa3ebc8@trac.tools.ietf.org> Content-Type: multipart/alternative; boundary="------------070406050108070707000706" Subject: Re: [core] #138: DTLS Clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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, 05 Apr 2011 10:42:01 -0000 This is a multi-part message in MIME format. --------------070406050108070707000706 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I have a question about DTLS-PSK per: draft-mcgrew-tls-aes-ccm-01.txt In sec 4, PSK Based AES-CCM Cipher Suites, it states: These ciphersuites make use of the default TLS 1.2 Pseudorandom Function (PRF), which uses HMAC with the SHA-256 hash function. The PSK and PSK-DHE key exchange is performed as defined in [RFC5487]. Does DTLS-PSK also use HMAC for the PRF? And if so, where is the PRF used? If we can't dodge this, we have a major hit on both code space and processing costs. As a point of information, in HIP-DEX, I have designed the PRF to use CMAC. This is NOT simple. There are some security boundaries up have to work with to use CMAC for a PRF; I have had some guidance on this, but invite more review. If we MUST use a PRF in DTLS-PSK we should really work with the TLS wg to get something other than an HMAC/SHA-256 based PRF. But it might be that DTLS as already dealt with this, and I am just missing the pertinent references. On 03/31/2011 12:17 AM, core issue tracker wrote: > #138: DTLS Clarification > > From the Prague coap-05 presentation: > > Currently unclear if coap-05 is specifying IPSec or DTLS, and in what > modes. > > This ticket is to clarify that DTLS is the must-implement security > mechanism for CoAP. > > - SharedKey (PSK), MultiKey (PSK) and Certificate mode are related to DTLS > > - Pre-shared key mode is must implement > > - NoSec mode (thus no DTLS) may be used in combination with IPSec, L2 > encryption or cases where security really isn’t needed > > - IPSec section still needed, but to be moved and edited appropriately. > -- Robert Moskowitz Senior Technical Director ICSA Labs, an Independent Division of Verizon Business Systems W:248-968-9809 F:248-968-2824 VoIP:248-291-0713 E:robert.moskowitz@icsalabs.com There's no limit to what can be accomplished if it doesn't matter who gets the credit --------------070406050108070707000706 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit I have a question about DTLS-PSK per:

draft-mcgrew-tls-aes-ccm-01.txt

In sec 4, PSK Based AES-CCM Cipher Suites, it states:

   These ciphersuites make use of the default TLS 1.2 Pseudorandom
   Function (PRF), which uses HMAC with the SHA-256 hash function.  The
   PSK and PSK-DHE key exchange is performed as defined in [RFC5487].

Does DTLS-PSK also use HMAC for the PRF?  And if so, where is the PRF used?  If we can't dodge this, we have a major hit on both code space and processing costs.

As a point of information, in HIP-DEX, I have designed the PRF to use CMAC.  This is NOT simple.  There are some security boundaries up have to work with to use CMAC for a PRF; I have had some guidance on this, but invite more review. 

If we MUST use a PRF in DTLS-PSK we should really work with the TLS wg to get something other than an HMAC/SHA-256 based PRF.  But it might be that DTLS as already dealt with this, and I am just missing the pertinent references.


On 03/31/2011 12:17 AM, core issue tracker wrote: 
#138: DTLS Clarification

 From the Prague coap-05 presentation:

 Currently unclear if coap-05 is specifying IPSec or DTLS, and in what
 modes.

 This ticket is to clarify that DTLS is the must-implement security
 mechanism for CoAP.

 - SharedKey (PSK), MultiKey (PSK) and Certificate mode are related to DTLS

 - Pre-shared key mode is must implement

 - NoSec mode (thus no DTLS) may be used in combination with IPSec, L2
 encryption or cases where security really isn’t needed

 - IPSec section still needed, but to be moved and edited appropriately.

--
Standard Robert Moskowitz
Senior Technical Director
ICSA Labs, an Independent Division of Verizon Business Systems
W:      248-968-9809
F:      248-968-2824
VoIP:   248-291-0713
E:      robert.moskowitz@icsalabs.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--------------070406050108070707000706-- From cabo@tzi.org Tue Apr 5 04:16:10 2011 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D95F73A6927 for ; Tue, 5 Apr 2011 04:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.184 X-Spam-Level: X-Spam-Status: No, score=-106.184 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9x4d3h7hjEub for ; Tue, 5 Apr 2011 04:16:10 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by core3.amsl.com (Postfix) with ESMTP id DCDF43A6922 for ; Tue, 5 Apr 2011 04:16:09 -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.3/8.14.3) with ESMTP id p35BHgNu024771; Tue, 5 Apr 2011 13:17:42 +0200 (CEST) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6AF44D5E; Tue, 5 Apr 2011 13:17:42 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4D9AF230.6020805@labs.htt-consult.com> Date: Tue, 5 Apr 2011 13:17:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <057.ca63b30ac3e3ffdf9aad52c02fa3ebc8@trac.tools.ietf.org> <4D9AF230.6020805@labs.htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] #138: DTLS Clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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, 05 Apr 2011 11:16:10 -0000 On Apr 5, 2011, at 12:42, Robert Moskowitz wrote: > Does DTLS-PSK also use HMAC for the PRF? And if so, where is the PRF = used? If we can't dodge this, we have a major hit on both code space = and processing costs. In TLS 1.2, the ciphersuite specifies the PRF. draft-mcgrew-tls-aes-ccm-01.txt indeed specifies the default TLS 1.2 = Pseudorandom Function, which uses HMAC with SHA-256. Of course, this also means yet another ciphersuite could be specified = that is similar to TLS_PSK_WITH_AES_256_CCM_8 but uses a different PRF = that is simpler to implement on chips with AES hardware. The obvious = question is whether this can be done on a timeline that would still make = it relevant for the MTI (mandatory to implement) security scheme of = CoAP, and whether this introduction of new crypto will delay the overall = progress of CoAP. Gruesse, Carsten From rgm@labs.htt-consult.com Tue Apr 5 05:12:04 2011 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69CF33A693C for ; Tue, 5 Apr 2011 05:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8MUXGUpTsPy for ; Tue, 5 Apr 2011 05:12:03 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id AADDB3A693A for ; Tue, 5 Apr 2011 05:12:03 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id C6EE162A6E; Tue, 5 Apr 2011 12:13:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7VxdSODffva; Tue, 5 Apr 2011 08:13:06 -0400 (EDT) Received: from nc2400.htt-consult.com (81-226-165-23-o1034.telia.com [81.226.165.23]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id C65F662A6C; Tue, 5 Apr 2011 08:13:05 -0400 (EDT) Message-ID: <4D9B0750.8010408@labs.htt-consult.com> Date: Tue, 05 Apr 2011 14:13:04 +0200 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9 MIME-Version: 1.0 To: Carsten Bormann References: <057.ca63b30ac3e3ffdf9aad52c02fa3ebc8@trac.tools.ietf.org> <4D9AF230.6020805@labs.htt-consult.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core@ietf.org Subject: Re: [core] #138: DTLS Clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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, 05 Apr 2011 12:12:04 -0000 On 04/05/2011 01:17 PM, Carsten Bormann wrote: > On Apr 5, 2011, at 12:42, Robert Moskowitz wrote: > >> Does DTLS-PSK also use HMAC for the PRF? And if so, where is the PRF used? If we can't dodge this, we have a major hit on both code space and processing costs. > In TLS 1.2, the ciphersuite specifies the PRF. > > draft-mcgrew-tls-aes-ccm-01.txt indeed specifies the default TLS 1.2 Pseudorandom Function, which uses HMAC with SHA-256. > > Of course, this also means yet another ciphersuite could be specified that is similar to TLS_PSK_WITH_AES_256_CCM_8 but uses a different PRF that is simpler to implement on chips with AES hardware. The obvious question is whether this can be done on a timeline that would still make it relevant for the MTI (mandatory to implement) security scheme of CoAP, and whether this introduction of new crypto will delay the overall progress of CoAP. I will bring this up with David, as I am currently asking him other related questions. If our timeline is for Quebec City, there is time to 'add' a CMAC PRF. You want to look at all the places you do things like this and see if you are truly minimizing things or not. You point out the 'cost' of the large number library, then miss still needing HMAC and SHA-256. From esko.dijk@philips.com Wed Apr 6 07:10:37 2011 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CC1328C0D7 for ; Wed, 6 Apr 2011 07:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.677 X-Spam-Level: X-Spam-Status: No, score=-5.677 tagged_above=-999 required=5 tests=[AWL=0.921, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeDjwHCDDNsK for ; Wed, 6 Apr 2011 07:10:33 -0700 (PDT) Received: from TX2EHSOBE006.bigfish.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by core3.amsl.com (Postfix) with ESMTP id AED9E3A693B for ; Wed, 6 Apr 2011 07:10:33 -0700 (PDT) Received: from mail128-tx2-R.bigfish.com (10.9.14.249) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.8; Wed, 6 Apr 2011 14:12:17 +0000 Received: from mail128-tx2 (localhost.localdomain [127.0.0.1]) by mail128-tx2-R.bigfish.com (Postfix) with ESMTP id 6118E15F053A for ; Wed, 6 Apr 2011 14:12:17 +0000 (UTC) X-SpamScore: -13 X-BigFish: VPS-13(zz217bL15d6O9251Jzz1202hzz8275bh8275dhz2dh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI Received: from mail128-tx2 (localhost.localdomain [127.0.0.1]) by mail128-tx2 (MessageSwitch) id 130209913772575_5520; Wed, 6 Apr 2011 14:12:17 +0000 (UTC) Received: from TX2EHSMHS038.bigfish.com (unknown [10.9.14.242]) by mail128-tx2.bigfish.com (Postfix) with ESMTP id F199CBF0054 for ; Wed, 6 Apr 2011 14:12:16 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by TX2EHSMHS038.bigfish.com (10.9.99.138) with Microsoft SMTP Server (TLS) id 14.1.225.8; Wed, 6 Apr 2011 14:12:16 +0000 Received: from NLHILEXH04.connect1.local (172.16.153.45) by connect1.philips.com (172.16.156.153) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 6 Apr 2011 16:11:55 +0200 Received: from NLCLUEXM03.connect1.local ([172.16.153.29]) by NLHILEXH04.connect1.local ([172.16.153.45]) with mapi; Wed, 6 Apr 2011 16:11:54 +0200 From: "Dijk, Esko" To: "core@ietf.org" Date: Wed, 6 Apr 2011 16:11:52 +0200 Thread-Topic: Combined 4.13 response with Block Option? Thread-Index: Acv0ZJQIx8ZQBp/tTp+HmFeeM1mcAw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A337AA36B3B96E4D853E6182B2F27AE2C76D7FCBAFNLCLUEXM03con_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: [core] Combined 4.13 response with Block Option? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 14:10:37 -0000 --_000_A337AA36B3B96E4D853E6182B2F27AE2C76D7FCBAFNLCLUEXM03con_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all / authors of block-02, looking at the core-block-02 draft; a server can indicate a preferred (e.g.= smaller) block size to a client in response to a blockwise PUT (see Figure= 9). This is nice but the examples (i.e. Fig 9) show only the case that the= server was capable of processing the entire first block (of 128 bytes, wh= ich is larger than the server's preference) correctly. What about a case wh= ere the server is only willing to process smaller blocks e.g. max 64 bytes = at a time? Of course the server can respond with error code 4.13 as indica= ted in the draft. However, the client could understand 4.13 as "no resource= s at this moment to support any more block operations" and then give up. Wh= at the server maybe wants to tell is "I can process 64 byte blocks at most = at a time, if you want retry this with a block size <=3D 64". Question is: is it allowed for the server to optionally include a Block Opt= ion in a 4.13 error response, to indicate the max block size that is suppor= ted ? I assume here that, even though a PUT request was correctly received, the s= erver for some implementation reason is unwilling to process a block that l= arge in one go. best regards, Esko Dijk ________________________________ 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_A337AA36B3B96E4D853E6182B2F27AE2C76D7FCBAFNLCLUEXM03con_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all / authors of block-02,

 

looking at the core-block-02 draft; a server can ind= icate a preferred (e.g. smaller) block size to a client in response to a bl= ockwise PUT (see Figure 9). This is nice but the examples (i.e. Fig 9) show= only the case that the server was capable of processing the  entire first block (of 128 bytes, which is= larger than the server’s preference) correctly. What about a case wh= ere the server is only willing to process smaller blocks e.g. max 64 bytes = at a time?  Of course the server can respond with error code 4.13 as indicated in the draft. However, the client could = understand 4.13 as “no resources at this moment to support any more b= lock operations” and then give up. What the server maybe wants to tel= l is “I can process 64 byte blocks at most at a time, if you want retry this with a block size <=3D 64”. <= /o:p>

 

Question is: is it allowed for the server to optiona= lly include a Block Option in a 4.13 error response, to indicate the max bl= ock size that is supported ? 

 

I assume here that, even though a PUT request was co= rrectly received, the server for some implementation reason is unwilling to= process a block that large in one go.

 

best regards,

Esko Dijk


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_A337AA36B3B96E4D853E6182B2F27AE2C76D7FCBAFNLCLUEXM03con_-- From likepeng@huawei.com Wed Apr 6 18:04:54 2011 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B457E3A69A2 for ; Wed, 6 Apr 2011 18:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.268 X-Spam-Level: X-Spam-Status: No, score=-0.268 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiadbfK7CE6M for ; Wed, 6 Apr 2011 18:04:52 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 51A733A6961 for ; Wed, 6 Apr 2011 18:04:52 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJ900K6MCEQJR@szxga04-in.huawei.com> for core@ietf.org; Thu, 07 Apr 2011 09:06:26 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJ9002EBCEQYU@szxga04-in.huawei.com> for core@ietf.org; Thu, 07 Apr 2011 09:06:26 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 07 Apr 2011 09:06:21 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.27]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Thu, 07 Apr 2011 09:06:25 +0800 Date: Thu, 07 Apr 2011 01:06:23 +0000 From: Likepeng In-reply-to: X-Originating-IP: [10.70.109.110] To: "Dijk, Esko" , "core@ietf.org" Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F2280F85@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_RK1nOcsCXozSl8Hi72cOrQ)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Combined 4.13 response with Block Option? Thread-index: Acv0ZJQIx8ZQBp/tTp+HmFeeM1mcAwAWmpzw X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Subject: Re: [core] Combined 4.13 response with Block Option? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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, 07 Apr 2011 01:04:54 -0000 --Boundary_(ID_RK1nOcsCXozSl8Hi72cOrQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 PldoYXQgdGhlIHNlcnZlciBtYXliZSB3YW50cyB0byB0ZWxsIGlzIKGwSSBjYW4gcHJvY2VzcyA2 NCBieXRlIGJsb2NrcyBhdCBtb3N0IGF0IGEgdGltZSwgaWYgeW91IHdhbnQgcmV0cnkgdGhpcyB3 aXRoIGEgYmxvY2sgc2l6ZSA8PSA2NKGxLg0KSWYgdGhlIHNlcnZlciBjYW6hr3QgYWNjZXB0IDY0 IGJ5dGUsIHdoaWNoIGlzIHBhcnQgb2YgdGhlIHJlc291cmNlLCB3aGF0IGlzIHRoZSB1c2UgY2Fz ZSB0byByZWNlaXZlIGFuIGV2ZW4gc21hbGxlciBwYXJ0IG9mIHRoZSByZXNvdXJjZT8NCg0KPlF1 ZXN0aW9uIGlzOiBpcyBpdCBhbGxvd2VkIGZvciB0aGUgc2VydmVyIHRvIG9wdGlvbmFsbHkgaW5j bHVkZSBhIEJsb2NrIE9wdGlvbiBpbiBhIDQuMTMgZXJyb3IgcmVzcG9uc2UsIHRvIGluZGljYXRl IHRoZSBtYXggYmxvY2sgc2l6ZSB0aGF0IGlzIHN1cHBvcnRlZCA/DQpDdXJyZW50bHkgdGhlIGRy YWZ0IHN1cHBvcnRzIHRoZSBpbmRpY2F0aW9uIG9mIHByZWZlcnJlZCBibG9jayBzaXplIGluIHRo ZSByZXNwb25zZSwgd2hpY2ggc2VlbXMgdG8gYmUgZW5vdWdoLg0KDQpLaW5kIFJlZ2FyZHMNCktl cGVuZw0Kt6K8/sjLOiBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjb3JlLWJvdW5jZXNA aWV0Zi5vcmddILT6se0gRGlqaywgRXNrbw0Kt6LLzcqxvOQ6IDIwMTHE6jTUwjbI1SAyMjoxMg0K ytW8/sjLOiBjb3JlQGlldGYub3JnDQrW98ziOiBbY29yZV0gQ29tYmluZWQgNC4xMyByZXNwb25z ZSB3aXRoIEJsb2NrIE9wdGlvbj8NCg0KRGVhciBhbGwgLyBhdXRob3JzIG9mIGJsb2NrLTAyLA0K DQpsb29raW5nIGF0IHRoZSBjb3JlLWJsb2NrLTAyIGRyYWZ0OyBhIHNlcnZlciBjYW4gaW5kaWNh dGUgYSBwcmVmZXJyZWQgKGUuZy4gc21hbGxlcikgYmxvY2sgc2l6ZSB0byBhIGNsaWVudCBpbiBy ZXNwb25zZSB0byBhIGJsb2Nrd2lzZSBQVVQgKHNlZSBGaWd1cmUgOSkuIFRoaXMgaXMgbmljZSBi dXQgdGhlIGV4YW1wbGVzIChpLmUuIEZpZyA5KSBzaG93IG9ubHkgdGhlIGNhc2UgdGhhdCB0aGUg c2VydmVyIHdhcyBjYXBhYmxlIG9mIHByb2Nlc3NpbmcgdGhlICBlbnRpcmUgZmlyc3QgYmxvY2sg KG9mIDEyOCBieXRlcywgd2hpY2ggaXMgbGFyZ2VyIHRoYW4gdGhlIHNlcnZlcqGvcyBwcmVmZXJl bmNlKSBjb3JyZWN0bHkuIFdoYXQgYWJvdXQgYSBjYXNlIHdoZXJlIHRoZSBzZXJ2ZXIgaXMgb25s eSB3aWxsaW5nIHRvIHByb2Nlc3Mgc21hbGxlciBibG9ja3MgZS5nLiBtYXggNjQgYnl0ZXMgYXQg YSB0aW1lPyAgT2YgY291cnNlIHRoZSBzZXJ2ZXIgY2FuIHJlc3BvbmQgd2l0aCBlcnJvciBjb2Rl IDQuMTMgYXMgaW5kaWNhdGVkIGluIHRoZSBkcmFmdC4gSG93ZXZlciwgdGhlIGNsaWVudCBjb3Vs ZCB1bmRlcnN0YW5kIDQuMTMgYXMgobBubyByZXNvdXJjZXMgYXQgdGhpcyBtb21lbnQgdG8gc3Vw cG9ydCBhbnkgbW9yZSBibG9jayBvcGVyYXRpb25zobEgYW5kIHRoZW4gZ2l2ZSB1cC4gV2hhdCB0 aGUgc2VydmVyIG1heWJlIHdhbnRzIHRvIHRlbGwgaXMgobBJIGNhbiBwcm9jZXNzIDY0IGJ5dGUg YmxvY2tzIGF0IG1vc3QgYXQgYSB0aW1lLCBpZiB5b3Ugd2FudCByZXRyeSB0aGlzIHdpdGggYSBi bG9jayBzaXplIDw9IDY0obEuDQoNClF1ZXN0aW9uIGlzOiBpcyBpdCBhbGxvd2VkIGZvciB0aGUg c2VydmVyIHRvIG9wdGlvbmFsbHkgaW5jbHVkZSBhIEJsb2NrIE9wdGlvbiBpbiBhIDQuMTMgZXJy b3IgcmVzcG9uc2UsIHRvIGluZGljYXRlIHRoZSBtYXggYmxvY2sgc2l6ZSB0aGF0IGlzIHN1cHBv cnRlZCA/DQoNCkkgYXNzdW1lIGhlcmUgdGhhdCwgZXZlbiB0aG91Z2ggYSBQVVQgcmVxdWVzdCB3 YXMgY29ycmVjdGx5IHJlY2VpdmVkLCB0aGUgc2VydmVyIGZvciBzb21lIGltcGxlbWVudGF0aW9u IHJlYXNvbiBpcyB1bndpbGxpbmcgdG8gcHJvY2VzcyBhIGJsb2NrIHRoYXQgbGFyZ2UgaW4gb25l IGdvLg0KDQpiZXN0IHJlZ2FyZHMsDQpFc2tvIERpamsNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1h eSBiZSBjb25maWRlbnRpYWwgYW5kIGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxpY2FibGUg bGF3LiBUaGUgbWVzc2FnZSBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUocyku IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5v dGlmaWVkIHRoYXQgYW55IHVzZSwgZm9yd2FyZGluZywgZGlzc2VtaW5hdGlvbiwgb3IgcmVwcm9k dWN0aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUg dW5sYXdmdWwuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBj b250YWN0IHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVz IG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlLg0K --Boundary_(ID_RK1nOcsCXozSl8Hi72cOrQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

>What the server maybe wants= to tell is =A1=B0I can process 64 byte blocks at most at a time, if you wa= nt retry this with a block size <=3D 64=A1=B1.

If the server can=A1=AFt accept 64 byte, which is part of the res= ource, what is the use case to receive an even smaller part of the resource= ?

 

>Question is: is it allowed = for the server to optionally include a Block Option in a 4.13 error respons= e, to indicate the max block size that is supported ? 

Currently the draft supports the indication of preferred block si= ze in the response, which seems to be enough.

 

Kind Regards

Kepeng

=B7=A2=BC=FE=C8=CB: core-bounces@ietf.org [mailto:core-bounces@ietf.= org] =B4=FA= =B1=ED Dijk, Esko
=B7=A2= =CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C26=C8=D5 22:12
=CA=D5=BC=FE=C8=CB: core@ietf.org
=D6=F7=CC=E2: [core] Combined 4.13 response with Block Option?=

 

Dear all / authors of block-02,=

 

looking at the core-block-02 dr= aft; a server can indicate a preferred (e.g. smaller) block size to a clien= t in response to a blockwise PUT (see Figure 9). This is nice but the examp= les (i.e. Fig 9) show only the case that the server was capable of processing the  entire first block (of= 128 bytes, which is larger than the server=A1=AFs preference) correctly. W= hat about a case where the server is only willing to process smaller blocks= e.g. max 64 bytes at a time?  Of course the server can respond with error code 4.13 as indicated in the draft. However= , the client could understand 4.13 as =A1=B0no resources at this moment to = support any more block operations=A1=B1 and then give up. What the server m= aybe wants to tell is =A1=B0I can process 64 byte blocks at most at a time, if you want retry this with a block size <=3D= 64=A1=B1.

 

Question is: is it allowed for = the server to optionally include a Block Option in a 4.13 error response, t= o indicate the max block size that is supported ? 

 

I assume here that, even though= a PUT request was correctly received, the server for some implementation r= eason is unwilling to process a block that large in one go.

 

best regards,=

Esko Dijk

 

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

--Boundary_(ID_RK1nOcsCXozSl8Hi72cOrQ)-- From ekr@rtfm.com Thu Apr 7 13:06:31 2011 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F99A28C15D for ; Thu, 7 Apr 2011 13:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.949 X-Spam-Level: X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMk+xhERPm3m for ; Thu, 7 Apr 2011 13:06:30 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 7E40728C159 for ; Thu, 7 Apr 2011 13:06:30 -0700 (PDT) Received: by iye19 with SMTP id 19so3479021iye.31 for ; Thu, 07 Apr 2011 13:08:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.140.193 with SMTP id l1mr2101357icu.119.1302206895250; Thu, 07 Apr 2011 13:08:15 -0700 (PDT) Received: by 10.42.241.5 with HTTP; Thu, 7 Apr 2011 13:08:15 -0700 (PDT) In-Reply-To: <4D9B0750.8010408@labs.htt-consult.com> References: <057.ca63b30ac3e3ffdf9aad52c02fa3ebc8@trac.tools.ietf.org> <4D9AF230.6020805@labs.htt-consult.com> <4D9B0750.8010408@labs.htt-consult.com> Date: Thu, 7 Apr 2011 13:08:15 -0700 Message-ID: From: Eric Rescorla To: Robert Moskowitz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core@ietf.org Subject: Re: [core] #138: DTLS Clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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, 07 Apr 2011 20:06:31 -0000 Bob, Do you have some measurements that show that HMAC and SHA-256 are that expensive? HMAC, at least, is a very small number of lines of code. I'd like to see some measurements for SHA-256 before we get all ramped up to change PRFs. -Ekr On Tue, Apr 5, 2011 at 5:13 AM, Robert Moskowitz wrote: > On 04/05/2011 01:17 PM, Carsten Bormann wrote: >> >> On Apr 5, 2011, at 12:42, Robert Moskowitz wrote: >> >>> Does DTLS-PSK also use HMAC for the PRF? =A0And if so, where is the PRF >>> used? =A0If we can't dodge this, we have a major hit on both code space= and >>> processing costs. >> >> In TLS 1.2, the ciphersuite specifies the PRF. >> >> draft-mcgrew-tls-aes-ccm-01.txt indeed specifies the default TLS 1.2 >> Pseudorandom Function, which uses HMAC with SHA-256. >> >> Of course, this also means yet another ciphersuite could be specified th= at >> is similar to TLS_PSK_WITH_AES_256_CCM_8 but uses a different PRF that i= s >> simpler to implement on chips with AES hardware. =A0The obvious question= is >> whether this can be done on a timeline that would still make it relevant= for >> the MTI (mandatory to implement) security scheme of CoAP, and whether th= is >> introduction of new crypto will delay the overall progress of CoAP. > > I will bring this up with David, as I am currently asking him other relat= ed > questions. > > If our timeline is for Quebec City, there is time to 'add' a CMAC PRF. = =A0You > want to look at all the places you do things like this and see if you are > truly minimizing things or not. =A0You point out the 'cost' of the large > number library, then miss still needing HMAC and SHA-256. > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From robert.cragie@gmail.com Thu Apr 7 15:32:26 2011 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07EB428C182 for ; Thu, 7 Apr 2011 15:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.426 X-Spam-Level: X-Spam-Status: No, score=-1.426 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8bu9lOZvZOL for ; Thu, 7 Apr 2011 15:32:25 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 57BDF28C16E for ; Thu, 7 Apr 2011 15:32:25 -0700 (PDT) Received: by vxg33 with SMTP id 33so2803737vxg.31 for ; Thu, 07 Apr 2011 15:34:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=U5/AtFvwpDljalfp576AP8HgPMGO5qMW6gKRv0kqd1M=; b=wkMAnzkcp8a761dHtPwlODMusfsJ8wnbBaIEd1sSPCgeYVEMCPkSjOd7hDdf/3fhiN csJ0KwVZg3n2Gth5SNY2FzxtgH01aWPSgOlEQKNrEGWmdlSR0TJoiPjIl9wAquFqjnto ckk8zGAex+RYP0L1vI3ZiGemgtTHft+4pTSVE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=oC6I/aOJZV9GqAieStTmZJljqnrEqzi5ymX6WVa7j4Dj+pYBGTDNzMWkdxRz5WlTLL VSC/Ho/VjH/J/mbf19E/tKZdJzFWBR95kWAGifoFTd0ghiwTDUiZvDT0OY4v6WCgFNi9 XKO19lASE+N4i95fLnERMhaH5RjW4ccN9K8V8= MIME-Version: 1.0 Received: by 10.220.182.200 with SMTP id cd8mr441494vcb.22.1302215649752; Thu, 07 Apr 2011 15:34:09 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.220.177.130 with HTTP; Thu, 7 Apr 2011 15:34:09 -0700 (PDT) Received: by 10.220.177.130 with HTTP; Thu, 7 Apr 2011 15:34:09 -0700 (PDT) In-Reply-To: References: <057.ca63b30ac3e3ffdf9aad52c02fa3ebc8@trac.tools.ietf.org> <4D9AF230.6020805@labs.htt-consult.com> <4D9B0750.8010408@labs.htt-consult.com> Date: Thu, 7 Apr 2011 23:34:09 +0100 X-Google-Sender-Auth: ZL6jU_VDhe1N8xL5NRD2whecMmM Message-ID: From: Robert Cragie To: Eric Rescorla Content-Type: multipart/alternative; boundary=90e6ba53b1b639806004a05bb560 Cc: core@ietf.org Subject: Re: [core] #138: DTLS Clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 22:32:26 -0000 --90e6ba53b1b639806004a05bb560 Content-Type: text/plain; charset=ISO-8859-1 In my experience both SHA-256 and HMAC are not expensive. We are using them successfully on resource constrained devices using the TLS with AES-CCM cipher suites. Robert On 7 Apr 2011 21:08, "Eric Rescorla" wrote: Bob, Do you have some measurements that show that HMAC and SHA-256 are that expensive? HMAC, at least, is a very small number of lines of code. I'd like to see some measurements for SHA-256 before we get all ramped up to change PRFs. -Ekr On Tue, Apr 5, 2011 at 5:13 AM, Robert Moskowitz wrote: > On 04/05/2011... --90e6ba53b1b639806004a05bb560 Content-Type: text/html; charset=ISO-8859-1

In my experience both SHA-256 and HMAC are not expensive. We are using them successfully on resource constrained devices using the TLS with AES-CCM cipher suites.

Robert

On 7 Apr 2011 21:08, "Eric Rescorla" <ekr@rtfm.com> wrote:

Bob,

Do you have some measurements that show that HMAC and SHA-256 are that
expensive?

HMAC, at least, is a very small number of lines of code. I'd like to
see some measurements
for SHA-256 before we get all ramped up to change PRFs.

-Ekr



On Tue, Apr 5, 2011 at 5:13 AM, Robert Moskowitz
<rgm@labs.htt-consult.com> wrote:
> On 04/05/2011...

--90e6ba53b1b639806004a05bb560-- From cabo@tzi.org Thu Apr 7 20:33:00 2011 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D1823A6A38 for ; Thu, 7 Apr 2011 20:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjstIn+3R6ml for ; Thu, 7 Apr 2011 20:32:59 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by core3.amsl.com (Postfix) with ESMTP id EB93F3A6A36 for ; Thu, 7 Apr 2011 20:32:58 -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.3/8.14.3) with ESMTP id p383YY14027186; Fri, 8 Apr 2011 05:34:34 +0200 (CEST) Received: from [192.168.217.101] (p5B3E6341.dip.t-dialin.net [91.62.99.65]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 29981DBE; Fri, 8 Apr 2011 05:34:34 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Fri, 8 Apr 2011 05:34:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <99AAB914-B0BB-445B-8DCF-75B23D6A1D5E@tzi.org> References: <057.ca63b30ac3e3ffdf9aad52c02fa3ebc8@trac.tools.ietf.org> <4D9AF230.6020805@labs.htt-consult.com> <4D9B0750.8010408@labs.htt-consult.com> To: robert.cragie@gridmerge.com X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] #138: DTLS Clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 08 Apr 2011 03:33:00 -0000 On Apr 8, 2011, at 00:34, Robert Cragie wrote: > In my experience both SHA-256 and HMAC are not expensive.=20 Clearly SHA-256 (and especially HMAC) are not particularly expensive in = execution time when used as the PRF for establishing TLS connections. Still, on a highly constrained device, all other things being the same, = it would be preferable not to spend the code space if existing AES = encryption hardware (or even software) can be employed. So I do believe = it is worth exploring an AES-based PRF, *if* it can provide the same = security characteristics. Gruesse, Carsten From oscar.garcia@philips.com Fri Apr 8 00:11:19 2011 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDF213A6876 for ; Fri, 8 Apr 2011 00:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTD7CSj77k4j for ; Fri, 8 Apr 2011 00:11:18 -0700 (PDT) Received: from CH1EHSOBE005.bigfish.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by core3.amsl.com (Postfix) with ESMTP id 33F863A6889 for ; Fri, 8 Apr 2011 00:11:18 -0700 (PDT) Received: from mail112-ch1-R.bigfish.com (216.32.181.171) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.8; Fri, 8 Apr 2011 07:13:03 +0000 Received: from mail112-ch1 (localhost.localdomain [127.0.0.1]) by mail112-ch1-R.bigfish.com (Postfix) with ESMTP id 250BA1988320; Fri, 8 Apr 2011 07:13:03 +0000 (UTC) X-SpamScore: -49 X-BigFish: VPS-49(zz217bL15d6O9251J542M98dKzz1202hzz1033IL8275bh8275dh5eeePz2dh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI Received: from mail112-ch1 (localhost.localdomain [127.0.0.1]) by mail112-ch1 (MessageSwitch) id 1302246780437098_28067; Fri, 8 Apr 2011 07:13:00 +0000 (UTC) Received: from CH1EHSMHS028.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.241]) by mail112-ch1.bigfish.com (Postfix) with ESMTP id DBCEA2004C; Fri, 8 Apr 2011 07:12:59 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by CH1EHSMHS028.bigfish.com (10.43.70.28) with Microsoft SMTP Server (TLS) id 14.1.225.8; Fri, 8 Apr 2011 07:12:54 +0000 Received: from NLAMSEXH04.connect1.local (172.16.153.25) by connect1.philips.com (172.16.156.150) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 8 Apr 2011 09:12:44 +0200 Received: from NLCLUEXM03.connect1.local ([172.16.153.29]) by NLAMSEXH04.connect1.local ([172.16.153.25]) with mapi; Fri, 8 Apr 2011 09:12:45 +0200 From: "Garcia Morchon, Oscar" To: Carsten Bormann Date: Fri, 8 Apr 2011 09:12:43 +0200 Thread-Topic: [core] #138: DTLS Clarification Thread-Index: Acv1nepwBg/58uVPSfyz7zeyUzB5uQAG3gfA Message-ID: <5F6BB0D9318FCA4083FC774C9A9ECEF68AE831F9F8@NLCLUEXM03.connect1.local> References: <057.ca63b30ac3e3ffdf9aad52c02fa3ebc8@trac.tools.ietf.org> <4D9AF230.6020805@labs.htt-consult.com> <4D9B0750.8010408@labs.htt-consult.com> <99AAB914-B0BB-445B-8DCF-75B23D6A1D5E@tzi.org> In-Reply-To: <99AAB914-B0BB-445B-8DCF-75B23D6A1D5E@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org" Subject: Re: [core] #138: DTLS Clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 08 Apr 2011 07:11:20 -0000 Hey, SHA-256 is not big, but for very small devices, one might try to find something smaller. May be this document (section 4) is useful: http://csrc.nist.gov/publications/nistpubs/800-108/sp800-108.pdf regards, Oscar. -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Car= sten Bormann Sent: Friday 8 April 2011 5:34 To: robert.cragie@gridmerge.com Cc: core@ietf.org Subject: Re: [core] #138: DTLS Clarification On Apr 8, 2011, at 00:34, Robert Cragie wrote: > In my experience both SHA-256 and HMAC are not expensive. Clearly SHA-256 (and especially HMAC) are not particularly expensive in exe= cution time when used as the PRF for establishing TLS connections. Still, on a highly constrained device, all other things being the same, it = would be preferable not to spend the code space if existing AES encryption = hardware (or even software) can be employed. So I do believe it is worth ex= ploring an AES-based PRF, *if* it can provide the same security characteris= tics. Gruesse, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core 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 esko.dijk@philips.com Fri Apr 8 00:56:31 2011 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3099628C0E9 for ; Fri, 8 Apr 2011 00:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=-2.742, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6+88SxXSodA for ; Fri, 8 Apr 2011 00:56:30 -0700 (PDT) Received: from AM1EHSOBE001.bigfish.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by core3.amsl.com (Postfix) with ESMTP id 4E49F3A6A28 for ; Fri, 8 Apr 2011 00:56:29 -0700 (PDT) Received: from mail112-am1-R.bigfish.com (10.3.201.247) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.8; Fri, 8 Apr 2011 07:58:13 +0000 Received: from mail112-am1 (localhost.localdomain [127.0.0.1]) by mail112-am1-R.bigfish.com (Postfix) with ESMTP id E5F87FB00CD; Fri, 8 Apr 2011 07:58:13 +0000 (UTC) X-SpamScore: -37 X-BigFish: VPS-37(zz217bL15d6O9251J1be0Lzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI Received: from mail112-am1 (localhost.localdomain [127.0.0.1]) by mail112-am1 (MessageSwitch) id 1302249493268010_6231; Fri, 8 Apr 2011 07:58:13 +0000 (UTC) Received: from AM1EHSMHS006.bigfish.com (unknown [10.3.201.254]) by mail112-am1.bigfish.com (Postfix) with ESMTP id 3F02F53004C; Fri, 8 Apr 2011 07:58:13 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by AM1EHSMHS006.bigfish.com (10.3.207.106) with Microsoft SMTP Server (TLS) id 14.1.225.8; Fri, 8 Apr 2011 07:58:12 +0000 Received: from NLHILEXH05.connect1.local (172.16.153.71) by connect1.philips.com (172.16.156.41) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 8 Apr 2011 09:58:12 +0200 Received: from NLCLUEXM03.connect1.local ([172.16.153.29]) by NLHILEXH05.connect1.local ([172.16.153.71]) with mapi; Fri, 8 Apr 2011 09:58:12 +0200 From: "Dijk, Esko" To: Likepeng , "core@ietf.org" Date: Fri, 8 Apr 2011 09:58:08 +0200 Thread-Topic: Combined 4.13 response with Block Option? Thread-Index: Acv0ZJQIx8ZQBp/tTp+HmFeeM1mcAwAWmpzwAEAt31A= Message-ID: References: <34966E97BE8AD64EAE9D3D6E4DEE36F2280F85@SZXEML506-MBS.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F2280F85@SZXEML506-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A337AA36B3B96E4D853E6182B2F27AE2C76DA8AA80NLCLUEXM03con_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [core] Combined 4.13 response with Block Option? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 08 Apr 2011 07:56:31 -0000 --_000_A337AA36B3B96E4D853E6182B2F27AE2C76DA8AA80NLCLUEXM03con_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBLZXBlbmcsDQoNCnRoZXJlIGFyZSBwcm9iYWJseSBub3QgbWFueSB1c2UgY2FzZXMgdGhh dCB3b3VsZCByZXF1aXJlIHRoaXMgZmVhdHVyZS4gSG93ZXZlciBteSB0aGlua2luZyB3YXMgdGhh dCBiZWNhdXNlIGltcGxlbWVudGF0aW9uIG9mIHRoaXMgZmVhdHVyZSAoobByZXNwb25kIDQuMTMg d2l0aCBCbG9jayBPcHRpb26hsSkgaXMgZnVsbHkgb3B0aW9uYWwgYXQgYm90aCBjbGllbnQgYW5k IHNlcnZlciBzaWRlcywgaXQgd291bGQgbm90IGh1cnQgdG8gaW5jbHVkZSBpdCBpbiB0aGUgc3Bl YyA/DQoNCkFuZCBJIGhhdmUgYSB1c2UgY2FzZSBpbiBtaW5kOiBhIHdpcmVsZXNzIGNvbnN0cmFp bmVkIHNlcnZlciBTIHRoYXQgaXMgY29ubmVjdGVkIHZpYSBhIHNsb3cgc2VyaWFsIGxpbmsgdG8g YSBsZWdhY3kgZGV2aWNlLCBzYXkgMTIwMCBicHMgc2ltaWxhciB0byB0aGUgREFMSSBwcm90b2Nv bC4gVGhlIGZpcm13YXJlIG9mIHRoZSBsZWdhY3kgZGV2aWNlIGlzIHRvIGJlIHVwZGF0ZWQgaW4g YmxvY2tzIHZpYSBDb0FQLCB3aGVyZSBTIHJlbGF5cyB0aGUgZGF0YSB0aGVuIG9uIHRvIHRoZSBz ZXJpYWwgbGluZSB1c2luZyBhIGN1c3RvbSBwcm90b2NvbC4gTm93IGEgY2xpZW50IG1pZ2h0IGZv b2xpc2hseSBkZWNpZGUgdG8gc2VuZCBhIFBVVCByZXF1ZXN0IHRvIFMgd2l0aCBhIDEwMjQgYnl0 ZSBibG9jay4gUyBkb2VzIGhhdmUgbWVtb3J5IHRvIHRlbXBvcmFyaWx5IGJ1ZmZlciB0aGUgbGFy Z2UgMTAyNCBieXRlIGJsb2NrLCBidXQgaXQgdGFrZXMgdXAgdG9vIG11Y2ggcmVzb3VyY2VzIGZv ciBhIHRvbyBsb25nIHRpbWUuIFRvIGdldCBhIHNpbXBsZSBpbXBsZW1lbnRhdGlvbiBhbmQgZ3Vh cmFudGVlZCByZWxpYWJsZSBvcGVyYXRpb24gb2YgUyBkdXJpbmcgdGhlIGZpcm13YXJlIHVwZGF0 ZSwgUyBwcmVmZXJzIDY0IGJ5dGUgYmxvY2tzIGFuZCBkb2VzIG5vdCB3YW50IHRvIGtlZXAgbGFy Z2UgYmxvY2tzIGluIG1lbW9yeS4gIEluIHRoZSBjdXJyZW50IENvQVAtYmxvY2sgZHJhZnQsIHRo ZXJlIGlzIG5vIHdheSBmb3IgUyB0byBpbmRpY2F0ZSB0aGlzOyBjdXJyZW50bHkgaWYgSaGvbSBj b3JyZWN0IFMgY2FuIGVpdGhlciAxKSByZXNwb25kIGVycm9yIDQuMTMgb3IgMikgQUNLIHdpdGgg YSBzdWNjZXNzIGNvZGUgYWZ0ZXIgaXQgaGFzIHByb2Nlc3NlZCB0aGUgZW50aXJlIDEwMjQgYnl0 ZSBmaXJzdCBibG9jay4gKGFzIGluIEZpZyA5KQ0KDQpPZiBjb3Vyc2UgYW5vdGhlciwgZWFzaWVy LCBzb2x1dGlvbiBoZXJlIGlzIHRoYXQgYWxsIG15IENvQVAgY2xpZW50cyBhcmUgcHJlLWNvbmZp Z3VyZWQgdG8gb25seSB1c2UgNjQtYnl0ZSBibG9ja3MgaW4gdGhlIGZpcnN0IHBsYWNlLiBCdXQg aW4gYSBtdWx0aS12ZW5kb3Igc2l0dWF0aW9uLCBvbmUgY2FuIG5vdCBiZSBzdXJlIHRoYXQgdGhp cyB0eXBlIG9mIGNvbmZpZ3VyYXRpb24gaXMgcG9zc2libGUgOykNCg0KYmVzdCByZWdhcmRzLA0K RXNrbw0KDQpGcm9tOiBMaWtlcGVuZyBbbWFpbHRvOmxpa2VwZW5nQGh1YXdlaS5jb21dDQpTZW50 OiBUaHVyc2RheSA3IEFwcmlsIDIwMTEgMzowNg0KVG86IERpamssIEVza287IGNvcmVAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBDb21iaW5lZCA0LjEzIHJlc3BvbnNlIHdpdGggQmxvY2sgT3B0aW9u Pw0KDQo+V2hhdCB0aGUgc2VydmVyIG1heWJlIHdhbnRzIHRvIHRlbGwgaXMgobBJIGNhbiBwcm9j ZXNzIDY0IGJ5dGUgYmxvY2tzIGF0IG1vc3QgYXQgYSB0aW1lLCBpZiB5b3Ugd2FudCByZXRyeSB0 aGlzIHdpdGggYSBibG9jayBzaXplIDw9IDY0obEuDQpJZiB0aGUgc2VydmVyIGNhbqGvdCBhY2Nl cHQgNjQgYnl0ZSwgd2hpY2ggaXMgcGFydCBvZiB0aGUgcmVzb3VyY2UsIHdoYXQgaXMgdGhlIHVz ZSBjYXNlIHRvIHJlY2VpdmUgYW4gZXZlbiBzbWFsbGVyIHBhcnQgb2YgdGhlIHJlc291cmNlPw0K DQo+UXVlc3Rpb24gaXM6IGlzIGl0IGFsbG93ZWQgZm9yIHRoZSBzZXJ2ZXIgdG8gb3B0aW9uYWxs eSBpbmNsdWRlIGEgQmxvY2sgT3B0aW9uIGluIGEgNC4xMyBlcnJvciByZXNwb25zZSwgdG8gaW5k aWNhdGUgdGhlIG1heCBibG9jayBzaXplIHRoYXQgaXMgc3VwcG9ydGVkID8NCkN1cnJlbnRseSB0 aGUgZHJhZnQgc3VwcG9ydHMgdGhlIGluZGljYXRpb24gb2YgcHJlZmVycmVkIGJsb2NrIHNpemUg aW4gdGhlIHJlc3BvbnNlLCB3aGljaCBzZWVtcyB0byBiZSBlbm91Z2guDQoNCktpbmQgUmVnYXJk cw0KS2VwZW5nDQq3orz+yMs6IGNvcmUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNvcmUtYm91 bmNlc0BpZXRmLm9yZ10gtPqx7SBEaWprLCBFc2tvDQq3osvNyrG85DogMjAxMcTqNNTCNsjVIDIy OjEyDQrK1bz+yMs6IGNvcmVAaWV0Zi5vcmcNCtb3zOI6IFtjb3JlXSBDb21iaW5lZCA0LjEzIHJl c3BvbnNlIHdpdGggQmxvY2sgT3B0aW9uPw0KDQpEZWFyIGFsbCAvIGF1dGhvcnMgb2YgYmxvY2st MDIsDQoNCmxvb2tpbmcgYXQgdGhlIGNvcmUtYmxvY2stMDIgZHJhZnQ7IGEgc2VydmVyIGNhbiBp bmRpY2F0ZSBhIHByZWZlcnJlZCAoZS5nLiBzbWFsbGVyKSBibG9jayBzaXplIHRvIGEgY2xpZW50 IGluIHJlc3BvbnNlIHRvIGEgYmxvY2t3aXNlIFBVVCAoc2VlIEZpZ3VyZSA5KS4gVGhpcyBpcyBu aWNlIGJ1dCB0aGUgZXhhbXBsZXMgKGkuZS4gRmlnIDkpIHNob3cgb25seSB0aGUgY2FzZSB0aGF0 IHRoZSBzZXJ2ZXIgd2FzIGNhcGFibGUgb2YgcHJvY2Vzc2luZyB0aGUgIGVudGlyZSBmaXJzdCBi bG9jayAob2YgMTI4IGJ5dGVzLCB3aGljaCBpcyBsYXJnZXIgdGhhbiB0aGUgc2VydmVyoa9zIHBy ZWZlcmVuY2UpIGNvcnJlY3RseS4gV2hhdCBhYm91dCBhIGNhc2Ugd2hlcmUgdGhlIHNlcnZlciBp cyBvbmx5IHdpbGxpbmcgdG8gcHJvY2VzcyBzbWFsbGVyIGJsb2NrcyBlLmcuIG1heCA2NCBieXRl cyBhdCBhIHRpbWU/ICBPZiBjb3Vyc2UgdGhlIHNlcnZlciBjYW4gcmVzcG9uZCB3aXRoIGVycm9y IGNvZGUgNC4xMyBhcyBpbmRpY2F0ZWQgaW4gdGhlIGRyYWZ0LiBIb3dldmVyLCB0aGUgY2xpZW50 IGNvdWxkIHVuZGVyc3RhbmQgNC4xMyBhcyChsG5vIHJlc291cmNlcyBhdCB0aGlzIG1vbWVudCB0 byBzdXBwb3J0IGFueSBtb3JlIGJsb2NrIG9wZXJhdGlvbnOhsSBhbmQgdGhlbiBnaXZlIHVwLiBX aGF0IHRoZSBzZXJ2ZXIgbWF5YmUgd2FudHMgdG8gdGVsbCBpcyChsEkgY2FuIHByb2Nlc3MgNjQg Ynl0ZSBibG9ja3MgYXQgbW9zdCBhdCBhIHRpbWUsIGlmIHlvdSB3YW50IHJldHJ5IHRoaXMgd2l0 aCBhIGJsb2NrIHNpemUgPD0gNjShsS4NCg0KUXVlc3Rpb24gaXM6IGlzIGl0IGFsbG93ZWQgZm9y IHRoZSBzZXJ2ZXIgdG8gb3B0aW9uYWxseSBpbmNsdWRlIGEgQmxvY2sgT3B0aW9uIGluIGEgNC4x MyBlcnJvciByZXNwb25zZSwgdG8gaW5kaWNhdGUgdGhlIG1heCBibG9jayBzaXplIHRoYXQgaXMg c3VwcG9ydGVkID8NCg0KSSBhc3N1bWUgaGVyZSB0aGF0LCBldmVuIHRob3VnaCBhIFBVVCByZXF1 ZXN0IHdhcyBjb3JyZWN0bHkgcmVjZWl2ZWQsIHRoZSBzZXJ2ZXIgZm9yIHNvbWUgaW1wbGVtZW50 YXRpb24gcmVhc29uIGlzIHVud2lsbGluZyB0byBwcm9jZXNzIGEgYmxvY2sgdGhhdCBsYXJnZSBp biBvbmUgZ28uDQoNCmJlc3QgcmVnYXJkcywNCkVza28gRGlqaw0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3Nh Z2UgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVnYWxseSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGlj YWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3Nl ZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJl Ynkgbm90aWZpZWQgdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9uLCBvciBy ZXByb2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1h eSBiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxl YXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBj b3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQo= --_000_A337AA36B3B96E4D853E6182B2F27AE2C76DA8AA80NLCLUEXM03con_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Dear Kepeng,

 

there are probably not many use cases that woul= d require this feature. However my thinking was that because implementation= of this feature (=A1=B0respond 4.13 with Block Option=A1=B1) is fully opti= onal at both client and server sides, it would not hurt to include it in th= e spec ?

 

And I have a use case in mind: a wireless constrained server S th= at is connected via a slow serial link to a legacy device, say 1200 bps sim= ilar to the DALI protocol. The firmware of the legacy device is to be updat= ed in blocks via CoAP, where S relays the data then on to the serial line u= sing a custom protocol. Now a client might foolishly decide to send a PUT r= equest to S with a 1024 byte block. S does have memory to temporarily buffe= r the large 1024 byte block, but it takes up too much resources for a too l= ong time. To get a simple implementation and guaranteed reliable operation = of S during the firmware update, S prefers 64 byte blocks and does not want= to keep large blocks in memory.  In the current CoAP-block draft, the= re is no way for S to indicate this; currently if I=A1=AFm correct S can ei= ther 1) respond error 4.13 or 2) ACK with a success code after it has proce= ssed the entire 1024 byte first block. (as in Fig 9)

<= p class=3DMsoNormal> <= /p>

Of course another, ea= sier, solution here is that all my CoAP clients are pre-configured to only = use 64-byte blocks in the first place. But in a multi-vendor situation, one= can not be sure that this type of configuration is possible ;)<= /span>

 

best regar= ds,

Esko

 

From: Likep= eng [mailto:likepeng@huawei.com]
Sent: Thursday 7 April 2011 3:0= 6
To: Dijk, Esko; core@ietf.org
Subject: Re: Combined 4= .13 response with Block Option?

 

>What the server = maybe wants to tell is =A1=B0I can process 64 byte blocks at most at a time= , if you want retry this with a block size <=3D 64=A1=B1.

= If the server can=A1=AFt acc= ept 64 byte, which is part of the resource, what is the use case to receive= an even smaller part of the resource?

 

>Question is: is it allowed for the server to= optionally include a Block Option in a 4.13 error response, to indicate th= e max block size that is supported ? 

Currently the draft supp= orts the indication of preferred block size in the response, which seems to= be enough.

 

= Kind Regards

K= epeng

=B7=A2=BC=FE=C8=CB: core-bounces@ietf.org= [mailto:core-bounces@ietf.org] =B4=FA=B1=ED Dijk, Esko
=B7=A2=CB=CD=CA=B1=BC=E4= :<= /b> 2011=C4=EA4=D4=C26=C8=D5 22:12
=CA=D5=BC=FE=C8=CB: core@ietf.org
=D6=F7=CC=E2= : [core] Combined 4.13 response wit= h Block Option?

=  

Dear all / authors of block-02,

 

look= ing at the core-block-02 draft; a server can indicate a preferred (e.g. sma= ller) block size to a client in response to a blockwise PUT (see Figure 9).= This is nice but the examples (i.e. Fig 9) show only the case that the ser= ver was capable of processing the  entire first block (of 128 bytes, w= hich is larger than the server=A1=AFs preference) correctly. What about a c= ase where the server is only willing to process smaller blocks e.g. max 64 = bytes at a time?  Of course the server can respond with error code 4.1= 3 as indicated in the draft. However, the client could understand 4.13 as = =A1=B0no resources at this moment to support any more block operations=A1= =B1 and then give up. What the server maybe wants to tell is =A1=B0I can pr= ocess 64 byte blocks at most at a time, if you want retry this with a block= size <=3D 64=A1=B1.

 

Question is: is it allowed for the server to opt= ionally include a Block Option in a 4.13 error response, to indicate the ma= x block size that is supported ? 

=  

I assume here that, even though a= PUT request was correctly received, the server for some implementation rea= son is unwilling to process a block that large in one go.

 

best regards,

Esko Dijk

=  

The information contained in this message may be confiden= tial and legally protected under applicable law. The message is intended so= lely for the addressee(s). If you are not the intended recipient, you are h= ereby 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.

<= /html>= --_000_A337AA36B3B96E4D853E6182B2F27AE2C76DA8AA80NLCLUEXM03con_-- From tianlinyi@huawei.com Fri Apr 8 01:19:36 2011 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B23E3A6814 for ; Fri, 8 Apr 2011 01:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.494 X-Spam-Level: X-Spam-Status: No, score=-4.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AunCDMbMKY1Z for ; Fri, 8 Apr 2011 01:19:28 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id EE5443A681B for ; Fri, 8 Apr 2011 01:19:27 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJB00EBNR72XN@szxga04-in.huawei.com> for core@ietf.org; Fri, 08 Apr 2011 16:21:02 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJB001ZJR724L@szxga04-in.huawei.com> for core@ietf.org; Fri, 08 Apr 2011 16:21:02 +0800 (CST) Received: from T34932F ([10.70.109.77]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJB0088YR72GV@szxml04-in.huawei.com> for core@ietf.org; Fri, 08 Apr 2011 16:21:02 +0800 (CST) Date: Fri, 08 Apr 2011 16:21:02 +0800 From: Linyi Tian To: 'core' Message-id: <012e01cbf5c5$e5ebcf30$b1c36d90$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_yBijRGDt7Y6HICCGlyW4kg)" Content-language: zh-cn Thread-index: Acv1xeXK4j3jilEdRjuNsb0F96Galg== Subject: [core] Throughout review on Link Format draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 08 Apr 2011 08:19:37 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à²¿·ÖÓʼþ¡£ --Boundary_(ID_yBijRGDt7Y6HICCGlyW4kg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I did throughout review of this draft and provides the following comments: Convention: [S1-P2] refers to [Section 1 - Paragraph 2] [c1] refers to [comment 1 ] 1. [S1-P2] [c1] Is "constrained web server" the correct term? Should we remove "web"? "In this document we refer to the discovery of resources hosted by a constrained web server, their attributes and other resource relations as CoRE Resource Discovery." 2. [S1-P3] [c2] Add "application/link-format as defined in section 7.4" at the end of following sentence to improve the readability. The CoRE Link Format is carried as a payload and is assigned an Internet media type. 3. [S1.1-P1] [S2.2-P2] [c3] If the resource is not hosted by the server, how to indicate this info? Since the "hosts" is the default relation type, should we define "external" instead? The relation types in Link Format are used to describe the resources in sensors. It is quite different with the web environment. I reviewed the RFC5988 carefully and believe that most of the relation types can't be used by Link Format. I suggest we have a table to list the ones that may be applicable to link format. 4. [S1.3] [c4] typo in "Link" term. Change "a tarfet" to "a target". 5. [S2-P3] [c5] typo in last sentence. Add "is" after "why it.useful". Change "Unicode" to "Unicode" See section 3 of [RFC5198], which explains why it useful to represent Unicode in a single unique form. 6. [S2.1] [c6] Examples should be added to improve the readability. I also propose to use "Base URIs" to replace "Context URI" and rephrase the text as following: Section 2.1 Target and Base URIs Each link conveys one target URI as a URI-reference inside angle brackets ("<>"). The base URI (defined in [RFC3986]) conveyed in the CoRE Link Format is by default built from the scheme and authority parts of the target URI. In the absence of scheme and authority, the base URI is built from the scheme and authority parts of the target resource which returning the set of links. The CoRE link format includes one or more links, each describing a resource hosted by a server using relation type "hosts". Other relations can be expressed by including an anchor parameter (which defines the base URI) along with an explicit relation parameter. This is an important difference to the way the HTTP Link Header format is used, as it is included in the header of an HTTP response for some URI (this URI is by default the base URI). Thus the HTTP Link Header is by default relating the target URI to the URI that was requested. See Section 5 of [RFC3986] for a description of how URIs are constructed from URI references. This example shows the base URI construction. ( I didn't update the example since I believe something wrong inside). REQ: GET /.well-known/core RES: 200 OK ;ct=40;rt="index";rt="Sensor Index", -------base URI is xxxx ;rt="TemperatureC";if="sensor", ----base URI is xxxx ;ct=41;rt="LightLux";if="sensor", ---base URI is xxxx ;anchor="/sensors/temp" ;rel="describedby", ---base URI is xxxx ;anchor="/sensors/temp";rel="alternate" ---base URI is xxxx 7. [S3.1-P2] [c7] typo. Add "be" after "The resource type attribute is not meant to ...used". 8. [S4-P2] [c8]What is the default port? 9. [S4.1-P2] [c9] Typo in the following sentence. What does "They name" mean? Other resource-param values refer to the link attribute they name 10.[S1.2.3-P2] [c10] resource directory service needs to be defined. How to register the link format and how to access it per sensor basis need to be defined. 11.[S2.2-P2][S5] [c11] I believe most of the relation types are not appropriate for CoAP. For example, "alternate" is used together with "type", "media" or other attributes for special meaning. You can refer to 4.12.4.1 of http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#rel-a lternate for further details. While in the example of section 5 of Link Format, we use "alternate" to indicate the short URI which is not defined. The same issue is for "described" in the example. It is used for reference of POWER document while we use it for URI description. We'd better to have a table to list the relation types that are applicable to CoAP rather than saying that anyone can be used in section 2.2. --Boundary_(ID_yBijRGDt7Y6HICCGlyW4kg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

I did throughout review of this = draft and provides the following comments:

Convention: =

[S1-P2] refers to [Section 1 = – Paragraph 2]

[c1] refers to [comment 1 = ]

1. [S1-P2] [c1] Is = “constrained web server” the correct term? Should we remove = “web”?

“In this document we refer = to the discovery of resources hosted by a constrained web server, their = attributes and other resource relations as CoRE Resource = Discovery.”

 

2. [S1-P3] [c2] Add “application/link-format as defined in section 7.4” at the = end of following sentence to improve the readability.

  The CoRE Link Format is = carried as a payload and is assigned an Internet media type.

 

3. [S1.1-P1] = [S2.2-P2]

[c3] If the resource is not = hosted by the server, how to indicate this info? Since the “hosts” is the = default relation type, should we define “external” instead? =

The relation types in Link = Format are used to describe the resources in sensors. It is quite different with the web environment. I reviewed the RFC5988 carefully and believe that most of = the relation types can’t be used by Link Format. I suggest we have a = table to list the ones that may be applicable to link = format.

 

4. [S1.3] = [c4] typo in “Link” term. Change “a tarfet” to “a target”.

 

5. [S2-P3] [c5] typo in last = sentence. Add “is” after “why it…useful”. Change “Unicode” to “Unicode”

See section 3 of [RFC5198], = which explains why it useful to represent Unicode in a single unique form. =

 

6. [S2.1] [c6] Examples should = be added to improve the readability. I also propose to use “Base URIs” = to replace “Context URI” and rephrase the text as = following:

Section 2.1  Target and = Base URIs

Each link conveys one target URI = as a URI-reference inside angle brackets ("<>").  The = base URI (defined in [RFC3986]) conveyed in the CoRE Link Format is by default built from = the scheme and authority parts of the target URI.  In the absence of = scheme and authority, the base URI is built from the scheme and authority parts = of the target resource which returning the set of links.

The CoRE link format includes = one or more links, each describing a resource hosted by a server using relation type = “hosts”. Other relations can be expressed by including an anchor parameter (which defines the base URI) along with an explicit relation parameter. This is = an important difference to the way the HTTP Link Header format is used, as = it is included in the header of an HTTP response for some URI (this URI is by = default the base URI).  Thus the HTTP Link Header is by default relating = the target URI to the URI that was requested. See Section 5 of [RFC3986] for = a description of how URIs are constructed from URI = references.

This example shows the base URI construction. ( I didn’t update the example since I believe = something wrong inside).

REQ: GET = /.well-known/core

   RES: 200 = OK

   </sensors>;ct=3D40;rt=3D"index";rt=3D"Sensor = Index",   -------base URI is xxxx

   </sensors/temp>;rt=3D"TemperatureC";if=3D"sensor&quo= t;,  ----base URI is xxxx

   </sensors/light>;ct=3D41;rt=3D"LightLux";if=3D"senso= r", ---base URI is xxxx

   <http://www.example.com/sensors/t123>;anchor=3D"/sensors/temp&= quot;

   = ;rel=3D"describedby",   ---base URI is xxxx

   </t>;anchor=3D"/sensors/temp";rel=3D"alternate"= ---base URI is xxxx

 

7. [S3.1-P2] [c7] typo. Add “be” after “The resource type attribute is not meant = to …..used”.

 

8. [S4-P2] [c8]What is the = default port?

 

9. [S4.1-P2] [c9] Typo in the = following sentence. What does “They name” mean?

Other resource-param values = refer to the link attribute they name

 

10.[S1.2.3-P2] [c10] resource = directory service needs to be defined. How to register the link format and how to = access it per sensor basis need to be defined.

 

11.[S2.2-P2][S5] [c11] I believe = most of the relation types are not appropriate for CoAP. For example, = “alternate” is used together with “type”, “media” or other attributes for special meaning. You can refer to 4.12.4.1 of http://www.whatwg.org/specs/web-apps/current-work/mu= ltipage/links.html#rel-alternate for further details. While in the example of section 5 of Link Format, = we use “alternate” to indicate the short URI which is not defined. The same issue is for = “described” in the example. It is used for reference of POWER document while we use = it for URI description. We’d better to have a table to list the relation = types that are applicable to CoAP rather than saying that anyone can be used = in section 2.2.

--Boundary_(ID_yBijRGDt7Y6HICCGlyW4kg)-- From cabo@tzi.org Fri Apr 8 03:27:45 2011 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BA9B3A6A01 for ; Fri, 8 Apr 2011 03:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdfdnZVoJIjW for ; Fri, 8 Apr 2011 03:27:43 -0700 (PDT) Received: from davie.textdrive.com (unknown [207.7.107.107]) by core3.amsl.com (Postfix) with ESMTP id 71CAB3A69B8 for ; Fri, 8 Apr 2011 03:27:43 -0700 (PDT) Received: from [10.128.2.210] (unknown [88.128.86.155]) by davie.textdrive.com (Postfix) with ESMTP id 2032535B46; Fri, 8 Apr 2011 10:29:26 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <5F6BB0D9318FCA4083FC774C9A9ECEF68AE831F9F8@NLCLUEXM03.connect1.local> Date: Fri, 8 Apr 2011 12:29:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <057.ca63b30ac3e3ffdf9aad52c02fa3ebc8@trac.tools.ietf.org> <4D9AF230.6020805@labs.htt-consult.com> <4D9B0750.8010408@labs.htt-consult.com> <99AAB914-B0BB-445B-8DCF-75B23D6A1D5E@tzi.org> <5F6BB0D9318FCA4083FC774C9A9ECEF68AE831F9F8@NLCLUEXM03.connect1.local> To: "Garcia Morchon, Oscar" X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org" Subject: Re: [core] #138: DTLS Clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 08 Apr 2011 10:27:45 -0000 On Apr 8, 2011, at 09:12, Garcia Morchon, Oscar wrote: > http://csrc.nist.gov/publications/nistpubs/800-108/sp800-108.pdf That indeed points to SP800-38B (CMAC). I don't know how to properly operate CMAC as a PRF for key derivation = with TLS's 48-byte (pre-)master secrets while using AES-128 (which uses = only 16-byte keys) -- what to do with the remaining 32 bytes of secret? = That's why I think this needs help from cryptographers... Gruesse, Carsten From rgm@labs.htt-consult.com Fri Apr 8 09:18:06 2011 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4CA23A69D6 for ; Fri, 8 Apr 2011 09:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EYwVITBNbjO for ; Fri, 8 Apr 2011 09:18:05 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id A841C3A69D2 for ; Fri, 8 Apr 2011 09:18:04 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 13E3962A84; Fri, 8 Apr 2011 16:19:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qic-5p6LDjc0; Fri, 8 Apr 2011 12:19:09 -0400 (EDT) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id D84AD62A70; Fri, 8 Apr 2011 12:19:08 -0400 (EDT) Message-ID: <4D9F357C.8040708@labs.htt-consult.com> Date: Fri, 08 Apr 2011 12:19:08 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9 MIME-Version: 1.0 To: Carsten Bormann References: <057.ca63b30ac3e3ffdf9aad52c02fa3ebc8@trac.tools.ietf.org> <4D9AF230.6020805@labs.htt-consult.com> <4D9B0750.8010408@labs.htt-consult.com> <99AAB914-B0BB-445B-8DCF-75B23D6A1D5E@tzi.org> In-Reply-To: <99AAB914-B0BB-445B-8DCF-75B23D6A1D5E@tzi.org> Content-Type: multipart/alternative; boundary="------------040007010806090100000903" Cc: core@ietf.org Subject: Re: [core] #138: DTLS Clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 08 Apr 2011 16:18:07 -0000 This is a multi-part message in MIME format. --------------040007010806090100000903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 04/07/2011 11:34 PM, Carsten Bormann wrote: > On Apr 8, 2011, at 00:34, Robert Cragie wrote: > >> In my experience both SHA-256 and HMAC are not expensive. > Clearly SHA-256 (and especially HMAC) are not particularly expensive in execution time when used as the PRF for establishing TLS connections. > > Still, on a highly constrained device, all other things being the same, it would be preferable not to spend the code space if existing AES encryption hardware (or even software) can be employed. So I do believe it is worth exploring an AES-based PRF, *if* it can provide the same security characteristics. I will point out that in 802.15.4 where AES-CCM hardware is present and AES-CMAC is available, the trend is to use it an avoid the code cost for SHA-whatever. And in CPU cost you are comparing a software implementation of SHA-whatever and HMAC with a hardware optimized CMAC. We are suppose to be looking at everything we do and what is truly needed for the application and what is 'supporting functions' And how the supporting functions add value with little cost. Remember there is concerted effort in IEEE in 11073 for medical and (I think) 11074 for energy to NOT use any of this IP and HTTP cruft. Further BTLE is now bringing their MAC into 6lowpan. Now they may claim to have completely solved (for their systems) the security challenge... And it will be interesting what 802.11LE will be like next year. The 'cost' in CPU and battery for the PRF should be small as it should be infrequent (rekeying only?). It is a code size issue. We have CMAC and we have CMAC PRFs. > Gruesse, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > -- Robert Moskowitz Senior Technical Director ICSA Labs, an Independent Division of Verizon Business Systems W:248-968-9809 F:248-968-2824 VoIP:248-291-0713 E:robert.moskowitz@icsalabs.com There's no limit to what can be accomplished if it doesn't matter who gets the credit --------------040007010806090100000903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 04/07/2011 11:34 PM, Carsten Bormann wrote: 
On Apr 8, 2011, at 00:34, Robert Cragie wrote:


In my experience both SHA-256 and HMAC are not expensive. 

Clearly SHA-256 (and especially HMAC) are not particularly expensive in execution time when used as the PRF for establishing TLS connections.

Still, on a highly constrained device, all other things being the same, it would be preferable not to spend the code space if existing AES encryption hardware (or even software) can be employed. So I do believe it is worth exploring an AES-based PRF, *if* it can provide the same security characteristics.

I will point out that in 802.15.4 where AES-CCM hardware is present and AES-CMAC is available, the trend is to use it an avoid the code cost for SHA-whatever.  And in CPU cost you are comparing a software implementation of SHA-whatever and HMAC with a hardware optimized CMAC.

We are suppose to be looking at everything we do and what is truly needed for the application and what is 'supporting functions'  And how the supporting functions add value with little cost.  Remember there is concerted effort in IEEE in 11073 for medical and (I think) 11074 for energy to NOT use any of this IP and HTTP cruft.

Further BTLE is now bringing their MAC into 6lowpan.  Now they may claim to have completely solved (for their systems) the security challenge...  And it will be interesting what 802.11LE will be like next year.

The 'cost' in CPU and battery for the PRF should be small as it should be infrequent (rekeying only?).  It is a code size issue.  We have CMAC and we have CMAC PRFs.


Gruesse, Carsten

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

--
Standard Robert Moskowitz
Senior Technical Director
ICSA Labs, an Independent Division of Verizon Business Systems
W:      248-968-9809
F:      248-968-2824
VoIP:   248-291-0713
E:      robert.moskowitz@icsalabs.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--------------040007010806090100000903-- From rgm@labs.htt-consult.com Fri Apr 8 09:25:53 2011 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89B2C3A694F for ; Fri, 8 Apr 2011 09:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efkC2SHz+Jf1 for ; Fri, 8 Apr 2011 09:25:48 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 0D1053A6907 for ; Fri, 8 Apr 2011 09:25:48 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 6C62162A7F; Fri, 8 Apr 2011 16:27:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBlT-8nd9OR4; Fri, 8 Apr 2011 12:26:47 -0400 (EDT) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id B539462A70; Fri, 8 Apr 2011 12:26:47 -0400 (EDT) Message-ID: <4D9F3747.30303@labs.htt-consult.com> Date: Fri, 08 Apr 2011 12:26:47 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9 MIME-Version: 1.0 To: Carsten Bormann References: <057.ca63b30ac3e3ffdf9aad52c02fa3ebc8@trac.tools.ietf.org> <4D9AF230.6020805@labs.htt-consult.com> <4D9B0750.8010408@labs.htt-consult.com> <99AAB914-B0BB-445B-8DCF-75B23D6A1D5E@tzi.org> <5F6BB0D9318FCA4083FC774C9A9ECEF68AE831F9F8@NLCLUEXM03.connect1.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "core@ietf.org" Subject: Re: [core] #138: DTLS Clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 08 Apr 2011 16:25:53 -0000 On 04/08/2011 06:29 AM, Carsten Bormann wrote: > On Apr 8, 2011, at 09:12, Garcia Morchon, Oscar wrote: > >> http://csrc.nist.gov/publications/nistpubs/800-108/sp800-108.pdf > That indeed points to SP800-38B (CMAC). > I don't know how to properly operate CMAC as a PRF for key derivation with TLS's 48-byte (pre-)master secrets while using AES-128 (which uses only 16-byte keys) -- what to do with the remaining 32 bytes of secret? That's why I think this needs help from cryptographers... There is RFC 4615. I do have a note here from Hugo Krawczyk somewhere that some improvements can be made on this. I followed Hugo's recommendation in the PRF in HIP-DEX. From hvdsomp@gmail.com Fri Apr 8 15:36:12 2011 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0435E3A6A3D for ; Fri, 8 Apr 2011 15:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jJK2U98WQJh for ; Fri, 8 Apr 2011 15:36:10 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 161093A6A36 for ; Fri, 8 Apr 2011 15:36:10 -0700 (PDT) Received: by qyk7 with SMTP id 7so2610010qyk.10 for ; Fri, 08 Apr 2011 15:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=pUzevto3060zCKJKhkCBPHJwCrD0WNuO5avp7YKzLPc=; b=rGnFkb0mg9ormqQUrYN0vHniKrfBbC+JZ7I/884nTXugl8HwzN5lknmDaS7Z4WFnUF q17Cd8Hpu9Fze8c7AmcIiMY+oUhr6rbjmPQeI6AyrxkFvFC2B8w0RZtvfqwAqQfSW9cG rZhj/Bo5UMQYN+zsRgaaNJ5wOQreU7VyfGEdY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=ik2VcO6Z4kDbWYxkkNU/b5iMTjj4LIKPkcVkxlUgcSUE7VCiBpvrVgDnMN2jZ9WpIB p/zvnbm73nqklFc1nfWmygvaRGif6H8G3tUnWxQFkDDpDIuCeUWVWo8SfJewv1Cyy6P/ SyqMQwUs32saW0v71/m0EdupO1WRmOXKMdY30= MIME-Version: 1.0 Received: by 10.229.65.216 with SMTP id k24mr2261248qci.237.1302302273898; Fri, 08 Apr 2011 15:37:53 -0700 (PDT) Received: by 10.229.227.148 with HTTP; Fri, 8 Apr 2011 15:37:53 -0700 (PDT) Date: Fri, 8 Apr 2011 16:37:53 -0600 Message-ID: From: Herbert van de Sompel To: core@ietf.org Content-Type: multipart/alternative; boundary=0016e651396e6d090b04a06fe06d Cc: azaroth42@gmail.com, Michael Nelson Subject: [core] declaring default Context IRI for links in application/link-format documents X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 08 Apr 2011 22:36:12 -0000 --0016e651396e6d090b04a06fe06d Content-Type: text/plain; charset=ISO-8859-1 Hi all, I have posted to this list before regarding the use of application/link-format documents in the context of the Memento (Time Travel for the Web) framework (see https://datatracker.ietf.org/doc/draft-vandesompel-memento/ and http://mementoweb.org). In Memento, we have come across a problem that we think you also have in the CoRE effort, and that we assume others would have that want to leverage application/link-format type documents: the real Context IRI for links expressed in these documents is implicit and can only be understood by applications that are specialized in processing a certain kind of application/link-format documents, e.g. CoRE-specific or Memento-specific processors. In Memento, a typical application/link-format document, which we call a TimeMap looks like this: ;rel="original", ; rel="timegate", ; rel="memento";datetime="Tue, 20 Jun 2000 18:02:59 GMT", ; rel="memento";datetime="Tue, 27 Oct 2009 20:49:54 GMT", ... All links should be interpreted to have http://a.example.org as Context IRI. If we understand it correctly, CoRE faces a similar issue because the links in its application/link-format documents need to be interpreted, for example, as having the baseURL (scheme & authority) of the Target IRI as their Context IRI. In both cases, there can be no "universal" understanding of the provided links. This problem could be addressed by making all links explicit through the introduction of an anchor for every single link, e.g. for TimeMaps: ; anchor="http://a.example.org"; rel="timegate", ; anchor="http://a.example.org"; rel="memento";datetime="Tue, 20 Jun 2000 18:02:59 GMT", ; anchor="http://a.example.org"; rel="memento";datetime="Tue, 27 Oct 2009 20:49:54 GMT", ... This is not impossible but it definitely generates a lot of redundancy in the document, and added complexity for processing. So, we were wondering whether there would be interest in introducing a solution that is inspired by the element of HTML, i.e. providing a link that expresses what the Context IRI is for all links provided in the document (the first line in the below example). The above Memento TimeMap would then look as follows: ;rel="contextIRI";anchor="URI-of-TimeMap", ; rel="timegate", ; rel="memento";datetime="Tue, 20 Jun 2000 18:02:59 GMT", ; rel="memento";datetime="Tue, 27 Oct 2009 20:49:54 GMT", ... In which: => URI-of-TimeMap is the URI of the application/link-format document itself => contextIRI is a new relation type that could be registered (e.g. in the CoRE RFC). Note that the rel could also be called "base" or "anchor", or whatever is deemed to make most sense. This would make links in application/link-format documents generally understandable, without the need to resort to repeating the same anchor in each link. And note that this would still allow overwriting the default Context IRI with another one by using the "anchor" attribute on a link. From a processing perspective, determining what the Context IRI for any given link is would be as follows: 1. The value provided in the "anchor" attribute on a link; 2. The value provided as the Target IRI of a link that has the contextIRI rel type; 3. The URI of the resource that returns the application/link-format document as a representation (as is the case with the Link header). Looking forward to feedback. Cheers Herbert Van de Sompel -- Herbert Van de Sompel Digital Library Research & Prototyping Los Alamos National Laboratory, Research Library http://public.lanl.gov/herbertv/ == --0016e651396e6d090b04a06fe06d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have posted to this list before regarding the = use of application/link-format documents in the context of the Memento (Tim= e Travel for the Web) framework (see=A0https://datatracker.ietf.org/doc/draft-= vandesompel-memento/ and http://memen= toweb.org).

In Memento, we have come across a pr= oblem that we think you also have in the CoRE effort, and that we assume ot= hers would have that want to leverage=A0application/link-format type docume= nts: the real Context IRI for links expressed in these documents is implici= t and can only be understood by applications that are specialized in proces= sing a certain kind of=A0application/link-format documents, e.g. CoRE-speci= fic or Memento-specific processors.=A0

In Memento, a typical=A0application/= link-format document, which we call a TimeMap looks like this:
<http://a.example.org>;rel=3D"original",
 <htt=
p://arxiv.example.net/timegate/http://a.example.org> ; rel=3D"t=
imegate",=A0
 &=
lt;http://arxiv.example.net/web/20000620180259/http://a.example.org&g=
t;
   ; rel=3D"memento";datetime=3D"Tue, 20 Jun 2000 18:02:59 G=
MT",=20
 <http://arxiv.example.net/web/20091027204954/http://a.example.org=
>
    ; rel=3D"memento";datetime=3D"Tue, 27 Oct 2009 20:49:54 =
GMT", ...
All links should be interpreted to= have=A0http://a.example.org as Context IRI= . =A0If we understand it correctly, CoRE faces a similar issue be= cause the links in its=A0application/link-format documen= ts need to be interpreted, for example, as having the baseURL (scheme &= authority) of the Target IRI as =A0their=A0Context IRI.= In both cases, there can be no "universal" understanding of the = provided links.

This problem could be addr= essed by making all links explicit through the introduction of an anchor fo= r every single link, e.g. for TimeMaps:
<= http://arxiv.example.net/timegate/http://a.example.org> ; anchor=3D"http://a.example.org"; rel=3D"timega= te", 
 <http://arxiv.example.net/web/20=
000620180259/http://a.example.org>
   ; anchor=3D"http://a.example.org"; rel=3D"memento&=
quot;;datetime=3D"Tue, 20 Jun 2000 18:02:59 GMT", 
 <http://arxiv.example.net/web/20=
091027204954/http://a.example.org>
    ; anchor=3D"http://a.example.org"; rel=3D"memen=
to";datetime=3D"Tue, 27 Oct 2009 20:49:54 GMT", ...
This is not impossible but it definitely genera= tes a lot of redundancy in the document, and added complexity for processin= g.=A0

So, we were wondering whether there would be interest in= introducing a solution that is inspired by the <base> element of HTM= L, i.e. providing a link that expresses what the Context= IRI is for all links provided in the document (the first line in the below= example). The above Memento TimeMap would then look as follows: 
<http://a.example.org<=
font class=3D"Apple-style-span" face=3D"arial, helvetica, sans-serif">>;=
rel=3D"contextIRI";anchor=3D"URI-o=
f-TimeMap",
 <http://arxiv.example.net/timegate/http://=
a.example.org> ; rel=3D"timegate",=A0
 <http://arxiv.example.net/web/20=
000620180259/http://a.example.org>
   ; rel=3D"memento";datetime=3D"Tue, 20 Jun 2000 18:02:59 G=
MT",=20
 <http://arxiv.example.net/web/20091027204954/http://a.example.org=
>
    ; rel=3D"memento";datetime=3D"Tue, 27 Oct 2009 20:49:54 =
GMT", ...
In which:

=3D>=A0URI-of-T= imeMap is the URI of the application/link-format documen= t itself
=3D> contextIRI is= a new relation type that could be registered (e.g. in the CoRE RFC). Note = that the rel could also be called "base" or "anchor", o= r whatever is deemed to make most sense.

This would make links in application/link-fo= rmat documents generally understandable, without the need to resort to repe= ating the same anchor in each link. And=A0note that this= would still allow overwriting the default Context IRI with another one by = using the "anchor" attribute on a link. From a processing perspec= tive, determining what the Context IRI for any given link is would be as fo= llows:
1. The value provided in the "anchor" attribute = on a link;
2. The value provided as the Target= IRI of a link that has the contextIRI rel type;
3. The URI of the resource that returns the=A0application/link-format document as a representation (as is the case= with the Link header).

Looking forward to feedb= ack.

Cheers
=
Herbert Van de Sompel

--
Herbert Van de Sompel
= Digi= tal Library Research & Prototyping
Los Alamos National Laboratory, Research Library
http://public.lanl.gov/herbertv/
=3D=3D

--0016e651396e6d090b04a06fe06d-- From likepeng@huawei.com Sun Apr 10 20:29:36 2011 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71D223A6A47 for ; Sun, 10 Apr 2011 20:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.829 X-Spam-Level: * X-Spam-Status: No, score=1.829 tagged_above=-999 required=5 tests=[AWL=-1.880, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vq+yHEVDy95m for ; Sun, 10 Apr 2011 20:29:34 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 16C723A6A43 for ; Sun, 10 Apr 2011 20:29:34 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJG0027XXOSDB@szxga05-in.huawei.com> for core@ietf.org; Mon, 11 Apr 2011 11:29:16 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJG002U3XORW7@szxga05-in.huawei.com> for core@ietf.org; Mon, 11 Apr 2011 11:29:16 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 11 Apr 2011 11:29:14 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.27]) by SZXEML402-HUB.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Mon, 11 Apr 2011 11:29:14 +0800 Date: Mon, 11 Apr 2011 03:29:12 +0000 From: Likepeng In-reply-to: X-Originating-IP: [10.70.109.110] To: "Dijk, Esko" , "core@ietf.org" Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F22828B7@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_r7h3mssRMkXYZjsD1fM2Pw)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Combined 4.13 response with Block Option? Thread-index: Acv0ZJQIx8ZQBp/tTp+HmFeeM1mcAwAWmpzwAEAt31AAjjEKIA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <34966E97BE8AD64EAE9D3D6E4DEE36F2280F85@SZXEML506-MBS.china.huawei.com> Subject: Re: [core] Combined 4.13 response with Block Option? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 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, 11 Apr 2011 03:29:36 -0000 --Boundary_(ID_r7h3mssRMkXYZjsD1fM2Pw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 UGVyc29uYWxseSBJIGRvbqGvdCB0aGluayBpdCBpcyBxdWl0ZSB1c2VmdWwuIEJ1dCBsZXShr3Mg aGVhciBvdGhlcqGvcyBvcGluaW9uLg0KDQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0KRnJvbTogRGlq aywgRXNrbyBbbWFpbHRvOmVza28uZGlqa0BwaGlsaXBzLmNvbV0NClNlbnQ6IEZyaWRheSwgQXBy aWwgMDgsIDIwMTEgMzo1OCBQTQ0KVG86IExpa2VwZW5nOyBjb3JlQGlldGYub3JnDQpTdWJqZWN0 OiBSRTogQ29tYmluZWQgNC4xMyByZXNwb25zZSB3aXRoIEJsb2NrIE9wdGlvbj8NCg0KRGVhciBL ZXBlbmcsDQoNCnRoZXJlIGFyZSBwcm9iYWJseSBub3QgbWFueSB1c2UgY2FzZXMgdGhhdCB3b3Vs ZCByZXF1aXJlIHRoaXMgZmVhdHVyZS4gSG93ZXZlciBteSB0aGlua2luZyB3YXMgdGhhdCBiZWNh dXNlIGltcGxlbWVudGF0aW9uIG9mIHRoaXMgZmVhdHVyZSAoobByZXNwb25kIDQuMTMgd2l0aCBC bG9jayBPcHRpb26hsSkgaXMgZnVsbHkgb3B0aW9uYWwgYXQgYm90aCBjbGllbnQgYW5kIHNlcnZl ciBzaWRlcywgaXQgd291bGQgbm90IGh1cnQgdG8gaW5jbHVkZSBpdCBpbiB0aGUgc3BlYyA/DQoN CkFuZCBJIGhhdmUgYSB1c2UgY2FzZSBpbiBtaW5kOiBhIHdpcmVsZXNzIGNvbnN0cmFpbmVkIHNl cnZlciBTIHRoYXQgaXMgY29ubmVjdGVkIHZpYSBhIHNsb3cgc2VyaWFsIGxpbmsgdG8gYSBsZWdh Y3kgZGV2aWNlLCBzYXkgMTIwMCBicHMgc2ltaWxhciB0byB0aGUgREFMSSBwcm90b2NvbC4gVGhl IGZpcm13YXJlIG9mIHRoZSBsZWdhY3kgZGV2aWNlIGlzIHRvIGJlIHVwZGF0ZWQgaW4gYmxvY2tz IHZpYSBDb0FQLCB3aGVyZSBTIHJlbGF5cyB0aGUgZGF0YSB0aGVuIG9uIHRvIHRoZSBzZXJpYWwg bGluZSB1c2luZyBhIGN1c3RvbSBwcm90b2NvbC4gTm93IGEgY2xpZW50IG1pZ2h0IGZvb2xpc2hs eSBkZWNpZGUgdG8gc2VuZCBhIFBVVCByZXF1ZXN0IHRvIFMgd2l0aCBhIDEwMjQgYnl0ZSBibG9j ay4gUyBkb2VzIGhhdmUgbWVtb3J5IHRvIHRlbXBvcmFyaWx5IGJ1ZmZlciB0aGUgbGFyZ2UgMTAy NCBieXRlIGJsb2NrLCBidXQgaXQgdGFrZXMgdXAgdG9vIG11Y2ggcmVzb3VyY2VzIGZvciBhIHRv byBsb25nIHRpbWUuIFRvIGdldCBhIHNpbXBsZSBpbXBsZW1lbnRhdGlvbiBhbmQgZ3VhcmFudGVl ZCByZWxpYWJsZSBvcGVyYXRpb24gb2YgUyBkdXJpbmcgdGhlIGZpcm13YXJlIHVwZGF0ZSwgUyBw cmVmZXJzIDY0IGJ5dGUgYmxvY2tzIGFuZCBkb2VzIG5vdCB3YW50IHRvIGtlZXAgbGFyZ2UgYmxv Y2tzIGluIG1lbW9yeS4gIEluIHRoZSBjdXJyZW50IENvQVAtYmxvY2sgZHJhZnQsIHRoZXJlIGlz IG5vIHdheSBmb3IgUyB0byBpbmRpY2F0ZSB0aGlzOyBjdXJyZW50bHkgaWYgSaGvbSBjb3JyZWN0 IFMgY2FuIGVpdGhlciAxKSByZXNwb25kIGVycm9yIDQuMTMgb3IgMikgQUNLIHdpdGggYSBzdWNj ZXNzIGNvZGUgYWZ0ZXIgaXQgaGFzIHByb2Nlc3NlZCB0aGUgZW50aXJlIDEwMjQgYnl0ZSBmaXJz dCBibG9jay4gKGFzIGluIEZpZyA5KQ0KDQpPZiBjb3Vyc2UgYW5vdGhlciwgZWFzaWVyLCBzb2x1 dGlvbiBoZXJlIGlzIHRoYXQgYWxsIG15IENvQVAgY2xpZW50cyBhcmUgcHJlLWNvbmZpZ3VyZWQg dG8gb25seSB1c2UgNjQtYnl0ZSBibG9ja3MgaW4gdGhlIGZpcnN0IHBsYWNlLiBCdXQgaW4gYSBt dWx0aS12ZW5kb3Igc2l0dWF0aW9uLCBvbmUgY2FuIG5vdCBiZSBzdXJlIHRoYXQgdGhpcyB0eXBl IG9mIGNvbmZpZ3VyYXRpb24gaXMgcG9zc2libGUgOykNCg0KYmVzdCByZWdhcmRzLA0KRXNrbw0K DQpGcm9tOiBMaWtlcGVuZyBbbWFpbHRvOmxpa2VwZW5nQGh1YXdlaS5jb21dDQpTZW50OiBUaHVy c2RheSA3IEFwcmlsIDIwMTEgMzowNg0KVG86IERpamssIEVza287IGNvcmVAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBDb21iaW5lZCA0LjEzIHJlc3BvbnNlIHdpdGggQmxvY2sgT3B0aW9uPw0KDQo+ V2hhdCB0aGUgc2VydmVyIG1heWJlIHdhbnRzIHRvIHRlbGwgaXMgobBJIGNhbiBwcm9jZXNzIDY0 IGJ5dGUgYmxvY2tzIGF0IG1vc3QgYXQgYSB0aW1lLCBpZiB5b3Ugd2FudCByZXRyeSB0aGlzIHdp dGggYSBibG9jayBzaXplIDw9IDY0obEuDQpJZiB0aGUgc2VydmVyIGNhbqGvdCBhY2NlcHQgNjQg Ynl0ZSwgd2hpY2ggaXMgcGFydCBvZiB0aGUgcmVzb3VyY2UsIHdoYXQgaXMgdGhlIHVzZSBjYXNl IHRvIHJlY2VpdmUgYW4gZXZlbiBzbWFsbGVyIHBhcnQgb2YgdGhlIHJlc291cmNlPw0KDQo+UXVl c3Rpb24gaXM6IGlzIGl0IGFsbG93ZWQgZm9yIHRoZSBzZXJ2ZXIgdG8gb3B0aW9uYWxseSBpbmNs dWRlIGEgQmxvY2sgT3B0aW9uIGluIGEgNC4xMyBlcnJvciByZXNwb25zZSwgdG8gaW5kaWNhdGUg dGhlIG1heCBibG9jayBzaXplIHRoYXQgaXMgc3VwcG9ydGVkID8NCkN1cnJlbnRseSB0aGUgZHJh ZnQgc3VwcG9ydHMgdGhlIGluZGljYXRpb24gb2YgcHJlZmVycmVkIGJsb2NrIHNpemUgaW4gdGhl IHJlc3BvbnNlLCB3aGljaCBzZWVtcyB0byBiZSBlbm91Z2guDQoNCktpbmQgUmVnYXJkcw0KS2Vw ZW5nDQq3orz+yMs6IGNvcmUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNvcmUtYm91bmNlc0Bp ZXRmLm9yZ10gtPqx7SBEaWprLCBFc2tvDQq3osvNyrG85DogMjAxMcTqNNTCNsjVIDIyOjEyDQrK 1bz+yMs6IGNvcmVAaWV0Zi5vcmcNCtb3zOI6IFtjb3JlXSBDb21iaW5lZCA0LjEzIHJlc3BvbnNl IHdpdGggQmxvY2sgT3B0aW9uPw0KDQpEZWFyIGFsbCAvIGF1dGhvcnMgb2YgYmxvY2stMDIsDQoN Cmxvb2tpbmcgYXQgdGhlIGNvcmUtYmxvY2stMDIgZHJhZnQ7IGEgc2VydmVyIGNhbiBpbmRpY2F0 ZSBhIHByZWZlcnJlZCAoZS5nLiBzbWFsbGVyKSBibG9jayBzaXplIHRvIGEgY2xpZW50IGluIHJl c3BvbnNlIHRvIGEgYmxvY2t3aXNlIFBVVCAoc2VlIEZpZ3VyZSA5KS4gVGhpcyBpcyBuaWNlIGJ1 dCB0aGUgZXhhbXBsZXMgKGkuZS4gRmlnIDkpIHNob3cgb25seSB0aGUgY2FzZSB0aGF0IHRoZSBz ZXJ2ZXIgd2FzIGNhcGFibGUgb2YgcHJvY2Vzc2luZyB0aGUgIGVudGlyZSBmaXJzdCBibG9jayAo b2YgMTI4IGJ5dGVzLCB3aGljaCBpcyBsYXJnZXIgdGhhbiB0aGUgc2VydmVyoa9zIHByZWZlcmVu Y2UpIGNvcnJlY3RseS4gV2hhdCBhYm91dCBhIGNhc2Ugd2hlcmUgdGhlIHNlcnZlciBpcyBvbmx5 IHdpbGxpbmcgdG8gcHJvY2VzcyBzbWFsbGVyIGJsb2NrcyBlLmcuIG1heCA2NCBieXRlcyBhdCBh IHRpbWU/ICBPZiBjb3Vyc2UgdGhlIHNlcnZlciBjYW4gcmVzcG9uZCB3aXRoIGVycm9yIGNvZGUg NC4xMyBhcyBpbmRpY2F0ZWQgaW4gdGhlIGRyYWZ0LiBIb3dldmVyLCB0aGUgY2xpZW50IGNvdWxk IHVuZGVyc3RhbmQgNC4xMyBhcyChsG5vIHJlc291cmNlcyBhdCB0aGlzIG1vbWVudCB0byBzdXBw b3J0IGFueSBtb3JlIGJsb2NrIG9wZXJhdGlvbnOhsSBhbmQgdGhlbiBnaXZlIHVwLiBXaGF0IHRo ZSBzZXJ2ZXIgbWF5YmUgd2FudHMgdG8gdGVsbCBpcyChsEkgY2FuIHByb2Nlc3MgNjQgYnl0ZSBi bG9ja3MgYXQgbW9zdCBhdCBhIHRpbWUsIGlmIHlvdSB3YW50IHJldHJ5IHRoaXMgd2l0aCBhIGJs b2NrIHNpemUgPD0gNjShsS4NCg0KUXVlc3Rpb24gaXM6IGlzIGl0IGFsbG93ZWQgZm9yIHRoZSBz ZXJ2ZXIgdG8gb3B0aW9uYWxseSBpbmNsdWRlIGEgQmxvY2sgT3B0aW9uIGluIGEgNC4xMyBlcnJv ciByZXNwb25zZSwgdG8gaW5kaWNhdGUgdGhlIG1heCBibG9jayBzaXplIHRoYXQgaXMgc3VwcG9y dGVkID8NCg0KSSBhc3N1bWUgaGVyZSB0aGF0LCBldmVuIHRob3VnaCBhIFBVVCByZXF1ZXN0IHdh cyBjb3JyZWN0bHkgcmVjZWl2ZWQsIHRoZSBzZXJ2ZXIgZm9yIHNvbWUgaW1wbGVtZW50YXRpb24g cmVhc29uIGlzIHVud2lsbGluZyB0byBwcm9jZXNzIGEgYmxvY2sgdGhhdCBsYXJnZSBpbiBvbmUg Z28uDQoNCmJlc3QgcmVnYXJkcywNCkVza28gRGlqaw0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5 IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVnYWxseSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGljYWJsZSBs YXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZShzKS4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90 aWZpZWQgdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9uLCBvciByZXByb2R1 Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1 bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNv bnRhY3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMg b2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQo= --Boundary_(ID_r7h3mssRMkXYZjsD1fM2Pw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Personally I don=A1=AFt think it is quite useful. But let=A1=AFs = hear other=A1=AFs opinion.

 

Kind Regards

Kepeng

From: Dijk, Esko [mailto:= esko.dijk@philips.com]
Sent: Friday, April 08, 2011 3:58 PM
To: Likepeng; core@ietf.org
Subject: RE: Combined 4.13 response with Block Option?

 

Dear Ke= peng,

&n= bsp;

there a= re probably not many use cases that would require this feature. However my = thinking was that because implementation of this feature (=A1=B0respond 4.1= 3 with Block Option=A1=B1) is fully optional at both client and server sides, it would not hurt to include it in the spec = ?

&n= bsp;

And I h= ave a use case in mind: a wireless constrained server S that is connected v= ia a slow serial link to a legacy device, say 1200 bps similar to the DALI = protocol. The firmware of the legacy device is to be updated in blocks via CoAP, where S relays the data then on to th= e serial line using a custom protocol. Now a client might foolishly decide = to send a PUT request to S with a 1024 byte block. S does have memory to te= mporarily buffer the large 1024 byte block, but it takes up too much resources for a too long time. To get= a simple implementation and guaranteed reliable operation of S during the = firmware update, S prefers 64 byte blocks and does not want to keep large b= locks in memory.  In the current CoAP-block draft, there is no way for S to indicate this; currently if I= =A1=AFm correct S can either 1) respond error 4.13 or 2) ACK with a success= code after it has processed the entire 1024 byte first block. (as in Fig 9= )

&n= bsp;

Of cour= se another, easier, solution here is that all my CoAP clients are pre-confi= gured to only use 64-byte blocks in the first place. But in a multi-vendor = situation, one can not be sure that this type of configuration is possible ;)

&n= bsp;

best re= gards,

Esko

&n= bsp;

From: Likepeng [mailto:li= kepeng@huawei.com]
Sent: Thursday 7 April 2011 3:06
To: Dijk, Esko; core@ietf.org
Subject: Re: Combined 4.13 response with Block Option?

 

>What the server maybe wants= to tell is =A1=B0I can process 64 byte blocks at most at a time, if you wa= nt retry this with a block size <=3D 64=A1=B1.

If the server can=A1=AFt accept 64 byte, which is part of the res= ource, what is the use case to receive an even smaller part of the resource= ?

 

>Question is: is it allowed = for the server to optionally include a Block Option in a 4.13 error respons= e, to indicate the max block size that is supported ? 

Currently the draft supports the indication of preferred block si= ze in the response, which seems to be enough.

 

Kind Regards

Kepeng

=B7=A2=BC=FE=C8=CB: core-bounces@ietf.org [mailto:core-bounces@ietf.= org] =B4=FA= =B1=ED Dijk, Esko
=B7=A2= =CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C26=C8=D5 22:12
=CA=D5=BC=FE=C8=CB: core@ietf.org
=D6=F7=CC=E2: [core] Combined 4.13 response with Block Option?=

 

Dear all / authors of block-02,=

 

looking at the core-block-02 dr= aft; a server can indicate a preferred (e.g. smaller) block size to a clien= t in response to a blockwise PUT (see Figure 9). This is nice but the examp= les (i.e. Fig 9) show only the case that the server was capable of processing the  entire first block (of= 128 bytes, which is larger than the server=A1=AFs preference) correctly. W= hat about a case where the server is only willing to process smaller blocks= e.g. max 64 bytes at a time?  Of course the server can respond with error code 4.13 as indicated in the draft. However= , the client could understand 4.13 as =A1=B0no resources at this moment to = support any more block operations=A1=B1 and then give up. What the server m= aybe wants to tell is =A1=B0I can process 64 byte blocks at most at a time, if you want retry this with a block size <=3D= 64=A1=B1.

 

Question is: is it allowed for = the server to optionally include a Block Option in a 4.13 error response, t= o indicate the max block size that is supported ? 

 

I assume here that, even though= a PUT request was correctly received, the server for some implementation r= eason is unwilling to process a block that large in one go.

 

best regards,=

Esko Dijk

 

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

--Boundary_(ID_r7h3mssRMkXYZjsD1fM2Pw)-- From ekr@rtfm.com Mon Apr 11 15:24:45 2011 Return-Path: X-Original-To: core@ietfc.amsl.com Delivered-To: core@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7AAB5E068E for ; Mon, 11 Apr 2011 15:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.272 X-Spam-Level: X-Spam-Status: No, score=-102.272 tagged_above=-999 required=5 tests=[AWL=0.705, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiIjso5KBulr for ; Mon, 11 Apr 2011 15:24:43 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id 77D56E06A4 for ; Mon, 11 Apr 2011 15:24:36 -0700 (PDT) Received: by iwn39 with SMTP id 39so7522561iwn.31 for ; Mon, 11 Apr 2011 15:24:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.227.194 with SMTP id jb2mr3571005icb.454.1302559014203; Mon, 11 Apr 2011 14:56:54 -0700 (PDT) Received: by 10.42.241.5 with HTTP; Mon, 11 Apr 2011 14:56:54 -0700 (PDT) In-Reply-To: <4D9F357C.8040708@labs.htt-consult.com> References: <057.ca63b30ac3e3ffdf9aad52c02fa3ebc8@trac.tools.ietf.org> <4D9AF230.6020805@labs.htt-consult.com> <4D9B0750.8010408@labs.htt-consult.com> <99AAB914-B0BB-445B-8DCF-75B23D6A1D5E@tzi.org> <4D9F357C.8040708@labs.htt-consult.com> Date: Mon, 11 Apr 2011 14:56:54 -0700 Message-ID: From: Eric Rescorla To: Robert Moskowitz Content-Type: text/plain; charset=ISO-8859-1 Cc: core@ietf.org Subject: Re: [core] #138: DTLS Clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 11 Apr 2011 22:24:45 -0000 On Fri, Apr 8, 2011 at 9:19 AM, Robert Moskowitz wrote: > On 04/07/2011 11:34 PM, Carsten Bormann wrote: > > On Apr 8, 2011, at 00:34, Robert Cragie wrote: > > In my experience both SHA-256 and HMAC are not expensive. > > Clearly SHA-256 (and especially HMAC) are not particularly expensive in > execution time when used as the PRF for establishing TLS connections. > > Still, on a highly constrained device, all other things being the same, it > would be preferable not to spend the code space if existing AES encryption > hardware (or even software) can be employed. The problem is that all else isn't equal here: we have a well-understood PRF that is already standardized. Not using that PRF reduces the general applicability of the proposed CCM modes. So, I think before making a change like that it would be better to demonstrate that the SHA-256 code is actually an important contributor to code size -Ekr From juhovh@iki.fi Mon Apr 11 23:25:09 2011 Return-Path: X-Original-To: core@ietfc.amsl.com Delivered-To: core@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E9B94E0743 for ; Mon, 11 Apr 2011 23:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Id0Ljh18NNw for ; Mon, 11 Apr 2011 23:25:09 -0700 (PDT) Received: from kirsi2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfc.amsl.com (Postfix) with ESMTP id 867BFE0730 for ; Mon, 11 Apr 2011 23:25:09 -0700 (PDT) Received: from [192.168.1.100] (88.192.44.252) by kirsi2.inet.fi (8.5.133) id 4D95968700159855 for core@ietf.org; Tue, 12 Apr 2011 09:25:08 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= In-Reply-To: Date: Tue, 12 Apr 2011 09:25:07 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4DD1DBC7-6868-4246-9184-441B59F35D3D@iki.fi> References: <057.ca63b30ac3e3ffdf9aad52c02fa3ebc8@trac.tools.ietf.org> <4D9AF230.6020805@labs.htt-consult.com> <4D9B0750.8010408@labs.htt-consult.com> <99AAB914-B0BB-445B-8DCF-75B23D6A1D5E@tzi.org> <4D9F357C.8040708@labs.htt-consult.com> To: core@ietf.org X-Mailer: Apple Mail (2.1082) Subject: Re: [core] #138: DTLS Clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 06:25:10 -0000 On Apr 12, 2011, at 12:56 AM, Eric Rescorla wrote: > On Fri, Apr 8, 2011 at 9:19 AM, Robert Moskowitz > wrote: >> On 04/07/2011 11:34 PM, Carsten Bormann wrote: >>=20 >> On Apr 8, 2011, at 00:34, Robert Cragie wrote: >>=20 >> In my experience both SHA-256 and HMAC are not expensive. >>=20 >> Clearly SHA-256 (and especially HMAC) are not particularly expensive = in >> execution time when used as the PRF for establishing TLS connections. >>=20 >> Still, on a highly constrained device, all other things being the = same, it >> would be preferable not to spend the code space if existing AES = encryption >> hardware (or even software) can be employed. >=20 > The problem is that all else isn't equal here: we have a = well-understood PRF > that is already standardized. Not using that PRF reduces the general > applicability > of the proposed CCM modes. So, I think before making a change like = that it > would be better to demonstrate that the SHA-256 code is actually an = important > contributor to code size I'm new on this list, but thought to express some motivation behind = this. I implemented Robert's HIP DEX protocol where he had successfully = removed cryptographic hash functions, and in the progress mentioned it = would be easy to make TLS similar by just using static ECDH or ECDH_anon = and CMAC based PRF, possibly even easier than implementing the HIP DEX = itself. I can't speak for anyone else, but I think you're misunderstanding my = idea here. Currently draft-mcgrew-tls-aes-ccm-eec-01 defines only = ECDSA_ECDHE cipher suites (which are written as ECDHE_ECDSA in the draft = by the way, that is completely wrong order) and if one wants to use them = they have to have a cryptographic hash function available anyway for = signing the ephemeral Diffie-Hellman keys. Changing the PRF to AES based = has no point there. However, using a CMAC based PRF that doesn't have a hash function would = be useful as an _optional_ feature in the ECDH_anon and PSK-ECDHE cipher = suites, which are apparently not defined yet. Just like the AES-GCM = cipher suites are defining two PRFs (SHA-256 and SHA-384 based HMAC), = the AES-CCM modes that don't use signing could define an additional PRF = for low class devices. I would probably need some data about SHA-256 = code space, because I very much agree that it is not expensive in = execution time, have to get back to it. But it's clear that already the = lookup tables of SHA-256 take some amount of space. I should probably also contact David McGrew about the same AES-CCM draft = related to the elliptic curves requirement. It has the sentence and a = list "The ECDHE_ECDSA key exchange is performed as defined in [RFC4492] = with the following additional stipulations", where I disagree with most = of the additional stipulations. They greatly reduce the general = applicability of the proposed CCM modes, as you just said. I'm = especially worried about that secp256r1 and secp384r1 MUST be supported, = because I have already demonstrated that my wireless sensor node is NOT = capable of even performing a secp256r1 handshake. The secp224r1 on the = other hand works reasonably well, difference between those two is huge = because of the different pseudo-Mersenne primes used in modular = reduction. Only reason why I see the two curves required there is NSA Suite B and = maybe something that's happening in the Zigbee group, but that shouldn't = affect the generalness of AES-CCM cipher suites in TLS. I remember = writing about this to David earlier, but apparently it wasn't changed = when the draft was updated. Before this kind of major problems with = general applicability are solved, I don't know how relevant it is to = fight about PRFs. But I don't think a CMAC PRF in addition to HMAC PRF = in some cipher suites would be a bad idea at all. What was the = motivation behind making the PRF selectable in TLS 1.2 if you are going = to argue against cipher suites selecting a different PRF as an option = anyway? Juho From juhovh@iki.fi Mon Apr 11 23:41:33 2011 Return-Path: X-Original-To: core@ietfc.amsl.com Delivered-To: core@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 81037E0754 for ; Mon, 11 Apr 2011 23:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNBRKo8Q0cZt for ; Mon, 11 Apr 2011 23:41:33 -0700 (PDT) Received: from kirsi2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfc.amsl.com (Postfix) with ESMTP id C2572E074D for ; Mon, 11 Apr 2011 23:41:32 -0700 (PDT) Received: from [192.168.1.100] (88.192.44.252) by kirsi2.inet.fi (8.5.133) id 4D9596870015A17F; Tue, 12 Apr 2011 09:41:31 +0300 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= In-Reply-To: <4DD1DBC7-6868-4246-9184-441B59F35D3D@iki.fi> Date: Tue, 12 Apr 2011 09:41:30 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <160E38E5-D29B-4B69-A245-9C7993638B0A@iki.fi> References: <057.ca63b30ac3e3ffdf9aad52c02fa3ebc8@trac.tools.ietf.org> <4D9AF230.6020805@labs.htt-consult.com> <4D9B0750.8010408@labs.htt-consult.com> <99AAB914-B0BB-445B-8DCF-75B23D6A1D5E@tzi.org> <4D9F357C.8040708@labs.htt-consult.com> <4DD1DBC7-6868-4246-9184-441B59F35D3D@iki.fi> To: =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= X-Mailer: Apple Mail (2.1082) Cc: core@ietf.org Subject: Re: [core] #138: DTLS Clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 06:41:33 -0000 On Apr 12, 2011, at 9:25 AM, Juho V=E4h=E4-Herttua wrote: > Currently draft-mcgrew-tls-aes-ccm-eec-01 defines only ECDSA_ECDHE = cipher suites (which are written as ECDHE_ECDSA in the draft by the way, = that is completely wrong order) Sorry, you can ignore that part, ECDHE_ECDSA is the correct order. It is = the PSK_DHE in draft-mcgrew-tls-aes-ccm-01 that is in the wrong order = (compared with RFC 4279) and I got confused here looking at them both. = In TLS notation the key exchange is always first and additional = parameters (signature, PSK) are after. Juho From rgm@labs.htt-consult.com Tue Apr 12 05:34:12 2011 Return-Path: X-Original-To: core@ietfc.amsl.com Delivered-To: core@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3ACA9E066B for ; Tue, 12 Apr 2011 05:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XE7o5PBjyCM6 for ; Tue, 12 Apr 2011 05:34:11 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfc.amsl.com (Postfix) with ESMTP id DE747E07BD for ; Tue, 12 Apr 2011 05:34:10 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id EBA1562AC1 for ; Tue, 12 Apr 2011 12:33:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofl23ta6w04l for ; Tue, 12 Apr 2011 08:33:14 -0400 (EDT) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id AAEC762A6C for ; Tue, 12 Apr 2011 08:33:14 -0400 (EDT) Message-ID: <4DA4468A.5040005@labs.htt-consult.com> Date: Tue, 12 Apr 2011 08:33:14 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9 MIME-Version: 1.0 To: core@ietf.org References: <057.ca63b30ac3e3ffdf9aad52c02fa3ebc8@trac.tools.ietf.org> <4D9AF230.6020805@labs.htt-consult.com> <4D9B0750.8010408@labs.htt-consult.com> <99AAB914-B0BB-445B-8DCF-75B23D6A1D5E@tzi.org> In-Reply-To: <99AAB914-B0BB-445B-8DCF-75B23D6A1D5E@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [core] HIP DEX code X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 12:34:12 -0000 A team of students at Aalto University have implemented HIP DEX http://code.google.com/p/hip-dex/source/checkout to analyze its performance. They have submitted a paper to http://www.ieee-pimrc.org/ I expect at a later date this paper can be made available (after the conference, probably). Meanwhile I am making some improvements to the protocol based on their findings. Watch for a new draft. From cabo@tzi.org Tue Apr 12 07:38:49 2011 Return-Path: X-Original-To: core@ietfc.amsl.com Delivered-To: core@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 74402E079E for ; Tue, 12 Apr 2011 07:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8LaNg6CINac for ; Tue, 12 Apr 2011 07:38:48 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfc.amsl.com (Postfix) with ESMTP id 51F04E0798 for ; Tue, 12 Apr 2011 07:38:48 -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.3/8.14.3) with ESMTP id p3CEcbHf024680; Tue, 12 Apr 2011 16:38:40 +0200 (CEST) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0F8AAFEE; Tue, 12 Apr 2011 16:38:37 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Tue, 12 Apr 2011 16:38:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6EE0F5D0-4183-4C26-8083-DF1AA0599B6D@tzi.org> References: <057.ca63b30ac3e3ffdf9aad52c02fa3ebc8@trac.tools.ietf.org> <4D9AF230.6020805@labs.htt-consult.com> <4D9B0750.8010408@labs.htt-consult.com> <99AAB914-B0BB-445B-8DCF-75B23D6A1D5E@tzi.org> <4D9F357C.8040708@labs.htt-consult.com> To: Eric Rescorla X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org WG" Subject: Re: [core] #138: DTLS Clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 14:38:49 -0000 On Apr 11, 2011, at 23:56, Eric Rescorla wrote: > So, I think before making a change like that it > would be better to demonstrate that the SHA-256 code is actually an = important > contributor to code size I can't claim really solid numbers here, but a quick check here at TZI = produced the following sizes: Processor Code+Constants (bytes) 8051 6337 (A) MSP430 3642 (A) ATmega 3472 (B) x86-64 2340 (A) Where (A) is a generic C implementation of SHA-256 and (B) is code = optimized for the specific processor family; all of these were compiled = with optimizer settings optimizing for code size. Clearly, it is possible to generate more compact implementations, but = the order of magnitude is certainly right. For what we have been calling class-2 devices (~50 KiB data/~250 KiB = code), there is no problem, as Robert has indicated. For class-1 = devices (~10/~100), this *is* a problem (there is more stuff competing = for these 48 to 128 KiB). I strongly believe the MTI (mandatory-to-implement) scheme needs to = address class-1 devices or it will be ignored, so I think spending some = time to look at alternative key derivation functions is well-justified. (Of course, it is not a foregone conclusion that a good one will pop = up.) Gruesse. Carsten From rgm@labs.htt-consult.com Tue Apr 12 08:20:24 2011 Return-Path: X-Original-To: core@ietfc.amsl.com Delivered-To: core@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6AFAFE07D5 for ; Tue, 12 Apr 2011 08:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cad3hpby7rOm for ; Tue, 12 Apr 2011 08:20:23 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfc.amsl.com (Postfix) with ESMTP id 43F5DE07A0 for ; Tue, 12 Apr 2011 08:20:23 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id EF69362B97; Tue, 12 Apr 2011 15:20:01 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZhKKbb3RRfP; Tue, 12 Apr 2011 11:19:41 -0400 (EDT) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id 1A87562C19; Tue, 12 Apr 2011 11:18:39 -0400 (EDT) Message-ID: <4DA46D4F.9090108@labs.htt-consult.com> Date: Tue, 12 Apr 2011 11:18:39 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9 MIME-Version: 1.0 To: Carsten Bormann References: <057.ca63b30ac3e3ffdf9aad52c02fa3ebc8@trac.tools.ietf.org> <4D9AF230.6020805@labs.htt-consult.com> <4D9B0750.8010408@labs.htt-consult.com> <99AAB914-B0BB-445B-8DCF-75B23D6A1D5E@tzi.org> <4D9F357C.8040708@labs.htt-consult.com> <6EE0F5D0-4183-4C26-8083-DF1AA0599B6D@tzi.org> In-Reply-To: <6EE0F5D0-4183-4C26-8083-DF1AA0599B6D@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "core@ietf.org WG" Subject: Re: [core] #138: DTLS Clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 15:20:24 -0000 On 04/12/2011 10:38 AM, Carsten Bormann wrote: > On Apr 11, 2011, at 23:56, Eric Rescorla wrote: > >> So, I think before making a change like that it >> would be better to demonstrate that the SHA-256 code is actually an important >> contributor to code size > I can't claim really solid numbers here, but a quick check here at TZI produced the following sizes: > > Processor Code+Constants (bytes) > 8051 6337 (A) > MSP430 3642 (A) > ATmega 3472 (B) > x86-64 2340 (A) > > Where (A) is a generic C implementation of SHA-256 and (B) is code optimized for the specific processor family; all of these were compiled with optimizer settings optimizing for code size. > Clearly, it is possible to generate more compact implementations, but the order of magnitude is certainly right. > > For what we have been calling class-2 devices (~50 KiB data/~250 KiB code), there is no problem, as Robert has indicated. For class-1 devices (~10/~100), this *is* a problem (there is more stuff competing for these 48 to 128 KiB). > > I strongly believe the MTI (mandatory-to-implement) scheme needs to address class-1 devices or it will be ignored, so I think spending some time to look at alternative key derivation functions is well-justified. > (Of course, it is not a foregone conclusion that a good one will pop up.) Am I correct that DTLS-PSK only needs PRF for key refresh? Key refresh pretty much has to be a part of a good KMP. HIP does this in 1 round trip using the UPDATE packets (unless PFS is needed, but then you would not be using HIP DEX, rather HIP BEX, IKEv2, etc.). TLS-PSK SHOULD be able to function as other security encapsulating protocols to instruct the KMP to produce fresh keys and not be manditory to do it internally. Plus a lot of class-1 devices will NOT be sending more than 2^61 datagrams over their lifetime thus perhaps never issuing a key refresh. In HIP DEX the key refresh is basically a call into the basic machinery. It is needed for the initial keying and is there if rekeying is ever needed. Thus two approaches, both should be included: TLS-PSK MAY use an external key refresh mechanism and TLS-AES-CCM MAY use a CMAC PRF. BTW, the PRF in HIP DEX is based on RFC 4615 with an improvement recommended by Hugo Krawczyk. Which is to use a nonce for the key not ZERO. From robert.cragie@gridmerge.com Tue Apr 12 09:08:08 2011 Return-Path: X-Original-To: core@ietfc.amsl.com Delivered-To: core@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9243AE07DA for ; Tue, 12 Apr 2011 09:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39nAqeY8JZyR for ; Tue, 12 Apr 2011 09:08:07 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfc.amsl.com (Postfix) with ESMTP id 55D37E07D3 for ; Tue, 12 Apr 2011 09:08:07 -0700 (PDT) Received: from client-82-26-149-225.pete.adsl.virginmedia.com ([82.26.149.225] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.73) id 1Q9g8L-0001a6-3V for core@ietf.org; Tue, 12 Apr 2011 17:08:06 +0100 Message-ID: <4DA478E2.6020701@gridmerge.com> Date: Tue, 12 Apr 2011 17:08:02 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: core@ietf.org References: <057.ca63b30ac3e3ffdf9aad52c02fa3ebc8@trac.tools.ietf.org> <4D9AF230.6020805@labs.htt-consult.com> <4D9B0750.8010408@labs.htt-consult.com> <99AAB914-B0BB-445B-8DCF-75B23D6A1D5E@tzi.org> <4D9F357C.8040708@labs.htt-consult.com> <6EE0F5D0-4183-4C26-8083-DF1AA0599B6D@tzi.org> In-Reply-To: <6EE0F5D0-4183-4C26-8083-DF1AA0599B6D@tzi.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080709020900060707000007" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [core] #138: DTLS Clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 16:08:08 -0000 This is a cryptographically signed message in MIME format. --------------ms080709020900060707000007 Content-Type: multipart/alternative; boundary="------------070400030603040005050301" This is a multi-part message in MIME format. --------------070400030603040005050301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable So some figures I have: Module ro code ro data rw data sha256.o 1 364 41 64 IAR=20 compiler, ARM7TDMI, thumb mode sha256.o 1 376 45 64 IAR=20 compiler, ARM Cortex M3 This is code written purely in C so could no doubt be optimised in=20 assembler. As already mentioned, HMAC on top is trivial. CMAC will also=20 require subkey and MAC generation code on top of the block cipher=20 invocation. SHA-256 becomes a fundamental building block for ECDHE_ECDSA cipher=20 suites as we also used for signature generation. We are actually trying=20 to deprecate SHA-1, which seems to persist in certain places (x509 for=20 example). Robert On 12/04/2011 3:38 PM, Carsten Bormann wrote: > On Apr 11, 2011, at 23:56, Eric Rescorla wrote: > >> So, I think before making a change like that it >> would be better to demonstrate that the SHA-256 code is actually an im= portant >> contributor to code size > I can't claim really solid numbers here, but a quick check here at TZI = produced the following sizes: > > Processor Code+Constants (bytes) > 8051 6337 (A) > MSP430 3642 (A) > ATmega 3472 (B) > x86-64 2340 (A) > > Where (A) is a generic C implementation of SHA-256 and (B) is code opti= mized for the specific processor family; all of these were compiled with = optimizer settings optimizing for code size. > Clearly, it is possible to generate more compact implementations, but t= he order of magnitude is certainly right. > > For what we have been calling class-2 devices (~50 KiB data/~250 KiB co= de), there is no problem, as Robert has indicated. For class-1 devices (= ~10/~100), this *is* a problem (there is more stuff competing for these 4= 8 to 128 KiB). > > I strongly believe the MTI (mandatory-to-implement) scheme needs to add= ress class-1 devices or it will be ignored, so I think spending some time= to look at alternative key derivation functions is well-justified. > (Of course, it is not a foregone conclusion that a good one will pop up= =2E) > > Gruesse. Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --------------070400030603040005050301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So some figures I have:

    Module       &n= bsp;           &nb= sp;         ro code  ro data=   rw data
    sha256.o       =             &= nbsp;         1 364  &n= bsp;    41       64 IAR compiler, ARM7TDMI, thumb mode
    sha256.o       =             &= nbsp;         1 376  &n= bsp;    45       64 IAR compiler, ARM Cortex M3

This is code written purely in C so could no doubt be optimised in assembler. As already mentioned, HMAC on top is trivial. CMAC will also require subkey and MAC generation code on top of the block cipher invocation.

SHA-256 becomes a fundamental building block for ECDHE_ECDSA cipher suites as we also used for signature generation. We are actually trying to deprecate SHA-1, which seems to persist in certain places (x509 for example).

Robert

On 12/04/2011 3:38 PM, Carsten Bormann wrote: 
On Apr 11, 2011, at 23:56, Eric Rescorla wrote:


So, I think before making a change like that it
would be better to demonstrate that the SHA-256 code is actually an impor=
tant
contributor to code size

I can't claim really solid numbers here, but a quick check here at TZI pr=
oduced the following sizes:

Processor	Code+Constants (bytes)
8051		6337			(A)
MSP430		3642			(A)
ATmega		3472			(B)
x86-64		2340			(A)

Where (A) is a generic C implementation of SHA-256 and (B) is code optimi=
zed for the specific processor family; all of these were compiled with op=
timizer settings optimizing for code size.
Clearly, it is possible to generate more compact implementations, but the=
 order of magnitude is certainly right.

For what we have been calling class-2 devices (~50 KiB data/~250 KiB code=
), there is no problem, as Robert has indicated.  For class-1 devices (~1=
0/~100), this *is* a problem (there is more stuff competing for these 48 =
to 128 KiB).

I strongly believe the MTI (mandatory-to-implement) scheme needs to addre=
ss class-1 devices or it will be ignored, so I think spending some time t=
o look at alternative key derivation functions is well-justified.
(Of course, it is not a foregone conclusion that a good one will pop up.)=


Gruesse. Carsten

_______________________________________________
core mailing list
core@=
ietf.org
https://www.ietf.org/mailman/listinfo/core
--------------070400030603040005050301-- --------------ms080709020900060707000007 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIREjCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIGPjCCBSagAwIBAgIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEX MBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAw WhcNMTEwODMwMjM1OTU5WjCB5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQ RVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIw MDMgQ29tb2RvIExpbWl0ZWQxFjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0B CQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALQCfpvU4Hd5YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1ut iDsDQqvWnt1cHgZb4N1FFbvLqV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdw lObJ1ol4FUWnFPB/A7/liT7G+FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1w gm4SRHIv7VJfgseNKQd5u55RHQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRF bWyoPEgAmGYXRwsdvmUkq8W2wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEA AaOCAh0wggIZMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRp GoTqjgTJPeVwG/HaXEXWnn/AGDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNV HSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1Ud IAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNv bW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2Eu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRp Y2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDov L2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneI VKHrpx4LJImjCEGNinH6G+PDrs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrW t5NMbwbotDQLTq0gXW6guL4ICyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV 3gmBbDPh3PVTyGfnAGOyUBSRCvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHG NnR+CZAx+qXTczLc8pL7DtDXokR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6 HSg520a9rfVXa1NqMIIGPjCCBSagAwIBAgIRALZcFI008b3qkGPLKBbwWBIwDQYJKoZIhvcN AQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtl IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDov L3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAwWhcNMTEwODMwMjM1OTU5WjCB 5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05BIE5PVCBWQUxJREFU RUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0cDovL3d3dy5j b21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExpbWl0ZWQx FjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVA Z3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALQCfpvU4Hd5 YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1utiDsDQqvWnt1cHgZb4N1FFbvL qV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdwlObJ1ol4FUWnFPB/A7/liT7G +FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1wgm4SRHIv7VJfgseNKQd5u55R HQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRFbWyoPEgAmGYXRwsdvmUkq8W2 wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEAAaOCAh0wggIZMB8GA1UdIwQY MBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRpGoTqjgTJPeVwG/HaXEXWnn/A GDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYL KwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQEC AQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNV HR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3Qt Q2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3Js MGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5jb21vZG9jYS5jb20v VVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneIVKHrpx4LJImjCEGNinH6G+PD rs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrWt5NMbwbotDQLTq0gXW6guL4I Cyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV3gmBbDPh3PVTyGfnAGOyUBSR CvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHGNnR+CZAx+qXTczLc8pL7DtDX okR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6HSg520a9rfVXa1NqMYIEYDCC BFwCAQEwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBM YWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMAkGBSsOAwIaBQCg ggJwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQxMjE2 MDgwMlowIwYJKoZIhvcNAQkEMRYEFCg60MVxF9/iH6BxZBUuzbMmLvZvMF8GCSqGSIb3DQEJ DzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB1QYJKwYBBAGCNxAEMYHHMIHEMIGu MQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4w HAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNl cnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAtlwUjTTxveqQY8soFvBYEjCB1wYLKoZIhvcNAQkQAgsxgceggcQw ga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkx HjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMA0GCSqGSIb3DQEBAQUABIIBAG5F ZGu0FAS5NDVGNPo1DkUc3OQ+b+jA7rVp8k6sykRdGHzn3cjAcxFnirB43hbKv5QS6LhZmRtf ezLrB/pNtTDoDUASYsxAw13bw51BQqB9QaeH3KDooq23z3Q4TtLRGzYpTo0Y4//S/vVpiyVZ jUAYAXCVCGfdncbX+4HqcMlN8Yu0x0GVxBEVdxBwpOX2tMPm0ykSxazQAL95svOd7BlFI9Qq 7ilmaPrMA8mTQMQ7v4FwJm1SSfVlJbvn6EHQyDzZuXsL5xUJmAqLto0xiZ0mboWNMzJdAhGe KcQYdAsdo3k0JqWvv2Q/ZrpC2BkeUHhpEOp1pY8OC4TzN9vsPAgAAAAAAAA= --------------ms080709020900060707000007-- From juhovh@iki.fi Tue Apr 12 09:42:15 2011 Return-Path: X-Original-To: core@ietfc.amsl.com Delivered-To: core@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A6269E083F for ; Tue, 12 Apr 2011 09:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZzMuwuadA5D for ; Tue, 12 Apr 2011 09:42:15 -0700 (PDT) Received: from kirsi2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfc.amsl.com (Postfix) with ESMTP id C29D9E083C for ; Tue, 12 Apr 2011 09:42:14 -0700 (PDT) Received: from [192.168.1.100] (88.192.44.252) by kirsi2.inet.fi (8.5.133) id 4D9596870016F7EC; Tue, 12 Apr 2011 19:41:57 +0300 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= In-Reply-To: <4DA46D4F.9090108@labs.htt-consult.com> Date: Tue, 12 Apr 2011 19:41:09 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5097C2D1-BC08-48D7-9655-CE888816E5B1@iki.fi> References: <057.ca63b30ac3e3ffdf9aad52c02fa3ebc8@trac.tools.ietf.org> <4D9AF230.6020805@labs.htt-consult.com> <4D9B0750.8010408@labs.htt-consult.com> <99AAB914-B0BB-445B-8DCF-75B23D6A1D5E@tzi.org> <4D9F357C.8040708@labs.htt-consult.com> <6EE0F5D0-4183-4C26-8083-DF1AA0599B6D@tzi.org> <4DA46D4F.9090108@labs.htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.1082) Cc: "core@ietf.org WG" Subject: Re: [core] #138: DTLS Clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 16:42:15 -0000 On Apr 12, 2011, at 6:18 PM, Robert Moskowitz wrote: > Am I correct that DTLS-PSK only needs PRF for key refresh? Short answer: Yes. Long answer: TLS (and DTLS) PSK suites generate "master secret" using PRF, shared = secret, client nonce and server nonce. The shared secret includes the = PSK and optionally RSA/DH/ECDH handshake. The actual keys are then = generated from this "master secret" by using the same PRF, client nonce = and server nonce. If the "master secret" is cached it can be reused in = following handshakes with different nonces. (and therefore it generates = different keys) > Key refresh pretty much has to be a part of a good KMP. HIP does this = in 1 round trip using the UPDATE packets (unless PFS is needed, but then = you would not be using HIP DEX, rather HIP BEX, IKEv2, etc.). TLS has actually two ways to refresh keys, either by caching the session = and doing a new TLS handshake, or by performing renegotiation. There are = several things in renegotiation which make it a bit complicated, = personally I might just stick with caching the session info and doing a = new handshake. In both cases it requires a 4-way handshake though. > TLS-PSK SHOULD be able to function as other security encapsulating = protocols to instruct the KMP to produce fresh keys and not be manditory = to do it internally. >=20 > Plus a lot of class-1 devices will NOT be sending more than 2^61 = datagrams over their lifetime thus perhaps never issuing a key refresh. = In HIP DEX the key refresh is basically a call into the basic machinery. = It is needed for the initial keying and is there if rekeying is ever = needed. >=20 > Thus two approaches, both should be included: TLS-PSK MAY use an = external key refresh mechanism and TLS-AES-CCM MAY use a CMAC PRF. >=20 > BTW, the PRF in HIP DEX is based on RFC 4615 with an improvement = recommended by Hugo Krawczyk. Which is to use a nonce for the key not = ZERO. This is actually a bit misleading, the PRF in HIP DEX is not really = based on RFC 4615. It is almost identical with RFC 5869 (by Hugo = Krawczyk) simply replacing the HMAC with CMAC. In HIP DEX the nonce is = defined as the block size of CMAC and in case of AES-128 the block size = is the same as key length, so RFC 4615 is not really relevant there. Juho From ekr@rtfm.com Tue Apr 12 15:25:31 2011 Return-Path: X-Original-To: core@ietfc.amsl.com Delivered-To: core@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 36E23E0895 for ; Tue, 12 Apr 2011 15:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.343 X-Spam-Level: X-Spam-Status: No, score=-102.343 tagged_above=-999 required=5 tests=[AWL=0.634, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nm0ySsGa3pWe for ; Tue, 12 Apr 2011 15:25:30 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfc.amsl.com (Postfix) with ESMTP id 7C66BE085E for ; Tue, 12 Apr 2011 15:25:30 -0700 (PDT) Received: by iye19 with SMTP id 19so38073iye.31 for ; Tue, 12 Apr 2011 15:25:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.60.205 with SMTP id wt13mr10964373icb.253.1302647130146; Tue, 12 Apr 2011 15:25:30 -0700 (PDT) Received: by 10.42.241.5 with HTTP; Tue, 12 Apr 2011 15:25:30 -0700 (PDT) In-Reply-To: <4DA46D4F.9090108@labs.htt-consult.com> References: <057.ca63b30ac3e3ffdf9aad52c02fa3ebc8@trac.tools.ietf.org> <4D9AF230.6020805@labs.htt-consult.com> <4D9B0750.8010408@labs.htt-consult.com> <99AAB914-B0BB-445B-8DCF-75B23D6A1D5E@tzi.org> <4D9F357C.8040708@labs.htt-consult.com> <6EE0F5D0-4183-4C26-8083-DF1AA0599B6D@tzi.org> <4DA46D4F.9090108@labs.htt-consult.com> Date: Tue, 12 Apr 2011 15:25:30 -0700 Message-ID: From: Eric Rescorla To: Robert Moskowitz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "core@ietf.org WG" Subject: Re: [core] #138: DTLS Clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 12 Apr 2011 22:25:31 -0000 On Tue, Apr 12, 2011 at 8:18 AM, Robert Moskowitz wrote: > On 04/12/2011 10:38 AM, Carsten Bormann wrote: >> >> On Apr 11, 2011, at 23:56, Eric Rescorla wrote: >> >>> So, I think before making a change like that it >>> would be better to demonstrate that the SHA-256 code is actually an >>> important >>> contributor to code size >> >> I can't claim really solid numbers here, but a quick check here at TZI >> produced the following sizes: >> >> Processor =A0 =A0 =A0 Code+Constants (bytes) >> 8051 =A0 =A0 =A0 =A0 =A0 =A06337 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= (A) >> MSP430 =A0 =A0 =A0 =A0 =A03642 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(A= ) >> ATmega =A0 =A0 =A0 =A0 =A03472 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(B= ) >> x86-64 =A0 =A0 =A0 =A0 =A02340 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(A= ) >> >> Where (A) is a generic C implementation of SHA-256 and (B) is code >> optimized for the specific processor family; all of these were compiled = with >> optimizer settings optimizing for code size. >> Clearly, it is possible to generate more compact implementations, but th= e >> order of magnitude is certainly right. >> >> For what we have been calling class-2 devices (~50 KiB data/~250 KiB >> code), there is no problem, as Robert has indicated. =A0For class-1 devi= ces >> (~10/~100), this *is* a problem (there is more stuff competing for these= 48 >> to 128 KiB). >> >> I strongly believe the MTI (mandatory-to-implement) scheme needs to >> address class-1 devices or it will be ignored, so I think spending some = time >> to look at alternative key derivation functions is well-justified. >> (Of course, it is not a foregone conclusion that a good one will pop up.= ) > > Am I correct that DTLS-PSK only needs PRF for key refresh? I don't know what you mean by "key refresh" here. DTLS-PSK generatess a new set of traffic keys based on the master secret for each association. > TLS-PSK SHOULD be able to function as other security encapsulating protoc= ols > to instruct the KMP to produce fresh keys and not be manditory to do it > internally. I don't understand "internally". TLS has an integrated key management protocol. There's no notion of an external KMP. -Ekr From alexey.melnikov@isode.com Wed Apr 13 01:46:17 2011 Return-Path: X-Original-To: core@ietfc.amsl.com Delivered-To: core@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 65A23E0684 for ; Wed, 13 Apr 2011 01:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Nwh3V3w0nct for ; Wed, 13 Apr 2011 01:46:16 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfc.amsl.com (Postfix) with ESMTP id A3E63E065F for ; Wed, 13 Apr 2011 01:46:08 -0700 (PDT) Received: from [188.29.146.88] (188.29.146.88.threembb.co.uk [188.29.146.88]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 13 Apr 2011 09:46:07 +0100 Message-ID: <4DA562B6.8000508@isode.com> Date: Wed, 13 Apr 2011 09:45:42 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: core@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [core] Review of draft-ietf-core-link-format-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2011 08:46:17 -0000 Hi, Here is my detailed review of the draft. It is mostly fine, but has lots of missing references. I also found lack of ABNF for the format to be inconvenient, but the prose description might be Ok, as long as it is accurate. 1. Introduction The main function of such a discovery mechanism is to provide Universal Resource Indicators (URIs, called links) for the resources I think "I" stands to Identifier. 1.2.1. Discovery Resource Discovery can be performed either unicast or multicast. When a server's IP address is already known, either a priori or resolved via the Domain Name System (DNS), unicast disovery is typo: discovery This is missing an informational reference for DNS. performed in order to locate the entry point to the resource of interest. This is performed using a GET to /.well-known/core on the server, which returns a payload in the CoRE Link Format. A client would then match the appropriate Resource Type, Interface Description and possible Content-Type for its application. These attributes may Please add an Informative reference to RFC 2045 after Content-Type. 1.3. Terminology Link Also called "typed links" in RFC5988. A link is a typed connection between two resources identified by URIs. Made up of a context URI, a link relation type, a tarfet URI, and optional typo: target target attributes. In Section 2: The CoRE link format uses the ABNF description and associated rules in Section 5 of [RFC5988]. In addition, the pchar rule is taken from [RFC3986]. The "Link:" text is omitted as that is part of the HTTP Link Header. As in [RFC5988], multiple link descriptions are separated by commas. Note that commas can also occur in quoted strings and URIs but do not end a description. Does this mean that some comma escaping mechanism is needed? The CoRE link format MUST use UTF-8 encoding A missing Normative reference to RFC 3629. , which SHOULD be in NFC (Unicode Normalization Form C). This also needs a Normative reference. 3. CoRE link extensions The following CoRE specific target attributes are defined. These attributes describe information useful in accessing the target link of the relation, and in some cases may be URIs. These URIs MUST be treated as indicators, and are not meant to be actually retrieved like a URL. Are you trying to say that they are not resolvable? link-extension = ( "ct" "=" integer ) link-extension = ( "sz" "=" integer ) integer = 1*DIGIT Are there any limits on allowed values? I generally think there should be one. 3.1. Resource type 'rt' attribute The resource type "rt" attribute is used to assign a semantically important type to a resource. One can think of this as a noun describing the resource. In the case of a temperature resource this could be an application-specific semantic type like "OutdoorTemperature", a Universal Resource Name (URN) like "urn:temperature:outdoor" or a URI referencing a specific concept in an ontology like "http://sweet.jpl.nasa.gov/2.0/phys.owl#Temperature". Is specific syntax important here, or are these values opaque? The interface description could be for example the URI of a Web Application Description Language (WADL) definition of the target I think an Informative reference is needed here. 3.3. Content-type code 'ct' attribute The Content-type code "ct" attribute provides a hint about the Internet media type this resource returns. Note that this is only a hint, and does not override the Content-type Option of a CoAP response obtained by actually following the link. The value is in the CoAP identifier code format as a decimal ASCII integer [I-D.ietf-core-coap]. This sentence is making the reference Normative, while it is listed as Informative. In Section 4.1: If the decoded query-pattern does not end with "*", a link value matches the query only if the value of the attribute or URI-reference denoted by the resource-param is bytewise identical to the query- pattern. If the decoded query-pattern ends with "*", it is sufficient that the remainder of the query-pattern be a prefix of the value denoted by the resource-param. Does * match an empty string? 6. Security Considerations Multicast requests using CoAP for the well-known link-format resources could be used to perform denial of service on a constrained network. A multicast request SHOULD only be accepted if the request is sufficiently authenticated and secured. Is there a mechanism to satisfy the SHOULD? 7.1. Attribute Registry This document defines a registry for the link extension attributes defined for use with the CoRE Link Format. The name of the registry is "CoRE Link Format Attributes". Is it wise to limit this registry to CORE only? For example, if another application using link relations is extended, how can conflicts with this registry be avoided? 7.4. New link-format Internet media type This memo registers the a new Internet media type for the CoRE link format, application/link-format. Type name: application Subtype name: link-format Required parameters: None Optional parameters: The query string may contain uri= to match the URI, or any other attribute defined for the link format to match that attribute as defined in this document. This is a wrong type of information here, as this is not talking about MIME type parameters. So I think None should be specified in this field Encoding considerations: UTF-8 (NFC) According to MIME type registration template this field should have the value "8bit". The rest can be a comment in (). Security considerations: None Are you sure :-). See RFC 4288. File extension(s): Any reason not to define an extension here? From esko.dijk@philips.com Tue Apr 19 02:29:33 2011 Return-Path: X-Original-To: core@ietfc.amsl.com Delivered-To: core@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4A8D9E0680 for ; Tue, 19 Apr 2011 02:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.003 X-Spam-Level: ** X-Spam-Status: No, score=2.003 tagged_above=-999 required=5 tests=[AWL=4.398, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBirUfhCGQCb for ; Tue, 19 Apr 2011 02:29:31 -0700 (PDT) Received: from TX2EHSOBE007.bigfish.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfc.amsl.com (Postfix) with ESMTP id 7A2B7E0677 for ; Tue, 19 Apr 2011 02:29:31 -0700 (PDT) Received: from mail124-tx2-R.bigfish.com (10.9.14.250) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.8; Tue, 19 Apr 2011 09:29:30 +0000 Received: from mail124-tx2 (localhost.localdomain [127.0.0.1]) by mail124-tx2-R.bigfish.com (Postfix) with ESMTP id D6796D4008C; Tue, 19 Apr 2011 09:29:30 +0000 (UTC) X-SpamScore: -44 X-BigFish: VPS-44(zz217bL15d6O9251J9371O1be0Lzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI Received: from mail124-tx2 (localhost.localdomain [127.0.0.1]) by mail124-tx2 (MessageSwitch) id 1303205369756330_18534; Tue, 19 Apr 2011 09:29:29 +0000 (UTC) Received: from TX2EHSMHS020.bigfish.com (unknown [10.9.14.242]) by mail124-tx2.bigfish.com (Postfix) with ESMTP id A153F1C9804D; Tue, 19 Apr 2011 09:29:29 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by TX2EHSMHS020.bigfish.com (10.9.99.120) with Microsoft SMTP Server (TLS) id 14.1.225.8; Tue, 19 Apr 2011 09:29:29 +0000 Received: from NLHILEXH01.connect1.local (172.16.153.76) by connect1.philips.com (172.16.156.160) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 19 Apr 2011 11:29:08 +0200 Received: from NLCLUEXM03.connect1.local ([172.16.153.29]) by NLHILEXH01.connect1.local ([172.16.153.76]) with mapi; Tue, 19 Apr 2011 11:29:12 +0200 From: "Dijk, Esko" To: Likepeng , "core@ietf.org" Date: Tue, 19 Apr 2011 11:29:10 +0200 Thread-Topic: Combined 4.13 response with Block Option? Thread-Index: Acv0ZJQIx8ZQBp/tTp+HmFeeM1mcAwAWmpzwAEAt31AAjjEKIAFqiNOA Message-ID: References: <34966E97BE8AD64EAE9D3D6E4DEE36F2280F85@SZXEML506-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F22828B7@SZXEML506-MBS.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F22828B7@SZXEML506-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A337AA36B3B96E4D853E6182B2F27AE2C76DBC5821NLCLUEXM03con_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [core] Combined 4.13 response with Block Option? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 19 Apr 2011 09:29:33 -0000 --_000_A337AA36B3B96E4D853E6182B2F27AE2C76DBC5821NLCLUEXM03con_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBLZXBlbmcsIGFsbCwgYXV0aG9ycywNCg0KYSBzaW1wbGVyIGFsdGVybmF0aXZlIHRvIHdo YXQgSSBwcm9wb3NlZCAoobA0LjEzIHJlc3BvbnNlIHdpdGggQmxvY2sgT3B0aW9uobEpIGlzIGZv ciB0aGUgc2VydmVyLCB3aG8gZG9lcyBub3Qgd2lzaCB0byBhY2NlcHQgYSBsYXJnZSBibG9jayAo ZXZlbiBpZiBpdCBpcyB0aGUgZmlyc3QgYmxvY2sgb2YgYSBzZXF1ZW5jZSBvbmx5KSwgdG8gdXNl IHRoZSA0LjEzIGVycm9yIHJlc3BvbnNlIGFzIHNwZWNpZmllZCBpbiB0aGUgY29hcC0wNSBJLUQs IHNlY3Rpb24gMy4xLjEuICBUaGlzIGNvdWxkIGJlIGludGVycHJldGVkIGJ5IHRoZSBjbGllbnQg YXMgobB0aGUgcmVxdWVzdCBJIHNlbnQgd2FzIHRvbyBsYXJnZaGxIHNvIHRoZSBjbGllbnQgbWF5 IGRlY2lkZSB0byB0cnkgYSBzbWFsbGVyIHJlcXVlc3QgbWVzc2FnZSAoaS5lLiBkZWNyZWFzZSB0 aGUgYmxvY2sgc2l6ZSBieSBzb21lIHNlbGYtY2hvc2VuIGFtb3VudCkuDQoNCk5vIHByb3RvY29s IGNoYW5nZXMgYXJlIHJlcXVpcmVkIGhlcmUsIGl0oa9zIGFscmVhZHkgaW4uIFRvIGF2b2lkIGNv bmZ1c2lvbiBhcyB0byB3aGF0IHRoZSA0LjEzIHJlc3BvbnNlIG1lYW5zIGluIHRoaXMgY2FzZSAo dGhpcyBjYXNlIGtpbmQgb2YgZmFsbHMgYmV0d2VlbiBjb2FwLTA1IGFuZCBibG9jay0wMiBjdXJy ZW50bHkgqEMgdGhlIGludGVycHJldGF0aW9uIG9mIDQuMTMgdXBvbiBmaXJzdCBibG9jayByZXF1 ZXN0IGRlcGVuZHMgb24gd2hpY2ggSS1EIHlvdSByZWZlciB0byEpLCBhIHNlbnRlbmNlIGNvdWxk IGJlIGFkZGVkIGluIGJsb2NrLTAyIDsNCg0KPG9yaWdpbmFsIHRleHQ+DQpUaGUgZXJyb3IgY29k ZSA0LjEzIChSZXF1ZXN0IEVudGl0eSBUb28gTGFyZ2UpIGNhbiBiZSByZXR1cm5lZCBhdCBhbnkg dGltZSBieSBhIHNlcnZlciB0aGF0IGRvZXMgbm90DQpjdXJyZW50bHkgaGF2ZSB0aGUgcmVzb3Vy Y2VzIHRvIHN0b3JlIGJsb2NrcyBmb3IgYSBibG9jay13aXNlIFBVVCBvcg0KUE9TVCB0cmFuc2Zl ciB0aGF0IGl0IHdvdWxkIGludGVuZCB0byBpbXBsZW1lbnQgaW4gYW4gYXRvbWljIGZhc2hpb24u DQoNCjxwcm9wb3NlZCBhZGRpdGlvbmFsIHRleHQgPg0KVGhlIGVycm9yIGNvZGUgNC4xMyAoUmVx dWVzdCBFbnRpdHkgVG9vIExhcmdlKSBNQVkgYWxzbyBiZSByZXR1cm5lZCBieSBhIHNlcnZlciBp biByZXNwb25zZSB0byBhIGZpcnN0IGJsb2NrIHJlcXVlc3QgdG8gaW5kaWNhdGUgdGhhdCB0aGUg YmxvY2sgc2l6ZSBpcyBsYXJnZXIgdGhhbiBpdCBpcyBjdXJyZW50bHkgd2lsbGluZyB0byBoYW5k bGUsIG9yIHRoYXQgdGhlIGZpcnN0IGJsb2NrIHJlcXVlc3QgcGF5bG9hZCB3YXMgdHJ1bmNhdGVk LCBldmVuIHRob3VnaCB0aGUgc2VydmVyIGRvZXMgY3VycmVudGx5IGhhdmUgdGhlIHJlc291cmNl cyBmb3IgY29tcGxldGluZyB0aGUgaW50ZW5kZWQgYmxvY2std2lzZSB0cmFuc2Zlci4gVGhlIGNs aWVudCBNQVkgdGhlbiByZXRyeSB0aGUgZmlyc3QgYmxvY2sgcmVxdWVzdCB1c2luZyBhIHNtYWxs ZXIgYmxvY2sgc2l6ZS4NCg0KYmVzdCByZWdhcmRzLA0KDQpFc2tvDQoNCg0KRnJvbTogTGlrZXBl bmcgW21haWx0bzpsaWtlcGVuZ0BodWF3ZWkuY29tXTxtYWlsdG86W21haWx0bzpsaWtlcGVuZ0Bo dWF3ZWkuY29tXT4NClNlbnQ6IE1vbmRheSAxMSBBcHJpbCAyMDExIDU6MjkNClRvOiBEaWprLCBF c2tvOyBjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUkU6IENv bWJpbmVkIDQuMTMgcmVzcG9uc2Ugd2l0aCBCbG9jayBPcHRpb24/DQoNClBlcnNvbmFsbHkgSSBk b26hr3QgdGhpbmsgaXQgaXMgcXVpdGUgdXNlZnVsLiBCdXQgbGV0oa9zIGhlYXIgb3RoZXKhr3Mg b3Bpbmlvbi4NCg0KS2luZCBSZWdhcmRzDQpLZXBlbmcNCkZyb206IERpamssIEVza28gW21haWx0 bzplc2tvLmRpamtAcGhpbGlwcy5jb21dPG1haWx0bzpbbWFpbHRvOmVza28uZGlqa0BwaGlsaXBz LmNvbV0+DQpTZW50OiBGcmlkYXksIEFwcmlsIDA4LCAyMDExIDM6NTggUE0NClRvOiBMaWtlcGVu ZzsgY29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBDb21i aW5lZCA0LjEzIHJlc3BvbnNlIHdpdGggQmxvY2sgT3B0aW9uPw0KDQpEZWFyIEtlcGVuZywNCg0K dGhlcmUgYXJlIHByb2JhYmx5IG5vdCBtYW55IHVzZSBjYXNlcyB0aGF0IHdvdWxkIHJlcXVpcmUg dGhpcyBmZWF0dXJlLiBIb3dldmVyIG15IHRoaW5raW5nIHdhcyB0aGF0IGJlY2F1c2UgaW1wbGVt ZW50YXRpb24gb2YgdGhpcyBmZWF0dXJlICihsHJlc3BvbmQgNC4xMyB3aXRoIEJsb2NrIE9wdGlv bqGxKSBpcyBmdWxseSBvcHRpb25hbCBhdCBib3RoIGNsaWVudCBhbmQgc2VydmVyIHNpZGVzLCBp dCB3b3VsZCBub3QgaHVydCB0byBpbmNsdWRlIGl0IGluIHRoZSBzcGVjID8NCg0KQW5kIEkgaGF2 ZSBhIHVzZSBjYXNlIGluIG1pbmQ6IGEgd2lyZWxlc3MgY29uc3RyYWluZWQgc2VydmVyIFMgdGhh dCBpcyBjb25uZWN0ZWQgdmlhIGEgc2xvdyBzZXJpYWwgbGluayB0byBhIGxlZ2FjeSBkZXZpY2Us IHNheSAxMjAwIGJwcyBzaW1pbGFyIHRvIHRoZSBEQUxJIHByb3RvY29sLiBUaGUgZmlybXdhcmUg b2YgdGhlIGxlZ2FjeSBkZXZpY2UgaXMgdG8gYmUgdXBkYXRlZCBpbiBibG9ja3MgdmlhIENvQVAs IHdoZXJlIFMgcmVsYXlzIHRoZSBkYXRhIHRoZW4gb24gdG8gdGhlIHNlcmlhbCBsaW5lIHVzaW5n IGEgY3VzdG9tIHByb3RvY29sLiBOb3cgYSBjbGllbnQgbWlnaHQgZm9vbGlzaGx5IGRlY2lkZSB0 byBzZW5kIGEgUFVUIHJlcXVlc3QgdG8gUyB3aXRoIGEgMTAyNCBieXRlIGJsb2NrLiBTIGRvZXMg aGF2ZSBtZW1vcnkgdG8gdGVtcG9yYXJpbHkgYnVmZmVyIHRoZSBsYXJnZSAxMDI0IGJ5dGUgYmxv Y2ssIGJ1dCBpdCB0YWtlcyB1cCB0b28gbXVjaCByZXNvdXJjZXMgZm9yIGEgdG9vIGxvbmcgdGlt ZS4gVG8gZ2V0IGEgc2ltcGxlIGltcGxlbWVudGF0aW9uIGFuZCBndWFyYW50ZWVkIHJlbGlhYmxl IG9wZXJhdGlvbiBvZiBTIGR1cmluZyB0aGUgZmlybXdhcmUgdXBkYXRlLCBTIHByZWZlcnMgNjQg Ynl0ZSBibG9ja3MgYW5kIGRvZXMgbm90IHdhbnQgdG8ga2VlcCBsYXJnZSBibG9ja3MgaW4gbWVt b3J5LiAgSW4gdGhlIGN1cnJlbnQgQ29BUC1ibG9jayBkcmFmdCwgdGhlcmUgaXMgbm8gd2F5IGZv ciBTIHRvIGluZGljYXRlIHRoaXM7IGN1cnJlbnRseSBpZiBJoa9tIGNvcnJlY3QgUyBjYW4gZWl0 aGVyIDEpIHJlc3BvbmQgZXJyb3IgNC4xMyBvciAyKSBBQ0sgd2l0aCBhIHN1Y2Nlc3MgY29kZSBh ZnRlciBpdCBoYXMgcHJvY2Vzc2VkIHRoZSBlbnRpcmUgMTAyNCBieXRlIGZpcnN0IGJsb2NrLiAo YXMgaW4gRmlnIDkpDQoNCk9mIGNvdXJzZSBhbm90aGVyLCBlYXNpZXIsIHNvbHV0aW9uIGhlcmUg aXMgdGhhdCBhbGwgbXkgQ29BUCBjbGllbnRzIGFyZSBwcmUtY29uZmlndXJlZCB0byBvbmx5IHVz ZSA2NC1ieXRlIGJsb2NrcyBpbiB0aGUgZmlyc3QgcGxhY2UuIEJ1dCBpbiBhIG11bHRpLXZlbmRv ciBzaXR1YXRpb24sIG9uZSBjYW4gbm90IGJlIHN1cmUgdGhhdCB0aGlzIHR5cGUgb2YgY29uZmln dXJhdGlvbiBpcyBwb3NzaWJsZSA7KQ0KDQpiZXN0IHJlZ2FyZHMsDQpFc2tvDQoNCkZyb206IExp a2VwZW5nIFttYWlsdG86bGlrZXBlbmdAaHVhd2VpLmNvbV08bWFpbHRvOlttYWlsdG86bGlrZXBl bmdAaHVhd2VpLmNvbV0+DQpTZW50OiBUaHVyc2RheSA3IEFwcmlsIDIwMTEgMzowNg0KVG86IERp amssIEVza287IGNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZTogQ29tYmluZWQgNC4xMyByZXNwb25zZSB3aXRoIEJsb2NrIE9wdGlvbj8NCg0KPldoYXQgdGhl IHNlcnZlciBtYXliZSB3YW50cyB0byB0ZWxsIGlzIKGwSSBjYW4gcHJvY2VzcyA2NCBieXRlIGJs b2NrcyBhdCBtb3N0IGF0IGEgdGltZSwgaWYgeW91IHdhbnQgcmV0cnkgdGhpcyB3aXRoIGEgYmxv Y2sgc2l6ZSA8PSA2NKGxLg0KSWYgdGhlIHNlcnZlciBjYW6hr3QgYWNjZXB0IDY0IGJ5dGUsIHdo aWNoIGlzIHBhcnQgb2YgdGhlIHJlc291cmNlLCB3aGF0IGlzIHRoZSB1c2UgY2FzZSB0byByZWNl aXZlIGFuIGV2ZW4gc21hbGxlciBwYXJ0IG9mIHRoZSByZXNvdXJjZT8NCg0KPlF1ZXN0aW9uIGlz OiBpcyBpdCBhbGxvd2VkIGZvciB0aGUgc2VydmVyIHRvIG9wdGlvbmFsbHkgaW5jbHVkZSBhIEJs b2NrIE9wdGlvbiBpbiBhIDQuMTMgZXJyb3IgcmVzcG9uc2UsIHRvIGluZGljYXRlIHRoZSBtYXgg YmxvY2sgc2l6ZSB0aGF0IGlzIHN1cHBvcnRlZCA/DQpDdXJyZW50bHkgdGhlIGRyYWZ0IHN1cHBv cnRzIHRoZSBpbmRpY2F0aW9uIG9mIHByZWZlcnJlZCBibG9jayBzaXplIGluIHRoZSByZXNwb25z ZSwgd2hpY2ggc2VlbXMgdG8gYmUgZW5vdWdoLg0KDQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0Kt6K8 /sjLOiBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZz4g W21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddPG1haWx0bzpbbWFpbHRvOmNvcmUtYm91bmNl c0BpZXRmLm9yZ10+ILT6se0gRGlqaywgRXNrbw0Kt6LLzcqxvOQ6IDIwMTHE6jTUwjbI1SAyMjox Mg0KytW8/sjLOiBjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3JnPg0K1vfM4jogW2Nv cmVdIENvbWJpbmVkIDQuMTMgcmVzcG9uc2Ugd2l0aCBCbG9jayBPcHRpb24/DQoNCkRlYXIgYWxs IC8gYXV0aG9ycyBvZiBibG9jay0wMiwNCg0KbG9va2luZyBhdCB0aGUgY29yZS1ibG9jay0wMiBk cmFmdDsgYSBzZXJ2ZXIgY2FuIGluZGljYXRlIGEgcHJlZmVycmVkIChlLmcuIHNtYWxsZXIpIGJs b2NrIHNpemUgdG8gYSBjbGllbnQgaW4gcmVzcG9uc2UgdG8gYSBibG9ja3dpc2UgUFVUIChzZWUg RmlndXJlIDkpLiBUaGlzIGlzIG5pY2UgYnV0IHRoZSBleGFtcGxlcyAoaS5lLiBGaWcgOSkgc2hv dyBvbmx5IHRoZSBjYXNlIHRoYXQgdGhlIHNlcnZlciB3YXMgY2FwYWJsZSBvZiBwcm9jZXNzaW5n IHRoZSAgZW50aXJlIGZpcnN0IGJsb2NrIChvZiAxMjggYnl0ZXMsIHdoaWNoIGlzIGxhcmdlciB0 aGFuIHRoZSBzZXJ2ZXKhr3MgcHJlZmVyZW5jZSkgY29ycmVjdGx5LiBXaGF0IGFib3V0IGEgY2Fz ZSB3aGVyZSB0aGUgc2VydmVyIGlzIG9ubHkgd2lsbGluZyB0byBwcm9jZXNzIHNtYWxsZXIgYmxv Y2tzIGUuZy4gbWF4IDY0IGJ5dGVzIGF0IGEgdGltZT8gIE9mIGNvdXJzZSB0aGUgc2VydmVyIGNh biByZXNwb25kIHdpdGggZXJyb3IgY29kZSA0LjEzIGFzIGluZGljYXRlZCBpbiB0aGUgZHJhZnQu IEhvd2V2ZXIsIHRoZSBjbGllbnQgY291bGQgdW5kZXJzdGFuZCA0LjEzIGFzIKGwbm8gcmVzb3Vy Y2VzIGF0IHRoaXMgbW9tZW50IHRvIHN1cHBvcnQgYW55IG1vcmUgYmxvY2sgb3BlcmF0aW9uc6Gx IGFuZCB0aGVuIGdpdmUgdXAuIFdoYXQgdGhlIHNlcnZlciBtYXliZSB3YW50cyB0byB0ZWxsIGlz IKGwSSBjYW4gcHJvY2VzcyA2NCBieXRlIGJsb2NrcyBhdCBtb3N0IGF0IGEgdGltZSwgaWYgeW91 IHdhbnQgcmV0cnkgdGhpcyB3aXRoIGEgYmxvY2sgc2l6ZSA8PSA2NKGxLg0KDQpRdWVzdGlvbiBp czogaXMgaXQgYWxsb3dlZCBmb3IgdGhlIHNlcnZlciB0byBvcHRpb25hbGx5IGluY2x1ZGUgYSBC bG9jayBPcHRpb24gaW4gYSA0LjEzIGVycm9yIHJlc3BvbnNlLCB0byBpbmRpY2F0ZSB0aGUgbWF4 IGJsb2NrIHNpemUgdGhhdCBpcyBzdXBwb3J0ZWQgPw0KDQpJIGFzc3VtZSBoZXJlIHRoYXQsIGV2 ZW4gdGhvdWdoIGEgUFVUIHJlcXVlc3Qgd2FzIGNvcnJlY3RseSByZWNlaXZlZCwgdGhlIHNlcnZl ciBmb3Igc29tZSBpbXBsZW1lbnRhdGlvbiByZWFzb24gaXMgdW53aWxsaW5nIHRvIHByb2Nlc3Mg YSBibG9jayB0aGF0IGxhcmdlIGluIG9uZSBnby4NCg0KYmVzdCByZWdhcmRzLA0KRXNrbyBEaWpr DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUaGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkgYmUgY29uZmlkZW50aWFsIGFuZCBsZWdhbGx5IHBy b3RlY3RlZCB1bmRlciBhcHBsaWNhYmxlIGxhdy4gVGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQgc29s ZWx5IGZvciB0aGUgYWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcs IGRpc3NlbWluYXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0 bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1h aWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgbWVzc2FnZS4NCg== --_000_A337AA36B3B96E4D853E6182B2F27AE2C76DBC5821NLCLUEXM03con_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Dear Kepeng, all, authors,

 

a simpler alternative to what I = proposed (=A1=B04.13 response with Block Option=A1=B1) is for the server, w= ho does not wish to accept a large block (even if it is the first block of = a sequence only), to use the 4.13 error response as specified in the coap-0= 5 I-D, section 3.1.1.  This could be interpreted by the client as =A1= =B0the request I sent was too large=A1=B1 so the client may decide to try a= smaller request message (i.e. decrease the block size by some self-chosen = amount).

 

No protocol changes are required here, it=A1=AFs already in. To a= void confusion as to what the 4.13 response means in this case (this case k= ind of falls between coap-05 and block-02 currently =A8C the interpretation= of 4.13 upon first block request depends on which I-D you refer to!), a se= ntence could be added in block-02 ;

 

<original text>

= The error code 4.13 (R= equest Entity Too Large) can be returned at any time by a server that does = not

cu= rrently have the resources to store blocks for a block-wise PUT or

POST transfer that it would inten= d to implement in an atomic fashion.

 

<proposed additional text = >

The error code 4.13 (Request= Entity Too Large) MAY also be returned by a server in response to a first = block request to indicate that the block size is larger than it is currentl= y willing to handle, or that the first block request payload was truncated,= even though the server does currently have the resources for completing th= e intended block-wise transfer. The client MAY then retry the first block r= equest using a smaller block size.

 

best regards,

 

= Esko

 

 

From: Li= kepeng [mailto:likepeng@hua= wei.com]
Sent: Monday 11 April 2011 5:29
To: Dijk,= Esko; core@ietf.org
Subject: RE: Combined 4.13 response with Block Option?

=

 

Personally I don=A1=AFt think it i= s quite useful. But let=A1=AFs hear other=A1=AFs opinion.=

 

Kind Regards

Kepeng

From: Dijk, Esko [mailto:esko.dijk@philips.com]
Sent: = Friday, April 08, 2011 3:58 PM
To: Likepeng; core@ietf.org
Subject: RE: Combined 4.13 respons= e with Block Option?

=  

Dea= r Kepeng,

 

there are probably not many use cases that would require this fe= ature. However my thinking was that because implementation of this feature = (=A1=B0respond 4.13 with Block Option=A1=B1) is fully optional at both clie= nt and server sides, it would not hurt to include it in the spec ?

 =

And I h= ave a use case in mind: a wireless constrained server S that is connected v= ia a slow serial link to a legacy device, say 1200 bps similar to the DALI = protocol. The firmware of the legacy device is to be updated in blocks via = CoAP, where S relays the data then on to the serial line using a custom pro= tocol. Now a client might foolishly decide to send a PUT request to S with = a 1024 byte block. S does have memory to temporarily buffer the large 1024 = byte block, but it takes up too much resources for a too long time. To get = a simple implementation and guaranteed reliable operation of S during the f= irmware update, S prefers 64 byte blocks and does not want to keep large bl= ocks in memory.  In the current CoAP-block draft, there is no way for = S to indicate this; currently if I=A1=AFm correct S can either 1) respond e= rror 4.13 or 2) ACK with a success code after it has processed the entire 1= 024 byte first block. (as in Fig 9)

 

Of course another, easier, solution he= re is that all my CoAP clients are pre-configured to only use 64-byte block= s in the first place. But in a multi-vendor situation, one can not be sure = that this type of configuration is possible ;)

 

best regards,

Esko<= /span>

 

From: Likepeng [mailto:likepeng@huawei.com]
= Sent: Thursday 7 April 2011 3:06
To: Dijk, Esko; core@ietf.org
Subject: Re: Combined 4.13= response with Block Option?

 

>What the server maybe= wants to tell is =A1=B0I can process 64 byte blocks at most at a time, if = you want retry this with a block size <=3D 64=A1=B1.

If the server can=A1=AFt accept 6= 4 byte, which is part of the resource, what is the use case to receive an e= ven smaller part of the resource?

 

>Question is: is it allowed for the server to opti= onally include a Block Option in a 4.13 error response, to indicate the max= block size that is supported ? 

<= span style=3D'font-size:10.5pt;color:#1F497D'>Currently the draft supports = the indication of preferred block size in the response, which seems to be e= nough.

 

Kind Regards

Kepeng=

=B7=A2=BC=FE=C8=CB= : core-bounces@ietf.org [mailto:core-bounces@ietf.org] = =B4=FA=B1=ED Dijk, Esko
=B7=A2=CB=CD=CA= =B1=BC=E4: 2011=C4=EA4=D4=C26=C8=D5 22:12
=CA=D5=BC=FE=C8=CB: core@= ietf.org
=D6=F7=CC=E2: [core] Combi= ned 4.13 response with Block Option?

 

Dear all / author= s of block-02,

 

looking at the core-block-02 draft; a server can indicate = a preferred (e.g. smaller) block size to a client in response to a blockwis= e PUT (see Figure 9). This is nice but the examples (i.e. Fig 9) show only = the case that the server was capable of processing the  entire first b= lock (of 128 bytes, which is larger than the server=A1=AFs preference) corr= ectly. What about a case where the server is only willing to process smalle= r blocks e.g. max 64 bytes at a time?  Of course the server can respon= d with error code 4.13 as indicated in the draft. However, the client could= understand 4.13 as =A1=B0no resources at this moment to support any more b= lock operations=A1=B1 and then give up. What the server maybe wants to tell= is =A1=B0I can process 64 byte blocks at most at a time, if you want retry= this with a block size <=3D 64=A1=B1.

 

Question is: is it allowed for= the server to optionally include a Block Option in a 4.13 error response, = to indicate the max block size that is supported ? 

 

I assume here t= hat, even though a PUT request was correctly received, the server for some = implementation reason is unwilling to process a block that large in one go.=

 

best regards,

Esko Dijk

 

The information contained in this mess= age may be confidential and legally protected under applicable law. The mes= sage is intended solely for the addressee(s). If you are not the intended r= ecipient, 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.

= --_000_A337AA36B3B96E4D853E6182B2F27AE2C76DBC5821NLCLUEXM03con_-- From trac+core@trac.tools.ietf.org Tue Apr 19 06:13:11 2011 Return-Path: X-Original-To: core@ietfc.amsl.com Delivered-To: core@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E3093E06F8 for ; Tue, 19 Apr 2011 06:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yF78c41-8U+3 for ; Tue, 19 Apr 2011 06:13:11 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id B5FDEE06F2 for ; Tue, 19 Apr 2011 06:13:09 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QCAjr-0004Ww-Kl; Tue, 19 Apr 2011 06:13:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: cabo@tzi.org, hartke@tzi.org X-Trac-Project: core Date: Tue, 19 Apr 2011 13:13:07 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/136#comment:1 Message-ID: <066.805bea213a7f28f6277e20132dbd0316@trac.tools.ietf.org> References: <057.65b7d09ad2ff8ea19af2be8c7d36e358@trac.tools.ietf.org> X-Trac-Ticket-ID: 136 In-Reply-To: <057.65b7d09ad2ff8ea19af2be8c7d36e358@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #136: UTF-8 matching clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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: Tue, 19 Apr 2011 13:13:12 -0000 #136: UTF-8 matching clarification Changes (by hartke@…): * owner: hartke@… => cabo@… -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: cabo@… Type: protocol defect | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Tue Apr 19 06:27:58 2011 Return-Path: X-Original-To: core@ietfc.amsl.com Delivered-To: core@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E06D2E06A7 for ; Tue, 19 Apr 2011 06:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAOHLRuCtfgI for ; Tue, 19 Apr 2011 06:27:58 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 5A40CE068E for ; Tue, 19 Apr 2011 06:27:58 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QCAyD-0001Qb-K3; Tue, 19 Apr 2011 06:27:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: cabo@tzi.org, hartke@tzi.org X-Trac-Project: core Date: Tue, 19 Apr 2011 13:27:57 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/136#comment:2 Message-ID: <066.ca2c5c2e3f15269f60ee184b99fbb0ce@trac.tools.ietf.org> References: <057.65b7d09ad2ff8ea19af2be8c7d36e358@trac.tools.ietf.org> X-Trac-Ticket-ID: 136 In-Reply-To: <057.65b7d09ad2ff8ea19af2be8c7d36e358@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cabo@tzi.org, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #136: UTF-8 matching clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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: Tue, 19 Apr 2011 13:27:59 -0000 #136: UTF-8 matching clarification Changes (by cabo@…): * status: new => assigned Comment: We have a little residual problem with uri-query here. This may contain percent-encoding, which may contain upper and lower case. RFC3986, section 2.1: pct-encoded = "%" HEXDIG HEXDIG The uppercase hexadecimal digits 'A' through 'F' are equivalent to the lowercase digits 'a' through 'f', respectively. If two URIs To get rid of this, we probably should try to get rid of percent-encoding in query strings. (Alternatively, we could require that all query strings be normalized according to RFC 3986 6.2.2.1 and 6.2.2.2, but that does not solve the difference between ',' and '%2c'.) To do that, we probably should identify '&' as our preferred delimiter and break up the query string along those and create separate uri-query options, one per &-delimited part. (Doing the same with '=' does not gain anything, as keys rarely contain equals signs, and makes things way more complicated.) -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: cabo@… Type: protocol defect | Status: assigned Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From likepeng@huawei.com Tue Apr 19 17:54:10 2011 Return-Path: X-Original-To: core@ietfc.amsl.com Delivered-To: core@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1CD22E072C for ; Tue, 19 Apr 2011 17:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.483 X-Spam-Level: X-Spam-Status: No, score=-0.483 tagged_above=-999 required=5 tests=[AWL=-2.088, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUmxk-bepu8i for ; Tue, 19 Apr 2011 17:54:07 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfc.amsl.com (Postfix) with ESMTP id 12602E0670 for ; Tue, 19 Apr 2011 17:54:06 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJX00E4IEI27G@szxga05-in.huawei.com> for core@ietf.org; Wed, 20 Apr 2011 08:54:02 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJX00KFQEI2G7@szxga05-in.huawei.com> for core@ietf.org; Wed, 20 Apr 2011 08:54:02 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 20 Apr 2011 08:53:56 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.27]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Wed, 20 Apr 2011 08:54:01 +0800 Date: Wed, 20 Apr 2011 00:54:00 +0000 From: Likepeng In-reply-to: X-Originating-IP: [10.70.109.110] To: "Dijk, Esko" , "core@ietf.org" Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F2283E66@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_AODFbCJnfpUl31bu5cktCg)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Combined 4.13 response with Block Option? Thread-index: AQHL/nSETKqXGLwIEEuujEVzqYzXI5Rl6xEA X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: EoZt FePS JMm6 J8CU KWbQ L9M5 L9pR MRT1 Nr8G N1BT OCZO Os7P Qm9B RYU8 TblP WGMd; 2; YwBvAHIAZQBAAGkAZQB0AGYALgBvAHIAZwA7AGUAcwBrAG8ALgBkAGkAagBrAEAAcABoAGkAbABpAHAAcwAuAGMAbwBtAA==; Sosha1_v1; 7; {20330FC5-F3A2-4CBD-B14E-AA2E33050FAA}; bABpAGsAZQBwAGUAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Wed, 20 Apr 2011 00:53:54 GMT; UgBFADoAIABDAG8AbQBiAGkAbgBlAGQAIAA0AC4AMQAzACAAcgBlAHMAcABvAG4AcwBlACAAdwBpAHQAaAAgAEIAbABvAGMAawAgAE8AcAB0AGkAbwBuAD8A x-cr-puzzleid: {20330FC5-F3A2-4CBD-B14E-AA2E33050FAA} References: <34966E97BE8AD64EAE9D3D6E4DEE36F2280F85@SZXEML506-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F22828B7@SZXEML506-MBS.china.huawei.com> Subject: Re: [core] Combined 4.13 response with Block Option? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2011 00:54:10 -0000 --Boundary_(ID_AODFbCJnfpUl31bu5cktCg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGkgRXNrbywNCg0KWW91IHByb3Bvc2VkIHRleHQgZXhjbHVkZXMgb25lIHNpdHVhdGlvbjogZHVy aW5nIHRoZSB0cmFuc21pc3Npb24sIGZvciBleGFtcGxlLCBhZnRlciBzZXZlcmFsIGJsb2Nrcywg dGhlIHJlY2lwaWVudCBmaW5kcyBvdXQgdGhhdCBpdCBoYXMgbm8gc3RvcmFnZSBmb3IgdGhlIHJl c3Qgb2YgdGhlIGJsb2NrcywgdGhlbiBpdCByZXR1cm5zIDQuMTM6IFJlcXVlc3QgRW50aXR5IFRv byBMYXJnZS4NCg0KPlRoZSBlcnJvciBjb2RlIDQuMTMgKFJlcXVlc3QgRW50aXR5IFRvbyBMYXJn ZSkgTUFZIGFsc28gYmUgcmV0dXJuZWQgYnkgYSBzZXJ2ZXIgaW4gcmVzcG9uc2UgdG8gYSBmaXJz dCBibG9jayByZXF1ZXN0IHRvIGluZGljYXRlIHRoYXQgdGhlIGJsb2NrIHNpemUgaXMgbGFyZ2Vy IHRoYW4gaXQgaXMgY3VycmVudGx5IHdpbGxpbmcgdG8gaGFuZGxlDQpJbiB0aGlzIGNhc2UsIHRo ZSBzZXJ2ZXIgY2FuIHJldHVybiBhIHNtYWxsZXIgYmxvY2sgc2l6ZSBpbiB0aGUgcmVzcG9uc2Us IGluc3RlYWQgb2YgYW4gZXJyb3IgY29kZS4NCg0KPm9yIHRoYXQgdGhlIGZpcnN0IGJsb2NrIHJl cXVlc3QgcGF5bG9hZCB3YXMgdHJ1bmNhdGVkLCBldmVuIHRob3VnaCB0aGUgc2VydmVyIGRvZXMg Y3VycmVudGx5IGhhdmUgdGhlIHJlc291cmNlcyBmb3IgY29tcGxldGluZyB0aGUgaW50ZW5kZWQg YmxvY2std2lzZSB0cmFuc2Zlci4NCkl0IGlzIGZpbmUgZm9yIHRoZSBzZXJ2ZXIgdG8gdHJ1bmNh dGUgdGhlIGZpcnN0IGJsb2NrIHJlcXVlc3QgcGF5bG9hZC4gVGhpcyBpcyBub3QgYW4gZXJyb3Iu DQoNCktpbmQgUmVnYXJkcw0KS2VwZW5nDQpGcm9tOiBEaWprLCBFc2tvIFttYWlsdG86ZXNrby5k aWprQHBoaWxpcHMuY29tXQ0KU2VudDogVHVlc2RheSwgQXByaWwgMTksIDIwMTEgNToyOSBQTQ0K VG86IExpa2VwZW5nOyBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSRTogQ29tYmluZWQgNC4xMyBy ZXNwb25zZSB3aXRoIEJsb2NrIE9wdGlvbj8NCg0KRGVhciBLZXBlbmcsIGFsbCwgYXV0aG9ycywN Cg0KYSBzaW1wbGVyIGFsdGVybmF0aXZlIHRvIHdoYXQgSSBwcm9wb3NlZCAoobA0LjEzIHJlc3Bv bnNlIHdpdGggQmxvY2sgT3B0aW9uobEpIGlzIGZvciB0aGUgc2VydmVyLCB3aG8gZG9lcyBub3Qg d2lzaCB0byBhY2NlcHQgYSBsYXJnZSBibG9jayAoZXZlbiBpZiBpdCBpcyB0aGUgZmlyc3QgYmxv Y2sgb2YgYSBzZXF1ZW5jZSBvbmx5KSwgdG8gdXNlIHRoZSA0LjEzIGVycm9yIHJlc3BvbnNlIGFz IHNwZWNpZmllZCBpbiB0aGUgY29hcC0wNSBJLUQsIHNlY3Rpb24gMy4xLjEuICBUaGlzIGNvdWxk IGJlIGludGVycHJldGVkIGJ5IHRoZSBjbGllbnQgYXMgobB0aGUgcmVxdWVzdCBJIHNlbnQgd2Fz IHRvbyBsYXJnZaGxIHNvIHRoZSBjbGllbnQgbWF5IGRlY2lkZSB0byB0cnkgYSBzbWFsbGVyIHJl cXVlc3QgbWVzc2FnZSAoaS5lLiBkZWNyZWFzZSB0aGUgYmxvY2sgc2l6ZSBieSBzb21lIHNlbGYt Y2hvc2VuIGFtb3VudCkuDQoNCk5vIHByb3RvY29sIGNoYW5nZXMgYXJlIHJlcXVpcmVkIGhlcmUs IGl0oa9zIGFscmVhZHkgaW4uIFRvIGF2b2lkIGNvbmZ1c2lvbiBhcyB0byB3aGF0IHRoZSA0LjEz IHJlc3BvbnNlIG1lYW5zIGluIHRoaXMgY2FzZSAodGhpcyBjYXNlIGtpbmQgb2YgZmFsbHMgYmV0 d2VlbiBjb2FwLTA1IGFuZCBibG9jay0wMiBjdXJyZW50bHkgqEMgdGhlIGludGVycHJldGF0aW9u IG9mIDQuMTMgdXBvbiBmaXJzdCBibG9jayByZXF1ZXN0IGRlcGVuZHMgb24gd2hpY2ggSS1EIHlv dSByZWZlciB0byEpLCBhIHNlbnRlbmNlIGNvdWxkIGJlIGFkZGVkIGluIGJsb2NrLTAyIDsNCg0K PG9yaWdpbmFsIHRleHQ+DQpUaGUgZXJyb3IgY29kZSA0LjEzIChSZXF1ZXN0IEVudGl0eSBUb28g TGFyZ2UpIGNhbiBiZSByZXR1cm5lZCBhdCBhbnkgdGltZSBieSBhIHNlcnZlciB0aGF0IGRvZXMg bm90DQpjdXJyZW50bHkgaGF2ZSB0aGUgcmVzb3VyY2VzIHRvIHN0b3JlIGJsb2NrcyBmb3IgYSBi bG9jay13aXNlIFBVVCBvcg0KUE9TVCB0cmFuc2ZlciB0aGF0IGl0IHdvdWxkIGludGVuZCB0byBp bXBsZW1lbnQgaW4gYW4gYXRvbWljIGZhc2hpb24uDQoNCjxwcm9wb3NlZCBhZGRpdGlvbmFsIHRl eHQgPg0KVGhlIGVycm9yIGNvZGUgNC4xMyAoUmVxdWVzdCBFbnRpdHkgVG9vIExhcmdlKSBNQVkg YWxzbyBiZSByZXR1cm5lZCBieSBhIHNlcnZlciBpbiByZXNwb25zZSB0byBhIGZpcnN0IGJsb2Nr IHJlcXVlc3QgdG8gaW5kaWNhdGUgdGhhdCB0aGUgYmxvY2sgc2l6ZSBpcyBsYXJnZXIgdGhhbiBp dCBpcyBjdXJyZW50bHkgd2lsbGluZyB0byBoYW5kbGUsIG9yIHRoYXQgdGhlIGZpcnN0IGJsb2Nr IHJlcXVlc3QgcGF5bG9hZCB3YXMgdHJ1bmNhdGVkLCBldmVuIHRob3VnaCB0aGUgc2VydmVyIGRv ZXMgY3VycmVudGx5IGhhdmUgdGhlIHJlc291cmNlcyBmb3IgY29tcGxldGluZyB0aGUgaW50ZW5k ZWQgYmxvY2std2lzZSB0cmFuc2Zlci4gVGhlIGNsaWVudCBNQVkgdGhlbiByZXRyeSB0aGUgZmly c3QgYmxvY2sgcmVxdWVzdCB1c2luZyBhIHNtYWxsZXIgYmxvY2sgc2l6ZS4NCg0KYmVzdCByZWdh cmRzLA0KDQpFc2tvDQoNCg0KRnJvbTogTGlrZXBlbmcgW21haWx0bzpsaWtlcGVuZ0BodWF3ZWku Y29tXTxtYWlsdG86W21haWx0bzpsaWtlcGVuZ0BodWF3ZWkuY29tXT4NClNlbnQ6IE1vbmRheSAx MSBBcHJpbCAyMDExIDU6MjkNClRvOiBEaWprLCBFc2tvOyBjb3JlQGlldGYub3JnPG1haWx0bzpj b3JlQGlldGYub3JnPg0KU3ViamVjdDogUkU6IENvbWJpbmVkIDQuMTMgcmVzcG9uc2Ugd2l0aCBC bG9jayBPcHRpb24/DQoNClBlcnNvbmFsbHkgSSBkb26hr3QgdGhpbmsgaXQgaXMgcXVpdGUgdXNl ZnVsLiBCdXQgbGV0oa9zIGhlYXIgb3RoZXKhr3Mgb3Bpbmlvbi4NCg0KS2luZCBSZWdhcmRzDQpL ZXBlbmcNCkZyb206IERpamssIEVza28gW21haWx0bzplc2tvLmRpamtAcGhpbGlwcy5jb21dPG1h aWx0bzpbbWFpbHRvOmVza28uZGlqa0BwaGlsaXBzLmNvbV0+DQpTZW50OiBGcmlkYXksIEFwcmls IDA4LCAyMDExIDM6NTggUE0NClRvOiBMaWtlcGVuZzsgY29yZUBpZXRmLm9yZzxtYWlsdG86Y29y ZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBDb21iaW5lZCA0LjEzIHJlc3BvbnNlIHdpdGggQmxv Y2sgT3B0aW9uPw0KDQpEZWFyIEtlcGVuZywNCg0KdGhlcmUgYXJlIHByb2JhYmx5IG5vdCBtYW55 IHVzZSBjYXNlcyB0aGF0IHdvdWxkIHJlcXVpcmUgdGhpcyBmZWF0dXJlLiBIb3dldmVyIG15IHRo aW5raW5nIHdhcyB0aGF0IGJlY2F1c2UgaW1wbGVtZW50YXRpb24gb2YgdGhpcyBmZWF0dXJlICih sHJlc3BvbmQgNC4xMyB3aXRoIEJsb2NrIE9wdGlvbqGxKSBpcyBmdWxseSBvcHRpb25hbCBhdCBi b3RoIGNsaWVudCBhbmQgc2VydmVyIHNpZGVzLCBpdCB3b3VsZCBub3QgaHVydCB0byBpbmNsdWRl IGl0IGluIHRoZSBzcGVjID8NCg0KQW5kIEkgaGF2ZSBhIHVzZSBjYXNlIGluIG1pbmQ6IGEgd2ly ZWxlc3MgY29uc3RyYWluZWQgc2VydmVyIFMgdGhhdCBpcyBjb25uZWN0ZWQgdmlhIGEgc2xvdyBz ZXJpYWwgbGluayB0byBhIGxlZ2FjeSBkZXZpY2UsIHNheSAxMjAwIGJwcyBzaW1pbGFyIHRvIHRo ZSBEQUxJIHByb3RvY29sLiBUaGUgZmlybXdhcmUgb2YgdGhlIGxlZ2FjeSBkZXZpY2UgaXMgdG8g YmUgdXBkYXRlZCBpbiBibG9ja3MgdmlhIENvQVAsIHdoZXJlIFMgcmVsYXlzIHRoZSBkYXRhIHRo ZW4gb24gdG8gdGhlIHNlcmlhbCBsaW5lIHVzaW5nIGEgY3VzdG9tIHByb3RvY29sLiBOb3cgYSBj bGllbnQgbWlnaHQgZm9vbGlzaGx5IGRlY2lkZSB0byBzZW5kIGEgUFVUIHJlcXVlc3QgdG8gUyB3 aXRoIGEgMTAyNCBieXRlIGJsb2NrLiBTIGRvZXMgaGF2ZSBtZW1vcnkgdG8gdGVtcG9yYXJpbHkg YnVmZmVyIHRoZSBsYXJnZSAxMDI0IGJ5dGUgYmxvY2ssIGJ1dCBpdCB0YWtlcyB1cCB0b28gbXVj aCByZXNvdXJjZXMgZm9yIGEgdG9vIGxvbmcgdGltZS4gVG8gZ2V0IGEgc2ltcGxlIGltcGxlbWVu dGF0aW9uIGFuZCBndWFyYW50ZWVkIHJlbGlhYmxlIG9wZXJhdGlvbiBvZiBTIGR1cmluZyB0aGUg ZmlybXdhcmUgdXBkYXRlLCBTIHByZWZlcnMgNjQgYnl0ZSBibG9ja3MgYW5kIGRvZXMgbm90IHdh bnQgdG8ga2VlcCBsYXJnZSBibG9ja3MgaW4gbWVtb3J5LiAgSW4gdGhlIGN1cnJlbnQgQ29BUC1i bG9jayBkcmFmdCwgdGhlcmUgaXMgbm8gd2F5IGZvciBTIHRvIGluZGljYXRlIHRoaXM7IGN1cnJl bnRseSBpZiBJoa9tIGNvcnJlY3QgUyBjYW4gZWl0aGVyIDEpIHJlc3BvbmQgZXJyb3IgNC4xMyBv ciAyKSBBQ0sgd2l0aCBhIHN1Y2Nlc3MgY29kZSBhZnRlciBpdCBoYXMgcHJvY2Vzc2VkIHRoZSBl bnRpcmUgMTAyNCBieXRlIGZpcnN0IGJsb2NrLiAoYXMgaW4gRmlnIDkpDQoNCk9mIGNvdXJzZSBh bm90aGVyLCBlYXNpZXIsIHNvbHV0aW9uIGhlcmUgaXMgdGhhdCBhbGwgbXkgQ29BUCBjbGllbnRz IGFyZSBwcmUtY29uZmlndXJlZCB0byBvbmx5IHVzZSA2NC1ieXRlIGJsb2NrcyBpbiB0aGUgZmly c3QgcGxhY2UuIEJ1dCBpbiBhIG11bHRpLXZlbmRvciBzaXR1YXRpb24sIG9uZSBjYW4gbm90IGJl IHN1cmUgdGhhdCB0aGlzIHR5cGUgb2YgY29uZmlndXJhdGlvbiBpcyBwb3NzaWJsZSA7KQ0KDQpi ZXN0IHJlZ2FyZHMsDQpFc2tvDQoNCkZyb206IExpa2VwZW5nIFttYWlsdG86bGlrZXBlbmdAaHVh d2VpLmNvbV08bWFpbHRvOlttYWlsdG86bGlrZXBlbmdAaHVhd2VpLmNvbV0+DQpTZW50OiBUaHVy c2RheSA3IEFwcmlsIDIwMTEgMzowNg0KVG86IERpamssIEVza287IGNvcmVAaWV0Zi5vcmc8bWFp bHRvOmNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogQ29tYmluZWQgNC4xMyByZXNwb25zZSB3 aXRoIEJsb2NrIE9wdGlvbj8NCg0KPldoYXQgdGhlIHNlcnZlciBtYXliZSB3YW50cyB0byB0ZWxs IGlzIKGwSSBjYW4gcHJvY2VzcyA2NCBieXRlIGJsb2NrcyBhdCBtb3N0IGF0IGEgdGltZSwgaWYg eW91IHdhbnQgcmV0cnkgdGhpcyB3aXRoIGEgYmxvY2sgc2l6ZSA8PSA2NKGxLg0KSWYgdGhlIHNl cnZlciBjYW6hr3QgYWNjZXB0IDY0IGJ5dGUsIHdoaWNoIGlzIHBhcnQgb2YgdGhlIHJlc291cmNl LCB3aGF0IGlzIHRoZSB1c2UgY2FzZSB0byByZWNlaXZlIGFuIGV2ZW4gc21hbGxlciBwYXJ0IG9m IHRoZSByZXNvdXJjZT8NCg0KPlF1ZXN0aW9uIGlzOiBpcyBpdCBhbGxvd2VkIGZvciB0aGUgc2Vy dmVyIHRvIG9wdGlvbmFsbHkgaW5jbHVkZSBhIEJsb2NrIE9wdGlvbiBpbiBhIDQuMTMgZXJyb3Ig cmVzcG9uc2UsIHRvIGluZGljYXRlIHRoZSBtYXggYmxvY2sgc2l6ZSB0aGF0IGlzIHN1cHBvcnRl ZCA/DQpDdXJyZW50bHkgdGhlIGRyYWZ0IHN1cHBvcnRzIHRoZSBpbmRpY2F0aW9uIG9mIHByZWZl cnJlZCBibG9jayBzaXplIGluIHRoZSByZXNwb25zZSwgd2hpY2ggc2VlbXMgdG8gYmUgZW5vdWdo Lg0KDQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0Kt6K8/sjLOiBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5v cmddPG1haWx0bzpbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10+ILT6se0gRGlqaywgRXNr bw0Kt6LLzcqxvOQ6IDIwMTHE6jTUwjbI1SAyMjoxMg0KytW8/sjLOiBjb3JlQGlldGYub3JnPG1h aWx0bzpjb3JlQGlldGYub3JnPg0K1vfM4jogW2NvcmVdIENvbWJpbmVkIDQuMTMgcmVzcG9uc2Ug d2l0aCBCbG9jayBPcHRpb24/DQoNCkRlYXIgYWxsIC8gYXV0aG9ycyBvZiBibG9jay0wMiwNCg0K bG9va2luZyBhdCB0aGUgY29yZS1ibG9jay0wMiBkcmFmdDsgYSBzZXJ2ZXIgY2FuIGluZGljYXRl IGEgcHJlZmVycmVkIChlLmcuIHNtYWxsZXIpIGJsb2NrIHNpemUgdG8gYSBjbGllbnQgaW4gcmVz cG9uc2UgdG8gYSBibG9ja3dpc2UgUFVUIChzZWUgRmlndXJlIDkpLiBUaGlzIGlzIG5pY2UgYnV0 IHRoZSBleGFtcGxlcyAoaS5lLiBGaWcgOSkgc2hvdyBvbmx5IHRoZSBjYXNlIHRoYXQgdGhlIHNl cnZlciB3YXMgY2FwYWJsZSBvZiBwcm9jZXNzaW5nIHRoZSAgZW50aXJlIGZpcnN0IGJsb2NrIChv ZiAxMjggYnl0ZXMsIHdoaWNoIGlzIGxhcmdlciB0aGFuIHRoZSBzZXJ2ZXKhr3MgcHJlZmVyZW5j ZSkgY29ycmVjdGx5LiBXaGF0IGFib3V0IGEgY2FzZSB3aGVyZSB0aGUgc2VydmVyIGlzIG9ubHkg d2lsbGluZyB0byBwcm9jZXNzIHNtYWxsZXIgYmxvY2tzIGUuZy4gbWF4IDY0IGJ5dGVzIGF0IGEg dGltZT8gIE9mIGNvdXJzZSB0aGUgc2VydmVyIGNhbiByZXNwb25kIHdpdGggZXJyb3IgY29kZSA0 LjEzIGFzIGluZGljYXRlZCBpbiB0aGUgZHJhZnQuIEhvd2V2ZXIsIHRoZSBjbGllbnQgY291bGQg dW5kZXJzdGFuZCA0LjEzIGFzIKGwbm8gcmVzb3VyY2VzIGF0IHRoaXMgbW9tZW50IHRvIHN1cHBv cnQgYW55IG1vcmUgYmxvY2sgb3BlcmF0aW9uc6GxIGFuZCB0aGVuIGdpdmUgdXAuIFdoYXQgdGhl IHNlcnZlciBtYXliZSB3YW50cyB0byB0ZWxsIGlzIKGwSSBjYW4gcHJvY2VzcyA2NCBieXRlIGJs b2NrcyBhdCBtb3N0IGF0IGEgdGltZSwgaWYgeW91IHdhbnQgcmV0cnkgdGhpcyB3aXRoIGEgYmxv Y2sgc2l6ZSA8PSA2NKGxLg0KDQpRdWVzdGlvbiBpczogaXMgaXQgYWxsb3dlZCBmb3IgdGhlIHNl cnZlciB0byBvcHRpb25hbGx5IGluY2x1ZGUgYSBCbG9jayBPcHRpb24gaW4gYSA0LjEzIGVycm9y IHJlc3BvbnNlLCB0byBpbmRpY2F0ZSB0aGUgbWF4IGJsb2NrIHNpemUgdGhhdCBpcyBzdXBwb3J0 ZWQgPw0KDQpJIGFzc3VtZSBoZXJlIHRoYXQsIGV2ZW4gdGhvdWdoIGEgUFVUIHJlcXVlc3Qgd2Fz IGNvcnJlY3RseSByZWNlaXZlZCwgdGhlIHNlcnZlciBmb3Igc29tZSBpbXBsZW1lbnRhdGlvbiBy ZWFzb24gaXMgdW53aWxsaW5nIHRvIHByb2Nlc3MgYSBibG9jayB0aGF0IGxhcmdlIGluIG9uZSBn by4NCg0KYmVzdCByZWdhcmRzLA0KRXNrbyBEaWprDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkg YmUgY29uZmlkZW50aWFsIGFuZCBsZWdhbGx5IHByb3RlY3RlZCB1bmRlciBhcHBsaWNhYmxlIGxh dy4gVGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2VlKHMpLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3Rp ZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24sIG9yIHJlcHJvZHVj dGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVu bGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29u dGFjdCB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBv ZiB0aGUgb3JpZ2luYWwgbWVzc2FnZS4NCg== --Boundary_(ID_AODFbCJnfpUl31bu5cktCg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hi Esko,

 

You proposed text excludes one situation: during the transmission= , for example, after several blocks, the recipient finds out that it has no= storage for the rest of the blocks, then it returns 4.13: Request Entity Too Large.

 

>The error code 4.13 (Request Entity Too Large) MAY also= be returned by a server in response to a first block request to indicate t= hat the block size is larger than it is currently willing to handle

In this case, the server can return a smaller block size in the r= esponse, instead of an error code.

 

>or that the first block request payload was truncated, = even though the server does currently have the resources for completing the= intended block-wise transfer.

It is fine for the server to truncate the first block request pay= load. This is not an error.

 

Kind Regards

Kepeng

From: Dijk, Esko [mailto:= esko.dijk@philips.com]
Sent: Tuesday, April 19, 2011 5:29 PM
To: Likepeng; core@ietf.org
Subject: RE: Combined 4.13 response with Block Option?

 

Dear Ke= peng, all, authors,

&n= bsp;

a simpl= er alternative to what I proposed (=A1=B04.13 response with Block Option=A1= =B1) is for the server, who does not wish to accept a large block (even if = it is the first block of a sequence only), to use the 4.13 error response as specified in the coap-05 I-D, section 3.1.1.&nb= sp; This could be interpreted by the client as =A1=B0the request I sent was= too large=A1=B1 so the client may decide to try a smaller request message = (i.e. decrease the block size by some self-chosen amount).

&n= bsp;

No prot= ocol changes are required here, it=A1=AFs already in. To avoid confusion as= to what the 4.13 response means in this case (this case kind of falls betw= een coap-05 and block-02 currently =A8C the interpretation of 4.13 upon first block request depends on which I-D you refer to!), a se= ntence could be added in block-02 ;

&n= bsp;

<ori= ginal text>

The error = code 4.13 (Request Entity Too Large) can be returned at any time by a serve= r that does not

currently = have the resources to store blocks for a block-wise PUT or

POST transfer that it would in= tend to implement in an atomic fashion.

 

<proposed additional text &g= t;

The error code 4.13 (Request E= ntity Too Large) MAY also be returned by a server in response to a first bl= ock request to indicate that the block size is larger than it is currently willing to handle, or that the first block = request payload was truncated, even though the server does currently have t= he resources for completing the intended block-wise transfer. The client MA= Y then retry the first block request using a smaller block size.

 

best re= gards,

&n= bsp;

Esko

&n= bsp;

&n= bsp;

From: Likepeng [mailto:likepeng@huawei.com= ]
Sent: Monday 11 April 2011 5:29
To: Dijk, Esko; core@ietf.org Subject: RE: Combined 4.13 response with Block Option?

 

Personally I don=A1=AFt think it is quite useful. But let=A1=AFs = hear other=A1=AFs opinion.

 

Kind Regards

Kepeng

From: Dijk, Esko [mailto:esko.dijk@philips= .com]
Sent: Friday, April 08, 2011 3:58 PM
To: Likepeng; core@ietf.org
Subject: RE: Combined 4.13 response with Block Option?

 

Dear Ke= peng,

&n= bsp;

there a= re probably not many use cases that would require this feature. However my = thinking was that because implementation of this feature (=A1=B0respond 4.1= 3 with Block Option=A1=B1) is fully optional at both client and server sides, it would not hurt to include it in the spec = ?

&n= bsp;

And I h= ave a use case in mind: a wireless constrained server S that is connected v= ia a slow serial link to a legacy device, say 1200 bps similar to the DALI = protocol. The firmware of the legacy device is to be updated in blocks via CoAP, where S relays the data then on to th= e serial line using a custom protocol. Now a client might foolishly decide = to send a PUT request to S with a 1024 byte block. S does have memory to te= mporarily buffer the large 1024 byte block, but it takes up too much resources for a too long time. To get= a simple implementation and guaranteed reliable operation of S during the = firmware update, S prefers 64 byte blocks and does not want to keep large b= locks in memory.  In the current CoAP-block draft, there is no way for S to indicate this; currently if I= =A1=AFm correct S can either 1) respond error 4.13 or 2) ACK with a success= code after it has processed the entire 1024 byte first block. (as in Fig 9= )

&n= bsp;

Of cour= se another, easier, solution here is that all my CoAP clients are pre-confi= gured to only use 64-byte blocks in the first place. But in a multi-vendor = situation, one can not be sure that this type of configuration is possible ;)

&n= bsp;

best re= gards,

Esko

&n= bsp;

From: Likepeng [mailto:likepeng@huawei.com= ]
Sent: Thursday 7 April 2011 3:06
To: Dijk, Esko; core@ietf.org Subject: Re: Combined 4.13 response with Block Option?

 

>What the server maybe wants= to tell is =A1=B0I can process 64 byte blocks at most at a time, if you wa= nt retry this with a block size <=3D 64=A1=B1.

If the server can=A1=AFt accept 64 byte, which is part of the res= ource, what is the use case to receive an even smaller part of the resource= ?

 

>Question is: is it allowed = for the server to optionally include a Block Option in a 4.13 error respons= e, to indicate the max block size that is supported ? 

Currently the draft supports the indication of preferred block si= ze in the response, which seems to be enough.

 

Kind Regards

Kepeng

=B7=A2=BC=FE=C8=CB: core-bounces@ietf.org [mailto:core-bounces@ietf.org] =B4=FA=B1=ED Dijk, Esko
=B7=A2= =CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C26=C8=D5 22:12
=CA=D5=BC=FE=C8=CB: core@ietf.org
=D6=F7=CC=E2: [core] Combined 4.13 response with Block Option?=

 

Dear all / authors of block-02,=

 

looking at the core-block-02 dr= aft; a server can indicate a preferred (e.g. smaller) block size to a clien= t in response to a blockwise PUT (see Figure 9). This is nice but the examp= les (i.e. Fig 9) show only the case that the server was capable of processing the  entire first block (of= 128 bytes, which is larger than the server=A1=AFs preference) correctly. W= hat about a case where the server is only willing to process smaller blocks= e.g. max 64 bytes at a time?  Of course the server can respond with error code 4.13 as indicated in the draft. However= , the client could understand 4.13 as =A1=B0no resources at this moment to = support any more block operations=A1=B1 and then give up. What the server m= aybe wants to tell is =A1=B0I can process 64 byte blocks at most at a time, if you want retry this with a block size <=3D= 64=A1=B1.

 

Question is: is it allowed for = the server to optionally include a Block Option in a 4.13 error response, t= o indicate the max block size that is supported ? 

 

I assume here that, even though= a PUT request was correctly received, the server for some implementation r= eason is unwilling to process a block that large in one go.

 

best regards,=

Esko Dijk

 

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

--Boundary_(ID_AODFbCJnfpUl31bu5cktCg)-- From esko.dijk@philips.com Wed Apr 20 04:21:07 2011 Return-Path: X-Original-To: core@ietfc.amsl.com Delivered-To: core@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C05D2E0680 for ; Wed, 20 Apr 2011 04:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.537 X-Spam-Level: X-Spam-Status: No, score=0.537 tagged_above=-999 required=5 tests=[AWL=2.932, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsitopW1j1gM for ; Wed, 20 Apr 2011 04:21:05 -0700 (PDT) Received: from TX2EHSOBE009.bigfish.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfc.amsl.com (Postfix) with ESMTP id 50875E0682 for ; Wed, 20 Apr 2011 04:21:05 -0700 (PDT) Received: from mail93-tx2-R.bigfish.com (10.9.14.253) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.8; Wed, 20 Apr 2011 11:21:04 +0000 Received: from mail93-tx2 (localhost.localdomain [127.0.0.1]) by mail93-tx2-R.bigfish.com (Postfix) with ESMTP id AE128BD04D5; Wed, 20 Apr 2011 11:21:04 +0000 (UTC) X-SpamScore: -50 X-BigFish: VPS-50(zz217bL15d6O9251J9371O1be0L1432Nzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI Received: from mail93-tx2 (localhost.localdomain [127.0.0.1]) by mail93-tx2 (MessageSwitch) id 1303298463392621_3885; Wed, 20 Apr 2011 11:21:03 +0000 (UTC) Received: from TX2EHSMHS012.bigfish.com (unknown [10.9.14.252]) by mail93-tx2.bigfish.com (Postfix) with ESMTP id 52B43460051; Wed, 20 Apr 2011 11:21:03 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by TX2EHSMHS012.bigfish.com (10.9.99.112) with Microsoft SMTP Server (TLS) id 14.1.225.8; Wed, 20 Apr 2011 11:21:02 +0000 Received: from nlamsexh03.connect1.local (172.16.153.24) by connect1.philips.com (172.16.156.49) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 20 Apr 2011 13:20:34 +0200 Received: from NLCLUEXM03.connect1.local ([172.16.153.29]) by nlamsexh03.connect1.local ([172.16.153.24]) with mapi; Wed, 20 Apr 2011 13:20:25 +0200 From: "Dijk, Esko" To: Likepeng , "core@ietf.org" Date: Wed, 20 Apr 2011 13:20:23 +0200 Thread-Topic: Combined 4.13 response with Block Option? Thread-Index: AQHL/nSETKqXGLwIEEuujEVzqYzXI5Rl6xEAgACJylA= Message-ID: References: <34966E97BE8AD64EAE9D3D6E4DEE36F2280F85@SZXEML506-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F22828B7@SZXEML506-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F2283E66@SZXEML506-MBS.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F2283E66@SZXEML506-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A337AA36B3B96E4D853E6182B2F27AE2C76DC51C96NLCLUEXM03con_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [core] Combined 4.13 response with Block Option? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2011 11:21:07 -0000 --_000_A337AA36B3B96E4D853E6182B2F27AE2C76DC51C96NLCLUEXM03con_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8gS2VwZW5nLA0KDQo+IFlvdSBwcm9wb3NlZCB0ZXh0IGV4Y2x1ZGVzIG9uZSBzaXR1YXRp b246IGR1cmluZyB0aGUgdHJhbnNtaXNzaW9uLCBmb3IgZXhhbXBsZSwgYWZ0ZXIgc2V2ZXJhbCBi bG9ja3MsIHRoZSByZWNpcGllbnQgZmluZHMgb3V0IHRoYXQgaXQgaGFzIG5vIHN0b3JhZ2UgZm9y IHRoZSByZXN0IG9mIHRoZSBibG9ja3MsIHRoZW4gaXQgcmV0dXJucyA0LjEzOiBSZXF1ZXN0IEVu dGl0eSBUb28gTGFyZ2UuDQpUaGlzIGNhc2UgaXMgaW5kZWVkIG5vdCBjb3ZlcmVkIGJ5IG15IHRl eHQsIGJ1dCBieSB0aGUgb3JpZ2luYWwgdGV4dCAoSSBwcm9wb3NlIHRvIGxlYXZlIHRoYXQgaW4h KQ0KDQo+ID5UaGUgZXJyb3IgY29kZSA0LjEzIChSZXF1ZXN0IEVudGl0eSBUb28gTGFyZ2UpIE1B WSBhbHNvIGJlIHJldHVybmVkIGJ5IGEgc2VydmVyIGluIHJlc3BvbnNlIHRvIGEgZmlyc3QgYmxv Y2sgcmVxdWVzdCB0byBpbmRpY2F0ZSB0aGF0IHRoZSBibG9jayBzaXplIGlzIGxhcmdlciB0aGFu IGl0IGlzIGN1cnJlbnRseSB3aWxsaW5nIHRvIGhhbmRsZQ0KPiBJbiB0aGlzIGNhc2UsIHRoZSBz ZXJ2ZXIgY2FuIHJldHVybiBhIHNtYWxsZXIgYmxvY2sgc2l6ZSBpbiB0aGUgcmVzcG9uc2UsIGlu c3RlYWQgb2YgYW4gZXJyb3IgY29kZS4NClRoYXShr3MgdHJ1ZSwgYnV0IGluIHRoZSBjdXJyZW50 IGRlZmluaXRpb24gKKGwSW4gdGhlIHJlc3BvbnNlIGZvciBhIFBVVCBvciBQT1NULCB0aGUgQmxv Y2sgb3B0aW9uIGluZGljYXRlcyB3aGF0IGJsb2NrIG51bWJlciBpcyBiZWluZyBhY2tub3dsZWRn ZWQuobEpIHRoZSBibG9jayBvcHRpb24gYWxzbyBzZXJ2ZXMgYXMgYW4gYWNrbm93bGVkZ2VtZW50 LiBJZiB0aGUgc2VydmVyIGlzIG5vdCB3aWxsaW5nIHRvIGhhbmRsZS9hY2tub3dsZWRnZSB0aGlz IGZpcnN0IGJsb2NrLCBpdCBmb2xsb3dzIHRoYXQgdGhlIEJsb2NrIE9wdGlvbiBjYW6hr3QgYmUg dXNlZCBpbiB0aGUgcmVzcG9uc2UgZWl0aGVyLiAgSW4gYW55IGNhc2UgbXkgIHByb3Bvc2VkIHRl eHQgc2hvdWxkIGJlIG1hZGUgbW9yZSBjbGVhci4NCg0KPiA+b3IgdGhhdCB0aGUgZmlyc3QgYmxv Y2sgcmVxdWVzdCBwYXlsb2FkIHdhcyB0cnVuY2F0ZWQsIGV2ZW4gdGhvdWdoIHRoZSBzZXJ2ZXIg ZG9lcyBjdXJyZW50bHkgaGF2ZSB0aGUgcmVzb3VyY2VzIGZvciBjb21wbGV0aW5nIHRoZSBpbnRl bmRlZCBibG9jay13aXNlIHRyYW5zZmVyLg0KPiBJdCBpcyBmaW5lIGZvciB0aGUgc2VydmVyIHRv IHRydW5jYXRlIHRoZSBmaXJzdCBibG9jayByZXF1ZXN0IHBheWxvYWQuIFRoaXMgaXMgbm90IGFu IGVycm9yLg0KSWYgYSBzZXJ2ZXIgcmVjZWl2aW5nIGEgKGZpcnN0KSBibG9jayBmaW5kcyB0aGF0 IHRoZSBtZXNzYWdlIGluIGl0cyByZWNlaXZlIGJ1ZmZlciBpcyB0cnVuY2F0ZWQgKHRydW5jYXRp b24gY2FzZSBJIHRvb2sgZnJvbSBjb2FwLTA1KSwgdGhlIHByb2JsZW0gaXMgaXQgY2Fuoa90IGFj a25vd2xlZGdlIHRoZSBibG9jayBiZWNhdXNlIHBhcnQgb2YgdGhlIGRhdGEgaXMgbWlzc2luZy4g SGVuY2UsIGl0IGNhbm5vdCBzZW5kIGEgQmxvY2sgT3B0aW9uIHRvIGluZGljYXRlIGEgc21hbGxl ciBibG9jayBzaXplIGlzIG5lY2Vzc2FyeS4gSXQgY2FuIG9ubHkgcmVzcG9uZCB3aXRoIGVycm9y IDQuMTMgaW4gdGhpcyBjYXNlPyAgVGhlbiB0aGUgaXNzdWUgaXMgdGhhdCB0aGUgY2xpZW50IHJl Y2VpdmluZyB0aGUgNC4xMyByZXNwb25kIG1heSBub3Qga25vdyB3aGF0IHRoZSBzZXJ2ZXIgZXhh Y3RseSBtZWFucyBieSB0aGF0OyB0aGVyZSBhcmUgdHdvIHdheXMgb2YgIGludGVycHJldGF0aW9u LCBvbmUgZGVyaXZlZCBmcm9tIGNvYXAtMDUgYW5kIG9uZSBkZXJpdmVkIGZyb20gY29hcC1ibG9j ay0wMi4NCg0KYmVzdCByZWdhcmRzLA0KRXNrbw0KDQpGcm9tOiBMaWtlcGVuZyBbbWFpbHRvOmxp a2VwZW5nQGh1YXdlaS5jb21dDQpTZW50OiBXZWRuZXNkYXkgMjAgQXByaWwgMjAxMSAyOjU0DQpU bzogRGlqaywgRXNrbzsgY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IENvbWJpbmVkIDQuMTMg cmVzcG9uc2Ugd2l0aCBCbG9jayBPcHRpb24/DQoNCkhpIEVza28sDQoNCllvdSBwcm9wb3NlZCB0 ZXh0IGV4Y2x1ZGVzIG9uZSBzaXR1YXRpb246IGR1cmluZyB0aGUgdHJhbnNtaXNzaW9uLCBmb3Ig ZXhhbXBsZSwgYWZ0ZXIgc2V2ZXJhbCBibG9ja3MsIHRoZSByZWNpcGllbnQgZmluZHMgb3V0IHRo YXQgaXQgaGFzIG5vIHN0b3JhZ2UgZm9yIHRoZSByZXN0IG9mIHRoZSBibG9ja3MsIHRoZW4gaXQg cmV0dXJucyA0LjEzOiBSZXF1ZXN0IEVudGl0eSBUb28gTGFyZ2UuDQoNCj5UaGUgZXJyb3IgY29k ZSA0LjEzIChSZXF1ZXN0IEVudGl0eSBUb28gTGFyZ2UpIE1BWSBhbHNvIGJlIHJldHVybmVkIGJ5 IGEgc2VydmVyIGluIHJlc3BvbnNlIHRvIGEgZmlyc3QgYmxvY2sgcmVxdWVzdCB0byBpbmRpY2F0 ZSB0aGF0IHRoZSBibG9jayBzaXplIGlzIGxhcmdlciB0aGFuIGl0IGlzIGN1cnJlbnRseSB3aWxs aW5nIHRvIGhhbmRsZQ0KSW4gdGhpcyBjYXNlLCB0aGUgc2VydmVyIGNhbiByZXR1cm4gYSBzbWFs bGVyIGJsb2NrIHNpemUgaW4gdGhlIHJlc3BvbnNlLCBpbnN0ZWFkIG9mIGFuIGVycm9yIGNvZGUu DQoNCj5vciB0aGF0IHRoZSBmaXJzdCBibG9jayByZXF1ZXN0IHBheWxvYWQgd2FzIHRydW5jYXRl ZCwgZXZlbiB0aG91Z2ggdGhlIHNlcnZlciBkb2VzIGN1cnJlbnRseSBoYXZlIHRoZSByZXNvdXJj ZXMgZm9yIGNvbXBsZXRpbmcgdGhlIGludGVuZGVkIGJsb2NrLXdpc2UgdHJhbnNmZXIuDQpJdCBp cyBmaW5lIGZvciB0aGUgc2VydmVyIHRvIHRydW5jYXRlIHRoZSBmaXJzdCBibG9jayByZXF1ZXN0 IHBheWxvYWQuIFRoaXMgaXMgbm90IGFuIGVycm9yLg0KDQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0K RnJvbTogRGlqaywgRXNrbyBbbWFpbHRvOmVza28uZGlqa0BwaGlsaXBzLmNvbV0NClNlbnQ6IFR1 ZXNkYXksIEFwcmlsIDE5LCAyMDExIDU6MjkgUE0NClRvOiBMaWtlcGVuZzsgY29yZUBpZXRmLm9y Zw0KU3ViamVjdDogUkU6IENvbWJpbmVkIDQuMTMgcmVzcG9uc2Ugd2l0aCBCbG9jayBPcHRpb24/ DQoNCkRlYXIgS2VwZW5nLCBhbGwsIGF1dGhvcnMsDQoNCmEgc2ltcGxlciBhbHRlcm5hdGl2ZSB0 byB3aGF0IEkgcHJvcG9zZWQgKKGwNC4xMyByZXNwb25zZSB3aXRoIEJsb2NrIE9wdGlvbqGxKSBp cyBmb3IgdGhlIHNlcnZlciwgd2hvIGRvZXMgbm90IHdpc2ggdG8gYWNjZXB0IGEgbGFyZ2UgYmxv Y2sgKGV2ZW4gaWYgaXQgaXMgdGhlIGZpcnN0IGJsb2NrIG9mIGEgc2VxdWVuY2Ugb25seSksIHRv IHVzZSB0aGUgNC4xMyBlcnJvciByZXNwb25zZSBhcyBzcGVjaWZpZWQgaW4gdGhlIGNvYXAtMDUg SS1ELCBzZWN0aW9uIDMuMS4xLiAgVGhpcyBjb3VsZCBiZSBpbnRlcnByZXRlZCBieSB0aGUgY2xp ZW50IGFzIKGwdGhlIHJlcXVlc3QgSSBzZW50IHdhcyB0b28gbGFyZ2WhsSBzbyB0aGUgY2xpZW50 IG1heSBkZWNpZGUgdG8gdHJ5IGEgc21hbGxlciByZXF1ZXN0IG1lc3NhZ2UgKGkuZS4gZGVjcmVh c2UgdGhlIGJsb2NrIHNpemUgYnkgc29tZSBzZWxmLWNob3NlbiBhbW91bnQpLg0KDQpObyBwcm90 b2NvbCBjaGFuZ2VzIGFyZSByZXF1aXJlZCBoZXJlLCBpdKGvcyBhbHJlYWR5IGluLiBUbyBhdm9p ZCBjb25mdXNpb24gYXMgdG8gd2hhdCB0aGUgNC4xMyByZXNwb25zZSBtZWFucyBpbiB0aGlzIGNh c2UgKHRoaXMgY2FzZSBraW5kIG9mIGZhbGxzIGJldHdlZW4gY29hcC0wNSBhbmQgYmxvY2stMDIg Y3VycmVudGx5IKhDIHRoZSBpbnRlcnByZXRhdGlvbiBvZiA0LjEzIHVwb24gZmlyc3QgYmxvY2sg cmVxdWVzdCBkZXBlbmRzIG9uIHdoaWNoIEktRCB5b3UgcmVmZXIgdG8hKSwgYSBzZW50ZW5jZSBj b3VsZCBiZSBhZGRlZCBpbiBibG9jay0wMiA7DQoNCjxvcmlnaW5hbCB0ZXh0Pg0KVGhlIGVycm9y IGNvZGUgNC4xMyAoUmVxdWVzdCBFbnRpdHkgVG9vIExhcmdlKSBjYW4gYmUgcmV0dXJuZWQgYXQg YW55IHRpbWUgYnkgYSBzZXJ2ZXIgdGhhdCBkb2VzIG5vdA0KY3VycmVudGx5IGhhdmUgdGhlIHJl c291cmNlcyB0byBzdG9yZSBibG9ja3MgZm9yIGEgYmxvY2std2lzZSBQVVQgb3INClBPU1QgdHJh bnNmZXIgdGhhdCBpdCB3b3VsZCBpbnRlbmQgdG8gaW1wbGVtZW50IGluIGFuIGF0b21pYyBmYXNo aW9uLg0KDQo8cHJvcG9zZWQgYWRkaXRpb25hbCB0ZXh0ID4NClRoZSBlcnJvciBjb2RlIDQuMTMg KFJlcXVlc3QgRW50aXR5IFRvbyBMYXJnZSkgTUFZIGFsc28gYmUgcmV0dXJuZWQgYnkgYSBzZXJ2 ZXIgaW4gcmVzcG9uc2UgdG8gYSBmaXJzdCBibG9jayByZXF1ZXN0IHRvIGluZGljYXRlIHRoYXQg dGhlIGJsb2NrIHNpemUgaXMgbGFyZ2VyIHRoYW4gaXQgaXMgY3VycmVudGx5IHdpbGxpbmcgdG8g aGFuZGxlLCBvciB0aGF0IHRoZSBmaXJzdCBibG9jayByZXF1ZXN0IHBheWxvYWQgd2FzIHRydW5j YXRlZCwgZXZlbiB0aG91Z2ggdGhlIHNlcnZlciBkb2VzIGN1cnJlbnRseSBoYXZlIHRoZSByZXNv dXJjZXMgZm9yIGNvbXBsZXRpbmcgdGhlIGludGVuZGVkIGJsb2NrLXdpc2UgdHJhbnNmZXIuIFRo ZSBjbGllbnQgTUFZIHRoZW4gcmV0cnkgdGhlIGZpcnN0IGJsb2NrIHJlcXVlc3QgdXNpbmcgYSBz bWFsbGVyIGJsb2NrIHNpemUuDQoNCmJlc3QgcmVnYXJkcywNCg0KRXNrbw0KDQoNCkZyb206IExp a2VwZW5nIFttYWlsdG86bGlrZXBlbmdAaHVhd2VpLmNvbV08bWFpbHRvOlttYWlsdG86bGlrZXBl bmdAaHVhd2VpLmNvbV0+DQpTZW50OiBNb25kYXkgMTEgQXByaWwgMjAxMSA1OjI5DQpUbzogRGlq aywgRXNrbzsgY29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJF OiBDb21iaW5lZCA0LjEzIHJlc3BvbnNlIHdpdGggQmxvY2sgT3B0aW9uPw0KDQpQZXJzb25hbGx5 IEkgZG9uoa90IHRoaW5rIGl0IGlzIHF1aXRlIHVzZWZ1bC4gQnV0IGxldKGvcyBoZWFyIG90aGVy oa9zIG9waW5pb24uDQoNCktpbmQgUmVnYXJkcw0KS2VwZW5nDQpGcm9tOiBEaWprLCBFc2tvIFtt YWlsdG86ZXNrby5kaWprQHBoaWxpcHMuY29tXTxtYWlsdG86W21haWx0bzplc2tvLmRpamtAcGhp bGlwcy5jb21dPg0KU2VudDogRnJpZGF5LCBBcHJpbCAwOCwgMjAxMSAzOjU4IFBNDQpUbzogTGlr ZXBlbmc7IGNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTog Q29tYmluZWQgNC4xMyByZXNwb25zZSB3aXRoIEJsb2NrIE9wdGlvbj8NCg0KRGVhciBLZXBlbmcs DQoNCnRoZXJlIGFyZSBwcm9iYWJseSBub3QgbWFueSB1c2UgY2FzZXMgdGhhdCB3b3VsZCByZXF1 aXJlIHRoaXMgZmVhdHVyZS4gSG93ZXZlciBteSB0aGlua2luZyB3YXMgdGhhdCBiZWNhdXNlIGlt cGxlbWVudGF0aW9uIG9mIHRoaXMgZmVhdHVyZSAoobByZXNwb25kIDQuMTMgd2l0aCBCbG9jayBP cHRpb26hsSkgaXMgZnVsbHkgb3B0aW9uYWwgYXQgYm90aCBjbGllbnQgYW5kIHNlcnZlciBzaWRl cywgaXQgd291bGQgbm90IGh1cnQgdG8gaW5jbHVkZSBpdCBpbiB0aGUgc3BlYyA/DQoNCkFuZCBJ IGhhdmUgYSB1c2UgY2FzZSBpbiBtaW5kOiBhIHdpcmVsZXNzIGNvbnN0cmFpbmVkIHNlcnZlciBT IHRoYXQgaXMgY29ubmVjdGVkIHZpYSBhIHNsb3cgc2VyaWFsIGxpbmsgdG8gYSBsZWdhY3kgZGV2 aWNlLCBzYXkgMTIwMCBicHMgc2ltaWxhciB0byB0aGUgREFMSSBwcm90b2NvbC4gVGhlIGZpcm13 YXJlIG9mIHRoZSBsZWdhY3kgZGV2aWNlIGlzIHRvIGJlIHVwZGF0ZWQgaW4gYmxvY2tzIHZpYSBD b0FQLCB3aGVyZSBTIHJlbGF5cyB0aGUgZGF0YSB0aGVuIG9uIHRvIHRoZSBzZXJpYWwgbGluZSB1 c2luZyBhIGN1c3RvbSBwcm90b2NvbC4gTm93IGEgY2xpZW50IG1pZ2h0IGZvb2xpc2hseSBkZWNp ZGUgdG8gc2VuZCBhIFBVVCByZXF1ZXN0IHRvIFMgd2l0aCBhIDEwMjQgYnl0ZSBibG9jay4gUyBk b2VzIGhhdmUgbWVtb3J5IHRvIHRlbXBvcmFyaWx5IGJ1ZmZlciB0aGUgbGFyZ2UgMTAyNCBieXRl IGJsb2NrLCBidXQgaXQgdGFrZXMgdXAgdG9vIG11Y2ggcmVzb3VyY2VzIGZvciBhIHRvbyBsb25n IHRpbWUuIFRvIGdldCBhIHNpbXBsZSBpbXBsZW1lbnRhdGlvbiBhbmQgZ3VhcmFudGVlZCByZWxp YWJsZSBvcGVyYXRpb24gb2YgUyBkdXJpbmcgdGhlIGZpcm13YXJlIHVwZGF0ZSwgUyBwcmVmZXJz IDY0IGJ5dGUgYmxvY2tzIGFuZCBkb2VzIG5vdCB3YW50IHRvIGtlZXAgbGFyZ2UgYmxvY2tzIGlu IG1lbW9yeS4gIEluIHRoZSBjdXJyZW50IENvQVAtYmxvY2sgZHJhZnQsIHRoZXJlIGlzIG5vIHdh eSBmb3IgUyB0byBpbmRpY2F0ZSB0aGlzOyBjdXJyZW50bHkgaWYgSaGvbSBjb3JyZWN0IFMgY2Fu IGVpdGhlciAxKSByZXNwb25kIGVycm9yIDQuMTMgb3IgMikgQUNLIHdpdGggYSBzdWNjZXNzIGNv ZGUgYWZ0ZXIgaXQgaGFzIHByb2Nlc3NlZCB0aGUgZW50aXJlIDEwMjQgYnl0ZSBmaXJzdCBibG9j ay4gKGFzIGluIEZpZyA5KQ0KDQpPZiBjb3Vyc2UgYW5vdGhlciwgZWFzaWVyLCBzb2x1dGlvbiBo ZXJlIGlzIHRoYXQgYWxsIG15IENvQVAgY2xpZW50cyBhcmUgcHJlLWNvbmZpZ3VyZWQgdG8gb25s eSB1c2UgNjQtYnl0ZSBibG9ja3MgaW4gdGhlIGZpcnN0IHBsYWNlLiBCdXQgaW4gYSBtdWx0aS12 ZW5kb3Igc2l0dWF0aW9uLCBvbmUgY2FuIG5vdCBiZSBzdXJlIHRoYXQgdGhpcyB0eXBlIG9mIGNv bmZpZ3VyYXRpb24gaXMgcG9zc2libGUgOykNCg0KYmVzdCByZWdhcmRzLA0KRXNrbw0KDQpGcm9t OiBMaWtlcGVuZyBbbWFpbHRvOmxpa2VwZW5nQGh1YXdlaS5jb21dPG1haWx0bzpbbWFpbHRvOmxp a2VwZW5nQGh1YXdlaS5jb21dPg0KU2VudDogVGh1cnNkYXkgNyBBcHJpbCAyMDExIDM6MDYNClRv OiBEaWprLCBFc2tvOyBjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3JnPg0KU3ViamVj dDogUmU6IENvbWJpbmVkIDQuMTMgcmVzcG9uc2Ugd2l0aCBCbG9jayBPcHRpb24/DQoNCj5XaGF0 IHRoZSBzZXJ2ZXIgbWF5YmUgd2FudHMgdG8gdGVsbCBpcyChsEkgY2FuIHByb2Nlc3MgNjQgYnl0 ZSBibG9ja3MgYXQgbW9zdCBhdCBhIHRpbWUsIGlmIHlvdSB3YW50IHJldHJ5IHRoaXMgd2l0aCBh IGJsb2NrIHNpemUgPD0gNjShsS4NCklmIHRoZSBzZXJ2ZXIgY2Fuoa90IGFjY2VwdCA2NCBieXRl LCB3aGljaCBpcyBwYXJ0IG9mIHRoZSByZXNvdXJjZSwgd2hhdCBpcyB0aGUgdXNlIGNhc2UgdG8g cmVjZWl2ZSBhbiBldmVuIHNtYWxsZXIgcGFydCBvZiB0aGUgcmVzb3VyY2U/DQoNCj5RdWVzdGlv biBpczogaXMgaXQgYWxsb3dlZCBmb3IgdGhlIHNlcnZlciB0byBvcHRpb25hbGx5IGluY2x1ZGUg YSBCbG9jayBPcHRpb24gaW4gYSA0LjEzIGVycm9yIHJlc3BvbnNlLCB0byBpbmRpY2F0ZSB0aGUg bWF4IGJsb2NrIHNpemUgdGhhdCBpcyBzdXBwb3J0ZWQgPw0KQ3VycmVudGx5IHRoZSBkcmFmdCBz dXBwb3J0cyB0aGUgaW5kaWNhdGlvbiBvZiBwcmVmZXJyZWQgYmxvY2sgc2l6ZSBpbiB0aGUgcmVz cG9uc2UsIHdoaWNoIHNlZW1zIHRvIGJlIGVub3VnaC4NCg0KS2luZCBSZWdhcmRzDQpLZXBlbmcN CreivP7IyzogY29yZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5v cmc+IFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXTxtYWlsdG86W21haWx0bzpjb3JlLWJv dW5jZXNAaWV0Zi5vcmddPiC0+rHtIERpamssIEVza28NCreiy83KsbzkOiAyMDExxOo01MI2yNUg MjI6MTINCsrVvP7IyzogY29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4NCtb3zOI6 IFtjb3JlXSBDb21iaW5lZCA0LjEzIHJlc3BvbnNlIHdpdGggQmxvY2sgT3B0aW9uPw0KDQpEZWFy IGFsbCAvIGF1dGhvcnMgb2YgYmxvY2stMDIsDQoNCmxvb2tpbmcgYXQgdGhlIGNvcmUtYmxvY2st MDIgZHJhZnQ7IGEgc2VydmVyIGNhbiBpbmRpY2F0ZSBhIHByZWZlcnJlZCAoZS5nLiBzbWFsbGVy KSBibG9jayBzaXplIHRvIGEgY2xpZW50IGluIHJlc3BvbnNlIHRvIGEgYmxvY2t3aXNlIFBVVCAo c2VlIEZpZ3VyZSA5KS4gVGhpcyBpcyBuaWNlIGJ1dCB0aGUgZXhhbXBsZXMgKGkuZS4gRmlnIDkp IHNob3cgb25seSB0aGUgY2FzZSB0aGF0IHRoZSBzZXJ2ZXIgd2FzIGNhcGFibGUgb2YgcHJvY2Vz c2luZyB0aGUgIGVudGlyZSBmaXJzdCBibG9jayAob2YgMTI4IGJ5dGVzLCB3aGljaCBpcyBsYXJn ZXIgdGhhbiB0aGUgc2VydmVyoa9zIHByZWZlcmVuY2UpIGNvcnJlY3RseS4gV2hhdCBhYm91dCBh IGNhc2Ugd2hlcmUgdGhlIHNlcnZlciBpcyBvbmx5IHdpbGxpbmcgdG8gcHJvY2VzcyBzbWFsbGVy IGJsb2NrcyBlLmcuIG1heCA2NCBieXRlcyBhdCBhIHRpbWU/ICBPZiBjb3Vyc2UgdGhlIHNlcnZl ciBjYW4gcmVzcG9uZCB3aXRoIGVycm9yIGNvZGUgNC4xMyBhcyBpbmRpY2F0ZWQgaW4gdGhlIGRy YWZ0LiBIb3dldmVyLCB0aGUgY2xpZW50IGNvdWxkIHVuZGVyc3RhbmQgNC4xMyBhcyChsG5vIHJl c291cmNlcyBhdCB0aGlzIG1vbWVudCB0byBzdXBwb3J0IGFueSBtb3JlIGJsb2NrIG9wZXJhdGlv bnOhsSBhbmQgdGhlbiBnaXZlIHVwLiBXaGF0IHRoZSBzZXJ2ZXIgbWF5YmUgd2FudHMgdG8gdGVs bCBpcyChsEkgY2FuIHByb2Nlc3MgNjQgYnl0ZSBibG9ja3MgYXQgbW9zdCBhdCBhIHRpbWUsIGlm IHlvdSB3YW50IHJldHJ5IHRoaXMgd2l0aCBhIGJsb2NrIHNpemUgPD0gNjShsS4NCg0KUXVlc3Rp b24gaXM6IGlzIGl0IGFsbG93ZWQgZm9yIHRoZSBzZXJ2ZXIgdG8gb3B0aW9uYWxseSBpbmNsdWRl IGEgQmxvY2sgT3B0aW9uIGluIGEgNC4xMyBlcnJvciByZXNwb25zZSwgdG8gaW5kaWNhdGUgdGhl IG1heCBibG9jayBzaXplIHRoYXQgaXMgc3VwcG9ydGVkID8NCg0KSSBhc3N1bWUgaGVyZSB0aGF0 LCBldmVuIHRob3VnaCBhIFBVVCByZXF1ZXN0IHdhcyBjb3JyZWN0bHkgcmVjZWl2ZWQsIHRoZSBz ZXJ2ZXIgZm9yIHNvbWUgaW1wbGVtZW50YXRpb24gcmVhc29uIGlzIHVud2lsbGluZyB0byBwcm9j ZXNzIGEgYmxvY2sgdGhhdCBsYXJnZSBpbiBvbmUgZ28uDQoNCmJlc3QgcmVnYXJkcywNCkVza28g RGlqaw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVGhlIGluZm9ybWF0aW9u IGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVnYWxs eSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGljYWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVk IHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdXNlLCBmb3J3YXJk aW5nLCBkaXNzZW1pbmF0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0 cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1cm4g ZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQo= --_000_A337AA36B3B96E4D853E6182B2F27AE2C76DC51C96NLCLUEXM03con_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hello Kepeng,

 

<= span style=3D'font-size:10.5pt;color:#1F497D'>> You proposed text exclud= es one situation: during the transmission, for example, after several block= s, the recipient finds out that it has no storage for the rest of the block= s, then it returns 4.13: Request Entity Too Large.

This case= is indeed not covered by my text, but by the original text (I propose to l= eave that in!)

 

> >The error code 4.13 (Request = Entity Too Large) MAY also be returned by a server in response to a first b= lock request to indicate that the block size is larger than it is currently= willing to handle

> In this case, the server can return a smaller block size i= n the response, instead of an error code.

That=A1=AFs true, = but in the current definition (=A1=B0In the response for a PUT or POST, the= Block option indicates what block number is being acknowledged.=A1=B1) the= block option also serves as an acknowledgement. If the server is not willi= ng to handle/acknowledge this first block, it follows that the Block Option= can=A1=AFt be used in the response either.  In any case my  prop= osed text should be made more clear.

 =

>= ; >or that t= he first block request payload was truncated, even though the server does c= urrently have the resources for completing the intended block-wise transfer= .

> = It is fine for the server to truncate the first block request payload. This= is not an error.

If a server receiving a (first) block finds that the message= in its receive buffer is truncated (truncation case I took from coap-05), = the problem is it can=A1=AFt acknowledge the block because part of the data= is missing. Hence, it cannot send a Block Option to indicate a smaller blo= ck size is necessary. It can only respond with error 4.13 in this case?&nbs= p; Then the issue is that the client receiving the 4.13 respond may not kno= w what the server exactly means by that; there are two ways of  interp= retation, one derived from coap-05 and one derived from coap-block-02.=

&n= bsp;

bes= t regards,

Esko

 

From: Likepeng [mailto:likepeng@huawei.com]
Sent: Wednesday 20 April= 2011 2:54
To: Dijk, Esko; core@ietf.org
Subject: RE: C= ombined 4.13 response with Block Option?

<= p class=3DMsoNormal> 

Hi Esko,

 

You proposed text excludes one situation: during the transmission, fo= r example, after several blocks, the recipient finds out that it has no sto= rage for the rest of the blocks, then it returns 4.13: Request Entity Too L= arge.

 

>The error code 4.13 (Re= quest Entity Too Large) MAY also be returned by a server in response to a f= irst block request to indicate that the block size is larger than it is cur= rently willing to handle

In this case, the server can return a smaller block size = in the response, instead of an error code.

 

>or that the first block request payload was truncated, even= though the server does currently have the resources for completing the int= ended block-wise transfer.

It is fine for the server to truncate the first block r= equest payload. This is not an error.

 

Ki= nd Regards

Kepeng

From: Dijk, Esko [mailto:esko.dijk@philips.com]
Sent:= Tuesday, April 19, 2011 5:29 PM
To: Likepeng; core@ietf.org
<= b>Subject: RE: Combined 4.13 response with Block Option?

 

Dear Kepeng, all, authors,<= /span>

 

a simpler = alternative to what I proposed (=A1=B04.13 response with Block Option=A1=B1= ) is for the server, who does not wish to accept a large block (even if it = is the first block of a sequence only), to use the 4.13 error response as s= pecified in the coap-05 I-D, section 3.1.1.  This could be interpreted= by the client as =A1=B0the request I sent was too large=A1=B1 so the clien= t may decide to try a smaller request message (i.e. decrease the block size= by some self-chosen amount).

 

No protocol changes are required here, it=A1= =AFs already in. To avoid confusion as to what the 4.13 response means in t= his case (this case kind of falls between coap-05 and block-02 currently = =A8C the interpretation of 4.13 upon first block request depends on which I= -D you refer to!), a sentence could be added in block-02 ;

 

<original te= xt>

The error code 4.13 (Request Entity Too Large) can be returned at any time= by a server that does not

currently have the resources to store blocks for a bl= ock-wise PUT or

POST trans= fer that it would intend to implement in an atomic fashion.

 

<pr= oposed additional text >

The e= rror code 4.13 (Request Entity Too Large) MAY also be returned by a server = in response to a first block request to indicate that the block size is lar= ger than it is currently willing to handle, or that the first block request= payload was truncated, even though the server does currently have the reso= urces for completing the intended block-wise transfer. The client MAY then = retry the first block request using a smaller block size.

 

best regards,

 

Esko

 

<= span style=3D'color:#1F497D'> 

From: Likepeng [mailto:likepeng@huawei.com]
Sent: Monday 11 April 2011 5= :29
To: Dijk, Esko; core@ietf.or= g
Subject: RE: Combined 4.13 response with Block Option?=

 

Personally = I don=A1=AFt think it is quite useful. But let=A1=AFs hear other=A1=AFs opi= nion.

 

Kind Regards

=

Kepeng<= o:p>

From: Dijk, Esko [mailto:esko.dijk@philips.com= ]
Sent: Friday, April 08, 2011 3:58 PM
To: Likepen= g; core@ietf.org
Subject: RE= : Combined 4.13 response with Block Option?

 

Dear Kepeng,

=  

there are probably not many use cases tha= t would require this feature. However my thinking was that because implemen= tation of this feature (=A1=B0respond 4.13 with Block Option=A1=B1) is full= y optional at both client and server sides, it would not hurt to include it= in the spec ?

 

And I have a use case in mind: a wireless constrained serve= r S that is connected via a slow serial link to a legacy device, say 1200 b= ps similar to the DALI protocol. The firmware of the legacy device is to be= updated in blocks via CoAP, where S relays the data then on to the serial = line using a custom protocol. Now a client might foolishly decide to send a= PUT request to S with a 1024 byte block. S does have memory to temporarily= buffer the large 1024 byte block, but it takes up too much resources for a= too long time. To get a simple implementation and guaranteed reliable oper= ation of S during the firmware update, S prefers 64 byte blocks and does no= t want to keep large blocks in memory.  In the current CoAP-block draf= t, there is no way for S to indicate this; currently if I=A1=AFm correct S = can either 1) respond error 4.13 or 2) ACK with a success code after it has= processed the entire 1024 byte first block. (as in Fig 9)

 

Of course anoth= er, easier, solution here is that all my CoAP clients are pre-configured to= only use 64-byte blocks in the first place. But in a multi-vendor situatio= n, one can not be sure that this type of configuration is possible ;)<= /o:p>

&nb= sp;

best= regards,

Esko

 

= From:= Likepeng [mailto:likepeng@= huawei.com]
Sent: Thursday 7 April 2011 3:06
To: D= ijk, Esko; core@ietf.org
Subject= : Re: Combined 4.13 response with Block Option?

 

&g= t;What the server maybe wants to tell is =A1=B0I can process 64 byte blocks= at most at a time, if you want retry this with a block size <=3D 64=A1= =B1.

If the se= rver can=A1=AFt accept 64 byte, which is part of the resource, what is the = use case to receive an even smaller part of the resource?=

 

>Question is: is it allowe= d for the server to optionally include a Block Option in a 4.13 error respo= nse, to indicate the max block size that is supported ? 

Curre= ntly the draft supports the indication of preferred block size in the respo= nse, which seems to be enough.

 

Kind Rega= rds

Kepeng

= =B7=A2=BC=FE=C8=CB: <= a href=3D"mailto:core-bounces@ietf.org">core-bounces@ietf.org [mailto:core-bounces@ietf.org] =B4=FA=B1=ED Dijk, Esko
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA4=D4=C26=C8=D5 22:12=
=CA=D5=BC=FE=C8=CB: core@ietf.org
=D6=F7=CC=E2: [core] Combined 4.13 resp= onse with Block Option?

 

Dear all / authors of block-02= ,

 

looking at the core-block-02 draft; a server can indicate a preferred (= e.g. smaller) block size to a client in response to a blockwise PUT (see Fi= gure 9). This is nice but the examples (i.e. Fig 9) show only the case that= the server was capable of processing the  entire first block (of 128 = bytes, which is larger than the server=A1=AFs preference) correctly. What a= bout a case where the server is only willing to process smaller blocks e.g.= max 64 bytes at a time?  Of course the server can respond with error = code 4.13 as indicated in the draft. However, the client could understand 4= .13 as =A1=B0no resources at this moment to support any more block operatio= ns=A1=B1 and then give up. What the server maybe wants to tell is =A1=B0I c= an process 64 byte blocks at most at a time, if you want retry this with a = block size <=3D 64=A1=B1.

 = ;

Question is: is it allowed for the server t= o optionally include a Block Option in a 4.13 error response, to indicate t= he max block size that is supported ? 

 

I assume here that, even tho= ugh a PUT request was correctly received, the server for some implementatio= n reason is unwilling to process a block that large in one go.

 

best regar= ds,

Esko Dijk

 

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

= --_000_A337AA36B3B96E4D853E6182B2F27AE2C76DC51C96NLCLUEXM03con_-- From trac+core@trac.tools.ietf.org Fri Apr 22 03:32:30 2011 Return-Path: X-Original-To: core@ietfc.amsl.com Delivered-To: core@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4E7E0E0679 for ; Fri, 22 Apr 2011 03:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RPC9MMUUGjX for ; Fri, 22 Apr 2011 03:32:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 9DE6AE0674 for ; Fri, 22 Apr 2011 03:32:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QDDf1-0001Nt-2Y; Fri, 22 Apr 2011 03:32:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Fri, 22 Apr 2011 10:32:27 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/101#comment:4 Message-ID: <062.410da1e31161be2fbac509d8b203b6aa@trac.tools.ietf.org> References: <053.4ee873d7ebb8f94277f774e4b089aa27@trac.tools.ietf.org> X-Trac-Ticket-ID: 101 In-Reply-To: <053.4ee873d7ebb8f94277f774e4b089aa27@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #101: Review media type registry X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 22 Apr 2011 10:32:30 -0000 #101: Review media type registry Changes (by zach@…): * owner: => zach@… -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: zach@… Type: task | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: ----------------------------+----------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Fri Apr 22 03:33:38 2011 Return-Path: X-Original-To: core@ietfc.amsl.com Delivered-To: core@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 07C66E0679 for ; Fri, 22 Apr 2011 03:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5Qj3VqFH7O5 for ; Fri, 22 Apr 2011 03:33:37 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 6FB8DE0674 for ; Fri, 22 Apr 2011 03:33:37 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QDDg6-0003gW-K5; Fri, 22 Apr 2011 03:33:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartke@tzi.org, angelo@castellani.net, zach@sensinode.com X-Trac-Project: core Date: Fri, 22 Apr 2011 10:33:34 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/132#comment:2 Message-ID: <062.b9aaa1f30447e430839b30f2608fa9d1@trac.tools.ietf.org> References: <053.23fd175ad3e8fb1a4a7303089729c32f@trac.tools.ietf.org> X-Trac-Ticket-ID: 132 In-Reply-To: <053.23fd175ad3e8fb1a4a7303089729c32f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, angelo@castellani.net, zach@sensinode.com, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #132: Separate response implicitly acks confirmable request X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 22 Apr 2011 10:33:38 -0000 #132: Separate response implicitly acks confirmable request Changes (by zach@…): * owner: => hartke@… -- --------------------------------+------------------------------------------- Reporter: hartke@… | Owner: hartke@… Type: editorial | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Fri Apr 22 04:54:00 2011 Return-Path: X-Original-To: core@ietfc.amsl.com Delivered-To: core@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 82179E06B6 for ; Fri, 22 Apr 2011 04:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiAAe1aeWgmB for ; Fri, 22 Apr 2011 04:54:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id F0685E06B1 for ; Fri, 22 Apr 2011 04:53:59 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QDEvs-00062I-7t; Fri, 22 Apr 2011 04:53:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hartke@tzi.org, angelo@castellani.net, cabo@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Fri, 22 Apr 2011 11:53:56 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/132#comment:3 Message-ID: <062.d0aa10b4a6f4cef620e5a2489ff80ec9@trac.tools.ietf.org> References: <053.23fd175ad3e8fb1a4a7303089729c32f@trac.tools.ietf.org> X-Trac-Ticket-ID: 132 In-Reply-To: <053.23fd175ad3e8fb1a4a7303089729c32f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, angelo@castellani.net, cabo@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #132: Separate response implicitly acks confirmable request X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 22 Apr 2011 11:54:00 -0000 #132: Separate response implicitly acks confirmable request Changes (by cabo@…): * status: new => closed * resolution: => fixed Comment: Fixed in [284]: Fix #132 (Thanks, Angelo!) -- --------------------------------+------------------------------------------- Reporter: hartke@… | Owner: hartke@… Type: editorial | Status: closed Priority: minor | Milestone: Component: coap | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu Apr 28 01:52:23 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 048CDE06CC for ; Thu, 28 Apr 2011 01:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APixqMdhOPYC for ; Thu, 28 Apr 2011 01:52:22 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 8111BE062A for ; Thu, 28 Apr 2011 01:52:22 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QFMxQ-00031y-PG; Thu, 28 Apr 2011 01:52:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Thu, 28 Apr 2011 08:52:20 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/144 Message-ID: <057.47982ae8991872cb7dbe8b4078a3cfa7@trac.tools.ietf.org> X-Trac-Ticket-ID: 144 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #144: Request CoAP Media Type ID for application/link-format X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 28 Apr 2011 08:52:23 -0000 #144: Request CoAP Media Type ID for application/link-format As application/link-format has not yet been registered with IANA, this draft needs to request a CoAP Media Type code. The current value of 40 will be requested as it has been in long-term use. Thus the current application/link-format entry in coap-05 will be removed in coap-06. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: task | Status: new Priority: trivial | Milestone: Component: link-format | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu Apr 28 01:55:17 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0BEEE06D6 for ; Thu, 28 Apr 2011 01:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6yKc0yAjZke for ; Thu, 28 Apr 2011 01:55:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 7C29FE06F8 for ; Thu, 28 Apr 2011 01:55:17 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QFN0H-0003AB-Ff; Thu, 28 Apr 2011 01:55:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Thu, 28 Apr 2011 08:55:17 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/145 Message-ID: <057.7012fc818d4796dca51ab6945aa77ea9@trac.tools.ietf.org> X-Trac-Ticket-ID: 145 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #145: Remove attribute registry X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 28 Apr 2011 08:55:17 -0000 #145: Remove attribute registry At the request of our ADs and Mark Nottingham, will be working on a general regsitry for Web Linking link extension attributes. Therefore the Section 7.1 Attribute Registry will be removed from link-format, and these CoRE specific attributes will be registered when the general registry becomes available. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: task | Status: new Priority: minor | Milestone: Component: link-format | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu Apr 28 03:40:23 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4831EE06F5 for ; Thu, 28 Apr 2011 03:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77cGTPmNvOhS for ; Thu, 28 Apr 2011 03:40:21 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 0437EE0659 for ; Thu, 28 Apr 2011 03:40:21 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QFOdw-0005da-46; Thu, 28 Apr 2011 03:40:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Thu, 28 Apr 2011 10:40:20 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/101#comment:5 Message-ID: <062.c69a9637e33bd45c825926feeea8b23b@trac.tools.ietf.org> References: <053.4ee873d7ebb8f94277f774e4b089aa27@trac.tools.ietf.org> X-Trac-Ticket-ID: 101 In-Reply-To: <053.4ee873d7ebb8f94277f774e4b089aa27@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #101: Review media type registry X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 28 Apr 2011 10:40:23 -0000 #101: Review media type registry Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Closed in coap-06 - Reduced the initial set of media types to five basic types already registered with IANA. - Added complete references for each type. - Removed the "Correct examples..." text that concerned Björn. -- ----------------------------+----------------------------------------------- Reporter: hartke@… | Owner: zach@… Type: task | Status: closed Priority: minor | Milestone: Component: coap | Version: Severity: - | Resolution: fixed Keywords: | ----------------------------+----------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu Apr 28 03:59:25 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63161E06B1 for ; Thu, 28 Apr 2011 03:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMBvoeCP0Kg0 for ; Thu, 28 Apr 2011 03:59:24 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id DF4F4E0659 for ; Thu, 28 Apr 2011 03:59:19 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QFOwJ-0002rt-Cc; Thu, 28 Apr 2011 03:59:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Thu, 28 Apr 2011 10:59:19 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/135#comment:1 Message-ID: <066.906045ce8895242e8bd90b0ad8812798@trac.tools.ietf.org> References: <057.937520e95c0963670ab27315deee5cee@trac.tools.ietf.org> X-Trac-Ticket-ID: 135 In-Reply-To: <057.937520e95c0963670ab27315deee5cee@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #135: Reply to NON Request X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 28 Apr 2011 10:59:25 -0000 #135: Reply to NON Request Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Clarifying text regarding response to a NON request were added along with an additional figure in coap-06. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: protocol defect | Status: closed Priority: minor | Milestone: Component: coap | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu Apr 28 04:10:06 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06789E0747 for ; Thu, 28 Apr 2011 04:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJ-PESl2Cmn4 for ; Thu, 28 Apr 2011 04:09:58 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE0BE06DF for ; Thu, 28 Apr 2011 04:09:58 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QFP6b-00017o-9U; Thu, 28 Apr 2011 04:09:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Thu, 28 Apr 2011 11:09:57 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/core/trac/ticket/139#comment:1 Message-ID: <066.7b6ad8bfa148b8b783a6b73b0be53b40@trac.tools.ietf.org> References: <057.5bc247d3d7b326d31ef9028a964e0298@trac.tools.ietf.org> X-Trac-Ticket-ID: 139 In-Reply-To: <057.5bc247d3d7b326d31ef9028a964e0298@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #139: Must-implement cipher suites X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 28 Apr 2011 11:10:06 -0000 #139: Must-implement cipher suites Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Done in coap-06. -- ----------------------------------+----------------------------------------- Reporter: zach@… | Owner: zach@… Type: protocol enhancement | Status: closed Priority: minor | Milestone: Component: coap | Version: Severity: - | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu Apr 28 04:20:30 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E33E074E for ; Thu, 28 Apr 2011 04:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPefpOr88GsN for ; Thu, 28 Apr 2011 04:20:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id CA005E074A for ; Thu, 28 Apr 2011 04:20:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QFPGm-0001oi-V7; Thu, 28 Apr 2011 04:20:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Thu, 28 Apr 2011 11:20:28 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/core/trac/ticket/140#comment:1 Message-ID: <066.bfeccd1d7a11068a1dcfe01fb3946552@trac.tools.ietf.org> References: <057.557dc07297e7013375c889ffb9e9dbad@trac.tools.ietf.org> X-Trac-Ticket-ID: 140 In-Reply-To: <057.557dc07297e7013375c889ffb9e9dbad@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #140: IKEv2 minimal reference X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 28 Apr 2011 11:20:30 -0000 #140: IKEv2 minimal reference Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Done in coap-06. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: editorial | Status: closed Priority: trivial | Milestone: Component: coap | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu Apr 28 04:39:43 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0254AE06C3 for ; Thu, 28 Apr 2011 04:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50n3mfm9YC0t for ; Thu, 28 Apr 2011 04:39:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id A53EAE06A5 for ; Thu, 28 Apr 2011 04:39:42 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QFPZO-0006kD-0n; Thu, 28 Apr 2011 04:39:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Thu, 28 Apr 2011 11:39:42 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/core/trac/ticket/138#comment:1 Message-ID: <066.3f3f88435495146005c6d277cbfee888@trac.tools.ietf.org> References: <057.ca63b30ac3e3ffdf9aad52c02fa3ebc8@trac.tools.ietf.org> X-Trac-Ticket-ID: 138 In-Reply-To: <057.ca63b30ac3e3ffdf9aad52c02fa3ebc8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #138: DTLS Clarification X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 28 Apr 2011 11:39:43 -0000 #138: DTLS Clarification Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Done in coap-06. -- ----------------------------------+----------------------------------------- Reporter: zach@… | Owner: zach@… Type: protocol enhancement | Status: closed Priority: minor | Milestone: Component: coap | Version: Severity: - | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu Apr 28 04:58:03 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9FEE06C2 for ; Thu, 28 Apr 2011 04:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvlpDg-uCUZj for ; Thu, 28 Apr 2011 04:58:02 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id D079DE068D for ; Thu, 28 Apr 2011 04:58:02 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QFPr8-0006fl-07; Thu, 28 Apr 2011 04:58:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Thu, 28 Apr 2011 11:58:01 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/142#comment:1 Message-ID: <066.7a220421404a5d9f388ce011c01adaf0@trac.tools.ietf.org> References: <057.1785b085f639645bb771c4ab0a053779@trac.tools.ietf.org> X-Trac-Ticket-ID: 142 In-Reply-To: <057.1785b085f639645bb771c4ab0a053779@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #142: Retransmit timeout jitter X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 28 Apr 2011 11:58:03 -0000 #142: Retransmit timeout jitter Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Done in coap-06. -- ----------------------------------+----------------------------------------- Reporter: zach@… | Owner: zach@… Type: protocol enhancement | Status: closed Priority: minor | Milestone: Component: coap | Version: Severity: - | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Ticket URL: core From kovatsch@inf.ethz.ch Fri Apr 29 08:35:02 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6117FE06A7 for ; Fri, 29 Apr 2011 08:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4vci-lGTqKW for ; Fri, 29 Apr 2011 08:35:01 -0700 (PDT) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id 9417AE0663 for ; Fri, 29 Apr 2011 08:35:00 -0700 (PDT) Received: from CAS12.d.ethz.ch (172.31.38.212) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.1.289.1; Fri, 29 Apr 2011 17:34:51 +0200 Received: from MBX20.d.ethz.ch ([fe80::81a7:b7a5:50c0:df0d]) by CAS12.d.ethz.ch ([fe80::7861:4ecb:7c42:cad4%11]) with mapi id 14.01.0289.001; Fri, 29 Apr 2011 17:34:58 +0200 From: "Kovatsch Matthias" To: "core@ietf.org" Thread-Topic: CoAP block sizes: power of two might not be optimal Thread-Index: AcwGfcHsDp9xn7EdT4OrSVjR+tAo4Q== Date: Fri, 29 Apr 2011 15:34:57 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B50841DBA2@MBX20.d.ethz.ch> Accept-Language: en-US, de-CH Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.10.67.50] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [core] CoAP block sizes: power of two might not be optimal X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 29 Apr 2011 15:35:02 -0000 RGVhciBDYXJzdGVuLCBkZWFyIENPUkUgbGlzdA0KDQpUaGUgYmxvY2sgc2l6ZXMgaGF2ZSBhIHN0 cm9uZyBpbXBhY3Qgb24gaG93IHRvIGRpbWVuc2lvbiB0aGUgYnVmZmVycyBvZiB0aGUgYXBwbGlj YXRpb24sIE9TLCBhbmQgbmV0d29yayBzdGFjay4NCkkgZmlndXJlZCB0aGF0IHRoZSBjdXJyZW50 IHNjaGVtZSwgdXNpbmcgcG93ZXJzIG9mIHR3bywgZG9lcyBub3QgcHJvdmlkZSBtYW55IHVzZWZ1 bCBjaG9pY2VzIGZvciB0aGUgaW1wbGVtZW50YXRpb24uDQpXaGlsZSA2NCBhcHBlYXJzIHRvIGJl IGEgZ29vZCBjaG9pY2UgZm9yIDE1LjQgZnJhbWVzLCB0aGUgbmV4dCBsYXJnZXIgc2l6ZSAxMjgg bWlnaHQgYWxyZWFkeSBiZSB0b28gbGFyZ2UgZm9yIGRldmljZXMgd2l0aCB2ZXJ5IGNvbnN0cmFp bmVkIG1lbW9yeS4gRnJvbSAyNTYgb253YXJkcywgaXQgYmVjb21lcyBkZW1hbmRpbmcgZm9yIHRo ZSBJUCBmcmFnbWVudGF0aW9uIGJ1ZmZlciBvZiBldmVyeSBob3AuDQoNCkFsdGhvdWdoIGl0IHdv dWxkIHJ1aW4gdGhlIGJlYXV0eSBvZiB0aGUgY3VycmVudCBjYWxjdWxhdGlvbiBhbmQgcmVxdWly ZSBtb3JlIGJpdHMsIG1heWJlIG11bHRpcGxlcyBvZiAzMiBvciBldmVuIGEgbG9va3VwIHRhYmxl IHdpdGggInJlYXNvbmFibGUgdmFsdWVzIiBtaWdodCBiZSBhIGJldHRlciBvcHRpb24uDQpXaGF0 IGRvIHlvdSB0aGluaz8NCg0KQmVzdCByZWdhcmRzDQpNYXR0aGlhcw0K From charles.palmer@onzo.com Fri Apr 29 09:33:13 2011 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67F5E06C0 for ; Fri, 29 Apr 2011 09:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfBCSLLUoXHE for ; Fri, 29 Apr 2011 09:33:09 -0700 (PDT) Received: from service38.mimecast.com (service38.mimecast.com [195.130.217.47]) by ietfa.amsl.com (Postfix) with SMTP id 09D26E069F for ; Fri, 29 Apr 2011 09:33:08 -0700 (PDT) Received: from onzosbs2k3.ONZO.local (217.138.5.2 [217.138.5.2]) by service38.mimecast.com; Fri, 29 Apr 2011 17:33:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 29 Apr 2011 17:33:05 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CoAP block sizes: power of two might not be optimal Thread-Index: AcwGfcHsDp9xn7EdT4OrSVjR+tAo4QACxq/a References: <55877B3AFB359744BA0F2140E36F52B50841DBA2@MBX20.d.ethz.ch> From: "Charles Palmer" To: "Kovatsch Matthias" , X-MC-Unique: 111042917330700302 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC068B.1DA3C53B" Subject: Re: [core] CoAP block sizes: power of two might not be optimal X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 29 Apr 2011 16:33:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC068B.1DA3C53B Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi all Matthias makes a reasonable point. Could I suggest that the block number field NUM is considered at the same t= ime. In particular, would there ever be a need for a 3-byte Block Option, w= ith a 20-bit block number field? Two bytes with a 12-bit NUM field supports= 64k byte resource representations even with the smallest 16-byte block siz= e. (Of course, if the SZX field takes more bits then the arithmetic changes= ...) Regards - Charles Palmer -----Original Message----- From: core-bounces@ietf.org on behalf of Kovatsch Matthias Sent: Fri 29/04/2011 16:34 To: core@ietf.org Subject: [core] CoAP block sizes: power of two might not be optimal =20 Dear Carsten, dear CORE list The block sizes have a strong impact on how to dimension the buffers of the= application, OS, and network stack. I figured that the current scheme, using powers of two, does not provide ma= ny useful choices for the implementation. While 64 appears to be a good choice for 15.4 frames, the next larger size = 128 might already be too large for devices with very constrained memory. Fr= om 256 onwards, it becomes demanding for the IP fragmentation buffer of eve= ry hop. Although it would ruin the beauty of the current calculation and require mo= re bits, maybe multiples of 32 or even a lookup table with "reasonable valu= es" might be a better option. What do you think? Best regards Matthias _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core -------------------------------- Onzo is a limited company number 06097997 registered in England & Wales. Th= e =20 registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingd= om. This email message may contain confidential and/or privileged information, = and is intended solely for the addressee(s). If you have received this email in= =20 error, please notify Onzo immediately. Unauthorised copying, disclosure or= =20 distribution of the material in this email is forbidden. -------------------------------- ------_=_NextPart_001_01CC068B.1DA3C53B Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable RE: [core] CoAP block sizes: power of two might not be optimal</TITL= E> </HEAD> <BODY> =20 =20 <!-- Converted from text/plain format --> <P><FONT SIZE=3D2>Hi all<BR> <BR> Matthias makes a reasonable point.<BR> <BR> Could I suggest that the block number field NUM is considered at the same t= ime. In particular, would there ever be a need for a 3-byte Block Option, w= ith a 20-bit block number field? Two bytes with a 12-bit NUM field supports= 64k byte resource representations even with the smallest 16-byte block siz= e. (Of course, if the SZX field takes more bits then the arithmetic changes= ...)<BR> <BR> Regards - Charles Palmer<BR> <BR> -----Original Message-----<BR> From: core-bounces@ietf.org on behalf of Kovatsch  Matthias<BR> Sent: Fri 29/04/2011 16:34<BR> To: core@ietf.org<BR> Subject: [core] CoAP block sizes: power of two might not be optimal<BR> <BR> Dear Carsten, dear CORE list<BR> <BR> The block sizes have a strong impact on how to dimension the buffers of the= application, OS, and network stack.<BR> I figured that the current scheme, using powers of two, does not provide ma= ny useful choices for the implementation.<BR> While 64 appears to be a good choice for 15.4 frames, the next larger size = 128 might already be too large for devices with very constrained memory. Fr= om 256 onwards, it becomes demanding for the IP fragmentation buffer of eve= ry hop.<BR> <BR> Although it would ruin the beauty of the current calculation and require mo= re bits, maybe multiples of 32 or even a lookup table with "reasonable= values" might be a better option.<BR> What do you think?<BR> <BR> Best regards<BR> Matthias<BR> _______________________________________________<BR> core mailing list<BR> core@ietf.org<BR> <A HREF=3D"https://www.ietf.org/mailman/listinfo/core">https://www.ietf.org= /mailman/listinfo/core</A><BR> <BR> <BR> </FONT> </P> <BR> <span style=3D"font-family:Arial; Font-size:8pt"> --------------------------------<br/> <a href=3D"http://www.onzo.com/">Onzo</a> is a limited company nu= mber 06097997 registered in England & Wales. The<br/> registered office is 6 Great Newport Street, London, WC2H 7JB, Un= ited Kingdom.<br/><br/> This email message may contain confidential and/or privileged inf= ormation, and<br/> is intended solely for the addressee(s). If you have received thi= s email in<br/> error, please notify <a href=3D"http://www.onzo.com/">Onzo</a> im= mediately. Unauthorised copying, disclosure or<br/> distribution of the material in this email is forbidden.<br/> --------------------------------<br/> </span> </BODY> </HTML> ------_=_NextPart_001_01CC068B.1DA3C53B--