From trac+core@trac.tools.ietf.org Fri Jul 1 01:32:46 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 C5A4B21F87E4 for ; Fri, 1 Jul 2011 01:32:46 -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 Y76B+N9Atfzn for ; Fri, 1 Jul 2011 01:32:46 -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 67B8521F87E2 for ; Fri, 1 Jul 2011 01:32:46 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QcZ9Y-0007Kh-D4; Fri, 01 Jul 2011 01:32:44 -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, 01 Jul 2011 08:32:44 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/162#comment:1 Message-ID: <066.505b9bc0d41449cdfb6e41bdd0f3e3ef@trac.tools.ietf.org> References: <057.2f42a753a9f270a64e975d49c7a5c4cd@trac.tools.ietf.org> X-Trac-Ticket-ID: 162 In-Reply-To: <057.2f42a753a9f270a64e975d49c7a5c4cd@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] #162: Add application/link-format to code 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, 01 Jul 2011 08:32:46 -0000 #162: Add application/link-format to code registry Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Done for coap-07. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: task | Status: closed Priority: trivial | Milestone: Component: coap | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Fri Jul 1 02:39:27 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 83FB311E80F6 for ; Fri, 1 Jul 2011 02:39:27 -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 YnTGzLXQpwTx for ; Fri, 1 Jul 2011 02:39:27 -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 391AD11E80F1 for ; Fri, 1 Jul 2011 02:39:27 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QcaC0-0003bV-6w; Fri, 01 Jul 2011 02:39: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: cabo@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Fri, 01 Jul 2011 09:39:20 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/core/trac/ticket/150#comment:1 Message-ID: <060.f5800610697e86756c4a76f195bfbf04@trac.tools.ietf.org> References: <051.11e19e815bf80765c13befd499cd1255@trac.tools.ietf.org> X-Trac-Ticket-ID: 150 In-Reply-To: <051.11e19e815bf80765c13befd499cd1255@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: 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] #150: Allow zero-length Content-Type 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, 01 Jul 2011 09:39:27 -0000 #150: Allow zero-length Content-Type Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Done in coap-07. -- --------------------------------+------------------------------------------- Reporter: cabo@… | Owner: cabo@… Type: protocol defect | Status: closed Priority: trivial | Milestone: Component: coap | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Fri Jul 1 02:51:26 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 AA13521F86B7 for ; Fri, 1 Jul 2011 02:51:26 -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 KJuqrLmO9rpi for ; Fri, 1 Jul 2011 02:51:26 -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 932F021F8688 for ; Fri, 1 Jul 2011 02:51:25 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QcaNZ-0007ue-0S; Fri, 01 Jul 2011 02:51: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: draft-ietf-core-coap@tools.ietf.org, zach@sensinode.com X-Trac-Project: core Date: Fri, 01 Jul 2011 09:51:16 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/core/trac/ticket/153#comment:1 Message-ID: <060.8d52c70b208c33043cfae461a4db76b8@trac.tools.ietf.org> References: <051.930a886e6b7e4afd934175bd439cabd5@trac.tools.ietf.org> X-Trac-Ticket-ID: 153 In-Reply-To: <051.930a886e6b7e4afd934175bd439cabd5@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.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 Resent-To: Resent-Message-Id: <20110701095125.932F021F8688@ietfa.amsl.com> Resent-Date: Fri, 1 Jul 2011 02:51:25 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #153: Make congestion control recommendation more actionable 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, 01 Jul 2011 09:51:26 -0000 #153: Make congestion control recommendation more actionable Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Added to Section 4.5 of coap-07. -- ----------------------------------+----------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-coap@… Type: protocol enhancement | Status: closed Priority: major | Milestone: Component: coap | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Fri Jul 1 02:57:24 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 714F021F87A2 for ; Fri, 1 Jul 2011 02:57:24 -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 V3OgWshLMTwz for ; Fri, 1 Jul 2011 02:57: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 2686121F87A1 for ; Fri, 1 Jul 2011 02:57:24 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QcaTR-000899-Ip; Fri, 01 Jul 2011 02:57:21 -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, zach@sensinode.com X-Trac-Project: core Date: Fri, 01 Jul 2011 09:57:21 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/149#comment:1 Message-ID: <060.316db4611b8c278400072dfbf33406d7@trac.tools.ietf.org> References: <051.da85a5b3711b520f501e5bff6373fa2b@trac.tools.ietf.org> X-Trac-Ticket-ID: 149 In-Reply-To: <051.da85a5b3711b520f501e5bff6373fa2b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: 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] #149: Text for PUT/POST response payloads is missing 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, 01 Jul 2011 09:57:24 -0000 #149: Text for PUT/POST response payloads is missing Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Changes made to coap-07. -- --------------------------------+------------------------------------------- Reporter: cabo@… | Owner: cabo@… Type: protocol defect | Status: closed Priority: major | Milestone: Component: coap | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: core From oscar.novo@ericsson.com Fri Jul 1 03:57:31 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 8DA0E21F8705 for ; Fri, 1 Jul 2011 03:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 R0QVlOD+K49P for ; Fri, 1 Jul 2011 03:57:30 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 43E9421F86FB for ; Fri, 1 Jul 2011 03:57:29 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-51-4e0da81802d0 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 29.B2.20773.818AD0E4; Fri, 1 Jul 2011 12:57:28 +0200 (CEST) Received: from ESESSCMS0355.eemea.ericsson.se ([169.254.1.139]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Fri, 1 Jul 2011 12:57:28 +0200 From: Oscar Novo To: "core@ietf.org" Date: Fri, 1 Jul 2011 12:57:27 +0200 Thread-Topic: draft-shelby-core-resource-directory-00 Thread-Index: Acw33aqCyfOZnwNcRsODRQPJSNyslg== Message-ID: <58E207308662A748A4AC1ECB4E885614081795E658@ESESSCMS0355.eemea.ericsson.se> 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_58E207308662A748A4AC1ECB4E885614081795E658ESESSCMS0355e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [core] draft-shelby-core-resource-directory-00 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, 01 Jul 2011 10:57:31 -0000 --_000_58E207308662A748A4AC1ECB4E885614081795E658ESESSCMS0355e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Zach & others, This week I've been reviewing the CoRE Resource Directory draft and I have = some minor questions/unclarities about it. It might be good idea to explain= /resolve them in a future version of the draft. 3.1 - Discovery: -if there are many RD, is there any policy about the RD which should be c= hoosen by a node? - what happen if there is not any RDs available? 3.2 - Registration: - if many RD, the EP have to register itself to every RD? Is the informatio= n replicated between the different RD? the EP informs and have to update al= l of them? - what is used the 'node identifier' for? - is not possible to modify the 'EP Node Identifier' after registration? 3.4 - Validation: - what if a node is an sleeping node and doesn't answer? what's the behavio= r of the EP? 4.1 - Resource Instance 'ins' attribute - What's the difference between instance and end-point-name? Cheers, Oscar [http://www.ericsson.com/shared/images/Email_line.gif] OSCAR NOVO Research Engineer, Ericsson Research Nomadiclab, Services and Software Ericsson Finland, Oy L M Ericsson Ab Hirsalantie 11 02420 Jorvas, Finland www.ericsson.com [http://www.ericsson.com/shared/images/Email.gif] This Communication is Confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com/email_disclaimer --_000_58E207308662A748A4AC1ECB4E885614081795E658ESESSCMS0355e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Zach &=20 others,
 
This=20 week I've been reviewing the CoRE Resource Directory draft and I have = some=20 minor questions/unclarities about it. It might be good idea to explain/reso= lve=20 them in a future version of the draft.
 
3.1 - Discovery:

  -if there are many RD, is there any policy about the RD whic= h=20 should be choosen by a node?

 - what happen if ther= e is=20 not any RDs available? 

 3.2 - Registration:

- if many RD, the EP have to register itself to every RD? Is=20 the information replicated between the different RD? the EP informs=20 and have to update all of them? 

- what is used the 'node identifier' for?

- is not possible to modify the 'EP Node Identifier' after registration?=

3.4 - Validation: 

- what if a node is an slee= ping=20 node and doesn't answer? what's the behavior of the EP?

4.1 - Resource Instance 'ins' attribute

- What's the difference between= =20 instance and end-point-name?

Cheers, 

Oscar


3Dline

OSCAR NOVO=20
Research Engineer, Ericsson Research


Nomadiclab, S= ervices=20 and Software

Ericsson Finl= and, Oy=20 L M Ericsson Ab
Hirsalantie 11
02420 Jorvas, Finland
www.ericsson.= com=20



3DEricsson=20






This=20 Communication is Confidential. We only send and receive email on the basis = of=20 the term set out at www.ericsson.com/email_di= sclaimer=20

 
--_000_58E207308662A748A4AC1ECB4E885614081795E658ESESSCMS0355e_-- From zach@sensinode.com Mon Jul 4 00:58:27 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 4AF6421F85A6 for ; Mon, 4 Jul 2011 00:58:27 -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=[AWL=1.300, BAYES_00=-2.599, 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 RqHnv31lYHLQ for ; Mon, 4 Jul 2011 00:58:26 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id DCACA21F8683 for ; Mon, 4 Jul 2011 00:58:25 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p647wKN1007144 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Jul 2011 10:58:20 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-246-746618515; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Mon, 4 Jul 2011 10:58:20 +0300 Message-Id: <0CDA091E-7C13-4E25-8623-3F1BB8AE2F68@sensinode.com> References: <20110627121506.12396.27491.idtracker@ietfa.amsl.com> To: Zach Shelby X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] Fwd: New Version Notification for draft-shelby-core-resource-directory-00.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: Mon, 04 Jul 2011 07:58:27 -0000 --Apple-Mail-246-746618515 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks everyone for the helpful feedback, ideas and interest on the = resource directory draft. This week I am going to dedicate my time to = releasing coap-07 and am on vacation after that, so forgive my silence = on answering questions about this draft for the next couple weeks. The = intention is to take the feedback into account and release a -01 rev in = Quebec. Zach=20 On Jun 27, 2011, at 3:20 PM, Zach Shelby wrote: > We have submitted an initial resource directory interface = specification draft, and would like to spend 10 minutes in Quebec to = present it. >=20 > http://tools.ietf.org/html/draft-shelby-core-resource-directory-00 >=20 > Zach >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Date: June 27, 2011 3:15:06 PM GMT+03:00 >> To: zach@sensinode.com >> Cc: srdjan.krco@ericsson.com, zach@sensinode.com >> Subject: New Version Notification for = draft-shelby-core-resource-directory-00.txt >>=20 >> A new version of I-D, draft-shelby-core-resource-directory-00.txt has = been successfully submitted by Zach Shelby and posted to the IETF = repository. >>=20 >> Filename: draft-shelby-core-resource-directory >> Revision: 00 >> Title: CoRE Resource Directory >> Creation date: 2011-06-27 >> WG ID: Individual Submission >> Number of pages: 16 >>=20 >> Abstract: >> In many M2M scenarios, direct discovery of resources is not = practical >> due to sleeping nodes, disperse networks, or networks where = multicast >> traffic is inefficient. These problems can be solved by employing = an >> entity called a Resource Directory (RD), which hosts descriptions of >> resources held on other servers, allowing lookups to be performed = for >> those resources. This document specifies the web interfaces that a >> Resource Directory supports in order for web servers to discover the >> RD and to registrer, maintain, lookup and remove resources >> descriptions. Furthermore, new link attributes useful in = conjunction >> with an RD are defined. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >=20 > --=20 > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com 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-246-746618515 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDcwNDA3NTgy MFowIwYJKoZIhvcNAQkEMRYEFPMf2tjbT8KBAkeO0Oe6iWntmndzMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAKhbymZSdhRghlQ8RNz2db87UhAK1VU2eyywjivjdiBFloqvSaH5ZHRg SpnqlP6idxaSU0lAh8FYoVEf1I+g/g3GmuH44q741XIA6BZk27GCLpps9TbbwciDkwPuzmTAlGkP YnRQxIoW1pAmjlg75InIK0eDNiEuFGgBifIrlEU4WcRO5LKMYh3OfdOvOndN1df9+WMUiPbkDH+X cHO12Chk7SB7WYFTA/4CoaffyAq9U7pqFtjjPNdeD7TbEZyLx48HQpGbl3ulLFAt4q+Rx53LUucG 9RKZoEL48VB3v3GGNbnFUvsP+E+II1Na/n5Bmt9d2eUXpYhIWE8xJaKzxF4AAAAAAAA= --Apple-Mail-246-746618515-- From jari.arkko@piuha.net Mon Jul 4 06:41:10 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 515F121F85F4 for ; Mon, 4 Jul 2011 06:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.352 X-Spam-Level: X-Spam-Status: No, score=-102.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, 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 D4gX6-kDvADt for ; Mon, 4 Jul 2011 06:41:10 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 77C0621F85E8 for ; Mon, 4 Jul 2011 06:41:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A08532CEFF for ; Mon, 4 Jul 2011 16:41:08 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKpW4qoETpPj for ; Mon, 4 Jul 2011 16:41:07 +0300 (EEST) Received: from [IPv6:::1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id A52552CC4B for ; Mon, 4 Jul 2011 16:41:07 +0300 (EEST) Message-ID: <4E11C2F3.2030702@piuha.net> Date: Mon, 04 Jul 2011 16:41:07 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: core@ietf.org References: <20110704133510.22797.55054.idtracker@ietfa.amsl.com> In-Reply-To: <20110704133510.22797.55054.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [core] FW: New Version Notification for draft-arkko-core-sleepy-sensors-00.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: Mon, 04 Jul 2011 13:41:10 -0000 FYI. Comments appreciated. http://tools.ietf.org/html/draft-arkko-core-sleepy-sensors-00 > Filename: draft-arkko-core-sleepy-sensors > Revision: 00 > Title: Implementing Tiny COAP Sensors > Creation date: 2011-07-04 > > Abstract: > The authors are developing COAP and IPv6-based sensor networks for > environments where lightweight implementations, long battery > lifetimes, and minimal management burden are important. The memo > shows how different communication models supported by COAP affect > implementation complexity and energy consumption, far more so than > mere changes in message syntax. Our prototype implements a > multicast-based IPv6, UDP, COAP, and XML protocol stack in less than > 50 assembler instructions. While this extremely minimal > implementation is suitable only for limited applications and makes a > number of assumptions, the general conclusions point to need for > further work in developing the COAP multicast and observation > frameworks. > From zehn.cao@gmail.com Mon Jul 4 07:02:27 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 7658211E80A1; Mon, 4 Jul 2011 07:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.902 X-Spam-Level: X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[AWL=0.697, BAYES_00=-2.599, 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 ih7zqmsnVgMz; Mon, 4 Jul 2011 07:02:27 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B546111E809F; Mon, 4 Jul 2011 07:02:26 -0700 (PDT) Received: by iye7 with SMTP id 7so5552894iye.31 for ; Mon, 04 Jul 2011 07:02:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=LXsRpjMBXLyK72FDCDEhWZal6B4O7WdthL9s/NTaYjs=; b=oi8SIwa/NxEGpzxBdzfcbDDZ/sxvJwILGln54jksQHaRXWGOWFro/xwAIrBx8OcPkg EnsYpCdWjvtuiEVt+wVUqnR/JhQv1WQ6NVkJUT3bxNmqUqzjheplZxBLkQWSQImDTzeF KM7/eH+Cz0BJ5s7iIMKkW1/oWSa52e/W/aYe8= MIME-Version: 1.0 Received: by 10.42.11.207 with SMTP id v15mr7191320icv.22.1309788146252; Mon, 04 Jul 2011 07:02:26 -0700 (PDT) Received: by 10.42.169.193 with HTTP; Mon, 4 Jul 2011 07:02:26 -0700 (PDT) In-Reply-To: <20110704135502.27697.88394.idtracker@ietfa.amsl.com> References: <20110704135502.27697.88394.idtracker@ietfa.amsl.com> Date: Mon, 4 Jul 2011 22:02:26 +0800 Message-ID: From: Zhen Cao To: core , lwip@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [core] Fwd: I-D Action: draft-cao-core-aol-req-00.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: Mon, 04 Jul 2011 14:02:27 -0000 A very simple draft yet, but easy to read and discuss. ---------- Forwarded message ---------- From: Date: Mon, Jul 4, 2011 at 9:55 PM Subject: I-D Action: draft-cao-core-aol-req-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Allways-online Requirement for S= leeping CoAP Node =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Zhen Cao =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-cao-core-aol-req-00.txt =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 5 =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-07-04 =A0 CoAP is to enable a concept of web of sensors, but there are many =A0 cases that the sensors are not always online and hence the requests =A0 from the web client cannot reach them in timely manner. =A0This =A0 document analyzes this problem and describes the requirements for a =A0 CoAP enabled sensor to behave always online. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cao-core-aol-req-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-cao-core-aol-req-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --=20 Best regards, Zhen From angelo.castellani@gmail.com Mon Jul 4 09:05:11 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 9AFB421F85E4 for ; Mon, 4 Jul 2011 09:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 PdNp8X4LdKpk for ; Mon, 4 Jul 2011 09:05:11 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA7021F85E3 for ; Mon, 4 Jul 2011 09:05:10 -0700 (PDT) Received: by qyk29 with SMTP id 29so4121337qyk.10 for ; Mon, 04 Jul 2011 09:05:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; bh=2nLvBzRmK1mJycHpKhouB+iwfQfH630oTB8xaxzn4b4=; b=F0vaGWYs/BZg0A5UQt4komMidVFzMrDQ9wo6wl304SoYg/bZJgwzKVhH+g1QgrMrKE kAGwR6eKCLJKegVWa92gog6NnAdRglhf/cWq9ioPxa1PO/5lv6rYzFpn5gyjHS/5o6oT CygO96gpWTW/nygdsgrkDGn7+QN2Y1ntmccRU= Received: by 10.229.65.144 with SMTP id j16mr4842332qci.26.1309795510170; Mon, 04 Jul 2011 09:05:10 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.229.84.73 with HTTP; Mon, 4 Jul 2011 09:04:50 -0700 (PDT) In-Reply-To: <20110704160348.3225.33415.idtracker@ietfa.amsl.com> References: <20110704160348.3225.33415.idtracker@ietfa.amsl.com> From: "Angelo P. Castellani" Date: Mon, 4 Jul 2011 18:04:50 +0200 X-Google-Sender-Auth: Dk_Q4EuVA0G3WmQE1VtwzuoRwgE Message-ID: To: core Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [core] Fwd: New Version Notification for draft-castellani-core-http-mapping-00.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: Mon, 04 Jul 2011 16:05:11 -0000 All, we have submitted a new draft about the mapping of CoAP to/from HTTP. We would like to have a slot in Quebec to present it. Best, Angelo, Salvatore, Akbar, Thomas and Esko ---------- Forwarded message ---------- From: Date: Mon, Jul 4, 2011 at 18:03 Subject: New Version Notification for draft-castellani-core-http-mapping-00= .txt To: angelo@castellani.net Cc: angelo@castellani.net, salvatore.loreto@ericsson.com, akbar.rahman@interdigital.com, tho@koanlogic.com, esko.dijk@philips.com A new version of I-D, draft-castellani-core-http-mapping-00.txt has been successfully submitted by Angelo P. Castellani and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-castellani-core-http-mapping Revision: =A0 =A0 =A0 =A000 Title: =A0 =A0 =A0 =A0 =A0 Best practices for HTTP-CoAP mapping implementat= ion Creation date: =A0 2011-07-04 WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission Number of pages: 23 Abstract: =A0 This draft aims at being a base reference documentation for HTTP-CoAP =A0 proxy implementors. =A0It details deployment options, discusses =A0 possible approaches for URI mapping, and provides useful =A0 considerations related to protocol translation. The IETF Secretariat From salvatore.loreto@ericsson.com Mon Jul 4 10:25: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 EF4F61F0C49 for ; Mon, 4 Jul 2011 10:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 PRhweTPDVjO5 for ; Mon, 4 Jul 2011 10:25:23 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0B67F1F0C42 for ; Mon, 4 Jul 2011 10:25:22 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-25-4e11f781c5e4 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 75.B3.09774.287F11E4; Mon, 4 Jul 2011 19:25:22 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Mon, 4 Jul 2011 19:25:21 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 35D00245A for ; Mon, 4 Jul 2011 20:25:21 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E9FAB5114F for ; Mon, 4 Jul 2011 20:25:20 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9A367506E8 for ; Mon, 4 Jul 2011 20:25:20 +0300 (EEST) Message-ID: <4E11F780.3090406@ericsson.com> Date: Mon, 4 Jul 2011 20:25:20 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: core@ietf.org References: <20110704160348.3225.33415.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [core] Fwd: New Version Notification for draft-castellani-core-http-mapping-00.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: Mon, 04 Jul 2011 17:25:24 -0000 here the link http://www.ietf.org/id/draft-castellani-core-http-mapping-00.txt -- Salvatore Loreto www.sloreto.com On 7/4/11 7:04 PM, Angelo P. Castellani wrote: > All, > > we have submitted a new draft about the mapping of CoAP to/from HTTP. > > We would like to have a slot in Quebec to present it. > > Best, > Angelo, Salvatore, Akbar, Thomas and Esko > > > ---------- Forwarded message ---------- > From: > Date: Mon, Jul 4, 2011 at 18:03 > Subject: New Version Notification for draft-castellani-core-http-mapping-00.txt > To: angelo@castellani.net > Cc: angelo@castellani.net, salvatore.loreto@ericsson.com, > akbar.rahman@interdigital.com, tho@koanlogic.com, > esko.dijk@philips.com > > > A new version of I-D, draft-castellani-core-http-mapping-00.txt has > been successfully submitted by Angelo P. Castellani and posted to the > IETF repository. > > Filename: draft-castellani-core-http-mapping > Revision: 00 > Title: Best practices for HTTP-CoAP mapping implementation > Creation date: 2011-07-04 > WG ID: Individual Submission > Number of pages: 23 > > Abstract: > This draft aims at being a base reference documentation for HTTP-CoAP > proxy implementors. It details deployment options, discusses > possible approaches for URI mapping, and provides useful > considerations related to protocol translation. > > > > > The IETF Secretariat > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From kerlyn2001@gmail.com Mon Jul 4 20:09:11 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 BB89221F872E for ; Mon, 4 Jul 2011 20:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 vUv5ejtmWxCV for ; Mon, 4 Jul 2011 20:09:11 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1F60821F8772 for ; Mon, 4 Jul 2011 20:09:11 -0700 (PDT) Received: by iye7 with SMTP id 7so6016996iye.31 for ; Mon, 04 Jul 2011 20:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=aebWrf26/gLShOmW56Wx79WvjxT11WXcOoLUANGZB0E=; b=el9MevNTGylJnW2fIJnvKbqNal3qUv4dhCXQBUfSTpl6i5ai6+vehYg8WPRDqGtzYM dO8YoaFJEm5nojn3YJJrgFg0V6PJzLJ1Pe1JbJKwxyL88/nTkS1sKB3qc6JeDk25RQIu 0fdiQanakmKpCjKFoH81Mtrz60RhslyWfzjDE= MIME-Version: 1.0 Received: by 10.42.108.6 with SMTP id f6mr1326142icp.327.1309835350325; Mon, 04 Jul 2011 20:09:10 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.42.218.5 with HTTP; Mon, 4 Jul 2011 20:09:10 -0700 (PDT) In-Reply-To: <20110704235317.25469.47459.idtracker@ietfa.amsl.com> References: <20110704235317.25469.47459.idtracker@ietfa.amsl.com> Date: Mon, 4 Jul 2011 23:09:10 -0400 X-Google-Sender-Auth: i7fqZX_BYktoorYFiyWcULrh8N4 Message-ID: From: Kerry Lynn To: core Content-Type: multipart/alternative; boundary=20cf303639b1c5396604a749ceeb Subject: [core] Fwd: New Version Notification for draft-lynn-core-discovery-mapping-00.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: Tue, 05 Jul 2011 03:09:11 -0000 --20cf303639b1c5396604a749ceeb Content-Type: text/plain; charset=ISO-8859-1 draft-lynn-core-discovery-mapping Apologies, but this proposal is still under construction. You might want to wait a day or two and comment on -01 when it's available. Regards, -K- ---------- Forwarded message ---------- From: Date: Mon, Jul 4, 2011 at 7:53 PM Subject: New Version Notification for draft-lynn-core-discovery-mapping-00.txt To: kerlyn@ieee.org Cc: kerlyn@ieee.org, zach@sensinode.com A new version of I-D, draft-lynn-core-discovery-mapping-00.txt has been successfully submitted by Kerry Lynn and posted to the IETF repository. Filename: draft-lynn-core-discovery-mapping Revision: 00 Title: CoRE Link-Format to DNS-Based Service Discovery Mapping Creation date: 2011-07-04 WG ID: Individual Submission Number of pages: 9 Abstract: Resource and service discovery are complimentary. Resource discovery provides fine-grained detail about the content of a server, while service discovery can provide a scable method to locate servers in large networks. This document defines a method for mapping between CoRE Link-Format attributes and DNS-Based Service Discovery fields so the two methods can be jointly employed in large scale networks. The IETF Secretariat --20cf303639b1c5396604a749ceeb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable draft-lynn-core-discovery-mapping

Apologie= s, but this proposal is still under construction.
You might want to wait a day or two and comment on
-01 when it= 9;s available.

Regards, -K-


---------- Forwarded message ---------- From: <internet-drafts@ietf.org>
= Date: Mon, Jul 4, 2011 at 7:53 PM
Subject: New Version Notification for = draft-lynn-core-discovery-mapping-00.txt
To: kerlyn@ieee.org
Cc: kerlyn@ieee.org, zach@sensinode.com


A new version of I-D, draft-l= ynn-core-discovery-mapping-00.txt has been successfully submitted by Kerry = Lynn and posted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-lynn-core-discovery-mapping
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 CoRE Link-Format to DNS-Based Service Discovery = Mapping
Creation date: =A0 2011-07-04
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 9

Abstract:
=A0 Resource and service discovery are complimentary. =A0Resource discover= y
=A0 provides fine-grained detail about the content of a server, while
=A0 service discovery can provide a scable method to locate servers in
=A0 large networks. =A0This document defines a method for mapping between<= br> =A0 CoRE Link-Format attributes and DNS-Based Service Discovery fields so<= br> =A0 the two methods can be jointly employed in large scale networks.




The IETF Secretariat

--20cf303639b1c5396604a749ceeb-- From trac+core@trac.tools.ietf.org Tue Jul 5 01:05:08 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 8C7EF21F874A for ; Tue, 5 Jul 2011 01:05:08 -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 Yt8txQVnFl5U for ; Tue, 5 Jul 2011 01:05:08 -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 3128721F8740 for ; Tue, 5 Jul 2011 01:05:08 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1Qe0d0-00066X-T2; Tue, 05 Jul 2011 01:05:06 -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: Tue, 05 Jul 2011 08:05:06 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/163 Message-ID: <057.213b5d9d1d62cee7319a2d6f5e3e5d21@trac.tools.ietf.org> X-Trac-Ticket-ID: 163 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] #163: Content-negotiation 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, 05 Jul 2011 08:05:08 -0000 #163: Content-negotiation I propose a ticket to add content-type preference indication to coap-07. In particular, the proposal is to add a new Elective option called "Accept". Here is text lifted from coap-misc-08: "The CoAP Accept option would when included one or more times in a request, carry one or more media types, each of which is an acceptable media type for the client, in the order of preference. If no Accept option is given, the client does not express a preference. The client prefers the representation returned by the server to be in one of the media types, but is willing to accept the response also if the server returns a representation in a different media type." One minor side effect of this change, is that the ct= attribute of core- link-format would need to be allowed multiple times. This attribute definition should anyways be moved from core-link-format and placed in core-coap as it is CoAP specific. -- ----------------------------------+----------------------------------------- Reporter: zach@… | Owner: zach@… Type: protocol enhancement | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: ----------------------------------+----------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Tue Jul 5 01:08:52 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 374E121F874F for ; Tue, 5 Jul 2011 01:08:52 -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 d3rP78o2Xjx5 for ; Tue, 5 Jul 2011 01:08:51 -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 C911921F873F for ; Tue, 5 Jul 2011 01:08:51 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1Qe0gd-0006PX-OR; Tue, 05 Jul 2011 01:08:51 -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: Tue, 05 Jul 2011 08:08:51 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/164 Message-ID: <057.e272ad5f1c35235dea46dad8b5931712@trac.tools.ietf.org> X-Trac-Ticket-ID: 164 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] #164: OPTIONS and TRACE to return always 501 in HTTP-CoAP binding 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, 05 Jul 2011 08:08:52 -0000 #164: OPTIONS and TRACE to return always 501 in HTTP-CoAP binding During review of coap-06 Carsten and Cullen suggested that the OPTIONS and TRACE sections are currently useless as currently written. The current text says that the proxy answers when Max-Forwards=0 but gives a 501 otherwise. To simplify the mapping further, thus tickets is to always return a 501 for both the OPTIONS and TRACE methods. -- ----------------------------------+----------------------------------------- Reporter: zach@… | Owner: zach@… Type: protocol enhancement | Status: new Priority: minor | Milestone: Component: coap | Version: Severity: - | Keywords: ----------------------------------+----------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Tue Jul 5 02:41:36 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 9F6B121F85E9 for ; Tue, 5 Jul 2011 02:41:36 -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 dP0iPZOkepw0 for ; Tue, 5 Jul 2011 02:41:36 -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 51BEA21F8606 for ; Tue, 5 Jul 2011 02:41:36 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1Qe28N-0008T1-BR; Tue, 05 Jul 2011 02:41:35 -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: Tue, 05 Jul 2011 09:41:35 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/164#comment:1 Message-ID: <066.c79add6c9cc635b9edcb0c3db06aabd4@trac.tools.ietf.org> References: <057.e272ad5f1c35235dea46dad8b5931712@trac.tools.ietf.org> X-Trac-Ticket-ID: 164 In-Reply-To: <057.e272ad5f1c35235dea46dad8b5931712@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] #164: OPTIONS and TRACE to return always 501 in HTTP-CoAP binding 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, 05 Jul 2011 09:41:36 -0000 #164: OPTIONS and TRACE to return always 501 in HTTP-CoAP binding Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Done in coap-07. -- ----------------------------------+----------------------------------------- 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 Tue Jul 5 04:22:12 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 3C62021F865F for ; Tue, 5 Jul 2011 04:22:12 -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 EsAxBEX7cWj4 for ; Tue, 5 Jul 2011 04:22:11 -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 D632C21F865A for ; Tue, 5 Jul 2011 04:22:11 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1Qe3hd-0007a1-RJ; Tue, 05 Jul 2011 04:22:05 -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, zach@sensinode.com X-Trac-Project: core Date: Tue, 05 Jul 2011 11:22:05 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/148#comment:1 Message-ID: <060.0af8152bdef7d7569c6947ad18bf3825@trac.tools.ietf.org> References: <051.46ad6891968ef77f92643e00277adff8@trac.tools.ietf.org> X-Trac-Ticket-ID: 148 In-Reply-To: <051.46ad6891968ef77f92643e00277adff8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: 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] #148: Explain that message sizes should be chosen consciously 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, 05 Jul 2011 11:22:12 -0000 #148: Explain that message sizes should be chosen consciously Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Done, new section added to coap-07. -- --------------------------------+------------------------------------------- Reporter: cabo@… | Owner: cabo@… 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 Tue Jul 5 04:38:37 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 C80E221F861C for ; Tue, 5 Jul 2011 04:38:37 -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 Ze7ZtBhM344N for ; Tue, 5 Jul 2011 04:38:37 -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 7806521F85C4 for ; Tue, 5 Jul 2011 04:38:37 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1Qe3xY-0005gN-HS; Tue, 05 Jul 2011 04:38:32 -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, zach@sensinode.com X-Trac-Project: core Date: Tue, 05 Jul 2011 11:38:32 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/147#comment:1 Message-ID: <060.06f219b0ce428160888a95e4adfea225@trac.tools.ietf.org> References: <051.8351ef873fe53636c3dcd4f8d8ba4313@trac.tools.ietf.org> X-Trac-Ticket-ID: 147 In-Reply-To: <051.8351ef873fe53636c3dcd4f8d8ba4313@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: 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] #147: Explain the difference between a Token and the Token Option 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, 05 Jul 2011 11:38:37 -0000 #147: Explain the difference between a Token and the Token Option Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Text added to Section 5.10.1. -- --------------------------------+------------------------------------------- Reporter: cabo@… | Owner: cabo@… 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 Tue Jul 5 04:47:20 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 B55E311E8072 for ; Tue, 5 Jul 2011 04:47:20 -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=[AWL=0.000, 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 7SFS-vSRCzaQ for ; Tue, 5 Jul 2011 04:47:20 -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 63C8A9E8005 for ; Tue, 5 Jul 2011 04:47:20 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1Qe463-0002Iu-SU; Tue, 05 Jul 2011 04:47: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: Tue, 05 Jul 2011 11:47:19 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/156#comment:1 Message-ID: <066.16b8cb45d54cb551f5bd1a9afbee8292@trac.tools.ietf.org> References: <057.dd42b4c72c7d62f11b05f9e63f961a46@trac.tools.ietf.org> X-Trac-Ticket-ID: 156 In-Reply-To: <057.dd42b4c72c7d62f11b05f9e63f961a46@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] #156: Mandatory to implement security 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, 05 Jul 2011 11:47:20 -0000 #156: Mandatory to implement security Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Done in coap-07. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: editorial | Status: closed Priority: minor | Milestone: Component: coap | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: core From esko.dijk@philips.com Tue Jul 5 04:53:16 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 DE85D21F8621 for ; Tue, 5 Jul 2011 04:53:16 -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=[AWL=0.001, BAYES_00=-2.599, 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 bUl0xSsg6MgK for ; Tue, 5 Jul 2011 04:53:16 -0700 (PDT) Received: from DB3EHSOBE002.bigfish.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id EF7D421F861D for ; Tue, 5 Jul 2011 04:53:15 -0700 (PDT) Received: from mail111-db3-R.bigfish.com (10.3.81.243) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.22; Tue, 5 Jul 2011 11:53:14 +0000 Received: from mail111-db3 (localhost.localdomain [127.0.0.1]) by mail111-db3-R.bigfish.com (Postfix) with ESMTP id CB4F4830081; Tue, 5 Jul 2011 11:53:14 +0000 (UTC) X-SpamScore: -13 X-BigFish: VPS-13(zz217bL15d6O9251Jzz1202hzz8275bhz2dh2a8h668h839h93fh) X-Forefront-Antispam-Report: CIP:168.87.56.20; KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI Received: from mail111-db3 (localhost.localdomain [127.0.0.1]) by mail111-db3 (MessageSwitch) id 1309866794655700_9510; Tue, 5 Jul 2011 11:53:14 +0000 (UTC) Received: from DB3EHSMHS013.bigfish.com (unknown [10.3.81.247]) by mail111-db3.bigfish.com (Postfix) with ESMTP id 91CE8DB004B; Tue, 5 Jul 2011 11:53:14 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by DB3EHSMHS013.bigfish.com (10.3.87.113) with Microsoft SMTP Server (TLS) id 14.1.225.22; Tue, 5 Jul 2011 11:53:14 +0000 Received: from NLHILEXH04.connect1.local (172.16.153.45) by connect1.philips.com (172.16.156.43) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 5 Jul 2011 13:52:59 +0200 Received: from NLCLUEXM03.connect1.local ([172.16.153.29]) by NLHILEXH04.connect1.local ([172.16.153.45]) with mapi; Tue, 5 Jul 2011 13:51:29 +0200 From: "Dijk, Esko" To: "cabo@tzi.org" , "zach@sensinode.com" Date: Tue, 5 Jul 2011 13:52:53 +0200 Thread-Topic: core-block-03 issue in definition of the 4.13 response Thread-Index: Acw7BaKQ819ANpuLTHimVtnc0VKknwAAZ0uw Message-ID: References: <051.46ad6891968ef77f92643e00277adff8@trac.tools.ietf.org> <060.0af8152bdef7d7569c6947ad18bf3825@trac.tools.ietf.org> In-Reply-To: <060.0af8152bdef7d7569c6947ad18bf3825@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {8E554833-01E9-4E73-9958-90D49CD56D0B} x-cr-hashedpuzzle: Ctyi D3XV D9mI FFRM Fqb6 KJe4 NQHk TMfT TxB4 XE+e ZBcn ZNix ZY1Q Zhr1 cdrQ dgpz; 3; YwBhAGIAbwBAAHQAegBpAC4AbwByAGcAOwBjAG8AcgBlAEAAaQBlAHQAZgAuAG8AcgBnADsAegBhAGMAaABAAHMAZQBuAHMAaQBuAG8AZABlAC4AYwBvAG0A; Sosha1_v1; 7; {8E554833-01E9-4E73-9958-90D49CD56D0B}; ZQBzAGsAbwAuAGQAaQBqAGsAQABwAGgAaQBsAGkAcABzAC4AYwBvAG0A; Tue, 05 Jul 2011 11:52:53 GMT; YwBvAHIAZQAtAGIAbABvAGMAawAtADAAMwAgAGkAcwBzAHUAZQAgAGkAbgAgAGQAZQBmAGkAbgBpAHQAaQBvAG4AIABvAGYAIAB0AGgAZQAgADQALgAxADMAIAByAGUAcwBwAG8AbgBzAGUA acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org" Subject: [core] core-block-03 issue in definition of the 4.13 response 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, 05 Jul 2011 11:53:17 -0000 RGVhciBhdXRob3JzLA0KDQpjb3JlLWJsb2NrLTAzICJvdmVybG9hZHMiIHRoZSBtZWFuaW5nIG9m IHRoZSA0LjEzIGVycm9yIHJlc3BvbnNlIGNvZGUgKFJlcXVlc3QgRW50aXR5IFRvbyBMYXJnZSku IEkgc2VlIGhlcmUgYW4gaW50ZXJvcGVyYWJpbGl0eSBwcm9ibGVtIGlmIGRpZmZlcmVudCBpbXBs ZW1lbnRlcnMgYXR0cmlidXRlIGRpZmZlcmVudCBtZWFuaW5ncyB0byB0aGUgNC4xMyByZXNwb25z ZS4NCg0KV2l0aCB0aGUgb3ZlcmxvYWRlZCBtZWFuaW5nIG9mIDQuMTMgSSBtZWFuOiAiVGhlIGVy cm9yIGNvZGUgNC4xMyAoUmVxdWVzdCBFbnRpdHkgVG9vIExhcmdlKSBjYW4gYmUgcmV0dXJuZWQg YXQgYW55IHRpbWUgYnkgYSBzZXJ2ZXIgdGhhdCBkb2VzIG5vdCBjdXJyZW50bHkgaGF2ZSB0aGUg cmVzb3VyY2VzIHRvIHN0b3JlIGJsb2NrcyBmb3IgYSBibG9jay13aXNlIHJlcXVlc3QgcGF5bG9h ZCB0cmFuc2ZlciB0aGF0IGl0IHdvdWxkIGludGVuZCB0byBpbXBsZW1lbnQgaW4gYW4gYXRvbWlj IGZhc2hpb24uIg0KDQpUaGUgb3JpZ2luYWwgbWVhbmluZyBvZiA0LjEzIChwYXlsb2FkIHRydW5j YXRlZCkgZnJvbSBjb2FwLTA2IHN0aWxsIGhvbGRzIGJlY2F1c2UgYmxvY2stMDMgZG9lcyBub3Qg cmV2b2tlIGl0LiBTbyBpZiBhIGNsaWVudCBzZW5kcyBhIGZpcnN0IHJlcXVlc3Qgd2l0aCBCbG9j ayBPcHRpb24sIGFuZCB0aGUgcGFja2V0IGlzIHRydW5jYXRlZCBhdCB0aGUgc2VydmVyIHNpZGUg ZHVlIHRvIGEgdG9vLWxhcmdlIHBhY2tldCwgdGhlIHNlcnZlciByZXNwb25kcyA0LjEzLiBCdXQg bm93IHRoZSBjbGllbnQgbWF5IGludGVycHJldCAocGVyIGJsb2NrLTAzKSB0aGlzIHJlc3BvbnNl IGFzICJ0aGUgc2VydmVyIGRvZXNuJ3QgaGF2ZSByZXNvdXJjZXMgdG8gc3RvcmUgYmxvY2tzIiBl dmVuIHRob3VnaCB0aGF0IGlzIG5vdCB0aGUgY2FzZS4gVGhpcyBpcyBhIGNsZWFyIGNhc2Ugd2hl cmUgY2xpZW50IGltcGxlbWVudGVycyBtYXkgYXNzdW1lIGRpZmZlcmVudCBtZWFuaW5ncyBvZiBh IDQuMTMuDQoNCk9uZSBzb2x1dGlvbiBtYXkgYmUgdG8gcG9pbnQgb3V0IGluIHRoZSBibG9jay0w MyB0ZXh0IHRoYXQgYSA0LjEzIHJlc3BvbnNlIHRvIGEgcmVxdWVzdCB3aXRoIEJsb2NrIE9wdGlv biBtYXkgbWVhbiBlaXRoZXIgInRydW5jYXRlZCIgb3IgImRvIG5vdCBoYXZlIHJlc291cmNlcyBm b3IgYmxvY2t3aXNlIiwgbm90IG5lY2Vzc2FyaWx5IHRoZSBsYXR0ZXIgb25seS4gQW5vdGhlciBz b2x1dGlvbiBpcyB0byBkZWZpbmUgdGhhdCBhIDQuMTMgZm9yIGEgZmlyc3QgYmxvY2sgbWVhbnMg InRydW5jYXRlZCIsIHdoaWxlIGZvciBhIHNlY29uZCBibG9jayBpdCBtZWFucyAiZG8gbm90IGhh dmUgcmVzb3VyY2VzIi4NCg0KYmVzdCByZWdhcmRzLA0KRXNrbw0KDQoNCkVza28gRGlqaw0KDQpQ aGlsaXBzIENvcnBvcmF0ZSBUZWNobm9sb2dpZXMsIFJlc2VhcmNoDQpIaWdoIFRlY2ggQ2FtcHVz IDM0LCBFaW5kaG92ZW4sIFRoZSBOZXRoZXJsYW5kcw0KZXNrby5kaWprQHBoaWxpcHMuY29tDQoN Cg0KDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkgYmUgY29u ZmlkZW50aWFsIGFuZCBsZWdhbGx5IHByb3RlY3RlZCB1bmRlciBhcHBsaWNhYmxlIGxhdy4gVGhl IG1lc3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2VlKHMpLiBJZiB5b3Ug YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0 aGF0IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24sIG9yIHJlcHJvZHVjdGlvbiBv ZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVs LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0 aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUg b3JpZ2luYWwgbWVzc2FnZS4NCg== From prvs=01678E9B5E=guido.moritz@uni-rostock.de Tue Jul 5 08:25:16 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 7B4459E8019 for ; Tue, 5 Jul 2011 08:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 AGoRPsZ7NEIM for ; Tue, 5 Jul 2011 08:25:15 -0700 (PDT) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB029E8018 for ; Tue, 5 Jul 2011 08:25:15 -0700 (PDT) From: Guido Moritz To: References: <057.213b5d9d1d62cee7319a2d6f5e3e5d21@trac.tools.ietf.org> In-Reply-To: <057.213b5d9d1d62cee7319a2d6f5e3e5d21@trac.tools.ietf.org> Date: Tue, 5 Jul 2011 17:25:05 +0200 Message-ID: <009701cc3b27$b7555d10$26001730$@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHH7sh8VZtg88aOR42vPk1MTGJ43pTmbG4w Content-Language: de X-Originating-IP: [139.30.201.226] Subject: Re: [core] #163: Content-negotiation 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, 05 Jul 2011 15:25:16 -0000 Dear all, Indeed, I like the idea of some kind of content negotiation. But I = existing CoAP draft is very strict in many points about what is allowed = by which endpoint and e.g. how a response must be interpreted.=20 This proposal instead seems not to be straight forward. A client can = include the preferred media type, but the server does not have to care = about it?!=20 How many media types will be supported by a typical CoAP implementation? = For example if a client does not care about it, it will not include any = Accept option. But if the client is only able to process XML and the = client expresses this in the Accept option, a JSON media type in the = response makes no sense. This can be seen as the typical way of = negotiating the capabilities between the endpoints. But is the provided = media type coupled to this specific resource, to this specific query = (e.g. by the query option) or to the complete server? Again, this is the = way how HTTP handles this issue, but CoAP much stricter in such points = is up to now. As result, I would suggest to have a specific option whereby a client = can express that the Accept media types are preferred, but the client is = willing to process also other media types (e.g. by a dedicated media = type 'any' or by including an empty media type option as last Accept = option). If this 'any' media type is not included, the client strictly = requires one of the media types indicated by the Accept options. If no = fitting media type is found in the Accept option, the server just = responds with a 4.15. My 2cents, Guido > -----Urspr=C3=BCngliche Nachricht----- > Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag = von > core issue tracker > Gesendet: Dienstag, 5. Juli 2011 10:05 > An: zach@sensinode.com > Cc: core@ietf.org > Betreff: [core] #163: Content-negotiation >=20 > #163: Content-negotiation >=20 > I propose a ticket to add content-type preference indication to = coap-07. > In particular, the proposal is to add a new Elective option called > "Accept". Here is text lifted from coap-misc-08: >=20 > "The CoAP Accept option would > when included one or more times in a request, carry one or more = media > types, each of which is an acceptable media type for the client, in > the order of preference. If no Accept option is given, the client > does not express a preference. The client prefers the = representation > returned by the > server to be in one of the media types, but is willing to accept > the response also if the server returns a representation in a > different media type." >=20 > One minor side effect of this change, is that the ct=3D attribute of = core- > link-format would need to be allowed multiple times. This attribute > definition should anyways be moved from core-link-format and placed = in > core-coap as it is CoAP specific. >=20 > -- > = ----------------------------------+--------------------------------------= --- > Reporter: zach@=E2=80=A6 | Owner: = zach@=E2=80=A6 > Type: protocol enhancement | Status: new > Priority: minor | Milestone: > Component: coap | Version: > Severity: - | Keywords: > = ----------------------------------+--------------------------------------= --- >=20 > Ticket URL: > core >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From trac+core@trac.tools.ietf.org Wed Jul 6 00:55:52 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 AD96221F85FE for ; Wed, 6 Jul 2011 00:55:52 -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 D+Y9XCLB4UJ9 for ; Wed, 6 Jul 2011 00:55:52 -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 5768A21F869D for ; Wed, 6 Jul 2011 00:55:52 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QeMxQ-0000YB-5y; Wed, 06 Jul 2011 00:55:40 -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, tianlinyi@huawei.com, zach@sensinode.com X-Trac-Project: core Date: Wed, 06 Jul 2011 07:55:40 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/161#comment:2 Message-ID: <066.7a938305ead144208abb2e0101beac04@trac.tools.ietf.org> References: <057.b32fa055beb54b0a5bae0f7915fff78c@trac.tools.ietf.org> X-Trac-Ticket-ID: 161 In-Reply-To: <057.b32fa055beb54b0a5bae0f7915fff78c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, tianlinyi@huawei.com, 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] #161: Registration for 2-byte media type codes 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: Wed, 06 Jul 2011 07:55:52 -0000 #161: Registration for 2-byte media type codes Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Done, added this text to Section 11.3: "The IANA policy for additions in the range 256-65535 inclusive is "First Come First Served" as described in [RFC5226]." -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: hartke@… Type: task | Status: closed Priority: minor | Milestone: Component: coap | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Wed Jul 6 00:56: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 D381121F869D for ; Wed, 6 Jul 2011 00:56: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 LoCvbg87jNpa for ; Wed, 6 Jul 2011 00:56:03 -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 8859121F85FE for ; Wed, 6 Jul 2011 00:56:03 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QeMxn-0000YT-Gn; Wed, 06 Jul 2011 00:56:03 -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: Wed, 06 Jul 2011 07:56:03 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/154#comment:1 Message-ID: <066.84371616fac32870eb6ae75709300709@trac.tools.ietf.org> References: <057.d9676aeeb0b1c844122c71cec07dc9e3@trac.tools.ietf.org> X-Trac-Ticket-ID: 154 In-Reply-To: <057.d9676aeeb0b1c844122c71cec07dc9e3@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] #154: Separate coaps:// schema and port for DTLS 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: Wed, 06 Jul 2011 07:56:03 -0000 #154: Separate coaps:// schema and port for DTLS Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Done in coap-07. -- ----------------------------------+----------------------------------------- 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 Wed Jul 6 01:16:48 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 76A6221F8584 for ; Wed, 6 Jul 2011 01:16:48 -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 tEvCw4U1by3Z for ; Wed, 6 Jul 2011 01:16:48 -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 1D24821F8581 for ; Wed, 6 Jul 2011 01:16:48 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QeNHm-00033I-6r; Wed, 06 Jul 2011 01:16: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: cabo@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Wed, 06 Jul 2011 08:16:42 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/151#comment:1 Message-ID: <066.092c405fc4a477e6035ec52f401964ba@trac.tools.ietf.org> References: <057.a0dfde1ed2d36d2bf749f251f2a956f4@trac.tools.ietf.org> X-Trac-Ticket-ID: 151 In-Reply-To: <057.a0dfde1ed2d36d2bf749f251f2a956f4@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: 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] #151: Clarify matching rules for messages and tokens 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: Wed, 06 Jul 2011 08:16:48 -0000 #151: Clarify matching rules for messages and tokens Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Done. In addition it was clarified that multiple strategies for keeping the Message ID variable can be employed. For example a single variable, or a variable for each prefix or destination address for end-points dealing with large numbers of transactions. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: cabo@… Type: protocol defect | Status: closed Priority: minor | Milestone: Component: coap | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: core From matthieu.vial@non.schneider-electric.com Wed Jul 6 01:20:26 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 5234821F86A0; Wed, 6 Jul 2011 01:20:26 -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=[AWL=0.300, BAYES_00=-2.599, 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 qzTnYkSZlASl; Wed, 6 Jul 2011 01:20:25 -0700 (PDT) Received: from mailX03.eud.schneider-electric.com (mailx03.eud.schneider-electric.com [205.167.7.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4886421F8685; Wed, 6 Jul 2011 01:20:25 -0700 (PDT) Received: from ateui02.Schneider-Electric.com ([10.198.14.10]) by mailX03.eud.schneider-electric.com with ESMTP id 2011070609571297-176912 ; Wed, 6 Jul 2011 09:57:12 +0200 In-Reply-To: To: matthieu.vial@non.schneider-electric.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 From: matthieu.vial@non.schneider-electric.com Message-ID: Date: Wed, 6 Jul 2011 10:20:01 +0200 X-MIMETrack: Serialize by Router on ATEUI02.Schneider-Electric.com/T/SVR/Schneider at 06/07/2011 10:20:16, Serialize complete at 06/07/2011 10:20:16, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 06/07/2011 09:57:12, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 06/07/2011 09:57:15, Serialize complete at 06/07/2011 09:57:15 Content-Type: text/plain; charset="US-ASCII" Cc: core-bounces@ietf.org, core WG Subject: [core] RE RE Fwd: New Version Notification for draft-shelby-core-resource-directory-00.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, 06 Jul 2011 08:20:26 -0000 Hi all, One more comment about rd. Now that CoAP have 2 schemes coap and coaps how the rd selects the scheme when it translates the URI reference in the posted resource description to an absolute URI. Do we need a "secure" attribute in link-format or the EP must post a resource description with absolute URIs and the appropriate scheme? Matthieu From trac+core@trac.tools.ietf.org Wed Jul 6 02:01:53 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 194D121F85FB for ; Wed, 6 Jul 2011 02:01:53 -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=[AWL=0.000, 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 pkn31yt7b7NR for ; Wed, 6 Jul 2011 02:01:52 -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 BD28F21F85FA for ; Wed, 6 Jul 2011 02:01:52 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QeNzQ-0000kX-0G; Wed, 06 Jul 2011 02:01:48 -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, zach@sensinode.com X-Trac-Project: core Date: Wed, 06 Jul 2011 09:01:47 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/155#comment:1 Message-ID: <066.e98d71c41d1763491a82f22c2ec8715f@trac.tools.ietf.org> References: <057.5a5705e0046569ddd481206733703337@trac.tools.ietf.org> X-Trac-Ticket-ID: 155 In-Reply-To: <057.5a5705e0046569ddd481206733703337@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: 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] #155: If-Match and If-None-Match options 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: Wed, 06 Jul 2011 09:01:53 -0000 #155: If-Match and If-None-Match options Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: If-Match and If-None-Match: * have been added to coap-07. -- ----------------------------------+----------------------------------------- Reporter: zach@… | Owner: cabo@… Type: protocol enhancement | Status: closed Priority: minor | Milestone: Component: coap | Version: Severity: - | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Ticket URL: core From zach@sensinode.com Wed Jul 6 04:36:40 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 98FB121F85D6 for ; Wed, 6 Jul 2011 04:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, 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 F8z98Ompsp1R for ; Wed, 6 Jul 2011 04:36:39 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8FB21F85B8 for ; Wed, 6 Jul 2011 04:36:38 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p66BaYrb015367 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Jul 2011 14:36:34 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-394-932513829; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <009701cc3b27$b7555d10$26001730$@uni-rostock.de> Date: Wed, 6 Jul 2011 14:36:35 +0300 Message-Id: References: <057.213b5d9d1d62cee7319a2d6f5e3e5d21@trac.tools.ietf.org> <009701cc3b27$b7555d10$26001730$@uni-rostock.de> To: Guido Moritz X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] #163: Content-negotiation 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, 06 Jul 2011 11:36:40 -0000 --Apple-Mail-394-932513829 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Guido, On Jul 5, 2011, at 6:25 PM, Guido Moritz wrote: > Dear all, >=20 > Indeed, I like the idea of some kind of content negotiation. But I = existing CoAP draft is very strict in many points about what is allowed = by which endpoint and e.g. how a response must be interpreted.=20 >=20 > This proposal instead seems not to be straight forward. A client can = include the preferred media type, but the server does not have to care = about it?!=20 I would say the philosophy of CoAP is to specify things so as to keep = implementations simple, and to allow requests to gracefully succeed with = non-critical mismatches (important in allowing minimal implementations). = Of course we need to keep resource interactions correct, to do that the = server and protocol behavior is pretty strict. Not sure I would describe = the interpretation of responses by a client to be strict at all, it is = really up to the client what it wants to do with a resource = representation. =20 > How many media types will be supported by a typical CoAP = implementation? For example if a client does not care about it, it will = not include any Accept option. But if the client is only able to process = XML and the client expresses this in the Accept option, a JSON media = type in the response makes no sense. This can be seen as the typical way = of negotiating the capabilities between the endpoints. But is the = provided media type coupled to this specific resource, to this specific = query (e.g. by the query option) or to the complete server? Again, this = is the way how HTTP handles this issue, but CoAP much stricter in such = points is up to now. The HTTP use case for content-type negotiation is different in my = opinion, where both the client and server might support large numbers of = media types, and have no (or very little) a-priori knowledge of what the = other might support. =20 =46rom my experience so far, the CoAP M2M use cases involve servers who = offer a representation in a few different pre-determined media types. = Clients know these types a priori through standardization (as in the = case of ETSI or ZigBee) or via the Link Format. Thus the main intention = is to allow a client to show preference for which of those known media = types is preferred. However there may always be mis-matches, for = example servers supporting new media-types out of the standard or not = updating link descriptions very often. Making the Accept option elective seems to fit the CoAP model well in my = opinion. It allows requests to still succeed even if some servers do not = support Accept, and allows requests that don't match to still succeed = even if a match isn't found. If the client doesn't find the = representation useful, it can just ignore it. So keep in mind that = there are two reasons the client may not get a content-type it put in = Accept options, either Accept is not supported by the server, or the = server doesn't have any of those preferred content-types. > As result, I would suggest to have a specific option whereby a client = can express that the Accept media types are preferred, but the client is = willing to process also other media types (e.g. by a dedicated media = type 'any' or by including an empty media type option as last Accept = option). If this 'any' media type is not included, the client strictly = requires one of the media types indicated by the Accept options. If no = fitting media type is found in the Accept option, the server just = responds with a 4.15. In practice what you are suggesting is to make the Accept option = Critical instead of Elective, and treating an empty Accept option as the = equivalent of HTTP Accept */*. That would of course mean that servers = not supporting Accept would fail, requiring a second request without = Accept. Is that any more efficient than possibly receiving a = representation the client might have to throw away on the first shot? Zach >=20 > My 2cents, > Guido >=20 >> -----Urspr=FCngliche Nachricht----- >> Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag = von >> core issue tracker >> Gesendet: Dienstag, 5. Juli 2011 10:05 >> An: zach@sensinode.com >> Cc: core@ietf.org >> Betreff: [core] #163: Content-negotiation >>=20 >> #163: Content-negotiation >>=20 >> I propose a ticket to add content-type preference indication to = coap-07. >> In particular, the proposal is to add a new Elective option called >> "Accept". Here is text lifted from coap-misc-08: >>=20 >> "The CoAP Accept option would >> when included one or more times in a request, carry one or more = media >> types, each of which is an acceptable media type for the client, in >> the order of preference. If no Accept option is given, the client >> does not express a preference. The client prefers the = representation >> returned by the >> server to be in one of the media types, but is willing to accept >> the response also if the server returns a representation in a >> different media type." >>=20 >> One minor side effect of this change, is that the ct=3D attribute of = core- >> link-format would need to be allowed multiple times. This attribute >> definition should anyways be moved from core-link-format and placed = in >> core-coap as it is CoAP specific. >>=20 >> -- >> = ----------------------------------+---------------------------------------= -- >> Reporter: zach@=85 | Owner: zach@=85 >> Type: protocol enhancement | Status: new >> Priority: minor | Milestone: >> Component: coap | Version: >> Severity: - | Keywords: >> = ----------------------------------+---------------------------------------= -- >>=20 >> Ticket URL: >> core >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com 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-394-932513829 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDcwNjExMzYz NVowIwYJKoZIhvcNAQkEMRYEFGxJVZ08SCGqUXm+aZK79g5xAro2MIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAFIkCP9/YsHpR0jpfkgQ5hUP8bCdKgyjdRfW9gtgvxu8mwY7RObL/p// tYtlnu8SG3xWQFw73hMbUX4F+AmjubLDUHZUL4IXQ3aAZtgJAfJZJod9mHBtm6vDH6G5xB9ePx+S OM1dsq8RpRCj0FqWGthy0cLztbhutg/OROT5wW0NEMCvk2YdI6ztmdVMeTPSXfZ2etWgQzj71563 uLa8wHF+nLctuFLEnqjBmRjaOdsEk0obxiM+sSbK9FxghF26BE5CwpoZjnnGHzPbE8+k3Qepi+Vw PVi0UPgEXCTT3ml4S3qUMSkimkFkJqYzz+mBq3eQ64if/WIeWQT02/x0mGIAAAAAAAA= --Apple-Mail-394-932513829-- From prvs=4168804501=guido.moritz@uni-rostock.de Wed Jul 6 05:32:22 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 0BFD921F8678 for ; Wed, 6 Jul 2011 05:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 UraHAiKRskkA for ; Wed, 6 Jul 2011 05:32:21 -0700 (PDT) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id 56FF321F8605 for ; Wed, 6 Jul 2011 05:32:20 -0700 (PDT) From: Guido Moritz To: 'Zach Shelby' References: <057.213b5d9d1d62cee7319a2d6f5e3e5d21@trac.tools.ietf.org> <009701cc3b27$b7555d10$26001730$@uni-rostock.de> In-Reply-To: Date: Wed, 6 Jul 2011 14:32:17 +0200 Message-ID: <004701cc3bd8$bdeecba0$39cc62e0$@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHH7sh8VZtg88aOR42vPk1MTGJ43gKePwIRAVTMJBuUyDjuUA== Content-Language: de X-Originating-IP: [139.30.201.226] Cc: core@ietf.org Subject: Re: [core] #163: Content-negotiation 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, 06 Jul 2011 12:32:22 -0000 I would not agree that servers are likely to support several media types = in parallel. But I totally agree that it is in the responsibility of = further standardization bodies to define domain specific 'profiles', including a limited number of media types. But in a M2M scenario, why should a client prefer any media type? Based = our measurements, even on 8bit platforms, parsing either XML, EXI, JSON our whatever has never been the bottleneck by means of timing. It is always about the required ROM/RAM usage of the parsers. So if I can understand = more than one media type, why should I prefer one? I don't have a use case = for this. I would say it is more important to indicate that the media types = in the Accept are not preferred, but the only ones the client can parse at = all. To relax this, in coap-misc two Accept options are defined, one elective = and one critical. Maybe we can have both? Guido > -----Urspr=FCngliche Nachricht----- > Von: Zach Shelby [mailto:zach@sensinode.com] > Gesendet: Mittwoch, 6. Juli 2011 13:37 > An: Guido Moritz > Cc: core@ietf.org > Betreff: Re: [core] #163: Content-negotiation >=20 > Guido, >=20 > On Jul 5, 2011, at 6:25 PM, Guido Moritz wrote: >=20 > > Dear all, > > > > Indeed, I like the idea of some kind of content negotiation. But I existing CoAP > draft is very strict in many points about what is allowed by which endpoint and > e.g. how a response must be interpreted. > > > > This proposal instead seems not to be straight forward. A client can include > the preferred media type, but the server does not have to care about = it?! >=20 > I would say the philosophy of CoAP is to specify things so as to keep > implementations simple, and to allow requests to gracefully succeed = with non- > critical mismatches (important in allowing minimal implementations). = Of > course we need to keep resource interactions correct, to do that the server and > protocol behavior is pretty strict. Not sure I would describe the interpretation of > responses by a client to be strict at all, it is really up to the = client what it wants > to do with a resource representation. >=20 > > How many media types will be supported by a typical CoAP = implementation? > For example if a client does not care about it, it will not include = any Accept > option. But if the client is only able to process XML and the client expresses this > in the Accept option, a JSON media type in the response makes no = sense. This > can be seen as the typical way of negotiating the capabilities between = the > endpoints. But is the provided media type coupled to this specific resource, to > this specific query (e.g. by the query option) or to the complete = server? Again, > this is the way how HTTP handles this issue, but CoAP much stricter in such > points is up to now. >=20 > The HTTP use case for content-type negotiation is different in my = opinion, > where both the client and server might support large numbers of media types, > and have no (or very little) a-priori knowledge of what the other = might support. >=20 > From my experience so far, the CoAP M2M use cases involve servers who offer > a representation in a few different pre-determined media types. = Clients know > these types a priori through standardization (as in the case of ETSI = or ZigBee) or > via the Link Format. Thus the main intention is to allow a client to = show > preference for which of those known media types is preferred. However there > may always be mis-matches, for example servers supporting new = media-types > out of the standard or not updating link descriptions very often. >=20 > Making the Accept option elective seems to fit the CoAP model well in = my > opinion. It allows requests to still succeed even if some servers do = not support > Accept, and allows requests that don't match to still succeed even if = a match > isn't found. If the client doesn't find the representation useful, it = can just ignore > it. So keep in mind that there are two reasons the client may not get = a content- > type it put in Accept options, either Accept is not supported by the server, or > the server doesn't have any of those preferred content-types. >=20 > > As result, I would suggest to have a specific option whereby a = client can > express that the Accept media types are preferred, but the client is willing to > process also other media types (e.g. by a dedicated media type 'any' = or by > including an empty media type option as last Accept option). If this = 'any' media > type is not included, the client strictly requires one of the media = types indicated > by the Accept options. If no fitting media type is found in the Accept option, the > server just responds with a 4.15. >=20 > In practice what you are suggesting is to make the Accept option = Critical > instead of Elective, and treating an empty Accept option as the = equivalent of > HTTP Accept */*. That would of course mean that servers not supporting > Accept would fail, requiring a second request without Accept. Is that = any more > efficient than possibly receiving a representation the client might = have to throw > away on the first shot? >=20 > Zach >=20 > > > > My 2cents, > > Guido > > > >> -----Urspr=FCngliche Nachricht----- > >> Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im = Auftrag von > >> core issue tracker > >> Gesendet: Dienstag, 5. Juli 2011 10:05 > >> An: zach@sensinode.com > >> Cc: core@ietf.org > >> Betreff: [core] #163: Content-negotiation > >> > >> #163: Content-negotiation > >> > >> I propose a ticket to add content-type preference indication to coap-07. > >> In particular, the proposal is to add a new Elective option called > >> "Accept". Here is text lifted from coap-misc-08: > >> > >> "The CoAP Accept option would > >> when included one or more times in a request, carry one or more = media > >> types, each of which is an acceptable media type for the client, = in > >> the order of preference. If no Accept option is given, the = client > >> does not express a preference. The client prefers the = representation > >> returned by the > >> server to be in one of the media types, but is willing to = accept > >> the response also if the server returns a representation in a > >> different media type." > >> > >> One minor side effect of this change, is that the ct=3D attribute = of core- > >> link-format would need to be allowed multiple times. This attribute > >> definition should anyways be moved from core-link-format and placed = in > >> core-coap as it is CoAP specific. > >> > >> -- > >> ----------------------------------+--------------------------------------= --- > >> Reporter: zach@=85 | Owner: zach@=85 > >> Type: protocol enhancement | Status: new > >> Priority: minor | Milestone: > >> Component: coap | Version: > >> Severity: - | Keywords: > >> ----------------------------------+--------------------------------------= --- > >> > >> Ticket URL: > >> core > >> > >> _______________________________________________ > >> core mailing list > >> core@ietf.org > >> https://www.ietf.org/mailman/listinfo/core > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core >=20 > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 From fluffy@cisco.com Wed Jul 6 14:25:10 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 BC78721F8AC0 for ; Wed, 6 Jul 2011 14:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.529 X-Spam-Level: X-Spam-Status: No, score=-110.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 cnC8SjJvcx-l for ; Wed, 6 Jul 2011 14:25:10 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id 0A45521F8ABE for ; Wed, 6 Jul 2011 14:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=816; q=dns/txt; s=iport; t=1309987509; x=1311197109; h=from:content-transfer-encoding:subject:date:references: to:message-id:mime-version; bh=f2CwOWGFm6I1chYBO7n78wER4XgQ4k/FxWC98//2M6M=; b=G+xCVVOZug7JZomEsTVxnqtsP5/2DAkN2NXGLD3mkyCJLdheV0U9kFeV ZLt/+mNYgsNO7x8l8cpDOmWnrnoxh5nxHqdi6dMDvUmvFCC/7JjnNFN2D frwahOk0+F+fOi7I+NB+dfuoqeYun04jXcvlOMNSi20cwec+tDV8FHNlW U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAErSFE6rRDoI/2dsb2JhbABTqAt3iHqlC54MhjcEh0aKe4R6i2I X-IronPort-AV: E=Sophos;i="4.65,489,1304294400"; d="scan'208";a="362713978" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-5.cisco.com with ESMTP; 06 Jul 2011 21:25:02 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p66LP2gw021376 for ; Wed, 6 Jul 2011 21:25:02 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Jul 2011 15:25:01 -0600 References: <20110706205339.F08C821F8C06@ietfa.amsl.com> To: core WG Message-Id: <6B00ECB7-81F3-4B23-9417-322D6FD68C0F@cisco.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] Fwd: CORE - Requested sessions have been scheduled for IETF 81 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, 06 Jul 2011 21:25:10 -0000 FYI Begin forwarded message: > From: IETF Secretariat > Date: July 6, 2011 2:53:39 PM MDT > To: fluffy@cisco.com > Cc: cabo@tzi.org, presnick@qualcomm.com, stpeter@stpeter.im, = session-request@ietf.org > Subject: CORE - Requested sessions have been scheduled for IETF 81=20 >=20 > Dear Cullen Jennings, >=20 > The sessions that you have requested have been scheduled. > Below is the scheduled session information followed by=20 > the information of sessions that you have requested. >=20 > CORE Session 1 (2 hours) > Wednesday, Morning Session I 0900-1130 > Room Name: 206 B > ---------------------------------------------- > CORE Session 2 (2 hours) > Wednesday, Afternoon Session I 1300-1500 > Room Name: 204 B > ---------------------------------------------- >=20 From zach@sensinode.com Thu Jul 7 03:42:11 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 62F8E21F87C2 for ; Thu, 7 Jul 2011 03:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.166 X-Spam-Level: X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, 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 x4hEoIduSpR5 for ; Thu, 7 Jul 2011 03:42:10 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 5A82421F8599 for ; Thu, 7 Jul 2011 03:42:08 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p67Ag30B006662 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Jul 2011 13:42:04 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-457-1015644243; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <004701cc3bd8$bdeecba0$39cc62e0$@uni-rostock.de> Date: Thu, 7 Jul 2011 13:42:05 +0300 Message-Id: <609ECA3B-26F5-4D70-B1F5-4C63EE86E775@sensinode.com> References: <057.213b5d9d1d62cee7319a2d6f5e3e5d21@trac.tools.ietf.org> <009701cc3b27$b7555d10$26001730$@uni-rostock.de> <004701cc3bd8$bdeecba0$39cc62e0$@uni-rostock.de> To: Guido Moritz X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] #163: Content-negotiation 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: Thu, 07 Jul 2011 10:42:11 -0000 --Apple-Mail-457-1015644243 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 6, 2011, at 3:32 PM, Guido Moritz wrote: > I would not agree that servers are likely to support several media = types in > parallel. But I totally agree that it is in the responsibility of = further > standardization bodies to define domain specific 'profiles', including = a > limited number of media types. Selected resources on servers will support several media types, we = already have seen that need from two SDOs that are designing for the use = of CoAP. They are defining which formats those resources need to support = in the standard, but require the Accept feature for a client to indicate = which one is preferred. This is by far the most likely use case where = CoAP Accept will really be used.=20 >=20 > But in a M2M scenario, why should a client prefer any media type? = Based our > measurements, even on 8bit platforms, parsing either XML, EXI, JSON = our > whatever has never been the bottleneck by means of timing. It is = always > about the required ROM/RAM usage of the parsers. So if I can = understand more > than one media type, why should I prefer one? The server may offer three representations, say XML, EXI and JSON. You = may only understand XML and JSON. You get the point.=20 > I don't have a use case for > this. Then why do you care? (kidding). The preference approach seems to work = fine for the use cases in mind.=20 > I would say it is more important to indicate that the media types in > the Accept are not preferred, but the only ones the client can parse = at all. In the end, what does that really change? The only difference is that = you will get a useless representation in the "preferred" model, or a = 4.06 (not acceptable) in the "only accept" case. They achieve the same = thing in reality.=20 > To relax this, in coap-misc two Accept options are defined, one = elective and > one critical. Maybe we can have both? I thought about that, but it is getting needlessly complex (and = confusing) to have two different options for Accept. =46rom the viewpoint of efficiency and simplicity, I would definitely = prefer for this to be Elective. Now, there is nothing stopping us from = making this "only accept" and returning a 4.06 error code even if the = option is elective. However, resource on servers that don't support = Accept (and thus only have a single media type) will just ignore it and = return the representation it has, and the client would just have to deal = with it. Does that behavior make sense to people?=20 Zach >=20 > Guido >=20 >> -----Urspr=FCngliche Nachricht----- >> Von: Zach Shelby [mailto:zach@sensinode.com] >> Gesendet: Mittwoch, 6. Juli 2011 13:37 >> An: Guido Moritz >> Cc: core@ietf.org >> Betreff: Re: [core] #163: Content-negotiation >>=20 >> Guido, >>=20 >> On Jul 5, 2011, at 6:25 PM, Guido Moritz wrote: >>=20 >>> Dear all, >>>=20 >>> Indeed, I like the idea of some kind of content negotiation. But I > existing CoAP >> draft is very strict in many points about what is allowed by which > endpoint and >> e.g. how a response must be interpreted. >>>=20 >>> This proposal instead seems not to be straight forward. A client can > include >> the preferred media type, but the server does not have to care about = it?! >>=20 >> I would say the philosophy of CoAP is to specify things so as to keep >> implementations simple, and to allow requests to gracefully succeed = with > non- >> critical mismatches (important in allowing minimal implementations). = Of >> course we need to keep resource interactions correct, to do that the > server and >> protocol behavior is pretty strict. Not sure I would describe the > interpretation of >> responses by a client to be strict at all, it is really up to the = client > what it wants >> to do with a resource representation. >>=20 >>> How many media types will be supported by a typical CoAP = implementation? >> For example if a client does not care about it, it will not include = any > Accept >> option. But if the client is only able to process XML and the client > expresses this >> in the Accept option, a JSON media type in the response makes no = sense. > This >> can be seen as the typical way of negotiating the capabilities = between the >> endpoints. But is the provided media type coupled to this specific > resource, to >> this specific query (e.g. by the query option) or to the complete = server? > Again, >> this is the way how HTTP handles this issue, but CoAP much stricter = in > such >> points is up to now. >>=20 >> The HTTP use case for content-type negotiation is different in my = opinion, >> where both the client and server might support large numbers of media > types, >> and have no (or very little) a-priori knowledge of what the other = might > support. >>=20 >> =46rom my experience so far, the CoAP M2M use cases involve servers = who > offer >> a representation in a few different pre-determined media types. = Clients > know >> these types a priori through standardization (as in the case of ETSI = or > ZigBee) or >> via the Link Format. Thus the main intention is to allow a client to = show >> preference for which of those known media types is preferred. = However > there >> may always be mis-matches, for example servers supporting new = media-types >> out of the standard or not updating link descriptions very often. >>=20 >> Making the Accept option elective seems to fit the CoAP model well in = my >> opinion. It allows requests to still succeed even if some servers do = not > support >> Accept, and allows requests that don't match to still succeed even if = a > match >> isn't found. If the client doesn't find the representation useful, it = can > just ignore >> it. So keep in mind that there are two reasons the client may not = get a > content- >> type it put in Accept options, either Accept is not supported by the > server, or >> the server doesn't have any of those preferred content-types. >>=20 >>> As result, I would suggest to have a specific option whereby a = client > can >> express that the Accept media types are preferred, but the client is > willing to >> process also other media types (e.g. by a dedicated media type 'any' = or by >> including an empty media type option as last Accept option). If this = 'any' > media >> type is not included, the client strictly requires one of the media = types > indicated >> by the Accept options. If no fitting media type is found in the = Accept > option, the >> server just responds with a 4.15. >>=20 >> In practice what you are suggesting is to make the Accept option = Critical >> instead of Elective, and treating an empty Accept option as the = equivalent > of >> HTTP Accept */*. That would of course mean that servers not = supporting >> Accept would fail, requiring a second request without Accept. Is that = any > more >> efficient than possibly receiving a representation the client might = have > to throw >> away on the first shot? >>=20 >> Zach >>=20 >>>=20 >>> My 2cents, >>> Guido >>>=20 >>>> -----Urspr=FCngliche Nachricht----- >>>> Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im = Auftrag > von >>>> core issue tracker >>>> Gesendet: Dienstag, 5. Juli 2011 10:05 >>>> An: zach@sensinode.com >>>> Cc: core@ietf.org >>>> Betreff: [core] #163: Content-negotiation >>>>=20 >>>> #163: Content-negotiation >>>>=20 >>>> I propose a ticket to add content-type preference indication to > coap-07. >>>> In particular, the proposal is to add a new Elective option called >>>> "Accept". Here is text lifted from coap-misc-08: >>>>=20 >>>> "The CoAP Accept option would >>>> when included one or more times in a request, carry one or more = media >>>> types, each of which is an acceptable media type for the client, = in >>>> the order of preference. If no Accept option is given, the client >>>> does not express a preference. The client prefers the = representation >>>> returned by the >>>> server to be in one of the media types, but is willing to = accept >>>> the response also if the server returns a representation in a >>>> different media type." >>>>=20 >>>> One minor side effect of this change, is that the ct=3D attribute = of > core- >>>> link-format would need to be allowed multiple times. This attribute >>>> definition should anyways be moved from core-link-format and placed = in >>>> core-coap as it is CoAP specific. >>>>=20 >>>> -- >>>>=20 > = ----------------------------------+---------------------------------------= -- >>>> Reporter: zach@=85 | Owner: zach@=85 >>>> Type: protocol enhancement | Status: new >>>> Priority: minor | Milestone: >>>> Component: coap | Version: >>>> Severity: - | Keywords: >>>>=20 > = ----------------------------------+---------------------------------------= -- >>>>=20 >>>> Ticket URL: >>>> core >>>>=20 >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>=20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>=20 >> -- >> Zach Shelby, Chief Nerd, Sensinode Ltd. >> http://www.sensinode.com >> http://zachshelby.org - My blog "On the Internet of Things" >> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded = Internet" >> Mobile: +358 40 7796297 >=20 >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com 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-457-1015644243 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDcwNzEwNDIw NlowIwYJKoZIhvcNAQkEMRYEFM6VXV9YuBnOx8elvkKyQSjyFuOPMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAGjd/xgGUDtCCo180HFwHHtp8tt2dSVxOdowjfuIOZ9qSH2Y3qeMpScV QcwKd0yxZpj3u5V4ZXKIG70t11rYtQej7v3z8lzsx0Y1ZicIO6Sbz9Lmo2JLMmROCZhG5FlMCfHt al88dJPyA8u9fhTPyvOBIbW3iZq8McI7OfZsTmJRRPTOSbiBrp1YA7ZsoTW/ASt86HtW1XSLK/NW XIxsuAa+eDm118d/+4+FFejE8ndykkBHtxyuknCZyYmLEyI/gSoNP9Yi0oU/T2/xymhJ2K1yU+Yd nXbUeGxRDFGNidvGHFFFXtF/OdULcgSN5BEOPvobNC/sDBesPOLTrqdHFlsAAAAAAAA= --Apple-Mail-457-1015644243-- From cabo@tzi.org Thu Jul 7 05:04:57 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 8B2EF21F85E4 for ; Thu, 7 Jul 2011 05:04:57 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZVgrWTpz4nj for ; Thu, 7 Jul 2011 05:04:57 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0884921F85D6 for ; Thu, 7 Jul 2011 05:04:55 -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 p67C4oqY004163; Thu, 7 Jul 2011 14:04:50 +0200 (CEST) Received: from [192.168.217.101] (p5B3E6C78.dip.t-dialin.net [91.62.108.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2068E9F9; Thu, 7 Jul 2011 14:04:49 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <609ECA3B-26F5-4D70-B1F5-4C63EE86E775@sensinode.com> Date: Thu, 7 Jul 2011 14:04:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <057.213b5d9d1d62cee7319a2d6f5e3e5d21@trac.tools.ietf.org> <009701cc3b27$b7555d10$26001730$@uni-rostock.de> <004701cc3bd8$bdeecba0$39cc62e0$@uni-rostock.de> <609ECA3B-26F5-4D70-B1F5-4C63EE86E775@sensinode.com> To: Zach Shelby X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] #163: Content-negotiation 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: Thu, 07 Jul 2011 12:04:57 -0000 On Jul 7, 2011, at 12:42, Zach Shelby wrote: > =46rom the viewpoint of efficiency and simplicity, I would definitely = prefer for this to be Elective. Now, there is nothing stopping us from = making this "only accept" and returning a 4.06 error code even if the = option is elective. However, resource on servers that don't support = Accept (and thus only have a single media type) will just ignore it and = return the representation it has, and the client would just have to deal = with it. Does that behavior make sense to people?=20 Well, there are two semantics. -- I need this (one out of a set of) content types, and I'm not = interested in anything else. If the option is Elective, the client still cannot rely on = getting just that. So for this semantics, the option should be = Critical. -- Please give my this (one out of a set of) content type, but I'd be = happy with anything else. If the option is Critical, the request might be needlessly = rejected. So for this semantics, the option should be Elective. Which of the ones do we need? Since I consider the cost of getting an = unwanted answer (as opposed to an error answer) negligible*), there is = little value to the first semantics. There is even less value to an = implementation that would honor a Critical Accept and choose to ignore = an Elective one (why on earth would one do that?). That's why I was = happy with only having the second. Maybe it would help to add some = implementer advice that, to maximize interoperability, the Accept = *should* be honored if the implementation can do that (well, whatever = this advice will be, it will be wishy-washy, so it can't be a SHOULD). Gruesse, Carsten *) Tell me if you have a counter-example that is not hypothetical. From prvs=5169C72A14=guido.moritz@uni-rostock.de Thu Jul 7 05:30:44 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 68B1A21F8728 for ; Thu, 7 Jul 2011 05:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 4vFNVqcBrNf8 for ; Thu, 7 Jul 2011 05:30:43 -0700 (PDT) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id 622C821F86FE for ; Thu, 7 Jul 2011 05:30:43 -0700 (PDT) From: Guido Moritz To: 'Carsten Bormann' , 'Zach Shelby' References: <057.213b5d9d1d62cee7319a2d6f5e3e5d21@trac.tools.ietf.org> <009701cc3b27$b7555d10$26001730$@uni-rostock.de> <004701cc3bd8$bdeecba0$39cc62e0$@uni-rostock.de> <609ECA3B-26F5-4D70-B1F5-4C63EE86E775@sensinode.com> In-Reply-To: Date: Thu, 7 Jul 2011 14:30:31 +0200 Message-ID: <00b701cc3ca1$a9665940$fc330bc0$@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHH7sh8VZtg88aOR42vPk1MTGJ43gKePwIRAVTMJBsCGWewSgFS/0XMAlsTGbCUm45RYA== Content-Language: de X-Originating-IP: [139.30.201.226] Cc: core@ietf.org Subject: Re: [core] #163: Content-negotiation 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: Thu, 07 Jul 2011 12:30:44 -0000 Maybe I am repeating myself, sorry! I don't get the point why on earth an endpoint (in an M2M) would prefer = to use a specific media type. Either it is capable of parsing it or it is = not. Or do we have implementations which are clever enough to use e.g. XML = for payload <100Byte and for payload >100Byte switching to EXI? If it is in the decision of the server to use the preferred media type = or to use anything else, can a client rely on that the next request will = result in the same (not wanted) media type? Or does a server deciding this each = time different? Guido > -----Urspr=FCngliche Nachricht----- > Von: Carsten Bormann [mailto:cabo@tzi.org] > Gesendet: Donnerstag, 7. Juli 2011 14:05 > An: Zach Shelby > Cc: Guido Moritz; core@ietf.org > Betreff: Re: [core] #163: Content-negotiation >=20 > On Jul 7, 2011, at 12:42, Zach Shelby wrote: >=20 > > From the viewpoint of efficiency and simplicity, I would definitely prefer for > this to be Elective. Now, there is nothing stopping us from making = this "only > accept" and returning a 4.06 error code even if the option is = elective. However, > resource on servers that don't support Accept (and thus only have a = single > media type) will just ignore it and return the representation it has, = and the > client would just have to deal with it. Does that behavior make sense = to people? >=20 > Well, there are two semantics. >=20 > -- I need this (one out of a set of) content types, and I'm not = interested in > anything else. > If the option is Elective, the client still cannot rely on getting just that. > So for this semantics, the option should be Critical. >=20 > -- Please give my this (one out of a set of) content type, but I'd be happy with > anything else. > If the option is Critical, the request might be needlessly rejected. So for > this semantics, the option should be Elective. >=20 > Which of the ones do we need? Since I consider the cost of getting an > unwanted answer (as opposed to an error answer) negligible*), there is little > value to the first semantics. There is even less value to an implementation that > would honor a Critical Accept and choose to ignore an Elective one = (why on > earth would one do that?). That's why I was happy with only having = the second. > Maybe it would help to add some implementer advice that, to maximize > interoperability, the Accept *should* be honored if the implementation = can do > that (well, whatever this advice will be, it will be wishy-washy, so = it can't be a > SHOULD). >=20 > Gruesse, Carsten >=20 > *) Tell me if you have a counter-example that is not hypothetical. From zach@sensinode.com Thu Jul 7 05:40:44 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 CEB9A21F876C for ; Thu, 7 Jul 2011 05:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.274 X-Spam-Level: X-Spam-Status: No, score=-3.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, 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 tVYNDB5727+j for ; Thu, 7 Jul 2011 05:40:44 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 9D56F21F8766 for ; Thu, 7 Jul 2011 05:40:43 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p67Ced8U029447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Jul 2011 15:40:39 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-483-1022759693; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: Date: Thu, 7 Jul 2011 15:40:41 +0300 Message-Id: References: <057.213b5d9d1d62cee7319a2d6f5e3e5d21@trac.tools.ietf.org> <009701cc3b27$b7555d10$26001730$@uni-rostock.de> <004701cc3bd8$bdeecba0$39cc62e0$@uni-rostock.de> <609ECA3B-26F5-4D70-B1F5-4C63EE86E775@sensinode.com> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] #163: Content-negotiation 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: Thu, 07 Jul 2011 12:40:44 -0000 --Apple-Mail-483-1022759693 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 7, 2011, at 3:04 PM, Carsten Bormann wrote: > -- I need this (one out of a set of) content types, and I'm not = interested in anything else. > If the option is Elective, the client still cannot rely on = getting just that. So for this semantics, the option should be = Critical. >=20 > -- Please give my this (one out of a set of) content type, but I'd be = happy with anything else. > If the option is Critical, the request might be needlessly = rejected. So for this semantics, the option should be Elective. >=20 > Which of the ones do we need? Since I consider the cost of getting an = unwanted answer (as opposed to an error answer) negligible*), there is = little value to the first semantics. There is even less value to an = implementation that would honor a Critical Accept and choose to ignore = an Elective one (why on earth would one do that?). That's why I was = happy with only having the second. Maybe it would help to add some = implementer advice that, to maximize interoperability, the Accept = *should* be honored if the implementation can do that (well, whatever = this advice will be, it will be wishy-washy, so it can't be a SHOULD). I came to the same conclusion.=20 Now I took a shot to improve the Accept text and made an attempt to = include SHOULD language as you suggest. Here is the current Accept = section text from the SVN version of CoAP. Does this need improvement = anyone? 5.10.5. Accept The CoAP Accept option indicates when included one or more times in a request, carry one or more media types, each of which is an acceptable media type for the client, in the order of preference. The representation format is given as a numeric media type identifier that is defined in the CoAP Media Type registry (Section 11.3). If no Accept options are given, the client does not express a preference (thus no default value is assumed). The client prefers the representation returned by the server to be in one of the media types indicated. The server SHOULD return one of the preferred media types if available. As a server might not support the Accept option (and thus would ignore it as it is elective), or a server might not have a preferred media type available, the client needs to be prepared to receive a representation in a different media type. The client can simply discard a representation it can not make use of. This option is "elective". It MAY occur more than once. --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com 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-483-1022759693 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDcwNzEyNDA0 MVowIwYJKoZIhvcNAQkEMRYEFCL2UeB9iiWaz/yXdXoFBzkGRbJaMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAILJmTrfI5JDxJI3n4MNHGJd3SMGGpeB00DYhtitRoE5/xAeFvw1JwPu NIsQB2YhTz2A8Vou9oo9amuY7A6VnLy9wI1xFNBlCIfnsO7Yld7S4q9KNbCPNTSiAnGexAKKBuEX u9wFd8Y/Q0AaKTnjyiQ/gyax+g6VmaHb5d+xfkqmk/pngRtS3zd3PumHqXLZfRuP8uMT/iprZmfS yJ8n6+KyOfyY27LQxTrODORoeF80G4+pJ4RhOzmO2JNXYBqsjLThHE4AgFwfI85ww6JFybs4mtZW 9LzbtaVaMUyuCBB7zFg4qal/3c/KOlZ7AtigQyEOi92ZYL2glqB5Lc/sJn4AAAAAAAA= --Apple-Mail-483-1022759693-- From prvs=5169C72A14=guido.moritz@uni-rostock.de Thu Jul 7 07:15:37 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 84DDD21F875E for ; Thu, 7 Jul 2011 07:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 uwn+T7zX-Xz3 for ; Thu, 7 Jul 2011 07:15:36 -0700 (PDT) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id 179F821F8763 for ; Thu, 7 Jul 2011 07:15:36 -0700 (PDT) From: Guido Moritz To: 'Zach Shelby' , 'Carsten Bormann' References: <057.213b5d9d1d62cee7319a2d6f5e3e5d21@trac.tools.ietf.org> <009701cc3b27$b7555d10$26001730$@uni-rostock.de> <004701cc3bd8$bdeecba0$39cc62e0$@uni-rostock.de> <609ECA3B-26F5-4D70-B1F5-4C63EE86E775@sensinode.com> In-Reply-To: Date: Thu, 7 Jul 2011 16:15:28 +0200 Message-ID: <00ec01cc3cb0$52ef31e0$f8cd95a0$@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHH7sh8VZtg88aOR42vPk1MTGJ43gKePwIRAVTMJBsCGWewSgFS/0XMAlsTGbABYgkVS5SQm+Og Content-Language: de X-Originating-IP: [139.30.201.226] Cc: core@ietf.org Subject: Re: [core] #163: Content-negotiation 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: Thu, 07 Jul 2011 14:15:37 -0000 I would still love to have more detailed information for the client how = the interpret a not wanted response. Otherwise it would be hard for a client = to determine which the real capabilities of the server are and which just = have occurred, e.g., due to implementation or situation specific side effect (e.g. RAM overload, temporary low throughput...). Something like: "If the server is temporarily not able to provide a = media type requested in the Accept option, the server SHOULD respond with a different media type. If the server is entirely not capable of providing = the requested media type, the server SHOULD respond with a 4.06." This is already possible with the existing text, but I guess it would be helpful to have a more precise definition. I am not sure which side = effects such a behavior might have. And I don't want to overstrain this discussion :) Guido > -----Urspr=FCngliche Nachricht----- > Von: Zach Shelby [mailto:zach@sensinode.com] > Gesendet: Donnerstag, 7. Juli 2011 14:41 > An: Carsten Bormann > Cc: Guido Moritz; core@ietf.org > Betreff: Re: [core] #163: Content-negotiation >=20 > On Jul 7, 2011, at 3:04 PM, Carsten Bormann wrote: >=20 > > -- I need this (one out of a set of) content types, and I'm not interested in > anything else. > > If the option is Elective, the client still cannot rely on getting just that. > So for this semantics, the option should be Critical. > > > > -- Please give my this (one out of a set of) content type, but I'd = be happy with > anything else. > > If the option is Critical, the request might be needlessly = rejected. So for > this semantics, the option should be Elective. > > > > Which of the ones do we need? Since I consider the cost of getting = an > unwanted answer (as opposed to an error answer) negligible*), there is little > value to the first semantics. There is even less value to an implementation that > would honor a Critical Accept and choose to ignore an Elective one = (why on > earth would one do that?). That's why I was happy with only having = the second. > Maybe it would help to add some implementer advice that, to maximize > interoperability, the Accept *should* be honored if the implementation = can do > that (well, whatever this advice will be, it will be wishy-washy, so = it can't be a > SHOULD). >=20 >=20 > I came to the same conclusion. >=20 > Now I took a shot to improve the Accept text and made an attempt to include > SHOULD language as you suggest. Here is the current Accept section = text from > the SVN version of CoAP. Does this need improvement anyone? >=20 > 5.10.5. Accept >=20 > The CoAP Accept option indicates when included one or more times in = a > request, carry one or more media types, each of which is an > acceptable media type for the client, in the order of preference. > The representation format is given as a numeric media type = identifier > that is defined in the CoAP Media Type registry (Section 11.3). If > no Accept options are given, the client does not express a = preference > (thus no default value is assumed). The client prefers the > representation returned by the server to be in one of the media = types > indicated. The server SHOULD return one of the preferred media = types > if available. As a server might not support the Accept option (and > thus would ignore it as it is elective), or a server might not have = a > preferred media type available, the client needs to be prepared to > receive a representation in a different media type. The client can > simply discard a representation it can not make use of. >=20 > This option is "elective". It MAY occur more than once. >=20 > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 From trac+core@trac.tools.ietf.org Fri Jul 8 04:17:22 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 56AD921F88C3 for ; Fri, 8 Jul 2011 04:17:22 -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 ctr52xd41KQj for ; Fri, 8 Jul 2011 04:17: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 5897021F869B for ; Fri, 8 Jul 2011 04:17:14 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1Qf93Z-0005sV-1u; Fri, 08 Jul 2011 04:17:13 -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, 08 Jul 2011 11:17:13 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/163#comment:1 Message-ID: <066.64486e4c8f7c95cdb73b5c0d497f5dec@trac.tools.ietf.org> References: <057.213b5d9d1d62cee7319a2d6f5e3e5d21@trac.tools.ietf.org> X-Trac-Ticket-ID: 163 In-Reply-To: <057.213b5d9d1d62cee7319a2d6f5e3e5d21@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] #163: Content-negotiation 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, 08 Jul 2011 11:17:22 -0000 #163: Content-negotiation Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Closing this ticket for the -07 release, acknowledging that the text will still need some tweaking. -- ----------------------------------+----------------------------------------- Reporter: zach@… | Owner: zach@… Type: protocol enhancement | Status: closed Priority: minor | Milestone: Component: coap | Version: Severity: - | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Ticket URL: core From internet-drafts@ietf.org Fri Jul 8 04:18:41 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 2DEDB21F891C; Fri, 8 Jul 2011 04:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, 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 UXvl2aqZBCT7; Fri, 8 Jul 2011 04:18:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23F121F8683; Fri, 8 Jul 2011 04:18:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110708111840.10832.24415.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2011 04:18:40 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-coap-07.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: Fri, 08 Jul 2011 11:18:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Work= ing Group of the IETF. Title : Constrained Application Protocol (CoAP) Author(s) : Zach Shelby Klaus Hartke Carsten Bormann Brian Frank Filename : draft-ietf-core-coap-07.txt Pages : 86 Date : 2011-07-08 This document specifies the Constrained Application Protocol (CoAP), a specialized web transfer protocol for use with constrained networks and nodes for machine-to-machine applications such as smart energy and building automation. These constrained nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while networks such as 6LoWPAN often have high packet error rates and a typical throughput of 10s of kbit/s. CoAP provides a method/response interaction model between application end-points, supports built-in resource discovery, and includes key web concepts such as URIs and content-types. CoAP easily translates to HTTP for integration with the web while meeting specialized requirements such as multicast support, very low overhead and simplicity for constrained environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-core-coap-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-core-coap-07.txt From zach@sensinode.com Fri Jul 8 04:26:05 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 C167821F89B6 for ; Fri, 8 Jul 2011 04:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.339 X-Spam-Level: X-Spam-Status: No, score=-3.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, 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 GPhOEziyEvAP for ; Fri, 8 Jul 2011 04:26:04 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 5714B21F8990 for ; Fri, 8 Jul 2011 04:26:03 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p68BPK81022632 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 8 Jul 2011 14:25:20 +0300 From: Zach Shelby Content-Type: multipart/signed; boundary=Apple-Mail-547--1042842980; protocol="application/pkcs7-signature"; micalg=sha1 Date: Fri, 8 Jul 2011 14:25:22 +0300 References: <20110708111840.10832.85329.idtracker@ietfa.amsl.com> To: core WG Message-Id: <162932A6-393D-4BD5-B5E8-A28F42AFA772@sensinode.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] Fwd: New Version Notification - draft-ietf-core-coap-07.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: Fri, 08 Jul 2011 11:26:05 -0000 --Apple-Mail-547--1042842980 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii An updated version of CoAP is now available. This now closes the known = issues and agreed upon feature additions since the -06 release. I do = recommend that implementers check through the diff, although most = changes are feature additions and won't break existing -06 = implementations.=20 Changed from ietf-06 to ietf-07: o application/link-format added to Media types registration (#160) o Moved content-type attribute to the document from link-format. o Added coaps scheme and DTLS-secured CoAP default port (#154) o Allowed 0-length Content-type options (#150) o Added congestion control recommendations (#153) o Improved text on PUT/POST response payloads (#149) o Added an Accept option for content-negotiation (#163) o Added If-Match and If-None-Match options (#155) o Improved Token Option explanation (#147) o Clarified mandatory to implement security (#156) o Added first come first server policy for 2-byte Media type codes (#161) o Clarify matching rules for messages and tokens (#151) o Changed OPTIONS and TRACE to always return 501 in HTTP-CoAP mapping (#164) Zach Begin forwarded message: > From: internet-drafts@ietf.org > Date: July 8, 2011 2:18:40 PM GMT+03:00 > To: core-chairs@tools.ietf.org, draft-ietf-core-coap@tools.ietf.org, = stpeter@stpeter.im > Subject: New Version Notification - draft-ietf-core-coap-07.txt >=20 > New version (-07) has been submitted for draft-ietf-core-coap-07.txt. > http://www.ietf.org/internet-drafts/draft-ietf-core-coap-07.txt >=20 >=20 > Diff from previous version: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-coap-07 >=20 > IETF Secretariat. --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com 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-547--1042842980 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 ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDcwODExMjUy MlowIwYJKoZIhvcNAQkEMRYEFJjFg6Dka11x11uRALN49cYzA3djMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAGh5vfO0JvbIrHG4UDQycLO0uVC1snk8SxQcORsjTO5z2ApPFdkoY8dd Kv7zYKWEWcl4jll7PvWd2vKjQV9ypssqhX3clS+T142Qw8nQoPXZx3xlXvS8A7oG8To4lvCGqsv8 TK0dGYXgwHBhlsEJwJ+dsY29mTMPEVjoX8h1BOOKIEQk/ZADFTndyOco7c3gPfeBdxBImWt0QIn7 ZOEZL77k/uE8GGV/rU4j6JGWw3Ki4yTOM9N5MDQp6c4IytOgu0EhkjNoznT/QIvS4XjyfgLVFv2h SPNnhlaKR1AZpEfvEhQZzjMC50JXczNmdofs++S6/zQmpPETa7GmAGslEBwAAAAAAAA= --Apple-Mail-547--1042842980-- From esko.dijk@philips.com Sun Jul 10 05:54: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 E67FD21F86C6 for ; Sun, 10 Jul 2011 05:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ck0wsHBEAf0B for ; Sun, 10 Jul 2011 05:54:23 -0700 (PDT) Received: from TX2EHSOBE005.bigfish.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id BCF2E21F86C4 for ; Sun, 10 Jul 2011 05:54:22 -0700 (PDT) Received: from mail129-tx2-R.bigfish.com (10.9.14.253) by TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id 14.1.225.22; Sun, 10 Jul 2011 12:54:22 +0000 Received: from mail129-tx2 (localhost.localdomain [127.0.0.1]) by mail129-tx2-R.bigfish.com (Postfix) with ESMTP id BE5765205EB; Sun, 10 Jul 2011 12:54:21 +0000 (UTC) X-SpamScore: -59 X-BigFish: VPS-59(zz217bL15d6O9251J9371M168aJ542M1418M1432N98dKzz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:168.87.56.20; KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI Received: from mail129-tx2 (localhost.localdomain [127.0.0.1]) by mail129-tx2 (MessageSwitch) id 1310302461394672_20615; Sun, 10 Jul 2011 12:54:21 +0000 (UTC) Received: from TX2EHSMHS032.bigfish.com (unknown [10.9.14.247]) by mail129-tx2.bigfish.com (Postfix) with ESMTP id 51A2E187804C; Sun, 10 Jul 2011 12:54:21 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by TX2EHSMHS032.bigfish.com (10.9.99.132) with Microsoft SMTP Server (TLS) id 14.1.225.22; Sun, 10 Jul 2011 12:54:21 +0000 Received: from NLHILEXH05.connect1.local (172.16.153.71) by connect1.philips.com (172.16.156.43) with Microsoft SMTP Server (TLS) id 8.3.106.1; Sun, 10 Jul 2011 14:54:22 +0200 Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by NLHILEXH05.connect1.local ([172.16.153.71]) with mapi; Sun, 10 Jul 2011 14:52:40 +0200 From: "Dijk, Esko" To: Guido Moritz , 'Zach Shelby' , 'Carsten Bormann' Date: Sun, 10 Jul 2011 14:54:19 +0200 Thread-Topic: [core] #163: Content-negotiation Thread-Index: AQHH7sh8VZtg88aOR42vPk1MTGJ43gKePwIRAVTMJBsCGWewSgFS/0XMAlsTGbABYgkVS5SQm+OggASYJOA= Message-ID: References: <057.213b5d9d1d62cee7319a2d6f5e3e5d21@trac.tools.ietf.org> <009701cc3b27$b7555d10$26001730$@uni-rostock.de> <004701cc3bd8$bdeecba0$39cc62e0$@uni-rostock.de> <609ECA3B-26F5-4D70-B1F5-4C63EE86E775@sensinode.com> <00ec01cc3cb0$52ef31e0$f8cd95a0$@uni-rostock.de> In-Reply-To: <00ec01cc3cb0$52ef31e0$f8cd95a0$@uni-rostock.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org" Subject: Re: [core] #163: Content-negotiation 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: Sun, 10 Jul 2011 12:54:24 -0000 I would agree with Zach that having one Elective Accept-option seems right = for the described use case (i.e. SDO/ZigBee/ETSI multiple content formats). [I'm probably repeating Zach's points here:] 1- Elective enables minimal implementations to be simpler (ignore "Accept" = entirely; return fixed content type) 2- a CoAP client according to the use case knows what a server offers, and = whether it supports Accept, since it's specified in a standard and/or disco= vered via Link Format. So the client would request from these formats and a= lmost always the server is able to serve one of these. Suppose the server in case 2 still returns something the client doesn't und= erstand, the client may interpret this as a form of "server error 4.15". No= te, I think that even with an Elective Accept option a server can still leg= ally return a 4.15 - this may even be agreed so by the people of the relate= d standard. Finally if RAM or resources are the problem the server should respond 5.00 = or 5.03, isn't it? Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Gui= do Moritz Sent: Thursday 7 July 2011 16:15 To: 'Zach Shelby'; 'Carsten Bormann' Cc: core@ietf.org Subject: Re: [core] #163: Content-negotiation I would still love to have more detailed information for the client how the interpret a not wanted response. Otherwise it would be hard for a client to determine which the real capabilities of the server are and which just have occurred, e.g., due to implementation or situation specific side effect (e.g. RAM overload, temporary low throughput...). Something like: "If the server is temporarily not able to provide a media type requested in the Accept option, the server SHOULD respond with a different media type. If the server is entirely not capable of providing th= e requested media type, the server SHOULD respond with a 4.06." This is already possible with the existing text, but I guess it would be helpful to have a more precise definition. I am not sure which side effects such a behavior might have. And I don't want to overstrain this discussion :) Guido > -----Urspr=FCngliche Nachricht----- > Von: Zach Shelby [mailto:zach@sensinode.com] > Gesendet: Donnerstag, 7. Juli 2011 14:41 > An: Carsten Bormann > Cc: Guido Moritz; core@ietf.org > Betreff: Re: [core] #163: Content-negotiation > > On Jul 7, 2011, at 3:04 PM, Carsten Bormann wrote: > > > -- I need this (one out of a set of) content types, and I'm not interested in > anything else. > > If the option is Elective, the client still cannot rely on getting just that. > So for this semantics, the option should be Critical. > > > > -- Please give my this (one out of a set of) content type, but I'd be happy with > anything else. > > If the option is Critical, the request might be needlessly rejected= . So for > this semantics, the option should be Elective. > > > > Which of the ones do we need? Since I consider the cost of getting an > unwanted answer (as opposed to an error answer) negligible*), there is little > value to the first semantics. There is even less value to an implementation that > would honor a Critical Accept and choose to ignore an Elective one (why o= n > earth would one do that?). That's why I was happy with only having the second. > Maybe it would help to add some implementer advice that, to maximize > interoperability, the Accept *should* be honored if the implementation ca= n do > that (well, whatever this advice will be, it will be wishy-washy, so it can't be a > SHOULD). > > > I came to the same conclusion. > > Now I took a shot to improve the Accept text and made an attempt to include > SHOULD language as you suggest. Here is the current Accept section text from > the SVN version of CoAP. Does this need improvement anyone? > > 5.10.5. Accept > > The CoAP Accept option indicates when included one or more times in a > request, carry one or more media types, each of which is an > acceptable media type for the client, in the order of preference. > The representation format is given as a numeric media type identifier > that is defined in the CoAP Media Type registry (Section 11.3). If > no Accept options are given, the client does not express a preference > (thus no default value is assumed). The client prefers the > representation returned by the server to be in one of the media types > indicated. The server SHOULD return one of the preferred media types > if available. As a server might not support the Accept option (and > thus would ignore it as it is elective), or a server might not have a > preferred media type available, the client needs to be prepared to > receive a representation in a different media type. The client can > simply discard a representation it can not make use of. > > This option is "elective". It MAY occur more than once. > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 _______________________________________________ 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 peter.van.der.stok@philips.com Mon Jul 11 07:38:27 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 B3F3321F8C76 for ; Mon, 11 Jul 2011 07:38:27 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swUwsIQI5rRf for ; Mon, 11 Jul 2011 07:38:26 -0700 (PDT) Received: from DB3EHSOBE003.bigfish.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3F88721F8B2E for ; Mon, 11 Jul 2011 07:38:26 -0700 (PDT) Received: from mail36-db3-R.bigfish.com (10.3.81.250) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.22; Mon, 11 Jul 2011 14:38:25 +0000 Received: from mail36-db3 (localhost.localdomain [127.0.0.1]) by mail36-db3-R.bigfish.com (Postfix) with ESMTP id 0BC311730441 for ; Mon, 11 Jul 2011 14:38:25 +0000 (UTC) X-SpamScore: -36 X-BigFish: VPS-36(zz217bL15d6O9251J936eKzz1202hzz1033IL8275dhz2dh2a8h668h839h93fh) X-Forefront-Antispam-Report: CIP:168.87.56.20; KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI Received: from mail36-db3 (localhost.localdomain [127.0.0.1]) by mail36-db3 (MessageSwitch) id 1310395099292985_8022; Mon, 11 Jul 2011 14:38:19 +0000 (UTC) Received: from DB3EHSMHS007.bigfish.com (unknown [10.3.81.254]) by mail36-db3.bigfish.com (Postfix) with ESMTP id 3E267143804B for ; Mon, 11 Jul 2011 14:38:19 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by DB3EHSMHS007.bigfish.com (10.3.87.107) with Microsoft SMTP Server (TLS) id 14.1.225.22; Mon, 11 Jul 2011 14:38:12 +0000 Received: from NLHILEXH02.connect1.local (172.16.153.92) by connect1.philips.com (172.16.156.40) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 11 Jul 2011 16:38:12 +0200 Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by NLHILEXH02.connect1.local ([172.16.153.92]) with mapi; Mon, 11 Jul 2011 16:36:31 +0200 From: "Stok, Peter van der" To: "core@ietf.org" Date: Mon, 11 Jul 2011 16:38:10 +0200 Thread-Topic: New Version Notification for draft-vanderstok-core-bc-04.txt Thread-Index: Acw/1qc0XJFrKPEuR/mzXdVOtRLNYQAAKu0w Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: [core] FW: New Version Notification for draft-vanderstok-core-bc-04.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: Mon, 11 Jul 2011 14:38:27 -0000 RGVhciBhbGwsDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC12YW5kZXJzdG9rLWNvcmUt YmMtMDQudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUGV0ZXIgdmFuIGRl ciBTdG9rIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6ICAg ICAgICBkcmFmdC12YW5kZXJzdG9rLWNvcmUtYmMNClJldmlzaW9uOiAgICAgICAgMDQNClRpdGxl OiAgICAgICAgICAgQ29BUCBVdGlsaXphdGlvbiBmb3IgQnVpbGRpbmcgQ29udHJvbA0KQ3JlYXRp b24gZGF0ZTogICAyMDExLTA3LTExDQpXRyBJRDogICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlz c2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAzNA0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC12YW5kZXJzdG9rLWNvcmUtYmMNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRyYWZ0 IGRlc2NyaWJlcyBhbiBleGFtcGxlIHVzZSBvZiB0aGUgUkVTVGZ1bCBDb0FQIHByb3RvY29sIGZv cg0KICAgYnVpbGRpbmcgYXV0b21hdGlvbiBhbmQgY29udHJvbCAoQkFDKSBhcHBsaWNhdGlvbnMg c3VjaCBhcyBIVkFDIGFuZA0KICAgbGlnaHRpbmcuICBBIGZldyBiYXNpYyBkZXNpZ24gYXNzdW1w dGlvbnMgYXJlIHN0YXRlZCBmaXJzdCwgdGhlbiBVUkkNCiAgIHN0cnVjdHVyZSBpcyB1dGlsaXpl ZCB0byBkZWZpbmUgZ3JvdXAgYXMgd2VsbCBhcyB1bmljYXN0IHNjb3BlIGZvcg0KICAgUkVTVGZ1 bCBvcGVyYXRpb25zLg0KDQogICBUaGUgYXV0aG9yaXR5IHBvcnRpb24gb2YgdGhlIFVSSSBpcyB1 c2VkIHRvIGlkZW50aWZ5IGEgZGV2aWNlIChncm91cCkNCiAgIGFuZCB0aGUgcmVzdWx0aW5nIERO UyBuYW1lIGlzIGJvdW5kIHRvIGEgdW5pY2FzdCAobXVsdGljYXN0KSBhZGRyZXNzLg0KICAgTmFt aW5nIGlzIGJ1aWxkaW5nIG9yIG9yZ2FuaXphdGlvbiBkZXBlbmRlbnQsIG11c3QgYmUgZmxleGli bGUsIGFuZA0KICAgZG9lcyBub3QgcmVxdWlyZSBzdGFuZGFyZGl6YXRpb24gZWZmb3J0cyBidXQg U0hPVUxEIGNvbmZvcm0gdG8gc29tZQ0KICAgdW5pZm9ybSBjb252ZW50aW9uLg0KDQogICBJdCBp cyBzaG93biB0aGF0IEROUy1iYXNlZCBzZXJ2aWNlIGRpc2NvdmVyeSBjYW4gYmUgdXNlZCB0byBs b2NhdGUNCiAgIFVSSXMgb24gdGhlIHNjYWxlIG5lY2Vzc2FyeSBpbiBsYXJnZSBjb21tZXJjaWFs IEJBQyBkZXBsb3ltZW50cy4NCiAgIEZpbmFsbHksIGEgbWV0aG9kIGlzIHByb3Bvc2VkIGZvciBt YXBwaW5nIFVSSXMgb250byBsZWdhY3kgQkFDDQogICByZXNvdXJjZXMsIGUuZy4sIHRvIGZhY2ls aXRhdGUgYXBwbGljYXRpb24tbGF5ZXIgZ2F0ZXdheXMuDQoNCiAgIFRoaXMgcHJvcG9zYWwgc3Vw cG9ydHMgdGhlIHZpZXcgdGhhdCAxKSBzZXJ2aWNlIGRpc2NvdmVyeSBpcw0KICAgY29tcGxlbWVu dGFyeSB0byByZXNvdXJjZSBkaXNjb3ZlcnkgYW5kIGZhY2lsaXRhdGVzIGNvbnRyb2wgbmV0d29y aw0KICAgc2NhbGluZywgYW5kIDIpIGJ1aWxkaW5nIGNvbnRyb2wgaXMgbGlrZWx5IHRvIG1vdmUg aW4gc3RlcHMgdG93YXJkDQogICBhbGwtSVAgY29udHJvbCBuZXR3b3JrcyBiYXNlZCBvbiB0aGUg bGVnYWN5IGVmZm9ydHMgcHJvdmlkZWQgYnkgREFMSSwNCiAgIExPTiwgQkFDbmV0LCBaaWdCZWUs IGFuZCBvdGhlciBzdGFuZGFyZHMsDQoNCkFkZGl0aW9ucyBGcm9tIGJjLTAzIHRvIGJjLTA0DQoN CiAgIC0gbW92ZWQgY29yZSBsaW5rIGV4dGVuc2lvbiBzdWItc2VjdGlvbiB0byByZXNvdXJjZSBk aXJlY3RvcnkgZHJhZnQNCg0KICAgLSBleHRlbmRlZCB1c2Ugb2Ygc2VydmljZSB0eXBlDQoNCiAg IC0gZ2F2ZSBETlMgcmVjb3JkIGV4YW1wbGVzIGFuZCB3b3JrZWQgb3V0IG11bHRpZnVuY3Rpb24g ZGV2aWNlDQoNCiAgIC0gYWRkZWQgcHJveHkgZGlzY292ZXJ5IGFuZCBsZWdhY3kgZ2F0ZXdheSBk aXNjb3ZlcnkNCg0KICAgLSBkZWZpbmVkIHBhdGggdHJlZSBhbmQgY29ycmVzcG9uZGluZyBzY2hl bWENCg0KICAgLSByZXZpZXdlZCBkZWZpbml0aW9uIG9mIHNlcnZlciwgc2VydmljZSwgZGV2aWNl LCBzZXJ2aWNlIGF0dHJpYnV0ZSwNCiAgIGFuZCByZXNvdXJjZQ0KDQoNCg0KDQoNCg0KVGhlIElF VEYgU2VjcmV0YXJpYXQNCg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3Nh Z2UgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVnYWxseSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGlj YWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3Nl ZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJl Ynkgbm90aWZpZWQgdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9uLCBvciBy ZXByb2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1h eSBiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxl YXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBj b3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQo= From kerlyn2001@gmail.com Mon Jul 11 07:48:07 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 0128121F8C73 for ; Mon, 11 Jul 2011 07:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.304 X-Spam-Level: X-Spam-Status: No, score=-0.304 tagged_above=-999 required=5 tests=[AWL=3.294, 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 bN+OyIlHqnzZ for ; Mon, 11 Jul 2011 07:48:06 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB58D21F8C68 for ; Mon, 11 Jul 2011 07:48:05 -0700 (PDT) Received: by iwn39 with SMTP id 39so4558062iwn.31 for ; Mon, 11 Jul 2011 07:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WwehrOJccdFaenPeBzFwD56OzX19c3waILMZBTHepqk=; b=RYTlKeQhcbX4o4CSeiNBKXtuzy0JVyyr1OJXGB5dZOSFj/feU3oLvD1YeS8Q3f8NWe N0yiB513vti30tBN4g82xxmqhxcG3Z0+Im0jftQHx+Uv2YXPmHgfdvBDGvXS5i7bJrdZ Mz4TFJtN+N0u5SEmGtdb13jKdo78PUIKHJDuk= MIME-Version: 1.0 Received: by 10.43.134.134 with SMTP id ic6mr5410567icc.108.1310395685411; Mon, 11 Jul 2011 07:48:05 -0700 (PDT) Received: by 10.42.224.66 with HTTP; Mon, 11 Jul 2011 07:48:05 -0700 (PDT) In-Reply-To: References: Date: Mon, 11 Jul 2011 10:48:05 -0400 Message-ID: From: Kerry Lynn To: "Stok, Peter van der" Content-Type: multipart/alternative; boundary=20cf307f38c4581be104a7cc4540 Cc: "core@ietf.org" Subject: Re: [core] FW: New Version Notification for draft-vanderstok-core-bc-04.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: Mon, 11 Jul 2011 14:48:07 -0000 --20cf307f38c4581be104a7cc4540 Content-Type: text/plain; charset=ISO-8859-1 Very small comments (can fix them next time, or not): Additions From bc-03 to bc-04 - moved core link extension sub-section to resource directory draft >>Should be discovery mapping draft - extended use of service type - gave DNS record examples and worked out multifunction device - added proxy discovery and legacy gateway discovery - defined path tree and corresponding schema - reviewed definition of server, service, device, service attribute, and resource >>Taking the container view of the world, the progression is: site, zone, group, device, server, service (interface), resource, attribute Regards, -K- On Mon, Jul 11, 2011 at 10:38 AM, Stok, Peter van der < peter.van.der.stok@philips.com> wrote: > Dear all, > > A new version of I-D, draft-vanderstok-core-bc-04.txt has been successfully > submitted by Peter van der Stok and posted to the IETF repository. > > Filename: draft-vanderstok-core-bc > Revision: 04 > Title: CoAP Utilization for Building Control > Creation date: 2011-07-11 > WG ID: Individual Submission > Number of pages: 34 > > https://datatracker.ietf.org/doc/draft-vanderstok-core-bc > > Abstract: > This draft describes an example use of the RESTful CoAP protocol for > building automation and control (BAC) applications such as HVAC and > lighting. A few basic design assumptions are stated first, then URI > structure is utilized to define group as well as unicast scope for > RESTful operations. > > The authority portion of the URI is used to identify a device (group) > and the resulting DNS name is bound to a unicast (multicast) address. > Naming is building or organization dependent, must be flexible, and > does not require standardization efforts but SHOULD conform to some > uniform convention. > > It is shown that DNS-based service discovery can be used to locate > URIs on the scale necessary in large commercial BAC deployments. > Finally, a method is proposed for mapping URIs onto legacy BAC > resources, e.g., to facilitate application-layer gateways. > > This proposal supports the view that 1) service discovery is > complementary to resource discovery and facilitates control network > scaling, and 2) building control is likely to move in steps toward > all-IP control networks based on the legacy efforts provided by DALI, > LON, BACnet, ZigBee, and other standards, > > Additions From bc-03 to bc-04 > > - moved core link extension sub-section to resource directory draft > > - extended use of service type > > - gave DNS record examples and worked out multifunction device > > - added proxy discovery and legacy gateway discovery > > - defined path tree and corresponding schema > > - reviewed definition of server, service, device, service attribute, > and resource > > > > > > > The IETF Secretariat > > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby notified > that any use, forwarding, dissemination, or reproduction of this message is > strictly prohibited and may be unlawful. If you are not the intended > recipient, please contact the sender by return e-mail and destroy all copies > of the original message. > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --20cf307f38c4581be104a7cc4540 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Very small comments (can fix them next time, or not):

Additions From bc-03 to bc-04

=A0 - moved core link extension sub-section to resource directory draft=
>>Shou= ld be discovery mapping draft

=A0 - extended use of service type

=A0 - gave DNS record example= s and worked out multifunction device

=A0 - added proxy discovery an= d legacy gateway discovery

=A0 - defined path tree and corresponding= schema

=A0 - reviewed definition of server, service, device, service attribute= ,
=A0 and resource
>>Taking the container view of the world, the progression is= :
site, zone, group, device, server, service (interface), res= ource, attribute

Regards, -K-


On Mon, Jul 11, 2011 at 10:38 AM, Sto= k, Peter van der <peter.van.der.stok@philips.com> wrote:
Dear all,

A new version of I-D, draft-vanderstok-core-bc-04.txt has been successfully= submitted by Peter van der Stok and posted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-vanderstok-core-bc
Revision: =A0 =A0 =A0 =A004
Title: =A0 =A0 =A0 =A0 =A0 CoAP Utilization for Building Control
Creation date: =A0 2011-07-11
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 34

https://datatracker.ietf.org/doc/draft-vanderstok-core-b= c

Abstract:
=A0 This draft describes an example use of the RESTful CoAP protocol for =A0 building automation and control (BAC) applications such as HVAC and =A0 lighting. =A0A few basic design assumptions are stated first, then URI=
=A0 structure is utilized to define group as well as unicast scope for
=A0 RESTful operations.

=A0 The authority portion of the URI is used to identify a device (group)<= br> =A0 and the resulting DNS name is bound to a unicast (multicast) address.<= br> =A0 Naming is building or organization dependent, must be flexible, and =A0 does not require standardization efforts but SHOULD conform to some =A0 uniform convention.

=A0 It is shown that DNS-based service discovery can be used to locate
=A0 URIs on the scale necessary in large commercial BAC deployments.
=A0 Finally, a method is proposed for mapping URIs onto legacy BAC
=A0 resources, e.g., to facilitate application-layer gateways.

=A0 This proposal supports the view that 1) service discovery is
=A0 complementary to resource discovery and facilitates control network =A0 scaling, and 2) building control is likely to move in steps toward
=A0 all-IP control networks based on the legacy efforts provided by DALI,<= br> =A0 LON, BACnet, ZigBee, and other standards,

Additions From bc-03 to bc-04

=A0 - moved core link extension sub-section to resource directory draft
=A0 - extended use of service type

=A0 - gave DNS record examples and worked out multifunction device

=A0 - added proxy discovery and legacy gateway discovery

=A0 - defined path tree and corresponding schema

=A0 - reviewed definition of server, service, device, service attribute, =A0 and resource






The IETF Secretariat

The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message.
_______________________________________________
core mailing list
core@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/core

--20cf307f38c4581be104a7cc4540-- From oscar.garcia@philips.com Mon Jul 11 12:09:54 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 F261E21F8C76 for ; Mon, 11 Jul 2011 12:09:53 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NOB7ObSgKC2 for ; Mon, 11 Jul 2011 12:09:50 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 417EF21F8E2D for ; Mon, 11 Jul 2011 12:09:45 -0700 (PDT) Received: from mail93-ch1-R.bigfish.com (216.32.181.170) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.22; Mon, 11 Jul 2011 19:09:44 +0000 Received: from mail93-ch1 (localhost.localdomain [127.0.0.1]) by mail93-ch1-R.bigfish.com (Postfix) with ESMTP id 5B6FE9B82FD for ; Mon, 11 Jul 2011 19:09:44 +0000 (UTC) X-SpamScore: -41 X-BigFish: VPS-41(zz217bL15d6O9251J936eK542Mzz1202hzz1033IL8275dhz2dh2a8h668h839h93fh61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:168.87.56.20; KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI Received: from mail93-ch1 (localhost.localdomain [127.0.0.1]) by mail93-ch1 (MessageSwitch) id 1310411384190130_26086; Mon, 11 Jul 2011 19:09:44 +0000 (UTC) Received: from CH1EHSMHS006.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.253]) by mail93-ch1.bigfish.com (Postfix) with ESMTP id 21F86C1004F for ; Mon, 11 Jul 2011 19:09:44 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by CH1EHSMHS006.bigfish.com (10.43.70.6) with Microsoft SMTP Server (TLS) id 14.1.225.22; Mon, 11 Jul 2011 19:09:39 +0000 Received: from nlamsexh01.connect1.local (172.16.153.11) by connect1.philips.com (172.16.156.43) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 11 Jul 2011 21:09:40 +0200 Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by nlamsexh01.connect1.local ([172.16.153.11]) with mapi; Mon, 11 Jul 2011 21:07:56 +0200 From: "Garcia Morchon, Oscar" To: core WG Date: Mon, 11 Jul 2011 21:09:35 +0200 Thread-Topic: New Version Notification for draft-garcia-core-security-02.txt Thread-Index: Acw//XFj/hfRsTMrSc+lt9IJncyYmwAAEgig Message-ID: <5F6BB0D9318FCA4083FC774C9A9ECEF68BF5D94C57@NLCLUEXM03.connect1.local> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, nl-NL Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: [core] FW: New Version Notification for draft-garcia-core-security-02.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: Mon, 11 Jul 2011 19:09:54 -0000 RGVhciBhbGwsDQoNCldlIGhhdmUgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gb2Ygb3VyIEludGVy bmV0IERyYWZ0LA0KDQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWdhcmNp YS1jb3JlLXNlY3VyaXR5Lw0KDQpyZWdhcmRzLA0KDQogICAgICAgIE9zY2FyLg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWls dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KU2VudDogTW9uZGF5IDExIEp1bHkgMjAxMSAy MTowNw0KVG86IEdhcmNpYSBNb3JjaG9uLCBPc2Nhcg0KQ2M6IEtlb2gsIFN5ZSBMb29uZzsgcnN0 cnVpay5leHRAZ21haWwuY29tOyBLdW1hciwgU2FuZGVlcDsgcmVuZS5odW1tZW5AY3Mucnd0aC1h YWNoZW4uZGU7IEdhcmNpYSBNb3JjaG9uLCBPc2Nhcg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1nYXJjaWEtY29yZS1zZWN1cml0eS0wMi50eHQNCg0KQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWdhcmNpYS1jb3JlLXNlY3VyaXR5LTAyLnR4dCBoYXMgYmVl biBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE9zY2FyIEdhcmNpYS1Nb3JjaG9uIGFuZCBwb3N0 ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6ICAgICAgICBkcmFmdC1nYXJj aWEtY29yZS1zZWN1cml0eQ0KUmV2aXNpb246ICAgICAgICAwMg0KVGl0bGU6ICAgICAgICAgICBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucyBpbiB0aGUgSVAtYmFzZWQgSW50ZXJuZXQgb2YgVGhpbmdz DQpDcmVhdGlvbiBkYXRlOiAgIDIwMTEtMDctMTENCldHIElEOiAgICAgICAgICAgSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDM5DQoNCkFic3RyYWN0Og0KICAgQSBkaXJl Y3QgaW50ZXJwcmV0YXRpb24gb2YgdGhlIEludGVybmV0IG9mIFRoaW5ncyBjb25jZXB0IHJlZmVy cyB0bw0KICAgdGhlIHVzYWdlIG9mIHN0YW5kYXJkIEludGVybmV0IHByb3RvY29scyB0byBhbGxv dyBmb3IgaHVtYW4tdG8tdGhpbmcNCiAgIG9yIHRoaW5nLXRvLXRoaW5nIGNvbW11bmljYXRpb24u ICBBbHRob3VnaCB0aGUgc2VjdXJpdHkgbmVlZHMgYXJlDQogICB3ZWxsLXJlY29nbml6ZWQsIGl0 IGlzIHN0aWxsIG5vdCBmdWxseSBjbGVhciBob3cgZXhpc3RpbmcgSVAtYmFzZWQNCiAgIHNlY3Vy aXR5IHByb3RvY29scyBjYW4gYmUgYXBwbGllZCB0byB0aGlzIG5ldyBzZXR0aW5nLiAgVGhpcw0K ICAgSW50ZXJuZXQtRHJhZnQgZmlyc3QgcHJvdmlkZXMgYW4gb3ZlcnZpZXcgb2Ygc2VjdXJpdHkg YXJjaGl0ZWN0dXJlLA0KICAgaXRzIGRlcGxveW1lbnQgbW9kZWwgYW5kIGdlbmVyYWwgc2VjdXJp dHkgbmVlZHMgaW4gdGhlIGNvbnRleHQgb2YgdGhlDQogICBsaWZlY3ljbGUgb2YgYSB0aGluZy4g IFRoZW4sIGl0IHByZXNlbnRzIGNoYWxsZW5nZXMgYW5kIHJlcXVpcmVtZW50cw0KICAgZm9yIHRo ZSBzdWNjZXNzZnVsIHJvbGwtb3V0IG9mIG5ldyBhcHBsaWNhdGlvbnMgYW5kIHVzYWdlIG9mIHN0 YW5kYXJkDQogICBJUC1iYXNlZCBzZWN1cml0eSBwcm90b2NvbHMgd2hlbiBhcHBsaWVkIHRvIGdl dCBhIGZ1bmN0aW9uYWwgSW50ZXJuZXQNCiAgIG9mIFRoaW5ncy4NCg0KDQoNCg0KVGhlIElFVEYg U2VjcmV0YXJpYXQNCg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2Ug bWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVnYWxseSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGljYWJs ZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZShz KS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkg bm90aWZpZWQgdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9uLCBvciByZXBy b2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBi ZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNl IGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBjb3Bp ZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQo= From internet-drafts@ietf.org Mon Jul 11 12:44: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 8D79011E81CF; Mon, 11 Jul 2011 12:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, 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 O36o49RmUBY6; Mon, 11 Jul 2011 12:44:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC5611E80FB; Mon, 11 Jul 2011 12:44:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711194430.29662.25639.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 12:44:30 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-block-04.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: Mon, 11 Jul 2011 19:44:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Work= ing Group of the IETF. Title : Blockwise transfers in CoAP Author(s) : Carsten Bormann Zach Shelby Filename : draft-ietf-core-block-04.txt Pages : 23 Date : 2011-07-11 CoAP is a RESTful transfer protocol for constrained nodes and networks. CoAP is based on datagram transport, which limits the maximum size of resource representations that can be transferred without too much fragmentation. The Block options provide a minimal way to transfer larger representations in a block-wise fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-core-block-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-core-block-04.txt From sakane@tanu.org Mon Jul 11 23:29: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 5DF8921F9134 for ; Mon, 11 Jul 2011 23:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.723 X-Spam-Level: X-Spam-Status: No, score=-0.723 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_EQ_JP=1.265] 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 rp3u1U8fcGut for ; Mon, 11 Jul 2011 23:29:29 -0700 (PDT) Received: from mama.tanu.org (z189134.ppp.asahi-net.or.jp [110.4.189.134]) by ietfa.amsl.com (Postfix) with ESMTP id C6E2321F9133 for ; Mon, 11 Jul 2011 23:29:29 -0700 (PDT) Received: from mactanu.local (dhcp-shinjuku-64-104-9-183.cisco.com [64.104.9.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mama.tanu.org (Postfix) with ESMTPSA id 167BC16B1C for ; Tue, 12 Jul 2011 15:29:24 +0900 (JST) Message-ID: <4E1BE9C4.1090805@tanu.org> Date: Tue, 12 Jul 2011 15:29:24 +0900 From: Shoichi Sakane User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: core@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [core] patch for wireshark 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 Jul 2011 06:29:30 -0000 CoAP developers, I made a patch for the CoAP dissector of the wireshark, which corresponds to coap-07, block-04 and observe-02. It includes Olaf's modification. Thanks Olaf. http://www.tanu.org/~sakane/download/packet-coap-20110712-r37592.patch Note that you should use the revision #37592 in the svn repository because the latest development version doesn't work due to run-time error. Any feedback is welcome. Shoichi From kerlyn2001@gmail.com Tue Jul 12 05:31:37 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 ABC5E21F905B for ; Tue, 12 Jul 2011 05:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 rbcibpL-7OKO for ; Tue, 12 Jul 2011 05:31:37 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1923421F9057 for ; Tue, 12 Jul 2011 05:31:37 -0700 (PDT) Received: by iye7 with SMTP id 7so5574871iye.31 for ; Tue, 12 Jul 2011 05:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=qdc5XXvBsVMgdR44KO56ijBddDj/8HyHkRVHwBAjmHs=; b=mtJNHY2CJaFshr4XT6yAQQWeTdti7qe2j52VSvdrbX7atDID8cgFtp2dc0Cby54N6g SktyDUYcQl5wi05Wu6gJ/5f/l184rs/dPGa4ZM1EgI4q6jVMbkLBNYrwO3Jf8ramZrJ2 8g8fL/eYAEN8IPUQUA1BBb3b5nJWLmBKDnUkQ= MIME-Version: 1.0 Received: by 10.42.95.137 with SMTP id f9mr6872453icn.376.1310473896410; Tue, 12 Jul 2011 05:31:36 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.42.224.66 with HTTP; Tue, 12 Jul 2011 05:31:36 -0700 (PDT) In-Reply-To: <20110711230629.10376.55697.idtracker@ietfa.amsl.com> References: <20110711230629.10376.55697.idtracker@ietfa.amsl.com> Date: Tue, 12 Jul 2011 08:31:36 -0400 X-Google-Sender-Auth: W2pDbHy3XfRTng5CcdIwSq6tXas Message-ID: From: Kerry Lynn To: core Content-Type: multipart/alternative; boundary=20cf30363e91153edc04a7de7bfc Subject: [core] Fwd: New Version Notification for draft-lynn-core-discovery-mapping-01.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: Tue, 12 Jul 2011 12:31:37 -0000 --20cf30363e91153edc04a7de7bfc Content-Type: text/plain; charset=ISO-8859-1 A new version of Core RD <-> DNS-SD mapping has been posted, and we'd like 10 minutes (preferably after Zach's RD talk) to present this plus related topics from the most recent -bc draft. http://tools.ietf.org/html/draft-lynn-core-discovery-mapping-01 Thanks, -K- ---------- Forwarded message ---------- From: Date: Mon, Jul 11, 2011 at 7:06 PM Subject: New Version Notification for draft-lynn-core-discovery-mapping-01.txt To: kerlyn@ieee.org Cc: kerlyn@ieee.org, zach@sensinode.com A new version of I-D, draft-lynn-core-discovery-mapping-01.txt has been successfully submitted by Kerry Lynn and posted to the IETF repository. Filename: draft-lynn-core-discovery-mapping Revision: 01 Title: CoRE Link-Format to DNS-Based Service Discovery Mapping Creation date: 2011-07-11 WG ID: Individual Submission Number of pages: 10 Abstract: Resource and service discovery are complimentary. Resource discovery provides fine-grained detail about the content of a server, while service discovery can provide a scalable method to locate servers in large networks. This document defines a method for mapping between CoRE Link Format attributes and DNS-Based Service Discovery fields so the two methods may be used interchangeably to locate services. The IETF Secretariat --20cf30363e91153edc04a7de7bfc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A new version of Core RD <-> DNS-SD mapping has been posted, and we&#= 39;d like 10 minutes
(preferably after Zach's RD talk) to present t= his plus related topics from the most recent
-bc draft.


Thanks, -K-
---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, Jul= 11, 2011 at 7:06 PM
Subject: New Version Notification for draft-lynn-core-discovery-mapping-01.= txt
To: kerlyn@ieee= .org
Cc: kerlyn= @ieee.org, zach= @sensinode.com


A new version of I-D, draft-lynn-core-discovery-mapping-01.txt has = been successfully submitted by Kerry Lynn and posted to the IETF repository= .

Filename: =A0 =A0 =A0 =A0draft-lynn-core-discovery-mapping
Revision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 CoRE Link-Format to DNS-Based Service Discovery = Mapping
Creation date: =A0 2011-07-11
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 10

Abstract:
=A0 Resource and service discovery are complimentary. =A0Resource discover= y
=A0 provides fine-grained detail about the content of a server, while
=A0 service discovery can provide a scalable method to locate servers in =A0 large networks. =A0This document defines a method for mapping between<= br> =A0 CoRE Link Format attributes and DNS-Based Service Discovery fields so<= br> =A0 the two methods may be used interchangeably to locate services.




The IETF Secretariat

--20cf30363e91153edc04a7de7bfc-- From yoshihiro.ohba@toshiba.co.jp Tue Jul 12 06:32:41 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 7D2DC21F906E for ; Tue, 12 Jul 2011 06:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 oCishj6y1YJW for ; Tue, 12 Jul 2011 06:32:41 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 43BC721F9058 for ; Tue, 12 Jul 2011 06:32:40 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id p6CDWctY024461 for ; Tue, 12 Jul 2011 22:32:38 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id p6CDWcNF012717 for core@ietf.org; Tue, 12 Jul 2011 22:32:38 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id YAA12716; Tue, 12 Jul 2011 22:32:38 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id p6CDWcmM014347 for ; Tue, 12 Jul 2011 22:32:38 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id p6CDWbWj002150; Tue, 12 Jul 2011 22:32:37 +0900 (JST) Received: from [133.199.18.176] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0LO800F3F2YD03A0@mail.po.toshiba.co.jp> for core@ietf.org; Tue, 12 Jul 2011 22:32:37 +0900 (JST) Date: Tue, 12 Jul 2011 22:32:09 +0900 From: Yoshihiro Ohba To: core Message-id: <4E1C4CD9.2090507@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 Subject: [core] Fwd: New Version Notification for draft-ohba-core-eap-based-bootstrapping-00.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: Tue, 12 Jul 2011 13:32:41 -0000 Hi, We submitted the following I-D. Your comments are appreciated. Yoshihiro Ohba -------- Original Message -------- Subject: New Version Notification for draft-ohba-core-eap-based-bootstrapping-00.txt Date: Fri, 01 Jul 2011 10:45:06 -0700 From: internet-drafts@ietf.org To: yohba727@gmail.com CC: yohba727@gmail.com, subir@research.telcordia.com, yoshihiro.ohba@toshiba.co.jp A new version of I-D, draft-ohba-core-eap-based-bootstrapping-00.txt has been successfully submitted by Yoshihiro Ohba and posted to the IETF repository. Filename: draft-ohba-core-eap-based-bootstrapping Revision: 00 Title: Bootstrapping CoAP Applications for Resource-Constrained Devices using EAP Creation date: 2011-07-01 WG ID: Individual Submission Number of pages: 9 Abstract: This document describes a mechanism to use EAP (Extensible Authentication Protocol) for bootstrapping DTLS-PSK (Pre-Shared Key) ciphersuites and PSK mode of IKEv2 that are used for establishing a secure communication channel between a CoAP (Constrained Application) client and a CoAP server to protect CoAP messaging. The IETF Secretariat From behcetsarikaya@yahoo.com Tue Jul 12 10:08:42 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 0B1BD21F8E50 for ; Tue, 12 Jul 2011 10:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.433 X-Spam-Level: X-Spam-Status: No, score=-0.433 tagged_above=-999 required=5 tests=[AWL=-0.434, BAYES_50=0.001] 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 D+sXLN8fC-6u for ; Tue, 12 Jul 2011 10:08:41 -0700 (PDT) Received: from nm5.bullet.mail.sp2.yahoo.com (nm5.bullet.mail.sp2.yahoo.com [98.139.91.75]) by ietfa.amsl.com (Postfix) with SMTP id 221C421F8E49 for ; Tue, 12 Jul 2011 10:08:41 -0700 (PDT) Received: from [98.139.91.65] by nm5.bullet.mail.sp2.yahoo.com with NNFMP; 12 Jul 2011 17:08:38 -0000 Received: from [98.139.91.27] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 12 Jul 2011 17:08:38 -0000 Received: from [127.0.0.1] by omp1027.mail.sp2.yahoo.com with NNFMP; 12 Jul 2011 17:08:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 502645.81850.bm@omp1027.mail.sp2.yahoo.com Received: (qmail 85288 invoked by uid 60001); 12 Jul 2011 17:08:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1310490518; bh=LYn1wO4rDiULzCOO8mR1/W5WrHWDqexwHDvUFwXTQGY=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=u9oA03+vPqr0h3APqhAfkvAyciY8sKAMgYgl9CicQDzasuNcCIRg+Z/ss6nAfyEuEL8lSFO41rpHxV8tRPJUdQZiTLb6aT2jL+4HkOMjm1v8z8x6nbXr/3qAzIFk+MYIbaRd98+lOEupeBl9GBCfsgKZNWQkZlZjJh8D0BQS94Q= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=KqlR5m41gRL257yjgWpdpnTaoi+93AxE7C/TROlpay+9D+wEo+vKu4n/30/fg6oxAFEdz08mFl9pmryfUdOAMu0e9J75IAjxkLpmiOBwsde3g0adV+Owbuf+VRjLKDW9KVFq84HvN5teAw2zMR/9/7cZd2UV9X4+Ic7bxt38KQE=; X-YMail-OSG: _EPqNxwVM1kBORiCpDkZTAEhVBgsB6uF5KJrfrGuiVRs7Az 8OXFEt1fZ.AZLWTr4lXvOuiPvBTE0k_EnBQyj96dKb4P_FShq.YgNJwP_5sU MiZaGA8OZFzfm14vFNyJTpeD_DVxkQvyM3ENbK87oJxOD3uZT4HVBYKberWa z6SjCD3csMDI.P1xjP9oUeCrpFYPoNVy9.EvUMx33Jql9ZpxxTvH2qbL2mz3 VoWeGmPRdJ8mojuPOJc.iMQKjOHZ0AS3TNRfb1_5i9HVaM8cU7PanZiJ7yLz QmkhIglkOaF5w7a.xewAJ2e7UnGdoaW68bx2RboGB9mEP5mSGcYKZajSwJKG ydhSauFDd4PMuR38s4iW7nhP96qlCjW43zdwE.aDQM9xVlZweBFPHf.MjECW FLcB25sWXuMmoTQ-- Received: from [50.58.7.243] by web111403.mail.gq1.yahoo.com via HTTP; Tue, 12 Jul 2011 10:08:37 PDT X-Mailer: YahooMailRC/572 YahooMailWebService/0.8.112.307740 Message-ID: <1310490517.84307.YahooMailRC@web111403.mail.gq1.yahoo.com> Date: Tue, 12 Jul 2011 10:08:37 -0700 (PDT) From: Behcet Sarikaya To: core MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [core] Bootstrap in draft-ohba-core-eap-based-bootstrapping and draft-garcia-core-security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya 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 Jul 2011 17:08:42 -0000 Hi all, It seems that the word bootstrapping has been used and overused in so many drafts (including draft-ohba-core-eap-based-bootstrapping and draft-garcia-core-security) and I suggest that we clarify this. Colin had a draft on Initial Configuration of Resource-Constrained Devices called draft-oflynn-6lowapp-bootstrapping submitted on Jan. 2010 in which he defined bootstrapping ashow to initially configure the network. Later on we continued this work on where Colin left indraft-sarikaya-core-sbootstrapping. I think that the definition Colin gave to bootstrapping is the right one. It matches with the historical use of bootstrapping in computers: you bootstrap your computer to initially configure it by a physical action (pressing a button) which loads a small record to the memory which when executed bootstraps (brings the whole OS to the memory) the system. Regards, Behcet From hannes.tschofenig@gmx.net Tue Jul 12 10:28:18 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 7BCF321F8CAB for ; Tue, 12 Jul 2011 10:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, 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 OKpuN4TA3MTi for ; Tue, 12 Jul 2011 10:28:06 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id B179B21F8C73 for ; Tue, 12 Jul 2011 10:28:05 -0700 (PDT) Received: (qmail invoked by alias); 12 Jul 2011 17:28:04 -0000 Received: from letku214.adsl.netsonic.fi (EHLO [10.0.0.6]) [194.29.195.214] by mail.gmx.net (mp062) with SMTP; 12 Jul 2011 19:28:04 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/MT/8jUwXMV2XCB54GxmWSaRWxsDQ2c3Hcn0L2D8 Ku5+Nv7P7C1/1/ Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <1310490517.84307.YahooMailRC@web111403.mail.gq1.yahoo.com> Date: Tue, 12 Jul 2011 20:28:01 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <96EBDFA8-7693-4A46-BA3A-6085A790B1DF@gmx.net> References: <1310490517.84307.YahooMailRC@web111403.mail.gq1.yahoo.com> To: Behcet Sarikaya X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: core Subject: Re: [core] Bootstrap in draft-ohba-core-eap-based-bootstrapping and draft-garcia-core-security 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 Jul 2011 17:28:18 -0000 Hi Behcet,=20 I agree with you that the term "bootstrapping" is not very helpful. There are three cases:=20 a) Key Distribution and Key Derivation Here an existing keying material is used to derive other keying material = or to use securely distribute keying material.=20 draft-ohba-core-eap-based-bootstrapping and=20 b) Bootstrapping (in terms of operating systems procedures) See description in = http://en.wikipedia.org/wiki/Bootstrapping_%28computing%29 draft-garcia-core-security seems to refer to this aspect, I believe.=20 c) Establishing initial keying material in a leap of faith style.=20 Example: Bluetooth pairing protocol http://tools.ietf.org/html/draft-pritikin-ttimodel-01 also discusses = these aspects.=20 Here the terms used are imprinting, pairing, enrollment, and = introduction are used to describe=20 Ciao Hannes On Jul 12, 2011, at 8:08 PM, Behcet Sarikaya wrote: > Hi all, > It seems that the word bootstrapping has been used and overused in so = many=20 > drafts (including draft-ohba-core-eap-based-bootstrapping and=20 > draft-garcia-core-security) and I suggest that we clarify this. >=20 > Colin had a draft on=20 > Initial Configuration of Resource-Constrained Devices > called draft-oflynn-6lowapp-bootstrapping submitted on Jan. 2010 in = which he=20 > defined bootstrapping ashow to initially configure the network. >=20 > Later on we continued this work on where Colin left=20 > indraft-sarikaya-core-sbootstrapping. >=20 > I think that the definition Colin gave to bootstrapping is the right = one. It=20 > matches with the historical use of bootstrapping in computers: you = bootstrap=20 > your computer to initially configure it by a physical action (pressing = a button)=20 > which loads a small record to the memory which when executed = bootstraps (brings=20 > the whole OS to the memory) the system. >=20 > Regards, >=20 > Behcet > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From behcetsarikaya@yahoo.com Tue Jul 12 12:26: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 E742B21F8CFF for ; Tue, 12 Jul 2011 12:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.694 X-Spam-Level: X-Spam-Status: No, score=-1.694 tagged_above=-999 required=5 tests=[AWL=0.905, 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 kEXwB7OpH07r for ; Tue, 12 Jul 2011 12:25:59 -0700 (PDT) Received: from nm27-vm1.bullet.mail.sp2.yahoo.com (nm27-vm1.bullet.mail.sp2.yahoo.com [98.139.91.233]) by ietfa.amsl.com (Postfix) with SMTP id B2F4221F8C4A for ; Tue, 12 Jul 2011 12:25:59 -0700 (PDT) Received: from [98.139.91.67] by nm27.bullet.mail.sp2.yahoo.com with NNFMP; 12 Jul 2011 19:25:57 -0000 Received: from [98.139.91.44] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 12 Jul 2011 19:25:57 -0000 Received: from [127.0.0.1] by omp1044.mail.sp2.yahoo.com with NNFMP; 12 Jul 2011 19:25:57 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 199381.48263.bm@omp1044.mail.sp2.yahoo.com Received: (qmail 63504 invoked by uid 60001); 12 Jul 2011 19:25:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1310498756; bh=yU2DpjhTs9iN4MBlNVYwmNrOr0AxHVDwYrq2tKPoDnQ=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=YGOoYzvk7bZ92YwZnq7ftI1Zk7RSvkLJB43KlZmAkkUKpaiyzVmPHVA2kbtZyrSOVhryBq2xtp4aKUR/RQ3BGYr8XRjHBdwKPF2+Tvg++nk0R5v06hLjeMpKZTjgxjTOcl3lOZbKH7lb8hudtu3tTTm5oDZUUGjqAv6rXH+n1tc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=cRRl+lp45ZX+R8460ybJY3dgVoHIi4YwDdpUjDMltWyEGSRUAg1a5sHiDUUKk6F/8hu8yIYnSBcxG7gR5doCSUWi3OAAt454AhQYYFtUK6l6Dex7DHB9EOFmhPkyxisOmMKzYmOXOBrQ79JSEdBkHLLmh4XhVklC+BJffm/jKiE=; X-YMail-OSG: Yv63RBEVM1lZnKTAFIITQyQLbHFmYrRevqq_TGan_vFsw9Y j8Qqb..u2Sv369oElf48mmHnDhhE5HzayyQqnZefRa.NPtEBcS3rvkS766Jh fmlZnDVN6jDr0kXDslRN_nCzn9oLkeAfsazCOvIBB_Ide1vd1jjHOynXAi3G _SV7zXria733YmbV3b2yAyQvfX6gZUYsPoCYo4lzZEbHWNCDXNpQdDIW73Jb bpBcD2iXDSvtlpGGWgvZZA0yF5httdBZuYSB9K6wS3rEsWOGrPyYkQ0.G9v7 Ug.TyZMXaZg4DUZmaKFWQR5mfUq7oqfHIq84EpjSDulPZVHDe1wnf.auLPtf WBJklbsTzZlZ3Tsu0CvvtD24omkhieB9CDPzgQThTyGavex8RXCrUy.gYnWc PZqhhuPAc50Tl_QUwsJ4Ck46tJahoe1g44EKileC4v4_ljysM0PwKCCY_CzF .EUs2TiMrUXtFsx7PTUHCtZ9nTqSVyodbCt6LuvLHgSJziAs45fbgmHWDTX. F3oP1 Received: from [50.58.7.243] by web111406.mail.gq1.yahoo.com via HTTP; Tue, 12 Jul 2011 12:25:55 PDT X-Mailer: YahooMailRC/572 YahooMailWebService/0.8.112.307740 References: <1310490517.84307.YahooMailRC@web111403.mail.gq1.yahoo.com> <96EBDFA8-7693-4A46-BA3A-6085A790B1DF@gmx.net> Message-ID: <1310498755.53153.YahooMailRC@web111406.mail.gq1.yahoo.com> Date: Tue, 12 Jul 2011 12:25:55 -0700 (PDT) From: Behcet Sarikaya To: core In-Reply-To: <96EBDFA8-7693-4A46-BA3A-6085A790B1DF@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [core] Bootstrap in draft-ohba-core-eap-based-bootstrapping and draft-garcia-core-security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya 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 Jul 2011 19:26:04 -0000 Hi Hannes (Kelly and Rene who replied to me only), Let me clarify. I checked the Wiki page, it is about what I talked, i.e. bootstrapping your PC. I am OK with it. In Core WG drafts, draft-ohba is about "bootstrapping" CoAP applications, establishing a secure channel between the CoAP client and CoAP server. As such it assumes a secure IP communication which is what we cover in draft-sarikaya. I think that establishing a secure channel between the CoAP client and CoAP server should not be called bootstrapping. OTOH, draft-garcia is totally chaotic about "bootstrapping". In Section 3 it talks about trust bootstrapping between nodes of different vendors. Then it talks about bootstrapping phase/procedures. Later on they mention the bootstrapping of security keys. Section 5.2 Bootstrapping of a Security Domain In Section 5.2.2 it tries to give a definition to bootstrapping. My suggestions are: for draft-ohba: please do not use bootstrapping, otherwise your draft is clear enough. for draft-garcia: This draft talks about so many things. In most places, what it refers to as bootstrapping and the description match what is covered in the original document which is draft-sarikaya. I suggest removing all those sections about bootstrapping because they are mostly repeating what we already had. Stay with whatever remains and see if it is worth to have such a document. Regards, Behcet > Hi Behcet, > > I agree with you that the term "bootstrapping" is not very helpful. > > There are three cases: > > a) Key Distribution and Key Derivation > > Here an existing keying material is used to derive other keying material or to >use securely distribute keying material. > > draft-ohba-core-eap-based-bootstrapping and > > b) Bootstrapping (in terms of operating systems procedures) > > See description in http://en.wikipedia.org/wiki/Bootstrapping_%28computing%29 > > draft-garcia-core-security seems to refer to this aspect, I believe. > > c) Establishing initial keying material in a leap of faith style. > > Example: Bluetooth pairing protocol > http://tools.ietf.org/html/draft-pritikin-ttimodel-01 also discusses these >aspects. > > Here the terms used are imprinting, pairing, enrollment, and introduction are >used to describe > > > Ciao > Hannes > > On Jul 12, 2011, at 8:08 PM, Behcet Sarikaya wrote: > > > Hi all, > > It seems that the word bootstrapping has been used and overused in so many > > drafts (including draft-ohba-core-eap-based-bootstrapping and > > draft-garcia-core-security) and I suggest that we clarify this. > > > > Colin had a draft on > > Initial Configuration of Resource-Constrained Devices > > called draft-oflynn-6lowapp-bootstrapping submitted on Jan. 2010 in which he > > > defined bootstrapping ashow to initially configure the network. > > > > Later on we continued this work on where Colin left > > indraft-sarikaya-core-sbootstrapping. > > > > I think that the definition Colin gave to bootstrapping is the right one. It > > > matches with the historical use of bootstrapping in computers: you bootstrap > > > your computer to initially configure it by a physical action (pressing a >button) > > > which loads a small record to the memory which when executed bootstraps >(brings > > > the whole OS to the memory) the system. > > > > Regards, > > > > Behcet > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > From yoshihiro.ohba@toshiba.co.jp Tue Jul 12 16:13:51 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 E6DAB11E80A4 for ; Tue, 12 Jul 2011 16:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 cAoOQAjpnm27 for ; Tue, 12 Jul 2011 16:13:47 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3167D11E80A2 for ; Tue, 12 Jul 2011 16:13:46 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id p6CNDjbf002149 for ; Wed, 13 Jul 2011 08:13:45 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id p6CNDjJ3014011 for core@ietf.org; Wed, 13 Jul 2011 08:13:45 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id JAA13995; Wed, 13 Jul 2011 08:13:44 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id p6CNDitB001005 for ; Wed, 13 Jul 2011 08:13:44 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id p6CNDiOV014290; Wed, 13 Jul 2011 08:13:44 +0900 (JST) Received: from [133.196.16.151] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0LO800FVSTUW03E0@mail.po.toshiba.co.jp> for core@ietf.org; Wed, 13 Jul 2011 08:13:44 +0900 (JST) Date: Wed, 13 Jul 2011 08:13:15 +0900 From: Yoshihiro Ohba In-reply-to: <1310498755.53153.YahooMailRC@web111406.mail.gq1.yahoo.com> To: core@ietf.org Message-id: <4E1CD50B.6090505@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <1310490517.84307.YahooMailRC@web111403.mail.gq1.yahoo.com> <96EBDFA8-7693-4A46-BA3A-6085A790B1DF@gmx.net> <1310498755.53153.YahooMailRC@web111406.mail.gq1.yahoo.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 Subject: Re: [core] Bootstrap in draft-ohba-core-eap-based-bootstrapping and draft-garcia-core-security 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 Jul 2011 23:13:52 -0000 Hi Hannes, Bahcet, Please see my comments below. (2011/07/13 4:25), Behcet Sarikaya wrote: > Hi Hannes (Kelly and Rene who replied to me only), > > > Let me clarify. > > I checked the Wiki page, it is about what I talked, i.e. bootstrapping your PC. > I am OK with it. > > In Core WG drafts, draft-ohba is about "bootstrapping" CoAP applications, > establishing a secure channel between the CoAP client and CoAP server. > Yes. > As such it assumes a secure IP communication which is what we cover in > draft-sarikaya. > > I think that establishing a secure channel between the CoAP client and CoAP > server should not be called bootstrapping. For example, RFC 4640 discuss "bootstrapping MIPv6", and in its abstract: "A mobile node needs at least the following information: a home address, a home agent address, and a security association with home agent to register with the home agent. The process of obtaining this information is called bootstrapping." This means that bootstrapping MIPv6 security is part of bootstrapping MIPv6. Following the same logic, I think bootstrapping CoAP security can be considered as part of bootstrapping CoAP application. > > OTOH, draft-garcia is totally chaotic about "bootstrapping". In Section 3 it > talks about trust bootstrapping between nodes of > different vendors. Then it talks about bootstrapping phase/procedures. > Later on they mention the bootstrapping of security keys. > > Section 5.2 Bootstrapping of a Security Domain > In Section 5.2.2 it tries to give a definition to bootstrapping. > > My suggestions are: > > for draft-ohba: please do not use bootstrapping, otherwise your draft is clear > enough. Since the term bootstrapping is already used for MIPv6 case, I think it can still use the term, but I agree that the draft should say bootstrapping CoAP security instead of bootstrapping CoAP application. Regards, Yoshihiro Ohba > > for draft-garcia: This draft talks about so many things. In most places, what it > refers to as bootstrapping and the description match what is covered in the > original document which is draft-sarikaya. I suggest removing all those sections > about bootstrapping because they are mostly repeating what we already had. Stay > with whatever remains and see if it is worth to have such a document. > > Regards, > > Behcet > > > >> Hi Behcet, >> >> I agree with you that the term "bootstrapping" is not very helpful. >> >> There are three cases: >> >> a) Key Distribution and Key Derivation >> >> Here an existing keying material is used to derive other keying material or to >> use securely distribute keying material. >> >> draft-ohba-core-eap-based-bootstrapping and >> >> b) Bootstrapping (in terms of operating systems procedures) >> >> See description in http://en.wikipedia.org/wiki/Bootstrapping_%28computing%29 >> >> draft-garcia-core-security seems to refer to this aspect, I believe. >> >> c) Establishing initial keying material in a leap of faith style. >> >> Example: Bluetooth pairing protocol >> http://tools.ietf.org/html/draft-pritikin-ttimodel-01 also discusses these >> aspects. >> >> Here the terms used are imprinting, pairing, enrollment, and introduction are >> used to describe >> >> >> Ciao >> Hannes >> >> On Jul 12, 2011, at 8:08 PM, Behcet Sarikaya wrote: >> >>> Hi all, >>> It seems that the word bootstrapping has been used and overused in so many > >>> drafts (including draft-ohba-core-eap-based-bootstrapping and >>> draft-garcia-core-security) and I suggest that we clarify this. >>> >>> Colin had a draft on >>> Initial Configuration of Resource-Constrained Devices >>> called draft-oflynn-6lowapp-bootstrapping submitted on Jan. 2010 in which he >> >>> defined bootstrapping ashow to initially configure the network. >>> >>> Later on we continued this work on where Colin left >>> indraft-sarikaya-core-sbootstrapping. >>> >>> I think that the definition Colin gave to bootstrapping is the right one. It >> >>> matches with the historical use of bootstrapping in computers: you bootstrap >> >>> your computer to initially configure it by a physical action (pressing a >> button) >> >>> which loads a small record to the memory which when executed bootstraps >> (brings >> >>> the whole OS to the memory) the system. >>> >>> Regards, >>> >>> Behcet >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >> >> > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From zehn.cao@gmail.com Wed Jul 13 01:19:53 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 ED81821F8BFE for ; Wed, 13 Jul 2011 01:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, 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 7WNL7j-tNg7t for ; Wed, 13 Jul 2011 01:19:50 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 00C2021F8BF6 for ; Wed, 13 Jul 2011 01:19:49 -0700 (PDT) Received: by iwn39 with SMTP id 39so6424424iwn.31 for ; Wed, 13 Jul 2011 01:19:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5Don7+fzDC2fcHZKqhWxnjfuXyrSq6L0FnTqUdQgUM0=; b=YnOCrMfMkGa0j8rJTktBtgUlNS3F/FAcxudBFGsYyIY4tKxMyy5XHwJDMoCrgix+pk UjpMV5Jfux+np64CuVnkp1/FnQnZ5CYZf9axp76e/BLQNylarHwMPCMh+uPq2GYN75pS xb9AE0yTmPTLzYJgjb9NF33n4b9/KEdB30qwU= MIME-Version: 1.0 Received: by 10.42.132.72 with SMTP id c8mr838565ict.505.1310545189440; Wed, 13 Jul 2011 01:19:49 -0700 (PDT) Received: by 10.42.166.8 with HTTP; Wed, 13 Jul 2011 01:19:49 -0700 (PDT) In-Reply-To: <4E1BE9C4.1090805@tanu.org> References: <4E1BE9C4.1090805@tanu.org> Date: Wed, 13 Jul 2011 16:19:49 +0800 Message-ID: From: Zhen Cao To: Shoichi Sakane Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core@ietf.org Subject: Re: [core] patch for wireshark 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 Jul 2011 08:19:54 -0000 Thank you for your work. I will try it. On Tue, Jul 12, 2011 at 2:29 PM, Shoichi Sakane wrote: > CoAP developers, > > I made a patch for the CoAP dissector of the wireshark, which > corresponds to coap-07, block-04 and observe-02. =A0It includes > Olaf's modification. =A0Thanks Olaf. > > http://www.tanu.org/~sakane/download/packet-coap-20110712-r37592.patch > > Note that you should use the revision #37592 in the svn repository > because the latest development version doesn't work due to > run-time error. > > Any feedback is welcome. > > Shoichi > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --=20 Best regards, Zhen From hannes.tschofenig@gmx.net Wed Jul 13 01:34:04 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 664BD21F8BCD for ; Wed, 13 Jul 2011 01:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, 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 Mq1LzAk132As for ; Wed, 13 Jul 2011 01:34:00 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 247B321F8B49 for ; Wed, 13 Jul 2011 01:33:59 -0700 (PDT) Received: (qmail invoked by alias); 13 Jul 2011 08:33:58 -0000 Received: from letku214.adsl.netsonic.fi (EHLO [10.0.0.6]) [194.29.195.214] by mail.gmx.net (mp067) with SMTP; 13 Jul 2011 10:33:58 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19YIG9LTVtYoNYiPTIibEcTWe9lIQyZZID7dLO20g uItJs07uIV3Q9P Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4E1CD50B.6090505@toshiba.co.jp> Date: Wed, 13 Jul 2011 11:33:57 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1310490517.84307.YahooMailRC@web111403.mail.gq1.yahoo.com> <96EBDFA8-7693-4A46-BA3A-6085A790B1DF@gmx.net> <1310498755.53153.YahooMailRC@web111406.mail.gq1.yahoo.com> <4E1CD50B.6090505@toshiba.co.jp> To: Yoshihiro Ohba X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: core@ietf.org Subject: Re: [core] Bootstrap in draft-ohba-core-eap-based-bootstrapping and draft-garcia-core-security 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 Jul 2011 08:34:04 -0000 Hi Yoshi,=20 it was a mistake to use the term "bootstrapping" in mobile IPv6 context = as well.=20 There was no good reason to create a new term given the existence of = already well-established terms.=20 Time to change that. Ciao Hannes On Jul 13, 2011, at 2:13 AM, Yoshihiro Ohba wrote: > Hi Hannes, Bahcet, >=20 > Please see my comments below. >=20 > (2011/07/13 4:25), Behcet Sarikaya wrote: >> Hi Hannes (Kelly and Rene who replied to me only), >>=20 >>=20 >> Let me clarify. >>=20 >> I checked the Wiki page, it is about what I talked, i.e. = bootstrapping your PC. >> I am OK with it. >>=20 >> In Core WG drafts, draft-ohba is about "bootstrapping" CoAP = applications, >> establishing a secure channel between the CoAP client and CoAP = server. >>=20 >=20 > Yes. >=20 >> As such it assumes a secure IP communication which is what we cover = in >> draft-sarikaya. >>=20 >> I think that establishing a secure channel between the CoAP client = and CoAP >> server should not be called bootstrapping. >=20 > For example, RFC 4640 discuss "bootstrapping MIPv6", and in its = abstract: >=20 > "A mobile node needs at least the following information: a home > address, a home agent address, and a security association with home > agent to register with the home agent. The process of obtaining this > information is called bootstrapping." >=20 > This means that bootstrapping MIPv6 security is part of bootstrapping > MIPv6. >=20 > Following the same logic, I think bootstrapping CoAP security can be > considered as part of bootstrapping CoAP application. >=20 >>=20 >> OTOH, draft-garcia is totally chaotic about "bootstrapping". In = Section 3 it >> talks about trust bootstrapping between nodes of >> different vendors. Then it talks about bootstrapping = phase/procedures. >> Later on they mention the bootstrapping of security keys. >>=20 >> Section 5.2 Bootstrapping of a Security Domain >> In Section 5.2.2 it tries to give a definition to bootstrapping. >>=20 >> My suggestions are: >>=20 >> for draft-ohba: please do not use bootstrapping, otherwise your draft = is clear >> enough. >=20 > Since the term bootstrapping is already used for MIPv6 case, I think > it can still use the term, but I agree that the draft should say > bootstrapping CoAP security instead of bootstrapping CoAP application. >=20 > Regards, > Yoshihiro Ohba >=20 >=20 >=20 >>=20 >> for draft-garcia: This draft talks about so many things. In most = places, what it >> refers to as bootstrapping and the description match what is covered = in the >> original document which is draft-sarikaya. I suggest removing all = those sections >> about bootstrapping because they are mostly repeating what we already = had. Stay >> with whatever remains and see if it is worth to have such a document. >>=20 >> Regards, >>=20 >> Behcet >>=20 >>=20 >>=20 >>> Hi Behcet, >>>=20 >>> I agree with you that the term "bootstrapping" is not very helpful. >>>=20 >>> There are three cases: >>>=20 >>> a) Key Distribution and Key Derivation >>>=20 >>> Here an existing keying material is used to derive other keying = material or to >>> use securely distribute keying material. >>>=20 >>> draft-ohba-core-eap-based-bootstrapping and >>>=20 >>> b) Bootstrapping (in terms of operating systems procedures) >>>=20 >>> See description in = http://en.wikipedia.org/wiki/Bootstrapping_%28computing%29 >>>=20 >>> draft-garcia-core-security seems to refer to this aspect, I = believe. >>>=20 >>> c) Establishing initial keying material in a leap of faith style. >>>=20 >>> Example: Bluetooth pairing protocol >>> http://tools.ietf.org/html/draft-pritikin-ttimodel-01 also discusses = these >>> aspects. >>>=20 >>> Here the terms used are imprinting, pairing, enrollment, and = introduction are >>> used to describe >>>=20 >>>=20 >>> Ciao >>> Hannes >>>=20 >>> On Jul 12, 2011, at 8:08 PM, Behcet Sarikaya wrote: >>>=20 >>>> Hi all, >>>> It seems that the word bootstrapping has been used and overused = in so many >>=20 >>>> drafts (including draft-ohba-core-eap-based-bootstrapping and >>>> draft-garcia-core-security) and I suggest that we clarify this. >>>>=20 >>>> Colin had a draft on >>>> Initial Configuration of Resource-Constrained Devices >>>> called draft-oflynn-6lowapp-bootstrapping submitted on Jan. 2010 = in which he >>>=20 >>>> defined bootstrapping ashow to initially configure the network. >>>>=20 >>>> Later on we continued this work on where Colin left >>>> indraft-sarikaya-core-sbootstrapping. >>>>=20 >>>> I think that the definition Colin gave to bootstrapping is the = right one. It >>>=20 >>>> matches with the historical use of bootstrapping in computers: you = bootstrap >>>=20 >>>> your computer to initially configure it by a physical action = (pressing a >>> button) >>>=20 >>>> which loads a small record to the memory which when executed = bootstraps >>> (brings >>>=20 >>>> the whole OS to the memory) the system. >>>>=20 >>>> Regards, >>>>=20 >>>> Behcet >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>=20 >>>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >>=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From zehn.cao@gmail.com Wed Jul 13 03:50:46 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 99A1321F86DE; Wed, 13 Jul 2011 03:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, 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 cjwd+egK159q; Wed, 13 Jul 2011 03:50:46 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E864721F86DD; Wed, 13 Jul 2011 03:50:45 -0700 (PDT) Received: by iye7 with SMTP id 7so6549392iye.31 for ; Wed, 13 Jul 2011 03:50:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=D6j7vwApHht8n3ofxOeT8FU0WsBLpShy5CTTrBxQBAw=; b=tL+BA304tMPOq3u8++vmv9j4Z0D5EI0bcH+uOdHrmifNlw0B9v7AVSrsUfHvQmCmEx kHQS4oWgyq0bcXfmUP/BN3cK1htqC8oBaGc1IUsUbGt9jU99FrDauXHoSyEdkqYjp59V lPIYfag79FDUC3y+anWti3g8ChEcy/+h0NKjQ= MIME-Version: 1.0 Received: by 10.42.19.134 with SMTP id c6mr1123683icb.371.1310554245540; Wed, 13 Jul 2011 03:50:45 -0700 (PDT) Received: by 10.42.166.8 with HTTP; Wed, 13 Jul 2011 03:50:45 -0700 (PDT) In-Reply-To: <4E11C2BE.8010605@piuha.net> References: <4E11C2BE.8010605@piuha.net> Date: Wed, 13 Jul 2011 18:50:45 +0800 Message-ID: From: Zhen Cao To: Jari Arkko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: lwip@ietf.org, core Subject: Re: [core] [Lwip] draft about implementation techniques for ensuring COAP implementations can sleep 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 Jul 2011 10:50:46 -0000 Hi Jari and authors, This is draft serves very much for a CoAP implementation guidance. I have some questions and comments as below: Questions: What's kind of tiny devices are you playing with? You mentioned 32-bit processor, how about the data and code size? For the CoAP implementation, is it built on top of some tiny operating system or stand alone? Comments: In Section 4.2, there is a strong message that the CoAP server model is NOT RECOMMENDED. It should be discussed though. In most cases of the m2m applications and services, it usually is the network side that initiates the communication and gets some information from the sensor, and I think that's why CoAP server model seems to be the default model in draft-ietf-core-coap. Yes, having the sensor proactively post information to the server slide is one way to circumvent the sleeping node issue. What has been lost here is that the sensor needs to send the message one by one which is also energy consuming. In some implementations, as discussed in section 4.1, a well-known url can be used, but in many others, the server model is still inevitably used, where "sleeping compatible protocols" (the term of Margret's position paper in last IAB IOT Workshop) or always online mechanisms are expected. On Mon, Jul 4, 2011 at 9:40 PM, Jari Arkko wrote: > FYI. Comments appreciated. > > http://tools.ietf.org/html/draft-arkko-core-sleepy-sensors-00 > >> Filename: =A0 =A0 =A0 =A0draft-arkko-core-sleepy-sensors >> Revision: =A0 =A0 =A0 =A000 >> Title: =A0 =A0 =A0 =A0 =A0 Implementing Tiny COAP Sensors >> Creation date: =A0 2011-07-04 >> >> Abstract: >> =A0 The authors are developing COAP and IPv6-based sensor networks for >> =A0 environments where lightweight implementations, long battery >> =A0 lifetimes, and minimal management burden are important. =A0The memo >> =A0 shows how different communication models supported by COAP affect >> =A0 implementation complexity and energy consumption, far more so than >> =A0 mere changes in message syntax. =A0Our prototype implements a >> =A0 multicast-based IPv6, UDP, COAP, and XML protocol stack in less than >> =A0 50 assembler instructions. =A0While this extremely minimal >> =A0 implementation is suitable only for limited applications and makes a >> =A0 number of assumptions, the general conclusions point to need for >> =A0 further work in developing the COAP multicast and observation >> =A0 frameworks. >> > > _______________________________________________ > Lwip mailing list > Lwip@ietf.org > https://www.ietf.org/mailman/listinfo/lwip > --=20 Best regards, Zhen From behcetsarikaya@yahoo.com Wed Jul 13 08:26:29 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 E1E3A11E811E for ; Wed, 13 Jul 2011 08:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.769 X-Spam-Level: X-Spam-Status: No, score=-1.769 tagged_above=-999 required=5 tests=[AWL=0.830, 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 nKrTIolTH3jJ for ; Wed, 13 Jul 2011 08:26:25 -0700 (PDT) Received: from nm3.bullet.mail.sp2.yahoo.com (nm3.bullet.mail.sp2.yahoo.com [98.139.91.73]) by ietfa.amsl.com (Postfix) with SMTP id 7193411E8113 for ; Wed, 13 Jul 2011 08:26:23 -0700 (PDT) Received: from [98.139.91.67] by nm3.bullet.mail.sp2.yahoo.com with NNFMP; 13 Jul 2011 15:26:23 -0000 Received: from [98.139.91.4] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 13 Jul 2011 15:26:23 -0000 Received: from [127.0.0.1] by omp1004.mail.sp2.yahoo.com with NNFMP; 13 Jul 2011 15:26:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 391428.3441.bm@omp1004.mail.sp2.yahoo.com Received: (qmail 59397 invoked by uid 60001); 13 Jul 2011 15:26:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1310570782; bh=zSQ2fOuvVFHgGe3owSRb9V2PMZ9Fr0Sp4N464aZWuhU=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=hnADI5vNkikVCnnnPcdtptQOKBbKpj8+35OWs1n2m52dhJrT8ijQ0kMrJzJJ1cC2Gjz964dTUpW1RGtm2KV3OoRzWU7pJff6TKRRcSLBO1vc00r9al2BKBqzodpUsAcugsjvkpxovOj7MC+r9HmKxra0p7wgFURgQX3UHZsDLlo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=01Vls5UEBLbP+RYZCYXNbk0vfRC7jPepwfPbeu6k761Ft1wLcExpjhm2qo704F2bYz+sd0RREvivgdI/438QKp/bGLmIRlamnJW4gVSuCLyIFSwcbROiB/Ihie+5p3xMv4NnubN3P1WbhyuOgvOJ8U7oOuoYiv1lzcYi6PfObfk=; X-YMail-OSG: yquQ9qUVM1m4jsJBcA6xkWIIWsRmsesn0eqaQ8aq6.OSv2f SbVu1_lNdW5.N0ZFrPzmQUUgeAE7DzH2RW5AlcaAE2em01tcM4jhCmQVcgRe .cdGy7u.G755wtf9m8APqf_.8IyNlpyvszC.5e3KhFrsZXe42e_Qx0CFf136 TzL2IcZEu.u_4YG2ct0z0JCRvgoRZCmr8JBCV6OUnwIQDiYmOECxkFE0gk6r wfEXdd6iJfBrPjjRV3gVobPcW_m9sVyraRmAVX9QMKM.UZwfqNCmlXCCFJIx lAWlCTt_d4_Ter44aga_54n074xwRL9HSsoP7V8a6AzrABM2Q_WumFMBa7sp 4.hQ2wAP.8DI1aodpR468jpDvgFGKIBF08OPePg57BQDZ82OON4fqSoOEhb1 f6RNBrdQe448HC0I5viPjB0qFRgdmbV9xnMcXVvwJESVjKAiaMw.qxYz06eX tIW9sKYT4Zz7VpLLRoVTS.oRvYjH9xYR5DAOTzwHA57ntm15KNbsUp.f6D7g 4l7qk Received: from [50.58.7.243] by web111404.mail.gq1.yahoo.com via HTTP; Wed, 13 Jul 2011 08:26:22 PDT X-Mailer: YahooMailRC/572 YahooMailWebService/0.8.112.307740 References: <1310490517.84307.YahooMailRC@web111403.mail.gq1.yahoo.com> <96EBDFA8-7693-4A46-BA3A-6085A790B1DF@gmx.net> <1310498755.53153.YahooMailRC@web111406.mail.gq1.yahoo.com> <4E1CD50B.6090505@toshiba.co.jp> Message-ID: <1310570782.54303.YahooMailRC@web111404.mail.gq1.yahoo.com> Date: Wed, 13 Jul 2011 08:26:22 -0700 (PDT) From: Behcet Sarikaya To: Hannes Tschofenig , Yoshihiro Ohba In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: core@ietf.org Subject: Re: [core] Bootstrap in draft-ohba-core-eap-based-bootstrapping and draft-garcia-core-security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya 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 Jul 2011 15:26:30 -0000 > Hi Yoshi, > > it was a mistake to use the term "bootstrapping" in mobile IPv6 context as >well. > > There was no good reason to create a new term given the existence of already >well-established terms. > > > Time to change that. +1 Behcet > > Ciao > Hannes > > On Jul 13, 2011, at 2:13 AM, Yoshihiro Ohba wrote: > > > Hi Hannes, Bahcet, > > > > Please see my comments below. > > > > (2011/07/13 4:25), Behcet Sarikaya wrote: > >> Hi Hannes (Kelly and Rene who replied to me only), > >> > >> > >> Let me clarify. > >> > >> I checked the Wiki page, it is about what I talked, i.e. bootstrapping your >PC. > >> I am OK with it. > >> > >> In Core WG drafts, draft-ohba is about "bootstrapping" CoAP applications, > >> establishing a secure channel between the CoAP client and CoAP server. > >> > > > > Yes. > > > >> As such it assumes a secure IP communication which is what we cover in > >> draft-sarikaya. > >> > >> I think that establishing a secure channel between the CoAP client and CoAP > >> server should not be called bootstrapping. > > > > For example, RFC 4640 discuss "bootstrapping MIPv6", and in its abstract: > > > > "A mobile node needs at least the following information: a home > > address, a home agent address, and a security association with home > > agent to register with the home agent. The process of obtaining this > > information is called bootstrapping." > > > > This means that bootstrapping MIPv6 security is part of bootstrapping > > MIPv6. > > > > Following the same logic, I think bootstrapping CoAP security can be > > considered as part of bootstrapping CoAP application. > > > >> > >> OTOH, draft-garcia is totally chaotic about "bootstrapping". In Section 3 >it > >> talks about trust bootstrapping between nodes of > >> different vendors. Then it talks about bootstrapping phase/procedures. > >> Later on they mention the bootstrapping of security keys. > >> > >> Section 5.2 Bootstrapping of a Security Domain > >> In Section 5.2.2 it tries to give a definition to bootstrapping. > >> > >> My suggestions are: > >> > >> for draft-ohba: please do not use bootstrapping, otherwise your draft is >clear > >> enough. > > > > Since the term bootstrapping is already used for MIPv6 case, I think > > it can still use the term, but I agree that the draft should say > > bootstrapping CoAP security instead of bootstrapping CoAP application. > > > > Regards, > > Yoshihiro Ohba > > > > > > > >> > >> for draft-garcia: This draft talks about so many things. In most places, >what it > >> refers to as bootstrapping and the description match what is covered in the > >> original document which is draft-sarikaya. I suggest removing all those >sections > >> about bootstrapping because they are mostly repeating what we already had. >Stay > >> with whatever remains and see if it is worth to have such a document. > >> > >> Regards, > >> > >> Behcet > >> > >> > >> > >>> Hi Behcet, > >>> > >>> I agree with you that the term "bootstrapping" is not very helpful. > >>> > >>> There are three cases: > >>> > >>> a) Key Distribution and Key Derivation > >>> > >>> Here an existing keying material is used to derive other keying material >or to > >>> use securely distribute keying material. > >>> > >>> draft-ohba-core-eap-based-bootstrapping and > >>> > >>> b) Bootstrapping (in terms of operating systems procedures) > >>> > >>> See description in >http://en.wikipedia.org/wiki/Bootstrapping_%28computing%29 > >>> > >>> draft-garcia-core-security seems to refer to this aspect, I believe. > >>> > >>> c) Establishing initial keying material in a leap of faith style. > >>> > >>> Example: Bluetooth pairing protocol > >>> http://tools.ietf.org/html/draft-pritikin-ttimodel-01 also discusses >these > >>> aspects. > >>> > >>> Here the terms used are imprinting, pairing, enrollment, and introduction >are > >>> used to describe > >>> > >>> > >>> Ciao > >>> Hannes > >>> > >>> On Jul 12, 2011, at 8:08 PM, Behcet Sarikaya wrote: > >>> > >>>> Hi all, > >>>> It seems that the word bootstrapping has been used and overused in so >many > >> > >>>> drafts (including draft-ohba-core-eap-based-bootstrapping and > >>>> draft-garcia-core-security) and I suggest that we clarify this. > >>>> > >>>> Colin had a draft on > >>>> Initial Configuration of Resource-Constrained Devices > >>>> called draft-oflynn-6lowapp-bootstrapping submitted on Jan. 2010 in >which he > >>> > >>>> defined bootstrapping ashow to initially configure the network. > >>>> > >>>> Later on we continued this work on where Colin left > >>>> indraft-sarikaya-core-sbootstrapping. > >>>> > >>>> I think that the definition Colin gave to bootstrapping is the right >one. It > >>> > >>>> matches with the historical use of bootstrapping in computers: you >bootstrap > >>> > >>>> your computer to initially configure it by a physical action (pressing a > >>> button) > >>> > >>>> which loads a small record to the memory which when executed bootstraps > >>> (brings > >>> > >>>> the whole OS to the memory) the system. > >>>> > >>>> Regards, > >>>> > >>>> Behcet > >>>> _______________________________________________ > >>>> core mailing list > >>>> core@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/core > >>> > >>> > >> _______________________________________________ > >> core mailing list > >> core@ietf.org > >> https://www.ietf.org/mailman/listinfo/core > >> > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From jari.arkko@piuha.net Thu Jul 14 08:21:19 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 EBA4521F85EC; Thu, 14 Jul 2011 08:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.4 X-Spam-Level: X-Spam-Status: No, score=-102.4 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, 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 Qkrn2oqI0pr6; Thu, 14 Jul 2011 08:21:18 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 08F7E21F85EE; Thu, 14 Jul 2011 08:20:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 42FF92CE66; Thu, 14 Jul 2011 18:20:49 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1neNwZ0KN4O; Thu, 14 Jul 2011 18:20:48 +0300 (EEST) Received: from [IPv6:::1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id D9DF32CC4B; Thu, 14 Jul 2011 18:20:47 +0300 (EEST) Message-ID: <4E1F094D.4030602@piuha.net> Date: Thu, 14 Jul 2011 18:20:45 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Zhen Cao References: <4E11C2BE.8010605@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lwip@ietf.org, core Subject: Re: [core] [Lwip] draft about implementation techniques for ensuring COAP implementations can sleep 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: Thu, 14 Jul 2011 15:21:19 -0000 Zhen, Thanks for your comments and questions. Inline: > This is draft serves very much for a CoAP implementation guidance. I > have some questions and comments as below: > > Questions: What's kind of tiny devices are you playing with? I'm using MBEDs, ARM Cortex M3 CPUs. But the exact implementation platform is not very relevant, I'm playing with a prototype platform that I would not use for a real implementation because its too costly, power hungry, has too many features, extra interfaces, too big, etc. > You > mentioned 32-bit processor, how about the data and code size? For the > CoAP implementation, is it built on top of some tiny operating system > or stand alone? > The implementation is stand-alone, kind of. It contains everything necessary except certain things that I considered to be a part of an ideal hardware platform for building sensors. Other people asked about this as well, so version -01 tries to explain this in more detail: In this platform, our implementation is under 50 assembler instructions (see Note 1). The implementation consists of a Ethernet, IPv6, UDP, COAP, and XML protocol stack and the sensor application. The sensor application is based on values provided by an A/D converter; any analog value can be measured. Note 1: This contains everything necessary for using an A/D converter, constructing a complete Ethernet frame along with the higher level protocol fields, and asking the link layer to send it. It excludes platform specific initializations of the link layer, actual emitting of bits on the wire, and putting the device to sleep and waking it up. The complexity of these tasks varies highly between platforms and link layer technologies. For instance, one some platforms and with Ethernet, sending a frame out is merely a question of setting some registers and asking the hardware to send a packet. Of course, with different link layers and platforms an implementation might be have to be arbitrarily complex to support the intricacies of the link layer in question. On the prototype platform that I'm using the implementation is big, because it links all kinds of debug libraries and other extra things in. And there's a separate OS that initializes the system and manages things like the USB and flash interfaces. But these are unnecessary if the implementation was running on a production sensor. Lets assume (1) that the CPU needs no particular initialization, it just starts executing the program upon wake-up, (2) it has lower layer hardware that can be told to transmit an otherwise complete frame from the memory in a handful of instructions, and (3) putting the device back to sleep is reasonably easy, in the order of few instructions. Then we are really talking about an implementation that consists of 50 instructions + the few instructions needed for those three tasks + data bytes needed for the memory image of the packet, and nothing else. Of course, there are wildly different platforms. I can also imagine a sensor that needs a 200.000 line baseband software to manage a radio-based link layer. > Comments: > In Section 4.2, there is a strong message that the CoAP server model > is NOT RECOMMENDED. It should be discussed though. In most cases of > the m2m applications and services, it usually is the network side that > initiates the communication and gets some information from the sensor, > and I think that's why CoAP server model seems to be the default model > in draft-ietf-core-coap. Yes, and to be clear Section 4.2 is our recommendation, not the CORE working group's recommendation. And we did formulate our recommendation in a provocative manner on purpose, to generate some discussion. The draft states the reasons for our recommendation, but of course a lot depends on what applications one is looking at, what one considers as the most important optimization criteria, and so on. So the recommendation is just our claim at this stage. That being said, the CORE working group's model is not cast in stone (or an RFC) yet either. Part of the reason that we're bringing these things up is that as we have some implementation experience that might help adjust the CORE specifications. In general, to me it appears that CORE has spent more time focusing on message formats than communication models and messaging sequences. Personally, I think message formats are less important than the higher level decisions about the communication model. > Yes, having the sensor proactively post > information to the server slide is one way to circumvent the sleeping > node issue. What has been lost here is that the sensor needs to send > the message one by one which is also energy consuming. Not sure what you mean by "one by one", can you clarify? In any case, there are many different communication models. One approach might be to put more intelligence on the sensor so that it reports only significant changes, and then you might be able to skip some communications altogether. I should also say that what communication model is best also depends highly on how much you think listening consumes power versus sending. > In some > implementations, as discussed in section 4.1, a well-known url can be > used, but in many others, the server model is still inevitably used, > where "sleeping compatible protocols" (the term of Margret's position > paper in last IAB IOT Workshop) or always online mechanisms are > expected. > What we describe in the draft is one extreme approach to sleep compatible protocols. We've taken our approach so far that we're starting to pay a price, for instance in terms of difficulties for ensuring reliable transmission. That being said, I don't think an always-on approach is particularly sleep compatible. Maybe there are ways to make it more sleep compatible, but again, we should look at what those ways are. Jari From jari.arkko@piuha.net Fri Jul 15 07:02:34 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 5375321F8767; Fri, 15 Jul 2011 07:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.395 X-Spam-Level: X-Spam-Status: No, score=-102.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, 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 Xv954COrPIaP; Fri, 15 Jul 2011 07:02:34 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id C025121F8766; Fri, 15 Jul 2011 07:02:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 0392A2CEFF; Fri, 15 Jul 2011 17:02:33 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVFpHoBU8rEI; Fri, 15 Jul 2011 17:02:32 +0300 (EEST) Received: from [IPv6:::1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 1C17D2CC4B; Fri, 15 Jul 2011 17:02:32 +0300 (EEST) Message-ID: <4E204877.8040108@piuha.net> Date: Fri, 15 Jul 2011 17:02:31 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: core , lwip@ietf.org, roll@ietf.org, 6lowpan@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [core] Internet of Things Hacking Meet 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, 15 Jul 2011 14:02:34 -0000 We would like to invite interested implementors for an informal session to interop test, play & demo, further develop your Things and for a general chat with other implementors. This is not a working group session or place to run presentations. If you happen to be around at the time and have some gear to bring or software on your laptop, do join us and maybe something interesting will come out of it. The event is intended for people implementing something around the Internet of Things space. For instance, I am personally interested in home networking and automation and will bring some COAP, IPv6, and 1-wire stuff, but other people are probably interested in other areas and protocols as well. We understand that this is a late announcement, and everyone has lots of other things on their agenda as well. For that purpose Hannes and I have reserved two nights to make it a bit more likely that people can drop by. The times are Saturday, July 23rd, 5PM to 8PM and Sunday, July 24th, 7PM to 9PM. Exact location is to be announced later, but it is in the IETF meeting hotel in Quebec City. Jari Arkko Hannes Tschofenig From hannes.tschofenig@gmx.net Sun Jul 17 06:31:00 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 2C40621F869C for ; Sun, 17 Jul 2011 06:31:00 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGGTux0+9xB2 for ; Sun, 17 Jul 2011 06:30:59 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id D5F3521F8698 for ; Sun, 17 Jul 2011 06:30:58 -0700 (PDT) Received: (qmail invoked by alias); 17 Jul 2011 13:30:57 -0000 Received: from unknown (EHLO [172.16.1.103]) [12.176.29.2] by mail.gmx.net (mp066) with SMTP; 17 Jul 2011 15:30:57 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX194fehH5ON4YUmtlLSNBaNIbQU6ampgQVC0rjijx4 zi41yGLeGOY5EN Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Sun, 17 Jul 2011 16:30:54 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <56345F95-BED6-40F9-924D-CE5105B50ACE@gmx.net> References: <1310490517.84307.YahooMailRC@web111403.mail.gq1.yahoo.com> <96EBDFA8-7693-4A46-BA3A-6085A790B1DF@gmx.net> <1310498755.53153.YahooMailRC@web111406.mail.gq1.yahoo.com> <4E1CD50B.6090505@toshiba.co.jp> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: core@ietf.org Subject: Re: [core] Bootstrap in draft-ohba-core-eap-based-bootstrapping and draft-garcia-core-security 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: Sun, 17 Jul 2011 13:31:00 -0000 Yoshi, I would also like to add that my comment regarding Bahcet's = suggestion for a terminology change does not lower the value of your = contribution in any way.=20 In fact, I find your document a very interesting discussion contribution = regarding the envisioned smart object security architecture.=20 Ciao Hannes On Jul 13, 2011, at 11:33 AM, Hannes Tschofenig wrote: > Hi Yoshi,=20 >=20 > it was a mistake to use the term "bootstrapping" in mobile IPv6 = context as well.=20 > There was no good reason to create a new term given the existence of = already well-established terms.=20 >=20 > Time to change that. >=20 > Ciao > Hannes >=20 > On Jul 13, 2011, at 2:13 AM, Yoshihiro Ohba wrote: >=20 >> Hi Hannes, Bahcet, >>=20 >> Please see my comments below. >>=20 >> (2011/07/13 4:25), Behcet Sarikaya wrote: >>> Hi Hannes (Kelly and Rene who replied to me only), >>>=20 >>>=20 >>> Let me clarify. >>>=20 >>> I checked the Wiki page, it is about what I talked, i.e. = bootstrapping your PC. >>> I am OK with it. >>>=20 >>> In Core WG drafts, draft-ohba is about "bootstrapping" CoAP = applications, >>> establishing a secure channel between the CoAP client and CoAP = server. >>>=20 >>=20 >> Yes. >>=20 >>> As such it assumes a secure IP communication which is what we cover = in >>> draft-sarikaya. >>>=20 >>> I think that establishing a secure channel between the CoAP client = and CoAP >>> server should not be called bootstrapping. >>=20 >> For example, RFC 4640 discuss "bootstrapping MIPv6", and in its = abstract: >>=20 >> "A mobile node needs at least the following information: a home >> address, a home agent address, and a security association with home >> agent to register with the home agent. The process of obtaining this >> information is called bootstrapping." >>=20 >> This means that bootstrapping MIPv6 security is part of bootstrapping >> MIPv6. >>=20 >> Following the same logic, I think bootstrapping CoAP security can be >> considered as part of bootstrapping CoAP application. >>=20 >>>=20 >>> OTOH, draft-garcia is totally chaotic about "bootstrapping". In = Section 3 it >>> talks about trust bootstrapping between nodes of >>> different vendors. Then it talks about bootstrapping = phase/procedures. >>> Later on they mention the bootstrapping of security keys. >>>=20 >>> Section 5.2 Bootstrapping of a Security Domain >>> In Section 5.2.2 it tries to give a definition to bootstrapping. >>>=20 >>> My suggestions are: >>>=20 >>> for draft-ohba: please do not use bootstrapping, otherwise your = draft is clear >>> enough. >>=20 >> Since the term bootstrapping is already used for MIPv6 case, I think >> it can still use the term, but I agree that the draft should say >> bootstrapping CoAP security instead of bootstrapping CoAP = application. >>=20 >> Regards, >> Yoshihiro Ohba >>=20 >>=20 >>=20 >>>=20 >>> for draft-garcia: This draft talks about so many things. In most = places, what it >>> refers to as bootstrapping and the description match what is covered = in the >>> original document which is draft-sarikaya. I suggest removing all = those sections >>> about bootstrapping because they are mostly repeating what we = already had. Stay >>> with whatever remains and see if it is worth to have such a = document. >>>=20 >>> Regards, >>>=20 >>> Behcet >>>=20 >>>=20 >>>=20 >>>> Hi Behcet, >>>>=20 >>>> I agree with you that the term "bootstrapping" is not very = helpful. >>>>=20 >>>> There are three cases: >>>>=20 >>>> a) Key Distribution and Key Derivation >>>>=20 >>>> Here an existing keying material is used to derive other keying = material or to >>>> use securely distribute keying material. >>>>=20 >>>> draft-ohba-core-eap-based-bootstrapping and >>>>=20 >>>> b) Bootstrapping (in terms of operating systems procedures) >>>>=20 >>>> See description in = http://en.wikipedia.org/wiki/Bootstrapping_%28computing%29 >>>>=20 >>>> draft-garcia-core-security seems to refer to this aspect, I = believe. >>>>=20 >>>> c) Establishing initial keying material in a leap of faith style. >>>>=20 >>>> Example: Bluetooth pairing protocol >>>> http://tools.ietf.org/html/draft-pritikin-ttimodel-01 also = discusses these >>>> aspects. >>>>=20 >>>> Here the terms used are imprinting, pairing, enrollment, and = introduction are >>>> used to describe >>>>=20 >>>>=20 >>>> Ciao >>>> Hannes >>>>=20 >>>> On Jul 12, 2011, at 8:08 PM, Behcet Sarikaya wrote: >>>>=20 >>>>> Hi all, >>>>> It seems that the word bootstrapping has been used and overused = in so many >>>=20 >>>>> drafts (including draft-ohba-core-eap-based-bootstrapping and >>>>> draft-garcia-core-security) and I suggest that we clarify this. >>>>>=20 >>>>> Colin had a draft on >>>>> Initial Configuration of Resource-Constrained Devices >>>>> called draft-oflynn-6lowapp-bootstrapping submitted on Jan. 2010 = in which he >>>>=20 >>>>> defined bootstrapping ashow to initially configure the = network. >>>>>=20 >>>>> Later on we continued this work on where Colin left >>>>> indraft-sarikaya-core-sbootstrapping. >>>>>=20 >>>>> I think that the definition Colin gave to bootstrapping is the = right one. It >>>>=20 >>>>> matches with the historical use of bootstrapping in computers: you = bootstrap >>>>=20 >>>>> your computer to initially configure it by a physical action = (pressing a >>>> button) >>>>=20 >>>>> which loads a small record to the memory which when executed = bootstraps >>>> (brings >>>>=20 >>>>> the whole OS to the memory) the system. >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Behcet >>>>> _______________________________________________ >>>>> core mailing list >>>>> core@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/core >>>>=20 >>>>=20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>>=20 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 From zehn.cao@gmail.com Sun Jul 17 23:17:54 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 9CA2A21F8B3D; Sun, 17 Jul 2011 23:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, 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 AvF-t2MkP3pE; Sun, 17 Jul 2011 23:17:54 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D3D2221F8B37; Sun, 17 Jul 2011 23:17:50 -0700 (PDT) Received: by iwn39 with SMTP id 39so2996770iwn.31 for ; Sun, 17 Jul 2011 23:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XatyWLfmCQzV/YJbYNZR06V9PPBVAJdziQbirSTXGv8=; b=jJrsYYe97/1C6JhZikvIZPuVL1Qy25diqOPEoRdypfV//fZt0PgzfU8d4RCgqIQPjs Eunh8AI/ZOLanQ7CqJ9a5dq/jw7qIzkVn33LZjJZH2R2IDncXqWGJbTXxc/s4srRKrix HXPXmLrjdzxMh4dAkuQbL4nN3HyJJEDCPPv10= MIME-Version: 1.0 Received: by 10.42.149.67 with SMTP id u3mr7528953icv.124.1310969870513; Sun, 17 Jul 2011 23:17:50 -0700 (PDT) Received: by 10.42.173.70 with HTTP; Sun, 17 Jul 2011 23:17:50 -0700 (PDT) In-Reply-To: <4E1F094D.4030602@piuha.net> References: <4E11C2BE.8010605@piuha.net> <4E1F094D.4030602@piuha.net> Date: Mon, 18 Jul 2011 14:17:50 +0800 Message-ID: From: Zhen Cao To: Jari Arkko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: lwip@ietf.org, core Subject: Re: [core] [Lwip] draft about implementation techniques for ensuring COAP implementations can sleep 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, 18 Jul 2011 06:17:55 -0000 Hi Jari, Thank you for the response. Please see inline. On Thu, Jul 14, 2011 at 11:20 PM, Jari Arkko wrote: > > Of course, there are wildly different platforms. I can also imagine a sen= sor > that needs a 200.000 line baseband software to manage a radio-based link > layer. Interesting to know your platform. Thank you. > >> Comments: >> In Section 4.2, there is a strong message that the CoAP server model >> is NOT RECOMMENDED. =A0It should be discussed though. =A0In most cases o= f >> the m2m applications and services, it usually is the network side that >> initiates the communication and gets some information from the sensor, >> and I think that's why CoAP server model seems to be the default model >> in draft-ietf-core-coap. > > Yes, and to be clear Section 4.2 is our recommendation, not the CORE work= ing > group's recommendation. And we did formulate our recommendation in a > provocative manner on purpose, to generate some discussion. The draft sta= tes > the reasons for our recommendation, but of course a lot depends on what > applications one is looking at, what one considers as the most important > optimization criteria, and so on. So the recommendation is just our claim= at > this stage. I see. > > That being said, the CORE working group's model is not cast in stone (or = an > RFC) yet either. Part of the reason that we're bringing these things up i= s > that as we have some implementation experience that might help adjust the > CORE specifications. In general, to me it appears that CORE has spent mor= e > time focusing on message formats than communication models and messaging > sequences. Personally, I think message formats are less important than th= e > higher level decisions about the communication model. Yes, communication model is very important and many times should be tailored to each implementation model. So I believe this should be in the scope of LWIG. Let's discuss it. > >> Yes, having the sensor proactively post >> information to the server slide is one way to circumvent the sleeping >> node issue. =A0 What has been lost here is that the sensor needs to send >> the message one by one which is also energy consuming. > > Not sure what you mean by "one by one", can you clarify? Sorry for the ambiguity. Assume that hundreds of web users are in need of the sensor information, so the sensor needs to send to them one by one, even in the observe model. I noticed that in your system, the sensor uses a well-know URL, so that the information is only sent once. That's a clever way, and releases the need of some component of coap, e.g., link-format. > What we describe in the draft is one extreme approach to sleep compatible > protocols. We've taken our approach so far that we're starting to pay a > price, for instance in terms of difficulties for ensuring reliable > transmission. That being said, I don't think an always-on approach is > particularly sleep compatible. Maybe there are ways to make it more sleep > compatible, but again, we should look at what those ways are. Interesting way forward. Anyway, we will try to take some experience in our system. Thank you. --=20 Best regards, Zhen From yoshihiro.ohba@toshiba.co.jp Mon Jul 18 11:53:11 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 3F19921F8B9B for ; Mon, 18 Jul 2011 11:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 atTZ6zSodogN for ; Mon, 18 Jul 2011 11:53:10 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 1E48E21F8B89 for ; Mon, 18 Jul 2011 11:53:09 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id p6IIr4jp007053; Tue, 19 Jul 2011 03:53:04 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id p6IIr4vn028163; Tue, 19 Jul 2011 03:53:04 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id DAA28162; Tue, 19 Jul 2011 03:53:04 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id p6IIr4tV000484; Tue, 19 Jul 2011 03:53:04 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id p6IIr4a5026031; Tue, 19 Jul 2011 03:53:04 +0900 (JST) Received: from [133.199.16.123] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0LOJ003OSLSF2880@mail.po.toshiba.co.jp>; Tue, 19 Jul 2011 03:53:04 +0900 (JST) Date: Tue, 19 Jul 2011 03:52:59 +0900 From: Yoshihiro Ohba In-reply-to: <56345F95-BED6-40F9-924D-CE5105B50ACE@gmx.net> To: Hannes Tschofenig Message-id: <4E24810B.40304@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <1310490517.84307.YahooMailRC@web111403.mail.gq1.yahoo.com> <96EBDFA8-7693-4A46-BA3A-6085A790B1DF@gmx.net> <1310498755.53153.YahooMailRC@web111406.mail.gq1.yahoo.com> <4E1CD50B.6090505@toshiba.co.jp> <56345F95-BED6-40F9-924D-CE5105B50ACE@gmx.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 Cc: core@ietf.org Subject: Re: [core] Bootstrap in draft-ohba-core-eap-based-bootstrapping and draft-garcia-core-security 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, 18 Jul 2011 18:53:11 -0000 Thanks, Hannes. I agree to change the terminology. Chairs: I request a slot to discuss my contribution in IETF81. Regards, Yoshihiro Ohba (2011/07/17 22:30), Hannes Tschofenig wrote: > Yoshi, I would also like to add that my comment regarding Bahcet's suggestion for a terminology change does not lower the value of your contribution in any way. > In fact, I find your document a very interesting discussion contribution regarding the envisioned smart object security architecture. > > Ciao > Hannes > > On Jul 13, 2011, at 11:33 AM, Hannes Tschofenig wrote: > >> Hi Yoshi, >> >> it was a mistake to use the term "bootstrapping" in mobile IPv6 context as well. >> There was no good reason to create a new term given the existence of already well-established terms. >> >> Time to change that. >> >> Ciao >> Hannes >> >> On Jul 13, 2011, at 2:13 AM, Yoshihiro Ohba wrote: >> >>> Hi Hannes, Bahcet, >>> >>> Please see my comments below. >>> >>> (2011/07/13 4:25), Behcet Sarikaya wrote: >>>> Hi Hannes (Kelly and Rene who replied to me only), >>>> >>>> >>>> Let me clarify. >>>> >>>> I checked the Wiki page, it is about what I talked, i.e. bootstrapping your PC. >>>> I am OK with it. >>>> >>>> In Core WG drafts, draft-ohba is about "bootstrapping" CoAP applications, >>>> establishing a secure channel between the CoAP client and CoAP server. >>>> >>> >>> Yes. >>> >>>> As such it assumes a secure IP communication which is what we cover in >>>> draft-sarikaya. >>>> >>>> I think that establishing a secure channel between the CoAP client and CoAP >>>> server should not be called bootstrapping. >>> >>> For example, RFC 4640 discuss "bootstrapping MIPv6", and in its abstract: >>> >>> "A mobile node needs at least the following information: a home >>> address, a home agent address, and a security association with home >>> agent to register with the home agent. The process of obtaining this >>> information is called bootstrapping." >>> >>> This means that bootstrapping MIPv6 security is part of bootstrapping >>> MIPv6. >>> >>> Following the same logic, I think bootstrapping CoAP security can be >>> considered as part of bootstrapping CoAP application. >>> >>>> >>>> OTOH, draft-garcia is totally chaotic about "bootstrapping". In Section 3 it >>>> talks about trust bootstrapping between nodes of >>>> different vendors. Then it talks about bootstrapping phase/procedures. >>>> Later on they mention the bootstrapping of security keys. >>>> >>>> Section 5.2 Bootstrapping of a Security Domain >>>> In Section 5.2.2 it tries to give a definition to bootstrapping. >>>> >>>> My suggestions are: >>>> >>>> for draft-ohba: please do not use bootstrapping, otherwise your draft is clear >>>> enough. >>> >>> Since the term bootstrapping is already used for MIPv6 case, I think >>> it can still use the term, but I agree that the draft should say >>> bootstrapping CoAP security instead of bootstrapping CoAP application. >>> >>> Regards, >>> Yoshihiro Ohba >>> >>> >>> >>>> >>>> for draft-garcia: This draft talks about so many things. In most places, what it >>>> refers to as bootstrapping and the description match what is covered in the >>>> original document which is draft-sarikaya. I suggest removing all those sections >>>> about bootstrapping because they are mostly repeating what we already had. Stay >>>> with whatever remains and see if it is worth to have such a document. >>>> >>>> Regards, >>>> >>>> Behcet >>>> >>>> >>>> >>>>> Hi Behcet, >>>>> >>>>> I agree with you that the term "bootstrapping" is not very helpful. >>>>> >>>>> There are three cases: >>>>> >>>>> a) Key Distribution and Key Derivation >>>>> >>>>> Here an existing keying material is used to derive other keying material or to >>>>> use securely distribute keying material. >>>>> >>>>> draft-ohba-core-eap-based-bootstrapping and >>>>> >>>>> b) Bootstrapping (in terms of operating systems procedures) >>>>> >>>>> See description in http://en.wikipedia.org/wiki/Bootstrapping_%28computing%29 >>>>> >>>>> draft-garcia-core-security seems to refer to this aspect, I believe. >>>>> >>>>> c) Establishing initial keying material in a leap of faith style. >>>>> >>>>> Example: Bluetooth pairing protocol >>>>> http://tools.ietf.org/html/draft-pritikin-ttimodel-01 also discusses these >>>>> aspects. >>>>> >>>>> Here the terms used are imprinting, pairing, enrollment, and introduction are >>>>> used to describe >>>>> >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> On Jul 12, 2011, at 8:08 PM, Behcet Sarikaya wrote: >>>>> >>>>>> Hi all, >>>>>> It seems that the word bootstrapping has been used and overused in so many >>>> >>>>>> drafts (including draft-ohba-core-eap-based-bootstrapping and >>>>>> draft-garcia-core-security) and I suggest that we clarify this. >>>>>> >>>>>> Colin had a draft on >>>>>> Initial Configuration of Resource-Constrained Devices >>>>>> called draft-oflynn-6lowapp-bootstrapping submitted on Jan. 2010 in which he >>>>> >>>>>> defined bootstrapping ashow to initially configure the network. >>>>>> >>>>>> Later on we continued this work on where Colin left >>>>>> indraft-sarikaya-core-sbootstrapping. >>>>>> >>>>>> I think that the definition Colin gave to bootstrapping is the right one. It >>>>> >>>>>> matches with the historical use of bootstrapping in computers: you bootstrap >>>>> >>>>>> your computer to initially configure it by a physical action (pressing a >>>>> button) >>>>> >>>>>> which loads a small record to the memory which when executed bootstraps >>>>> (brings >>>>> >>>>>> the whole OS to the memory) the system. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Behcet >>>>>> _______________________________________________ >>>>>> core mailing list >>>>>> core@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/core >>>>> >>>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>> >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >> > > From kovatsch@inf.ethz.ch Mon Jul 18 12:27:15 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 30CB5228014 for ; Mon, 18 Jul 2011 12:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 DeFukDGSBZYw for ; Mon, 18 Jul 2011 12:27:10 -0700 (PDT) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id D35A422800E for ; Mon, 18 Jul 2011 12:27:09 -0700 (PDT) Received: from CAS20.d.ethz.ch (172.31.51.110) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.1.289.1; Mon, 18 Jul 2011 21:27:07 +0200 Received: from MBX10.d.ethz.ch ([169.254.1.74]) by CAS20.d.ethz.ch ([fe80::2cd8:4907:7776:c56d%11]) with mapi id 14.01.0289.001; Mon, 18 Jul 2011 21:27:08 +0200 From: "Kovatsch Matthias" To: "Dijk, Esko" , Guido Moritz , 'Zach Shelby' , 'Carsten Bormann' Thread-Topic: [core] #163: Content-negotiation Thread-Index: AQHMOyyb55r8LvEpvECHu03CUjaKZJTfCguAgAAPkICAAXOLgIAAFxwAgAAKBoCAABp8AIAEoFKAgA0dX8A= Date: Mon, 18 Jul 2011 19:27:06 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B50D3217F0@MBX10.d.ethz.ch> References: <057.213b5d9d1d62cee7319a2d6f5e3e5d21@trac.tools.ietf.org> <009701cc3b27$b7555d10$26001730$@uni-rostock.de> <004701cc3bd8$bdeecba0$39cc62e0$@uni-rostock.de> <609ECA3B-26F5-4D70-B1F5-4C63EE86E775@sensinode.com> <00ec01cc3cb0$52ef31e0$f8cd95a0$@uni-rostock.de> In-Reply-To: Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.253] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "core@ietf.org" Subject: Re: [core] #163: Content-negotiation 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, 18 Jul 2011 19:27:15 -0000 Hi I agree that we need an (elective) Accept option to choose between differen= t representations. But why should CoAP allow multiple occurrences of that option? Here, I totally agree with Guido: Why should a client prefer one over anoth= er? It just complicates the implementation on both sides. The representations to choose from should be announced in the Link Format. = If this is not done properly at the server-side, the client can still fall = back to a trial-and-error behavior to check of one of his supported formats= is available (there won't be that many..). Best regards Matthias > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of > Dijk, Esko > Sent: Sonntag, 10. Juli 2011 14:54 > To: Guido Moritz; 'Zach Shelby'; 'Carsten Bormann' > Cc: core@ietf.org > Subject: Re: [core] #163: Content-negotiation >=20 > I would agree with Zach that having one Elective Accept-option seems righ= t > for the described use case (i.e. SDO/ZigBee/ETSI multiple content > formats). >=20 > [I'm probably repeating Zach's points here:] > 1- Elective enables minimal implementations to be simpler (ignore "Accept= " > entirely; return fixed content type) > 2- a CoAP client according to the use case knows what a server offers, an= d > whether it supports Accept, since it's specified in a standard and/or > discovered via Link Format. So the client would request from these format= s > and almost always the server is able to serve one of these. >=20 > Suppose the server in case 2 still returns something the client doesn't > understand, the client may interpret this as a form of "server error > 4.15". Note, I think that even with an Elective Accept option a server ca= n > still legally return a 4.15 - this may even be agreed so by the people of > the related standard. > Finally if RAM or resources are the problem the server should respond 5.0= 0 > or 5.03, isn't it? >=20 >=20 > Esko >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of > Guido Moritz > Sent: Thursday 7 July 2011 16:15 > To: 'Zach Shelby'; 'Carsten Bormann' > Cc: core@ietf.org > Subject: Re: [core] #163: Content-negotiation >=20 > I would still love to have more detailed information for the client how > the interpret a not wanted response. Otherwise it would be hard for a > client to determine which the real capabilities of the server are and > which just have occurred, e.g., due to implementation or situation > specific side effect (e.g. RAM overload, temporary low throughput...). >=20 > Something like: "If the server is temporarily not able to provide a media > type requested in the Accept option, the server SHOULD respond with a > different media type. If the server is entirely not capable of providing > the requested media type, the server SHOULD respond with a 4.06." >=20 > This is already possible with the existing text, but I guess it would be > helpful to have a more precise definition. I am not sure which side > effects such a behavior might have. >=20 > And I don't want to overstrain this discussion :) >=20 > Guido >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Zach Shelby [mailto:zach@sensinode.com] > > Gesendet: Donnerstag, 7. Juli 2011 14:41 > > An: Carsten Bormann > > Cc: Guido Moritz; core@ietf.org > > Betreff: Re: [core] #163: Content-negotiation > > > > On Jul 7, 2011, at 3:04 PM, Carsten Bormann wrote: > > > > > -- I need this (one out of a set of) content types, and I'm not > interested in > > anything else. > > > If the option is Elective, the client still cannot rely on > > > getting > just that. > > So for this semantics, the option should be Critical. > > > > > > -- Please give my this (one out of a set of) content type, but I'd > > > be > happy with > > anything else. > > > If the option is Critical, the request might be needlessly > rejected. > So for > > this semantics, the option should be Elective. > > > > > > Which of the ones do we need? Since I consider the cost of getting > > > an > > unwanted answer (as opposed to an error answer) negligible*), there is > little > > value to the first semantics. There is even less value to an > implementation that > > would honor a Critical Accept and choose to ignore an Elective one > > (why on earth would one do that?). That's why I was happy with only > > having the > second. > > Maybe it would help to add some implementer advice that, to maximize > > interoperability, the Accept *should* be honored if the implementation > > can > do > > that (well, whatever this advice will be, it will be wishy-washy, so > > it > can't be a > > SHOULD). > > > > > > I came to the same conclusion. > > > > Now I took a shot to improve the Accept text and made an attempt to > include > > SHOULD language as you suggest. Here is the current Accept section > > text > from > > the SVN version of CoAP. Does this need improvement anyone? > > > > 5.10.5. Accept > > > > The CoAP Accept option indicates when included one or more times in = a > > request, carry one or more media types, each of which is an > > acceptable media type for the client, in the order of preference. > > The representation format is given as a numeric media type identifie= r > > that is defined in the CoAP Media Type registry (Section 11.3). If > > no Accept options are given, the client does not express a preferenc= e > > (thus no default value is assumed). The client prefers the > > representation returned by the server to be in one of the media type= s > > indicated. The server SHOULD return one of the preferred media type= s > > if available. As a server might not support the Accept option (and > > thus would ignore it as it is elective), or a server might not have = a > > preferred media type available, the client needs to be prepared to > > receive a representation in a different media type. The client can > > simply discard a representation it can not make use of. > > > > This option is "elective". It MAY occur more than once. > > > > -- > > Zach Shelby, Chief Nerd, Sensinode Ltd. > > http://www.sensinode.com > > http://zachshelby.org - My blog "On the Internet of Things" > > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > > Mobile: +358 40 7796297 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby > notified that any use, forwarding, dissemination, or reproduction of this > message is strictly prohibited and may be unlawful. If you are not the > intended recipient, please contact the sender by return e-mail and destro= y > all copies of the original message. >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From hartketzi@googlemail.com Wed Jul 20 10:53:57 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 CB0C021F8AF5 for ; Wed, 20 Jul 2011 10:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 M7TN2MMRH1fV for ; Wed, 20 Jul 2011 10:53:54 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id B47C221F8AF4 for ; Wed, 20 Jul 2011 10:53:53 -0700 (PDT) Received: by fxe4 with SMTP id 4so2502874fxe.27 for ; Wed, 20 Jul 2011 10:53:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=sakeQ7pYjSUz3G1rEG45d22fesJw+X+fdoadAes6TfE=; b=Dmg2pX3ItkqmWgpniWnVaKKBsRxMZfk63k+igPCtvl301rQ0ngklp1qX8la4BSKf6b 5yH8RuBWlWi/BnUK50KtrvCbRgyjrpxTjPcqaId2bgUhisTChZiXgZHJUvQfSUx4X19v h7+MatQFelZzo4JPyI/zfoCheW28ulwk1UTJE= MIME-Version: 1.0 Received: by 10.223.17.6 with SMTP id q6mr3052598faa.96.1311184432675; Wed, 20 Jul 2011 10:53:52 -0700 (PDT) Sender: hartketzi@googlemail.com Received: by 10.223.87.15 with HTTP; Wed, 20 Jul 2011 10:53:52 -0700 (PDT) Date: Wed, 20 Jul 2011 19:53:52 +0200 X-Google-Sender-Auth: iNjaq5645FymS-Mih149YVyp3J4 Message-ID: From: Klaus Hartke To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] Options for Stale Content 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 Jul 2011 17:57:45 -0000 I'd like to propose the addition of a Stale-If-Error and Stale-While-Revalidate Option (both elective) to draft-ietf-core-coap with the same semantics as the "stale-if-error" and "stale-while-revalidate" Cache-Control extensions defined in . It would be great if someone could briefly present this in Quebec on my behalf (5 minutes). Klaus From fluffy@cisco.com Thu Jul 21 07:15:48 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 CEF9021F855E for ; Thu, 21 Jul 2011 07:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.753 X-Spam-Level: X-Spam-Status: No, score=-103.753 tagged_above=-999 required=5 tests=[AWL=-1.154, BAYES_00=-2.599, 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 wkeubIm3i7lR for ; Thu, 21 Jul 2011 07:15:48 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id EEF9421F87C3 for ; Thu, 21 Jul 2011 07:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1097; q=dns/txt; s=iport; t=1311257748; x=1312467348; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=dekWr1LumgVz1gM4P66wgHIb+w7/VP+W4wrMXl0YDZs=; b=ik64hkxSDoU6MKTLa32zHal8DRi5W1Y61Q61FGXnRBBXk3fsCj6cQIKp vQ60CkVAiZDg8XVsndvtEmt9mmetFehfnAYLd282Ca/k0Mh+iK8DMtYfP ypawFWWWleZVjuDlNJ4L5KCP5gRfgwjZbQeGGthWRN8mRGQOXeVlu3UPJ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGgzKE6rRDoI/2dsb2JhbABUp2p3pVuBI54nhV9fBIdVixmQfQ X-IronPort-AV: E=Sophos;i="4.67,240,1309737600"; d="scan'208";a="5116483" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-4.cisco.com with ESMTP; 21 Jul 2011 14:15:45 +0000 Received: from sjc-vpn4-1446.cisco.com (sjc-vpn4-1446.cisco.com [10.21.85.165]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6LEFjLO010296 for ; Thu, 21 Jul 2011 14:15:45 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Jul 2011 07:15:44 -0700 Message-Id: To: core WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] Draft agenda 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: Thu, 21 Jul 2011 14:15:48 -0000 Sorry but I forgot to send this to the list when I posted it to the web = site. The draft agenda is below, let us know if it needs changes. Draft Agenda - Version 1 Session 1 Admin (10 min) Link Format draft-ietf-core-link-format (Shelby 5 minutes) CoAP draft-ietf-core-coap (Shelby 25 minutes) Block draft-ietf-core-block (Shelby 15 minutes) Observe draft-ietf-core-observe (Hartke 15 minutes) Proxy Implementation Advice draft-castellani-core-http-coap-mapping (Castellani 15 minutes) = =20 Session 2 Admin (5 minutes) Group Communications draft-rahman-core-groupcomm (Rahman 10 minutes) Size Option draft-li-core-coap-size-option (Li 10 minutes) Request Timeout Option draft-li-core-coap-request-timeout-option (Li 10 minutes) Building Automation Usage draft-vanderstok-core-bc (Van der Stok 10 minutes)=20 SoAP over CoAP draft-moritz-core-soap-over-coap (Moritz 10 minutes) From yoshihiro.ohba@toshiba.co.jp Thu Jul 21 07:42:12 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 D582E21F86D9 for ; Thu, 21 Jul 2011 07:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 mIgvbPL45kQF for ; Thu, 21 Jul 2011 07:42:12 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 0545021F86AC for ; Thu, 21 Jul 2011 07:42:11 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id p6LEgBrt012296 for ; Thu, 21 Jul 2011 23:42:11 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id p6LEgAAY012919 for core@ietf.org; Thu, 21 Jul 2011 23:42:10 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id ZAA12918; Thu, 21 Jul 2011 23:42:10 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id p6LEgADp005207 for ; Thu, 21 Jul 2011 23:42:10 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id p6LEgATh017664; Thu, 21 Jul 2011 23:42:10 +0900 (JST) Received: from [133.199.18.251] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0LOO00KY3U69DVE0@mail.po.toshiba.co.jp> for core@ietf.org; Thu, 21 Jul 2011 23:42:10 +0900 (JST) Date: Thu, 21 Jul 2011 23:41:59 +0900 From: Yoshihiro Ohba In-reply-to: To: core@ietf.org Message-id: <4E283AB7.90004@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 Subject: Re: [core] Draft agenda 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: Thu, 21 Jul 2011 14:42:12 -0000 Is it possible to add a slot to discuss my draft: draft-ohba-core-eap-based-bootstrapping? Best Regards, Yoshihiro Ohba (2011/07/21 23:15), Cullen Jennings wrote: > > Sorry but I forgot to send this to the list when I posted it to the web site. The draft agenda is below, let us know if it needs changes. > > > > Draft Agenda - Version 1 > > Session 1 > > Admin (10 min) > > Link Format > draft-ietf-core-link-format (Shelby 5 minutes) > > CoAP > draft-ietf-core-coap (Shelby 25 minutes) > > Block > draft-ietf-core-block (Shelby 15 minutes) > > Observe > draft-ietf-core-observe (Hartke 15 minutes) > > Proxy Implementation Advice > draft-castellani-core-http-coap-mapping (Castellani 15 minutes) > > > Session 2 > > Admin (5 minutes) > > Group Communications > draft-rahman-core-groupcomm (Rahman 10 minutes) > > Size Option > draft-li-core-coap-size-option (Li 10 minutes) > > Request Timeout Option > draft-li-core-coap-request-timeout-option (Li 10 minutes) > > Building Automation Usage > draft-vanderstok-core-bc (Van der Stok 10 minutes) > > SoAP over CoAP > draft-moritz-core-soap-over-coap (Moritz 10 minutes) > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From oscar.novo@ericsson.com Fri Jul 22 03:10:32 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 65B5821F86C4 for ; Fri, 22 Jul 2011 03:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 ldLanIiMrXz5 for ; Fri, 22 Jul 2011 03:10:31 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 12A1621F86B9 for ; Fri, 22 Jul 2011 03:10:30 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-aa-4e294c95326c Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id CE.B6.20773.59C492E4; Fri, 22 Jul 2011 12:10:30 +0200 (CEST) Received: from ESESSCMS0355.eemea.ericsson.se ([169.254.1.39]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Fri, 22 Jul 2011 12:10:29 +0200 From: Oscar Novo To: "core@ietf.org" , "hartke@tzi.org" Date: Fri, 22 Jul 2011 12:10:28 +0200 Thread-Topic: Observing Resources in CoAP: re-ordering Thread-Index: AcxIV5TkpEGNg4wOSv6Nlpvoo3ya3w== Message-ID: <58E207308662A748A4AC1ECB4E8856140AD29AC7C7@ESESSCMS0355.eemea.ericsson.se> 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_58E207308662A748A4AC1ECB4E8856140AD29AC7C7ESESSCMS0355e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [core] Observing Resources in CoAP: re-ordering 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, 22 Jul 2011 10:10:32 -0000 --_000_58E207308662A748A4AC1ECB4E8856140AD29AC7C7ESESSCMS0355e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I think the way the observe draft handles reordering is far too complicated= . Besides, I'm wondering how this solution would work for sleeping clients.= Have you think about it? At least, I can see some problems with the actual= solution. I think a neat solution would be that the server increments in one an integ= er value in every notification to indicate the order of the notifications. = What do you think about that? Cheers, Oscar [http://www.ericsson.com/shared/images/Email_line.gif] OSCAR NOVO Research Engineer, Ericsson Research Nomadiclab, Services and Software Ericsson Finland, Oy L M Ericsson Ab Hirsalantie 11 02420 Jorvas, Finland www.ericsson.com [http://www.ericsson.com/shared/images/Email.gif] This Communication is Confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com/email_disclaimer --_000_58E207308662A748A4AC1ECB4E8856140AD29AC7C7ESESSCMS0355e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I think t= he way the=20 observe draft handles reordering is far too complicated. Besides, I'm wonde= ring=20 how this solution would work for sleeping clients. Have you think abou= t it?=20 At least, I can see some problems with the actual solution.=20
 
I think a neat solut= ion=20 would be that the server increments in one an integer value = in=20 every notification to indicate the order of the notifications. What do you = think=20 about that? 
 
Cheers,
 
Oscar


3Dline

OSCAR NOVO=20
Research Engineer, Ericsson Research


Nomadiclab, S= ervices=20 and Software

Ericsson Finl= and, Oy=20 L M Ericsson Ab
Hirsalantie 11
02420 Jorvas, Finland
www.ericsson.= com=20



3DEricsson=20






This=20 Communication is Confidential. We only send and receive email on the basis = of=20 the term set out at www.ericsson.com/email_di= sclaimer=20

 
--_000_58E207308662A748A4AC1ECB4E8856140AD29AC7C7ESESSCMS0355e_-- From kovatsch@inf.ethz.ch Fri Jul 22 03:20:37 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 CCB8B21F8764 for ; Fri, 22 Jul 2011 03:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 RLqxbQhMjCO7 for ; Fri, 22 Jul 2011 03:20:37 -0700 (PDT) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id 639E421F84FE for ; Fri, 22 Jul 2011 03:20:36 -0700 (PDT) Received: from CAS22.d.ethz.ch (172.31.51.112) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.1.289.1; Fri, 22 Jul 2011 12:20:32 +0200 Received: from MBX20.d.ethz.ch ([fe80::81a7:b7a5:50c0:df0d]) by CAS22.d.ethz.ch ([fe80::dd0e:466a:b055:c090%11]) with mapi id 14.01.0289.001; Fri, 22 Jul 2011 12:20:35 +0200 From: "Kovatsch Matthias" To: Oscar Novo , "core@ietf.org" , "hartke@tzi.org" Thread-Topic: Observing Resources in CoAP: re-ordering Thread-Index: AcxIV5TkpEGNg4wOSv6Nlpvoo3ya3wAAGDWA Date: Fri, 22 Jul 2011 10:20:34 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B50D33C33F@MBX20.d.ethz.ch> References: <58E207308662A748A4AC1ECB4E8856140AD29AC7C7@ESESSCMS0355.eemea.ericsson.se> In-Reply-To: <58E207308662A748A4AC1ECB4E8856140AD29AC7C7@ESESSCMS0355.eemea.ericsson.se> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.253] Content-Type: multipart/related; boundary="_004_55877B3AFB359744BA0F2140E36F52B50D33C33FMBX20dethzch_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [core] Observing Resources in CoAP: re-ordering 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, 22 Jul 2011 10:20:37 -0000 --_004_55877B3AFB359744BA0F2140E36F52B50D33C33FMBX20dethzch_ Content-Type: multipart/alternative; boundary="_000_55877B3AFB359744BA0F2140E36F52B50D33C33FMBX20dethzch_" --_000_55877B3AFB359744BA0F2140E36F52B50D33C33FMBX20dethzch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Sleeping nodes could have a function to map their internal clock to that cu= rrent integer and only update the value when sending notifications. But I would also prefer the a simple counter for the notifications. If the = subscriber is interested in timing, typical applications would include a pr= oper timestamp in the notification anyway. This way I client can also detect how many NON-notifications were lost (or = even CONs if the link is really bad for some time). Regards Matthias From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Osc= ar Novo Sent: Freitag, 22. Juli 2011 12:10 To: core@ietf.org; hartke@tzi.org Subject: [core] Observing Resources in CoAP: re-ordering Hi, I think the way the observe draft handles reordering is far too complicated= . Besides, I'm wondering how this solution would work for sleeping clients.= Have you think about it? At least, I can see some problems with the actual= solution. I think a neat solution would be that the server increments in one an integ= er value in every notification to indicate the order of the notifications. = What do you think about that? Cheers, Oscar [Description: Image removed by sender. line] OSCAR NOVO Research Engineer, Ericsson Research Nomadiclab, Services and Software Ericsson Finland, Oy L M Ericsson Ab Hirsalantie 11 02420 Jorvas, Finland www.ericsson.com [Description: Image removed by sender. Ericsson] This Communication is Confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com/email_disclaimer --_000_55877B3AFB359744BA0F2140E36F52B50D33C33FMBX20dethzch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello=

 = ;

Sleeping n= odes could have a function to map their internal clock to that current inte= ger and only update the value when sending notifications.=

But I woul= d also prefer the a simple counter for the notifications. If the subscriber= is interested in timing, typical applications would include a proper timestamp in the notification anyway.

 = ;

This way I= client can also detect how many NON-notifications were lost (or even CONs = if the link is really bad for some time).

 = ;

Regards

Matthias

 = ;

 = ;

From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Oscar Novo
Sent: Freitag, 22. Juli 2011 12:10
To: core@ietf.org; hartke@tzi.org
Subject: [core] Observing Resources in CoAP: re-ordering<= /span>

 

Hi,

 

I think the way the observe draft handles= reordering is far too complicated. Besides, I'm wondering how this solutio= n would work for sleeping clients. Have you think about it? At least, I can see some problems with the actual solution.

 

I think a neat solution would be tha= t the server increments in one an integer value in every notifica= tion to indicate the order of the notifications. What do you think about that? 

 

Cheers,

 

Oscar

 

3D"Description:

OSCAR NOVO
Research Engineer, Ericsson Research


Nomadiclab, Services and Software

Ericsson Finland, Oy L M Er= icsson Ab
Hirsalantie 11
02420 Jorvas, Finland
www.ericsson.com



3D"Desc=





This Communication is Confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com/email_disclaimer

 

--_000_55877B3AFB359744BA0F2140E36F52B50D33C33FMBX20dethzch_-- --_004_55877B3AFB359744BA0F2140E36F52B50D33C33FMBX20dethzch_ Content-Type: image/jpeg; name="~WRD000.jpg" Content-Description: ~WRD000.jpg Content-Disposition: inline; filename="~WRD000.jpg"; size=823; creation-date="Fri, 22 Jul 2011 10:13:14 GMT"; modification-date="Fri, 22 Jul 2011 10:13:14 GMT" Content-ID: <~WRD000.jpg> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABkAGQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigD//2Q== --_004_55877B3AFB359744BA0F2140E36F52B50D33C33FMBX20dethzch_-- From hartketzi@googlemail.com Fri Jul 22 09:55:58 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 6421E21F8B0B for ; Fri, 22 Jul 2011 09:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_31=0.6, 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 ULamWJuuP56k for ; Fri, 22 Jul 2011 09:55:57 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id E493A21F8B00 for ; Fri, 22 Jul 2011 09:55:52 -0700 (PDT) Received: by fxe4 with SMTP id 4so6389622fxe.27 for ; Fri, 22 Jul 2011 09:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=wg8zlAXDvDtktzbIXdCmSqnB+u9PTfFBO3gPEMWChh8=; b=YDL5pRJaZCs83AjmuoFGYeWjCdcsLUeOvT+1k2XBsWgoExPdEt7WeuiT0Pza9/wyoA dT4F2f3XUPmVK3JooPOQ6lDt17Qph2PJqx+nZD0P2bM/sGn4NJdsHCu/+DDPo5nFHHUU 9nQDbwPGknRxoNsE4B7JyNDWwHdMFI4iBME68= MIME-Version: 1.0 Received: by 10.223.71.208 with SMTP id i16mr2337faj.20.1311353752036; Fri, 22 Jul 2011 09:55:52 -0700 (PDT) Sender: hartketzi@googlemail.com Received: by 10.223.87.15 with HTTP; Fri, 22 Jul 2011 09:55:51 -0700 (PDT) In-Reply-To: <58E207308662A748A4AC1ECB4E8856140AD29AC7C7@ESESSCMS0355.eemea.ericsson.se> References: <58E207308662A748A4AC1ECB4E8856140AD29AC7C7@ESESSCMS0355.eemea.ericsson.se> Date: Fri, 22 Jul 2011 18:55:51 +0200 X-Google-Sender-Auth: e4Ayx_wQfpmiF4rYUR_3P_aEgp4 Message-ID: From: Klaus Hartke To: "core@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [core] Observing Resources in CoAP: re-ordering 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, 22 Jul 2011 16:55:58 -0000 The reordering mechanism was designed to make as few requirements on implementations as possible. This led to some fairly complex language in the draft, but allows for many very simple implementations.=A0I agree that the text should be simplified; there is already a ticket on that (#129). A simple counter for notifications is actually an acceptable implementation, provided that the server does not reuse the same counter value within 2^16 seconds. Another acceptable implementation is to use the current value of the device's clock. Again, the only requirement is that the same value is not reused within 2^16 seconds. There is no requirement that the clock returns the correct date/time or that the clock ticks exactly every second. Here's an implementation in Python: Server: message.observe =3D long(time.time()) % (2**16) Client: obs =3D lookup(message.token) v1 =3D obs.v t1 =3D obs.t v2 =3D long(message.observe) t2 =3D long(time.time()) if (v1 - v2) % (2**16) < (2**15) and t2 < (t1 + (2**14)): print "Discard" else: obs.v =3D v2 obs.t =3D t2 print "Accept" The server needs no state to generate the option value. The client needs just to remember two values per observation relationship; the if-expression is copied literally from the draft. I'm not sure how this can be further simplified; suggestions are welcome. Regarding sleeping devices, draft-arkko-core-sleepy-sensors-01 states for Message IDs: "We have found that using a suitably shifted value of a real-time clock is the most convenient way to generate a good value for this field. On many small platforms, a real-time clock can be kept counting with a very small amount of power. Note that it does not matter what value the real-time clock is initially initialized to; the only thing that matters for the Message ID field is that it keeps changing." The same applies for the Observe option value, so I see no problem here at present. Can you expand on the problems you see with sleeping devices? Klaus On 22 July 2011 12:10, Oscar Novo wrote: > > Hi, > > I think the way the observe draft handles reordering is far too complicat= ed. Besides, I'm wondering how this solution would work for sleeping client= s.=A0Have you think about it? At least, I can=A0see some problems with the = actual solution. > > I think a neat solution would=A0be that=A0the=A0server increments in one = an integer value in every notification to indicate the order of the notific= ations. What do you think about that? > > Cheers, > > Oscar From jari.arkko@piuha.net Sat Jul 23 03:26:22 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 6277721F85C0; Sat, 23 Jul 2011 03:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.419 X-Spam-Level: X-Spam-Status: No, score=-102.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, 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 HrVSn5F-vFIB; Sat, 23 Jul 2011 03:26:21 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id B598521F84FE; Sat, 23 Jul 2011 03:26:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id AB5142CEFF; Sat, 23 Jul 2011 13:26:15 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JL0FqmC9ocxr; Sat, 23 Jul 2011 13:26:14 +0300 (EEST) Received: from [IPv6:::1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id A89E62CC4B; Sat, 23 Jul 2011 13:26:13 +0300 (EEST) Message-ID: <4E2AA1C3.80309@piuha.net> Date: Sat, 23 Jul 2011 06:26:11 -0400 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: core , lwip@ietf.org, roll@ietf.org, 6lowpan@ietf.org References: <4E204877.8040108@piuha.net> In-Reply-To: <4E204877.8040108@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [core] Internet of Things Hacking Meet 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: Sat, 23 Jul 2011 10:26:22 -0000 Today Saturday we will be at room 301 A from 5PM to 8PM. Note that there will be another meeting finishing at 5PM in the same room. Tomorrow Sunday we will be at 304 B from 7PM to 9PM. This is the IESG meeting room. Jari From fluffy@cisco.com Sun Jul 24 07:22: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 CD5AB21F8678 for ; Sun, 24 Jul 2011 07:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.685 X-Spam-Level: X-Spam-Status: No, score=-103.685 tagged_above=-999 required=5 tests=[AWL=-1.086, BAYES_00=-2.599, 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 SqqWzqwOQLmR for ; Sun, 24 Jul 2011 07:22:06 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 510AD21F8569 for ; Sun, 24 Jul 2011 07:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1356; q=dns/txt; s=iport; t=1311517326; x=1312726926; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=/dTFEWjol3o57EzDBIlyBLVysYAgPYREC2XYZgf97pE=; b=bp+iKcpkcp2adVP2S8/hE0hjX8vomz0oLbrotHpGQ04inz9l5tN7QYe6 P3q4KN4ii2pPutNF8E+OrSZxr/6MJ/mRZwVqfZOiclPxtIZKxIh7Wn4YF 7hKvR8BMzOfhh8U9hAB8BMnVTLMEbXYwp2Ia2t1T4DFQAeEr2Oge04svA M=; X-IronPort-AV: E=Sophos;i="4.67,256,1309737600"; d="scan'208";a="5899625" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-3.cisco.com with ESMTP; 24 Jul 2011 14:22:06 +0000 Received: from [10.21.119.151] ([10.21.119.151]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6OEM3n9030837; Sun, 24 Jul 2011 14:22:04 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Sun, 24 Jul 2011 10:22:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <16024FA3-FBA4-4BCF-A5A8-F98EF25F7DCC@cisco.com> References: To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] Draft agenda - version 2 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: Sun, 24 Jul 2011 14:22:06 -0000 Updated agenda below. If you are presenting, please send slides to the = chairs before wed morning 7 am EST.=20 Draft Agenda - Version 2 Session 1=20 Admin (10 min) Link Format draft-ietf-core-link-format (Shelby 5 minutes) CoAP draft-ietf-core-coap (Shelby 30 minutes) Block draft-ietf-core-block (Shelby 15 minutes) Observe draft-ietf-core-observe (Hartke 15 minutes) Proxy Implementation Advice draft-castellani-core-http-coap-mapping (Castellani 15 minutes) = =20 Sleepy Sensors arkko-core-sleepy-sensors (Jari 15 minutes) Session 2=20 Admin (5 minutes) Group Communications draft-rahman-core-groupcomm (Rahman 15 minutes) Size Option draft-li-core-coap-size-option (Li 15 minutes) Request Timeout Option draft-li-core-coap-request-timeout-option (Li 15 minutes) Always Online Requirements for CoAP Nodes (Zhen 15 minutes) draft-cao-core-aol-req-00.txt Building Automation Usage draft-vanderstok-core-bc (Van der Stok 15 minutes)=20 Bootstrapping with EAP draft-ohba-core-eap-based-bootstrapping (Yoshihiro 15 Minutes) SoAP over CoAP draft-moritz-core-soap-over-coap (Moritz 15 minutes) From fluffy@cisco.com Sun Jul 24 07:56: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 4B26B21F852C for ; Sun, 24 Jul 2011 07:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.651 X-Spam-Level: X-Spam-Status: No, score=-103.651 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, 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 G2xDfRTvZctD for ; Sun, 24 Jul 2011 07:56:12 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 9B35621F8520 for ; Sun, 24 Jul 2011 07:56:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1385; q=dns/txt; s=iport; t=1311519372; x=1312728972; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=nU0UbQY9qkwWAO0MXsVPSgV9c4TWut1BSGBiD3zbdU0=; b=KTS8iY15UjJlOaJs2WF6KxzqttkgbQUz8HkBAzKuT27HoFxYGq8hRAIB PSU8s6pluDnyD6tizPr+HK/4vcUClHkI953Egf9GOrCgLg9bj2DoBj42Z +uMeIOZUooe4encMlH57ZSECoHLG7h5vnHMcVedoXP4W3jyaeVP85Ugex c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHYxLE6rRDoH/2dsb2JhbAA1AQEBAQMUAStWDFIUUQc+pyx3pnydJoVgXwSScIUHi3U X-IronPort-AV: E=Sophos;i="4.67,256,1309737600"; d="scan'208";a="5902632" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-2.cisco.com with ESMTP; 24 Jul 2011 14:56:12 +0000 Received: from [10.21.119.151] ([10.21.119.151]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6OEuAN1029160 for ; Sun, 24 Jul 2011 14:56:10 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Cullen Jennings In-Reply-To: <16024FA3-FBA4-4BCF-A5A8-F98EF25F7DCC@cisco.com> Date: Sun, 24 Jul 2011 10:56:09 -0400 Content-Transfer-Encoding: 7bit Message-Id: <833D611E-8CA6-4866-966B-0AC221B2751B@cisco.com> References: <16024FA3-FBA4-4BCF-A5A8-F98EF25F7DCC@cisco.com> To: core WG X-Mailer: Apple Mail (2.1084) Subject: Re: [core] Draft agenda - version 3 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: Sun, 24 Jul 2011 14:56:13 -0000 Draft Agenda - Version 3 Session 1 Admin (10 min) Link Format draft-ietf-core-link-format (Shelby 5 minutes) CoAP draft-ietf-core-coap (Shelby 30 minutes) Block draft-ietf-core-block (Shelby 15 minutes) Observe draft-ietf-core-observe (Hartke 15 minutes) Proxy Implementation Advice draft-castellani-core-http-coap-mapping (Castellani 15 minutes) Sleepy Sensors arkko-core-sleepy-sensors (Jari 15 minutes) Resource Directory and DNS-SD mapping (Kerry & Zach 15 min) draft-lynn-core-discovery-mapping draft-shelby-core-resource-directory Session 2 Admin (5 minutes) Group Communications draft-rahman-core-groupcomm (Rahman 15 minutes) Size Option draft-li-core-coap-size-option (Li 15 minutes) Request Timeout Option draft-li-core-coap-request-timeout-option (Li 15 minutes) Always Online Requirements for CoAP Nodes (Zhen 15 minutes) draft-cao-core-aol-req-00.txt Building Automation Usage draft-vanderstok-core-bc (Van der Stok 15 minutes) Bootstrapping with EAP draft-ohba-core-eap-based-bootstrapping (Yoshihiro 15 Minutes) SoAP over CoAP draft-moritz-core-soap-over-coap (Moritz 15 minutes) From jari.arkko@piuha.net Sun Jul 24 13:48:32 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 54FA921F8562; Sun, 24 Jul 2011 13:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.434 X-Spam-Level: X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, 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 z6tKEhxO1ovx; Sun, 24 Jul 2011 13:48:31 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id B0DEF21F8506; Sun, 24 Jul 2011 13:48:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9A1122CE66; Sun, 24 Jul 2011 23:48:29 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttnf3Y2Ymku9; Sun, 24 Jul 2011 23:48:28 +0300 (EEST) Received: from [IPv6:::1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 9BE4D2CC4B; Sun, 24 Jul 2011 23:48:27 +0300 (EEST) Message-ID: <4E2C851A.9000909@piuha.net> Date: Sun, 24 Jul 2011 16:48:26 -0400 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: core , lwip@ietf.org, roll@ietf.org, 6lowpan@ietf.org References: <4E204877.8040108@piuha.net> <4E2AA1C3.80309@piuha.net> In-Reply-To: <4E2AA1C3.80309@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [core] [Roll] Internet of Things Hacking Meet 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: Sun, 24 Jul 2011 20:48:32 -0000 An update: We are also today at the same room as yesterday: 301A. Welcome! Jari Jari Arkko kirjoitti: > Today Saturday we will be at room 301 A from 5PM to 8PM. Note that > there will be another meeting finishing at 5PM in the same room. > Tomorrow Sunday we will be at 304 B from 7PM to 9PM. This is the IESG > meeting room. > > Jari > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From oscar.novo@ericsson.com Mon Jul 25 04:53:53 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 D796D21F84B6 for ; Mon, 25 Jul 2011 04:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] 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 lKeMQ1t+egFg for ; Mon, 25 Jul 2011 04:53:52 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id AF10421F849F for ; Mon, 25 Jul 2011 03:31:30 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-88-4e2d4601206b Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A0.7E.09774.1064D2E4; Mon, 25 Jul 2011 12:31:29 +0200 (CEST) Received: from ESESSCMS0355.eemea.ericsson.se ([169.254.1.251]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Mon, 25 Jul 2011 12:31:29 +0200 From: Oscar Novo To: Klaus Hartke , "core@ietf.org" Date: Mon, 25 Jul 2011 12:31:27 +0200 Thread-Topic: [core] Observing Resources in CoAP: re-ordering Thread-Index: AcxIkGSsrHZUWfJQSb+gkYgCNcBa6ACI6PCw Message-ID: <58E207308662A748A4AC1ECB4E8856140DCC0F8F29@ESESSCMS0355.eemea.ericsson.se> References: <58E207308662A748A4AC1ECB4E8856140AD29AC7C7@ESESSCMS0355.eemea.ericsson.se> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [core] Observing Resources in CoAP: re-ordering 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, 25 Jul 2011 11:53:54 -0000 If we suppose the case of a network which has some sleeping nodes and some = caching nodes which store the observation methods and deliver them once the= sleeping-nodes are awake. How an sleeping observer could handle the histor= ical notifications data of a subject if the wake up time of the node is hig= her than 18.2 hours? As you said, simplifying some parts of the text might help. Right now, the = complexity of it make it difficult to understand the draft. =20 Oscar -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Kla= us Hartke Sent: 22. hein=E4kuuta 2011 19:56 To: core@ietf.org Subject: Re: [core] Observing Resources in CoAP: re-ordering The reordering mechanism was designed to make as few requirements on implem= entations as possible. This led to some fairly complex language in the draf= t, but allows for many very simple implementations.=A0I agree that the text= should be simplified; there is already a ticket on that (#129). A simple counter for notifications is actually an acceptable implementation= , provided that the server does not reuse the same counter value within 2^1= 6 seconds. Another acceptable implementation is to use the current value of the device= 's clock. Again, the only requirement is that the same value is not reused = within 2^16 seconds. There is no requirement that the clock returns the cor= rect date/time or that the clock ticks exactly every second. Here's an implementation in Python: Server: message.observe =3D long(time.time()) % (2**16) Client: obs =3D lookup(message.token) v1 =3D obs.v t1 =3D obs.t v2 =3D long(message.observe) t2 =3D long(time.time()) if (v1 - v2) % (2**16) < (2**15) and t2 < (t1 + (2**14)): print "Discard" else: obs.v =3D v2 obs.t =3D t2 print "Accept" The server needs no state to generate the option value. The client needs ju= st to remember two values per observation relationship; the if-expression i= s copied literally from the draft. I'm not sure how this can be further sim= plified; suggestions are welcome. Regarding sleeping devices, draft-arkko-core-sleepy-sensors-01 states for M= essage IDs: "We have found that using a suitably shifted value of a real-ti= me clock is the most convenient way to generate a good value for this field= . On many small platforms, a real-time clock can be kept counting with a ve= ry small amount of power. Note that it does not matter what value the real-= time clock is initially initialized to; the only thing that matters for the= Message ID field is that it keeps changing." The same applies for the Obse= rve option value, so I see no problem here at present. Can you expand on the problems you see with sleeping devices? Klaus On 22 July 2011 12:10, Oscar Novo wrote: > > Hi, > > I think the way the observe draft handles reordering is far too complicat= ed. Besides, I'm wondering how this solution would work for sleeping client= s.=A0Have you think about it? At least, I can=A0see some problems with the = actual solution. > > I think a neat solution would=A0be that=A0the=A0server increments in one = an integer value in every notification to indicate the order of the notific= ations. What do you think about that? > > Cheers, > > Oscar _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Mon Jul 25 05:05:44 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 E926021F8591 for ; Mon, 25 Jul 2011 05:05:44 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXkJxOTDdK0m for ; Mon, 25 Jul 2011 05:05:44 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id E3ABE21F86A2 for ; Mon, 25 Jul 2011 05:02:49 -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 p6PC2eXC005347; Mon, 25 Jul 2011 14:02:40 +0200 (CEST) Received: from [192.168.217.105] (p5B3E756E.dip.t-dialin.net [91.62.117.110]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 80F1455C; Mon, 25 Jul 2011 14:02:40 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <58E207308662A748A4AC1ECB4E8856140DCC0F8F29@ESESSCMS0355.eemea.ericsson.se> Date: Mon, 25 Jul 2011 14:02:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <58E207308662A748A4AC1ECB4E8856140AD29AC7C7@ESESSCMS0355.eemea.ericsson.se> <58E207308662A748A4AC1ECB4E8856140DCC0F8F29@ESESSCMS0355.eemea.ericsson.se> To: Oscar Novo X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org" , Klaus Hartke Subject: Re: [core] Observing Resources in CoAP: re-ordering 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, 25 Jul 2011 12:05:45 -0000 On Jul 25, 2011, at 12:31, Oscar Novo wrote: > If we suppose the case of a network which has some sleeping nodes and = some caching nodes which store the observation methods and deliver them = once the sleeping-nodes are awake. How an sleeping observer could handle = the historical notifications data of a subject if the wake up time of = the node is higher than 18.2 hours? I'm not sure I understand the question, but after 18.2 hours the time = limit of t2 < (t1 + (2**14)) is long gone, so there would be no need to = check for reordered messages reaching back that long. Gruesse, Carsten From rgm@labs.htt-consult.com Mon Jul 25 09:05:08 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 507B221F9043 for ; Mon, 25 Jul 2011 09:05:08 -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 Oa5VUHDXXQyG for ; Mon, 25 Jul 2011 09:05:07 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id AB20221F8BC6 for ; Mon, 25 Jul 2011 07:07:53 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 8F42F62A94 for ; Mon, 25 Jul 2011 14:07:49 +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 fbhhIJ4gHi86 for ; Mon, 25 Jul 2011 10:07:39 -0400 (EDT) Received: from nc2400.htt-consult.com (unknown [207.164.135.98]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id 212CC62A6F for ; Mon, 25 Jul 2011 10:07:39 -0400 (EDT) Message-ID: <4E2D78AA.60008@labs.htt-consult.com> Date: Mon, 25 Jul 2011 10:07:38 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11 MIME-Version: 1.0 To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [core] An update on IEEE 802.15.4 Key Management 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, 25 Jul 2011 16:05:08 -0000 This past week, the Key Management Protocol Interest Group met and moved forward with a plan to develop a transport mechanism for any Key Management Protocol. See presentation: https://mentor.ieee.org/802.15/documents/15-11-0381-03-0hip-KMP-over-4e-Multipurpose.ppt This approach will use the new Information Elements of 802.15.4e and Multipurpose Frames to transport any Key Management Protocol. Now I much prefer that you all use HIP, but I am a realist that more than one screwdriver is needed in the toolbox, so IKEv2, 802.1X, SAE, and a 4-way-handshake (like in 802.11i) will be described. One challenge will be short address selection and collision avoidance. A general method of collision avoidance is needed, as a WPAN could have more than one KMP in use. It is conceivable that this is too hard to resolve, and KMP will be restricted to long addresses. This will be a Recommended Practice. In Okinawa we will be formalizing the design of the transport shim, the Security Association requirements, and how to interact with the 802.15.4 security mechinism as discribed in the forth-coming 802.15.4-2011 (802.15.4i). The draft PAR is: https://mentor.ieee.org/802.15/documents/15-11-0512-01-0hip-Key-Management-Protocol-PAR.doc To participate in this work, please join the HIPIG 802.15 mailing list. Considering our timeline to a PAR (could happen in November), the management does not want to create a KMPIG mailing list. The current documents are under HIPIG, but all documents moving forward will be under KMPIG. I will be available during the week to discuss this. From internet-drafts@ietf.org Mon Jul 25 19:33: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 30DEC21F8C24; Mon, 25 Jul 2011 19:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, 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 EMrQUm+z7wzq; Mon, 25 Jul 2011 19:33:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B884B21F8C1B; Mon, 25 Jul 2011 19:33:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.56 Message-ID: <20110726023316.15210.20438.idtracker@ietfa.amsl.com> Date: Mon, 25 Jul 2011 19:33:16 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-link-format-07.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: Tue, 26 Jul 2011 02:33:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Work= ing Group of the IETF. Title : CoRE Link Format Author(s) : Zach Shelby Filename : draft-ietf-core-link-format-07.txt Pages : 19 Date : 2011-07-25 This document defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes and other relationships between links. Based on the HTTP Link Header format defined in RFC5988, the CoRE Link Format is carried as a payload and is assigned an Internet media type. A well- known URI is defined as a default entry-point for requesting the links hosted by a server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-core-link-format-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-core-link-format-07.txt From stpeter@stpeter.im Tue Jul 26 05:11:37 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 4CC0C21F8B6A for ; Tue, 26 Jul 2011 05:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, 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 tXmJ5VNgxiaf for ; Tue, 26 Jul 2011 05:11:36 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BF47721F8B32 for ; Tue, 26 Jul 2011 05:11:36 -0700 (PDT) Received: from squire.local (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DA054411C7 for ; Tue, 26 Jul 2011 06:12:34 -0600 (MDT) Message-ID: <4E2EAEF7.8070607@stpeter.im> Date: Tue, 26 Jul 2011 08:11:35 -0400 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: core WG References: <20110726111619.1979.59839.idtracker@ietfa.amsl.com> In-Reply-To: <20110726111619.1979.59839.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.2 OpenPGP: url=https://stpeter.im/stpeter.asc X-Forwarded-Message-Id: <20110726111619.1979.59839.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [core] Fwd: I-D Action: draft-arkko-core-security-arch-00.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: Tue, 26 Jul 2011 12:11:37 -0000 FYI. -------- Original Message -------- Subject: I-D Action: draft-arkko-core-security-arch-00.txt Date: Tue, 26 Jul 2011 04:16:19 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : CoAP Security Architecture Author(s) : Jari Arkko Ari Keranen Filename : draft-arkko-core-security-arch-00.txt Pages : 22 Date : 2011-07-26 Constrained Application Protocol (CoAP) is a light-weight protocol designed to be used in machine-to-machine applications. This memo describes challenges associated with securing CoAP and proposes a new security model that the authors believe is suitable for these environments. The model requires minimal amount of configuration, but still provides strong security and is a natural fit with the typical communication practices smart object networking environments. This memo also proposes JSON payload format extensions to support the architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-arkko-core-security-arch-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-arkko-core-security-arch-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From oscar.garcia@philips.com Tue Jul 26 08:07:49 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 D963721F8BD3 for ; Tue, 26 Jul 2011 08:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 8Q-JHOdBuy2E for ; Tue, 26 Jul 2011 08:07:47 -0700 (PDT) Received: from TX2EHSOBE007.bigfish.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id BC4FA21F8BDC for ; Tue, 26 Jul 2011 08:07:47 -0700 (PDT) Received: from mail35-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.22; Tue, 26 Jul 2011 15:07:47 +0000 Received: from mail35-tx2 (localhost.localdomain [127.0.0.1]) by mail35-tx2-R.bigfish.com (Postfix) with ESMTP id 1197BC504C6; Tue, 26 Jul 2011 15:07:47 +0000 (UTC) X-SpamScore: -52 X-BigFish: VPS-52(zf7Iz217bL15d6O9251J936eK1b0bM542M1418Mzz1202hzz1033IL8275dhz2dh2a8h668h839h944h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:168.87.56.20; KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI Received: from mail35-tx2 (localhost.localdomain [127.0.0.1]) by mail35-tx2 (MessageSwitch) id 1311692866704357_20850; Tue, 26 Jul 2011 15:07:46 +0000 (UTC) Received: from TX2EHSMHS032.bigfish.com (unknown [10.9.14.253]) by mail35-tx2.bigfish.com (Postfix) with ESMTP id A0BD2B0050; Tue, 26 Jul 2011 15:07:46 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by TX2EHSMHS032.bigfish.com (10.9.99.132) with Microsoft SMTP Server (TLS) id 14.1.225.22; Tue, 26 Jul 2011 15:07:46 +0000 Received: from NLHILEXH05.connect1.local (172.16.153.71) by connect1.philips.com (172.16.156.43) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 26 Jul 2011 17:07:39 +0200 Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by NLHILEXH05.connect1.local ([172.16.153.71]) with mapi; Tue, 26 Jul 2011 17:05:34 +0200 From: "Garcia Morchon, Oscar" To: core WG Date: Tue, 26 Jul 2011 17:07:46 +0200 Thread-Topic: [core] Fwd: I-D Action: draft-arkko-core-security-arch-00.txt Thread-Index: AcxLjOYWScqi6ejrRIixjbGXSbAnIQADvjSw Message-ID: <5F6BB0D9318FCA4083FC774C9A9ECEF68C17FE7BFD@NLCLUEXM03.connect1.local> References: <20110726111619.1979.59839.idtracker@ietfa.amsl.com> <4E2EAEF7.8070607@stpeter.im> In-Reply-To: <4E2EAEF7.8070607@stpeter.im> 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: "ari.keranen@ericsson.com" Subject: Re: [core] Fwd: I-D Action: draft-arkko-core-security-arch-00.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: Tue, 26 Jul 2011 15:07:49 -0000 All, Below you find comments on the draft. Two main comments: Comment A) My main comment is that the threat model and actual security/ope= rational needs for which the architecture has been designed are missing. Th= us, it is rather difficult to analyze how well the architecture fits some u= se cases or others. Comment B) My feeling is that we have to align in security to make clear ho= w thoughts/solutions fit together. In our draft we describe a number of sec= urity profiles, in such a way that applications with basic security needs h= ave basic security mechanism; applications with more strict threats introdu= ce more advanced security mechanisms. It would be good to describe the secu= rity architecture for CoAP/6LoWPAN networks in these terms. Regards, Oscar. ----------------------------------------------- (some first comments) Comment related to: "This section discusses three challenges: implementatio= n difficulties, practical provisioning problems, and layering and communica= tion models." For implementation, it is said that resource-limitations should not be over= emphasized. It is true; but it is still key to keep things as simple as pos= sible. If I remember well, the target devices are 100/10. Comment related to: " This list of short identifiers can then be fed to a c= entral server as a list of authorized devices." It would be good if the architecture could address ad-hoc settings; very fr= equent in this type of networks. Comment related to: "The authors have employed a simple but not completely = secure method where the last few digits of the identity are printed on a ti= ny device just a few millimeters across." This is a very specific use case. I would suggest to clearly identify the a= pplication scope of this approach. Comment related to: " the private key which never leaves the device." No all applications can assume usage of PKC. Comment related to: "Each devices generates its own identity in a random, s= ecure key generation process." This is written as part of the architecture; should be first listed as a re= quirement. Comment related to: "Under most circumstances there is actually no addition= al configuration effort from provisioning security." Circumstances should be detailed - otherwise, there is risk of misusing sec= urity methods. Comment related to: " Devices that do not belong to the kit can not claim t= o be in the group, because the group identity would change if any new keys = were added to Igrp." Approach might fail when thinking about the thing lifecycle (decommissionin= g and reinstallation) - this should be covered to update group identities. Comment related to: " then communicated out-of- band to the peers that need= to know what devices to trust." This approach might not scale for networks with 100s of devices. Comment related to: "A node with identity I should sign each message it se= nds with the private key associated with the identity I." This is very expensive from CPU point of view; PKC cannot be assumed in all= devices; this should be supported by standard protocols Comment related to: "timestamp-based approach SHOULD be used in addition to= the basic signatures" This requires time-synchronization (that should be also secure ;)). This mi= ght not be supported by all applications/networks/devices. Comment related to: "that have seen multiple messages from the same sender = SHOULD silently ignore messages that do not have a sequence number greater = than the one they have seen last" This does not work - you should consider at least a window of numbers accep= ted. Otherwise many messages might be dropped (multiple paths might lead to= messages arriving in different order). Comment related to: "However, it is our belief that the right layer for thi= s solution is at the application layer." In some applications, lower layers should be protected as well. Otherwise, = you can just flood the network. Comment related to: " This can be supported, with some additional provision= ing effort and optional pairing protocols." In my view, we need a basic provisioning protocol that can really be used i= n different applications. Otherwise, the amount of code/approaches in the d= evices is going to exploit. It will be also very difficult to manage all th= e provisioning approaches. Comment related to: " In any case, as with sensor networks the amount of co= nfiguration information is minimized: just one short identity value needs = to be fed in." Advanced security policies might require defining which type of information= is accepted from a given device. Comment related to: " there are some remaining vulnerabilities that may or = may not be acceptable for the application in question." For the security architecture, we should first list "addressed threats" and= "threats out-of-the-scope"; and then define solution. Comment related to: "Only identities need to be communicated to the devices= , not certificates," I think that there are other use cases that require more advanced policies. Comment related to: " The concrete implementation of the proposed architect= ure involves a specification for the identity format and generation, and a = specification of the data format necessary to carry the signature, public k= ey, timestamp, and sequence number data objects." My feeling is that this can increase the overhead quite a lot. Do you have = numbers for the actual message sizes? It would be also good if the solution= could be implemented by means of existing protocols (e.g., DTLS); otherwis= e we are creating something completely new ... when there are already lots = of things out there. Comment related to: " 5.2. Identity Generation" The presented methods can work - but it really seems to me that they are qu= ite bulky. This should fit small devices at the end, right? 100/10. Comment related to: " RSA public/private key pair SHOULD be used." Personally, I do believe that RSA is very heavy. If I remember well, 128-bi= t equivalent security requires 3072 bit RSA keys... no fully sure if this a= pplies to small devices (if the devices can run PKC at all) Comment related to: " The extension data should consist of a 16-bit length = field that expresses the number of public keys that follow, " Usage of the fingerprint of the public-key would make things more efficient= . Comment related to: " Every secure message MUST carry a JSON envelope objec= t. " This can be very expensive (BW/CPU). Fragmentation might be required. Secur= ity issues might appear with fragmentation. Comment related to: " deployment model, security architecture, and an initi= al sketch of protocol design to support the architecture." Here I am missing the actual threat model, operational needs, and security = requirements of the target deployment. It seems to me that the architecture= has been designed starting from HITs. The design needs should be at the be= ginning. Then list possibilities for doing things. Then describe solution. = Then analyze how the architecture fits the requirements identified at the b= eginning. -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Pet= er Saint-Andre Sent: Tuesday 26 July 2011 8:12 To: core WG Subject: [core] Fwd: I-D Action: draft-arkko-core-security-arch-00.txt FYI. -------- Original Message -------- Subject: I-D Action: draft-arkko-core-security-arch-00.txt Date: Tue, 26 Jul 2011 04:16:19 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : CoAP Security Architecture Author(s) : Jari Arkko Ari Keranen Filename : draft-arkko-core-security-arch-00.txt Pages : 22 Date : 2011-07-26 Constrained Application Protocol (CoAP) is a light-weight protocol designed to be used in machine-to-machine applications. This memo describes challenges associated with securing CoAP and proposes a new security model that the authors believe is suitable for these environments. The model requires minimal amount of configuration, but still provides strong security and is a natural fit with the typical communication practices smart object networking environments. This memo also proposes JSON payload format extensions to support the architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-arkko-core-security-arch-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-arkko-core-security-arch-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ 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 oscar.garcia@philips.com Tue Jul 26 08:07:56 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 E25CC1F0C38 for ; Tue, 26 Jul 2011 08:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 iIv7cjHR0HpY for ; Tue, 26 Jul 2011 08:07:56 -0700 (PDT) Received: from TX2EHSOBE006.bigfish.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7F80F1F0C37 for ; Tue, 26 Jul 2011 08:07:55 -0700 (PDT) Received: from mail109-tx2-R.bigfish.com (10.9.14.242) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.22; Tue, 26 Jul 2011 15:07:54 +0000 Received: from mail109-tx2 (localhost.localdomain [127.0.0.1]) by mail109-tx2-R.bigfish.com (Postfix) with ESMTP id B87A814E8465; Tue, 26 Jul 2011 15:07:54 +0000 (UTC) X-SpamScore: -43 X-BigFish: VPS-43(zz217bL15d6O9251J14e4Mb73dMzz1202hzz8275ch1033IL8275dhz2dh2a8h668h839h944h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:168.87.56.20; KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI Received: from mail109-tx2 (localhost.localdomain [127.0.0.1]) by mail109-tx2 (MessageSwitch) id 1311692874252492_9423; Tue, 26 Jul 2011 15:07:54 +0000 (UTC) Received: from TX2EHSMHS017.bigfish.com (unknown [10.9.14.251]) by mail109-tx2.bigfish.com (Postfix) with ESMTP id 2ED5C36804B; Tue, 26 Jul 2011 15:07:54 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by TX2EHSMHS017.bigfish.com (10.9.99.117) with Microsoft SMTP Server (TLS) id 14.1.225.22; Tue, 26 Jul 2011 15:07:53 +0000 Received: from NLHILEXH05.connect1.local (172.16.153.71) by connect1.philips.com (172.16.156.153) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 26 Jul 2011 17:07:27 +0200 Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by NLHILEXH05.connect1.local ([172.16.153.71]) with mapi; Tue, 26 Jul 2011 17:05:26 +0200 From: "Garcia Morchon, Oscar" To: core WG , Carsten Bormann , Cullen Jennings Date: Tue, 26 Jul 2011 17:07:37 +0200 Thread-Topic: key provisioning and device association Thread-Index: AcxLHrcWFeSb6ShZSz+uN66Hn0kYtwAAHOuAABiUMcAACLdhUA== Message-ID: <5F6BB0D9318FCA4083FC774C9A9ECEF68C17FE7BFC@NLCLUEXM03.connect1.local> 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: "subir@research.telcordia.com" Subject: [core] key provisioning and device association 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, 26 Jul 2011 15:07:57 -0000 Dear all, Yesterday afternoon Yoshi, Subir and myself had a good discussion about approaches related for key provisioning and device association. We would like to create a forum to discuss this all together. Next we wanted to briefly share with you some of the main points (comments/ additions are welcome): - We think that this is an important aspect that should be considered within the working group. - we have to align and discuss different approaches. - approach in https://datatracker.ietf.org/doc/draft-ohba-core-eap-= based-bootstrapping/ is a particular approach. We believe that it can work in many use cases; however, it really needs to be analyzed how well it fits, e.= g., very resource-constrained devices/networks. At the end of this email you find a description of the involved messages. - as described in Section 6 in https://datatracker.ietf.org/doc/dra= ft-garcia-core-security/ , different applications might have different needs, in particular: - some approaches might be required due to legacy systems (= e.g., AAA architectures usually rely on EAP methods) - some (new) lightweight approaches might be needed to fit = in small devices/constrained networks. - In particular, in Prague was discussed the possib= ility of a very lightweight " Duckling and Mother " approach and I = believe that Carsten had started to write an I-D in that direction based on DTLS. In th= is approach, DTLS was used to set up a common key to be used by a pair of devi= ces. - I think it would be good to recover/think about C= arsten's approach. - different approaches can/should be evaluated in: # messages/code size/sec= urity/flexibility ------------------------- A few ideas/steps to make next steps more concrete: a) it would be good to create a group "flexible bootstrapping" I-D which in= cludes methods addressing key use cases. b) in particular, it would be good to create an extensible bootstrapping fi= tting different use cases. Two main needs are as follows (others?) case 1: lightweight applications that have to reuse as much as poss= ible existing code and limit number of exchanged messages bytes (e.g., reuse of operational security protocols (e.g., DTLS)= for key provisioning Device association to a security domain) case 2: legacy systems in which protocol reuse is needed. (use of specialized protocols) c) a particular approach - that might be included in the I-D - would be a m= odular method in which starting with a very basic method valid for resource-constr= ained devices, the method can be extended in such a way that might also cover leg= acy systems. This is just a first thought, but that might be good to further an= alyze it. The approach might have three levels of complexity: - Level 1: very basic "local" approach based on DTLS (as described = by Carsten) and allowing for "Duckling and Mother" key provisioning bet= ween two devices. (two devices that are close by can setup a common key that = can be used with DTLS later. For the ""Duckling and Mother" DTLS is reused s= o that No additional source code is needed") - Level 2: very basic "centralized" (D)TLS approach in which (D)TLS= is used for key provisioning from a central device in the Internet. The= key provisioning Might distribute in a secure way some keys to be used in a = given security domain). (here DTLS is reused so no additional code is required) - Level 3: TLS can be reused as lower layer for EAP (http://tools.i= etf.org/html/draft-nir-tls-eap-12 ). If the same could be done with DTLS, EAP might be transport= ed and CoAP devices could interact with existing AAA infrastructures. T= his approach however increases the requirements in source code in the de= vices and might involve a higher overhead. d) the above approach allows for fully interoperability, in the sense that = the methods can be extended to address different use cases, but it also requires more s= tandardization. Another approach would be to keep Step 1 and Step 2 based on DTLS as descri= bed above, and also have https://datatracker.ietf.org/doc/draft-ohba-core-eap-based-bootst= rapping/. e) Last week I did some research helped by University of Murcia (Spain) whe= re an open implementation of PANA has been developed (http://sourceforge.net/projects/= openpana/). Below you find a summary of exchanged messages for the PANA/EAP approach (E= AP method based on certificates, PSK would be more lightweight). -------------------------------- I hope this helps, Comments/ideas are very welcome, Regards, Oscar. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >From OpenPana (http://sourceforge.net/projects/openpana/) developed by Univ= ersity of Murcia (Spain) PANA CLIENT INITIATION: 16 bytes PANA AUTH REQUEST (PRF & INTEGRITY Algorithms exchange): 40 bytes PANA AUTH= ANSWER (PRF & INTEGRITY Algorithms exchange): 40 bytes PANA AUTH REQUEST (Carrying EAP Packet & NONCE AVP): 60 bytes PANA AUTH ANS= WER (Carrying NONCE AVP): 44 bytes PANA AUTH REQUEST (Carrying EAP Packet only (EAP RESPONSE)): 36 bytes PANA = AUTH ANSWER (Without AVP): 16 bytes PANA AUTH REQUEST (Carrying EAP Packet only (EAP REQUEST)): 32 bytes PANA A= UTH ANSWER (Without AVP): 16 bytes PANA AUTH REQUEST (Carrying EAP Packet only (CLIENT HELLO)): 88 bytes PANA = AUTH ANSWER (Without AVP): 16 bytes PANA AUTH REQUEST (Carrying EAP Packet only (SERVER HELLO)): 1324 bytes PAN= A AUTH ANSWER (Without AVP): 16 bytes PANA AUTH REQUEST (Carrying EAP Packet only (EAP RESPONSE)): 32 bytes PANA = AUTH ANSWER (Without AVP): 16 bytes PANA AUTH REQUEST (Carrying EAP Packet only (TLSV1)): 1112 bytes PANA AUTH = ANSWER (Without AVP): 16 bytes PANA AUTH REQUEST (Carrying EAP Packet only (SSL)): 1432 bytes PANA AUTH AN= SWER (Without AVP): 16 bytes PANA AUTH REQUEST (Carrying EAP Packet only (EAP REQUEST)): 32 bytes PANA A= UTH ANSWER (Without AVP): 16 bytes PANA AUTH REQUEST (Carrying EAP Packet only (TLSV1)): 1364 bytes PANA AUTH = ANSWER (Without AVP): 16 bytes PANA AUTH REQUEST (Carrying EAP Packet only (TLSV1)): 96 bytes PANA AUTH AN= SWER (Without AVP): 16 bytes PANA AUTH REQUEST (Carrying EAP Packet only (EAP RESPONSE)): 32 bytes PANA = AUTH ANSWER (Without AVP): 16 bytes PANA AUTH REQUEST (Carrying EAP Packet (EAP SUCCESS), Key-Id, Result-Code, = Session-Lifetime & Auth AVPS): 92 bytes PANA AUTH ANSWER (Carrying Key-Id &= Auth Avps): 56 bytes (Three short comments: (i) message sizes require fragmentation so that the = # of packets in the air will be higher; (ii) PANA-AUTH-REQUEST are PANA-AUT= H-ANSWER small (16 B) because EAP piggybacking is not active; (iii) if EAP = piggybacking is active, the # of messages would decrease.) 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 rgm@labs.htt-consult.com Wed Jul 27 04:04:15 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 28B1921F8B70 for ; Wed, 27 Jul 2011 04:04:15 -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 XydalJKBkan4 for ; Wed, 27 Jul 2011 04:04:14 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 4468F21F8B6E for ; Wed, 27 Jul 2011 04:04:14 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 684F062AE1 for ; Wed, 27 Jul 2011 11:04: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 hWyUGiSAjPga for ; Wed, 27 Jul 2011 07:03:44 -0400 (EDT) Received: from nc2400.htt-consult.com (dhcp-47f5.meeting.ietf.org [130.129.71.245]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id A986262AB8 for ; Wed, 27 Jul 2011 07:03:44 -0400 (EDT) Message-ID: <4E2FF085.4030206@labs.htt-consult.com> Date: Wed, 27 Jul 2011 07:03:33 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11 MIME-Version: 1.0 To: core@ietf.org References: <4E2D78AA.60008@labs.htt-consult.com> <4E2ECB31.3040702@ericsson.com> In-Reply-To: <4E2ECB31.3040702@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [core] An update on IEEE 802.15.4 Key Management 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, 27 Jul 2011 11:04:15 -0000 hmmm, I pieced those together. let me see... On 07/26/2011 10:12 AM, Ari Keränen wrote: > Hi Bob, > > Those links don't seem to work; at least I get a page saying "The page > requested was not found or is not a functioning properly." > > > Cheers, > Ari > > On 25.7.2011 10:07, Robert Moskowitz wrote: >> This past week, the Key Management Protocol Interest Group met and moved >> forward with a plan to develop a transport mechanism for any Key >> Management Protocol. See presentation: >> >> https://mentor.ieee.org/802.15/documents/15-11-0381-03-0hip-KMP-over-4e-Multipurpose.ppt >> https://mentor.ieee.org/802.15/dcn/11/15-11-0381-03-0hip-key-management-over-4e-multipurpose-frames.ppt yes. I see I got it wrong. >> >> >> This approach will use the new Information Elements of 802.15.4e and >> Multipurpose Frames to transport any Key Management Protocol. Now I much >> prefer that you all use HIP, but I am a realist that more than one >> screwdriver is needed in the toolbox, so IKEv2, 802.1X, SAE, and a >> 4-way-handshake (like in 802.11i) will be described. >> >> One challenge will be short address selection and collision avoidance. A >> general method of collision avoidance is needed, as a WPAN could have >> more than one KMP in use. It is conceivable that this is too hard to >> resolve, and KMP will be restricted to long addresses. >> >> This will be a Recommended Practice. In Okinawa we will be formalizing >> the design of the transport shim, the Security Association requirements, >> and how to interact with the 802.15.4 security mechinism as discribed in >> the forth-coming 802.15.4-2011 (802.15.4i). The draft PAR is: >> >> https://mentor.ieee.org/802.15/documents/15-11-0512-01-0hip-Key-Management-Protocol-PAR.doc >> https://mentor.ieee.org/802.15/dcn/11/15-11-0512-01-0hip-key-management-protocol-par.doc .15 uses 'dcn' , not 'documents'. And I had the case wrong to boot. >> >> >> To participate in this work, please join the HIPIG 802.15 mailing list. >> Considering our timeline to a PAR (could happen in November), the >> management does not want to create a KMPIG mailing list. The current >> documents are under HIPIG, but all documents moving forward will be >> under KMPIG. >> >> I will be available during the week to discuss this. From tianlinyi@huawei.com Wed Jul 27 12:03: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 3B98B5E80AE for ; Wed, 27 Jul 2011 12:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.928 X-Spam-Level: X-Spam-Status: No, score=-4.928 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_FUTURE_03_06=0.274, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 ZonK5ApfM0sq for ; Wed, 27 Jul 2011 12:03:05 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 83A8121F8760 for ; Wed, 27 Jul 2011 12:02:56 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP00080CA8VXB@szxga03-in.huawei.com> for core@ietf.org; Thu, 28 Jul 2011 03:02:55 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP00018BA8VSV@szxga03-in.huawei.com> for core@ietf.org; Thu, 28 Jul 2011 03:02:55 +0800 (CST) Received: from [130.129.22.143] (dhcp-168f.meeting.ietf.org [130.129.22.143]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LP000640A8QJW@szxml11-in.huawei.com> for core@ietf.org; Thu, 28 Jul 2011 03:02:55 +0800 (CST) Date: Wed, 27 Jul 2011 21:02:48 -0400 From: Linyi Tian 01 To: core@ietf.org Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_zKv+4Xz9ASuDsAArdlI6Lw)" Thread-topic: Minutes for Core Wednesday Afternoon Meeting User-Agent: Microsoft-MacOutlook/14.0.0.100825 Subject: [core] Minutes for Core Wednesday Afternoon Meeting 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, 27 Jul 2011 19:03:06 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_zKv+4Xz9ASuDsAArdlI6Lw) Content-type: text/plain; charset=GB2312 Content-transfer-encoding: quoted-printable Hi, Core Folks Here is the minutes I took during this afternoon meeting. I am not sure whether this is the worst minutes you ever seen in Core:) Minutes for Core (Wednesday Afternoon) 1. Charter Review Peter suggested it maybe reasonable to allow several months work on block draft. Linyi suggested it make sense to merge the size option draft into block draft if it is accepted as WG item. =20 =20 2. Core Resource Directory Draft (Zach) There is a related EU project SENSI (2008-2010) for this feature. Hannes Tschofenig:=20 =A1=A4 Which part will be standardized in the RD architecture? There is different IOP need in different parts. =A1=A4 Is the interface between the RDS and sensor or device? What does client means? Kepeng Li:=20 =A1=A4 Can we achieve partially update, from the syntax, it seems to be difficult;=20 =A1=A4 Does it have influence to the link-format document, because it is mentioned in the ppt =20 3. DNS-Based Service Discovery (Kerry Lynn) Kepeng: Should this be informational? No other serious issues were raised. =20 4. Group Communication (Akbar) Kerry: xxxx (was not captured, sorry) It was proposed to have application multicast, why now we changed to IP layer multicast? Akbar: We investigated the different options: IP Multicast, Overlay Multicast and CoAP Application Level Group Management. Finally we come to the conclusion that we should just do IP Multicast. Zach: Do you think that multicast will cause congestion control? In the bas= e spec, we have already used IP multicast. =20 5. Size Option (Kepeng Li) cabo: =A1=A4 I like the basic approach [20:02:16] 1) I like the basic approach [20:02:53] *** kepeng_li\40jabber.org (kepeng_li@jabber.org/4290206ceb1e85de) has left the room [20:03:09] 2) We need to separate the HEAD (send no data) function from the size indication 3) We need to provide the end-points with hints on when to send this and when not. [20:03:09] 2) We need to separate the HEAD (send no data) function from the size indication 3) We need to provide the end-points with hints on when to send this and when not. Hum: (1) WG should work on this: some hum (2) Not sure: some hum (3) Objections: no hum =20 =20 6. Request timeout (Kepeng Li) Milliseconds or mibiseconds: Mibisectonds Cabo:=20 =A1=A4 I like the basic approach =A1=A4 We cold misuse timeout=3D0 as HEAD Zach: I am not convinced we need this. It is better to see implementations Linyi: This is similar to Accept header. It is the recommendation for the timeout. If it is not supported, it can just be ignored. =20 7. Building Control (Peter) Zach: I think the idea of forcing the sensors in the group to have the same path should be carefully considered. An alternative way is to have a proxy in between. Peter: Put the proxy in between will cause delay. Ed: Where the DNS server is? Who is administrative it in that scenario? Kerry: In commercial applications, you can delegate DNS resource. Anders: For large buildings you will have administrative DNS server. Kerry: It is also possible to add DNS records in existing DNS. =20 8. Bootstrapping (Yoshihiro) Oscar has some suggestions. =20 9. CoAP securety (Jari) Yoshihiro=A3=BA This identity is the client device identity. Consider the mutua= l authentication, how this can be done? Hennes: The different trust model leads to different solutions. This is the application layer solution. I am wondering how this can form a big picture for different trust models in terms of standardization. Jari: We are proposing architecture that provides a practical, minimal-configuration approach to smart object security. Jari clarified the proposal is mainly on the provision part. Cheers, Linyi --Boundary_(ID_zKv+4Xz9ASuDsAArdlI6Lw) Content-type: text/html; charset=GB2312 Content-transfer-encoding: quoted-printable
Hi, Core Folks

= Here is the minutes I took during this afternoon meeting. I am not sure whet= her this is the worst minutes you ever seen in Core:)

Minutes f= or Core (Wednesday Afternoon)

1. Charte= r Review

Peter sug= gested it maybe reasonable to allow several months work on block draft.

Linyi sug= gested it make sense to merge the size option draft into block draft if it is acce= pted as WG item.

&nbs= p;

&nbs= p;

2. Core R= esource Directory Draft (Zach)

There is = a related EU project SENSI (2008-2010) for this feature.

Hannes Tschofenig:

=A1=A4    &= nbsp; Which part will be standardized in the RD architecture? There is different IOP ne= ed in different parts.

=A1=A4    &n= bsp; Is the interface between the RDS and sensor or device? What does client means?=

Kepeng Li= :

=A1=A4    &= nbsp; Can we achieve partially update, from the syntax, it seems to be difficult;

=A1=A4    &n= bsp; Does it have influence to the link-format document, because it is mentioned in t= he ppt

&nbs= p;

3. DNS-Ba= sed Service Discovery (Kerry Lynn)

Kepeng: S= hould this be informational?

No other = serious issues were raised.

&nbs= p;

4. Group Communication (Akbar)

Kerry: xx= xx (was not captured, sorry)

It was pr= oposed to have application multicast, why now we changed to IP layer multicast?

Akbar: We= investigated the different options: IP Multicast, Overlay Multicast and CoA= P Application Level Group Management. Finally we come to the conclusion that = we should just do IP Multicast.

Zach: Do = you think that multicast will cause congestion control? In the base spec, we ha= ve already used IP multicast.

&nbs= p;

5. Size O= ption (Kepeng Li)

cabo:

=A1=A4      I like the basic approach
[20:02:16] <cabo> 1) I like the basic approach
[20:02:53] *** kepeng_li\40jabber.org (kepeng_li@jabber.org/4290206ceb1e85d= e) has left the room
[20:03:09] <cabo> 2) We need to separate the HEAD (send no data) function from the size indication
3) We need to provide the end-points with hints on when to send this and wh= en not.

[20:03:09] <cabo> 2) We need to separate the HEAD (send no data) function from the size indication
3) We need to provide the end-points with hints on when to send this and when not.

Hum:=

(1) WG sh= ould work on this: some hum

(2) Not s= ure: some hum

(3) Objec= tions: no hum

&nbs= p;

&nbs= p;

6. Reques= t timeout (Kepeng Li)

Milliseco= nds or mibiseconds: Mibisectonds

Cabo:

=A1=A4    &= nbsp; I like the basic approach

=A1=A4    &n= bsp; We cold misuse timeout=3D0 as HEAD

Zach: I a= m not convinced we need this. It is better to see implementations

Linyi: Th= is is similar to Accept header. It is the recommendation for the timeout. If it i= s not supported, it can just be ignored.

&nbs= p;

7. Buildi= ng Control (Peter)

Zach: I t= hink the idea of forcing the sensors in the group to have the same path should be carefully considered. An alternative way is to have a proxy in between.

Peter: Pu= t the proxy in between will cause delay.

Ed: Where= the DNS server is? Who is administrative it in that scenario?

=

Kerry: In= commercial applications, you can delegate DNS resource. <= /p>

Anders: F= or large buildings you will have administrative DNS server.

Kerry: It= is also possible to add DNS records in existing DNS.

&nbs= p;

8. Bootst= rapping (Yoshihiro)

Oscar has= some suggestions.

&nbs= p;

9. CoAP s= ecurety (Jari)

Yoshihiro= =A3=BA This identity is the client de= vice identity. Consider the mutual authentication, how this can be done?

Hennes: T= he different trust model leads to different solutions. This is the application= layer solution. I am wondering how this can form a big picture for differen= t trust models in terms of standardization. =

Jari: We = are proposing architecture that provides a practical, minimal-configuration approach to smart object security.

Jari clar= ified the proposal is mainly on the provision part. 


Cheers,
Linyi
--Boundary_(ID_zKv+4Xz9ASuDsAArdlI6Lw)-- From samita.chakrabarti@ericsson.com Thu Jul 28 13:53:14 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 3CC8121F8B3E for ; Thu, 28 Jul 2011 13:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.662 X-Spam-Level: X-Spam-Status: No, score=-6.662 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 514n+7kZMcN3 for ; Thu, 28 Jul 2011 13:53:13 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id B9DFB21F8B38 for ; Thu, 28 Jul 2011 13:53:13 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p6SKrAZB031693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 28 Jul 2011 15:53:13 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.121]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 28 Jul 2011 16:53:11 -0400 From: Samita Chakrabarti To: "core@ietf.org" Date: Thu, 28 Jul 2011 16:53:09 -0400 Thread-Topic: Pointer to energy-aware-nd draft Thread-Index: AcxNaFvQLrrbtoszTN27bpNAnI1hXw== Message-ID: <16D60F43CA0B724F8052D7E9323565D71E6737376F@EUSAACMS0715.eamcs.ericsson.se> 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_16D60F43CA0B724F8052D7E9323565D71E6737376FEUSAACMS0715e_" MIME-Version: 1.0 Subject: [core] Pointer to energy-aware-nd draft 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: Thu, 28 Jul 2011 20:53:14 -0000 --_000_16D60F43CA0B724F8052D7E9323565D71E6737376FEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As per Cullen's and Jari's request, here is the pointer to the recent energ= y-aware-nd document to minimize the multicast periodic messages by doing re= gistration at the default router. This is the first version of the draft an= d the next revision will have some more changes to fit it to generic IPv6 s= cenarios. http://tools.ietf.org/html/draft-chakrabarti-nordmark-energy-aware-nd-00 -Samita --_000_16D60F43CA0B724F8052D7E9323565D71E6737376FEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
As per Cu= llen's and=20 Jari's request, here is the pointer to the recent energy-aware-nd docu= ment=20 to minimize the multicast periodic messages by doing registration at the de= fault=20 router. This is the first version of the draft and the next revision will h= ave=20 some more changes to fit it to generic IPv6 scenarios.
 
http://tools.ietf.org/html/draft-chakrabarti-nordmark-energy-aware-n= d-00
 
-Samita
 
--_000_16D60F43CA0B724F8052D7E9323565D71E6737376FEUSAACMS0715e_-- From angelo.castellani@gmail.com Thu Jul 28 15:19:27 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 D7D3E21F885C for ; Thu, 28 Jul 2011 15:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.777 X-Spam-Level: X-Spam-Status: No, score=-3.777 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 hVtnsaoe3uj9 for ; Thu, 28 Jul 2011 15:19:27 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5444C21F87BC for ; Thu, 28 Jul 2011 15:19:27 -0700 (PDT) Received: by qwc23 with SMTP id 23so2083400qwc.31 for ; Thu, 28 Jul 2011 15:19:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=Sume0/vWGVLy2qRFrDd6vpCxkzgweEw/ndzGUjf7W84=; b=bUhcMNb7PuUulPOlTFWDM3JjEpYwDUn5WHHCACvoFvPICNooQjmrHDU9JzpHp5afVe 8mgWJSLnGuctDtHQudvoK/fjXNK0c23thooLGXJ7Zsdrcr2ADYEz8+9ttYNnHqHOXi4Z sj8CAmxvDywt5DnONJi5TVw4AbJJ/Y8I/HCpE= Received: by 10.229.224.75 with SMTP id in11mr428497qcb.211.1311891550080; Thu, 28 Jul 2011 15:19:10 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.229.233.209 with HTTP; Thu, 28 Jul 2011 15:18:50 -0700 (PDT) From: "Angelo P. Castellani" Date: Thu, 28 Jul 2011 18:18:50 -0400 X-Google-Sender-Auth: 3i0lIVVAj5-Guo6hYzfsJ57kan8 Message-ID: To: core Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] Small glitch in coap-07 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: Thu, 28 Jul 2011 22:19:27 -0000 In Section 8.2.2 of coap-07 there is written: If the CoAP entity has an entity tag, the proxy SHOULD include an ETag Option in the response and process ETag Options in requests as described below. However there is no further text below regarding ETags. Best, Angelo