From trac+core@trac.tools.ietf.org Fri Nov 2 01:58:49 2012 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 76FCF21F98DE for ; Fri, 2 Nov 2012 01:58:49 -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 qtpT4RuF+M5y for ; Fri, 2 Nov 2012 01:58:49 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id DADC921F98D8 for ; Fri, 2 Nov 2012 01:58:48 -0700 (PDT) Received: from localhost ([127.0.0.1]:57788 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TUD5D-0002n0-1P; Fri, 02 Nov 2012 09:58:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, zach@sensinode.com X-Trac-Project: core Date: Fri, 02 Nov 2012 08:58:30 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/246#comment:1 Message-ID: <066.7d7ea6452f83f065ade56e9d3e03784a@trac.tools.ietf.org> References: <051.c0be34405f3e5e5cab4565e76bf12039@trac.tools.ietf.org> X-Trac-Ticket-ID: 246 In-Reply-To: <051.c0be34405f3e5e5cab4565e76bf12039@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.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 grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: brian@skyfoundry.com, cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20121102085848.DADC921F98D8@ietfa.amsl.com> Resent-Date: Fri, 2 Nov 2012 01:58:48 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #246: Estimation of Leisure 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, 02 Nov 2012 08:58:49 -0000 #246: Estimation of Leisure Changes (by zach@…): * status: new => closed * resolution: => fixed -- -----------------------------+------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-coap@… Type: other technical | Status: closed Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: coap-09 Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+------------------------------------- Ticket URL: core From zach@sensinode.com Fri Nov 2 02:20:50 2012 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 1DF8021F9973 for ; Fri, 2 Nov 2012 02:20:50 -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 D+1wO8AvonKS for ; Fri, 2 Nov 2012 02:20:49 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0F021F9933 for ; Fri, 2 Nov 2012 02:20:48 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id qA29KjTt014350; Fri, 2 Nov 2012 11:20:46 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <031DD135F9160444ABBE3B0C36CED618AFBE78@011-DB3MPN2-082.MGDPHG.emi.philips.com> Date: Fri, 2 Nov 2012 11:20:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8AFA0CA2-F37E-4A25-AD4C-8E863A9FFD0B@sensinode.com> References: <031DD135F9160444ABBE3B0C36CED618AFBE04@011-DB3MPN2-082.MGDPHG.emi.philips.com> <1D48EEB1-8B66-4D82-97E7-AC3B6C7F944D@sensinode.com> <031DD135F9160444ABBE3B0C36CED618AFBE78@011-DB3MPN2-082.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org" Subject: Re: [core] Scalability of multicast use for discovery (ticket #247) 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, 02 Nov 2012 09:20:50 -0000 Coming back to the solution for this ticket. I would like to propose the = following in the WG meeting next week: 1. Change the IPv4 request to the Local Network Control Block. Although = we could ask for the Ad-Hoc Block I think Local Network is sufficient = for our discovery needs in IPv4. 2. Change the IPv6 request to link-local and site-local scope only. Here = we need site-local scope due to the way 6LoWPAN networks are typically = built.=20 3. Recommend the use application specific multicast addresses for larger = scope multicast needs. Regarding the security consideration, with these changes I think the = existing text in 11.4 is sufficient.=20 If this is OK with the WG, then we can make the needed changes in -13 = and then update our IANA registration request accordingly.=20 Zach On Oct 18, 2012, at 10:27 AM, Dijk, Esko wrote: > I agree, since the CoRE discovery use cases seem to be all for = link-local or site-local scope multicast. >=20 > For the IPv4 address assignment, there's no site-local IPv4 but = looking at the IANA registry = (http://www.iana.org/assignments/multicast-addresses/multicast-addresses.x= ml#multicast-addresses-3 ) it looks somewhat like the ad-hoc block I = (224.0.2.0 - 224.0.255.255) has taken on this function? Since there are = some recent additions of single addresses in there. > Alternatively we only register link-local for IPv4. >=20 > Esko >=20 > -----Original Message----- > From: Zach Shelby [mailto:zach@sensinode.com]=20 > Sent: Thursday 18 October 2012 9:05 > To: Dijk, Esko > Cc: core@ietf.org > Subject: Re: [core] Scalability of multicast use for discovery (ticket = #247) >=20 > Esko, >=20 > On Oct 18, 2012, at 9:07 AM, Dijk, Esko wrote: >=20 >> Dear all, >>=20 >> to explore possible solutions to ticket #247 = (http://trac.tools.ietf.org/wg/core/trac/ticket/247) in the WG here are = some initial ideas. >>=20 >> To enable safe use of multicast for CoAP discovery; we could include = in core-coap stricter requirements on multicast responding e.g.: >>=20 >> - for site-local scope or any smaller scope, a discovery multicast = request (/.well-known/core) by an unauthenticated client MAY be = responded to by a server >> - for organization-local and global scope, a discovery multicast = request by an unauthenticated client SHOULD NOT be responsed to >> - for global scope, a discovery multicast request SHOULD NOT be = responded to. Exception case is a server known to be deployed in an = isolated network i.e. multicast not propagating onto the internet or to = multicast backbones. In that case the server MUST be explicitly = configured to do so. >=20 > This is not just about discovery, but for responding to any multicast = CoAP request.=20 >=20 > I start to be doubtful about the actual utility of the CoAP multicast = address with global scope (the risks are much greater than the benefit). = To be safer, and deal with the IANA comments completely, we could just = limit the default CoAP multicast address to local and site-local scope = only. For specialized applications where global scope could be useful, = it would be better for that application to use a dedicated multicast = address for that purpose.=20 >=20 > Zach >=20 >> This would allow local multicast discovery (of servers previously = unknown to the client) use cases without the side effects that the IANA = appointed expert mentions. >>=20 >> regards, >> Esko >>=20 >>=20 >> Esko Dijk >>=20 >> Philips Group Innovation, Research >> High Tech Campus 34, Eindhoven, The Netherlands >> esko.dijk@philips.com >>=20 >>=20 >>=20 >> The information contained in this message may be confidential and = legally protected under applicable law. The message is intended solely = for the addressee(s). If you are not the intended recipient, you are = hereby notified that any use, forwarding, dissemination, or reproduction = of this message is strictly prohibited and may be unlawful. If you are = not the intended recipient, please contact the sender by return e-mail = and destroy all copies of the original message. >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=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 >=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 From trac+core@trac.tools.ietf.org Fri Nov 2 02:21:27 2012 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 0467A21F9973 for ; Fri, 2 Nov 2012 02:21:27 -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 1lSUGKqASkLZ for ; Fri, 2 Nov 2012 02:21:26 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 599CF21F9933 for ; Fri, 2 Nov 2012 02:21:26 -0700 (PDT) Received: from localhost ([127.0.0.1]:59759 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TUDR2-0000Jx-Pp; Fri, 02 Nov 2012 10:21:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, esko.dijk@philips.com, zach@sensinode.com X-Trac-Project: core Date: Fri, 02 Nov 2012 09:21:04 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/247#comment:3 Message-ID: <075.18764006332af2e0718671b5046c2878@trac.tools.ietf.org> References: <060.165feff053c11cfa0d65de452eb53ed9@trac.tools.ietf.org> X-Trac-Ticket-ID: 247 In-Reply-To: <060.165feff053c11cfa0d65de452eb53ed9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, esko.dijk@philips.com, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: brian@skyfoundry.com, cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20121102092126.599CF21F9933@ietfa.amsl.com> Resent-Date: Fri, 2 Nov 2012 02:21:26 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #247: Scalability questions IANA review for IPv6/IPv4 multicast address request X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 09:21:27 -0000 #247: Scalability questions IANA review for IPv6/IPv4 multicast address request Comment (by zach@…): Coming back to the solution for this ticket. I would like to propose the following in the WG meeting next week: 1. Change the IPv4 request to the Local Network Control Block. Although we could ask for the Ad-Hoc Block I think Local Network is sufficient for our discovery needs in IPv4. 2. Change the IPv6 request to link-local and site-local scope only. Here we need site-local scope due to the way 6LoWPAN networks are typically built. 3. Recommend the use application specific multicast addresses for larger scope multicast needs. Regarding the security consideration, with these changes I think the existing text in 11.4 is sufficient. If this is OK with the WG, then we can make the needed changes in -13 and then update our IANA registration request accordingly. -- -----------------------------+------------------------------------- Reporter: esko.dijk@… | Owner: draft-ietf-core-coap@… Type: protocol defect | Status: new Priority: major | Milestone: post-WGLC-1 Component: coap | Version: Severity: - | Resolution: Keywords: | -----------------------------+------------------------------------- Ticket URL: core From jara@um.es Fri Nov 2 03:52:27 2012 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 5250D21F9750 for ; Fri, 2 Nov 2012 03:52:27 -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 pUQuYp3lIwrZ for ; Fri, 2 Nov 2012 03:52:26 -0700 (PDT) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7C421F9727 for ; Fri, 2 Nov 2012 03:52:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 398745D581; Fri, 2 Nov 2012 11:52:24 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AWATtlaRdWLe; Fri, 2 Nov 2012 11:52:23 +0100 (CET) Received: from localhost (ursus13.um.es [155.54.212.233]) by xenon14.um.es (Postfix) with ESMTP id 2C3DC5D591; Fri, 2 Nov 2012 11:52:22 +0100 (CET) Received: from mdc-wsg-3.utc.com (mdc-wsg-3.utc.com [192.249.47.203]) by webmail.atica.um.es (Horde Framework) with HTTP; Fri, 02 Nov 2012 11:52:22 +0100 Message-ID: <20121102115222.15844vkxp8y3r6qu@webmail.atica.um.es> Date: Fri, 02 Nov 2012 11:52:22 +0100 From: Antonio Jara To: Zach Shelby References: <031DD135F9160444ABBE3B0C36CED618AFBE04@011-DB3MPN2-082.MGDPHG.emi.philips.com> <1D48EEB1-8B66-4D82-97E7-AC3B6C7F944D@sensinode.com> <031DD135F9160444ABBE3B0C36CED618AFBE78@011-DB3MPN2-082.MGDPHG.emi.philips.com> <8AFA0CA2-F37E-4A25-AD4C-8E863A9FFD0B@sensinode.com> In-Reply-To: <8AFA0CA2-F37E-4A25-AD4C-8E863A9FFD0B@sensinode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.2) Cc: "core@ietf.org" Subject: Re: [core] Scalability of multicast use for discovery (ticket #247) 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, 02 Nov 2012 10:52:27 -0000 Hi Zach, Maybe, it could be interesting to ask also to IANA some predefinition of multicast addresses for CoAP devices: Variable scope to find all the CoAP devices (similar to other technologies e.g. BACnet). 1- CoAP // e.g. FF0X:0:0:0:0:0:0:C0A7 Note that, it s is also considering the local and site scopes: 1- Local CoAP Devices // e.g. FF02:0:0:0:0:0:0:C0A7 2- Site CoAP Devices // e.g. FF05:0:0:0:0:0:0:C0A7 7 is because looks like "P" in HEX. In addition, it could be considered the options for CoAP RD. 1- Local CoAP Resource Directories (Browsing) // e.g. FF02:0:0:0:0:0:0:C0AB 2- Site CoAP Resource Directories (Browsing) // e.g. FF05:0:0:0:0:0:0:C0AB B is because the browsing, commonly used in mDNSv6 (FB). Best regards, Antonio J. Jara Quoting Zach Shelby : > Coming back to the solution for this ticket. I would like to propose > the following in the WG meeting next week: > > 1. Change the IPv4 request to the Local Network Control Block. > Although we could ask for the Ad-Hoc Block I think Local Network is > sufficient for our discovery needs in IPv4. > 2. Change the IPv6 request to link-local and site-local scope only. > Here we need site-local scope due to the way 6LoWPAN networks are > typically built. > 3. Recommend the use application specific multicast addresses for > larger scope multicast needs. > > Regarding the security consideration, with these changes I think the > existing text in 11.4 is sufficient. > > If this is OK with the WG, then we can make the needed changes in > -13 and then update our IANA registration request accordingly. > > Zach > > On Oct 18, 2012, at 10:27 AM, Dijk, Esko wrote: > >> I agree, since the CoRE discovery use cases seem to be all for >> link-local or site-local scope multicast. >> >> For the IPv4 address assignment, there's no site-local IPv4 but >> looking at the IANA registry >> (http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xml#multicast-addresses-3 ) it looks somewhat like the ad-hoc block I (224.0.2.0 - 224.0.255.255) has taken on this function? Since there are some recent additions of single addresses in >> there. >> Alternatively we only register link-local for IPv4. >> >> Esko >> >> -----Original Message----- >> From: Zach Shelby [mailto:zach@sensinode.com] >> Sent: Thursday 18 October 2012 9:05 >> To: Dijk, Esko >> Cc: core@ietf.org >> Subject: Re: [core] Scalability of multicast use for discovery (ticket #247) >> >> Esko, >> >> On Oct 18, 2012, at 9:07 AM, Dijk, Esko wrote: >> >>> Dear all, >>> >>> to explore possible solutions to ticket #247 >>> (http://trac.tools.ietf.org/wg/core/trac/ticket/247) in the WG >>> here are some initial ideas. >>> >>> To enable safe use of multicast for CoAP discovery; we could >>> include in core-coap stricter requirements on multicast responding >>> e.g.: >>> >>> - for site-local scope or any smaller scope, a discovery multicast >>> request (/.well-known/core) by an unauthenticated client MAY be >>> responded to by a server >>> - for organization-local and global scope, a discovery multicast >>> request by an unauthenticated client SHOULD NOT be responsed to >>> - for global scope, a discovery multicast request SHOULD NOT be >>> responded to. Exception case is a server known to be deployed in >>> an isolated network i.e. multicast not propagating onto the >>> internet or to multicast backbones. In that case the server MUST >>> be explicitly configured to do so. >> >> This is not just about discovery, but for responding to any >> multicast CoAP request. >> >> I start to be doubtful about the actual utility of the CoAP >> multicast address with global scope (the risks are much greater >> than the benefit). To be safer, and deal with the IANA comments >> completely, we could just limit the default CoAP multicast address >> to local and site-local scope only. For specialized applications >> where global scope could be useful, it would be better for that >> application to use a dedicated multicast address for that purpose. >> >> Zach >> >>> This would allow local multicast discovery (of servers previously >>> unknown to the client) use cases without the side effects that the >>> IANA appointed expert mentions. >>> >>> regards, >>> Esko >>> >>> >>> Esko Dijk >>> >>> Philips Group Innovation, Research >>> High Tech Campus 34, Eindhoven, The Netherlands >>> esko.dijk@philips.com >>> >>> >>> >>> 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 >> >> -- >> 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 >> >> > > -- > 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 > From barryleiba.mailing.lists@gmail.com Fri Nov 2 10:29:11 2012 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 1655021F8E46 for ; Fri, 2 Nov 2012 10:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.095 X-Spam-Level: X-Spam-Status: No, score=-103.095 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbtRK1m+cS6G for ; Fri, 2 Nov 2012 10:29:10 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id DC18B21F8E45 for ; Fri, 2 Nov 2012 10:29:09 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so3023772lbo.31 for ; Fri, 02 Nov 2012 10:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=CNr5aGNmv2Y1ElwKnqETMcKIyPBpaZXa83aDIAcqi9M=; b=SuuSZfpuvM0Mc4ir+uOHMBjhaFeWlDy1/XQnF56DnjUv+C/L9d7sv6eNEbnvx4KuiD jJt+PNMhS7RlfPe7djCIsNuhHTg+fqkljMRC9fIO3/6jA7xm290/O6I9gyb2A3UTOopB 5Cq3+Uf+1rOe1fjWwmZoys3obhzB+eImT8ire+6fp5iUUhX96RfAI8NgWwDDQv3LuFAI sHRQRJCl24Zx7PMzzQgyXaAIHJnDHLLdfMyc9hDSKP8O/dgiqv93fV4F6d3e+hQbth0k kU2poQktYc6nrUgR6/1mNd6gZHfPYUcJ9gyM5MCm5Ib97tSqYzyZQEAOEdxKSiGCpOBM yMlQ== MIME-Version: 1.0 Received: by 10.152.114.100 with SMTP id jf4mr2275602lab.47.1351877348724; Fri, 02 Nov 2012 10:29:08 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.99.131 with HTTP; Fri, 2 Nov 2012 10:29:08 -0700 (PDT) Date: Fri, 2 Nov 2012 13:29:08 -0400 X-Google-Sender-Auth: t-ZjWhGFVs1zHtckH-8VHVQ2-hg Message-ID: From: Barry Leiba To: "core@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1 Subject: [core] Mail to Carsten bouncing? 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, 02 Nov 2012 17:29:11 -0000 Carsten, I just got a bounce from trying to send mail to the chairs. This came from one of the IETF tools servers (grenache.tools.ietf.org): ------------------------------- cabo@tzi.org (generated from app-chairs@tools.ietf.org) SMTP error from remote mail server after RCPT TO:: host mailhost.informatik.uni-bremen.de [2001:638:708:30c9::12]: 550 5.7.1 ... Access denied. IP name lookup failed [IPv6:2a01:3f0:1:2:225:90ff:fe34:720e] - Please fix your DNS server and resend ------------------------------- Barry From cabo@tzi.org Fri Nov 2 20:00:19 2012 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 7073621F9B59 for ; Fri, 2 Nov 2012 20:00:19 -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 Z3Fr7DgUjufE for ; Fri, 2 Nov 2012 20:00:18 -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 8AD5D21F9B4C for ; Fri, 2 Nov 2012 20:00:18 -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 qA3303On009404; Sat, 3 Nov 2012 04:00:04 +0100 (CET) Received: from dhcp-4161.meeting.ietf.org (unknown [130.129.65.97]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 18C0B43B; Sat, 3 Nov 2012 04:00:02 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Fri, 2 Nov 2012 22:59:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <951F12DA-C201-4CC7-8DD8-639DCE9AB11F@tzi.org> References: To: Barry Leiba X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] Mail to Carsten bouncing? 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, 03 Nov 2012 03:00:19 -0000 On Nov 2, 2012, at 13:29, Barry Leiba wrote: > Carsten, I just got a bounce from trying to send mail to the chairs. >=20 > This came from one of the IETF tools servers = (grenache.tools.ietf.org): > ------------------------------- > cabo@tzi.org > (generated from app-chairs@tools.ietf.org) > SMTP error from remote mail server after RCPT TO:: > host mailhost.informatik.uni-bremen.de [2001:638:708:30c9::12]: > 550 5.7.1 ... Access denied. IP name lookup failed > [IPv6:2a01:3f0:1:2:225:90ff:fe34:720e] - Please fix your DNS server > and resend > ------------------------------- Yes, Henrik occasionally has trouble with the IPv6 PTR setup behind the = hosting of (some of?) the tools servers, and some spam management setups = (including that at my university, sorry about that) just don't take = E-mail from addresses with bad PTRs. So I'm notifying him again... Non-tools E-mail does seem to reach me (in spades). Gr=FC=DFe, Carsten From trac+core@trac.tools.ietf.org Sat Nov 3 11:41:57 2012 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 1E7BA21F9CBF for ; Sat, 3 Nov 2012 11:41:57 -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=[AWL=0.000, 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 rHpWG6vDzd0S for ; Sat, 3 Nov 2012 11:41:56 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD9621F9C8A for ; Sat, 3 Nov 2012 11:41:12 -0700 (PDT) Received: from localhost ([127.0.0.1]:48291 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TUieP-0003PU-1C; Sat, 03 Nov 2012 19:40:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-block@tools.ietf.org, hartke@tzi.org, cabo@tzi.org X-Trac-Project: core Date: Sat, 03 Nov 2012 18:40:57 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/205#comment:2 Message-ID: <066.d517a98530fb84a6e47d0f81a077134a@trac.tools.ietf.org> References: <051.9b5708494f8201a3ec752fc23da47723@trac.tools.ietf.org> X-Trac-Ticket-ID: 205 In-Reply-To: <051.9b5708494f8201a3ec752fc23da47723@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-block@tools.ietf.org, hartke@tzi.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, zach@sensinode.com Resent-Message-Id: <20121103184112.8AD9621F9C8A@ietfa.amsl.com> Resent-Date: Sat, 3 Nov 2012 11:41:12 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #205: Clarify that Size does not modify the request semantics beyond adding the size information 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: Sat, 03 Nov 2012 18:41:57 -0000 #205: Clarify that Size does not modify the request semantics beyond adding the size information Changes (by cabo@…): * status: new => closed * resolution: => fixed Comment: Fix as laid out above was applied in block-10. (Forgot to close this.) -- -----------------------------+-------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-block@… Type: editorial | Status: closed Priority: minor | Milestone: post-WGLC-1 Component: block | Version: block-08 Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+-------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sat Nov 3 11:48:20 2012 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 0FE4521F8DAA for ; Sat, 3 Nov 2012 11:48:20 -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 jYH0hGFs3zwF for ; Sat, 3 Nov 2012 11:48:19 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE2A21F8D5A for ; Sat, 3 Nov 2012 11:48:19 -0700 (PDT) Received: from localhost ([127.0.0.1]:49053 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TUilG-0000mk-JT; Sat, 03 Nov 2012 19:48:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: cabo@tzi.org, hartke@tzi.org X-Trac-Project: core Date: Sat, 03 Nov 2012 18:48:02 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/210#comment:2 Message-ID: <066.87089a9c407064fb7e985b02999b54fa@trac.tools.ietf.org> References: <051.d904ee0bea6c59be24fc5a28e7e8cf18@trac.tools.ietf.org> X-Trac-Ticket-ID: 210 In-Reply-To: <051.d904ee0bea6c59be24fc5a28e7e8cf18@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: cabo@tzi.org, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #210: Disentangle Block and Token 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: Sat, 03 Nov 2012 18:48:20 -0000 #210: Disentangle Block and Token Changes (by cabo@…): * owner: draft-ietf-core-block@… => cabo@… * status: new => assigned * type: protocol defect => editorial Comment: Modified this to an editorial ticket: -- the technical changes have been made in block-10, and -- we now just need to make sure that all editorial repercussions are covered. -- -----------------------------+-------------------------- Reporter: cabo@… | Owner: cabo@… Type: editorial | Status: assigned Priority: major | Milestone: post-WGLC-1 Component: block | Version: block-08 Severity: In WG Last Call | Resolution: Keywords: | -----------------------------+-------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sat Nov 3 11:55:36 2012 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 651C021F9C7D for ; Sat, 3 Nov 2012 11:55:36 -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=[AWL=0.000, 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 A0otvhCtNG4G for ; Sat, 3 Nov 2012 11:55:35 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id B2C2921F9C6A for ; Sat, 3 Nov 2012 11:55:35 -0700 (PDT) Received: from localhost ([127.0.0.1]:49911 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TUisE-0004UG-C8; Sat, 03 Nov 2012 19:55:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-block@tools.ietf.org, hartke@tzi.org, cabo@tzi.org X-Trac-Project: core Date: Sat, 03 Nov 2012 18:55:14 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/206#comment:2 Message-ID: <066.c64f8a4bff5f394290e98fef7888ac61@trac.tools.ietf.org> References: <051.965a95dc46e1afb12f7d1a12aed61bdf@trac.tools.ietf.org> X-Trac-Ticket-ID: 206 In-Reply-To: <051.965a95dc46e1afb12f7d1a12aed61bdf@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-block@tools.ietf.org, hartke@tzi.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, zach@sensinode.com Resent-Message-Id: <20121103185535.B2C2921F9C6A@ietfa.amsl.com> Resent-Date: Sat, 3 Nov 2012 11:55:35 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #206: Clarify that atomic Block1 transfers match per token *and* endpoint 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: Sat, 03 Nov 2012 18:55:36 -0000 #206: Clarify that atomic Block1 transfers match per token *and* endpoint Comment (by cabo@…): Some editorial work remains even after the main issue is covered by #210 and block-10: The last paragraph of 2.4 is the only one in block-10 to mention the importance of the endpoint. So some additional text is still needed to indicate that servers that run buffered transfers (e.g., for atomic semantics) will allocate them per endpoint. -- -----------------------------+-------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-block@… Type: editorial | Status: new Priority: major | Milestone: post-WGLC-1 Component: block | Version: block-08 Severity: In WG Last Call | Resolution: Keywords: | -----------------------------+-------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sun Nov 4 14:54:07 2012 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 EF90C21F862D for ; Sun, 4 Nov 2012 14:54:07 -0800 (PST) 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=[AWL=0.000, 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 rv80U3czOO81 for ; Sun, 4 Nov 2012 14:54:07 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5FB21F8604 for ; Sun, 4 Nov 2012 14:54:07 -0800 (PST) Received: from localhost ([127.0.0.1]:39418 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TV94h-0002cp-OR; Sun, 04 Nov 2012 23:53:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Sun, 04 Nov 2012 22:53:51 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/252 Message-ID: <060.21265d28244400dba1ada3082dcb036a@trac.tools.ietf.org> X-Trac-Ticket-ID: 252 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20121104225407.6C5FB21F8604@ietfa.amsl.com> Resent-Date: Sun, 4 Nov 2012 14:54:07 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #252: Conflicting security requirements in groupcomm/core-coap 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: Sun, 04 Nov 2012 22:54:08 -0000 #252: Conflicting security requirements in groupcomm/core-coap Conflicting security requirements: core-coap-12: "CoAP servers SHOULD NOT accept multicast requests that can not be authenticated". groupcomm-03: "Group communications MUST operate in CoAP NoSec (No Security) mode" Should be resolved perhaps in either groupcomm, core-coap, or both? -- --------------------------------+----------------------------------------- Reporter: esko.dijk@… | Owner: draft-ietf-core-groupcomm@… Type: protocol defect | Status: new Priority: major | Milestone: Component: groupcomm | Version: Severity: Active WG Document | Keywords: --------------------------------+----------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sun Nov 4 18:50:49 2012 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 5C21C21F8916 for ; Sun, 4 Nov 2012 18:50:49 -0800 (PST) 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 EBGu+3y2gpYT for ; Sun, 4 Nov 2012 18:50:48 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 5099321F8924 for ; Sun, 4 Nov 2012 18:50:48 -0800 (PST) Received: from localhost ([127.0.0.1]:33083 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TVCln-0008Dg-7R; Mon, 05 Nov 2012 03:50:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-block@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 05 Nov 2012 02:50:35 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/253 Message-ID: <051.6211cf307a6c1c0ca7695e53d5349711@trac.tools.ietf.org> X-Trac-Ticket-ID: 253 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-block@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, zach@sensinode.com Resent-Message-Id: <20121105025048.5099321F8924@ietfa.amsl.com> Resent-Date: Sun, 4 Nov 2012 18:50:48 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #253: Block2 vs. Initiative (Don't call us, we'll call you) 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: Mon, 05 Nov 2012 02:50:49 -0000 #253: Block2 vs. Initiative (Don't call us, we'll call you) In the (still unpublished) editorial rewrite, I'm trying to make one aspect of the behavior of Block2 more explicit than it is in the current draft (block-10, with some details also in Section 6 of observe-07). With Block1, it is always the initiative of the client to send the next block -- which is quite natural, as the client has to generate them and therefore knows when it's time to send the next block. With Block2, we support the basic case of a stateless resource on a server by keeping the initiative with the client as well. Then there are a couple of (currently less than perfectly defined) cases where the initiative switches to the server: Combinations of Block 1 and Block2 (ticket #203), and block-wise observe notifications (section 6 of observe-07). One of the objectives of block-11 is to describe the cases for server-side Block initiative in a more clearly defined, understandable way. Up to now I thought that this is all we need to do about this. Klaus Hartke points out that there are other cases where server-side initiative may be desirable. In particular, with buffered transfers (i.e., the server is setting up a cached copy of the resource to serve blocks from), server-side initiative is more natural. One design principle of CoAP is that we give the server the flexibility to do what best fits the application. So, whether the initiative for a Block2 transfer is with the client as with Block1 or with the server should be decided by the server. If we allow that, instead of using the current rules, the client needs to know the outcome of the decision of the server -- otherwise, a request for the next block from the client would likely cross the next block being sent independently from the server. This means that the server needs a way to say "Don't call us, we'll call you" when sending the first block of a block-wise response (Block2). Implementing this in the protocol poses a number of less important questions (which still need to be decided). Let's call this information "the initiative bit" for know (leaving open whether that is realized by a separate option or by changing Block2). Clearly, the default value of that bit needs to be "client-side", as we want to support the basic, stateless server case without any additional fluff. 1) Do we need to make the "server-side" value explicit for the two cases where it already is server-side (or do we keep it implicit that the presence of a Block1 or Observe option in a response indicates server-side initiative)? Making it explicit creates another breaking change and adds redundant information to a message, but may seem more "consistent". 2) Does a client need a way to influence the server side decision, expressing a preference or even prohibiting one choice? I don't think that is actually needed; the server is likely to implement only one way anyway. There may also be some work required on the potential of using server-side initiative for carrying out amplification attacks. While amplification attacks are possible with many UDP-based protocols (right now, the favorite of the black-hat community appears to be DNS), the attractiveness of a protocol increases with the amplification factors achievable. Being able to achieve amplification factors beyond those of DNS makes a protocol very attractive. (covers msg02890, #203, nits13m, nits13n) -- ----------------------------------+------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-block@… Type: protocol enhancement | Status: new Priority: major | Milestone: post-WGLC-1 Component: block | Version: block-10 Severity: Active WG Document | Keywords: ----------------------------------+------------------------------------- Ticket URL: core From henrik@levkowetz.com Sat Nov 3 05:32:01 2012 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 542BB21F9C68 for ; Sat, 3 Nov 2012 05:32:01 -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 BjbDO4-Uv1V6 for ; Sat, 3 Nov 2012 05:32:00 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [IPv6:2a01:3f0:0:31::14]) by ietfa.amsl.com (Postfix) with ESMTP id 916A321F9C67 for ; Sat, 3 Nov 2012 05:31:59 -0700 (PDT) Received: from [130.129.84.30] (port=57333 helo=dhcp-541e.meeting.ietf.org) by merlot.tools.ietf.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.77) (envelope-from ) id 1TUcsx-0003R2-5W; Sat, 03 Nov 2012 13:31:36 +0100 Message-ID: <50950E9A.8020500@levkowetz.com> Date: Sat, 03 Nov 2012 08:31:22 -0400 From: Henrik Levkowetz User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.10) Gecko/20121024 Thunderbird/10.0.10 MIME-Version: 1.0 To: Carsten Bormann References: <951F12DA-C201-4CC7-8DD8-639DCE9AB11F@tzi.org> In-Reply-To: <951F12DA-C201-4CC7-8DD8-639DCE9AB11F@tzi.org> X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig45790E38FB4326B71918E1A0" X-SA-Exim-Connect-IP: 130.129.84.30 X-SA-Exim-Rcpt-To: cabo@tzi.org, barryleiba@computer.org, core@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:57:07 +0000) X-SA-Exim-Scanned: Yes (on merlot.tools.ietf.org) X-Mailman-Approved-At: Mon, 05 Nov 2012 08:03:46 -0800 Cc: Barry Leiba , "core@ietf.org WG" Subject: Re: [core] Mail to Carsten bouncing? 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, 03 Nov 2012 12:32:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig45790E38FB4326B71918E1A0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Carsten, On 2012-11-02 22:59 Carsten Bormann said the following: > On Nov 2, 2012, at 13:29, Barry Leiba wrote: >=20 >> Carsten, I just got a bounce from trying to send mail to the chairs. >>=20 >> This came from one of the IETF tools servers (grenache.tools.ietf.org)= : >> ------------------------------- >> cabo@tzi.org >> (generated from app-chairs@tools.ietf.org) >> SMTP error from remote mail server after RCPT TO:: >> host mailhost.informatik.uni-bremen.de [2001:638:708:30c9::12]: >> 550 5.7.1 ... Access denied. IP name lookup failed >> [IPv6:2a01:3f0:1:2:225:90ff:fe34:720e] - Please fix your DNS server >> and resend >> ------------------------------- >=20 > Yes, Henrik occasionally has trouble with the IPv6 PTR setup behind the= hosting of (some of?) the tools servers, and some spam management setups= (including that at my university, sorry about that) just don't take E-ma= il from addresses with bad PTRs. So I'm notifying him again... >=20 > Non-tools E-mail does seem to reach me (in spades). These days, all the 3 servers have reverses for the IPv6 addresses, but I found that for some reason, Exim on one of the machines is using the EUI-48 address instead of the explicitly assigned IPv6 address for outgoing mail. I've earlier told it to not even have the EUI-address assigned to the interface (in /etc/network/interfaces) but now I again see that address on the interface... I've zapped it, and will try to figure out what could have made it appear again... Best regards, Henrik --------------enig45790E38FB4326B71918E1A0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iEUEARECAAYFAlCVDqIACgkQeVhrtTJkXCPMCgCgveW/Jv1h69eSSmvSEb6cAqK4 7pgAmOcjuYukEmi9yHUHbbziq3/obQM= =vOcz -----END PGP SIGNATURE----- --------------enig45790E38FB4326B71918E1A0-- From trac+core@trac.tools.ietf.org Mon Nov 5 10:48:35 2012 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 545C621F8510 for ; Mon, 5 Nov 2012 10:48:35 -0800 (PST) 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 aOfP3Jyuu3DD for ; Mon, 5 Nov 2012 10:48:34 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4B921F87EF for ; Mon, 5 Nov 2012 10:48:34 -0800 (PST) Received: from localhost ([127.0.0.1]:40364 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TVRib-0002fJ-6C; Mon, 05 Nov 2012 19:48:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: cabo@tzi.org X-Trac-Project: core Date: Mon, 05 Nov 2012 18:48:17 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/245#comment:1 Message-ID: <066.60c01a05acae794e7420a0bf0d5c5535@trac.tools.ietf.org> References: <051.25002bcbb00ea4e0153e473b6ddf6c60@trac.tools.ietf.org> X-Trac-Ticket-ID: 245 In-Reply-To: <051.25002bcbb00ea4e0153e473b6ddf6c60@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #245: Compression vs. Block 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: Mon, 05 Nov 2012 18:48:35 -0000 #245: Compression vs. Block Changes (by cabo@…): * owner: draft-ietf-core-block@… => cabo@… * status: new => assigned Comment: Assuming that there is no further discussion, I'll reflect this clarification in clap-11. -- -----------------------------+-------------------------- Reporter: cabo@… | Owner: cabo@… Type: other technical | Status: assigned Priority: minor | Milestone: post-WGLC-1 Component: block | Version: block-08 Severity: In WG Last Call | Resolution: Keywords: | -----------------------------+-------------------------- Ticket URL: core From hartke@tzi.org Mon Nov 5 11:09:36 2012 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 A268821F8443 for ; Mon, 5 Nov 2012 11:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, 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 8zdeG374ZzDX for ; Mon, 5 Nov 2012 11:09:36 -0800 (PST) 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 3093221F8432 for ; Mon, 5 Nov 2012 11:09:28 -0800 (PST) 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 qA5J9LIU017160 for ; Mon, 5 Nov 2012 20:09:21 +0100 (CET) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E6F7A35D for ; Mon, 5 Nov 2012 20:09:20 +0100 (CET) Received: by mail-pa0-f44.google.com with SMTP id fb11so4140088pad.31 for ; Mon, 05 Nov 2012 11:09:19 -0800 (PST) Received: by 10.68.218.97 with SMTP id pf1mr32942682pbc.96.1352142559069; Mon, 05 Nov 2012 11:09:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.156.238 with HTTP; Mon, 5 Nov 2012 11:08:58 -0800 (PST) In-Reply-To: <066.60c01a05acae794e7420a0bf0d5c5535@trac.tools.ietf.org> References: <051.25002bcbb00ea4e0153e473b6ddf6c60@trac.tools.ietf.org> <066.60c01a05acae794e7420a0bf0d5c5535@trac.tools.ietf.org> From: Klaus Hartke Date: Mon, 5 Nov 2012 21:08:58 +0200 Message-ID: To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] #245: Compression vs. Block 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, 05 Nov 2012 19:09:37 -0000 > The intention is to transfer the content-coded representation, > which is sliced up in blocks. Isn't one use-case of -block the retrieval of a part/slice of a representation without necessarily retrieving all parts? How does a client decompress such a slice? Or is the use-case not applicable for compressed representations? Klaus From cabo@tzi.org Mon Nov 5 11:25:16 2012 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 6DD5B21F84F3 for ; Mon, 5 Nov 2012 11:25:15 -0800 (PST) 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 SuKECGKNbcZD for ; Mon, 5 Nov 2012 11:25:14 -0800 (PST) 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 C5F1621F84D2 for ; Mon, 5 Nov 2012 11:25:08 -0800 (PST) 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 qA5JP1ln024866 for ; Mon, 5 Nov 2012 20:25:02 +0100 (CET) Received: from dhcp-9336.meeting.ietf.org (dhcp-9336.meeting.ietf.org [130.129.11.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4CE47375; Mon, 5 Nov 2012 20:25:01 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Mon, 5 Nov 2012 14:24:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8A51C6AB-E451-4C1B-AA1E-797E69F9E101@tzi.org> References: <051.25002bcbb00ea4e0153e473b6ddf6c60@trac.tools.ietf.org> <066.60c01a05acae794e7420a0bf0d5c5535@trac.tools.ietf.org> To: Klaus Hartke X-Mailer: Apple Mail (2.1499) Cc: core@ietf.org Subject: Re: [core] #245: Compression vs. Block 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, 05 Nov 2012 19:25:16 -0000 On Nov 5, 2012, at 14:08, Klaus Hartke wrote: >> The intention is to transfer the content-coded representation, >> which is sliced up in blocks. >=20 > Isn't one use-case of -block the retrieval of a part/slice of a > representation without necessarily retrieving all parts? How does a > client decompress such a slice? Or is the use-case not applicable for > compressed representations? There are indeed compression schemes that allow you to independently = work with slices of a larger data item. Unfortunately, these typically require some flexibility in the size of = the compressed slice to remain efficient. -block doesn't have that: Everything is a power of two. So if you need = to do this, -block is a bad match. I'd expect you are better off using URI parameters to select the slice = then. But I don't know a specific use case*) for that, so I can't discuss this = very intelligently. Gr=FC=DFe, Carsten *) apart from compressed paging, but I don't think this is very relevant = here. From trac+core@trac.tools.ietf.org Mon Nov 5 17:11:22 2012 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 EED2311E80AE for ; Mon, 5 Nov 2012 17:11:21 -0800 (PST) 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=[AWL=0.000, 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 P6xsqiQJUgDt for ; Mon, 5 Nov 2012 17:11:21 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 2686D21F8687 for ; Mon, 5 Nov 2012 17:11:21 -0800 (PST) Received: from localhost ([127.0.0.1]:48209 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TVXh3-0004xX-EV; Tue, 06 Nov 2012 02:11:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, zach@sensinode.com X-Trac-Project: core Date: Tue, 06 Nov 2012 01:11:05 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/254 Message-ID: <057.ec774322b67c4c328255575fa02402bb@trac.tools.ietf.org> X-Trac-Ticket-ID: 254 X-SA-Exim-Connect-IP: 127.0.0.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 grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: brian@skyfoundry.com, cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20121106011121.2686D21F8687@ietfa.amsl.com> Resent-Date: Mon, 5 Nov 2012 17:11:21 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #254: Max-Age MUST IMPLEMENT for proxies 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, 06 Nov 2012 01:11:22 -0000 #254: Max-Age MUST IMPLEMENT for proxies Cullen Jennings notes (msg03072au): Section 5.10 Imagine a proxy that does not understand Max-Age. The server sends a response to proxy with Max-Age of 10 seconds. The proxy does not understand this so it removes this. Now the client that made the request to the proxy things the Max-Age in the response is 60 seconds. This seems broken - am I missing something about how this works? -- -----------------------------+------------------------------------ Reporter: zach@… | Owner: draft-ietf-core-coap@… Type: other technical | Status: new Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: coap-12 Severity: In WG Last Call | Keywords: -----------------------------+------------------------------------ Ticket URL: core From trac+core@trac.tools.ietf.org Mon Nov 5 17:22:19 2012 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 BE26511E80C5 for ; Mon, 5 Nov 2012 17:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, 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 88psvZlRVka2 for ; Mon, 5 Nov 2012 17:22:19 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 2887F11E80B8 for ; Mon, 5 Nov 2012 17:22:19 -0800 (PST) Received: from localhost ([127.0.0.1]:48989 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TVXrj-0003d7-J4; Tue, 06 Nov 2012 02:22:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Tue, 06 Nov 2012 01:22:07 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/255 Message-ID: <057.2ba8550a3f0f2269f9c67df979775e71@trac.tools.ietf.org> X-Trac-Ticket-ID: 255 X-SA-Exim-Connect-IP: 127.0.0.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 grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #255: Authority Name issues with SNI and X.509 certificate 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, 06 Nov 2012 01:22:19 -0000 #255: Authority Name issues with SNI and X.509 certificate Thomas Fossati notes (msg03022): Section 10.1.3. says: The Authority Name in the certificate is the name that would be used in the Authority part of a CoAP URI. So it seems that a 'host [":" port]' syntax is to be assumed as Authority Name, which gets quickly furry, both WRT the use of it in a certificate (A.), and in the SNI extension (B.). A. The Authority Name should go into the subjectAltName in the X.509 certificate, typically one of 'dNSName' or 'iPAddress' is used when certificates are bound to hosts. But there is no room for the '[":" port]' there, so none of them can be used in the general case. One could then fall back on 'otherName', but then an OID needs to be registered to allow a minimum degree of interop. The same, or worse, applies to the case where EUI-64 is used. B. RFC 6066 imposes the following restrictions on the server name format: - "the only server names supported are DNS hostnames" - "Literal IPv4 and IPv6 addresses are not permitted in HostName so, the claim "Devices SHOULD support the Server Name Indication (SNI) to indicate their Authority Name in the SNI HostName" seems not completely consistent with RFC 6066. Luckily "other name types may be added in the future (by an RFC that updates this document)" but then we have to provide this new name format for use in SNI for CoAP endpoints. As a side note, the text in 10.1.3.: It is worth noting that this [the authority part of a CoAP URI] would typically not be either an IP address or DNS name but would instead be a long term unique identifier for the device such as the EUI-64 is not consistent with the host production in RFC 3986 (i.e. host = IP- literal / IPv4address / reg-name), unless we want to go all the way to IPvFuture :-) Solution: Define how CoAP uses SNI in Certificates as per RFC6125. -- -----------------------------+------------------------- Reporter: zach@… | Owner: zach@… Type: other technical | Status: new Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: coap-12 Severity: In WG Last Call | Keywords: -----------------------------+------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Nov 5 17:23:14 2012 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 03F4D21F84FC for ; Mon, 5 Nov 2012 17:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 Q5D9Kbq05K+Q for ; Mon, 5 Nov 2012 17:23:13 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 5B95321F84EC for ; Mon, 5 Nov 2012 17:23:13 -0800 (PST) Received: from localhost ([127.0.0.1]:49113 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TVXsg-0007Hs-C3; Tue, 06 Nov 2012 02:23:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Tue, 06 Nov 2012 01:23:06 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/255#comment:1 Message-ID: <072.b3385e5c750266ca33bcfe6ab1d87550@trac.tools.ietf.org> References: <057.2ba8550a3f0f2269f9c67df979775e71@trac.tools.ietf.org> X-Trac-Ticket-ID: 255 In-Reply-To: <057.2ba8550a3f0f2269f9c67df979775e71@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.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 grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #255: Authority Name issues with SNI and X.509 certificate 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, 06 Nov 2012 01:23:14 -0000 #255: Authority Name issues with SNI and X.509 certificate Comment (by zach@…): (nit12d) Esko Dijk notes: Section 9.1.3.3 The Authority Name in the certificate is the name that would be used in the Authority part of a CoAP URI. It is worth noting that this would typically not be either an IP address or DNS name but would instead be a long term unique identifier for the device such as the EUI-64 Don't understand this part. The authority of a CoAP URI would typically be an IP address or DNS name. Or is this mentioning another type of CoAP URI than are normally used. -- -----------------------------+-------------------------- Reporter: zach@… | Owner: zach@… Type: other technical | Status: new Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: coap-12 Severity: In WG Last Call | Resolution: Keywords: | -----------------------------+-------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Nov 5 17:47:17 2012 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 9368511E80C5 for ; Mon, 5 Nov 2012 17:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 ctoQuo2BqDr1 for ; Mon, 5 Nov 2012 17:47:16 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1BC11E80A5 for ; Mon, 5 Nov 2012 17:47:16 -0800 (PST) Received: from localhost ([127.0.0.1]:51119 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TVYFo-0004bO-I2; Tue, 06 Nov 2012 02:47:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, zach@sensinode.com X-Trac-Project: core Date: Tue, 06 Nov 2012 01:47:00 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/256 Message-ID: <057.a275d4eab7b92af3040f5be8e8fd5844@trac.tools.ietf.org> X-Trac-Ticket-ID: 256 X-SA-Exim-Connect-IP: 127.0.0.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 grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: brian@skyfoundry.com, cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20121106014716.7B1BC11E80A5@ietfa.amsl.com> Resent-Date: Mon, 5 Nov 2012 17:47:16 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #256: Caching text needs to be updated 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, 06 Nov 2012 01:47:17 -0000 #256: Caching text needs to be updated Klaus Hartke notes: Section 5.6 all options match between those in the presented request and those of the request used to obtain the stored response (which includes the request URI), except that there is no need for a match of the Token, Max-Age, or ETag request option(s), or any request options marked as NoCacheKey (Section 5.4), and This is not entirely true, as the ETag request option may be part of the cache key as well: We have two places where we can define the properties of an option: in the RFC, and in the option number. If a proxy recognises the ETag Option, then its caching behaviour is defined in the RFC: the proxy determines if the ETag identifies a fresh response and returns either 2.03 (Valid) or not. If a proxy does not recognise the ETag Option, we have the choice if it's safe to forward it, or not. If it's not safe to forward, then the proxy removes it, makes the request towards the destination, stores the result in its cache, and returns the response to the client. But if it is safe to forward, then the server makes the request towards the destination *with* the ETag Option, stores the result in its cache, and returns the response to the client. The proxy can use the response to satisfy later requests only if these have the same ETag Option, because the origin server could have returned a different response for a different ETag Option value. So the option number must indicate to caches that do not recognise the ETag Option that it is part of the cache-key. So the text in Section 5.6 needs to be rephrased and brought in line with Section 5.4.2. -- -----------------------------+------------------------------------ Reporter: zach@… | Owner: draft-ietf-core-coap@… Type: editorial | Status: new Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: coap-12 Severity: In WG Last Call | Keywords: -----------------------------+------------------------------------ Ticket URL: core From trac+core@trac.tools.ietf.org Tue Nov 6 03:30:30 2012 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 1E7D121F87A3 for ; Tue, 6 Nov 2012 03:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 BEF+V6QyEHay for ; Tue, 6 Nov 2012 03:30:29 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 7633A21F879B for ; Tue, 6 Nov 2012 03:30:29 -0800 (PST) Received: from localhost ([127.0.0.1]:49580 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TVhMB-0007kJ-0e; Tue, 06 Nov 2012 12:30:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Tue, 06 Nov 2012 11:30:10 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/257 Message-ID: <051.bfa8620fef2432adf8e7cc19532dcb39@trac.tools.ietf.org> X-Trac-Ticket-ID: 257 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: brian@skyfoundry.com, cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20121106113029.7633A21F879B@ietfa.amsl.com> Resent-Date: Tue, 6 Nov 2012 03:30:29 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #257: URI references and multicast requests 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, 06 Nov 2012 11:30:30 -0000 #257: URI references and multicast requests Klaus Hartke notes: Section 8 When a client performs a Multicast GET and receives one or more resource representations that contain URI references, it is not clear what the Retrieval URI is (see ). - Is it the request URI with the multicast address? - Is it the related unicast request URI? How does the client learn the host name of the node? Proposal: For the purposes of defaulting a base URI, construct a unicast retrieval URI by replacing the multicast address by a literal built from the IP address taken from the response endpoint address. -- -----------------------------+------------------------------------ Reporter: cabo@… | Owner: draft-ietf-core-coap@… Type: other technical | Status: new Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: coap-11 Severity: In WG Last Call | Keywords: -----------------------------+------------------------------------ Ticket URL: core From trac+core@trac.tools.ietf.org Tue Nov 6 03:49:02 2012 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 E22A721F8862 for ; Tue, 6 Nov 2012 03:49:02 -0800 (PST) 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 T4vuxiCceeiD for ; Tue, 6 Nov 2012 03:49:02 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 101C521F8842 for ; Tue, 6 Nov 2012 03:49:02 -0800 (PST) Received: from localhost ([127.0.0.1]:51459 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TVheB-00007X-SW; Tue, 06 Nov 2012 12:48:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-observe@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Tue, 06 Nov 2012 11:48:47 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/258 Message-ID: <051.3c984165effb92092dc532973c01ed03@trac.tools.ietf.org> X-Trac-Ticket-ID: 258 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: hartke@tzi.org Resent-Message-Id: <20121106114902.101C521F8842@ietfa.amsl.com> Resent-Date: Tue, 6 Nov 2012 03:49:02 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #258: Be explicit about the "observe key" 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, 06 Nov 2012 11:49:03 -0000 #258: Be explicit about the "observe key" Matthias Kovatsch notes (msg03748b): Section 5 Because a client (or an intermediary in the client role) can only be once in the list of observers of a resource at a server (or an intermediary in the server role) -- it is useless to observe the same resource multiple times -- an intermediary MUST observe a resource only once, even if there are multiple clients for which it observes the resource. What about different content-types/accept options? An intermediary must be able to serve them if they are supported by the origin server. But if they cannot be converted, the intermediary can only use observing for one content-type. Maybe the observe list entry should also be dependent on the content-type? Proposal: 1) Explicitly define which options go into the key that separates one observation relationship from another; include the URI and Accept. (What else?) 2) It will be hard to "merge" observation relationships on the server that lead to the same content-format (e.g., overlapping Accept options); this will require some client (proxy) action upon receiving the first response. (We do promise that the Content-Format will not change.) Add this as an implementation note. -- -----------------------------+--------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-observe@… Type: other technical | Status: new Priority: minor | Milestone: post-WGLC-1 Component: observe | Version: observe-07 Severity: In WG Last Call | Keywords: -----------------------------+--------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Tue Nov 6 04:13:06 2012 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 7DD1D21F88B9 for ; Tue, 6 Nov 2012 04:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 fO3q+Vstgp1X for ; Tue, 6 Nov 2012 04:13:04 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id B800F21F88C4 for ; Tue, 6 Nov 2012 04:13:04 -0800 (PST) Received: from localhost ([127.0.0.1]:54124 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TVi1R-0004DK-6T; Tue, 06 Nov 2012 13:12:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Tue, 06 Nov 2012 12:12:49 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/259 Message-ID: <051.b150c522197456646133cd1bca831535@trac.tools.ietf.org> X-Trac-Ticket-ID: 259 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: brian@skyfoundry.com, cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20121106121304.B800F21F88C4@ietfa.amsl.com> Resent-Date: Tue, 6 Nov 2012 04:13:04 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #259: Standardize a workaround for HTTP library limitations in talking to forward HTTP-COAP cross-proxies? 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, 06 Nov 2012 12:13:06 -0000 #259: Standardize a workaround for HTTP library limitations in talking to forward HTTP-COAP cross-proxies? Cullen Jennings notes (msg03072bu): Section 8 - I tried passing a COAP URL in a HTTP request line of various libraries, firewalls, and other tools. In theory it might work, but my observation is that in practice, it does not. I'm not sure how to fix this. One possible solution is making a way to translate well know http URL into a coap URL. So for example, the translator proxy that received an HTTP request like http://www.proxy.com/.wellknonw/core-translate/1.2.3.4_4567/foo/bar?a=3 would translate that to coap://1.2.3.4:4567/foo/bar?a=3 If we did something like this, your standard web libraries running on things like google app engine could make REST calls to the proxy that resulted in a request to the CoAP device. Perhaps you think this approach is the reverse proxy approach but one way or another, I can see how to get the current solution working very well in practice. Solution: Defining such a workaround mapping (carrying a CoAP URI "in" a URI) is straightforward (with a little bike-shedding needed). Do we do this in core-coap or separately? -- -----------------------------+------------------------------------ Reporter: cabo@… | Owner: draft-ietf-core-coap@… Type: other technical | Status: new Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: coap-09 Severity: In WG Last Call | Keywords: -----------------------------+------------------------------------ Ticket URL: core From tho@koanlogic.com Tue Nov 6 05:25:22 2012 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 8E1BE21F84D3 for ; Tue, 6 Nov 2012 05:25:22 -0800 (PST) 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 l8o+JE2PRVgy for ; Tue, 6 Nov 2012 05:25:22 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 195A221F8476 for ; Tue, 6 Nov 2012 05:25:21 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so298278qca.31 for ; Tue, 06 Nov 2012 05:25:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=RgzmsezVZEhGgCbo+/YhBkJqk8Y23yDYuNpzehTw9VM=; b=AR6SJgaj323GRjB1dDxRJsCBzuQCv0s3yEGkX789Tq1YDAcextWBa4T2DB5eUTOPsP OT7zSejAp+Rozszd2xAubEBjIldMKYw+oqZnBpZFQowVHkq3nxxk/wrqKsUT8xek9lF2 VsM36yIuT9ocD1OKgF/MWjzSmz9Sye6V6Dit6yaJr/V6+opyJwJAON1l74qA7OAVIlRZ Yr+XQfl10Ndzksdi0X2CzIYlah6O9WKT/9JbnQGMUihIFwUrla+xeVzX9qoFrSv2pqdQ DJCcPnYG3y+SRlYCUhPpR/eMj15FwW3KxlecALdqmQK8f7GhQFpKrOGEWmPW1AgmKUKm yf/g== MIME-Version: 1.0 Received: by 10.224.109.7 with SMTP id h7mr1489336qap.78.1352208321341; Tue, 06 Nov 2012 05:25:21 -0800 (PST) Received: by 10.49.71.10 with HTTP; Tue, 6 Nov 2012 05:25:21 -0800 (PST) X-Originating-IP: [81.134.152.4] In-Reply-To: References: <051.b150c522197456646133cd1bca831535@trac.tools.ietf.org> Date: Tue, 6 Nov 2012 13:25:21 +0000 Message-ID: From: Thomas Fossati To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlLjIMtRhxS7TE+ynkHDQkzJVGlzki+3lus8Std6eli+MATWR5iDQXwvn1kLGLi2pabqffS Subject: Re: [core] #259: Standardize a workaround for HTTP library limitations in talking to forward HTTP-COAP cross-proxies? 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, 06 Nov 2012 13:25:22 -0000 On Tue, Nov 6, 2012 at 12:12 PM, core issue tracker wrote: > #259: Standardize a workaround for HTTP library limitations in talking to forward > HTTP-COAP cross-proxies? Re to this, I've added a feature request to HTML5: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19582 to let browsers configure their HTTP-CoAP forward proxy via the registerProtocolHandler API. Maybe worth doing some lobbying in this direction ? From trac+core@trac.tools.ietf.org Tue Nov 6 05:41:36 2012 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 A8C7121F88C3 for ; Tue, 6 Nov 2012 05:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 X19WYHuh2Yo1 for ; Tue, 6 Nov 2012 05:41:36 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 19FEA21F88AF for ; Tue, 6 Nov 2012 05:41:36 -0800 (PST) Received: from localhost ([127.0.0.1]:33922 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TVjP6-0004zn-Fw; Tue, 06 Nov 2012 14:41:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, zach@sensinode.com X-Trac-Project: core Date: Tue, 06 Nov 2012 13:41:20 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/244#comment:1 Message-ID: <066.c844ad385a013aef9df87af74a1d480d@trac.tools.ietf.org> References: <051.5337030b6167f7bbffd876418e412f61@trac.tools.ietf.org> X-Trac-Ticket-ID: 244 In-Reply-To: <051.5337030b6167f7bbffd876418e412f61@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.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 grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: brian@skyfoundry.com, cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20121106134136.19FEA21F88AF@ietfa.amsl.com> Resent-Date: Tue, 6 Nov 2012 05:41:36 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #244: max-age vs. network latency and retransmissions 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, 06 Nov 2012 13:41:36 -0000 #244: max-age vs. network latency and retransmissions Changes (by zach@…): * status: new => closed * resolution: => fixed -- -----------------------------+------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-coap@… Type: other technical | Status: closed Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: coap-09 Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Tue Nov 6 05:54:43 2012 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 1036621F8905 for ; Tue, 6 Nov 2012 05:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 neL7HRtPPFKr for ; Tue, 6 Nov 2012 05:54:42 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 53A2B21F88FC for ; Tue, 6 Nov 2012 05:54:42 -0800 (PST) Received: from localhost ([127.0.0.1]:35235 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TVjbr-0005CW-0D; Tue, 06 Nov 2012 14:54:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Tue, 06 Nov 2012 13:54:30 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/260 Message-ID: <057.29d11a717740777bc743bea492a89bf9@trac.tools.ietf.org> X-Trac-Ticket-ID: 260 X-SA-Exim-Connect-IP: 127.0.0.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 grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #260: IANA Policy Review 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, 06 Nov 2012 13:54:43 -0000 #260: IANA Policy Review This ticket is to perform a review on all our IANA policy decisions in this draft, update, and then get feedback from IANA. -- --------------------+------------------------- Reporter: zach@… | Owner: zach@… Type: task | Status: new Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: coap-12 Severity: - | Keywords: --------------------+------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Tue Nov 6 05:57:35 2012 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 CC1DC21F8689 for ; Tue, 6 Nov 2012 05:57:35 -0800 (PST) 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 iqG-BrSMjpfB for ; Tue, 6 Nov 2012 05:57:35 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 2A18021F866B for ; Tue, 6 Nov 2012 05:57:35 -0800 (PST) Received: from localhost ([127.0.0.1]:35716 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TVjek-0006qY-KS; Tue, 06 Nov 2012 14:57:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Tue, 06 Nov 2012 13:57:30 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/261 Message-ID: <057.11b9a385ad96122a62f1e35a84bb4cd5@trac.tools.ietf.org> X-Trac-Ticket-ID: 261 X-SA-Exim-Connect-IP: 127.0.0.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 grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #261: SHOULD Review 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, 06 Nov 2012 13:57:35 -0000 #261: SHOULD Review The coap-12 specification has 70 instances of SHOULD. Also many of the still outstanding 1st WGLC nits are related to SHOULD adjustment. -- --------------------+------------------------- Reporter: zach@… | Owner: zach@… Type: task | Status: new Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: coap-12 Severity: - | Keywords: --------------------+------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Tue Nov 6 06:14:13 2012 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 C5AC021F881E for ; Tue, 6 Nov 2012 06:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 vBM9F0fgWI3m for ; Tue, 6 Nov 2012 06:14:12 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id DA86A21F87A6 for ; Tue, 6 Nov 2012 06:14:05 -0800 (PST) Received: from localhost ([127.0.0.1]:37510 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TVjuZ-0004oO-N7; Tue, 06 Nov 2012 15:13:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Tue, 06 Nov 2012 14:13:51 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/262 Message-ID: <051.722e5df3abf1190252374b63910bdfae@trac.tools.ietf.org> X-Trac-Ticket-ID: 262 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: brian@skyfoundry.com, cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20121106141405.DA86A21F87A6@ietfa.amsl.com> Resent-Date: Tue, 6 Nov 2012 06:14:05 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #262: Split out IPsec details into a separate draft 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, 06 Nov 2012 14:14:13 -0000 #262: Split out IPsec details into a separate draft Cullen Jennings notes (msg03072c): Section 10.2 I'm wondering what parts of text around IPSec really need to be in the draft? I'm having a hard time finding anywhere where it has any normative impact. (This is now section 9.2 in coap-12.) Proposal: From the point of view of CoAP, there is indeed little normative text that interfaces to IPsec at this point. There is some work to do, e.g. msg03024, and there is little implementation experience. The remaining issues might receive better attention when they are exposed in their own draft instead of buried in the main CoAP specification. -- -----------------------------+------------------------------------ Reporter: cabo@… | Owner: draft-ietf-core-coap@… Type: other technical | Status: new Priority: major | Milestone: post-WGLC-1 Component: coap | Version: coap-12 Severity: In WG Last Call | Keywords: -----------------------------+------------------------------------ Ticket URL: core From cabo@tzi.org Tue Nov 6 06:25:15 2012 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 3DE8321F8862 for ; Tue, 6 Nov 2012 06:25:15 -0800 (PST) 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 N6MXUKgWB8e7 for ; Tue, 6 Nov 2012 06:25:14 -0800 (PST) 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 7A31921F8721 for ; Tue, 6 Nov 2012 06:25:14 -0800 (PST) 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 qA6EP4vo028181 for ; Tue, 6 Nov 2012 15:25:04 +0100 (CET) Received: from dhcp-9336.meeting.ietf.org (dhcp-9336.meeting.ietf.org [130.129.11.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B3346883; Tue, 6 Nov 2012 15:25:03 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Nov 2012 09:25:00 -0500 To: "core@ietf.org WG" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [core] IETF85: Slide set posted 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, 06 Nov 2012 14:25:15 -0000 A first set of slides is in: http://www.ietf.org/proceedings/85/slides/slides-85-core-0.pdf There is a bit more entropy in the slide preparation for this meeting = than usual... There will be updates; please reload often. See you all at 13:00... Gr=FC=DFe, Carsten From kovatsch@inf.ethz.ch Tue Nov 6 08:32:07 2012 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 374D421F86E4 for ; Tue, 6 Nov 2012 08:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 2ZCg6tCXRHft for ; Tue, 6 Nov 2012 08:32:06 -0800 (PST) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 77BA821F86B3 for ; Tue, 6 Nov 2012 08:32:06 -0800 (PST) Received: from CAS11.d.ethz.ch (172.31.38.211) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 6 Nov 2012 17:31:53 +0100 Received: from MBX10.d.ethz.ch ([fe80::6d7b:f3da:a5b1:c9e9]) by CAS11.d.ethz.ch ([fe80::ecc9:4e2d:b26b:1614%10]) with mapi id 14.02.0298.004; Tue, 6 Nov 2012 17:31:57 +0100 From: "Kovatsch Matthias" To: Thomas Fossati , "core@ietf.org" Thread-Topic: [core] #259: Standardize a workaround for HTTP library limitations in talking to forward HTTP-COAP cross-proxies? Thread-Index: AQHNvCIrAd+Q4LzJZEGZINMcvTNy7Zfc/XhQ Date: Tue, 6 Nov 2012 16:31:57 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514D02409@MBX10.d.ethz.ch> References: <051.b150c522197456646133cd1bca831535@trac.tools.ietf.org> In-Reply-To: Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.9.88] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [core] #259: Standardize a workaround for HTTP library limitations in talking to forward HTTP-COAP cross-proxies? 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, 06 Nov 2012 16:32:07 -0000 > to let browsers configure their HTTP-CoAP forward proxy via the > registerProtocolHandler API. >=20 >=20 > Maybe worth doing some lobbying in this direction ? I already had a longer e-mail discussion with Ian Hickson after IETF 83 on = this. The consensus was that we will have to convince the browser vendors and bri= ng up a solid security model, as "Application X wants to access device Y"-l= isting might not scale. When I talked to Patrick McManus from Mozilla Firefox at last IETF, he was = quite positive about integrating CoAP directly into the browser. They are a= lready integrating DTLS 1.2 for RTCWeb (not scriptable so far, though)... Unfortunately, I do not have the time to work on a patch that brings a C++ = CoAP implementation to Firefox. Patrick said that would be a good first ste= p to get CoAP integration started... I am planning, though, to extend my Copper Firefox extension, so that peopl= e can use a CoapRequest object similar to the XMLHttpRequest object in Web = applications, or even provide a unified REST object API (XHR is still very = soapy..). This might also be a good demo to convince people. Help and input on this would be very welcome! Ciao Matthias From tho@koanlogic.com Tue Nov 6 08:59:34 2012 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 3768521F8628 for ; Tue, 6 Nov 2012 08:59:34 -0800 (PST) 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 q62L8xmZ-0+G for ; Tue, 6 Nov 2012 08:59:33 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD6421F85C4 for ; Tue, 6 Nov 2012 08:59:33 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so467948qca.31 for ; Tue, 06 Nov 2012 08:59:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=qn6KTSG4UEcGniWr15JZnlg6Q1CORFkFYEbkS5myqfk=; b=EsYe/g9Yp8TXmEReIuPEweiTZ/9GRV2DOSMkpdu/cuo2oZYCOO3ibU28XrEdfWuFI7 NPTu5fyosz4h4VQmC5WU2ICnsbpqdlKpPvAr6PmTwh41O2Y04lRdVvpDwzvX1VNn72Y/ 8fqPYZ0xkfM7oOIwb9k6WDZt4zk6AT2DkdRQN4g+wyJAGGvxrFBkLLe+KqEpMrYqGJUA 9J1BoTjd2XuebyyFw+Cr6cqNHPJcghlNjdTuCGMJVLdwvys4VvXgXTZwHcbhbR1UJpcv NX5N5awHR4wB39siEE7T59DmEipyRpk1dULRXHI+cSQREiE6RCS+xPkzU5lOZym8nqqz YNRw== MIME-Version: 1.0 Received: by 10.224.223.19 with SMTP id ii19mr2560508qab.74.1352221171450; Tue, 06 Nov 2012 08:59:31 -0800 (PST) Received: by 10.49.71.10 with HTTP; Tue, 6 Nov 2012 08:59:31 -0800 (PST) X-Originating-IP: [81.134.152.4] In-Reply-To: <55877B3AFB359744BA0F2140E36F52B514D02409@MBX10.d.ethz.ch> References: <051.b150c522197456646133cd1bca831535@trac.tools.ietf.org> <55877B3AFB359744BA0F2140E36F52B514D02409@MBX10.d.ethz.ch> Date: Tue, 6 Nov 2012 16:59:31 +0000 Message-ID: From: Thomas Fossati To: Kovatsch Matthias Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmrbUwQQ3g/eeIOewQZ2FGjixo3CPGOJgcn77pRj4KuG5ZTLG9IGdOoI0Vm966Pqge1de/R Cc: core@ietf.org Subject: Re: [core] #259: Standardize a workaround for HTTP library limitations in talking to forward HTTP-COAP cross-proxies? 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, 06 Nov 2012 16:59:34 -0000 Hi Matthias, On Tue, Nov 6, 2012 at 4:31 PM, Kovatsch Matthias wrote: > I already had a longer e-mail discussion with Ian Hickson after IETF 83 on this. my scenario is: a web application needs mashing up both CoAP and HTTP resources in one single page. On download/startup it asks the user to registerProtocolHandler() for a given HTTP-CoAP proxy under its control. If user agrees, native CoAP resources can be interacted via HTTP back and forth the translating gateway. Another web application could do the same but with a different HTTP-CoAP proxy in another tab at the same time. It seems pretty scalable to me. And the security model is the usual one in the browser world, asking the user to opt in for a specific capability. Also, since the browser speaks plain HTTP with the HTTP-CoAP proxy, there's no need to integrate the CoAP bits in Mozilla or whatever. Am I missing something ? From cabo@tzi.org Tue Nov 6 09:40:24 2012 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 4179021F8A63 for ; Tue, 6 Nov 2012 09:40:24 -0800 (PST) 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 l4pP9IRwf+3t for ; Tue, 6 Nov 2012 09:40:23 -0800 (PST) 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 00EE321F8A69 for ; Tue, 6 Nov 2012 09:40:22 -0800 (PST) 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 qA6HeEOW025729 for ; Tue, 6 Nov 2012 18:40:14 +0100 (CET) Received: from dhcp-9336.meeting.ietf.org (dhcp-9336.meeting.ietf.org [130.129.11.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5CFF29DB; Tue, 6 Nov 2012 18:40:14 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Carsten Bormann In-Reply-To: Date: Tue, 6 Nov 2012 12:40:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <41B4D852-C24B-4877-8522-295095E9B380@tzi.org> References: To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1499) Subject: Re: [core] IETF85: Slide set posted 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, 06 Nov 2012 17:40:24 -0000 Updated for Tuesday meeting (in 20 minutes). Gr=FC=DFe, Carsten On Nov 6, 2012, at 09:25, Carsten Bormann wrote: > A first set of slides is in: >=20 > http://www.ietf.org/proceedings/85/slides/slides-85-core-0.pdf >=20 > There is a bit more entropy in the slide preparation for this meeting = than usual... > There will be updates; please reload often. >=20 > See you all at 13:00... >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From kovatsch@inf.ethz.ch Tue Nov 6 12:57:38 2012 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 AB85121F8B18 for ; Tue, 6 Nov 2012 12:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=-1.000, 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 SsYGkPbIiPiA for ; Tue, 6 Nov 2012 12:57:38 -0800 (PST) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id 77C0921F85D8 for ; Tue, 6 Nov 2012 12:57:36 -0800 (PST) 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.2.298.4; Tue, 6 Nov 2012 21:57:21 +0100 Received: from MBX10.d.ethz.ch ([fe80::6d7b:f3da:a5b1:c9e9]) by CAS20.d.ethz.ch ([fe80::2cd8:4907:7776:c56d%10]) with mapi id 14.02.0298.004; Tue, 6 Nov 2012 21:57:21 +0100 From: "Kovatsch Matthias" To: Thomas Fossati Thread-Topic: [core] #259: Standardize a workaround for HTTP library limitations in talking to forward HTTP-COAP cross-proxies? Thread-Index: AQHNvCIrAd+Q4LzJZEGZINMcvTNy7Zfc/XhQ///5rYCAABFCgA== Date: Tue, 6 Nov 2012 20:57:21 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514D029A3@MBX10.d.ethz.ch> References: <051.b150c522197456646133cd1bca831535@trac.tools.ietf.org> <55877B3AFB359744BA0F2140E36F52B514D02409@MBX10.d.ethz.ch> In-Reply-To: Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.9.88] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "core@ietf.org" Subject: Re: [core] #259: Standardize a workaround for HTTP library limitations in talking to forward HTTP-COAP cross-proxies? 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, 06 Nov 2012 20:57:38 -0000 > my scenario is: >=20 > a web application needs mashing up both CoAP and HTTP resources in one > single page. Yes, that is the general scenario I also imagine. The details depend on own= ership and the relationships between application, devices, and user. =20 > On download/startup it asks the user to registerProtocolHandler() for a g= iven > HTTP-CoAP proxy under its control. > If user agrees, native CoAP resources can be interacted via HTTP back and > forth the translating gateway. Ah, so the application Web server and the cross-proxy, i.e., also the devic= es behind it, belong to the same authority? ("its control" -> the applicati= on) But if so, why does the server not contact the devices directly, so that th= ere is only communication between browser and application server? > Another web application could do the same but with a different HTTP-CoAP > proxy in another tab at the same time. > It seems pretty scalable to me. Yes it is, because the actual access control is managed at a single cross-p= roxy that connects to all devices. > And the security model is the usual one in the browser world, asking the = user > to opt in for a specific capability. Yes, as a start I also believe in an access control list similar to microph= one or webcam. =20 > Also, since the browser speaks plain HTTP with the HTTP-CoAP proxy, there= 's > no need to integrate the CoAP bits in Mozilla or whatever. > Am I missing something ? Back then, I was thinking of different use cases (as well): Imagine you buy a bunch of sensors and actuators for home automation and th= ey all communicate in your local network but are shielded from the Internet= by your router. The vendor might provide a Web application to configure or update the HA sy= stem. Therefore the application needs access to the devices. This is done t= hrough the browser: "Site X wants to access device Y / all local devices. A= llow?" Here we need CoAP support in the browser---or a local cross-proxy. I= t is still a bit fuzzy to me how RawPublicKeys or even certificates will be= managed here. I would image that the owner installs something on her devic= es that allows to verify requests. The vendor could also have something pre= -installed. For mashups where multiple authorities are involved, registering a single c= ross-proxy will not help. The application could solve access to CoAP device= s by directly using HTTP cross-proxy URIs in cross-domain AJAX requests. Bu= t I like the idea of actually having real observe notifications for real-ti= me Web applications. Thus, again CoAP support in the browser. Still, there = will be intercepting proxies involved, as even public devices need to be sh= ielded by caches. Private devices will also have some sort of access contro= l at the intercepting proxies, I guess. Maybe we should collect these detailed scenarios and then think about the b= est APIs to cover them all. Ciao Matthias From tho@koanlogic.com Tue Nov 6 14:27:00 2012 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 7920B21F8B5E for ; Tue, 6 Nov 2012 14:27:00 -0800 (PST) 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 PgRwiC+drzIz for ; Tue, 6 Nov 2012 14:27:00 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2672621F8458 for ; Tue, 6 Nov 2012 14:26:58 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so701609qca.31 for ; Tue, 06 Nov 2012 14:26:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=AlPbfmZ+Q+O5GU67wdxu7ERKBvluAYjQHs6w0ND7LQ0=; b=JcqHUS2px70AxFUEIuj1nVm50wr6TwLejCkleTW2cngKd0qinmQsExzXy5uLy5bhMR +r+cHvDyPorrNYnwtL5Cq5wP8xenaCM4QOGjtB70mlm2Z09b1xdg+gTsi0QH0PYjl1ia Hip+E6Cv5xbhAK2jUh457zZUWQXO4g+8IGRtqGCPdT8h/6vrzR+Em2bOCUBF2a7fo4Jc bM+Do6pOFnRWRGkodFlOpKpjChiR/htaKe0ZM+yUHvUcuQC9imLNj4ur72oCqiKHhbLb LI8ljfVtpILVoQxY0qrIyjk+vxv/dJMqNqYG8/Pe5lgp099QGRmzBPO37KlB0WUlshbv 7UWA== MIME-Version: 1.0 Received: by 10.49.1.36 with SMTP id 4mr4431222qej.46.1352240818521; Tue, 06 Nov 2012 14:26:58 -0800 (PST) Received: by 10.49.71.10 with HTTP; Tue, 6 Nov 2012 14:26:58 -0800 (PST) X-Originating-IP: [213.81.89.208] In-Reply-To: <55877B3AFB359744BA0F2140E36F52B514D029A3@MBX10.d.ethz.ch> References: <051.b150c522197456646133cd1bca831535@trac.tools.ietf.org> <55877B3AFB359744BA0F2140E36F52B514D02409@MBX10.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B514D029A3@MBX10.d.ethz.ch> Date: Tue, 6 Nov 2012 22:26:58 +0000 Message-ID: From: Thomas Fossati To: Kovatsch Matthias Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQln6csdaKomJDmIPdUTQ1FPsU2cAZViNtIlrhtb4Jfv4BJh3SV8KNptp3DU17cKwo6R6gEz Cc: "core@ietf.org" Subject: Re: [core] #259: Standardize a workaround for HTTP library limitations in talking to forward HTTP-COAP cross-proxies? 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, 06 Nov 2012 22:27:00 -0000 On Tue, Nov 6, 2012 at 8:57 PM, Kovatsch Matthias wrote: > Maybe we should collect these detailed scenarios and then think about the best APIs to cover them all. Agreed, but (pragmatically speaking) we'd better not leave out the chance to get an HTML5 API -- even if it gives a suboptimal solution. At least we can count on all the major browsers for providing us with a pervasive mechanism to create simple mashups. From kovatsch@inf.ethz.ch Tue Nov 6 14:51:17 2012 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 4DEAD21F8B69 for ; Tue, 6 Nov 2012 14:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.266 X-Spam-Level: X-Spam-Status: No, score=-9.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 w0DTfiu7wDJW for ; Tue, 6 Nov 2012 14:51:16 -0800 (PST) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id B9E0621F8B95 for ; Tue, 6 Nov 2012 14:51:15 -0800 (PST) Received: from CAS22.d.ethz.ch (172.31.51.112) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 6 Nov 2012 23:50:39 +0100 Received: from MBX10.d.ethz.ch ([fe80::6d7b:f3da:a5b1:c9e9]) by CAS22.d.ethz.ch ([fe80::dd0e:466a:b055:c090%10]) with mapi id 14.02.0298.004; Tue, 6 Nov 2012 23:50:44 +0100 From: "Kovatsch Matthias" To: Thomas Fossati Thread-Topic: [core] #259: Standardize a workaround for HTTP library limitations in talking to forward HTTP-COAP cross-proxies? Thread-Index: AQHNvCIrAd+Q4LzJZEGZINMcvTNy7Zfc/XhQ///5rYCAABFCgIAASjsAgAAVbzA= Date: Tue, 6 Nov 2012 22:50:43 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514D02EF9@MBX10.d.ethz.ch> References: <051.b150c522197456646133cd1bca831535@trac.tools.ietf.org> <55877B3AFB359744BA0F2140E36F52B514D02409@MBX10.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B514D029A3@MBX10.d.ethz.ch> In-Reply-To: Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.9.88] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "core@ietf.org" Subject: Re: [core] #259: Standardize a workaround for HTTP library limitations in talking to forward HTTP-COAP cross-proxies? 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, 06 Nov 2012 22:51:17 -0000 > Agreed, but (pragmatically speaking) we'd better not leave out the chance= to > get an HTML5 API -- even if it gives a suboptimal solution. >=20 > At least we can count on all the major browsers for providing us with a > pervasive mechanism to create simple mashups. Yes, it is a good start! If also posting to the Bugzilla discussion or some= thing else could help, tell me (or us, I guess). I just wanted to point out, that it is only a first step, as only a limited= type of mashup is possible. From tho@koanlogic.com Tue Nov 6 15:06:08 2012 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 9E04E21F8ACC for ; Tue, 6 Nov 2012 15:06:08 -0800 (PST) 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 xCsea1cjWn+m for ; Tue, 6 Nov 2012 15:06:08 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0137D21F84BA for ; Tue, 6 Nov 2012 15:06:07 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so724281qca.31 for ; Tue, 06 Nov 2012 15:06:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=jdQZift7DvGXpWMR9zSi+aX0Yf6+GFxnXotp/1Y9quc=; b=oumQaiQBZqAYklQBTAVvLC5BvNlcTbgF+KvutiL4mMp1bfE/KPUPppg3liUZ55+0jR PkaONVSljyZ0pygYRzW2GvAwvQbm/ebc+vJZndOGsBqllE81GzZK3b5WnPAnxAXiFAxZ u0zOg6y3PpDvsGsoyEBneMnXzs9v2wASuLqXWn+Kk7GSX3+6G4muyCIRWlhrTF+LcA52 fYkWcI7nYuX6p82CEuenxBBwnvYSxiAUhkiREMCt8skOPg3bRluphBFjk9HIBmE1/gg3 y7PmZNM7x6makgYy/U5Y4aujG5Mmq+PGHK9LPMcOva5OrinNO3uLU1JcTrrj6B5xUp1i VXkQ== MIME-Version: 1.0 Received: by 10.49.2.74 with SMTP id 10mr4778554qes.10.1352243167462; Tue, 06 Nov 2012 15:06:07 -0800 (PST) Received: by 10.49.71.10 with HTTP; Tue, 6 Nov 2012 15:06:07 -0800 (PST) X-Originating-IP: [213.81.89.208] In-Reply-To: References: <051.b150c522197456646133cd1bca831535@trac.tools.ietf.org> <55877B3AFB359744BA0F2140E36F52B514D02409@MBX10.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B514D029A3@MBX10.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B514D02EF9@MBX10.d.ethz.ch> Date: Tue, 6 Nov 2012 23:06:07 +0000 Message-ID: From: Thomas Fossati To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkOSfBk3F9jRLyekNmMjppf764jNh+juiWqCZia1jWE58zjmit+m0PYatT+NRsm5c9AaNC/ Subject: Re: [core] #259: Standardize a workaround for HTTP library limitations in talking to forward HTTP-COAP cross-proxies? 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, 06 Nov 2012 23:06:08 -0000 On Tue, Nov 6, 2012 at 10:50 PM, Kovatsch Matthias wrote: > Yes, it is a good start! If also posting to the Bugzilla discussion > or something else could help, tell me (or us, I guess). Please, do :-) > I just wanted to point out, that it is only a first step, as only a > limited type of mashup is possible. Correct. BTW I'd be more than happy to join efforts to model the "ideal" HTTP-CoAP API (something that, among other things, has bubbled up frequently in my conversations with Sal...), and which would also provide a great benchmark for the HTTP-CoAP proxy. From mcr@sandelman.ca Tue Nov 6 10:38:27 2012 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 CFE6721F841D for ; Tue, 6 Nov 2012 10:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.91 X-Spam-Level: X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_96_XX=1.69, NO_RELAYS=-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 1RbSUaVwtKfu for ; Tue, 6 Nov 2012 10:38:27 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 1E29021F8BEE for ; Tue, 6 Nov 2012 10:38:27 -0800 (PST) Received: from [IPV6:2001:df8:0:16:e98d:3236:daa2:8a2b] (unknown [IPv6:2001:df8:0:16:e98d:3236:daa2:8a2b]) by tuna.sandelman.ca (Postfix) with ESMTPSA id 55B7A20178; Tue, 6 Nov 2012 13:39:00 -0500 (EST) User-Agent: K-9 Mail for Android MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Michael Richardson {quigon} To: core@ietf.org,zach@sensinode.com Message-ID: <8b79ff13-e7a9-4e2e-8806-811f39eaf800@email.android.com> X-Mailman-Approved-At: Wed, 07 Nov 2012 08:02:19 -0800 Subject: [core] coap-link-format 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: , Date: Tue, 06 Nov 2012 18:38:28 -0000 X-Original-Date: Wed, 05 Sep 2012 10:45:24 -0400 X-List-Received-Date: Tue, 06 Nov 2012 18:38:28 -0000 I have a minor editorial comment about section 3.1 about core-link-format. It says: "The resource type attribute MUST NOT occur more than once in a link." I understand specifying rules as to what is compliant and what is not. But, given the liberal part of the Postel doctrine, I want to suggest instead one of these texts be added. "If more than one resource type attribute is seen, the last one is used." or "If more than one resource type attribute is seen, the link description is discarded as invalid." or "If more than one resource type attribute is seen, the entire file is discarded as invalid." thanks. -- Sent from my android transformer, running CM9 From cabo@tzi.org Wed Nov 7 08:39:19 2012 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 22B7B21F8BD5 for ; Wed, 7 Nov 2012 08:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.174 X-Spam-Level: X-Spam-Status: No, score=-106.174 tagged_above=-999 required=5 tests=[AWL=0.075, 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 7195f0yYBtrH for ; Wed, 7 Nov 2012 08:39:18 -0800 (PST) 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 9EACC21F8C27 for ; Wed, 7 Nov 2012 08:39:17 -0800 (PST) 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 qA7Gd9T0026819; Wed, 7 Nov 2012 17:39:09 +0100 (CET) Received: from dhcp-9336.meeting.ietf.org (dhcp-9336.meeting.ietf.org [130.129.11.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7EF7E79C; Wed, 7 Nov 2012 17:39:08 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <8b79ff13-e7a9-4e2e-8806-811f39eaf800@email.android.com> Date: Wed, 7 Nov 2012 11:39:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3B2178B4-1758-41F8-943B-167C5C7DA38E@tzi.org> References: <8b79ff13-e7a9-4e2e-8806-811f39eaf800@email.android.com> To: Michael Richardson {quigon} X-Mailer: Apple Mail (2.1499) Cc: core@ietf.org Subject: Re: [core] coap-link-format 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, 07 Nov 2012 16:39:19 -0000 On Sep 5, 2012, at 10:45, Michael Richardson {quigon} = wrote: > I have a minor editorial comment about section 3.1 about = core-link-format. JFYI, that is now RFC 6690. > It says: > "The resource type attribute MUST NOT occur more than once in a = link." Actually, it says: "The Resource Type attribute MUST NOT appear more than once in a link." The specific issue is an instance of a general protocol evolution = objective that could be termed "soup avoidance". The Postel Principle is a bit like water. If you sprinkle too much of it on top of a protocol, that turns into = soup (as in HTML). If you put in too little, the protocol may become brittle. > I understand specifying rules as to what is compliant and what is not. > But, given the liberal part of the Postel doctrine, I want to suggest = instead one of these texts be added. > "If more than one resource type attribute is seen, the last one is = used." That would be almost a recipe for soup. > or > "If more than one resource type attribute is seen, the link = description is discarded as invalid." > or > "If more than one resource type attribute is seen, the entire file is = discarded as invalid." The latter alternatives are examples that I would call militant = anti-soup vigilance. Right now, I'd say, if you want a link to have a resource type, send = exactly one. Otherwise, you are deep in undefined behavior. Gr=FC=DFe, Carsten From alper.yegin@yegin.org Thu Nov 8 03:27:46 2012 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 E520D21F8A72 for ; Thu, 8 Nov 2012 03:27:46 -0800 (PST) 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 jQfDUdr92ell for ; Thu, 8 Nov 2012 03:27:46 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 5B19721F8654 for ; Thu, 8 Nov 2012 03:27:46 -0800 (PST) Received: from [10.119.8.5] (prod02.i.atl.fullmeshnetworks.com [64.120.52.100]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0Lm2Pp-1SwoP63LU1-00ZcUl; Thu, 08 Nov 2012 06:27:44 -0500 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Alper Yegin In-Reply-To: <508AB6F1.4060701@toshiba.co.jp> Date: Thu, 8 Nov 2012 13:27:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <983D316C-8B9F-464F-9C84-5CC826184923@yegin.org> References: <508AB6F1.4060701@toshiba.co.jp> To: Carsten Bormann X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:UZDkcZNU3vceKZsAPrVSY39YidE2Aoywab66Ewv1pMl ztq5Yhr6cgqtJfjIwentREaKXZX2TbOx7btM9omXHNmjM+p8YO YtLd2YgTNoCa9sfVWsmQ+lg/dfabWnUODSidiRucsrbgeyLf6X Mp3F/L0OEKJKmhj8fL51lYilgfVNnU+1PxfbipH1NQ8DB5N4HX jODtlI6Fv9m8R/pCdvPHyblerRpStRVF8ctuLSQK3ZwCZ0l5Rl KpjFVbKzFGVTKaOQB0mgVRN8zM8K/yVTUBRWOUGJlNmGjb/Xeu VS03kVTYdP2mlypXh6lqmtH0JGAYqUcgiq5X1yJrZ4lUA3fogU FMl1rdOHjwSzy4A0Ekjy71ptVKtiZHrPp2SlPmbvA Cc: "core@ietf.org WG" Subject: Re: [core] CoRE agenda @ IETF85 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, 08 Nov 2012 11:27:47 -0000 Hello Carsten, CORE security discussions on Friday are colliding with the security = discussions in PCP WG. Is it possible to take on the CORE security discussions somewhere in the = second half of the agenda? Thanks. Alper On Oct 26, 2012, at 7:14 PM, Yusuke DOI wrote: > Carsten, >=20 > if it's not too late, please let me introduce content-type parameter = option in 5 min. talk. I'll be on the site. >=20 > - Time: 5 min. for presentation, maybe another 5 min. for discussion? > (I have no idea it's too long or short) > - Presenter: Yusuke DOI > - Objective: discussion on the content-type parameter proposal >=20 > Thanks! >=20 > Yusuke >=20 > (2012/10/25 5:32), Carsten Bormann wrote: >> I put in a first version of the agenda at: >>=20 >> http://www.ietf.org/proceedings/85/agenda/agenda-85-core >>=20 >> This time we might have a chance to cover a little more of the new = stuff, in the Friday session. >>=20 >> If you haven't put in your slot request, please do so, and please = indicate >> -- time needed for any presentation and, more importantly, for = discussion >> -- who will run the slot (presenter) >> -- what are your objectives for requesting the slot? >>=20 >> If you have, and I lost it, please retransmit :-) >>=20 >> Gr=FC=DFe, Carsten >>=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 From cabo@tzi.org Thu Nov 8 05:01:25 2012 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 4DD3021F8793 for ; Thu, 8 Nov 2012 05:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.19 X-Spam-Level: X-Spam-Status: No, score=-106.19 tagged_above=-999 required=5 tests=[AWL=0.059, 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 dV2iUP-L0H9O for ; Thu, 8 Nov 2012 05:01:24 -0800 (PST) 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 8AFAD21F84B9 for ; Thu, 8 Nov 2012 05:01:24 -0800 (PST) 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 qA8D1EKt010017; Thu, 8 Nov 2012 14:01:14 +0100 (CET) Received: from dhcp-47b8.meeting.ietf.org (dhcp-47b8.meeting.ietf.org [130.129.71.184]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F390ACC7; Thu, 8 Nov 2012 14:01:13 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <983D316C-8B9F-464F-9C84-5CC826184923@yegin.org> Date: Thu, 8 Nov 2012 08:01:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0EC313CE-CE2C-4AB6-9C60-65A7763C8534@tzi.org> References: <508AB6F1.4060701@toshiba.co.jp> <983D316C-8B9F-464F-9C84-5CC826184923@yegin.org> To: Alper Yegin , "Mehmet (NSN - DE/Munich) Ersue" X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] CoRE agenda @ IETF85 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, 08 Nov 2012 13:01:25 -0000 On Nov 8, 2012, at 06:27, Alper Yegin wrote: > Hello Carsten, >=20 > CORE security discussions on Friday are colliding with the security = discussions in PCP WG. > Is it possible to take on the CORE security discussions somewhere in = the second half of the agenda? If Mehmet does not object (SOLACE is somewhat related to COMAN), let's = do that. Gr=FC=DFe, Carsten From salvatore.loreto@ericsson.com Thu Nov 8 11:42:12 2012 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 8A05321F8853 for ; Thu, 8 Nov 2012 11:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.963 X-Spam-Level: X-Spam-Status: No, score=-105.963 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 7yiyHl6TqAes for ; Thu, 8 Nov 2012 11:42:11 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id EAF6C21F88F8 for ; Thu, 8 Nov 2012 11:42:10 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-55-509c0b110e68 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9A.12.11564.11B0C905; Thu, 8 Nov 2012 20:42:09 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Thu, 8 Nov 2012 20:42:09 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3CD17247A for ; Thu, 8 Nov 2012 21:42:09 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7ECAB53B70 for ; Thu, 8 Nov 2012 21:42:08 +0200 (EET) Received: from dhcp-12c3.meeting.ietf.org (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 045B753680 for ; Thu, 8 Nov 2012 21:42:07 +0200 (EET) Message-ID: <509C0B0F.4000409@ericsson.com> Date: Thu, 8 Nov 2012 14:42:07 -0500 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: core@ietf.org References: <20121015134442.14537.59996.idtracker@ietfa.amsl.com> <507D5EBC.3060907@ericsson.com> In-Reply-To: <507D5EBC.3060907@ericsson.com> Content-Type: multipart/alternative; boundary="------------080809040100020204020104" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUyM+Jvja4g95wAgz+vLS32vV3P7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujNN797MX9PhXXG4+zdjAON+mi5GDQ0LAROLHXfYuRk4gU0zi wr31bF2MXBxCAicZJa62PmKGcNYzSjz89JcFwjnHKPF3ySwmCOcgo8Tvi9MQnCX/bjCBDOMV 0JaYtaOREcRmEVCRuLHyPxuIzSZgJvH84RZmEFtUIFli7acn7BD1ghInZz5hAbFFgOxdd7cz gdwnLGAtsfKuMkhYSCBR4tSVe2BjOAV0JO5/OgY2hlkgTGL/0WtMED+oSVw9t4kZol5Lovds J9MERuFZSDbMQtICYdtKXJhzHSouL7H97RxmCFtX4sL/KSjiCxjZVjGy5yZm5qSXG25iBIb+ wS2/dXcwnjoncohRmoNFSZyXK2m/v5BAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGZfM907h/ rKvm5W7eNGN5w9ot4oaRiQ32D85uXfdx5d61st9ickRuPWThOnOJQdDx1PZsfpvOSVJsTiyn vZ4/LGNS9zSetqA0e/eC0+uX9BXu2716xl8Px5YLh21FH+//xDBfI35q+eeg4/+NtwadNnOf +ujh0v1n3wqUFGra2kablbyzqBPqUmIpzkg01GIuKk4EAOCryVFLAgAA Subject: Re: [core] new draft core-sleepy-problem-statement 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, 08 Nov 2012 19:42:12 -0000 --------------080809040100020204020104 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit tomorrow there is a slot in the agenda to present the draft and hopefully enough time to exchange ideas and chat on the way forward on how to address it in CoAP please read the draft is really a short one thanks Salvatore -- Salvatore Loreto, PhD www.sloreto.com On 10/16/12 9:18 AM, Salvatore Loreto wrote: > > The authors of the various I-Ds related to solutions for Sleepy Devices > have collaborated to produce a first version of a problem statement: > http://www.ietf.org/internet-drafts/draft-rahman-core-sleepy-problem-statement-00.txt > > > The idea behind this joint effort is to trigger a discussions in the > CORE WG so > that all relevant considerations for sleeping devices as well all the > possible use cases/scenarios > are taken into account when designing the specific CoAP solution(s). > > We would really appreciate if you read it and send out comments in the > CoRE mailing list. > > We also look forward to discuss this problem statement, with enough time, > in on of the F2F session Atlanta > > cheers > /Sal > -- > Salvatore Loreto, PhD > www.sloreto.com > > > -------- Original Message -------- > Subject: New Version Notification for > draft-rahman-core-sleepy-problem-statement-00.txt > Date: Mon, 15 Oct 2012 16:44:42 +0300 > From: internet-drafts@ietf.org > To: akbar.rahman@interdigital.com > CC: Salvatore Loreto , > "tho@koanlogic.com" , > "matthieu.vial@schneider-electric.com" > > > > > A new version of I-D, draft-rahman-core-sleepy-problem-statement-00.txt > has been successfully submitted by Akbar Rahman and posted to the > IETF repository. > > Filename: draft-rahman-core-sleepy-problem-statement > Revision: 00 > Title: Sleepy Devices in CoAP - Problem Statement > Creation date: 2012-10-15 > WG ID: Individual Submission > Number of pages: 8 > URL:http://www.ietf.org/internet-drafts/draft-rahman-core-sleepy-problem-statement-00.txt > Status:http://datatracker.ietf.org/doc/draft-rahman-core-sleepy-problem-statement > Htmlized:http://tools.ietf.org/html/draft-rahman-core-sleepy-problem-statement-00 > > > Abstract: > This document analyzes the COAP protocol issues related to sleeping > devices. The only goal of this document is to trigger discussions in > the CORE WG so that all relevant considerations for sleeping devices > are taken into account when designing CoAP. > > > > > The IETF Secretariat > > > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --------------080809040100020204020104 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
tomorrow there is a slot in the agenda to present the draft and
hopefully enough time to exchange ideas and chat on the way forward
on how to address it in CoAP

please read the draft is really a short one

thanks
Salvatore


-- 
Salvatore Loreto, PhD
www.sloreto.com


On 10/16/12 9:18 AM, Salvatore Loreto wrote:

The authors of the various I-Ds related to solutions for Sleepy Devices
have collaborated to produce a first version of a problem statement:
http://www.ietf.org/internet-drafts/draft-rahman-core-sleepy-problem-statement-00.txt

The idea behind this joint effort is to trigger a discussions in the CORE WG so
that all relevant considerations for sleeping devices as well all the possible use cases/scenarios
are taken into account when designing the specific CoAP solution(s).

We would really appreciate if you read it and send out comments in the CoRE mailing list.

We also look forward to discuss this problem statement, with enough time,
in on of the F2F session Atlanta

cheers
/Sal
-- 
Salvatore Loreto, PhD
www.sloreto.com


-------- Original Message --------
Subject: New Version Notification for draft-rahman-core-sleepy-problem-statement-00.txt
Date: Mon, 15 Oct 2012 16:44:42 +0300
From: internet-drafts@ietf.org <internet-drafts@ietf.org>
To: akbar.rahman@interdigital.com <akbar.rahman@interdigital.com>
CC: Salvatore Loreto <salvatore.loreto@ericsson.com>, "tho@koanlogic.com" <tho@koanlogic.com>, "matthieu.vial@schneider-electric.com" <matthieu.vial@schneider-electric.com> 


A new version of I-D, draft-rahman-core-sleepy-problem-statement-00.txt
has been successfully submitted by Akbar Rahman and posted to the
IETF repository.

Filename:	 draft-rahman-core-sleepy-problem-statement
Revision:	 00
Title:		 Sleepy Devices in CoAP - Problem Statement
Creation date:	 2012-10-15
WG ID:		 Individual Submission
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-rahman-core-sleepy-problem-statement-00.txt
Status:          http://datatracker.ietf.org/doc/draft-rahman-core-sleepy-problem-statement
Htmlized:        http://tools.ietf.org/html/draft-rahman-core-sleepy-problem-statement-00


Abstract:
   This document analyzes the COAP protocol issues related to sleeping
   devices.  The only goal of this document is to trigger discussions in
   the CORE WG so that all relevant considerations for sleeping devices
   are taken into account when designing CoAP.

                                                                                  


The IETF Secretariat







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


--------------080809040100020204020104-- From cabo@tzi.org Thu Nov 8 15:56:16 2012 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 E19AD21F8B66 for ; Thu, 8 Nov 2012 15:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.205 X-Spam-Level: X-Spam-Status: No, score=-106.205 tagged_above=-999 required=5 tests=[AWL=0.044, 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 3liZTgD2734L for ; Thu, 8 Nov 2012 15:56:16 -0800 (PST) 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 B8FE421F8B62 for ; Thu, 8 Nov 2012 15:56:15 -0800 (PST) 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 qA8Nu7LP021387 for ; Fri, 9 Nov 2012 00:56:07 +0100 (CET) Received: from dhcp-9336.meeting.ietf.org (dhcp-9336.meeting.ietf.org [130.129.11.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id EB287FDD; Fri, 9 Nov 2012 00:56:06 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Nov 2012 18:56:04 -0500 To: "core@ietf.org WG" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [core] Agenda and slides for tomorrow = Friday 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, 08 Nov 2012 23:56:17 -0000 Slides and an updated agenda for tomorrow are available at http://www.ietf.org/proceedings/85/agenda/agenda-85-core http://www.ietf.org/proceedings/85/slides/slides-85-core-0.pdf See you tomorrow at 11:20 in Salon E! Gr=FC=DFe, Carsten From esko.dijk@philips.com Tue Nov 13 02:53:59 2012 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 3E9F521F868F for ; Tue, 13 Nov 2012 02:53:59 -0800 (PST) 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 k-vwv2agqq-J for ; Tue, 13 Nov 2012 02:53:54 -0800 (PST) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3719121F8680 for ; Tue, 13 Nov 2012 02:53:52 -0800 (PST) Received: from mail120-db3-R.bigfish.com (10.3.81.232) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Tue, 13 Nov 2012 10:53:49 +0000 Received: from mail120-db3 (localhost [127.0.0.1]) by mail120-db3-R.bigfish.com (Postfix) with ESMTP id 73BF22401AF; Tue, 13 Nov 2012 10:53:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -34 X-BigFish: VPS-34(zz217bI98dI15d6O9371I9251Jd6eah542M1432Izz1de0h1202h1d1ah1d2ahzz8275ch1033IL17326ah8275bh8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0l1155h) Received: from mail120-db3 (localhost.localdomain [127.0.0.1]) by mail120-db3 (MessageSwitch) id 135280402727875_17471; Tue, 13 Nov 2012 10:53:47 +0000 (UTC) Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.235]) by mail120-db3.bigfish.com (Postfix) with ESMTP id 0452112004B; Tue, 13 Nov 2012 10:53:47 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by DB3EHSMHS019.bigfish.com (10.3.87.119) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 13 Nov 2012 10:53:46 +0000 Received: from 011-DB3MMR1-022.MGDPHG.emi.philips.com (10.128.28.105) by 011-DB3MMR1-006.MGDPHG.emi.philips.com (10.128.28.56) with Microsoft SMTP Server (TLS) id 14.2.318.3; Tue, 13 Nov 2012 10:53:46 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.20]) by 011-DB3MMR1-022.MGDPHG.emi.philips.com ([fe80::1113:17d7:70dc:6faa%11]) with mapi id 14.02.0318.003; Tue, 13 Nov 2012 10:53:46 +0000 From: "Dijk, Esko" To: Antonio Jara , Zach Shelby Thread-Topic: [core] Scalability of multicast use for discovery (ticket #247) Thread-Index: Ac2s9uoOPZ6pzG7LT9++vLv1CHW/k////x4A///qPrCAF998gIAAGZkA/+64XJA= Date: Tue, 13 Nov 2012 10:53:44 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618B0C18C@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED618AFBE04@011-DB3MPN2-082.MGDPHG.emi.philips.com> <1D48EEB1-8B66-4D82-97E7-AC3B6C7F944D@sensinode.com> <031DD135F9160444ABBE3B0C36CED618AFBE78@011-DB3MPN2-082.MGDPHG.emi.philips.com> <8AFA0CA2-F37E-4A25-AD4C-8E863A9FFD0B@sensinode.com> <20121102115222.15844vkxp8y3r6qu@webmail.atica.um.es> In-Reply-To: <20121102115222.15844vkxp8y3r6qu@webmail.atica.um.es> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.94.216.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org" Subject: Re: [core] Scalability of multicast use for discovery (ticket #247) 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, 13 Nov 2012 10:53:59 -0000 Hi Antonio, what we will first try is to get an allocation in the 0x0-0xFF group which = would help save some bytes in 6LoWPAN link-local use. So it could be, skipp= ing the last 2 characters: FF0x::C0 if that's not allowed for some reason, we could ask for C0A7. The usage of scopes may be restricted in the way Zach proposes. Esko -----Original Message----- From: Antonio Jara [mailto:jara@um.es] Sent: Friday 2 November 2012 11:52 To: Zach Shelby Cc: Dijk, Esko; core@ietf.org Subject: Re: [core] Scalability of multicast use for discovery (ticket #247= ) Hi Zach, Maybe, it could be interesting to ask also to IANA some predefinition of multicast addresses for CoAP devices: Variable scope to find all the CoAP devices (similar to other technologies e.g. BACnet). 1- CoAP // e.g. FF0X:0:0:0:0:0:0:C0A7 Note that, it s is also considering the local and site scopes: 1- Local CoAP Devices // e.g. FF02:0:0:0:0:0:0:C0A7 2- Site CoAP Devices // e.g. FF05:0:0:0:0:0:0:C0A7 7 is because looks like "P" in HEX. In addition, it could be considered the options for CoAP RD. 1- Local CoAP Resource Directories (Browsing) // e.g. FF02:0:0:0:0:0:0:C0AB 2- Site CoAP Resource Directories (Browsing) // e.g. FF05:0:0:0:0:0:0:C0AB B is because the browsing, commonly used in mDNSv6 (FB). Best regards, Antonio J. Jara Quoting Zach Shelby : > Coming back to the solution for this ticket. I would like to propose > the following in the WG meeting next week: > > 1. Change the IPv4 request to the Local Network Control Block. > Although we could ask for the Ad-Hoc Block I think Local Network is > sufficient for our discovery needs in IPv4. > 2. Change the IPv6 request to link-local and site-local scope only. > Here we need site-local scope due to the way 6LoWPAN networks are > typically built. > 3. Recommend the use application specific multicast addresses for > larger scope multicast needs. > > Regarding the security consideration, with these changes I think the > existing text in 11.4 is sufficient. > > If this is OK with the WG, then we can make the needed changes in > -13 and then update our IANA registration request accordingly. > > Zach > > On Oct 18, 2012, at 10:27 AM, Dijk, Esko wrote: > >> I agree, since the CoRE discovery use cases seem to be all for >> link-local or site-local scope multicast. >> >> For the IPv4 address assignment, there's no site-local IPv4 but >> looking at the IANA registry >> (http://www.iana.org/assignments/multicast-addresses/multicast-addresses= .xml#multicast-addresses-3 ) it looks somewhat like the ad-hoc block I (224= .0.2.0 - 224.0.255.255) has taken on this function? Since there are some re= cent additions of single addresses in >> there. >> Alternatively we only register link-local for IPv4. >> >> Esko >> >> -----Original Message----- >> From: Zach Shelby [mailto:zach@sensinode.com] >> Sent: Thursday 18 October 2012 9:05 >> To: Dijk, Esko >> Cc: core@ietf.org >> Subject: Re: [core] Scalability of multicast use for discovery (ticket #= 247) >> >> Esko, >> >> On Oct 18, 2012, at 9:07 AM, Dijk, Esko wrote: >> >>> Dear all, >>> >>> to explore possible solutions to ticket #247 >>> (http://trac.tools.ietf.org/wg/core/trac/ticket/247) in the WG >>> here are some initial ideas. >>> >>> To enable safe use of multicast for CoAP discovery; we could >>> include in core-coap stricter requirements on multicast responding >>> e.g.: >>> >>> - for site-local scope or any smaller scope, a discovery multicast >>> request (/.well-known/core) by an unauthenticated client MAY be >>> responded to by a server >>> - for organization-local and global scope, a discovery multicast >>> request by an unauthenticated client SHOULD NOT be responsed to >>> - for global scope, a discovery multicast request SHOULD NOT be >>> responded to. Exception case is a server known to be deployed in >>> an isolated network i.e. multicast not propagating onto the >>> internet or to multicast backbones. In that case the server MUST >>> be explicitly configured to do so. >> >> This is not just about discovery, but for responding to any >> multicast CoAP request. >> >> I start to be doubtful about the actual utility of the CoAP >> multicast address with global scope (the risks are much greater >> than the benefit). To be safer, and deal with the IANA comments >> completely, we could just limit the default CoAP multicast address >> to local and site-local scope only. For specialized applications >> where global scope could be useful, it would be better for that >> application to use a dedicated multicast address for that purpose. >> >> Zach >> >>> This would allow local multicast discovery (of servers previously >>> unknown to the client) use cases without the side effects that the >>> IANA appointed expert mentions. >>> >>> regards, >>> Esko >>> >>> >>> Esko Dijk >>> >>> Philips Group Innovation, Research >>> High Tech Campus 34, Eindhoven, The Netherlands >>> esko.dijk@philips.com >>> >>> >>> >>> 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 >> >> -- >> 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 >> >> > > -- > 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 jara@um.es Tue Nov 13 02:59:14 2012 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 38D8B21F869B for ; Tue, 13 Nov 2012 02:59:14 -0800 (PST) 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 86HraBqg4qbf for ; Tue, 13 Nov 2012 02:59:09 -0800 (PST) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id A1B3021F861B for ; Tue, 13 Nov 2012 02:59:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 4B12C4BD49; Tue, 13 Nov 2012 11:59:06 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id EL2QeG3IjimF; Tue, 13 Nov 2012 11:59:05 +0100 (CET) Received: from localhost (ursus11.um.es [155.54.212.229]) by xenon12.um.es (Postfix) with ESMTP id 054414BDC6; Tue, 13 Nov 2012 11:59:04 +0100 (CET) Received: from mdc-wsg-1.utc.com (mdc-wsg-1.utc.com [192.249.47.201]) by webmail.atica.um.es (Horde Framework) with HTTP; Tue, 13 Nov 2012 11:59:04 +0100 Message-ID: <20121113115904.6252576sd1m1g8hk@webmail.atica.um.es> Date: Tue, 13 Nov 2012 11:59:04 +0100 From: Antonio Jara To: "Dijk, Esko" References: <031DD135F9160444ABBE3B0C36CED618AFBE04@011-DB3MPN2-082.MGDPHG.emi.philips.com> <1D48EEB1-8B66-4D82-97E7-AC3B6C7F944D@sensinode.com> <031DD135F9160444ABBE3B0C36CED618AFBE78@011-DB3MPN2-082.MGDPHG.emi.philips.com> <8AFA0CA2-F37E-4A25-AD4C-8E863A9FFD0B@sensinode.com> <20121102115222.15844vkxp8y3r6qu@webmail.atica.um.es> <031DD135F9160444ABBE3B0C36CED618B0C18C@011-DB3MPN2-082.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED618B0C18C@011-DB3MPN2-082.MGDPHG.emi.philips.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.2) Cc: "core@ietf.org" Subject: Re: [core] Scalability of multicast use for discovery (ticket #247) 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, 13 Nov 2012 10:59:14 -0000 Hi Esko, This sounds perfect for me. Checking the IANA assignment this does not look assigned. Therefore, it should not be any problem. http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xml Best regards and thanks, Antonio J. Jara Quoting "Dijk, Esko" : > Hi Antonio, > > what we will first try is to get an allocation in the 0x0-0xFF group > which would help save some bytes in 6LoWPAN link-local use. So it > could be, skipping the last 2 characters: > FF0x::C0 > > if that's not allowed for some reason, we could ask for C0A7. > The usage of scopes may be restricted in the way Zach proposes. > > Esko > > -----Original Message----- > From: Antonio Jara [mailto:jara@um.es] > Sent: Friday 2 November 2012 11:52 > To: Zach Shelby > Cc: Dijk, Esko; core@ietf.org > Subject: Re: [core] Scalability of multicast use for discovery (ticket #247) > > Hi Zach, > > Maybe, it could be interesting to ask also to IANA some predefinition > of multicast addresses for CoAP devices: > > Variable scope to find all the CoAP devices (similar to other > technologies e.g. BACnet). > 1- CoAP // e.g. FF0X:0:0:0:0:0:0:C0A7 > > Note that, it s is also considering the local and site scopes: > 1- Local CoAP Devices // e.g. FF02:0:0:0:0:0:0:C0A7 > 2- Site CoAP Devices // e.g. FF05:0:0:0:0:0:0:C0A7 > > 7 is because looks like "P" in HEX. > > In addition, it could be considered the options for CoAP RD. > 1- Local CoAP Resource Directories (Browsing) // e.g. FF02:0:0:0:0:0:0:C0AB > 2- Site CoAP Resource Directories (Browsing) // e.g. FF05:0:0:0:0:0:0:C0AB > > B is because the browsing, commonly used in mDNSv6 (FB). > > Best regards, > Antonio J. Jara > > Quoting Zach Shelby : > >> Coming back to the solution for this ticket. I would like to propose >> the following in the WG meeting next week: >> >> 1. Change the IPv4 request to the Local Network Control Block. >> Although we could ask for the Ad-Hoc Block I think Local Network is >> sufficient for our discovery needs in IPv4. >> 2. Change the IPv6 request to link-local and site-local scope only. >> Here we need site-local scope due to the way 6LoWPAN networks are >> typically built. >> 3. Recommend the use application specific multicast addresses for >> larger scope multicast needs. >> >> Regarding the security consideration, with these changes I think the >> existing text in 11.4 is sufficient. >> >> If this is OK with the WG, then we can make the needed changes in >> -13 and then update our IANA registration request accordingly. >> >> Zach >> >> On Oct 18, 2012, at 10:27 AM, Dijk, Esko wrote: >> >>> I agree, since the CoRE discovery use cases seem to be all for >>> link-local or site-local scope multicast. >>> >>> For the IPv4 address assignment, there's no site-local IPv4 but >>> looking at the IANA registry >>> (http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xml#multicast-addresses-3 ) it looks somewhat like the ad-hoc block I (224.0.2.0 - 224.0.255.255) has taken on this function? Since there are some recent additions of single addresses >>> in >>> there. >>> Alternatively we only register link-local for IPv4. >>> >>> Esko >>> >>> -----Original Message----- >>> From: Zach Shelby [mailto:zach@sensinode.com] >>> Sent: Thursday 18 October 2012 9:05 >>> To: Dijk, Esko >>> Cc: core@ietf.org >>> Subject: Re: [core] Scalability of multicast use for discovery >>> (ticket #247) >>> >>> Esko, >>> >>> On Oct 18, 2012, at 9:07 AM, Dijk, Esko wrote: >>> >>>> Dear all, >>>> >>>> to explore possible solutions to ticket #247 >>>> (http://trac.tools.ietf.org/wg/core/trac/ticket/247) in the WG >>>> here are some initial ideas. >>>> >>>> To enable safe use of multicast for CoAP discovery; we could >>>> include in core-coap stricter requirements on multicast responding >>>> e.g.: >>>> >>>> - for site-local scope or any smaller scope, a discovery multicast >>>> request (/.well-known/core) by an unauthenticated client MAY be >>>> responded to by a server >>>> - for organization-local and global scope, a discovery multicast >>>> request by an unauthenticated client SHOULD NOT be responsed to >>>> - for global scope, a discovery multicast request SHOULD NOT be >>>> responded to. Exception case is a server known to be deployed in >>>> an isolated network i.e. multicast not propagating onto the >>>> internet or to multicast backbones. In that case the server MUST >>>> be explicitly configured to do so. >>> >>> This is not just about discovery, but for responding to any >>> multicast CoAP request. >>> >>> I start to be doubtful about the actual utility of the CoAP >>> multicast address with global scope (the risks are much greater >>> than the benefit). To be safer, and deal with the IANA comments >>> completely, we could just limit the default CoAP multicast address >>> to local and site-local scope only. For specialized applications >>> where global scope could be useful, it would be better for that >>> application to use a dedicated multicast address for that purpose. >>> >>> Zach >>> >>>> This would allow local multicast discovery (of servers previously >>>> unknown to the client) use cases without the side effects that the >>>> IANA appointed expert mentions. >>>> >>>> regards, >>>> Esko >>>> >>>> >>>> Esko Dijk >>>> >>>> Philips Group Innovation, Research >>>> High Tech Campus 34, Eindhoven, The Netherlands >>>> esko.dijk@philips.com >>>> >>>> >>>> >>>> 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 >>> >>> -- >>> 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 >>> >>> >> >> -- >> 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 protected under applicable law. The message is intended > solely for the addressee(s). If you are not the intended recipient, > you are hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original > message. > > From alessandro.ludovici@entel.upc.edu Tue Nov 13 03:10:58 2012 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 5705321F85EB for ; Tue, 13 Nov 2012 03:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 pHAohyVPWHnB for ; Tue, 13 Nov 2012 03:10:57 -0800 (PST) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF0521F85FC for ; Tue, 13 Nov 2012 03:10:55 -0800 (PST) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id qADBAppY029697 for ; Tue, 13 Nov 2012 12:10:51 +0100 Received: from webmail.entel.upc.edu (wireless.upc.es [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 9B3392CBD0F for ; Tue, 13 Nov 2012 12:10:46 +0100 (CET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_85ee6cd6367a67ca8d3c439a3568b3d0" Date: Tue, 13 Nov 2012 12:10:46 +0100 From: Alessandro Ludovici To: Message-ID: <8980058527dc9594b0e3fd194b4359d5@webmail.entel.upc.edu> X-Sender: alessandro.ludovici@entel.upc.edu User-Agent: RoundCube Webmail/0.5.1 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Tue, 13 Nov 2012 12:10:52 +0100 (CET) Subject: [core] RD Update in CoRE Resource Directory 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, 13 Nov 2012 11:10:58 -0000 --=_85ee6cd6367a67ca8d3c439a3568b3d0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Dear List, The actual version of the draft "CoRE Resource Directory" (draft-shelby-core-resource-directory-04) allows updating a resource in the RD using either POST or PUT methods. According to the registration section (5.2), the POST method has the effect of creating or updating a resource in the RD. Section 5.3 also defines how update a resource using the PUT method. I find a bit confusing that both methods may be used to update the RD. Wouldn't be better that only the PUT method can update the RD? Regards, -- Alessandro Ludovici Wireless Network Group(WNG), Department of Telematic Engineering, Universitat Politècnica de Catalunya, C/Jordi Girona 1-3, Mòdul C3, 08034 Barcelona, Spain; E-Mail: alessandro.ludovici@entel.upc.edu Tel.: +34-93-401-70-41; Fax: +34-93-401-10-58 --=_85ee6cd6367a67ca8d3c439a3568b3d0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Dear List,

The actual version of the draft "CoRE Resource Directory" (draft-shelby-= core-resource-directory-04) allows updating a resource in the RD using eith= er POST or PUT methods. According to the registration section (5.2), t= he POST method has the effect of creating or updating a= resource in the RD. Section 5.3 also defines how update a resource us= ing the PUT method.

I find a bit confusing that both methods may be used to update the RD. W= ouldn't be better that only the PUT method can update the RD?

Regards,

-- 

Alessandro Ludovici
Wireless Network Group(WNG),=20
Department of Telematic Engineering,=20
Universitat Politècnica de Catalunya,=20
C/Jordi Girona 1-3, Mòdul C3, 08034 Barcelona, Spain;=20
E-Mail: alessandro.ludovici@entel.upc.edu=20
Tel.: +34-93-401-70-41; Fax: +34-93-401-10-58
--=_85ee6cd6367a67ca8d3c439a3568b3d0-- From trac+core@trac.tools.ietf.org Tue Nov 13 03:35:07 2012 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 0DFAA21F8485 for ; Tue, 13 Nov 2012 03:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 0hzXr8KrY3w4 for ; Tue, 13 Nov 2012 03:35:06 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 38FAE21F8477 for ; Tue, 13 Nov 2012 03:35:05 -0800 (PST) Received: from localhost ([127.0.0.1]:40062 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TYElN-0005mN-Vs; Tue, 13 Nov 2012 12:34:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Tue, 13 Nov 2012 11:34:41 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/263 Message-ID: <060.b950e43a348efde2c0bfd3eb012039d3@trac.tools.ietf.org> X-Trac-Ticket-ID: 263 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: brian@skyfoundry.com, cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20121113113506.38FAE21F8477@ietfa.amsl.com> Resent-Date: Tue, 13 Nov 2012 03:35:05 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #263: Proxied responses to multicast request can't be distinguished by client 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, 13 Nov 2012 11:35:07 -0000 #263: Proxied responses to multicast request can't be distinguished by client (This ticket is either protocol defect or editorial, depending on viewpoint.) Section 8.2.2 of core-coap-12 describes a multicast request via a CoAP proxy. The proxy sends all responses back to the client. However, the client can't identify from which CoAP server any particular response is coming. (With regular non-proxied multicast, the IP source address provides this information. For a proxied request, all responses coming back carry the IP address of the CoAP proxy as the source IP address.) This ticket is meant to record our decision on this matter: 1- do we define a method such that the client can identify responses by IP address of the responding CoAP server? 2- do we leave it as now and recommend/mention that the server includes some form of self-identification in a response to a multicast request? 3- do nothing (4- any other?) -- -----------------------------+------------------------------------ Reporter: esko.dijk@… | Owner: draft-ietf-core-coap@… Type: protocol defect | Status: new Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: coap-12 Severity: - | Keywords: -----------------------------+------------------------------------ Ticket URL: core From trac+core@trac.tools.ietf.org Tue Nov 13 07:48:29 2012 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 6711321F8728 for ; Tue, 13 Nov 2012 07:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 1i+Lv62h1nuq for ; Tue, 13 Nov 2012 07:48:29 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB0021F86AD for ; Tue, 13 Nov 2012 07:48:27 -0800 (PST) Received: from localhost ([127.0.0.1]:34129 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TYIik-0005gA-Mf; Tue, 13 Nov 2012 16:48:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, hartke@tzi.org X-Trac-Project: core Date: Tue, 13 Nov 2012 15:48:14 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/263#comment:1 Message-ID: <075.094372760f0850fcce94c26377e72686@trac.tools.ietf.org> References: <060.b950e43a348efde2c0bfd3eb012039d3@trac.tools.ietf.org> X-Trac-Ticket-ID: 263 In-Reply-To: <060.b950e43a348efde2c0bfd3eb012039d3@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: brian@skyfoundry.com, cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20121113154828.3FB0021F86AD@ietfa.amsl.com> Resent-Date: Tue, 13 Nov 2012 07:48:27 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #263: Proxied responses to multicast request can't be distinguished by client 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, 13 Nov 2012 15:48:29 -0000 #263: Proxied responses to multicast request can't be distinguished by client Comment (by hartke@…): The client might not even be aware that it made a multicast request, e.g., if it follows some link and sends {{{ Proxy-Uri: coap://xyzzy.example.net/s/temp }}} and xyzzy.example.net resolves to an IP multicast address. -- -----------------------------+------------------------------------- Reporter: esko.dijk@… | Owner: draft-ietf-core-coap@… Type: protocol defect | Status: new Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: coap-12 Severity: - | Resolution: Keywords: | -----------------------------+------------------------------------- Ticket URL: core From alessandro.ludovici@entel.upc.edu Tue Nov 13 08:09:56 2012 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 DEEC921F876D for ; Tue, 13 Nov 2012 08:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=1.300, 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 UCRsK55XJiSk for ; Tue, 13 Nov 2012 08:09:55 -0800 (PST) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by ietfa.amsl.com (Postfix) with ESMTP id CECDD21F8766 for ; Tue, 13 Nov 2012 08:09:53 -0800 (PST) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id qADG9nGb021303 for ; Tue, 13 Nov 2012 17:09:50 +0100 Received: from webmail.entel.upc.edu (wireless.upc.es [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id AAFDB2CBD0E for ; Tue, 13 Nov 2012 17:09:44 +0100 (CET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_ec35505a83c3ac38c61fd02d0def9202" Date: Tue, 13 Nov 2012 17:09:44 +0100 From: Alessandro Ludovici To: Message-ID: X-Sender: alessandro.ludovici@entel.upc.edu User-Agent: RoundCube Webmail/0.5.1 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Tue, 13 Nov 2012 17:09:50 +0100 (CET) Subject: [core] Removing entries from CoRE RD 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, 13 Nov 2012 16:09:56 -0000 --=_ec35505a83c3ac38c61fd02d0def9202 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Dear List, I have a comment about the removal of RD entries specified in section 5.5 of draft-shelby-core-resource-directory-04. The removal request interface defined by the draft is specified as follows: Method: DELETE URI Template: /{+location} At present, the removal request has the effects of removing the whole registration of an endpoint. However, an endpoint could have many resources registered at the same location. If it wishes to remove only one or more resources but maintains the remaining it can't. I propose to enrich the removal request interface by allowing an endpoint to send the removal parameter of one or multiple resource in CoRE Link Format. If a removal request contains a payload in CoRE Link Format the RD will remove only the resources that the payload specifies. Otherwise, the RD will remove the whole registration of the endpoint. Regards, -- Alessandro Ludovici Wireless Network Group(WNG), Department of Telematic Engineering, Universitat Politècnica de Catalunya, C/Jordi Girona 1-3, Mòdul C3, 08034 Barcelona, Spain; E-Mail: alessandro.ludovici@entel.upc.edu Tel.: +34-93-401-70-41; Fax: +34-93-401-10-58 --=_ec35505a83c3ac38c61fd02d0def9202 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Dear List,

I have a comment about the removal of RD entries specified in secti= on 5.5 of draft-shelby-core-resource-directory-04. 

The removal request interface defined by the draft is specified as follo= ws:

   Method:  DELETE  
   URI Template:  /{+location}

At present, the removal request has the effects of removing the whole re= gistration of an endpoint. However, an endpoint could have many resources r= egistered at the same location. If it wishes to remove only one or more res= ources but maintains the remaining it can't. 

I propose to enrich the removal request interface by allowing an endpoin= t to send the removal parameter of one or multiple resource in CoRE Link Fo= rmat. If a removal request contains a payload in CoRE Link Format the RD wi= ll remove only the resources that the payload specifies. Otherwise, the RD = will remove the whole registration of the endpoint.

Regards,

--=20
Alessandro Ludovici
Wireless Network Group(WNG),=20
Department of Telematic Engineering,=20
Universitat Politècnica de Catalunya,=20
C/Jordi Girona 1-3, Mòdul C3, 08034 Barcelona, Spain;=20
E-Mail: alessandro.ludovici@entel.upc.edu=20
Tel.: +34-93-401-70-41; Fax: +34-93-401-10-58
--=_ec35505a83c3ac38c61fd02d0def9202-- From jara@um.es Tue Nov 13 08:18:30 2012 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 7CA0221F88E9 for ; Tue, 13 Nov 2012 08:18:30 -0800 (PST) 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_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 yaXB7zXoVokt for ; Tue, 13 Nov 2012 08:18:30 -0800 (PST) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 30F7F21F87CD for ; Tue, 13 Nov 2012 08:18:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 822D55D566; Tue, 13 Nov 2012 17:18:26 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 06AzdtrUeKqE; Tue, 13 Nov 2012 17:18:26 +0100 (CET) Received: from localhost (ursus13.um.es [155.54.212.233]) by xenon13.um.es (Postfix) with ESMTP id ED7A45D51E; Tue, 13 Nov 2012 17:18:25 +0100 (CET) Received: from mdc-wsg-1.utc.com (mdc-wsg-1.utc.com [192.249.47.201]) by webmail.atica.um.es (Horde Framework) with HTTP; Tue, 13 Nov 2012 17:18:25 +0100 Message-ID: <20121113171825.16095lkj4ixqgcsx@webmail.atica.um.es> Date: Tue, 13 Nov 2012 17:18:25 +0100 From: Antonio Jara To: Alessandro Ludovici References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3.2) Cc: core@ietf.org Subject: Re: [core] Removing entries from CoRE RD 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, 13 Nov 2012 16:18:30 -0000 Dear Alessandro, If you want to modify the ep, then sends an update. I guess is simpler =20 than partial removes, that could create inconsistencies easily... Best regards, Antonio J. Jara Quoting Alessandro Ludovici : > > > Dear List, > > I have a comment about the removal of RD entries > specified in section 5.5 of draft-shelby-core-resource-directory-04. > > > The removal request interface defined by the draft is specified as > follows: > > Method: DELETE > > URI Template: /{+location} > > At present, > the removal request has the effects of removing the whole registration > of an endpoint. However, an endpoint could have many resources > registered at the same location. If it wishes to remove only one or more > resources but maintains the remaining it can't. > > I propose to enrich > the removal request interface by allowing an endpoint to send the > removal parameter of one or multiple resource in CoRE Link Format. If a > removal request contains a payload in CoRE Link Format the RD will > remove only the resources that the payload specifies. Otherwise, the RD > will remove the whole registration of the endpoint. > > Regards, > > -- > > Alessandro Ludovici > Wireless Network Group(WNG), > Department of > Telematic Engineering, > Universitat Polit=E8cnica de Catalunya, > C/Jordi > Girona 1-3, M=F2dul C3, 08034 Barcelona, Spain; > E-Mail: > alessandro.ludovici@entel.upc.edu > Tel.: +34-93-401-70-41; Fax: > +34-93-401-10-58 > From alessandro.ludovici@entel.upc.edu Tue Nov 13 08:31:47 2012 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 2CE2021F8754 for ; Tue, 13 Nov 2012 08:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.948 X-Spam-Level: X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[AWL=0.650, 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 CWpeoT7obn-n for ; Tue, 13 Nov 2012 08:31:46 -0800 (PST) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6961721F86FD for ; Tue, 13 Nov 2012 08:31:44 -0800 (PST) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id qADGVgn6029564; Tue, 13 Nov 2012 17:31:42 +0100 Received: from webmail.entel.upc.edu (wireless.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 058F82CBD0E; Tue, 13 Nov 2012 17:31:37 +0100 (CET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_64a8e672e7a082efd2fa76559aa42f5a" Date: Tue, 13 Nov 2012 17:31:37 +0100 From: Alessandro Ludovici To: Antonio Jara In-Reply-To: <20121113171825.16095lkj4ixqgcsx@webmail.atica.um.es> References: <20121113171825.16095lkj4ixqgcsx@webmail.atica.um.es> Message-ID: X-Sender: alessandro.ludovici@entel.upc.edu User-Agent: RoundCube Webmail/0.5.1 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Tue, 13 Nov 2012 17:31:42 +0100 (CET) Cc: core@ietf.org Subject: Re: [core] Removing entries from CoRE RD 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, 13 Nov 2012 16:31:47 -0000 --=_64a8e672e7a082efd2fa76559aa42f5a Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Dear Antonio, I don't think that using update requests would be simpler than using a remove request. How does the endpoint specifies that it wishes to perform a removal in an update request? It could be confusing for the RD as well as it could create inconsistency. Instead, a remove request would be more straightforward and helps to avoid confusion. Best Regards, Alessandro On Tue, 13 Nov 2012 17:18:25 +0100, Antonio Jara wrote: > Dear Alessandro, > > If you want to modify the ep, then sends an update. I guess is simpler > than partial removes, that could create inconsistencies easily... > > Best regards, > Antonio J. Jara > > Quoting Alessandro Ludovici : > >> Dear List, I have a comment about the removal of RD entries specified in section 5.5 of draft-shelby-core-resource-directory-04. The removal request interface defined by the draft is specified as follows: Method: DELETE URI Template: /{+location} At present, the removal request has the effects of removing the whole registration of an endpoint. However, an endpoint could have many resources registered at the same location. If it wishes to remove only one or more resources but maintains the remaining it can't. I propose to enrich the removal request interface by allowing an endpoint to send the removal parameter of one or multiple resource in CoRE Link Format. If a removal request contains a payload in CoRE Link Format the RD will remove only the resources that the payload specifies. Otherwise, the RD will remove the whole registration of the endpoint. Regards, -- Alessandro Ludovici Wireless Network Group(WNG), Department of Telematic Engineering, Universitat Politècnica de Catalunya, C/Jordi Girona 1-3, Mòdul C3, 08034 Barcelona, Spain; E-Mail: alessandro.ludovici@entel.upc.edu [1] Tel.: +34-93-401-70-41; Fax: +34-93-401-10-58 Links: ------ [1] mailto:alessandro.ludovici@entel.upc.edu [2] mailto:alessandro.ludovici@entel.upc.edu --=_64a8e672e7a082efd2fa76559aa42f5a Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Dear Antonio,

I don't think that using update requests would be simpler than using a r= emove request. How does the endpoint specifies that it wishes to perform a = removal in an update request? It could be confusing for the RD as well= as it could create inconsistency. Instead, a remove request woul= d be more straightforward and helps to avoid confusion.

Best Regards,

Alessandro

On Tue, 13 Nov 2012 17:18:25 +0100, Antonio Jara wrote:

Dear Alessandro,

If you want to modify the ep, then sends an update. I guess is simpler =20
than partial removes, that could create inconsistencies easily...

Best regards,
Antonio J. Jara

Quoting Alessandro Ludovici <alessandro.ludovici@entel.upc.edu>:
Dear List, I have a comment about the= removal of RD entries specified in section 5.5 of draft-shelby-core-resour= ce-directory-04. The removal request interface defined by the draft is spec= ified as follows: Method: DELETE URI Template: /{+location} At present, the= removal request has the effects of removing the whole registration of an e= ndpoint. However, an endpoint could have many resources registered at the s= ame location. If it wishes to remove only one or more resources but maintai= ns the remaining it can't. I propose to enrich the removal request interfac= e by allowing an endpoint to send the removal parameter of one or multiple = resource in CoRE Link Format. If a removal request contains a payload in Co= RE Link Format the RD will remove only the resources that the payload speci= fies. Otherwise, the RD will remove the whole registration of the endpoint= =2E Regards, -- Alessandro Ludovici Wireless Network Group(WNG), Department= of Telematic Engineering, Universitat Politècnica de Catalunya, C/J= ordi Girona 1-3, Mòdul C3, 08034 Barcelona, Spain; E-Mail: alessandro.ludovici@entel.upc= =2Eedu Tel.: +34-93-401-70-41; Fax: +34-93-401-10-58
--=_64a8e672e7a082efd2fa76559aa42f5a-- From jara@um.es Tue Nov 13 08:52:26 2012 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 E16BE21F8695 for ; Tue, 13 Nov 2012 08:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, 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 D1Q-C3Jwzlsf for ; Tue, 13 Nov 2012 08:52:25 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id B63FD21F8568 for ; Tue, 13 Nov 2012 08:52:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id EE8D353730; Tue, 13 Nov 2012 17:52:21 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MkpQTrg4DNgc; Tue, 13 Nov 2012 17:52:21 +0100 (CET) Received: from localhost (ursus13.um.es [155.54.212.233]) by xenon11.um.es (Postfix) with ESMTP id 2B2D45364E; Tue, 13 Nov 2012 17:52:20 +0100 (CET) Received: from mdc-wsg-1.utc.com (mdc-wsg-1.utc.com [192.249.47.201]) by webmail.atica.um.es (Horde Framework) with HTTP; Tue, 13 Nov 2012 17:52:20 +0100 Message-ID: <20121113175220.20046m2ap15d81j8@webmail.atica.um.es> Date: Tue, 13 Nov 2012 17:52:20 +0100 From: Antonio Jara To: Alessandro Ludovici References: <20121113171825.16095lkj4ixqgcsx@webmail.atica.um.es> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3.2) Cc: core@ietf.org Subject: Re: [core] Removing entries from CoRE RD 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, 13 Nov 2012 16:52:26 -0000 Dear Alessandro, From my understanding update re-write the content of the ep, with the =20 defined payload content. For that reason, if you overwrite an ep description with less =20 resources, you are indicating that that ep now has only available the =20 indicated resources in the update. Regards, Antonio J. Jara Quoting Alessandro Ludovici : > > > Dear Antonio, > > I don't think that using update requests would be > simpler than using a remove request. How does the endpoint specifies > that it wishes to perform a removal in an update request? It could be > confusing for the RD as well as it could create inconsistency. Instead, > a remove request would be more straightforward and helps to avoid > confusion. > > Best Regards, > > Alessandro > > On Tue, 13 Nov 2012 17:18:25 > +0100, Antonio Jara wrote: > >> Dear Alessandro, >> >> If you want to > modify the ep, then sends an update. I guess is simpler >> than partial > removes, that could create inconsistencies easily... >> >> Best > regards, >> Antonio J. Jara >> >> Quoting Alessandro Ludovici : >> >>> Dear > List, I have a comment about the removal of RD entries specified in > section 5.5 of draft-shelby-core-resource-directory-04. The removal > request interface defined by the draft is specified as follows: Method: > DELETE URI Template: /{+location} At present, the removal request has > the effects of removing the whole registration of an endpoint. However, > an endpoint could have many resources registered at the same location. > If it wishes to remove only one or more resources but maintains the > remaining it can't. I propose to enrich the removal request interface by > allowing an endpoint to send the removal parameter of one or multiple > resource in CoRE Link Format. If a removal request contains a payload in > CoRE Link Format the RD will remove only the resources that the payload > specifies. Otherwise, the RD will remove the whole registration of the > endpoint. Regards, -- Alessandro Ludovici Wireless Network Group(WNG), > Department of Telematic Engineering, Universitat Polit=C3=A8cnica de > Catalunya, C/Jordi Girona 1-3, M=C3=B2dul C3, 08034 Barcelona, Spain; E-Ma= il: > alessandro.ludovici@entel.upc.edu [1] Tel.: +34-93-401-70-41; Fax: > +34-93-401-10-58 > > > Links: > ------ > [1] > mailto:alessandro.ludovici@entel.upc.edu > [2] > mailto:alessandro.ludovici@entel.upc.edu > From alessandro.ludovici@entel.upc.edu Tue Nov 13 09:03:11 2012 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 0BB1821F86EE for ; Tue, 13 Nov 2012 09:03:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.165 X-Spam-Level: X-Spam-Status: No, score=-3.165 tagged_above=-999 required=5 tests=[AWL=0.433, 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 lYu99KkebimU for ; Tue, 13 Nov 2012 09:03:10 -0800 (PST) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by ietfa.amsl.com (Postfix) with ESMTP id B888321F865B for ; Tue, 13 Nov 2012 09:03:09 -0800 (PST) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id qADH359v006341; Tue, 13 Nov 2012 18:03:05 +0100 Received: from webmail.entel.upc.edu (www-entel.upc.es [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 14EE82CBD0E; Tue, 13 Nov 2012 18:03:00 +0100 (CET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_b66f5336e79b339b5ee7c411114c71d4" Date: Tue, 13 Nov 2012 18:03:00 +0100 From: Alessandro Ludovici To: Antonio Jara In-Reply-To: <20121113175220.20046m2ap15d81j8@webmail.atica.um.es> References: <20121113171825.16095lkj4ixqgcsx@webmail.atica.um.es> <20121113175220.20046m2ap15d81j8@webmail.atica.um.es> Message-ID: <4ed4f2e8f0009eb208814705cdf4e102@webmail.entel.upc.edu> X-Sender: alessandro.ludovici@entel.upc.edu User-Agent: RoundCube Webmail/0.5.1 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Tue, 13 Nov 2012 18:03:05 +0100 (CET) Cc: core@ietf.org Subject: Re: [core] Removing entries from CoRE RD 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, 13 Nov 2012 17:03:11 -0000 --=_b66f5336e79b339b5ee7c411114c71d4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 On Tue, 13 Nov 2012 17:52:20 +0100, Antonio Jara wrote: > From my understanding update re-write the content of the ep, with the defined payload content. Yes, it is. >For that reason, if you overwrite an ep description with less resources, you are indicating that that ep now has only available the indicated resources in the >update. No, you are not indicating that. Section 5.3 states the following: "Paremeters that have not changed SHOULD NOT be included in an update". As a consequence the RD will not take any action on resources that are not contained in the payload. Regards, Alessandro --=_b66f5336e79b339b5ee7c411114c71d4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

On Tue, 13 Nov 2012 17:52:20 +0100, Antonio Jara wrote:

> From my understanding update re-write the content of the ep, with t= he defined payload content. 

Yes, it is.

>For that reason, if you overwrite an ep description with less r= esources, you are indicating that that ep now has only available the i= ndicated resources in the >update.

No, you are not indicating that. Section 5.3 states the following: "Pare= meters that have not changed SHOULD NOT be included in an update". As = a consequence the RD will not take any action on resources that a= re not contained in the payload.

Regards,

Alessandro

--=_b66f5336e79b339b5ee7c411114c71d4-- From Bert.Greevenbosch@huawei.com Wed Nov 14 18:44:40 2012 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 8FEA91F041A for ; Wed, 14 Nov 2012 18:44:40 -0800 (PST) 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 nryh40JUfgn3 for ; Wed, 14 Nov 2012 18:44:39 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFDB21F853C for ; Wed, 14 Nov 2012 18:44:39 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMU79660; Thu, 15 Nov 2012 02:44:37 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 15 Nov 2012 02:44:23 +0000 Received: from SZXEML431-HUB.china.huawei.com (10.72.61.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 15 Nov 2012 02:44:35 +0000 Received: from SZXEML509-MBX.china.huawei.com ([10.82.67.37]) by szxeml431-hub.china.huawei.com ([10.72.61.39]) with mapi id 14.01.0323.003; Thu, 15 Nov 2012 10:44:31 +0800 From: Bert Greevenbosch To: "core@ietf.org" Thread-Topic: The Profile Description and Minimum Request Interval drafts Thread-Index: Ac3C2yNltfzFRkjuQra7R7RmB0Y8gw== Date: Thu, 15 Nov 2012 02:44:32 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB629123711@szxeml509-mbx> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [core] The Profile Description and Minimum Request Interval drafts 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, 15 Nov 2012 02:44:40 -0000 Hello all, Since there was no time in Atlanta to discuss the Profile Format and Minimu= m Request Interval drafts, I would like to raise awareness through the list= . Below summaries of both drafts. I look forward to your comments! Best regards, Bert Profile Description =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D http://datatracker.ietf.org/doc/draft-greevenbosch-core-profile-description= / This draft provides a JSON format for signalling the server's capabilities.= It currently can signal supported options, media types and block sizes, bu= t other items can be added. It also provides a lookup mechanism by filterin= g on specific fields through a URI-Query. To acquire the profile data of resources on a particular service, the .well= -known/profile URI-path is introduced. For example, to get all information = from sensors served by www.example.org, we can do a GET to http://www.examp= le.org/.well-known/profile. An example is as follows: Request: GET coap://www.example.org/.well-known/profile=20 Response: 2.05 Content (application/json)=20 {=20 "profile":=20 {=20 "path":"cam", "op":[3,4,7,11,12,19,23,35],=20 "cf":[0,40,50]=20 "b2s":[4,5]=20 } } This is the profile of a camera sensor at "coap://www.example.org/cam", tha= t supports the "Uri-Host" (3), "ETag" (4), "Uri-Port" (7), "Uri-Path" (11),= "Content-Format" (12), "Token" (19), "Block2" (23) and "Proxy-Uri" (35) op= tions. The supported content formats are "text/plain" (0), "application/ li= nk-format" (40) and "application/json" (50). The supported Block2 can use 2= 56 or 512 byte blocks. Minimum Request Interval =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D http://datatracker.ietf.org/doc/draft-greevenbosch-core-minimum-request-int= erval/ The "MinimumRequestInterval" option can be used to indicate the minimum tim= e between two requests in a transaction. The mechanism was originally inten= ded for Block, but is now also usable for other transactions, such as brows= ing a server. In a request, the option contains the time interval between requests that t= he client is using. In a response, the option contains the minimum interval= that the client must obey. The goal is to reduce the server load and network traffic by slowing down t= he client, without delaying associated ACKs. From tho@koanlogic.com Thu Nov 15 01:44:28 2012 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 936F421F85CC for ; Thu, 15 Nov 2012 01:44:28 -0800 (PST) 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 ZIzFSb20NrM8 for ; Thu, 15 Nov 2012 01:44:28 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 76BBB21F85C8 for ; Thu, 15 Nov 2012 01:44:27 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so977073qca.31 for ; Thu, 15 Nov 2012 01:44:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=18JMargi8/BZCh6ZFLRuzrj7g0DCdql9zPJGLZ67pi8=; b=Gp88Cv2nVdIBTPrkYt/z8jp97Mu9GhDjicRRm5EUpueNL9l1Zp2UdHGSNYVk/Ewi5h 1Q/16ienrviKBu39WQkH6gHJGEhTUHmWnLm2H29G341ZDz6fxghtFmKxkt0eNFphL+mS rFL+ab+qSYJMAzKH5CteAAeLOi5augDoZ8Bv3lgzG7jQIFKJALGLUfKlMFs9w0MJ20+d gLYADdJ54Z++H0+RDfmqxcJ1fDYoILhMjIJ8tYQONigoSmEDjxz/5cyF/6KRgB6Z0WWp AUjegsXj48Fgj/LveYWcvRL2uoz/BtFC8gOCpKCqraVIVVVqpbyYVdeskxn4XQp0+jhV DMSg== MIME-Version: 1.0 Received: by 10.229.114.199 with SMTP id f7mr85220qcq.108.1352972666454; Thu, 15 Nov 2012 01:44:26 -0800 (PST) Received: by 10.49.2.72 with HTTP; Thu, 15 Nov 2012 01:44:26 -0800 (PST) X-Originating-IP: [81.134.152.4] In-Reply-To: References: <051.b150c522197456646133cd1bca831535@trac.tools.ietf.org> Date: Thu, 15 Nov 2012 09:44:26 +0000 Message-ID: From: Thomas Fossati To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlLYxOn69zgTZOB1bl11LoTOB+ZJyWChS/LjKdh5B5868BUfjC0VVY4dR/6eLHcHoJakd4j Subject: Re: [core] #259: Standardize a workaround for HTTP library limitations in talking to forward HTTP-COAP cross-proxies? 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, 15 Nov 2012 09:44:28 -0000 On Tue, Nov 6, 2012 at 1:25 PM, Thomas Fossati wrote: > On Tue, Nov 6, 2012 at 12:12 PM, core issue tracker > wrote: >> #259: Standardize a workaround for HTTP library limitations in talking to forward >> HTTP-COAP cross-proxies? > > Re to this, I've added a feature request to HTML5 > to let browsers configure their HTTP-CoAP forward proxy via the > registerProtocolHandler API. > > > Maybe worth doing some lobbying in this direction ? Follow-up to notify the list about the unsuccessful lobbying attempt: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19582 From cabo@tzi.org Tue Nov 20 01:59:57 2012 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 BDBFD21F8722 for ; Tue, 20 Nov 2012 01:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.949 X-Spam-Level: X-Spam-Status: No, score=-106.949 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, J_CHICKENPOX_42=0.6, 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 rhGXaX5BU58E for ; Tue, 20 Nov 2012 01:59:57 -0800 (PST) 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 C91C821F8736 for ; Tue, 20 Nov 2012 01:59:56 -0800 (PST) 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 qAK9xsYF026076 for ; Tue, 20 Nov 2012 10:59:54 +0100 (CET) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4148633F; Tue, 20 Nov 2012 10:59:54 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Nov 2012 10:59:53 +0100 To: "core@ietf.org WG" Message-Id: <59F91FE6-186E-46DD-A02A-A81689B44C5E@tzi.org> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [core] The CoAP Ping 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, 20 Nov 2012 09:59:57 -0000 Klaus came up with a way to "ping" CoAP servers: Send them an empty Confirmable message, i.e. with code=3D0 and no = payload. According to the letter of 4.2 in coap-12: A Confirmable message always carries either a request or response and MUST NOT be empty. A recipient MUST acknowledge such a message with an Acknowledgement message or, if it lacks context to process the message properly (including the case where the message is empty or has an encoding error), MUST reject it; rejecting a Confirmable message is effected by sending a matching Reset message and otherwise ignoring it. ... the server MUST send an RST message. Both messages are 4 bytes and are correlated by the Message ID; a great = basis for a "ping" type interaction. (And there is no amplification, making this less useful in an attack.) I wrote a little tool to make use of this: coaping $ coaping coap.me 5683 0.5 3 Trying 3 times with coap.me at port 5683, waiting 0.5 seconds max: 0 13.3 ms 2001:638:708:30da:221:70ff:fe46:17d3 1 3.6 ms 2001:638:708:30da:221:70ff:fe46:17d3 2 2.4 ms 2001:638:708:30da:221:70ff:fe46:17d3 To install, just type this (should work on any modern Linux/Unix/OSX, = more work on Windows): gem install coaping (or "sudo gem install coaping" if you need additional permission). Now the interesting questions for the WG: 1) Are we interpreting coap-12 right here? e.g., vs0.inf.ethz.ch sends back an empty ACK, not a RST. More importantly, 2) is this the right thing to require of a server? Or should the spec = change? Should we have ping-like functionality? Should that ping be based on = something else? Do we need a more elaborate ping? A traceroute? :-) Gr=FC=DFe, Carsten From hartke@tzi.org Tue Nov 20 02:25:30 2012 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 48BA021F858F for ; Tue, 20 Nov 2012 02:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, 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 MFYi6ib-djrX for ; Tue, 20 Nov 2012 02:25:29 -0800 (PST) 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 52CA221F85B4 for ; Tue, 20 Nov 2012 02:25:29 -0800 (PST) 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 qAKAPE9G011249 for ; Tue, 20 Nov 2012 11:25:14 +0100 (CET) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8ED43378 for ; Tue, 20 Nov 2012 11:25:13 +0100 (CET) Received: by mail-da0-f44.google.com with SMTP id h15so2617188dan.31 for ; Tue, 20 Nov 2012 02:25:11 -0800 (PST) Received: by 10.68.218.97 with SMTP id pf1mr47363778pbc.96.1353407111689; Tue, 20 Nov 2012 02:25:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.156.238 with HTTP; Tue, 20 Nov 2012 02:24:51 -0800 (PST) In-Reply-To: <59F91FE6-186E-46DD-A02A-A81689B44C5E@tzi.org> References: <59F91FE6-186E-46DD-A02A-A81689B44C5E@tzi.org> From: Klaus Hartke Date: Tue, 20 Nov 2012 12:24:51 +0200 Message-ID: To: "core@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] The CoAP Ping 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, 20 Nov 2012 10:25:30 -0000 Carsten Bormann wrote: > Klaus came up with a way to "ping" CoAP servers: > Send them an empty Confirmable message, i.e. with code=0 and no payload. Background: When the host in a CoAP URI is a DNS name, resolving the name can lead to multiple IP addresses. When applying the Happy Eyeballs algorithm [1], there is a need to determine a "winning connection". DTLS aside, we don't have a connection setup handshake that could be used for this. It's also not a good idea to make actual requests to the server, in particular if the method is POST, since the server likely does not deduplicate requests that it receives on different IP addresses. So I was looking for a harmless way to probe an IP address and port for a CoAP server, which the current behaviour specified in -coap seems to perfectly provide. Klaus [1] http://tools.ietf.org/html/rfc6555 From kovatsch@inf.ethz.ch Tue Nov 20 07:07:12 2012 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 ED9BF21F874A for ; Tue, 20 Nov 2012 07:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.11 X-Spam-Level: X-Spam-Status: No, score=-9.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] 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 b3lVGuw1F-G4 for ; Tue, 20 Nov 2012 07:07:05 -0800 (PST) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 08BBE21F874F for ; Tue, 20 Nov 2012 07:06:58 -0800 (PST) Received: from CAS12.d.ethz.ch (172.31.38.212) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 20 Nov 2012 16:06:40 +0100 Received: from MBX10.d.ethz.ch ([fe80::6d7b:f3da:a5b1:c9e9]) by CAS12.d.ethz.ch ([fe80::7861:4ecb:7c42:cad4%10]) with mapi id 14.02.0298.004; Tue, 20 Nov 2012 16:06:42 +0100 From: "Kovatsch Matthias" To: "core@ietf.org WG" Thread-Topic: CoAP jump mechanism Thread-Index: Ac3HLwlCd1JVVU2UQ3a8ARAWHlZt1g== Date: Tue, 20 Nov 2012 15:06:41 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [core] CoAP jump mechanism 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, 20 Nov 2012 15:07:12 -0000 Dear list We just stumbled upon some issues with coap-12's jump mechanism: The exact bounds should be given, just like for the option length encoding = to avoid problems due to the integer division. I also assumed that deltas 15..29 are handled by a 0xF1 jump. The text in F= igure 9, however, may also imply that 0xF1 is only used for delta=3D=3D15 a= nd for the overlapping region, 0xF2 SHOULD be used. I would prefer the 0xF1 jumps, as they save one byte. Or is this just left = to the implementation? Ciao Matthias From mab@comnets.uni-bremen.de Tue Nov 20 08:02:19 2012 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 5A6A521F84EB for ; Tue, 20 Nov 2012 08:02:19 -0800 (PST) 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 FcRK1ciq4jn8 for ; Tue, 20 Nov 2012 08:02:13 -0800 (PST) Received: from bugs.comnets.uni-bremen.de (bugs.comnets.uni-bremen.de [IPv6:2001:638:708:1155::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E07C21F850E for ; Tue, 20 Nov 2012 08:02:13 -0800 (PST) Received: from shelbyville.comnets.uni-bremen.de (shelbyville [10.10.155.50]) by bugs.comnets.uni-bremen.de (Postfix) with ESMTPS id F0993D4014C for ; Tue, 20 Nov 2012 17:02:11 +0100 (CET) From: Markus Becker Organization: Comnets, University Bremen To: core@ietf.org Date: Tue, 20 Nov 2012 17:02:10 +0100 User-Agent: KMail/1.13.7 (Linux/3.5-trunk-686-pae; KDE/4.8.4; i686; ; ) References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201211201702.11180.mab@comnets.uni-bremen.de> Subject: Re: [core] CoAP jump mechanism 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, 20 Nov 2012 16:02:19 -0000 > Dear list > > We just stumbled upon some issues with coap-12's jump mechanism: > > The exact bounds should be given, just like for the option length encoding > to avoid problems due to the integer division. I also assumed that deltas > 15..29 are handled by a 0xF1 jump. > The text in Figure 9, however, may also > imply that 0xF1 is only used for delta==15 and for the overlapping region, > 0xF2 SHOULD be used. Hello Matthias, when implementing this, I read this figure exactly the way you say in the sentence above. The interpretation of the figure, might as well impact the ETSI interop event. If read otherwise, the (Delta/8)-2 should be different, so that there is no overlap, or? Then, a delta of 30 should be coded to 0xf2 0x00? Thus, the equation becomes Delta-30. Similarly, (Delta/8)-258 should be changed. For 15..29: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 1 1 | 0 0 0 1 | 0xf1 +---+---+---+---+---+---+---+---+ For 30..269: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 1 1 | 0 0 1 0 | 0xf2 +---+---+---+---+---+---+---+---+ | Option Jump Value | Delta-30 +---+---+---+---+---+---+---+---+ For 270..65818: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 1 1 | 0 0 1 1 | 0xf3 +---+---+---+---+---+---+---+---+ | | +--- Option Jump Value ---+ Delta-270 | | +---+---+---+---+---+---+---+---+ Markus > I would prefer the 0xF1 jumps, as they save one byte. > Or is this just left to the implementation? > > Ciao > Matthias > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core ------------------------------------------------ | Dipl.-Ing. Markus Becker | Communication Networks | TZI - Center for Computing Technologies | University Bremen | Germany ------------------------------------------------ | web: http://www.comnets.uni-bremen.de/~mab/ | mailto: mab@comnets.uni-bremen.de | telephone: +49 421 218 62379 | building: NW1 room: N2260 ------------------------------------------------ From cabo@tzi.org Tue Nov 20 09:09:04 2012 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 1692521F8803 for ; Tue, 20 Nov 2012 09:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.416 X-Spam-Level: X-Spam-Status: No, score=-106.416 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 ho9pAYl5IbET for ; Tue, 20 Nov 2012 09:09:03 -0800 (PST) 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 4EF3821F87F2 for ; Tue, 20 Nov 2012 09:09:02 -0800 (PST) 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 qAKH8s4d014630; Tue, 20 Nov 2012 18:08:54 +0100 (CET) Received: from [192.168.217.117] (p548933ED.dip.t-dialin.net [84.137.51.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9420A287; Tue, 20 Nov 2012 18:08:54 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> Date: Tue, 20 Nov 2012 18:08:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> To: "Kovatsch Matthias" X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] CoAP jump mechanism 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, 20 Nov 2012 17:09:04 -0000 On Nov 20, 2012, at 16:06, "Kovatsch Matthias" = wrote: > Dear list >=20 > We just stumbled upon some issues with coap-12's jump mechanism: >=20 > The exact bounds should be given, just like for the option length = encoding to avoid problems due to the integer division. > I also assumed that deltas 15..29 are handled by a 0xF1 jump. That is the intention. (15 is handled by 0xf1, and the rest of 0..14 is handled by a normal = delta.) > The text in Figure 9, however, may also imply that 0xF1 is only used = for delta=3D=3D15 and for the overlapping region, 0xF2 SHOULD be used. > I would prefer the 0xF1 jumps, as they save one byte. Or is this just = left to the implementation? The delta in Fig 9 is the one effected by the Jump. The 4-bit delta in = the following option has to be added to that. (Yes, this could be said explicitly.) I agree that it would be nicer if there were no overlap between the = deltas covered by "f1 xy" and "f2 nn xy". Unfortunately, what we wrote = down in coap-12 has this overlap (caused by the attempt to avoid a = division by 15), and the specific approach I chose was not so bright. We could go ahead and introduce *another* breaking change, or live with = the slight inefficiency for a number of option deltas around 2070 (which = could be "f2 ff xy" instead of "f3 00 00 xy" if there were no overlap). Gr=FC=DFe, Carsten From cabo@tzi.org Tue Nov 20 09:54:41 2012 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 CEB8C21F8685 for ; Tue, 20 Nov 2012 09:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.404 X-Spam-Level: X-Spam-Status: No, score=-106.404 tagged_above=-999 required=5 tests=[AWL=-0.155, 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 ribD8ggMu8MV for ; Tue, 20 Nov 2012 09:54:39 -0800 (PST) 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 375E021F87A3 for ; Tue, 20 Nov 2012 09:54:38 -0800 (PST) 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 qAKHsSA1006316; Tue, 20 Nov 2012 18:54:28 +0100 (CET) Received: from [192.168.217.117] (p548933ED.dip.t-dialin.net [84.137.51.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 91A492D1; Tue, 20 Nov 2012 18:54:28 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <201211201702.11180.mab@comnets.uni-bremen.de> Date: Tue, 20 Nov 2012 18:54:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <201211201702.11180.mab@comnets.uni-bremen.de> To: Markus Becker X-Mailer: Apple Mail (2.1499) Cc: core@ietf.org Subject: Re: [core] CoAP jump mechanism 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, 20 Nov 2012 17:54:42 -0000 On Nov 20, 2012, at 17:02, Markus Becker = wrote: > For 30..269: > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | 1 1 1 1 | 0 0 1 0 | 0xf2 > +---+---+---+---+---+---+---+---+ > | Option Jump Value | Delta-30 > +---+---+---+---+---+---+---+---+ >=20 > For 270..65818: > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | 1 1 1 1 | 0 0 1 1 | 0xf3 > +---+---+---+---+---+---+---+---+ > | | > +--- Option Jump Value ---+ Delta-270 > | | > +---+---+---+---+---+---+---+---+ Ah, but the Jump value is multiplied by 8 to get the actual delta (plus = some constant) -- we still have the 4-bit delta in the actual option = header for the rest. So if we did this, 0xf2 would reach from 30 to 2084, and only for 2085+ = you would need 0xf3. (Right now, that number is 2071; so the net effect of the mistake I made = is that we waste a byte for total (jump + 4-bit) option number deltas = between 2071 and 2084; I still believe that is a livable loss for not = introducing another breaking change.) So if you want to give exact ranges and start from totalDelta, for what = is in coap-12 now: > For totalDelta between 30..2070: > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | 1 1 1 1 | 0 0 1 0 | 0xf2 > +---+---+---+---+---+---+---+---+ > | Option Jump Value | (totalDelta-23)/8 > +---+---+---+---+---+---+---+---+ >=20 > For totalDelta 2071..65535: > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > | 1 1 1 1 | 0 0 1 1 | 0xf3 > +---+---+---+---+---+---+---+---+ > | | > +--- Option Jump Value ---+ (totalDelta-2071)/8 > | | > +---+---+---+---+---+---+---+---+ (And, if I hadn't had that thinko, it would be -37 instead of -23 and = -2085 instead of -2071. I think :-) That's what you get for retrofitting something like this; by now I of = course have a completely different, "cleaner" design in mind, but that = wouldn't be less code either. Gr=FC=DFe, Carsten From kovatsch@inf.ethz.ch Tue Nov 20 09:58:38 2012 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 1051D21F87A3 for ; Tue, 20 Nov 2012 09:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.854 X-Spam-Level: X-Spam-Status: No, score=-7.854 tagged_above=-999 required=5 tests=[AWL=-1.255, 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 IkarPUb2LcDa for ; Tue, 20 Nov 2012 09:58:37 -0800 (PST) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id 370CD21F8628 for ; Tue, 20 Nov 2012 09:58:37 -0800 (PST) Received: from CAS11.d.ethz.ch (172.31.38.211) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 20 Nov 2012 18:58:32 +0100 Received: from MBX10.d.ethz.ch ([fe80::6d7b:f3da:a5b1:c9e9]) by CAS11.d.ethz.ch ([fe80::ecc9:4e2d:b26b:1614%10]) with mapi id 14.02.0298.004; Tue, 20 Nov 2012 18:58:35 +0100 From: "Kovatsch Matthias" To: Carsten Bormann Thread-Topic: [core] CoAP jump mechanism Thread-Index: Ac3HLwlCd1JVVU2UQ3a8ARAWHlZt1gACkyKAAAN61GA= Date: Tue, 20 Nov 2012 17:58:34 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> In-Reply-To: <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "core@ietf.org WG" Subject: Re: [core] CoAP jump mechanism 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, 20 Nov 2012 17:58:38 -0000 > > The exact bounds should be given, just like for the option length encod= ing > to avoid problems due to the integer division. > > I also assumed that deltas 15..29 are handled by a 0xF1 jump. >=20 > That is the intention. > (15 is handled by 0xf1, and the rest of 0..14 is handled by a normal delt= a.) Okay, good to be clear on that. > > The text in Figure 9, however, may also imply that 0xF1 is only used fo= r > delta=3D=3D15 and for the overlapping region, 0xF2 SHOULD be used. > > I would prefer the 0xF1 jumps, as they save one byte. Or is this just l= eft to > the implementation? >=20 > The delta in Fig 9 is the one effected by the Jump. The 4-bit delta in t= he > following option has to be added to that. > (Yes, this could be said explicitly.) I was only confused because the overlap was not mentioned at all and usuall= y the draft is quite helpful with implementation considerations :) > I agree that it would be nicer if there were no overlap between the delta= s > covered by "f1 xy" and "f2 nn xy". Unfortunately, what we wrote down in > coap-12 has this overlap (caused by the attempt to avoid a division by 15= ), > and the specific approach I chose was not so bright. > We could go ahead and introduce *another* breaking change, or live with > the slight inefficiency for a number of option deltas around 2070 (which = could > be "f2 ff xy" instead of "f3 00 00 xy" if there were no overlap). Yeah, let us just keep it this way, otherwise we need another strange summa= nd in the formula... Ciao Matthias From Bert.Greevenbosch@huawei.com Wed Nov 21 18:52:24 2012 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 85E8F21E8053 for ; Wed, 21 Nov 2012 18:52:24 -0800 (PST) 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 tsESEp3cU92C for ; Wed, 21 Nov 2012 18:52:23 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3732A21E8048 for ; Wed, 21 Nov 2012 18:52:22 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALU21668; Thu, 22 Nov 2012 02:52:19 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 22 Nov 2012 02:51:46 +0000 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 22 Nov 2012 02:52:15 +0000 Received: from SZXEML509-MBX.china.huawei.com ([10.82.67.37]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.003; Thu, 22 Nov 2012 10:52:09 +0800 From: Bert Greevenbosch To: "Kovatsch Matthias" , Carsten Bormann Thread-Topic: [core] CoAP jump mechanism Thread-Index: Ac3HLwlCd1JVVU2UQ3a8ARAWHlZt1v//n0CAgAAN4QD//WsngA== Date: Thu, 22 Nov 2012 02:52:08 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "core@ietf.org WG" Subject: Re: [core] CoAP jump mechanism 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, 22 Nov 2012 02:52:24 -0000 Hi all, This is a good opportunity to dig up my (now rather dusty) knowledge about = interval analysis from my university times, even though that was continuous= math, whereas here we work in the discrete domain. Two intervals A=3D[aL,aH] and B=3D[bL,bH] can be added through the rule A+B= =3D[aL+bL,aH+bH]. Below, I will be cheating a little as in the continuous domain, multiplying= an interval by a constant properly leads to an interval that contains all = values between its minimum and maximum, whereas in the discrete domain hole= s within the interval appear. We can signal the regular option deltas 0..14 without long jump; the relate= d interval is Dr=3D[0,14]. We denote the long jump interval for 0xf1 by L1=3D[15,15], for 0xf2 by L2 a= nd for 0xf3 by L3. The option deltas that can be reached through 0xf1 are t= hus within D1=3DL1+Dr=3D[15,29]. For 0xf2, 0<=3D(Delta/8)-2<=3D255 resolves to L2=3D[16,2056] =3D> D2=3DL2+D= r=3D[16,2070]. We see an overlap D1^D2=3D[16,29] (14 values). For 0xf3, 0<=3D(Delta/8)-258<=3D65535 resolves to L3=3D[2064,526344] =3D> D= 3=3DL3+Dr=3D[2064,526358]. Another overlap D2^D3=3D[2064,2070] (7 values). I believe the form (Delta/8)-x indeed is best, as division by non-powers of= two is cumbersome, and dividing by 16 would lead to holes due to the size = of Dr. However, dividing by 8 means that we cannot avoid all overlap. So for 0xf2, 0<=3D(Delta/8)-x2<=3D255 would resolve to L2=3D[8*x2,2040+8*x2= ] and thus D2=3D[8*x2,2054+8*x2]. To minimise the overlap, it would be best= if we chose the highest x2 such that 8*x2<=3D30. This leads to x2=3Dfloor(= 30/8)=3D3, whereas currently it is specified as 2. The new value would give= D2=3D[24,2078], implying an overlap D1^D2=3D[24,29] (6 values). For 0xf3, 0<=3D(Delta/8)-x3<=3D65535 gives L3=3D[8*x3,524280+8*x3] and D3= =3D[8*x3,524294+8*x3]. Taking x2=3D3, to avoid overlap, we need to maximise= x3 such that 8*x3<=3D2079 =3D> x3=3D259. This gives D3=3D[2072,526366] and= an overlap D2^D3=3D[2072,2078] (7 values). Summary ------- Changing the formulas to (Delta/8)-3 for 0xf2 and (Delta/8)-259 for 0xf3 wo= uld save us 8 overlapping values. I am not sure if this justifies a change in the spec though (since it is no= n-editorial, though small). Probably a far too complicated way to come to this conclusion, but at least= it confirms earlier findings... :-) Best regards, Bert -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Kov= atsch Matthias Sent: 21 November 2012 01:59 To: Carsten Bormann Cc: core@ietf.org WG Subject: Re: [core] CoAP jump mechanism > > The exact bounds should be given, just like for the option length encod= ing > to avoid problems due to the integer division. > > I also assumed that deltas 15..29 are handled by a 0xF1 jump. >=20 > That is the intention. > (15 is handled by 0xf1, and the rest of 0..14 is handled by a normal delt= a.) Okay, good to be clear on that. > > The text in Figure 9, however, may also imply that 0xF1 is only used fo= r > delta=3D=3D15 and for the overlapping region, 0xF2 SHOULD be used. > > I would prefer the 0xF1 jumps, as they save one byte. Or is this just l= eft to > the implementation? >=20 > The delta in Fig 9 is the one effected by the Jump. The 4-bit delta in t= he > following option has to be added to that. > (Yes, this could be said explicitly.) I was only confused because the overlap was not mentioned at all and usuall= y the draft is quite helpful with implementation considerations :) > I agree that it would be nicer if there were no overlap between the delta= s > covered by "f1 xy" and "f2 nn xy". Unfortunately, what we wrote down in > coap-12 has this overlap (caused by the attempt to avoid a division by 15= ), > and the specific approach I chose was not so bright. > We could go ahead and introduce *another* breaking change, or live with > the slight inefficiency for a number of option deltas around 2070 (which = could > be "f2 ff xy" instead of "f3 00 00 xy" if there were no overlap). Yeah, let us just keep it this way, otherwise we need another strange summa= nd in the formula... Ciao Matthias _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From trac+core@trac.tools.ietf.org Thu Nov 22 00:53:15 2012 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 E1D4621F873F for ; Thu, 22 Nov 2012 00:53:15 -0800 (PST) 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 J1ylUA-WQGFt for ; Thu, 22 Nov 2012 00:53:15 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id DEAFB21F8711 for ; Thu, 22 Nov 2012 00:53:14 -0800 (PST) Received: from localhost ([127.0.0.1]:33387 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TbSWg-0007OJ-Uc; Thu, 22 Nov 2012 09:52:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, esko.dijk@philips.com, zach@sensinode.com X-Trac-Project: core Date: Thu, 22 Nov 2012 08:52:50 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/core/trac/ticket/247#comment:4 Message-ID: <075.42bb4b64c1ea2270b9f656f86fa6f4b1@trac.tools.ietf.org> References: <060.165feff053c11cfa0d65de452eb53ed9@trac.tools.ietf.org> X-Trac-Ticket-ID: 247 In-Reply-To: <060.165feff053c11cfa0d65de452eb53ed9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, esko.dijk@philips.com, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: brian@skyfoundry.com, cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20121122085314.DEAFB21F8711@ietfa.amsl.com> Resent-Date: Thu, 22 Nov 2012 00:53:14 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #247: Scalability questions IANA review for IPv6/IPv4 multicast address request X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 08:53:16 -0000 #247: Scalability questions IANA review for IPv6/IPv4 multicast address request Comment (by esko.dijk@philips.com): Noting the discussion on the list about an easy-to-remember multicast address similar to BACnet (FF0x::BAC0). Proposals are: FF0x::C0 FF0x::C0A7 https://www.ietf.org/mail-archive/web/core/current/msg03801.html -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | coap@tools.ietf.org Type: protocol | Status: new defect | Milestone: post-WGLC-1 Priority: major | Version: Component: coap | Resolution: Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu Nov 22 00:56:14 2012 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 BBEF221F87AA for ; Thu, 22 Nov 2012 00:56:14 -0800 (PST) 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 mLmvehE5+KZb for ; Thu, 22 Nov 2012 00:56:14 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 32B7521F8484 for ; Thu, 22 Nov 2012 00:56:14 -0800 (PST) Received: from localhost ([127.0.0.1]:34649 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TbSZt-0004Co-4J; Thu, 22 Nov 2012 09:56:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, esko.dijk@philips.com, zach@sensinode.com X-Trac-Project: core Date: Thu, 22 Nov 2012 08:56:09 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/core/trac/ticket/247#comment:5 Message-ID: <075.9fef2bdd47c1afd519f6e0d571dbb841@trac.tools.ietf.org> References: <060.165feff053c11cfa0d65de452eb53ed9@trac.tools.ietf.org> X-Trac-Ticket-ID: 247 In-Reply-To: <060.165feff053c11cfa0d65de452eb53ed9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, esko.dijk@philips.com, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: brian@skyfoundry.com, cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20121122085614.32B7521F8484@ietfa.amsl.com> Resent-Date: Thu, 22 Nov 2012 00:56:14 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #247: Scalability questions IANA review for IPv6/IPv4 multicast address request X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 08:56:14 -0000 #247: Scalability questions IANA review for IPv6/IPv4 multicast address request Changes (by esko.dijk@philips.com): * priority: major => minor Comment: Noting agreement with IANA and address request reviewer: - allocation will be done at time of core-coap publication when all details are worked out. - IPv4 allocation in Internetwork Control Block is okay; Adhoc Block not needed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | coap@tools.ietf.org Type: protocol | Status: new defect | Milestone: post-WGLC-1 Priority: minor | Version: Component: coap | Resolution: Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From esko.dijk@philips.com Thu Nov 22 01:44:23 2012 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 283E421F8815 for ; Thu, 22 Nov 2012 01:44:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.972 X-Spam-Level: X-Spam-Status: No, score=-3.972 tagged_above=-999 required=5 tests=[AWL=1.027, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_42=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 lZ3MagW2RVEz for ; Thu, 22 Nov 2012 01:44:22 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2058221F8735 for ; Thu, 22 Nov 2012 01:44:22 -0800 (PST) Received: from mail24-va3-R.bigfish.com (10.7.14.239) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 14.1.225.23; Thu, 22 Nov 2012 09:44:21 +0000 Received: from mail24-va3 (localhost [127.0.0.1]) by mail24-va3-R.bigfish.com (Postfix) with ESMTP id 0C31310022A; Thu, 22 Nov 2012 09:44:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -33 X-BigFish: VPS-33(zz217bI15d6O9251Jc89bh168aJ542Mzz1de0h1202h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h15d0l1155h) Received: from mail24-va3 (localhost.localdomain [127.0.0.1]) by mail24-va3 (MessageSwitch) id 1353577459143103_22326; Thu, 22 Nov 2012 09:44:19 +0000 (UTC) Received: from VA3EHSMHS015.bigfish.com (unknown [10.7.14.249]) by mail24-va3.bigfish.com (Postfix) with ESMTP id 15FED6007A; Thu, 22 Nov 2012 09:44:19 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by VA3EHSMHS015.bigfish.com (10.7.99.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 22 Nov 2012 09:44:18 +0000 Received: from 011-DB3MMR1-015.MGDPHG.emi.philips.com (10.128.28.99) by 011-DB3MMR1-004.MGDPHG.emi.philips.com (10.128.28.54) with Microsoft SMTP Server (TLS) id 14.2.318.3; Thu, 22 Nov 2012 09:44:17 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.209]) by 011-DB3MMR1-015.MGDPHG.emi.philips.com ([10.128.28.99]) with mapi id 14.02.0318.003; Thu, 22 Nov 2012 09:44:17 +0000 From: "Dijk, Esko" To: Carsten Bormann , "core@ietf.org WG" Thread-Topic: [core] The CoAP Ping Thread-Index: AQHNxwXQg+yvTnKkek+XseW2kwn0CZf1nDZA Date: Thu, 22 Nov 2012 09:44:17 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618B25C6E@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <59F91FE6-186E-46DD-A02A-A81689B44C5E@tzi.org> In-Reply-To: <59F91FE6-186E-46DD-A02A-A81689B44C5E@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.103] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [core] The CoAP Ping 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, 22 Nov 2012 09:44:23 -0000 > 1) Are we interpreting coap-12 right here? Yes, in my view - the text mentions the empty message case explicitly. > 2) is this the right thing to require of a server? Or should the spec ch= ange? Suppose we change the spec to let the server not respond to empty CON messa= ge. Then I can still 'ping' it by sending a malformed ("encoding error") CoAP C= ON message. So it would not matter much I assume whether the server responds to empty C= ON messages or not? The ping function would still be there. Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Car= sten Bormann Sent: Tuesday 20 November 2012 11:00 To: core@ietf.org WG Subject: [core] The CoAP Ping Klaus came up with a way to "ping" CoAP servers: Send them an empty Confirmable message, i.e. with code=3D0 and no payload. According to the letter of 4.2 in coap-12: A Confirmable message always carries either a request or response and MUST NOT be empty. A recipient MUST acknowledge such a message with an Acknowledgement message or, if it lacks context to process the message properly (including the case where the message is empty or has an encoding error), MUST reject it; rejecting a Confirmable message is effected by sending a matching Reset message and otherwise ignoring it. ... the server MUST send an RST message. Both messages are 4 bytes and are correlated by the Message ID; a great bas= is for a "ping" type interaction. (And there is no amplification, making this less useful in an attack.) I wrote a little tool to make use of this: coaping $ coaping coap.me 5683 0.5 3 Trying 3 times with coap.me at port 5683, waiting 0.5 seconds max: 0 13.3 ms 2001:638:708:30da:221:70ff:fe46:17d3 1 3.6 ms 2001:638:708:30da:221:70ff:fe46:17d3 2 2.4 ms 2001:638:708:30da:221:70ff:fe46:17d3 To install, just type this (should work on any modern Linux/Unix/OSX, more = work on Windows): gem install coaping (or "sudo gem install coaping" if you need additional permission). Now the interesting questions for the WG: 1) Are we interpreting coap-12 right here? e.g., vs0.inf.ethz.ch sends back an empty ACK, not a RST. More importantly, 2) is this the right thing to require of a server? Or should the spec chan= ge? Should we have ping-like functionality? Should that ping be based on somet= hing else? Do we need a more elaborate ping? A traceroute? :-) Gr=FC=DFe, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From hartke@tzi.org Thu Nov 22 03:23:46 2012 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 E719F21F8617 for ; Thu, 22 Nov 2012 03:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, 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 CVfeDc7gbcYP for ; Thu, 22 Nov 2012 03:23:46 -0800 (PST) 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 1DBFE21F85D8 for ; Thu, 22 Nov 2012 03:23:45 -0800 (PST) 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 qAMBNcYr018697 for ; Thu, 22 Nov 2012 12:23:38 +0100 (CET) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id EEAF3F60 for ; Thu, 22 Nov 2012 12:23:37 +0100 (CET) Received: by mail-pa0-f44.google.com with SMTP id hz11so3817213pad.31 for ; Thu, 22 Nov 2012 03:23:36 -0800 (PST) Received: by 10.66.79.72 with SMTP id h8mr522737pax.49.1353583416094; Thu, 22 Nov 2012 03:23:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.156.238 with HTTP; Thu, 22 Nov 2012 03:23:14 -0800 (PST) In-Reply-To: <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> From: Klaus Hartke Date: Thu, 22 Nov 2012 13:23:14 +0200 Message-ID: To: "core@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] CoAP jump mechanism 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, 22 Nov 2012 11:23:47 -0000 Bert Greevenbosch wrote: > Changing the formulas to (Delta/8)-3 for 0xf2 and (Delta/8)-259 for 0xf3 would save us 8 overlapping values. > > I am not sure if this justifies a change in the spec though (since it is non-editorial, though small). I wouldn't worry too much about this small inefficiency. What actually bothers me is the accumulated wealth of different solutions for the same problem: At the beginning, the message format was designed for 0 to 15 option instances, each with a delta between 0 and 15 and a value length between 0 and 15. All of these three artificial limitations were found to low over time, so we ended up with a zoo of mechanisms to work around them: * option count: (1) OC field, (2) end-of-options marker; * delta: (1) option header, (2) jump by 15, (3) long jump; * option length: (1) option header, (2) elongated option header. The result is surely a small packet size, but I'm wondering if this also applies to code size and the amount of head-scratching that an implementer needs to do to get an implementation of CoAP. Klaus From cabo@tzi.org Thu Nov 22 06:29:49 2012 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 6AAAF21F84DA for ; Thu, 22 Nov 2012 06:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.394 X-Spam-Level: X-Spam-Status: No, score=-106.394 tagged_above=-999 required=5 tests=[AWL=-0.145, 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 Y1WVtMTpl3vx for ; Thu, 22 Nov 2012 06:29:48 -0800 (PST) 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 89FF421F890D for ; Thu, 22 Nov 2012 06:29:48 -0800 (PST) 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 qAMETf9M027318 for ; Thu, 22 Nov 2012 15:29:41 +0100 (CET) Received: from [192.168.217.105] (p5489334E.dip.t-dialin.net [84.137.51.78]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4580411E; Thu, 22 Nov 2012 15:29:41 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Thu, 22 Nov 2012 15:29:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> To: Klaus Hartke X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] CoAP jump mechanism 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, 22 Nov 2012 14:29:49 -0000 On Nov 22, 2012, at 12:23, Klaus Hartke wrote: > a zoo of mechanisms > to work around them: >=20 > * option count: (1) OC field, (2) end-of-options marker; > * delta: (1) option header, (2) jump by 15, (3) long jump; > * option length: (1) option header, (2) elongated option header. The three numbers have a different use, a different nature, and a = different distribution function. For all of them, there is a likely small case and less likely larger = cases. So having two cases in each of them is just fine. The delta is a bit more different because it can get very large due to = the way we changed the registration policies. So we have three = (actually: four) cases. I think we have lamented about the operation wound left by the surgical = removal of fenceposts already :-) Yes, there is a little scar on the code because of that. But this is = ten lines of code. (I also have a design in mind that would be nine lines of code. But = let's not go there at this point...) Honestly, what worries me myself a bit more is that many implementers = these days have trouble figuring out arithmetic. As another data point, base32 was replaced by base16 in = draft-farrell-decade-ni-10.txt because implementers thought that = juggling 5-bit units in 8-bit bytes was "too hard" (and this isn't even = about constrained systems). Well, it doesn't make too much of a = difference here, so we are now stuck with base16. I learn from that: protocols should be designed to be implementable = requiring minimal arithmetic skills from the implementers, and I'm happy = to accept this as another non-technical requirement. I think we are safe here with CoAP for option count and option length.=20= For delta, where the design is now a tiny bit suboptimal, we probably = should write a couple more lines in the lwig document. Fortunately, all these number ranges are small enough that implementers = can (and should!) write exhaustive automatic tests for them. Gr=FC=DFe, Carsten From hartke@tzi.org Thu Nov 22 07:23:58 2012 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 69C7521F8919 for ; Thu, 22 Nov 2012 07:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, 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 uEWMnxJLo2f3 for ; Thu, 22 Nov 2012 07:23:57 -0800 (PST) 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 4464B21F8915 for ; Thu, 22 Nov 2012 07:23:57 -0800 (PST) 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 qAMFNmV2028196 for ; Thu, 22 Nov 2012 16:23:49 +0100 (CET) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id EEE0E190 for ; Thu, 22 Nov 2012 16:23:47 +0100 (CET) Received: by mail-pb0-f44.google.com with SMTP id uo1so5902602pbc.31 for ; Thu, 22 Nov 2012 07:23:46 -0800 (PST) Received: by 10.68.247.39 with SMTP id yb7mr5926003pbc.15.1353597826061; Thu, 22 Nov 2012 07:23:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.156.238 with HTTP; Thu, 22 Nov 2012 07:23:25 -0800 (PST) In-Reply-To: <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> From: Klaus Hartke Date: Thu, 22 Nov 2012 17:23:25 +0200 Message-ID: To: "core@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] CoAP jump mechanism 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, 22 Nov 2012 15:23:58 -0000 Carsten Bormann wrote: > Honestly, what worries me myself a bit more is that many implementers these days have trouble figuring out arithmetic. Figuring out clever arithmetic is not the problem -- in particular if this leads to an overall small packet size and code size. What I dislike is that there are 6+ instances where a different arithmetic needs to be figured out, just to solve the same problem: that 4 bits are not enough to encode the useful range of option counts, deltas and lengths. Why can't the same code (consisting of two cases) be used for all three numbers? I see how we ended up where we are: For us, it's much easier to just change a few lines in our existing code base and make a small change to the draft, than to come up with a new format that is easy to implement in new code bases. In my opinion though we should optimize for new CoAP implementations with constrained code size, and not primarily for minimal changes to the existing implementations. > I think we have lamented about the operation wound left by the surgical removal of fenceposts already :-) I attended the Atlanta meeting only remotely, but to me it felt like the audience was quicker to agree to this change than you were. Did I get a wrong impression? > For delta, where the design is now a tiny bit suboptimal, we probably should write a couple more lines in the lwig document. I would argue for less lines of code and text, not for more. Klaus From cabo@tzi.org Thu Nov 22 07:48:29 2012 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 DFB7F21F880B for ; Thu, 22 Nov 2012 07:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.385 X-Spam-Level: X-Spam-Status: No, score=-106.385 tagged_above=-999 required=5 tests=[AWL=-0.136, 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 yjp0vPG7UbNR for ; Thu, 22 Nov 2012 07:48:29 -0800 (PST) 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 092A821F8807 for ; Thu, 22 Nov 2012 07:48:24 -0800 (PST) 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 qAMFmHbj010847 for ; Thu, 22 Nov 2012 16:48:18 +0100 (CET) Received: from [192.168.217.105] (p5489334E.dip.t-dialin.net [84.137.51.78]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 89C471BC; Thu, 22 Nov 2012 16:48:17 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Thu, 22 Nov 2012 16:48:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <67619223-260B-4C11-8509-795B93DC3F29@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> To: Klaus Hartke X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] CoAP jump mechanism 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, 22 Nov 2012 15:48:30 -0000 On Nov 22, 2012, at 16:23, Klaus Hartke wrote: > What I dislike is that there are 6+ instances where a different > arithmetic needs to be figured out We heard you. All but the delta computation for jump are trivial, though. (And that's where I think documentation solves the problem nicely, = because the resulting code still is trivial.) There may be some cognitive dissonance in what we arrived at over time, = but there is no design from scratch that is actually significantly = simpler. In engineering, you have to know when to stop tweaking... Gr=FC=DFe, Carsten From zach@sensinode.com Thu Nov 22 08:02:53 2012 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 8045421F89CE for ; Thu, 22 Nov 2012 08:02:53 -0800 (PST) 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 Npnxi5hYexB8 for ; Thu, 22 Nov 2012 08:02:52 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id B8FAF21F8919 for ; Thu, 22 Nov 2012 08:02:51 -0800 (PST) Received: from [172.20.10.4] (84-231-176-183.elisa-mobile.fi [84.231.176.183]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id qAMG2lET011259; Thu, 22 Nov 2012 18:02:47 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Thu, 22 Nov 2012 18:02:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> To: Klaus Hartke X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org WG" Subject: Re: [core] CoAP jump mechanism 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, 22 Nov 2012 16:02:53 -0000 On Nov 22, 2012, at 5:23 PM, Klaus Hartke wrote: > What I dislike is that there are 6+ instances where a different > arithmetic needs to be figured out, just to solve the same problem: > that 4 bits are not enough to encode the useful range of option > counts, deltas and lengths. Why can't the same code (consisting of two > cases) be used for all three numbers? Do you have a particular proposal in mind?=20 I would argue that it is too late to make huge changes or redesign from = scratch - we have a lot of industry really using this and just promised = that coap-12 was the last breaking compatibility change (with WG = consensus behind it). That said, if there is something we can remove, = simplify or explain better that does not break backward compatibility = with coap-12, then we should definitely consider it. In particular if = there is something that can be simply removed or simplified that is not = really needed, that would be perfectly fine at this point.=20 > I see how we ended up where we are: For us, it's much easier to just > change a few lines in our existing code base and make a small change > to the draft, than to come up with a new format that is easy to > implement in new code bases. The IETF has a policy of running code for a good reason, but it does = result in having to realize protocol evolution as you are really using a = protocol and moving it towards RFC while working out issues. I think = we've done a great job of that, and have had running code and real = products using our specifications all along. The downside is that you = need to evolve a protocol and can't just do a fresh re-design. I totally = prefer this to what is done in many SDOs - design a monster of a = protocol, publish the standard, then cross your fingers and hope it will = work :-/ Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From tho@koanlogic.com Thu Nov 22 08:42:41 2012 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 9A1A221F85A1 for ; Thu, 22 Nov 2012 08:42:41 -0800 (PST) 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=[AWL=-0.000, 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 nTO9ckCd6ICT for ; Thu, 22 Nov 2012 08:42:41 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id E668621F859E for ; Thu, 22 Nov 2012 08:42:40 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so6409201qca.31 for ; Thu, 22 Nov 2012 08:42:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=x8rvjf8rSu0DS431sZ081Rhvd7ceXBgbQcXukfAt4Zs=; b=iUFeStDkdp23WkB7wr9F6UxqLJ/EhD3vHfhguI/4Wq+mr+YRo2GwV7Vl6tVXx7GFw9 Z7j4qdGC0hqD1D3TVVh9qstxRqP471ElN+auYJKW3WTN3QdMaTyEGP5ITfwmq+5lTl1x tGsJaLYFgIbAtjxQqM+zqjQtBGVK5a+zZbDIHGT9/QmEBQp7s59l5IwehU932CeP/mIs I0LaagTeazOScPBcqxbBtOGGz4ErOzrrnNHHwyxljgSd8gpljUUsjnIJUy2apOsz/w6L l6QDYcMzlGNbIPGb4i3ZUJoogrPBsbqoC9p7tIHy70JhD91+yB8nPsleM8sm8D8ORcE3 dG/Q== MIME-Version: 1.0 Received: by 10.49.83.129 with SMTP id q1mr1277746qey.11.1353602560137; Thu, 22 Nov 2012 08:42:40 -0800 (PST) Received: by 10.49.2.72 with HTTP; Thu, 22 Nov 2012 08:42:39 -0800 (PST) X-Originating-IP: [81.134.152.4] In-Reply-To: References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> Date: Thu, 22 Nov 2012 16:42:39 +0000 Message-ID: From: Thomas Fossati To: Zach Shelby Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmqjg0knRGUIg9Uae57dSqFXYGHZ+GaxRLAb0Ij+pG9m+g7r7d4mnlawWzR35kAd2z8G8mX Cc: "core@ietf.org WG" , Klaus Hartke Subject: Re: [core] CoAP jump mechanism 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, 22 Nov 2012 16:42:41 -0000 Hi Zach, On Thu, Nov 22, 2012 at 4:02 PM, Zach Shelby wrote: > I would argue that it is too late to make huge changes or redesign from s= cratch - we have a lot of industry really using this and just promised that= coap-12 was the last breaking compatibility change (with WG consensus behi= nd it). That said, if there is something we can remove, simplify or explain= better that does not break backward compatibility with coap-12, then we sh= ould definitely consider it. In particular if there is something that can b= e simply removed or simplified that is not really needed, that would be per= fectly fine at this point. > The IETF has a policy of running code for a good reason, but it does resu= lt in having to realize protocol evolution as you are really using a protoc= ol and moving it towards RFC while working out issues. I think we've done a= great job of that, and have had running code and real products using our s= pecifications all along. The downside is that you need to evolve a protocol= and can't just do a fresh re-design. I totally prefer this to what is done= in many SDOs - design a monster of a protocol, publish the standard, then = cross your fingers and hope it will work :-/ it sounds like you're arguing that CoAP is no more in its prototyping phase= . I would counter-argue that until it is not gone through WGLC and has passed it, it has to be considered prototypal, independently of the cardinality of the already deployed software/hardware base. The IETF model of running code must be a value added to the process of creating protocols -- in that it provides early evidence of what works and what doesn't, and allows for fixing issues before it's too late -- not as a bond that prevents us from getting a clean and satisfactory design in the end. I share the same "bad feeling" WRT the current option encoding algorithm as Klaus, and would be happy to see a more elegant solution, if at all possible. But I can also live with Carsten's argument about the fact that re-designing from scratch the option encoding would not provide any major benefit over what we have now. Instead, saying we can't move bits around because it would break existing deployments, well, this is less likely to be an acceptable reason, at least for me. Cheers, Thomas. From zach@sensinode.com Thu Nov 22 09:11:32 2012 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 5AA0D21F854F for ; Thu, 22 Nov 2012 09:11:32 -0800 (PST) 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 dx-joaCL5IXK for ; Thu, 22 Nov 2012 09:11:31 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 488EB21F8485 for ; Thu, 22 Nov 2012 09:11:30 -0800 (PST) Received: from [192.168.1.102] (188-67-14-55.bb.dnainternet.fi [188.67.14.55]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id qAMHBR5q018829; Thu, 22 Nov 2012 19:11:28 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Thu, 22 Nov 2012 19:10:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1306CEF6-E37B-4172-B6B0-0DEAA06E7CD1@sensinode.com> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> To: Thomas Fossati X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org WG" , Klaus Hartke Subject: Re: [core] CoAP jump mechanism 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, 22 Nov 2012 17:11:32 -0000 Hi, On Nov 22, 2012, at 6:42 PM, Thomas Fossati wrote: > The IETF model of running code must be a value added to the process of > creating protocols -- in that it provides early evidence of what works > and what doesn't, and allows for fixing issues before it's too late -- > not as a bond that prevents us from getting a clean and satisfactory > design in the end. Of course not. It just affects the way we design and evolve protocols - = in a good way in my opinion. We end up with protocols that really work, = with tons of experience in using them.=20 > I share the same "bad feeling" WRT the current option encoding > algorithm as Klaus, and would be happy to see a more elegant solution, > if at all possible. But I can also live with Carsten's argument about > the fact that re-designing from scratch the option encoding would not > provide any major benefit over what we have now. I happen to feel the same.=20 > Instead, saying we can't move bits around because it would break > existing deployments, well, this is less likely to be an acceptable > reason, at least for me. Also note I said I am open to hearing good proposals :-)=20 Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From cabo@tzi.org Thu Nov 22 09:45:52 2012 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 43CE321F85ED for ; Thu, 22 Nov 2012 09:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.377 X-Spam-Level: X-Spam-Status: No, score=-106.377 tagged_above=-999 required=5 tests=[AWL=-0.128, 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 hyr1ERMqsQUS for ; Thu, 22 Nov 2012 09:45:43 -0800 (PST) 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 C3F7921F85E2 for ; Thu, 22 Nov 2012 09:45:07 -0800 (PST) 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 qAMHiPjX005870; Thu, 22 Nov 2012 18:44:26 +0100 (CET) Received: from [192.168.217.105] (p5489334E.dip.t-dialin.net [84.137.51.78]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 61231242; Thu, 22 Nov 2012 18:44:25 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Thu, 22 Nov 2012 18:44:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> To: Thomas Fossati X-Mailer: Apple Mail (2.1499) Cc: Klaus Hartke , "core@ietf.org WG" Subject: Re: [core] CoAP jump mechanism 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, 22 Nov 2012 17:45:52 -0000 On Nov 22, 2012, at 17:42, Thomas Fossati wrote: > would be happy to see a more elegant solution I actually went to the trouble and designed that, before I came up with = the current jump design. The "elegant" solution certainly *looked* better on a napkin, but it had = pretty much the same complexity. And it would have been much more of a breaking change. So as long as the IETF doesn't create a directorate for protocol = aesthetics (I want to be a founding member!), let's stick with what we = have. Gr=FC=DFe, Carsten PS.: At least we now have carved out an assignment for the next = "Protocol Design" class: Design a type-length-value encoding for a protocol that needs to be = relatively compact, as well as low-complexity in implementation. Multiple TLVs of the same type must be representable and maintain = ordering; otherwise, ordering can (and should) be defined by the = protocol. The TLV section needs to be self-delimiting, i.e. at the end you need to = know that you are at the end (there is a single "payload" following). The number of TLVs in any instance is likely to be below five, but can = expand without a defined bound (except that the overall packet length = will stay below 2**11 bytes). There can be zero TLV elements, this should use zero bytes. In addition to the TLV elements themselves, you can use approximately = four bits in the header. Values can rarely have a byte length of up to about 2**10 bytes, but are = typically short, often 0, 1, 2, or 3 bytes, with another small cluster = below approximately 10 bytes. The type range is focused on cardinals in the below 50s, but can expand = up to 2**16 (and will typically stay in clusters if that is the case). The sequence of TLVs must be stable when a TLV is added or removed. =20 Every single value must be encoded as-is (no stuffing expansion, no = intervening delimiters) so an implementation can represent it internally = by a length and a pointer into the packet. More generally, an encoding that has just one or a small number of = representations for a single TLV set to be encoded is favored. The overall processing should be on the level of bytes (possibly with a = few subdivisions within, such as nibbles); bit-level compacting without = regard for byte boundaries is not acceptable for complexity reasons. = There should be no need to do operations that are non-trivial on = constrained systems, such as an integer divide, to build or decode the = protocol encoding. Any solution that is not much worse in encoding space or complexity than = the CoAP TLV encoding is acceptable (e.g., the solution should not use = more than one byte TL overhead per TLV in the typical case). Any requirements that I have missed? Should be a fun assignment. But = no bearing on CoAP at this point in its life. (The fun thing is that the CoAP encoding is *simpler* than the set of = requirements. That's the way it should be...) From tho@koanlogic.com Thu Nov 22 10:16:04 2012 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 9765E21F8464 for ; Thu, 22 Nov 2012 10:16:04 -0800 (PST) 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 CdgDeYn4J4py for ; Thu, 22 Nov 2012 10:16:04 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id EAE2E21F8463 for ; Thu, 22 Nov 2012 10:16:03 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id t11so1117679qaa.10 for ; Thu, 22 Nov 2012 10:16:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=p7itRCBi+c+wzZEMUjedgppdrb/duJ3VbFtvoRIZ2Po=; b=S+xFMkwc8xyL44Qb7KypvfX4mrJHfdCrRALbP1lQckO2BaOj88J8PB/qwS/GjgjKM4 rH4yIMrWs3yhSAHOphTTva4HB9rhD/yQjH4Y3Pos3mpPrYi2kXQu9GknhBbPdYXIpP6r oU4I7KXoGgjpcke9rDLKU+iQZVk2SJdZcQdMmTMIIAIkQd/VeRpt238y3Pnp89Kt5H/g di/B1emj0XweNxqKLKC+qb8+pew7WD2/X7D/wkf66nHpjp31OSR2vwUHMB710u1zQkDb qgCYeN7zzH0ULCuCce95YKcq2mDL69gmJqugYs8D0VkGDXhy6qlM5wMBN0fUpo1SCoTa h2cA== MIME-Version: 1.0 Received: by 10.49.133.97 with SMTP id pb1mr1503304qeb.31.1353608163090; Thu, 22 Nov 2012 10:16:03 -0800 (PST) Received: by 10.49.2.72 with HTTP; Thu, 22 Nov 2012 10:16:02 -0800 (PST) X-Originating-IP: [81.134.152.4] In-Reply-To: References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> Date: Thu, 22 Nov 2012 18:16:02 +0000 Message-ID: From: Thomas Fossati To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnVXSJTrIleaaF4VV6XGxVzjNr9sv2s7U7J4+yl5Wv5VIuVYedEzna6K2Ecs5jwdOrVF84F Cc: Klaus Hartke , "core@ietf.org WG" Subject: Re: [core] CoAP jump mechanism 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, 22 Nov 2012 18:16:04 -0000 On Thu, Nov 22, 2012 at 5:44 PM, Carsten Bormann wrote: > I actually went to the trouble and designed that, before I came up with the current jump design. > The "elegant" solution certainly *looked* better on a napkin, but it had pretty much the same complexity. mmm, for "a more elegant solution" I mean one which lower the complexity, not one that stays pretty much the same as the current proposal. But I guess half the members of the directorate for protocol aesthetics would disagree with me on this point :-) So, as already said, if we can't find a better solution (and in a reasonably short time frame), I'd be perfectly fine with the current state of art. From hartke@tzi.org Thu Nov 22 14:22:43 2012 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 2380D21F8A02 for ; Thu, 22 Nov 2012 14:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.827 X-Spam-Level: X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=-2.800, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_SUMOF=5, HELO_EQ_DE=0.35, J_CHICKENPOX_44=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 l4ABi5DX1GNj for ; Thu, 22 Nov 2012 14:22:42 -0800 (PST) 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 C44A021F8816 for ; Thu, 22 Nov 2012 14:22:40 -0800 (PST) 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 qAMMMVHN026472 for ; Thu, 22 Nov 2012 23:22:31 +0100 (CET) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 68B2D2F9 for ; Thu, 22 Nov 2012 23:22:30 +0100 (CET) Received: by mail-pa0-f44.google.com with SMTP id hz11so4099359pad.31 for ; Thu, 22 Nov 2012 14:22:28 -0800 (PST) Received: by 10.68.218.97 with SMTP id pf1mr8436307pbc.96.1353622948557; Thu, 22 Nov 2012 14:22:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.156.238 with HTTP; Thu, 22 Nov 2012 14:22:07 -0800 (PST) In-Reply-To: References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> From: Klaus Hartke Date: Fri, 23 Nov 2012 00:22:07 +0200 Message-ID: To: "core@ietf.org WG" Content-Type: multipart/mixed; boundary=e89a8ff244fb02326f04cf1ce70e Subject: Re: [core] CoAP jump mechanism 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, 22 Nov 2012 22:22:43 -0000 --e89a8ff244fb02326f04cf1ce70e Content-Type: text/plain; charset=ISO-8859-1 I've given it a quick try. The basic idea: * option count: always use an end-of-options marker; get rid of the OC field. * delta/length: use 4 bits; insert one or two additional bytes after the option header if necessary. I've implemented it and compared it against the current encoding using the 23 core ETSI Plugtest2 test cases (~ 30 request/response pairs). I've also made a first attempt at writing it down (see attachment). Before After Request Header Bytes 544 546 Response Header Bytes 506 497 Pages of Text 5 3 Lines of Code 209 112 (for Option Count, Delta and Length combined) So the improvements are clearly not in the packet size, but in the code size and the number of times an implementer has to bang his head against the wall. I guess this can be further improved. Klaus -- My code to encode the option header: public void WriteOptionHeader(CoapOption number, int length) { int p = this.pos++; int hi = WriteOptionHeaderField(number - this.prev); int lo = WriteOptionHeaderField(length); this.buffer[p] = (byte)((hi << 4) | lo); this.prev = number; } private int WriteOptionHeaderField(int value) { if (value > 255) { this.buffer[this.pos++] = (byte)(value >> 8); this.buffer[this.pos++] = (byte)value; return 14; } else if (value > 12) { this.buffer[this.pos++] = (byte)value; return 13; } else { return value; } } public void WriteEndOfOptions() { this.buffer[this.pos++] = 0xff; } --e89a8ff244fb02326f04cf1ce70e Content-Type: text/plain; charset=US-ASCII; name="new-format.txt" Content-Disposition: attachment; filename="new-format.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h9ufjqcy0 SW50ZXJuZXQtRHJhZnQgICAgICAgICAgIE5ldyBDb0FQIE1lc3NhZ2UgRm9ybWF0ICAgICAgICAg ICBOb3ZlbWJlciAyMDEyCgoKMy4gIE1lc3NhZ2UgRm9ybWF0CgogICBDb0FQIG1lc3NhZ2VzIGFy ZSBlbmNvZGVkIGluIGEgc2ltcGxlIGJpbmFyeSBmb3JtYXQuICBCeSBkZWZhdWx0LAogICBlYWNo IG1lc3NhZ2Ugb2NjdXBpZXMgdGhlIGRhdGEgc2VjdGlvbiBvZiBvbmUgVURQIGRhdGFncmFtLiAg Q29BUCBtYXkKICAgYWxzbyBiZSB1c2VkIG92ZXIgRGF0YWdyYW0gVHJhbnNwb3J0IExheWVyIFNl Y3VyaXR5IChEVExTKSAoc2VlCiAgIFNlY3Rpb24gOSkuICBJdCBjb3VsZCBhbHNvIGJlIHVzZWQg b3ZlciBvdGhlciB0cmFuc3BvcnRzLCB0aGUKICAgc3BlY2lmaWNhdGlvbiBvZiB3aGljaCBpcyBv dXQgb2YgdGhpcyBkb2N1bWVudCdzIHNjb3BlLgoKICAgVGhlIGZvcm1hdCBvZiBhIG1lc3NhZ2Ug aXMgc2hvd24gaW4gRmlndXJlIDEgYmVsb3cuICBJdCBjb25zaXN0cyBvZgogICB0aGUgZml4ZWQt c2l6ZWQgQ29BUCBIZWFkZXIgZm9sbG93ZWQgYnkgYSBUb2tlbiwgemVybyBvciBtb3JlIENvQVAK ICAgT3B0aW9ucyBpbiBUeXBlLUxlbmd0aC1WYWx1ZSAoVExWKSBmb3JtYXQsIGFuIE9wdGlvbiBU ZXJtaW5hdG9yIGFuZCBhCiAgIHBheWxvYWQuICBUaGUgcGF5bG9hZCBpcyBtYWRlIHVwIG9mIHRo ZSBieXRlcyBhZnRlciB0aGUgT3B0aW9uCiAgIFRlcm1pbmF0b3I7IHRoZSBsZW5ndGggaXMgY2Fs Y3VsYXRlZCBmcm9tIHRoZSBkYXRhZ3JhbSBsZW5ndGguCgogICAgIDAgICAgICAgICAgICAgICAg ICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMKICAgIDAgMSAyIDMg NCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQog ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKwogICB8VmVyfCBUIHxSfCBUTCAgfCAgICAgIENvZGUgICAgIHwgICAgICAgICAg TWVzc2FnZSBJRCAgICAgICAgICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgVG9rZW4gLi4uCiAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rCiAgIHwgICBPcHRpb25zIChpZiBhbnkpIC4uLgogICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8MSAxIDEg MSAxIDEgMSAxfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgUGF5bG9hZCAoaWYgYW55KSAuLi4KICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsKCiAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMTogTWVzc2FnZSBGb3JtYXQK CjMuMS4gIEhlYWRlciBGb3JtYXQKCiAgIFRoZSBmaWVsZHMgaW4gdGhlIGhlYWRlciBhcmUgZGVm aW5lZCBhcyBmb2xsb3dzOgoKICAgVmVyc2lvbjogMi1iaXQgdW5zaWduZWQgaW50ZWdlci4gIElu ZGljYXRlcyB0aGUgQ29BUCB2ZXJzaW9uIG51bWJlci4KICAgICAgICAgICAgSW1wbGVtZW50YXRp b25zIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBNVVNUIHNldCB0aGlzIGZpZWxkIHRvCiAgICAgICAg ICAgIDEuICBPdGhlciB2YWx1ZXMgYXJlIHJlc2VydmVkIGZvciBmdXR1cmUgdmVyc2lvbnMuCgog ICBUeXBlOiAgICAyLWJpdCB1bnNpZ25lZCBpbnRlZ2VyLiAgSW5kaWNhdGVzIGlmIHRoaXMgbWVz c2FnZSBpcyBvZgogICAgICAgICAgICB0eXBlIENvbmZpcm1hYmxlICgwKSwgTm9uLUNvbmZpcm1h YmxlICgxKSwgQWNrbm93bGVkZ2VtZW50CiAgICAgICAgICAgICgyKSBvciBSZXNldCAoMykuICBT ZWUgU2VjdGlvbiA0IGZvciB0aGUgc2VtYW50aWNzIG9mIHRoZXNlCiAgICAgICAgICAgIG1lc3Nh Z2UgdHlwZXMuCgogICAoUillc2VydmVkOiAgMS1iaXQgdW5zaWduZWQgaW50ZWdlci4gIFJlc2Vy dmVkIGZvciBmdXR1cmUgdXNlLgoKCgoKCgoKSGFydGtlICAgICAgICAgICAgICAgICAgICBFeHBp cmVzIE1heSAyNiwgMjAxMyAgICAgICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgIE5ldyBDb0FQIE1lc3NhZ2UgRm9ybWF0ICAgICAgICAgICBOb3ZlbWJlciAy MDEyCgoKICAgVG9rZW4gTGVuZ3RoOiAgMy1iaXQgdW5zaWduZWQgaW50ZWdlci4gIEluZGljYXRl cyB0aGUgbGVuZ3RoIG9mIHRoZQogICAgICAgICAgICBUb2tlbiBhZnRlciB0aGUgaGVhZGVyICgw LTcgYnl0ZXMpLgoKICAgQ29kZTogICAgOC1iaXQgdW5zaWduZWQgaW50ZWdlci4gIEluZGljYXRl cyBpZiB0aGUgbWVzc2FnZSBjYXJyaWVzIGEKICAgICAgICAgICAgcmVxdWVzdCAoMS0zMSkgb3Ig YSByZXNwb25zZSAoNjQtMTkxKSwgb3IgaXMgZW1wdHkgKDApLgogICAgICAgICAgICAoQWxsIG90 aGVyIGNvZGUgdmFsdWVzIGFyZSByZXNlcnZlZC4pICBJbiBjYXNlIG9mIGEgcmVxdWVzdCwKICAg ICAgICAgICAgdGhlIENvZGUgZmllbGQgaW5kaWNhdGVzIHRoZSBSZXF1ZXN0IE1ldGhvZDsgaW4g Y2FzZSBvZiBhCiAgICAgICAgICAgIHJlc3BvbnNlIGEgUmVzcG9uc2UgQ29kZS4gIFBvc3NpYmxl IHZhbHVlcyBhcmUgbWFpbnRhaW5lZCBpbgogICAgICAgICAgICB0aGUgQ29BUCBDb2RlIFJlZ2lz dHJ5IChTZWN0aW9uIDEyLjEpLiAgU2VlIFNlY3Rpb24gNSBmb3IKICAgICAgICAgICAgdGhlIHNl bWFudGljcyBvZiByZXF1ZXN0cyBhbmQgcmVzcG9uc2VzLgoKICAgTWVzc2FnZSBJRDogIDE2LWJp dCB1bnNpZ25lZCBpbnRlZ2VyLiAgVXNlZCBmb3IgdGhlIGRldGVjdGlvbiBvZgogICAgICAgICAg ICBtZXNzYWdlIGR1cGxpY2F0aW9uLCBhbmQgdG8gbWF0Y2ggbWVzc2FnZXMgb2YgdHlwZQogICAg ICAgICAgICBBY2tub3dsZWRnZW1lbnQvUmVzZXQgYW5kIG1lc3NhZ2VzIG9mIHR5cGUgQ29uZmly bWFibGUvCiAgICAgICAgICAgIE5vbi1Db25maXJtYWJsZS4gIFNlZSBTZWN0aW9uIDQgZm9yIE1l c3NhZ2UgSUQgZ2VuZXJhdGlvbgogICAgICAgICAgICBydWxlcyBhbmQgaG93IG1lc3NhZ2VzIGFy ZSBtYXRjaGVkLgoKICAgVG9rZW46ICAgVXNlZCB0byBjb3VwbGUgcmVzcG9uc2VzIHdpdGggcmVx dWVzdHMuICBTZWUgU2VjdGlvbiA1IGZvcgogICAgICAgICAgICBkZXRhaWxzLgoKMy4yLiAgT3B0 aW9uIEZvcm1hdAoKICAgRWFjaCBpbnN0YW5jZSBvZiBhIENvQVAgT3B0aW9uIGluIGEgbWVzc2Fn ZSBoYXMgYW4gT3B0aW9uIE51bWJlciwgYQogICBMZW5ndGggYW5kIGEgVmFsdWUuICBUaGUgZm9y bWF0IG9mIGFuIG9wdGlvbiBpcyBzaG93biBpbiBGaWd1cmUgMgogICBiZWxvdy4KCiAgIEluc3Rl YWQgb2Ygc3BlY2lmeWluZyB0aGUgT3B0aW9uIE51bWJlciBkaXJlY3RseSwgb3B0aW9ucyBNVVNU IGFwcGVhcgogICBpbiBvcmRlciBvZiB0aGVpciBPcHRpb24gTnVtYmVycyBhbmQgYSBkZWx0YSBl bmNvZGluZyBpcyB1c2VkIGJldHdlZW4KICAgdGhlbTogVGhlIE9wdGlvbiBOdW1iZXIgZm9yIGVh Y2ggb3B0aW9uIGlzIGNhbGN1bGF0ZWQgYXMgdGhlIHN1bSBvZgogICBpdHMgZGVsdGEgYW5kIHRo ZSBPcHRpb24gTnVtYmVyIG9mIHRoZSBwcmVjZWRpbmcgb3B0aW9uIGluIHRoZQogICBtZXNzYWdl LiAgRm9yIHRoZSBmaXJzdCBvcHRpb24gaW4gYSBtZXNzYWdlLCBhIHByZWNlZGluZyBvcHRpb24g d2l0aAogICBPcHRpb24gTnVtYmVyIHplcm8gaXMgYXNzdW1lZC4gIE11bHRpcGxlIG9wdGlvbnMg d2l0aCB0aGUgc2FtZSBPcHRpb24KICAgTnVtYmVyIGNhbiBiZSBpbmNsdWRlZCBieSB1c2luZyBh biBkZWx0YSBvZiB6ZXJvLgoKICAgICAwICAgMSAgIDIgICAzICAgNCAgIDUgICA2ICAgNwogICAr LS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSsKICAgfCBPcHRpb24gRGVsdGEgIHwgT3B0 aW9uIExlbmd0aCB8CiAgICstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKwogICB8ICAg T3B0aW9uIERlbHRhICgwLTIgQikgLi4uCiAgICstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0r LS0tKwogICB8ICAgT3B0aW9uIExlbmd0aCAoMC0yIEIpIC4uLgogICArLS0tKy0tLSstLS0rLS0t Ky0tLSstLS0rLS0tKy0tLSsKICAgfCAgIE9wdGlvbiBWYWx1ZSAuLi4KICAgKy0tLSstLS0rLS0t Ky0tLSstLS0rLS0tKy0tLSstLS0rCgogICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAy OiBPcHRpb24gRm9ybWF0CgogICBUaGUgZmllbGRzIGluIGFuIG9wdGlvbiBhcmUgZGVmaW5lZCBh cyBmb2xsb3dzOgoKCgpIYXJ0a2UgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDI2LCAy MDEzICAgICAgICAgICAgICAgICAgW1BhZ2UgMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg TmV3IENvQVAgTWVzc2FnZSBGb3JtYXQgICAgICAgICAgIE5vdmVtYmVyIDIwMTIKCgogICBEZWx0 YTogICA0LWJpdCB1bnNpZ25lZCBpbnRlZ2VyLiAgSW5kaWNhdGVzIHRoZSBkaWZmZXJlbmNlIGJl dHdlZW4KICAgICAgICAgICAgdGhlIE9wdGlvbiBOdW1iZXIgb2YgdGhpcyBvcHRpb24gYW5kIHRo ZSBwcmV2aW91cyBvcHRpb24gKG9yCiAgICAgICAgICAgIHplcm8gZm9yIHRoZSBmaXJzdCBvcHRp b24pLiAgSW4gb3RoZXIgd29yZHMsIHRoZSBPcHRpb24KICAgICAgICAgICAgTnVtYmVyIGlzIGNh bGN1bGF0ZWQgYnkgc2ltcGx5IHN1bW1pbmcgdGhlIE9wdGlvbiBEZWx0YQogICAgICAgICAgICBm aWVsZHMgb2YgdGhpcyBhbmQgcHJldmlvdXMgb3B0aW9ucyBiZWZvcmUgaXQuICBUaHJlZSB2YWx1 ZXMKICAgICAgICAgICAgYXJlIHJlc2VydmVkIGZvciBzcGVjaWFsIGNvbnN0cnVjdHM6CgogICAg ICAgICAgICAxMzogIEFuIDgtYml0IHVuc2lnbmVkIGludGVnZXIgZm9sbG93cyB0aGUgaW5pdGlh bCBieXRlIGFuZAogICAgICAgICAgICAgICAgIGluZGljYXRlcyB0aGUgT3B0aW9uIERlbHRhLgoK ICAgICAgICAgICAgMTQ6ICBBIDE2LWJpdCB1bnNpZ25lZCBpbnRlZ2VyIGZvbGxvd3MgdGhlIGlu aXRpYWwgYnl0ZSBhbmQKICAgICAgICAgICAgICAgICBpbmRpY2F0ZXMgdGhlIE9wdGlvbiBEZWx0 YS4KCiAgICAgICAgICAgIDE1OiAgSW5kaWNhdGVzIHRoZSBPcHRpb24gVGVybWluYXRvci4KCiAg IExlbmd0aDogIDQtYml0IHVuc2lnbmVkIGludGVnZXIuICBJbmRpY2F0ZXMgdGhlIGxlbmd0aCBv ZiB0aGUgT3B0aW9uCiAgICAgICAgICAgIFZhbHVlLCBpbiBieXRlcy4gIFRocmVlIHZhbHVlcyBh cmUgcmVzZXJ2ZWQgZm9yIHNwZWNpYWwKICAgICAgICAgICAgY29uc3RydWN0czoKCiAgICAgICAg ICAgIDEzOiAgQW4gOC1iaXQgdW5zaWduZWQgaW50ZWdlciBwcmVjZWRlcyB0aGUgT3B0aW9uIFZh bHVlIGFuZAogICAgICAgICAgICAgICAgIGluZGljYXRlcyB0aGUgT3B0aW9uIExlbmd0aC4KCiAg ICAgICAgICAgIDE0OiAgQSAxNi1iaXQgdW5zaWduZWQgaW50ZWdlciBwcmVjZWRlcyB0aGUgT3B0 aW9uIFZhbHVlIGFuZAogICAgICAgICAgICAgICAgIGluZGljYXRlcyB0aGUgT3B0aW9uIExlbmd0 aC4KCiAgICAgICAgICAgIDE1OiAgUmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2UuCgogICBWYWx1ZTog ICBUaGUgbGVuZ3RoIGFuZCBmb3JtYXQgb2YgdGhlIE9wdGlvbiBWYWx1ZSBkZXBlbmRzIG9uIHRo ZQogICAgICAgICAgICByZXNwZWN0aXZlIG9wdGlvbiwgd2hpY2ggTUFZIGRlZmluZSB2YXJpYWJs ZSBsZW5ndGggdmFsdWVzLgogICAgICAgICAgICBTZWUgU2VjdGlvbiAzLjMgZm9yIHRoZSBmb3Jt YXRzIHRoZSBvcHRpb25zIGRlZmluZWQgaW4gdGhpcwogICAgICAgICAgICBkb2N1bWVudCBtYWtl IHVzZSBvZjsgb3RoZXIgb3B0aW9ucyBNQVkgbWFrZSB1c2Ugb2Ygb3RoZXIKICAgICAgICAgICAg b3B0aW9uIHZhbHVlIGZvcm1hdHMuCgogICBPcHRpb24gTnVtYmVycyBhcmUgbWFpbnRhaW5lZCBp biB0aGUgQ29BUCBPcHRpb24gTnVtYmVyIFJlZ2lzdHJ5CiAgIChTZWN0aW9uIDEyLjIpLiAgU2Vl IFNlY3Rpb24gNS4xMCBmb3IgdGhlIHNlbWFudGljcyBvZiB0aGUgb3B0aW9ucwogICBkZWZpbmVk IGluIHRoaXMgZG9jdW1lbnQuCgozLjMuICBPcHRpb24gVmFsdWUgRm9ybWF0cwoKICAgVGhlIG9w dGlvbnMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IG1ha2UgdXNlIG9mIHRoZSBmb2xsb3dpbmcg b3B0aW9uCiAgIHZhbHVlIGZvcm1hdHMuCgogICAuLi4KCgoKCgoKCgpIYXJ0a2UgICAgICAgICAg ICAgICAgICAgIEV4cGlyZXMgTWF5IDI2LCAyMDEzICAgICAgICAgICAgICAgICAgW1BhZ2UgM10K --e89a8ff244fb02326f04cf1ce70e-- From tho@koanlogic.com Thu Nov 22 15:11:30 2012 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 4DAFD21F8532 for ; Thu, 22 Nov 2012 15:11:30 -0800 (PST) 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=[AWL=-0.000, 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 xw2oS5l9la93 for ; Thu, 22 Nov 2012 15:11:29 -0800 (PST) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8003021F8514 for ; Thu, 22 Nov 2012 15:11:29 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id c4so1095949qae.10 for ; Thu, 22 Nov 2012 15:11:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=YcjgKDTJaxW6oM6QOAm9jJEdGG+gWOwvS9elyoc+d8g=; b=psuEU6jM+aRIZUZP5+WQhkd8S3cEls3xE32poKax5FggSlRCtqOWmacfbdDVen/MPi rauZShyC9wyG2JnPqWCKVuyR6lggac3YFNdfKHTsbZqrKSRfPJtPF3BVuJ7/snQiF1nR qQmhCld6X6K89dy8hyJjFbeJopphp5wL+5/kx5g9ZJDYgA3ZOr7DFpVKD6gfqSve1qQb CQXlc/FuH7/F96fJkHf7jbSGDOGQNwqbyD7O2T6OQoiCb0v4EY5MWQSioBFsZT+6YwIx nyCvSCi+gdO/ska1P2rr2/TmxWZZ83/UPV+Ik6X2CXsfI18HUxpTVhsYKyTA5iUJ+2b0 ZFig== MIME-Version: 1.0 Received: by 10.229.234.158 with SMTP id kc30mr447532qcb.52.1353625888585; Thu, 22 Nov 2012 15:11:28 -0800 (PST) Received: by 10.49.2.72 with HTTP; Thu, 22 Nov 2012 15:11:28 -0800 (PST) X-Originating-IP: [213.81.89.208] In-Reply-To: References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> Date: Thu, 22 Nov 2012 23:11:28 +0000 Message-ID: From: Thomas Fossati To: Klaus Hartke Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmc0sonnl0OXPa5aXFIMavijRt0iccnT1pELZFIUCFm47MvQptrUniVMSDo8S+qzG3hvsVt Cc: "core@ietf.org WG" Subject: Re: [core] CoAP jump mechanism 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, 22 Nov 2012 23:11:30 -0000 On Thu, Nov 22, 2012 at 10:22 PM, Klaus Hartke wrote: > I've given it a quick try. Heck Klaus, you are quick :-) Besides, the proposal is sound, I like it. Just one nit: you don't tell what we are supposed to do with the nibble just after the Option Terminator. Discard it, right ? Anyway, +1 ! From cabo@tzi.org Thu Nov 22 15:17:50 2012 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 DA76521F8432 for ; Thu, 22 Nov 2012 15:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.37 X-Spam-Level: X-Spam-Status: No, score=-106.37 tagged_above=-999 required=5 tests=[AWL=-0.121, 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 6jEcy78oHI6f for ; Thu, 22 Nov 2012 15:17:50 -0800 (PST) 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 1CCFC21F844E for ; Thu, 22 Nov 2012 15:17:49 -0800 (PST) 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 qAMNHgpm015335 for ; Fri, 23 Nov 2012 00:17:42 +0100 (CET) Received: from [192.168.217.105] (p5489334E.dip.t-dialin.net [84.137.51.78]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F0C8030C; Fri, 23 Nov 2012 00:17:41 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Fri, 23 Nov 2012 00:17:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6A70B068-8B25-42D2-AB3D-8D42FB2B37CD@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> To: Klaus Hartke X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] CoAP jump mechanism 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, 22 Nov 2012 23:17:51 -0000 On Nov 22, 2012, at 23:22, Klaus Hartke wrote: > Before After >=20 > Request Header Bytes 544 546 > Response Header Bytes 506 497 Can you check these numbers? They don't fit your code. Gr=FC=DFe, Carsten From hartke@tzi.org Thu Nov 22 15:49:39 2012 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 20BFC21F8660 for ; Thu, 22 Nov 2012 15:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.067 X-Spam-Level: X-Spam-Status: No, score=-5.067 tagged_above=-999 required=5 tests=[AWL=0.560, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, 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 JT-hHAytlzq3 for ; Thu, 22 Nov 2012 15:49:38 -0800 (PST) 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 6419D21F864D for ; Thu, 22 Nov 2012 15:49:38 -0800 (PST) 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 qAMNnUiO026381 for ; Fri, 23 Nov 2012 00:49:30 +0100 (CET) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DDA13311 for ; Fri, 23 Nov 2012 00:49:29 +0100 (CET) Received: by mail-pb0-f44.google.com with SMTP id uo1so6081061pbc.31 for ; Thu, 22 Nov 2012 15:49:28 -0800 (PST) Received: by 10.68.230.234 with SMTP id tb10mr9008611pbc.71.1353628168122; Thu, 22 Nov 2012 15:49:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.156.238 with HTTP; Thu, 22 Nov 2012 15:49:07 -0800 (PST) In-Reply-To: References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> From: Klaus Hartke Date: Fri, 23 Nov 2012 01:49:07 +0200 Message-ID: To: "core@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] CoAP jump mechanism 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, 22 Nov 2012 23:49:39 -0000 Thomas Fossati wrote: > On Thu, Nov 22, 2012 at 10:22 PM, Klaus Hartke wrote: >> I've given it a quick try. > > Heck Klaus, you are quick :-) Besides, the proposal is sound, I like it. I'm glad you like it. > Just one nit: you don't tell what we are supposed to do with the > nibble just after the Option Terminator. Discard it, right ? The text can be improved a lot; I just wanted to write the basics down quickly. On that nibble, something like "must set to x when sent and ignored when received" would need to be added. Best regards, Klaus From hartke@tzi.org Thu Nov 22 15:50:48 2012 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 86BCD21F89AD for ; Thu, 22 Nov 2012 15:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.16 X-Spam-Level: X-Spam-Status: No, score=-5.16 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, 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 2UFa0eUuEr74 for ; Thu, 22 Nov 2012 15:50:46 -0800 (PST) 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 7F4B721F864D for ; Thu, 22 Nov 2012 15:50:46 -0800 (PST) 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 qAMNocY2028521 for ; Fri, 23 Nov 2012 00:50:38 +0100 (CET) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 501AA313 for ; Fri, 23 Nov 2012 00:50:38 +0100 (CET) Received: by mail-pa0-f44.google.com with SMTP id hz11so4124356pad.31 for ; Thu, 22 Nov 2012 15:50:36 -0800 (PST) Received: by 10.68.218.97 with SMTP id pf1mr8976679pbc.96.1353628236449; Thu, 22 Nov 2012 15:50:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.156.238 with HTTP; Thu, 22 Nov 2012 15:50:16 -0800 (PST) In-Reply-To: <6A70B068-8B25-42D2-AB3D-8D42FB2B37CD@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <6A70B068-8B25-42D2-AB3D-8D42FB2B37CD@tzi.org> From: Klaus Hartke Date: Fri, 23 Nov 2012 01:50:16 +0200 Message-ID: To: "core@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] CoAP jump mechanism 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, 22 Nov 2012 23:50:48 -0000 Carsten Bormann wrote: > Klaus Hartke wrote: > >> Before After >> >> Request Header Bytes 544 546 >> Response Header Bytes 506 497 > > Can you check these numbers? They don't fit your code. I've just double-checked my code and rerun the test with the same result. The numbers are correct. Best regards, Klaus From cabo@tzi.org Thu Nov 22 15:56:38 2012 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 334DE21F8465 for ; Thu, 22 Nov 2012 15:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.363 X-Spam-Level: X-Spam-Status: No, score=-106.363 tagged_above=-999 required=5 tests=[AWL=-0.114, 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 U7HIu4UgvtHV for ; Thu, 22 Nov 2012 15:56:37 -0800 (PST) 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 5E47E21F8462 for ; Thu, 22 Nov 2012 15:56:37 -0800 (PST) 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 qAMNuRsB029338 for ; Fri, 23 Nov 2012 00:56:28 +0100 (CET) Received: from [192.168.217.105] (p5489334E.dip.t-dialin.net [84.137.51.78]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 812FB316; Fri, 23 Nov 2012 00:56:27 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Fri, 23 Nov 2012 00:56:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <6A70B068-8B25-42D2-AB3D-8D42FB2B37CD@tzi.org> To: Klaus Hartke X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] CoAP jump mechanism 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, 22 Nov 2012 23:56:38 -0000 On Nov 23, 2012, at 00:50, Klaus Hartke wrote: >> Can you check these numbers? They don't fit your code. >=20 > I've just double-checked my code and rerun the test with the same > result. The numbers are correct. Ah, you have more code for special-casing the Token. Got it. I read only the code, not the text. Gr=FC=DFe, Carsten From hartke@tzi.org Thu Nov 22 16:05:11 2012 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 F03B921F84D2 for ; Thu, 22 Nov 2012 16:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.227 X-Spam-Level: X-Spam-Status: No, score=-5.227 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, 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 An6CY4UP3bvm for ; Thu, 22 Nov 2012 16:05:11 -0800 (PST) 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 37DAB21F847C for ; Thu, 22 Nov 2012 16:05:11 -0800 (PST) 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 qAN052P5003330 for ; Fri, 23 Nov 2012 01:05:02 +0100 (CET) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DDB7131B for ; Fri, 23 Nov 2012 01:05:01 +0100 (CET) Received: by mail-pb0-f44.google.com with SMTP id uo1so6085479pbc.31 for ; Thu, 22 Nov 2012 16:04:59 -0800 (PST) Received: by 10.68.230.234 with SMTP id tb10mr9105107pbc.71.1353629099755; Thu, 22 Nov 2012 16:04:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.156.238 with HTTP; Thu, 22 Nov 2012 16:04:39 -0800 (PST) In-Reply-To: References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <6A70B068-8B25-42D2-AB3D-8D42FB2B37CD@tzi.org> From: Klaus Hartke Date: Fri, 23 Nov 2012 02:04:39 +0200 Message-ID: To: "core@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] CoAP jump mechanism 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, 23 Nov 2012 00:05:12 -0000 Carsten Bormann wrote: > Ah, you have more code for special-casing the Token. Got it. Yes. But it's less code. I removed 20 lines and added 12. Best regards, Klaus From cabo@tzi.org Thu Nov 22 16:10:43 2012 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 3157B21F88FC for ; Thu, 22 Nov 2012 16:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.358 X-Spam-Level: X-Spam-Status: No, score=-106.358 tagged_above=-999 required=5 tests=[AWL=-0.109, 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 InIE00RCwzDz for ; Thu, 22 Nov 2012 16:10:42 -0800 (PST) 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 1999421F86A4 for ; Thu, 22 Nov 2012 16:10:41 -0800 (PST) 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 qAN0AYBT006199 for ; Fri, 23 Nov 2012 01:10:34 +0100 (CET) Received: from [192.168.217.105] (p5489334E.dip.t-dialin.net [84.137.51.78]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D4EAC31D; Fri, 23 Nov 2012 01:10:33 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Fri, 23 Nov 2012 01:10:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> To: Klaus Hartke X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] CoAP jump mechanism 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, 23 Nov 2012 00:10:43 -0000 On Nov 23, 2012, at 00:49, Klaus Hartke wrote: >> Just one nit: you don't tell what we are supposed to do with the >> nibble just after the Option Terminator. Discard it, right ? >=20 > The text can be improved a lot; I just wanted to write the basics down > quickly. On that nibble, something like "must set to x when sent and > ignored when received" would need to be added. It's better to keep it open for future extensions. Only allow 0xFF as the terminator and make everything else an error. Just don't pretend the 0xFF is an option header, it isn't. Gr=FC=DFe, Carsten From cabo@tzi.org Thu Nov 22 16:45:43 2012 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 55F9C21F8798 for ; Thu, 22 Nov 2012 16:45:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.353 X-Spam-Level: X-Spam-Status: No, score=-106.353 tagged_above=-999 required=5 tests=[AWL=-0.104, 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 Qdd6SbLaNxzD for ; Thu, 22 Nov 2012 16:45:42 -0800 (PST) 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 8D0FF21F86A0 for ; Thu, 22 Nov 2012 16:45:42 -0800 (PST) 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 qAN0jXX7016737 for ; Fri, 23 Nov 2012 01:45:33 +0100 (CET) Received: from [192.168.217.105] (p5489334E.dip.t-dialin.net [84.137.51.78]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 369A6322; Fri, 23 Nov 2012 01:45:33 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Fri, 23 Nov 2012 01:45:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <6A70B068-8B25-42D2-AB3D-8D42FB2B37CD@tzi.org> To: Klaus Hartke X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] CoAP jump mechanism 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, 23 Nov 2012 00:45:43 -0000 On Nov 23, 2012, at 01:04, Klaus Hartke wrote: >> Ah, you have more code for special-casing the Token. Got it. >=20 > Yes. But it's less code. I removed 20 lines and added 12. Oh, I *like* special-casing Token. Putting it right after the = message-ID also allows some interesting additional simplifications in = constrained-system code. Your numbers look good because you aren't using the default Token very = much. This means in your corpus the Token optimization compensates = spending a byte for the start-of-payload delimiter (and, because Token = has a high option number, for some responses, actually saves a byte). Gr=FC=DFe, Carsten From zach@sensinode.com Fri Nov 23 00:13:01 2012 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 3BD8821F8863 for ; Fri, 23 Nov 2012 00:13:01 -0800 (PST) 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, J_CHICKENPOX_44=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 TWjsfhpkRmxq for ; Fri, 23 Nov 2012 00:12:56 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 64ECB21F84D9 for ; Fri, 23 Nov 2012 00:12:55 -0800 (PST) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id qAN8Cq36013088; Fri, 23 Nov 2012 10:12:52 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Fri, 23 Nov 2012 10:13:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> To: Klaus Hartke X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org WG" Subject: Re: [core] CoAP jump mechanism 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, 23 Nov 2012 08:13:01 -0000 Hi, Nice proposal, thanks. - Regarding the Token right after the header (as some kind of special = option), I am not so sure I like that. Considering we are NSTART=3D1 for = the base protocol, you can usually do with the default value anyways. = Would prefer to keep the base header fixed-length and just leave Token = as an option. - I do like dropping the Option Count, this is something we can easy do = anyways (independent of the rest of the proposal).=20 - The Option Delta and Length extension mechanism here is good. But it = should have been proposed earlier when we were considering the jump = mechanism and then approving it in the working group. Also with your = mechanism of being able to easily represent 0-12, 0-255 and 0-65535 = option deltas, you no longer really need option deltas at all. Why not = just go to straight option numbers at that point? Yes it is slightly = less efficient, but then it is a lot easier to do ultra-simple single = purpose implementations (like Jari's assembler Ethernet thing) and to = debug.=20 Zach On Nov 23, 2012, at 12:22 AM, Klaus Hartke wrote: > I've given it a quick try. >=20 > The basic idea: >=20 > * option count: always use an end-of-options marker; get rid of the OC = field. > * delta/length: use 4 bits; insert one or two additional bytes after > the option header if necessary. >=20 > I've implemented it and compared it against the current encoding using > the 23 core ETSI Plugtest2 test cases (~ 30 request/response pairs). > I've also made a first attempt at writing it down (see attachment). >=20 >=20 > Before After >=20 > Request Header Bytes 544 546 > Response Header Bytes 506 497 >=20 > Pages of Text 5 3 >=20 > Lines of Code 209 112 > (for Option Count, Delta and Length combined) >=20 >=20 > So the improvements are clearly not in the packet size, but in the > code size and the number of times an implementer has to bang his head > against the wall. >=20 > I guess this can be further improved. >=20 > Klaus >=20 >=20 > -- > My code to encode the option header: >=20 > public void WriteOptionHeader(CoapOption number, int length) > { > int p =3D this.pos++; > int hi =3D WriteOptionHeaderField(number - this.prev); > int lo =3D WriteOptionHeaderField(length); > this.buffer[p] =3D (byte)((hi << 4) | lo); > this.prev =3D number; > } >=20 > private int WriteOptionHeaderField(int value) > { > if (value > 255) > { > this.buffer[this.pos++] =3D (byte)(value >> 8); > this.buffer[this.pos++] =3D (byte)value; > return 14; > } > else if (value > 12) > { > this.buffer[this.pos++] =3D (byte)value; > return 13; > } > else > { > return value; > } > } >=20 > public void WriteEndOfOptions() > { > this.buffer[this.pos++] =3D 0xff; > } > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From cabo@tzi.org Fri Nov 23 00:36:47 2012 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 A09CA21F85ED for ; Fri, 23 Nov 2012 00:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.482 X-Spam-Level: X-Spam-Status: No, score=-106.482 tagged_above=-999 required=5 tests=[AWL=-0.233, 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 0P9lDx4wjiPz for ; Fri, 23 Nov 2012 00:36:46 -0800 (PST) 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 B0AEB21F85E6 for ; Fri, 23 Nov 2012 00:36:45 -0800 (PST) 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 qAN8aawX012493; Fri, 23 Nov 2012 09:36:37 +0100 (CET) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A00F33BD; Fri, 23 Nov 2012 09:36:36 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Fri, 23 Nov 2012 09:36:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1ED91E90-100F-4013-A188-CF9901B98F67@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> To: Zach Shelby X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" , Klaus Hartke Subject: Re: [core] CoAP jump mechanism 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, 23 Nov 2012 08:36:48 -0000 On Nov 23, 2012, at 09:13, Zach Shelby wrote: > Hi, >=20 > Nice proposal, thanks. >=20 > - Regarding the Token right after the header (as some kind of special = option), I am not so sure I like that. Considering we are NSTART=3D1 for = the base protocol, you can usually do with the default value anyways. Yeah. Just set TL=3D0 and don't send anything. > Would prefer to keep the base header fixed-length and just leave Token = as an option. It *is* kind of optional in Klaus' current proposal -- you can send 0 = bytes. > - I do like dropping the Option Count, this is something we can easy = do anyways (independent of the rest of the proposal).=20 If we actually do a breaking change, we should go the whole way. (I'm not yet convinced of that, BTW.) > - The Option Delta and Length extension mechanism here is good. But it = should have been proposed earlier when we were considering the jump = mechanism and then approving it in the working group. Yes, definitely. > Also with your mechanism of being able to easily represent 0-12, 0-255 = and 0-65535 option deltas, you no longer really need option deltas at = all. Why not just go to straight option numbers at that point? Yes it is = slightly less efficient, but then it is a lot easier to do ultra-simple = single purpose implementations (like Jari's assembler Ethernet thing) = and to debug.=20 Option number deltas are: -- indeed significantly more efficient; but more importantly: -- guarantee an order, which is good for the receiver, and rarely adds = complexity at the sender. Item 2 is really what reduces complexity significantly. Gr=FC=DFe, Carsten From cabo@tzi.org Fri Nov 23 00:39:23 2012 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 6C01E21F85FF for ; Fri, 23 Nov 2012 00:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.424 X-Spam-Level: X-Spam-Status: No, score=-106.424 tagged_above=-999 required=5 tests=[AWL=-0.175, 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 lNnTgHqFAQ9A for ; Fri, 23 Nov 2012 00:39:22 -0800 (PST) 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 1245621F85FC for ; Fri, 23 Nov 2012 00:39:12 -0800 (PST) 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 qAN8d5G1013391 for ; Fri, 23 Nov 2012 09:39:05 +0100 (CET) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 20B383C3; Fri, 23 Nov 2012 09:39:05 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Fri, 23 Nov 2012 09:39:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <51D9306A-68A1-414B-8977-D55353420341@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> To: Klaus Hartke X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] CoAP jump mechanism 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, 23 Nov 2012 08:39:23 -0000 On Nov 23, 2012, at 01:10, Carsten Bormann wrote: > Just don't pretend the 0xFF is an option header, it isn't. Actually, call it "Payload Start Indicator", and only send it if there = actually is a payload. This gives the efficiency of the current scheme even for default-token = messages, as long as they have no payload (which should be about half of = them). Gr=FC=DFe, Carsten From hartke@tzi.org Fri Nov 23 00:50:28 2012 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 3743E21F84D9 for ; Fri, 23 Nov 2012 00:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.277 X-Spam-Level: X-Spam-Status: No, score=-5.277 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, 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 oL7HVrPRfXJ3 for ; Fri, 23 Nov 2012 00:50:27 -0800 (PST) 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 63FF721F84D6 for ; Fri, 23 Nov 2012 00:50:27 -0800 (PST) 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 qAN8oIvF021034 for ; Fri, 23 Nov 2012 09:50:18 +0100 (CET) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 18D4F3D8 for ; Fri, 23 Nov 2012 09:50:17 +0100 (CET) Received: by mail-pb0-f44.google.com with SMTP id uo1so6318065pbc.31 for ; Fri, 23 Nov 2012 00:50:16 -0800 (PST) Received: by 10.68.197.71 with SMTP id is7mr12418017pbc.79.1353660616083; Fri, 23 Nov 2012 00:50:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.156.238 with HTTP; Fri, 23 Nov 2012 00:49:54 -0800 (PST) In-Reply-To: <51D9306A-68A1-414B-8977-D55353420341@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <51D9306A-68A1-414B-8977-D55353420341@tzi.org> From: Klaus Hartke Date: Fri, 23 Nov 2012 10:49:54 +0200 Message-ID: To: "core@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] CoAP jump mechanism 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, 23 Nov 2012 08:50:28 -0000 Carsten Bormann wrote: >> Just don't pretend the 0xFF is an option header, it isn't. > > Actually, call it "Payload Start Indicator", and only send it if there actually is a payload. > This gives the efficiency of the current scheme even for default-token messages, as long as they have no payload (which should be about half of them). With this change, I get the following numbers: Before After Request Header Bytes 544 527 Response Header Bytes 506 486 Best regards, Klaus From angelo.castellani@gmail.com Fri Nov 23 00:57:57 2012 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 8320121F8674 for ; Fri, 23 Nov 2012 00:57:57 -0800 (PST) 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 znGsyRWyy+yd for ; Fri, 23 Nov 2012 00:57:56 -0800 (PST) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6372921F8673 for ; Fri, 23 Nov 2012 00:57:56 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id dr1so818521wgb.1 for ; Fri, 23 Nov 2012 00:57:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=/JeFOOc3cqhuEe4xki1rEhiBpijDautnEI9P33hfgn8=; b=qLKoVtItV7zZjY0mUKwKDzjWNUwx7OgRDjtGEMTKEMwjoMTEsQaI2buSVlxH+ZwL4/ p1+sRcZ6ntMuUfdO4yMMW82VnLkDmw6z/gbw98BI91s/2uxrMcbGZ4spFqeGHBl9fCZi fcWluVJiloDoqEaoFipzBI/8ubQASQniH63LdUNHqjFUftRkjlYFC955FBoG4XRY71VU cIlvi/SytzuZ3MJ9GEK6bZiJRSaEKJe9gOlEclqYLlDQPHZLAcwTjz7NenHvt9z8oXLI lruzhqO7NQVWfBZSQOtr4t/aOlDHE08VXNmGcgO6pECSwYfK5nkkWnbCbv4f3/UhwU9t vTJA== Received: by 10.216.211.73 with SMTP id v51mr1239112weo.74.1353661075565; Fri, 23 Nov 2012 00:57:55 -0800 (PST) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.78.203 with HTTP; Fri, 23 Nov 2012 00:57:40 -0800 (PST) In-Reply-To: References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> From: "Angelo P. Castellani" Date: Fri, 23 Nov 2012 09:57:40 +0100 X-Google-Sender-Auth: 4Xyb5A-MpEHmX5Q-M-YYYyi21lM Message-ID: To: Klaus Hartke Content-Type: multipart/mixed; boundary=001636c5ad678e2e5104cf25c724 Cc: "core@ietf.org WG" Subject: Re: [core] CoAP jump mechanism 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, 23 Nov 2012 08:57:57 -0000 --001636c5ad678e2e5104cf25c724 Content-Type: text/plain; charset=UTF-8 I like your proposal as well, it may also help monolithic or "cross-layer" CoAP implementations. I have a small improvement to it, with the aim of supporting also small tokens that do not need to be carried inline. This fixes also another problem with constrained devices. That devices MAY choose also to only support small tokens that have a very limited size. This provides an "entry level" support for tokens on hosts that cannot allocate up to 8 bytes for the token on each request slot. With static allocation supporting it means reserving 8 bytes for each request slot, even if the token is smaller or absent as well. Best, Angelo 2012/11/23 Klaus Hartke : > Thomas Fossati wrote: >> On Thu, Nov 22, 2012 at 10:22 PM, Klaus Hartke wrote: >>> I've given it a quick try. >> >> Heck Klaus, you are quick :-) Besides, the proposal is sound, I like it. > > I'm glad you like it. > >> Just one nit: you don't tell what we are supposed to do with the >> nibble just after the Option Terminator. Discard it, right ? > > The text can be improved a lot; I just wanted to write the basics down > quickly. On that nibble, something like "must set to x when sent and > ignored when received" would need to be added. > > Best regards, > Klaus > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --001636c5ad678e2e5104cf25c724 Content-Type: text/plain; charset=US-ASCII; name="new-format-v2.txt" Content-Disposition: attachment; filename="new-format-v2.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h9v2oqd70 ICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAg ICAgICAgICAzCiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDEKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgfFZlcnwgVCB8SXwgVEwgIHwgICAg ICBDb2RlICAgICB8ICAgICAgICAgIE1lc3NhZ2UgSUQgICAgICAgICAgIHwKICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsK ICAgfCAgIFRva2VuIChpZiBhbnkpIC4uLgogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgT3B0aW9ucyAoaWYg YW55KSAuLi4KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsKICAgfDEgMSAxIDEgMSAxIDEgMXwKICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAg fCAgIFBheWxvYWQgKGlmIGFueSkgLi4uCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCgogICBJbmxpbmUgVG9rZW4gKEkp OiAxLWJpdCB1bnNpZ25lZCBpbnRlZ2VyLiBJZiBpcyBlcXVhbCB0byAxLCB0aGUgVG9rZW4gaXMg dHJhbnNtaXR0ZWQgaW5saW5lOwogICB0aGUgdG9rZW4gbGVuZ3RoIGlzIGdpdmVuIGJ5IHRoZSB2 YWx1ZSBvZiBUTC4KICAgSWYgSSBpcyBlcXVhbCB0byAwLCB0aGUgVG9rZW4gaXMgZ2l2ZW4gYnkg dGhlIHZhbHVlIG9mIFRMIGZpZWxkLgoKICAgVG9rZW4gTGVuZ3RoIChUTCk6ICAzLWJpdCB1bnNp Z25lZCBpbnRlZ2VyLiAgSW5kaWNhdGVzIHRoZSBsZW5ndGggb2YgdGhlCiAgICAgICAgICAgIFRv a2VuIGFmdGVyIHRoZSBoZWFkZXIgKDAtNyBieXRlcykgaWYgSSBpcyBlcXVhbCB0byAxLgogICBJ ZiBJIGlzIGVxdWFsIHRvIDAsIFRMIGNvbnRhaW5zIHRoZSBUb2tlbiB2YWx1ZS4KCiAgIEhvc3Rz IG5vdCBzdXBwb3J0aW5nIHRoZSBUb2tlbiBvbmx5IGFjY2VwdCByZXF1ZXN0cyB3aXRoIEk9MCBh bmQgVEw9MC4K --001636c5ad678e2e5104cf25c724-- From cabo@tzi.org Fri Nov 23 01:38:39 2012 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 3EA2821F847C for ; Fri, 23 Nov 2012 01:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.389 X-Spam-Level: X-Spam-Status: No, score=-106.389 tagged_above=-999 required=5 tests=[AWL=-0.140, 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 l0ltaJrLQemr for ; Fri, 23 Nov 2012 01:38:38 -0800 (PST) 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 6D8A821F846B for ; Fri, 23 Nov 2012 01:38:38 -0800 (PST) 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 qAN9cSnh015032; Fri, 23 Nov 2012 10:38:28 +0100 (CET) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B1D97458; Fri, 23 Nov 2012 10:38:28 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Fri, 23 Nov 2012 10:38:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <77B42BD5-B650-4F4A-A454-1623715E7368@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> To: "Angelo P. Castellani" X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" , Klaus Hartke Subject: Re: [core] CoAP jump mechanism 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, 23 Nov 2012 09:38:39 -0000 On Nov 23, 2012, at 09:57, "Angelo P. Castellani" = wrote: > I have a small improvement to it, with the aim of supporting also > small tokens that do not need to be carried inline. Small Tokens have always been supported. Your encoding change looks like you believe the structure of the = encoding shapes the choices of the implementers: By making it more = efficient to send a Token of up to three bits, implementers will choose = to do so. That may be true to some extent, but what is wrong with sending a small = token in a 1-byte part? Neither giving up the reserved bit nor adding a special case for Tokens = < 8 enthuses me... (And then there is the pesky detail that a one-byte Token with 0x00 is = different from a zero-byte Token.) Gr=FC=DFe, Carsten From tho@koanlogic.com Fri Nov 23 01:44:58 2012 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 D473221F8611 for ; Fri, 23 Nov 2012 01:44:58 -0800 (PST) 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 OpK3SAkLegdX for ; Fri, 23 Nov 2012 01:44:58 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 439B021F8605 for ; Fri, 23 Nov 2012 01:44:57 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so6818306qca.31 for ; Fri, 23 Nov 2012 01:44:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=k1GCVGyp3UwL1ASzVanoK2eTIKh5KrbXh/SIgUYmcnU=; b=MX57DKMstwXng/lwPFOXiSxgzWuV2n7lm0sRwyG99gCPBePZIEY7s0djDshGFm2JnH DiFBHiPj2wvLQYivsT4Cj3LK3TmxYM0SCavrQw32GWik+Z44cHLby7XF265SJUZSRSzr GK4lk9cdoubm/xTC+t5M76g1/nfd35SGYmMbWaEPRcRtif0RXH3NvCkpn12spqlI2+E9 tqndtHqt8pTfEmh7eATAZh07GZxOoKW0SBxp4kS2uqm6sskfEK+0H4n9GgCLaBSLBWxX VGVaGNFen8jTIxHmhQYsMKKsgcl4T8xnpUoKE4WASX7tZwrxYy2FVnizD2xcwDUnp1j/ bPlQ== MIME-Version: 1.0 Received: by 10.49.133.97 with SMTP id pb1mr3559112qeb.31.1353663897515; Fri, 23 Nov 2012 01:44:57 -0800 (PST) Received: by 10.49.2.72 with HTTP; Fri, 23 Nov 2012 01:44:57 -0800 (PST) X-Originating-IP: [81.134.152.4] In-Reply-To: References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <51D9306A-68A1-414B-8977-D55353420341@tzi.org> Date: Fri, 23 Nov 2012 09:44:57 +0000 Message-ID: From: Thomas Fossati To: Klaus Hartke Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn5q6MF63nYMSIC2gSl0LviZ3i5NezKxTcRu6wURzQ18iYi3ALskZjGS04/bt2FdEW8X3CN Cc: "core@ietf.org WG" Subject: Re: [core] CoAP jump mechanism 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, 23 Nov 2012 09:44:58 -0000 > With this change, I get the following numbers: > > Before After > > Request Header Bytes 544 527 > Response Header Bytes 506 486 So, with Klaus proposal we are getting very good figures and an extremely simple decoding algorithm. Add to this the excellent idea proposed by Angelo for inlining tiny tokens, and we reach a point where efficiency and simplicity of design met without one compromising the other. What do we want more ? From zach@sensinode.com Fri Nov 23 01:51:15 2012 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 A0EF921F8612 for ; Fri, 23 Nov 2012 01:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 Ycxmx1-6RUOf for ; Fri, 23 Nov 2012 01:51:11 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 9C31E21F8605 for ; Fri, 23 Nov 2012 01:51:10 -0800 (PST) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id qAN9p6kA003936; Fri, 23 Nov 2012 11:51:06 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <77B42BD5-B650-4F4A-A454-1623715E7368@tzi.org> Date: Fri, 23 Nov 2012 11:51:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <77B42BD5-B650-4F4A-A454-1623715E7368@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Cc: Klaus Hartke , "core@ietf.org WG" Subject: Re: [core] CoAP jump mechanism 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, 23 Nov 2012 09:51:15 -0000 On Nov 23, 2012, at 11:38 AM, Carsten Bormann wrote: > On Nov 23, 2012, at 09:57, "Angelo P. Castellani" = wrote: >=20 >> I have a small improvement to it, with the aim of supporting also >> small tokens that do not need to be carried inline. >=20 > Small Tokens have always been supported. >=20 > Your encoding change looks like you believe the structure of the = encoding shapes the choices of the implementers: By making it more = efficient to send a Token of up to three bits, implementers will choose = to do so. >=20 > That may be true to some extent, but what is wrong with sending a = small token in a 1-byte part? > Neither giving up the reserved bit nor adding a special case for = Tokens < 8 enthuses me... > (And then there is the pesky detail that a one-byte Token with 0x00 is = different from a zero-byte Token.) Have to agree with Carstren, not sure I see the gain vs. extra code = options pain here. The point of the exercise Klaus is going through is = to reduce the number of options and complexity. This goes in the = opposite direction. The Token is often set by the one who is not a super = duper constrained node anyways (e.g. in Observation that is usually the = case).=20 Zach=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From angelo.castellani@gmail.com Fri Nov 23 02:47:29 2012 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 EFD6121F859C for ; Fri, 23 Nov 2012 02:47:29 -0800 (PST) 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 5uIBHgagEo1e for ; Fri, 23 Nov 2012 02:47:29 -0800 (PST) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id AB38721F85A1 for ; Fri, 23 Nov 2012 02:47:28 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hq7so1275508wib.1 for ; Fri, 23 Nov 2012 02:47:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=KXNmLizx2WJ0x1k29cd8mv/imMdzHC+xygePjIbnQcY=; b=lTUW4Y4IhZUnt/dQNvKxYfW2KA1Z4pQPtEPik5GT05P4AnjyfvrNEMLmINv88hfBOA SsqJ+3IyJMRyP7SBkMviXb993tdaZYsQPidy7WAt50No8pJefvUXGMVKOiuOkIJGxXp/ +Er2TaK7VUjmuSYGf/voSygCEgevELi00d6Z1ruG+psmYpaHKE6KjR3VFcbHXZu3VoQK pc36TB4MA7Gw190+hAjrMrCry4tna3yJjqH8+DWmDhqG/v60s0t8PJ2Hkj4oU2ShFTGe Fj7j3BeTO2Rxvw0VFzNv5H8Jm6dlV9vEd7AEoRS2PsElGTye/UoeZgiZTGaxJnxjaofK skgw== Received: by 10.180.109.132 with SMTP id hs4mr5496166wib.1.1353667647576; Fri, 23 Nov 2012 02:47:27 -0800 (PST) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.78.203 with HTTP; Fri, 23 Nov 2012 02:47:12 -0800 (PST) In-Reply-To: References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <77B42BD5-B650-4F4A-A454-1623715E7368@tzi.org> From: "Angelo P. Castellani" Date: Fri, 23 Nov 2012 11:47:12 +0100 X-Google-Sender-Auth: vqZDhTQiO7OHrTOKguqyMStwmtI Message-ID: To: Carsten Bormann , Zach Shelby Content-Type: text/plain; charset=UTF-8 Cc: Klaus Hartke , "core@ietf.org WG" Subject: Re: [core] CoAP jump mechanism 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, 23 Nov 2012 10:47:30 -0000 Carsten, Zach, please evaluate better the reasons why I am proposing this. A server supporting the Token option MUST be prepared o receive up to 8 bytes by the client, and MUST echo it back to the client when the request has been successfully processed. Tokens are a pain from a constrained server perspective, typically constrained servers allocate memory in a static way. To avoid statically reserving 8 bytes for *each* request slot, a server implementor may choose to not support token option at all (is it permitted to a server to do this, right?). On Nov 23, 2012, Carsten Bormann wrote: > Small Tokens have always been supported. > [...] what is wrong with sending a small token in a 1-byte part? A constrained server, thus using static allocation, has some way to support ONLY 1-byte tokens? On Nov 23, 2012, Carsten Bormann wrote: > Neither giving up the reserved bit [...] enthuses me... Yes I share your perplexity. A reserved bit in the first byte of the header is a very precious one. We have to carefully reflect its usage. On Nov 23, 2012, Carsten Bormann wrote: > nor adding a special case for Tokens < 8 enthuses me... On Nov 23, 2012, Zach Shelby wrote: > [...] not sure I see the gain vs. extra code options pain here. > The point of the exercise Klaus is going through is to reduce the number of options and complexity. > This goes in the opposite direction. Complexity is my concern too, infact my proposal is aiming to reduce the complexity of implementing the token for servers. My point is that if they can choose to ONLY implement a Short Token, they will probably support it in the short version. On Nov 23, 2012, Zach Shelby wrote: > The Token is often set by the one who is not a super duper constrained node anyways (e.g. in Observation that is usually the case). Zach, that is exactly the point. Clients are usually not that constrained, but servers are! If I am a server supporting observations and tokens, and assume that I use static allocation which is usually the case in constrained servers. I have to allocate a number of memory slots to save the state of that observation. Each slot have to contain also a field for the Token of 8 bytes, no matter that I will not receive it in my observation request, or that the actual token received is 1 byte long! Angelo From angelo.castellani@gmail.com Fri Nov 23 02:48:34 2012 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 83C5E21F86AD for ; Fri, 23 Nov 2012 02:48:34 -0800 (PST) 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 iiFkGOk+nrhh for ; Fri, 23 Nov 2012 02:48:33 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 193B521F84DA for ; Fri, 23 Nov 2012 02:48:32 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr13so365299wgb.13 for ; Fri, 23 Nov 2012 02:48:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=c2CcQyRhVP8p8UlEzJ6o1h5Aqw7lOJHbz69Op813rdE=; b=MAvEaM6OLMNE1e7k35o+Mi/kOhpYCd+/abdBsdPUhP5k0ulK8Jm2gMKgx7qBC97Pxt p8ykytR3sIeDXaoqH5Ba7fTq5VuLmYzCKWUMek7dKKdQ58noPD7TxxZqTy5g705p/rUF 0oGAcxVRs2+WPiyi29XG/jynQ6A4mNvbh2LQGV4iGvyGmKQyQr29f2vtO39UMQxByE9F 0ba4FqyZOCM7+49PZ9JJKbZhevFvGqcZFKiPrYanUpedZjFL8qUs5d1GW/JPtKkIYuk5 VoXu9ikxcihaXUtBR5OLvN8jk4p6rOynRqjJobINq1WvfMmCPodHXfcyCOXKVQIZdr6P UNtQ== Received: by 10.180.24.4 with SMTP id q4mr8874038wif.19.1353667712314; Fri, 23 Nov 2012 02:48:32 -0800 (PST) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.78.203 with HTTP; Fri, 23 Nov 2012 02:48:17 -0800 (PST) In-Reply-To: <77B42BD5-B650-4F4A-A454-1623715E7368@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <77B42BD5-B650-4F4A-A454-1623715E7368@tzi.org> From: "Angelo P. Castellani" Date: Fri, 23 Nov 2012 11:48:17 +0100 X-Google-Sender-Auth: xD_JsnKb9-D3zjQHBDwL32fh0bY Message-ID: To: Carsten Bormann Content-Type: multipart/mixed; boundary=f46d043be1c622ec4f04cf2753a5 Cc: "core@ietf.org WG" , Klaus Hartke Subject: Re: [core] CoAP jump mechanism 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, 23 Nov 2012 10:48:34 -0000 --f46d043be1c622ec4f04cf2753a5 Content-Type: text/plain; charset=UTF-8 2012/11/23 Carsten Bormann : > (And then there is the pesky detail that a one-byte Token with 0x00 is different from a zero-byte Token.) I forgot to address this. I attach an updated proposal. --f46d043be1c622ec4f04cf2753a5 Content-Type: text/plain; charset=US-ASCII; name="new-format-v2.1.txt" Content-Disposition: attachment; filename="new-format-v2.1.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h9v6t5pv0 ICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAg ICAgICAgICAzCiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDEKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgfFZlcnwgVCB8U3wgVEwgIHwgICAg ICBDb2RlICAgICB8ICAgICAgICAgIE1lc3NhZ2UgSUQgICAgICAgICAgIHwKICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsK ICAgfCAgIFRva2VuIChpZiBhbnkpIC4uLgogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgT3B0aW9ucyAoaWYg YW55KSAuLi4KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsKICAgfDEgMSAxIDEgMSAxIDEgMXwKICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAg fCAgIFBheWxvYWQgKGlmIGFueSkgLi4uCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCgogICBTaG9ydCBUb2tlbiAoUyk6 IDEtYml0IHVuc2lnbmVkIGludGVnZXIuIElmIFMgaXMgZXF1YWwgdG8gMCwgdGhlCiAgICAgICAg VG9rZW4gaXMgdHJhbnNtaXR0ZWQgaW5saW5lOwogICAgICAgIHRoZSB0b2tlbiBsZW5ndGggaXMg Z2l2ZW4gYnkgdGhlIHZhbHVlIG9mIFRMLgogICAgICAgIElmIFMgaXMgZXF1YWwgdG8gMSwgdGhl IFRva2VuIGlzIGdpdmVuIGJ5IHRoZSB2YWx1ZSBvZiBUTCBmaWVsZC4KCiAgIFRva2VuIExlbmd0 aCAoVEwpOiAgMy1iaXQgdW5zaWduZWQgaW50ZWdlci4gIEluZGljYXRlcyB0aGUgbGVuZ3RoIG9m IHRoZQogICAgICAgIFRva2VuIGFmdGVyIHRoZSBoZWFkZXIgKDAtNyBieXRlcykgaWYgUyBpcyBl cXVhbCB0byAwLgogICAgICAgIElmIFMgaXMgZXF1YWwgdG8gMSwgVEwgY29udGFpbnMgdGhlIFRv a2VuIHZhbHVlLgoKICAgSG9zdHMgbm90IHN1cHBvcnRpbmcgdGhlIFRva2VuIG9ubHkgYWNjZXB0 IHJlcXVlc3RzIHdpdGggUz0wIGFuZCBUTD0wLAogICB3aGljaCBpcyB0aGUgemVyby1sZW5ndGgg VG9rZW4uCgogICBIb3N0cyBzdXBwb3J0aW5nIG9ubHkgdGhlIFNob3J0IFRva2VuIGFjY2VwdCBh bHNvIHJlcXVlc3RzIHdpdGggUz0xLAogICBUTCB3aWxsIGNvbnRhaW4gdGhlIFRva2VuIHZhbHVl LgoKICAgSG9zdHMgaGF2aW5nIGZ1bGwgc3VwcG9ydCBmb3IgVG9rZW4gd2lsbCBhY2NlcHQgYWxz byByZXF1ZXN0cyB3aXRoIFM9MAogICBhbmQgVEw+MC4K --f46d043be1c622ec4f04cf2753a5-- From cabo@tzi.org Fri Nov 23 03:28:05 2012 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 1970A21F906C for ; Fri, 23 Nov 2012 03:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.348 X-Spam-Level: X-Spam-Status: No, score=-106.348 tagged_above=-999 required=5 tests=[AWL=-0.099, 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 Xfd2KV0Y6AcU for ; Fri, 23 Nov 2012 03:28:04 -0800 (PST) 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 40CDF21F8FF3 for ; Fri, 23 Nov 2012 03:28:04 -0800 (PST) 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 qANBRrIO013662; Fri, 23 Nov 2012 12:27:53 +0100 (CET) Received: from [192.168.217.105] (p5489334E.dip.t-dialin.net [84.137.51.78]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DA14D554; Fri, 23 Nov 2012 12:27:52 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Fri, 23 Nov 2012 12:27:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <77B42BD5-B650-4F4A-A454-1623715E7368@tzi.org> To: "Angelo P. Castellani" X-Mailer: Apple Mail (2.1499) Cc: Klaus Hartke , "core@ietf.org WG" Subject: Re: [core] CoAP jump mechanism 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, 23 Nov 2012 11:28:05 -0000 On Nov 23, 2012, at 11:47, "Angelo P. Castellani" = wrote: > A server supporting the Token option MUST be prepared o receive up to > 8 bytes by the client, I'm not sure that is a binary choice. What you are proposing is an encoding change. If the semantics above were true then any server supporting the = three-bit Tokens would also need to support the 8-byte tokens. I don't know why you believe a different encoding changes the semantics = here. > and MUST echo it back to the client when the > request has been successfully processed. That much is true. In reality a server that is severely resource constrained will have to = do what needs to be done. If rejecting Tokens beyond a single byte is what makes that server = possible (and it wouldn't work with long tokens), then you can always = 5.00 on a long token. I think the lwig document might be enhanced with some language on how a = client should be choosing token values. Gr=FC=DFe, Carsten From angelo.castellani@gmail.com Fri Nov 23 04:00:55 2012 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 E9D1821F858A for ; Fri, 23 Nov 2012 04:00:55 -0800 (PST) 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 37t2aV9NRxfI for ; Fri, 23 Nov 2012 04:00:55 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id F308921F84E0 for ; Fri, 23 Nov 2012 04:00:54 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so2006735wey.31 for ; Fri, 23 Nov 2012 04:00:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=ciZ2E1Xk0NA/QhjWqHIizyiACoQz8ihmvmxNSMXDO/k=; b=MznK1kMkhmYJgsfzh5Bz8sJcX8WMeN/3bnjLtOzGJaJ2CM51/BhG+D0piwEKo3kAWo spg81wIpTkiiUoYU4VQu3ZRzAFTIjyEeuGPRlD12U69OvLS2OoZyUjAyG07M3LMfGjgb AfAgSSY4r0RyoPm3vu1K8moVnavaaI2syPwx3fB/61VJzVIkV7VF/6aI+uggDHonPyme S2lOlntGTycbrx3+huUYGScctBI6D+8D5nEh7LZ1yhq2HpDHVh6tYm9j/yMkCm/WS1gb z2C5jFIo6XZWHoureNw5A/tvKyOIW5LLYEZg+x0U/Tx/Q8DNrA24NYDgRJJWs815bE7z vdcw== Received: by 10.216.227.137 with SMTP id d9mr1322689weq.205.1353672053644; Fri, 23 Nov 2012 04:00:53 -0800 (PST) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.78.203 with HTTP; Fri, 23 Nov 2012 04:00:38 -0800 (PST) In-Reply-To: References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <77B42BD5-B650-4F4A-A454-1623715E7368@tzi.org> From: "Angelo P. Castellani" Date: Fri, 23 Nov 2012 13:00:38 +0100 X-Google-Sender-Auth: wiuo2-ClL22PyGaRd2DrOoZA690 Message-ID: To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Klaus Hartke , "core@ietf.org WG" Subject: Re: [core] CoAP jump mechanism 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, 23 Nov 2012 12:00:56 -0000 A server may choose arbitrarily which size of token to support? So a client sending a request with a token, may have to poll the server until it finds a token size that works for that server? I share that ideally a client MUST choose the token size for a request as the shortest possible for him, so a 5.00 will be obtained only in that case. But allowing a server to arbitrarily choose the size of token it supports seems a pain for interoperability to me. Imagine that we will have servers not supporting tokens, servers supporting tokens up to 1-byte, servers supporting tokens up to 2-bytes, etc. etc Understanding the capabilities of a server (options supported), if them cannot be known in advance, and intersect them with that required/supported/needed by the client could happen to be an operational nightmare for CoAP. IMHO if we add to this that the Token option can be supported in 9 different ways we are really growing the operational complexity! Angelo p.s.: a server may support 2-bytes, 4-bytes and 8-bytes tokens, but not 1-byte, 3-bytes, 5-bytes, 6-bytes or 7-bytes? assume that it chooses to support only those sizes to simplify its implementation. is it permitted? 2012/11/23 Carsten Bormann : > On Nov 23, 2012, at 11:47, "Angelo P. Castellani" = wrote: > >> A server supporting the Token option MUST be prepared o receive up to >> 8 bytes by the client, > > I'm not sure that is a binary choice. > What you are proposing is an encoding change. > If the semantics above were true then any server supporting the three-bit= Tokens would also need to support the 8-byte tokens. > I don't know why you believe a different encoding changes the semantics h= ere. > >> and MUST echo it back to the client when the >> request has been successfully processed. > > That much is true. > > In reality a server that is severely resource constrained will have to do= what needs to be done. > If rejecting Tokens beyond a single byte is what makes that server possib= le (and it wouldn't work with long tokens), then you can always 5.00 on a l= ong token. > > I think the lwig document might be enhanced with some language on how a c= lient should be choosing token values. > > Gr=C3=BC=C3=9Fe, Carsten > From cabo@tzi.org Fri Nov 23 04:12:28 2012 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 850C921F8512 for ; Fri, 23 Nov 2012 04:12:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.344 X-Spam-Level: X-Spam-Status: No, score=-106.344 tagged_above=-999 required=5 tests=[AWL=-0.095, 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 yvpvRH+EJS5m for ; Fri, 23 Nov 2012 04:12:28 -0800 (PST) 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 A411221F8626 for ; Fri, 23 Nov 2012 04:12:27 -0800 (PST) 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 qANCCIOA009360; Fri, 23 Nov 2012 13:12:18 +0100 (CET) Received: from [192.168.217.105] (p54893AC9.dip.t-dialin.net [84.137.58.201]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 47FAA5C0; Fri, 23 Nov 2012 13:12:18 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Fri, 23 Nov 2012 13:12:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2F3D4494-7781-42F9-B8D3-2FB2B9B637E3@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <77B42BD5-B650-4F4A-A454-1623715E7368@tzi.org> To: "Angelo P. Castellani" X-Mailer: Apple Mail (2.1499) Cc: Klaus Hartke , "core@ietf.org WG" Subject: Re: [core] CoAP jump mechanism 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, 23 Nov 2012 12:12:28 -0000 On Nov 23, 2012, at 13:00, "Angelo P. Castellani" = wrote: > So a client sending a request with a token, may have to poll the > server until it finds a token size that works for that server? No. A half way reasonable client will choose the smallest token that = makes the application work. If the server can't handle that, they wont interoperate. =20 (Note that we are talking about heroically small systems here, if the = Token size actually does matter.) And there is no point in retrying with a smaller token if the client = needed the larger one in the first place. (If it didn't, why did it send a large token?) A client that uses a small NSTART will use the default Token (0 bytes) = or a small one (1 byte). A client that also needs some protection against cache poisoning from = off-path attackers, but can't use DTLS for some reason, may want to use = a larger token (6-8 bytes). Those servers that are stateless will have = no problem implementing this. Maybe you are trying to use Token for something it wasn't meant for. Gr=FC=DFe, Carsten From kovatsch@inf.ethz.ch Fri Nov 23 04:23:31 2012 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 45EC621F855C for ; Fri, 23 Nov 2012 04:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.227 X-Spam-Level: X-Spam-Status: No, score=-9.227 tagged_above=-999 required=5 tests=[AWL=1.372, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 MRQdyvDfy0iO for ; Fri, 23 Nov 2012 04:23:30 -0800 (PST) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3C121F8559 for ; Fri, 23 Nov 2012 04:23:29 -0800 (PST) Received: from CAS10.d.ethz.ch (172.31.38.210) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.298.4; Fri, 23 Nov 2012 13:23:05 +0100 Received: from MBX10.d.ethz.ch ([fe80::6d7b:f3da:a5b1:c9e9]) by CAS10.d.ethz.ch ([fe80::cce:fc66:7b56:a06a%10]) with mapi id 14.02.0298.004; Fri, 23 Nov 2012 13:23:12 +0100 From: "Kovatsch Matthias" To: Klaus Hartke , "core@ietf.org WG" Thread-Topic: [core] CoAP jump mechanism Thread-Index: Ac3HLwlCd1JVVU2UQ3a8ARAWHlZt1gACkyKAAAN61GAAQy5vAAAR2ZcAAAaC2AAAAeCQgAABYB4AAAFkSYAAAigXAAABGtMAAAiYKIAAAbk5AAABUJ6AAAC/oYAAEcJ+AAAAYNwAAAkgMkA= Date: Fri, 23 Nov 2012 12:23:11 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514D2E9F7@MBX10.d.ethz.ch> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <51D9306A-68A1-414B-8977-D55353420341@tzi.org> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [core] CoAP jump mechanism 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, 23 Nov 2012 12:23:31 -0000 > With this change, I get the following numbers: >=20 > Before After >=20 > Request Header Bytes 544 527 > Response Header Bytes 506 486 I also like the clean-up and of course the performance gain, which should b= e a main goal for constrained environments. Back when tackling the 270 byte limit, the resistance seemed too big to do = the clean-up. Thus, also the quick agreement in Atlanta, I guess. It definitely is painful do have another breaking change, but only now we k= now what we need. Prototyping along the different drafts helped us a lot th= ere. In short: +1 > Angelo P. Castellani: > But allowing a server to arbitrarily choose the size of token it supports= seems > a pain for interoperability to me. But is having two different ways to encode the Token not just along these l= ines? Ciao Matthias From angelo.castellani@gmail.com Fri Nov 23 05:38:08 2012 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 3E89421F845D for ; Fri, 23 Nov 2012 05:38:07 -0800 (PST) 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=[AWL=-0.000, 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 hO2hG4Cjohqq for ; Fri, 23 Nov 2012 05:38:04 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF5BD21F8419 for ; Fri, 23 Nov 2012 05:38:03 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so2046084wey.31 for ; Fri, 23 Nov 2012 05:33:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=BSsZG8O71WfkTkNLbFui7EH23OJKKho4LP4zBILdGoM=; b=OA+SARVetlqn6Sf6bv+EHA7jrMaRUbveudPx7V+8wfjWgesRkpGJGx+TsleFL9zCk/ tpmzX+DZpYmoxAJBvXSxX9ewhYtbYEc0VkbftjocZeJEppjNeKsVsHvKCFUDHF5Wehb1 YdmafJI5CIHE3bsE1Gg+I3NiC8Ojl0XWP85stua+QrVD8TgOd4gJQg3zZ7wLDC3QDGF9 WD+dMLXaaGI1AdUdhqDX1e6O7DCt3/9vIVv9DjS6yg6/6rt/vyX9aAhiUU5PiskfmqpV +GijZx0DCoxySpHcuHD1DHQaZjnAx49GrOTs7OzlAxJW9dZ5GIYzoIdMkm3zTmCPaGwU W3rA== Received: by 10.216.200.160 with SMTP id z32mr1518377wen.53.1353677596641; Fri, 23 Nov 2012 05:33:16 -0800 (PST) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.78.203 with HTTP; Fri, 23 Nov 2012 05:33:01 -0800 (PST) In-Reply-To: <2F3D4494-7781-42F9-B8D3-2FB2B9B637E3@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <77B42BD5-B650-4F4A-A454-1623715E7368@tzi.org> <2F3D4494-7781-42F9-B8D3-2FB2B9B637E3@tzi.org> From: "Angelo P. Castellani" Date: Fri, 23 Nov 2012 14:33:01 +0100 X-Google-Sender-Auth: ZtDjgsYlL6_lhyWxigBPobZMouk Message-ID: To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Cc: Klaus Hartke , "core@ietf.org WG" Subject: Re: [core] CoAP jump mechanism 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, 23 Nov 2012 13:38:09 -0000 2012/11/23 Carsten Bormann : > Maybe you are trying to use Token for something it wasn't meant for. I am not using Tokens anyway :) However, since this will be a standard, I was trying to think all the situations I can came around. Best, Angelo From cabo@tzi.org Fri Nov 23 05:42:55 2012 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 081E021F8465 for ; Fri, 23 Nov 2012 05:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.34 X-Spam-Level: X-Spam-Status: No, score=-106.34 tagged_above=-999 required=5 tests=[AWL=-0.091, 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 XH3QQeReZZOB for ; Fri, 23 Nov 2012 05:42:54 -0800 (PST) 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 8A3FB21F845E for ; Fri, 23 Nov 2012 05:42:53 -0800 (PST) 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 qANDgiIk001323 for ; Fri, 23 Nov 2012 14:42:44 +0100 (CET) Received: from [192.168.217.105] (p54893AC9.dip.t-dialin.net [84.137.58.201]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0665168E; Fri, 23 Nov 2012 14:42:43 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Fri, 23 Nov 2012 14:42:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> To: Klaus Hartke X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] CoAP jump mechanism 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, 23 Nov 2012 13:42:55 -0000 On Nov 22, 2012, at 23:22, Klaus Hartke wrote: > One thing I'm not sure I like is that the "Klaus encoding" has multiple = ways to say the same thing: If an option length is, say, 10 bytes, this can be expressed by a 4-bit = field of value 0xA, a 4-bit field of value 0xD followed by a byte of = value 0x0A, and by a 4-bit field of value 0xE followed by two bytes of = value 0x000A. We have this problem already in the uints (with a SHOULD tying to outlaw = it), but so far we didn't have it in the option encoding itself -- this = was bijective between the abstract set of (sequences of) option values = and the encoding. To fully keep this property, we would have to add back some of the = dreaded arithmetic, e.g.: 13: An 8-bit unsigned integer follows the initial byte and indicates the value of ([delta/length] - 13). 14: A 16-bit unsigned integer follows the initial byte and indicates the value of ([delta/length] - 269). There are a couple of cases where this happens to save a byte (256-269), = but this is not my main intention. My objective is to make sure that a receiver doesn't have to cope with = multiple ways of saying the same thing, which is always causing = hard-to-debug interoperability problems when some of these ways work and = others don't. Gr=FC=DFe, Carsten From cabo@tzi.org Fri Nov 23 05:45:58 2012 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 5F20021F856B for ; Fri, 23 Nov 2012 05:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.336 X-Spam-Level: X-Spam-Status: No, score=-106.336 tagged_above=-999 required=5 tests=[AWL=-0.087, 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 kJq6Aytxnmn1 for ; Fri, 23 Nov 2012 05:45:58 -0800 (PST) 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 9DA7021F8481 for ; Fri, 23 Nov 2012 05:45:57 -0800 (PST) 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 qANDjksN002656 for ; Fri, 23 Nov 2012 14:45:46 +0100 (CET) Received: from [192.168.217.105] (p54893AC9.dip.t-dialin.net [84.137.58.201]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 24761696; Fri, 23 Nov 2012 14:45:46 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> Date: Fri, 23 Nov 2012 14:45:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> To: Klaus Hartke X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] CoAP jump mechanism 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, 23 Nov 2012 13:45:58 -0000 On Nov 23, 2012, at 14:42, Carsten Bormann wrote: > 256-269 Math is hard, let's go shopping (it's Black Friday!). I meant 256-268, of course. Gr=FC=DFe, Carsten From Bert.Greevenbosch@huawei.com Fri Nov 23 17:24:19 2012 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 3BE5221F8487 for ; Fri, 23 Nov 2012 17:24:19 -0800 (PST) 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=[AWL=0.000, 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 VcDUh46rWkLK for ; Fri, 23 Nov 2012 17:24:18 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CEBB721F8465 for ; Fri, 23 Nov 2012 17:24:17 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALV89100; Sat, 24 Nov 2012 01:24:14 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 24 Nov 2012 01:23:35 +0000 Received: from SZXEML441-HUB.china.huawei.com (10.82.67.179) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 24 Nov 2012 01:24:13 +0000 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by szxeml441-hub.china.huawei.com ([10.82.67.179]) with mapi id 14.01.0323.003; Sat, 24 Nov 2012 09:24:05 +0800 From: Bert Greevenbosch To: "Angelo P. Castellani" , Carsten Bormann Thread-Topic: [core] CoAP jump mechanism Thread-Index: Ac3HLwlCd1JVVU2UQ3a8ARAWHlZt1v//n0CAgAAN4QD//WsngIAFSw8AgAA0FgCAAA8FgIAACwEAgAALIoCAABFBAIAACNYAgABEwoCAAA3JAIAACoWAgACZRACAAAtmAIAAA5QAgAAPoACAAAtdAIAACSgA//6c7YA= Date: Sat, 24 Nov 2012 01:24:05 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63CAA6A27@szxeml509-mbs> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <77B42BD5-B650-4F4A-A454-1623715E7368@tzi.org> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "core@ietf.org WG" , Klaus Hartke Subject: Re: [core] CoAP jump mechanism 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, 24 Nov 2012 01:24:19 -0000 PiBVbmRlcnN0YW5kaW5nIHRoZSBjYXBhYmlsaXRpZXMgb2YgYSBzZXJ2ZXIgKG9wdGlvbnMgc3Vw cG9ydGVkKSwgaWYNCj4gdGhlbSBjYW5ub3QgYmUga25vd24gaW4gYWR2YW5jZSwgYW5kIGludGVy c2VjdCB0aGVtIHdpdGggdGhhdA0KPiByZXF1aXJlZC9zdXBwb3J0ZWQvbmVlZGVkIGJ5IHRoZSBj bGllbnQgY291bGQgaGFwcGVuIHRvIGJlIGFuDQo+IG9wZXJhdGlvbmFsIG5pZ2h0bWFyZSBmb3Ig Q29BUC4NCg0KVGhlIG1lY2hhbmlzbSBmcm9tIGRyYWZ0LWdyZWV2ZW5ib3NjaC1jb3JlLXByb2Zp bGUtZGVzY3JpcHRpb24gaXMgaW50ZW5kZWQgdG8gcHJvdmlkZSBzZXJ2ZXIgc3BlY2lmaWMgaW5m b3JtYXRpb24gaW4gYWR2YW5jZS4NCg0KSSBhbSBub3QgaW4gZmF2b3VyIG9mIGhhdmluZyB0d28g c2VwYXJhdGUgbWVjaGFuaXNtcyBmb3IgdG9rZW5zIHRob3VnaC4NCg0KQmVzdCByZWdhcmRzLA0K QmVydA0KDQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWdyZWV2ZW5ib3Nj aC1jb3JlLXByb2ZpbGUtZGVzY3JpcHRpb24vDQo= From zach@sensinode.com Sat Nov 24 10:58:36 2012 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 17F1C21F854D for ; Sat, 24 Nov 2012 10:58:36 -0800 (PST) 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 9Gery1bVcn6m for ; Sat, 24 Nov 2012 10:58:35 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id B97A521F854B for ; Sat, 24 Nov 2012 10:58:33 -0800 (PST) Received: from [192.168.1.102] (87-95-3-173.bb.dnainternet.fi [87.95.3.173]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id qAOIwUWM009815; Sat, 24 Nov 2012 20:58:30 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> Date: Sat, 24 Nov 2012 20:58:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3DDE1B3C-CBF4-4773-A3C2-AA61856B270C@sensinode.com> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org WG" , Klaus Hartke Subject: Re: [core] CoAP jump mechanism 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, 24 Nov 2012 18:58:36 -0000 On Nov 23, 2012, at 3:42 PM, Carsten Bormann wrote: >> >=20 > One thing I'm not sure I like is that the "Klaus encoding" has = multiple ways to say the same thing: > If an option length is, say, 10 bytes, this can be expressed by a = 4-bit field of value 0xA, a 4-bit field of value 0xD followed by a byte = of value 0x0A, and by a 4-bit field of value 0xE followed by two bytes = of value 0x000A. >=20 > We have this problem already in the uints (with a SHOULD tying to = outlaw it), but so far we didn't have it in the option encoding itself = -- this was bijective between the abstract set of (sequences of) option = values and the encoding. >=20 > To fully keep this property, we would have to add back some of the = dreaded arithmetic, e.g.: >=20 > 13: An 8-bit unsigned integer follows the initial byte and > indicates the value of ([delta/length] - 13). >=20 > 14: A 16-bit unsigned integer follows the initial byte and > indicates the value of ([delta/length] - 269). >=20 > There are a couple of cases where this happens to save a byte = (256-269), but this is not my main intention. > My objective is to make sure that a receiver doesn't have to cope with = multiple ways of saying the same thing, which is always causing = hard-to-debug interoperability problems when some of these ways work and = others don't. +1. I think this is a valid improvement to Klaus's design. Klaus, could you please do a design update so that we can properly = assess it taking into account the useful suggestions from this thread? = In particular including the end of options flag only when the payload is = there and the ranges suggested by Carsten. If we would decide to do a = change like this, the time window for doing it would need to be very = short.=20 Thanks, Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From hartke@tzi.org Sat Nov 24 16:01:25 2012 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 0CC0821F849A for ; Sat, 24 Nov 2012 16:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.816 X-Spam-Level: X-Spam-Status: No, score=-2.816 tagged_above=-999 required=5 tests=[AWL=-2.189, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_SUMOF=5, HELO_EQ_DE=0.35, 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 nSyPncZ+DZrG for ; Sat, 24 Nov 2012 16:01:24 -0800 (PST) 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 069A921F8499 for ; Sat, 24 Nov 2012 16:01:23 -0800 (PST) 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 qAP01G4k023161 for ; Sun, 25 Nov 2012 01:01:16 +0100 (CET) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A810594E for ; Sun, 25 Nov 2012 01:01:15 +0100 (CET) Received: by mail-pa0-f44.google.com with SMTP id hz11so5105286pad.31 for ; Sat, 24 Nov 2012 16:01:13 -0800 (PST) Received: by 10.66.72.225 with SMTP id g1mr21575214pav.79.1353801673685; Sat, 24 Nov 2012 16:01:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.156.238 with HTTP; Sat, 24 Nov 2012 16:00:53 -0800 (PST) In-Reply-To: <3DDE1B3C-CBF4-4773-A3C2-AA61856B270C@sensinode.com> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> <3DDE1B3C-CBF4-4773-A3C2-AA61856B270C@sensinode.com> From: Klaus Hartke Date: Sun, 25 Nov 2012 02:00:53 +0200 Message-ID: To: "core@ietf.org WG" Content-Type: multipart/mixed; boundary=f46d042f9eb0db3b9a04cf4683bb Subject: Re: [core] CoAP jump mechanism 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, 25 Nov 2012 00:01:25 -0000 --f46d042f9eb0db3b9a04cf4683bb Content-Type: text/plain; charset=ISO-8859-1 Attached is a new version of the text with the following changes: * Include the end-of-options/start-of-payload marker only if payload is present. * No payload and a zero-length payload are considered equivalent. (Is this the right choice?) * Payload marker is specified separately from the option format. * Non-overlapping option delta/length field values. * More fancy artwork. Best regards, Klaus --f46d042f9eb0db3b9a04cf4683bb Content-Type: text/plain; charset=US-ASCII; name="new-format-02.txt" Content-Disposition: attachment; filename="new-format-02.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h9xecucv0 SW50ZXJuZXQtRHJhZnQgICAgICAgICAgIE5ldyBDb0FQIE1lc3NhZ2UgRm9ybWF0ICAgICAgICAg ICBOb3ZlbWJlciAyMDEyCgoKMy4gIE1lc3NhZ2UgRm9ybWF0CgogICBDb0FQIG1lc3NhZ2VzIGFy ZSBlbmNvZGVkIGluIGEgc2ltcGxlIGJpbmFyeSBmb3JtYXQuICBCeSBkZWZhdWx0LAogICBlYWNo IG1lc3NhZ2Ugb2NjdXBpZXMgdGhlIGRhdGEgc2VjdGlvbiBvZiBvbmUgVURQIGRhdGFncmFtLiAg VGhlCiAgIG1lc3NhZ2UgZm9ybWF0IHN0YXJ0cyB3aXRoIGEgaGVhZGVyIHdoaWNoIGlzIHZhcmlh YmxlIGluIGxlbmd0aCBhbmQKICAgY2FuIGJlIGJldHdlZW4gNCB0byAxMSBieXRlcyBsb25nLiAg Rm9sbG93aW5nIHRoZSBoZWFkZXIgY29tZXMgYSBsaXN0CiAgIG9mIHplcm8gb3IgbW9yZSBDb0FQ IE9wdGlvbnMgaW4gVHlwZS1MZW5ndGgtVmFsdWUgKFRMVikgZm9ybWF0IGFuZAogICBvcHRpb25h bGx5IGEgcGF5bG9hZCB3aGljaCB0YWtlcyB1cCB0aGUgcmVzdCBvZiB0aGUgZGF0YWdyYW0uCgog ICBDb0FQIG1heSBhbHNvIGJlIHVzZWQgb3ZlciBEYXRhZ3JhbSBUcmFuc3BvcnQgTGF5ZXIgU2Vj dXJpdHkgKERUTFMpOwogICBzZWUgU2VjdGlvbiA5LiAgSXQgY291bGQgYWxzbyBiZSB1c2VkIG92 ZXIgb3RoZXIgdHJhbnNwb3J0cywgdGhlCiAgIHNwZWNpZmljYXRpb24gb2Ygd2hpY2ggaXMgb3V0 IG9mIHRoaXMgZG9jdW1lbnQncyBzY29wZS4KCjMuMS4gIEhlYWRlciBGb3JtYXQKCiAgIFRoZSBm b3JtYXQgb2YgdGhlIGhlYWRlciBpcyBhcyBmb2xsb3dzOgoKICAgICAgICAgICAgICAgICAgICAg MCAgIDEgICAyICAgMyAgIDQgICA1ICAgNiAgIDcKICAgICAgICAgICAgICAgICAgICstLS0tLS0t Ky0tLS0tLS0rLS0tKy0tLS0tLS0tLS0tKwogICAgICAgICAgICAgICAgICAgfCAgICAgICB8ICAg ICAgIHwgICB8ICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICB8IFZlci0gIHwgVHlwZSAg fCBSIHwgIFRva2VuICAgIHwgICAxIGJ5dGUKICAgICAgICAgICAgICAgICAgIHwgc2lvbiAgfCAg ICAgICB8ICAgfCAgTGVuZ3RoICAgfAogICAgICAgICAgICAgICAgICAgKy0tLS0tLS0rLS0tLS0t LSstLS0rLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgQ29kZSAgICAg ICAgICAgICAgfCAgIDEgYnl0ZQogICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfAogICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8CiAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgICAgICAgICAgICAgICAgICstLS0gICAgICAgTWVzc2FnZSBJRCAgICAgICAgLS0tKyAgIDIg Ynl0ZXMKICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fAogICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAg ICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICAgICAgICAg ICAgICAgICAgXCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgICAgICAg ICAgICAvICAgICAgICAgICAgIFRva2VuICAgICAgICAgICAgIC8gICAwLTcgYnl0ZXMKICAgICAg ICAgICAgICAgICAgIFwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICAg ICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCgogICAgICAgICAgICAg ICAgICAgICAgICAgIEZpZ3VyZSAxOiBIZWFkZXIgRm9ybWF0CgogICBUaGUgZmllbGRzIGluIHRo ZSBoZWFkZXIgYXJlIGRlZmluZWQgYXMgZm9sbG93czoKCiAgIFZlcnNpb246ICAyLWJpdCB1bnNp Z25lZCBpbnRlZ2VyLiAgSW5kaWNhdGVzIHRoZSBDb0FQIHZlcnNpb24gbnVtYmVyLgogICAgICAg ICAgICAgSW1wbGVtZW50YXRpb25zIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBNVVNUIHNldCB0aGlz IGZpZWxkCiAgICAgICAgICAgICB0byAxLiAgT3RoZXIgdmFsdWVzIGFyZSByZXNlcnZlZCBmb3Ig ZnV0dXJlIHZlcnNpb25zLgoKCgoKSGFydGtlICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE1h eSAyOSwgMjAxMyAgICAgICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgIE5ldyBDb0FQIE1lc3NhZ2UgRm9ybWF0ICAgICAgICAgICBOb3ZlbWJlciAyMDEyCgoK ICAgVHlwZTogICAgIDItYml0IHVuc2lnbmVkIGludGVnZXIuICBJbmRpY2F0ZXMgaWYgdGhpcyBt ZXNzYWdlIGlzIG9mCiAgICAgICAgICAgICB0eXBlIENvbmZpcm1hYmxlICgwKSwgTm9uLUNvbmZp cm1hYmxlICgxKSwgQWNrbm93bGVkZ2VtZW50CiAgICAgICAgICAgICAoMikgb3IgUmVzZXQgKDMp LiAgVGhlIHNlbWFudGljcyBvZiB0aGVzZSBtZXNzYWdlIHR5cGVzIGFyZQogICAgICAgICAgICAg ZGVmaW5lZCBpbiBTZWN0aW9uIDQuCgogICAoUillc2VydmVkOiAgMS1iaXQgdW5zaWduZWQgaW50 ZWdlci4gIFJlc2VydmVkIGZvciBmdXR1cmUgdXNlLgoKICAgVG9rZW4gTGVuZ3RoOiAgMy1iaXQg dW5zaWduZWQgaW50ZWdlci4gIEluZGljYXRlcyB0aGUgbGVuZ3RoIG9mIHRoZQogICAgICAgICAg ICAgdmFyaWFibGUtbGVuZ3RoIFRva2VuIGZpZWxkICgwLTcgYnl0ZXMpLgoKICAgQ29kZTogICAg IDgtYml0IHVuc2lnbmVkIGludGVnZXIuICBJbmRpY2F0ZXMgaWYgdGhlIG1lc3NhZ2UgY2Fycmll cyBhCiAgICAgICAgICAgICByZXF1ZXN0ICgxLTMxKSBvciBhIHJlc3BvbnNlICg2NC0xOTEpLCBv ciBpcyBlbXB0eSAoMCkuCiAgICAgICAgICAgICBBbGwgb3RoZXIgdmFsdWVzIGFyZSByZXNlcnZl ZC4gIEluIGNhc2Ugb2YgYSByZXF1ZXN0LCB0aGUKICAgICAgICAgICAgIENvZGUgZmllbGQgaW5k aWNhdGVzIHRoZSBSZXF1ZXN0IE1ldGhvZDsgaW4gY2FzZSBvZiBhCiAgICAgICAgICAgICByZXNw b25zZSBhIFJlc3BvbnNlIENvZGUuICBQb3NzaWJsZSB2YWx1ZXMgYXJlIG1haW50YWluZWQKICAg ICAgICAgICAgIGluIHRoZSBDb0FQIENvZGUgUmVnaXN0cnkgKFNlY3Rpb24gMTIuMSkuICBUaGUg c2VtYW50aWNzIG9mCiAgICAgICAgICAgICByZXF1ZXN0cyBhbmQgcmVzcG9uc2VzIGFyZSBkZWZp bmVkIGluIFNlY3Rpb24gNS4KCiAgIE1lc3NhZ2UgSUQ6ICAxNi1iaXQgdW5zaWduZWQgaW50ZWdl ci4gIFVzZWQgZm9yIHRoZSBkZXRlY3Rpb24gb2YKICAgICAgICAgICAgIG1lc3NhZ2UgZHVwbGlj YXRpb24sIGFuZCB0byBtYXRjaCBtZXNzYWdlcyBvZiB0eXBlCiAgICAgICAgICAgICBBY2tub3ds ZWRnZW1lbnQvUmVzZXQgdG8gbWVzc2FnZXMgb2YgdHlwZSBDb25maXJtYWJsZS8KICAgICAgICAg ICAgIE5vbi1Db25maXJtYWJsZS4gIFRoZSBydWxlcyBmb3IgZ2VuZXJhdGluZyBhIE1lc3NhZ2Ug SUQgYW5kCiAgICAgICAgICAgICBtYXRjaGluZyBtZXNzYWdlcyBhcmUgZGVmaW5lZCBpbiBTZWN0 aW9uIDQuCgogICBUb2tlbjogICAgVXNlZCB0byBjb3JyZWxhdGUgcmVxdWVzdHMgYW5kIHJlc3Bv bnNlcy4gIFRoZSBydWxlcyBmb3IKICAgICAgICAgICAgIGdlbmVyYXRpbmcgYSBUb2tlbiBhbmQg Y29ycmVsYXRpbmcgcmVxdWVzdHMgYW5kIHJlc3BvbnNlcwogICAgICAgICAgICAgYXJlIGRlZmlu ZWQgaW4gU2VjdGlvbiA1LgoKMy4yLiAgT3B0aW9uIEZvcm1hdAoKICAgQ29BUCBkZWZpbmVzIGEg bnVtYmVyIG9mIG9wdGlvbnMgd2hpY2ggY2FuIGJlIGluY2x1ZGVkIGluIGEgbWVzc2FnZS4KICAg RWFjaCBvcHRpb24gaW5zdGFuY2UgaW4gYSBtZXNzYWdlIHNwZWNpZmllcyB0aGUgT3B0aW9uIE51 bWJlciBvZiB0aGUKICAgZGVmaW5lZCBDb0FQIG9wdGlvbiwgdGhlIGxlbmd0aCBvZiB0aGUgT3B0 aW9uIFZhbHVlIGFuZCB0aGUgT3B0aW9uCiAgIFZhbHVlIGl0c2VsZi4KCiAgIEluc3RlYWQgb2Yg c3BlY2lmeWluZyB0aGUgT3B0aW9uIE51bWJlciBkaXJlY3RseSwgdGhlIGluc3RhbmNlcyBNVVNU CiAgIGFwcGVhciBpbiBvcmRlciBvZiB0aGVpciBPcHRpb24gTnVtYmVycyBhbmQgYSBkZWx0YSBl bmNvZGluZyBpcyB1c2VkCiAgIGJldHdlZW4gdGhlbTogVGhlIE9wdGlvbiBOdW1iZXIgZm9yIGVh Y2ggaW5zdGFuY2UgaXMgY2FsY3VsYXRlZCBhcwogICB0aGUgc3VtIG9mIGl0cyBkZWx0YSBhbmQg dGhlIE9wdGlvbiBOdW1iZXIgb2YgdGhlIHByZWNlZGluZyBpbnN0YW5jZQogICBpbiB0aGUgbWVz c2FnZS4gIEZvciB0aGUgZmlyc3QgaW5zdGFuY2UgaW4gYSBtZXNzYWdlLCBhIHByZWNlZGluZwog ICBvcHRpb24gaW5zdGFuY2Ugd2l0aCBPcHRpb24gTnVtYmVyIHplcm8gaXMgYXNzdW1lZC4gIE11 bHRpcGxlCiAgIGluc3RhbmNlcyBvZiB0aGUgc2FtZSBvcHRpb24gY2FuIGJlIGluY2x1ZGVkIGJ5 IHVzaW5nIGEgZGVsdGEgb2YKICAgemVyby4KCiAgIE9wdGlvbiBOdW1iZXJzIGFyZSBtYWludGFp bmVkIGluIHRoZSBDb0FQIE9wdGlvbiBOdW1iZXIgUmVnaXN0cnkKICAgKFNlY3Rpb24gMTIuMiku ICBTZWUgU2VjdGlvbiA1LjEwIGZvciB0aGUgc2VtYW50aWNzIG9mIHRoZSBvcHRpb25zCiAgIGRl ZmluZWQgaW4gdGhpcyBkb2N1bWVudC4KCgoKCkhhcnRrZSAgICAgICAgICAgICAgICAgICAgRXhw aXJlcyBNYXkgMjksIDIwMTMgICAgICAgICAgICAgICAgICBbUGFnZSAyXQoMCkludGVybmV0LURy YWZ0ICAgICAgICAgICBOZXcgQ29BUCBNZXNzYWdlIEZvcm1hdCAgICAgICAgICAgTm92ZW1iZXIg MjAxMgoKCiAgICAgICAgICAgICAgICAgICAgIDAgICAxICAgMiAgIDMgICA0ICAgNSAgIDYgICA3 CiAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsKICAg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfAogICAgICAg ICAgICAgICAgICAgfCAgT3B0aW9uIERlbHRhIHwgT3B0aW9uIExlbmd0aCB8ICAgMSBieXRlCiAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwKICAgICAg ICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKwogICAgICAgICAg ICAgICAgICAgXCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgICAgICAg ICAgICAvICAgICAgICAgT3B0aW9uIERlbHRhICAgICAgICAgIC8gICAwLTIgYnl0ZXMKICAgICAg ICAgICAgICAgICAgIFwgICAgICAgICAgKGV4dGVuZGVkKSAgICAgICAgICAgXAogICAgICAgICAg ICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAg ICAgICBcICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgICAgICAgICAg IC8gICAgICAgICBPcHRpb24gTGVuZ3RoICAgICAgICAgLyAgIDAtMiBieXRlcwogICAgICAgICAg ICAgICAgICAgXCAgICAgICAgICAoZXh0ZW5kZWQpICAgICAgICAgICBcCiAgICAgICAgICAgICAg ICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICAg IFwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICAgICAgICAgICAgLyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAvCiAgICAgICAgICAgICAgICAgICBcICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgICAgICAgICAgIC8gICAgICAgICBP cHRpb24gVmFsdWUgICAgICAgICAgLyAgIDAgb3IgbW9yZSBieXRlcwogICAgICAgICAgICAgICAg ICAgXCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgICAgICAgICAgICAv ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8KICAgICAgICAgICAgICAgICAgIFwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICAgICAgICAgICAgKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCgogICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3Vy ZSAyOiBPcHRpb24gRm9ybWF0CgogICBUaGUgZmllbGRzIGluIGFuIG9wdGlvbiBhcmUgZGVmaW5l ZCBhcyBmb2xsb3dzOgoKICAgRGVsdGE6ICAgIDQtYml0IHVuc2lnbmVkIGludGVnZXIuICBJbmRp Y2F0ZXMgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbgogICAgICAgICAgICAgdGhlIE9wdGlvbiBOdW1i ZXIgb2YgdGhpcyBvcHRpb24gYW5kIHRoZSBwcmV2aW91cyBvcHRpb24KICAgICAgICAgICAgIChv ciB6ZXJvIGZvciB0aGUgZmlyc3Qgb3B0aW9uKS4gIEluIG90aGVyIHdvcmRzLCB0aGUgT3B0aW9u CiAgICAgICAgICAgICBOdW1iZXIgaXMgY2FsY3VsYXRlZCBieSBzaW1wbHkgc3VtbWluZyB0aGUg T3B0aW9uIERlbHRhCiAgICAgICAgICAgICBmaWVsZHMgb2YgdGhpcyBhbmQgcHJldmlvdXMgb3B0 aW9ucyBiZWZvcmUgaXQuICBUaHJlZQogICAgICAgICAgICAgdmFsdWVzIGFyZSByZXNlcnZlZCBm b3Igc3BlY2lhbCBjb25zdHJ1Y3RzOgoKICAgICAgICAgICAgIDEzOiAgQW4gOC1iaXQgdW5zaWdu ZWQgaW50ZWdlciBmb2xsb3dzIHRoZSBpbml0aWFsIGJ5dGUgYW5kCiAgICAgICAgICAgICAgICAg IGluZGljYXRlcyB0aGUgT3B0aW9uIERlbHRhIG1pbnVzIDEzLgoKICAgICAgICAgICAgIDE0OiAg QSAxNi1iaXQgdW5zaWduZWQgaW50ZWdlciBmb2xsb3dzIHRoZSBpbml0aWFsIGJ5dGUgYW5kCiAg ICAgICAgICAgICAgICAgIGluZGljYXRlcyB0aGUgT3B0aW9uIERlbHRhIG1pbnVzIDI2OS4KCiAg ICAgICAgICAgICAxNTogIFJlc2VydmVkIGZvciB0aGUgUGF5bG9hZCBNYXJrZXI7IHNlZSBTZWN0 aW9uIDMuNAogICAgICAgICAgICAgICAgICBiZWxvdy4KCiAgIExlbmd0aDogICA0LWJpdCB1bnNp Z25lZCBpbnRlZ2VyLiAgSW5kaWNhdGVzIHRoZSBsZW5ndGggb2YgdGhlIE9wdGlvbgogICAgICAg ICAgICAgVmFsdWUsIGluIGJ5dGVzLiAgVGhyZWUgdmFsdWVzIGFyZSByZXNlcnZlZCBmb3Igc3Bl Y2lhbAogICAgICAgICAgICAgY29uc3RydWN0czoKCgoKCgpIYXJ0a2UgICAgICAgICAgICAgICAg ICAgIEV4cGlyZXMgTWF5IDI5LCAyMDEzICAgICAgICAgICAgICAgICAgW1BhZ2UgM10KDApJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgTmV3IENvQVAgTWVzc2FnZSBGb3JtYXQgICAgICAgICAgIE5v dmVtYmVyIDIwMTIKCgogICAgICAgICAgICAgMTM6ICBBbiA4LWJpdCB1bnNpZ25lZCBpbnRlZ2Vy IHByZWNlZGVzIHRoZSBPcHRpb24gVmFsdWUKICAgICAgICAgICAgICAgICAgYW5kIGluZGljYXRl cyB0aGUgT3B0aW9uIExlbmd0aCBtaW51cyAxMy4KCiAgICAgICAgICAgICAxNDogIEEgMTYtYml0 IHVuc2lnbmVkIGludGVnZXIgcHJlY2VkZXMgdGhlIE9wdGlvbiBWYWx1ZQogICAgICAgICAgICAg ICAgICBhbmQgaW5kaWNhdGVzIHRoZSBPcHRpb24gTGVuZ3RoIG1pbnVzIDI2OS4KCiAgICAgICAg ICAgICAxNTogIFJlc2VydmVkIGZvciBmdXR1cmUgdXNlLgoKICAgVmFsdWU6ICAgIFRoZSBsZW5n dGggYW5kIGZvcm1hdCBvZiB0aGUgT3B0aW9uIFZhbHVlIGRlcGVuZHMgb24gdGhlCiAgICAgICAg ICAgICByZXNwZWN0aXZlIG9wdGlvbiwgd2hpY2ggTUFZIGRlZmluZSB2YXJpYWJsZSBsZW5ndGgg dmFsdWVzLgogICAgICAgICAgICAgU2VlIFNlY3Rpb24gMy4zIGZvciB0aGUgZm9ybWF0cyB1c2Vk IGluIHRoaXMgZG9jdW1lbnQ7CiAgICAgICAgICAgICBvcHRpb25zIGRlZmluZWQgaW4gb3RoZXIg ZG9jdW1lbnRzIE1BWSBtYWtlIHVzZSBvZiBvdGhlcgogICAgICAgICAgICAgb3B0aW9uIHZhbHVl IGZvcm1hdHMuCgozLjMuICBPcHRpb24gVmFsdWUgRm9ybWF0cwoKICAgVGhlIG9wdGlvbnMgZGVm aW5lZCBpbiB0aGlzIGRvY3VtZW50IG1ha2UgdXNlIG9mIHRoZSBmb2xsb3dpbmcgb3B0aW9uCiAg IHZhbHVlIGZvcm1hdHMuIC4uLgoKMy40LiAgUGF5bG9hZCBGb3JtYXQKCiAgIEZvbGxvd2luZyB0 aGUgaGVhZGVyIGFuZCBvcHRpb25zIGNvbWVzIHRoZSBvcHRpb25hbCBwYXlsb2FkLiAgSWYKICAg cHJlc2VudCwgaXQgaXMgcHJlZml4ZWQgYnkgYSBmaXhlZCwgb25lLWJ5dGUgUGF5bG9hZCBNYXJr ZXIgKDB4RjApCiAgIHdoaWNoIGluZGljYXRlcyB0aGUgZW5kIG9mIHRoZSBsaXN0IG9mIG9wdGlv bnMgYW5kIHRoZSBzdGFydCBvZiB0aGUKICAgcGF5bG9hZC4gIFRoZSBwYXlsb2FkIGRhdGEgZXh0 ZW5kcyBmcm9tIGFmdGVyIHRoZSBtYXJrZXIgdG8gdGhlIGVuZAogICBvZiB0aGUgVURQIGRhdGFn cmFtLCBpLmUuLCB0aGUgUGF5bG9hZCBMZW5ndGggaXMgY2FsY3VsYXRlZCBmcm9tIHRoZQogICBk YXRhZ3JhbSBzaXplLgoKICAgICAgICAgICAgICAgICAgICAgMCAgIDEgICAyICAgMyAgIDQgICA1 ICAgNiAgIDcKICAgICAgICAgICAgICAgICAgICstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0r LS0tKwogICAgICAgICAgICAgICAgICAgfCAgIHwgICB8ICAgfCAgIHwgICB8ICAgfCAgIHwgICB8 CiAgICAgICAgICAgICAgICAgICB8IDEgfCAxIHwgMSB8IDEgfCAwIHwgMCB8IDAgfCAwIHwgICAx IGJ5dGUKICAgICAgICAgICAgICAgICAgIHwgICB8ICAgfCAgIHwgICB8ICAgfCAgIHwgICB8ICAg fAogICAgICAgICAgICAgICAgICAgKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rCiAg ICAgICAgICAgICAgICAgICBcICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAg ICAgICAgICAgICAgIC8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLwogICAgICAgICAg ICAgICAgICAgXCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgICAgICAg ICAgICAvICAgICAgICAgICAgUGF5bG9hZCAgICAgICAgICAgIC8gICAwIG9yIG1vcmUgYnl0ZXMK ICAgICAgICAgICAgICAgICAgIFwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAg ICAgICAgICAgICAgICAgLyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAvCiAgICAgICAg ICAgICAgICAgICBcICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgICAg ICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwoKICAgICAgICAgICAgICAg ICAgICAgICAgIEZpZ3VyZSAzOiBQYXlsb2FkIEZvcm1hdAoKICAgTm8gZGlzdGluY3Rpb24gaXMg YmVpbmcgbWFkZSBiZXR3ZWVuIGEgbWVzc2FnZSB3aXRoIG5vIHBheWxvYWQgYW5kIGEKICAgemVy by1sZW5ndGggcGF5bG9hZC4gIEVpdGhlciBjYXNlIGRlbm90ZXMgYSB6ZXJvLWxlbmd0aCBwYXls b2FkLgoKCgoKSGFydGtlICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE1heSAyOSwgMjAxMyAg ICAgICAgICAgICAgICAgIFtQYWdlIDRdCg== --f46d042f9eb0db3b9a04cf4683bb-- From cabo@tzi.org Sat Nov 24 22:48:52 2012 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 E1BBE21F8518 for ; Sat, 24 Nov 2012 22:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.333 X-Spam-Level: X-Spam-Status: No, score=-106.333 tagged_above=-999 required=5 tests=[AWL=-0.084, 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 7VjOpg84Mp5S for ; Sat, 24 Nov 2012 22:48:52 -0800 (PST) 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 C74D721F8521 for ; Sat, 24 Nov 2012 22:48:51 -0800 (PST) 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 qAP6mg2e005786 for ; Sun, 25 Nov 2012 07:48:42 +0100 (CET) Received: from [192.168.217.105] (p548922FD.dip.t-dialin.net [84.137.34.253]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4CA79961; Sun, 25 Nov 2012 07:48:42 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Sun, 25 Nov 2012 07:48:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9FCF6E24-CE7C-4E26-887A-0918369C992D@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> <3DDE1B3C-CBF4-4773-A3C2-AA61856B270C@sensinode.com> To: Klaus Hartke X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] CoAP jump mechanism 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, 25 Nov 2012 06:48:53 -0000 On Nov 25, 2012, at 01:00, Klaus Hartke wrote: > * More fancy artwork. I liked the old version (32 bits in a row) better. (The one-byte-per row format is fine for the option.) Terminologically, I'd stick with a fixed 4-byte header, which is = followed by the Token value, if any. ** Technical comments: What happened to 8-byte Tokens? Is that an intentional change? Do use 0xFF for the payload marker. (In transports without a length indication, we could use 0xF0 etc. for a = payload size indication later, using the same encoding for the second = nibble as for the option length. 0xF as a length nibble then just means = "indefinite length", i.e. until the end of the PDU.) "Reserved for future use" does not mean anything with respect to packet = processing rules. -> MUST be sent as 0. MUST be processed as an encoding error unless = received as 0. =20 (Again with s/0/15/ later). Gr=FC=DFe, Carsten From hartke@tzi.org Wed Nov 28 00:21:21 2012 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 E1D5921F8623 for ; Wed, 28 Nov 2012 00:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.627 X-Spam-Level: X-Spam-Status: No, score=-0.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_SUMOF=5, HELO_EQ_DE=0.35, 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 qI+ptbEI4D39 for ; Wed, 28 Nov 2012 00:21:21 -0800 (PST) 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 A392821F85B0 for ; Wed, 28 Nov 2012 00:21:20 -0800 (PST) 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 qAS8LCJv004085 for ; Wed, 28 Nov 2012 09:21:12 +0100 (CET) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 214508DD for ; Wed, 28 Nov 2012 09:21:11 +0100 (CET) Received: by mail-pa0-f44.google.com with SMTP id hz11so7385073pad.31 for ; Wed, 28 Nov 2012 00:21:10 -0800 (PST) Received: by 10.68.218.97 with SMTP id pf1mr55879680pbc.96.1354090870013; Wed, 28 Nov 2012 00:21:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.156.238 with HTTP; Wed, 28 Nov 2012 00:20:48 -0800 (PST) In-Reply-To: <9FCF6E24-CE7C-4E26-887A-0918369C992D@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> <3DDE1B3C-CBF4-4773-A3C2-AA61856B270C@sensinode.com> <9FCF6E24-CE7C-4E26-887A-0918369C992D@tzi.org> From: Klaus Hartke Date: Wed, 28 Nov 2012 09:20:48 +0100 Message-ID: To: "core@ietf.org WG" Content-Type: multipart/mixed; boundary=e89a8ff244fb4cfdb504cf89d968 Subject: Re: [core] CoAP jump mechanism 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, 28 Nov 2012 08:21:22 -0000 --e89a8ff244fb4cfdb504cf89d968 Content-Type: text/plain; charset=ISO-8859-1 I've updated the text with the two changes (0xFF payload marker and error unless reserved fields received as 0). Carsten Bormann wrote: > What happened to 8-byte Tokens? Is that an intentional change? Instead of a 3-bit field for the token length (0-7) and reserve a bit, we could alternatively use a 4-bit field and reserve lengths 9-15. Klaus --e89a8ff244fb4cfdb504cf89d968 Content-Type: text/plain; charset=US-ASCII; name="new-format-03.txt" Content-Disposition: attachment; filename="new-format-03.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ha26gy2i0 SW50ZXJuZXQtRHJhZnQgICAgICAgICAgIE5ldyBDb0FQIE1lc3NhZ2UgRm9ybWF0ICAgICAgICAg ICBOb3ZlbWJlciAyMDEyCgoKMy4gIE1lc3NhZ2UgRm9ybWF0CgogICBDb0FQIG1lc3NhZ2VzIGFy ZSBlbmNvZGVkIGluIGEgc2ltcGxlIGJpbmFyeSBmb3JtYXQuICBCeSBkZWZhdWx0LAogICBlYWNo IG1lc3NhZ2Ugb2NjdXBpZXMgdGhlIGRhdGEgc2VjdGlvbiBvZiBvbmUgVURQIGRhdGFncmFtLiAg VGhlCiAgIG1lc3NhZ2UgZm9ybWF0IHN0YXJ0cyB3aXRoIGEgaGVhZGVyIHdoaWNoIGlzIHZhcmlh YmxlIGluIGxlbmd0aCBhbmQKICAgY2FuIGJlIGJldHdlZW4gNCB0byAxMSBieXRlcyBsb25nLiAg Rm9sbG93aW5nIHRoZSBoZWFkZXIgY29tZXMgYSBsaXN0CiAgIG9mIHplcm8gb3IgbW9yZSBDb0FQ IE9wdGlvbnMgaW4gVHlwZS1MZW5ndGgtVmFsdWUgKFRMVikgZm9ybWF0IGFuZAogICBvcHRpb25h bGx5IGEgcGF5bG9hZCB3aGljaCB0YWtlcyB1cCB0aGUgcmVzdCBvZiB0aGUgZGF0YWdyYW0uCgog ICBDb0FQIG1heSBhbHNvIGJlIHVzZWQgb3ZlciBEYXRhZ3JhbSBUcmFuc3BvcnQgTGF5ZXIgU2Vj dXJpdHkgKERUTFMpOwogICBzZWUgU2VjdGlvbiA5LiAgSXQgY291bGQgYWxzbyBiZSB1c2VkIG92 ZXIgb3RoZXIgdHJhbnNwb3J0cywgdGhlCiAgIHNwZWNpZmljYXRpb24gb2Ygd2hpY2ggaXMgb3V0 IG9mIHRoaXMgZG9jdW1lbnQncyBzY29wZS4KCjMuMS4gIEhlYWRlciBGb3JtYXQKCiAgIFRoZSBm b3JtYXQgb2YgdGhlIGhlYWRlciBpcyBhcyBmb2xsb3dzOgoKICAgICAgICAgICAgICAgICAgICAg MCAgIDEgICAyICAgMyAgIDQgICA1ICAgNiAgIDcKICAgICAgICAgICAgICAgICAgICstLS0tLS0t Ky0tLS0tLS0rLS0tKy0tLS0tLS0tLS0tKwogICAgICAgICAgICAgICAgICAgfCAgICAgICB8ICAg ICAgIHwgICB8ICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICB8IFZlci0gIHwgVHlwZSAg fCBSIHwgIFRva2VuICAgIHwgICAxIGJ5dGUKICAgICAgICAgICAgICAgICAgIHwgc2lvbiAgfCAg ICAgICB8ICAgfCAgTGVuZ3RoICAgfAogICAgICAgICAgICAgICAgICAgKy0tLS0tLS0rLS0tLS0t LSstLS0rLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgQ29kZSAgICAg ICAgICAgICAgfCAgIDEgYnl0ZQogICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfAogICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8CiAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgICAgICAgICAgICAgICAgICstLS0gICAgICAgTWVzc2FnZSBJRCAgICAgICAgLS0tKyAgIDIg Ynl0ZXMKICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fAogICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAg ICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICAgICAgICAg ICAgICAgICAgXCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgICAgICAg ICAgICAvICAgICAgICAgICAgIFRva2VuICAgICAgICAgICAgIC8gICAwLTcgYnl0ZXMKICAgICAg ICAgICAgICAgICAgIFwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICAg ICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCgogICAgICAgICAgICAg ICAgICAgICAgICAgIEZpZ3VyZSAxOiBIZWFkZXIgRm9ybWF0CgogICBUaGUgZmllbGRzIGluIHRo ZSBoZWFkZXIgYXJlIGRlZmluZWQgYXMgZm9sbG93czoKCiAgIFZlcnNpb246ICAyLWJpdCB1bnNp Z25lZCBpbnRlZ2VyLiAgSW5kaWNhdGVzIHRoZSBDb0FQIHZlcnNpb24gbnVtYmVyLgogICAgICAg ICAgICAgSW1wbGVtZW50YXRpb25zIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBNVVNUIHNldCB0aGlz IGZpZWxkCiAgICAgICAgICAgICB0byAxLiAgT3RoZXIgdmFsdWVzIGFyZSByZXNlcnZlZCBmb3Ig ZnV0dXJlIHZlcnNpb25zLgoKCgoKSGFydGtlICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE1h eSAzMSwgMjAxMyAgICAgICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgIE5ldyBDb0FQIE1lc3NhZ2UgRm9ybWF0ICAgICAgICAgICBOb3ZlbWJlciAyMDEyCgoK ICAgVHlwZTogICAgIDItYml0IHVuc2lnbmVkIGludGVnZXIuICBJbmRpY2F0ZXMgaWYgdGhpcyBt ZXNzYWdlIGlzIG9mCiAgICAgICAgICAgICB0eXBlIENvbmZpcm1hYmxlICgwKSwgTm9uLUNvbmZp cm1hYmxlICgxKSwgQWNrbm93bGVkZ2VtZW50CiAgICAgICAgICAgICAoMikgb3IgUmVzZXQgKDMp LiAgVGhlIHNlbWFudGljcyBvZiB0aGVzZSBtZXNzYWdlIHR5cGVzIGFyZQogICAgICAgICAgICAg ZGVmaW5lZCBpbiBTZWN0aW9uIDQuCgogICBSZXNlcnZlZDogMS1iaXQgdW5zaWduZWQgaW50ZWdl ci4gIFRoaXMgZmllbGQgTVVTVCBiZSBzZXQgdG8gMC4gIElmCiAgICAgICAgICAgICB0aGUgZmll bGQgaXMgbm90IHNldCB0byAwLCBpdCBNVVNUIGJlIHByb2Nlc3NlZCBhcyBhCiAgICAgICAgICAg ICBtZXNzYWdlIGZvcm1hdCBlcnJvci4KCiAgIFRva2VuIExlbmd0aDogIDMtYml0IHVuc2lnbmVk IGludGVnZXIuICBJbmRpY2F0ZXMgdGhlIGxlbmd0aCBvZiB0aGUKICAgICAgICAgICAgIHZhcmlh YmxlLWxlbmd0aCBUb2tlbiBmaWVsZCAoMC03IGJ5dGVzKS4KCiAgIENvZGU6ICAgICA4LWJpdCB1 bnNpZ25lZCBpbnRlZ2VyLiAgSW5kaWNhdGVzIGlmIHRoZSBtZXNzYWdlIGNhcnJpZXMgYQogICAg ICAgICAgICAgcmVxdWVzdCAoMS0zMSkgb3IgYSByZXNwb25zZSAoNjQtMTkxKSwgb3IgaXMgZW1w dHkgKDApLgogICAgICAgICAgICAgQWxsIG90aGVyIHZhbHVlcyBhcmUgcmVzZXJ2ZWQuICBJbiBj YXNlIG9mIGEgcmVxdWVzdCwgdGhlCiAgICAgICAgICAgICBDb2RlIGZpZWxkIGluZGljYXRlcyB0 aGUgUmVxdWVzdCBNZXRob2Q7IGluIGNhc2Ugb2YgYQogICAgICAgICAgICAgcmVzcG9uc2UgYSBS ZXNwb25zZSBDb2RlLiAgUG9zc2libGUgdmFsdWVzIGFyZSBtYWludGFpbmVkCiAgICAgICAgICAg ICBpbiB0aGUgQ29BUCBDb2RlIFJlZ2lzdHJ5IChTZWN0aW9uIDEyLjEpLiAgVGhlIHNlbWFudGlj cyBvZgogICAgICAgICAgICAgcmVxdWVzdHMgYW5kIHJlc3BvbnNlcyBhcmUgZGVmaW5lZCBpbiBT ZWN0aW9uIDUuCgogICBNZXNzYWdlIElEOiAgMTYtYml0IHVuc2lnbmVkIGludGVnZXIuICBVc2Vk IGZvciB0aGUgZGV0ZWN0aW9uIG9mCiAgICAgICAgICAgICBtZXNzYWdlIGR1cGxpY2F0aW9uLCBh bmQgdG8gbWF0Y2ggbWVzc2FnZXMgb2YgdHlwZQogICAgICAgICAgICAgQWNrbm93bGVkZ2VtZW50 L1Jlc2V0IHRvIG1lc3NhZ2VzIG9mIHR5cGUgQ29uZmlybWFibGUvCiAgICAgICAgICAgICBOb24t Q29uZmlybWFibGUuICBUaGUgcnVsZXMgZm9yIGdlbmVyYXRpbmcgYSBNZXNzYWdlIElEIGFuZAog ICAgICAgICAgICAgbWF0Y2hpbmcgbWVzc2FnZXMgYXJlIGRlZmluZWQgaW4gU2VjdGlvbiA0LgoK ICAgVG9rZW46ICAgIFVzZWQgdG8gY29ycmVsYXRlIHJlcXVlc3RzIGFuZCByZXNwb25zZXMuICBU aGUgcnVsZXMgZm9yCiAgICAgICAgICAgICBnZW5lcmF0aW5nIGEgVG9rZW4gYW5kIGNvcnJlbGF0 aW5nIHJlcXVlc3RzIGFuZCByZXNwb25zZXMKICAgICAgICAgICAgIGFyZSBkZWZpbmVkIGluIFNl Y3Rpb24gNS4KCjMuMi4gIE9wdGlvbiBGb3JtYXQKCiAgIENvQVAgZGVmaW5lcyBhIG51bWJlciBv ZiBvcHRpb25zIHdoaWNoIGNhbiBiZSBpbmNsdWRlZCBpbiBhIG1lc3NhZ2UuCiAgIEVhY2ggb3B0 aW9uIGluc3RhbmNlIGluIGEgbWVzc2FnZSBzcGVjaWZpZXMgdGhlIE9wdGlvbiBOdW1iZXIgb2Yg dGhlCiAgIGRlZmluZWQgQ29BUCBvcHRpb24sIHRoZSBsZW5ndGggb2YgdGhlIE9wdGlvbiBWYWx1 ZSBhbmQgdGhlIE9wdGlvbgogICBWYWx1ZSBpdHNlbGYuCgogICBJbnN0ZWFkIG9mIHNwZWNpZnlp bmcgdGhlIE9wdGlvbiBOdW1iZXIgZGlyZWN0bHksIHRoZSBpbnN0YW5jZXMgTVVTVAogICBhcHBl YXIgaW4gb3JkZXIgb2YgdGhlaXIgT3B0aW9uIE51bWJlcnMgYW5kIGEgZGVsdGEgZW5jb2Rpbmcg aXMgdXNlZAogICBiZXR3ZWVuIHRoZW06IFRoZSBPcHRpb24gTnVtYmVyIGZvciBlYWNoIGluc3Rh bmNlIGlzIGNhbGN1bGF0ZWQgYXMKICAgdGhlIHN1bSBvZiBpdHMgZGVsdGEgYW5kIHRoZSBPcHRp b24gTnVtYmVyIG9mIHRoZSBwcmVjZWRpbmcgaW5zdGFuY2UKICAgaW4gdGhlIG1lc3NhZ2UuICBG b3IgdGhlIGZpcnN0IGluc3RhbmNlIGluIGEgbWVzc2FnZSwgYSBwcmVjZWRpbmcKICAgb3B0aW9u IGluc3RhbmNlIHdpdGggT3B0aW9uIE51bWJlciB6ZXJvIGlzIGFzc3VtZWQuICBNdWx0aXBsZQog ICBpbnN0YW5jZXMgb2YgdGhlIHNhbWUgb3B0aW9uIGNhbiBiZSBpbmNsdWRlZCBieSB1c2luZyBh IGRlbHRhIG9mCiAgIHplcm8uCgogICBPcHRpb24gTnVtYmVycyBhcmUgbWFpbnRhaW5lZCBpbiB0 aGUgQ29BUCBPcHRpb24gTnVtYmVyIFJlZ2lzdHJ5CiAgIChTZWN0aW9uIDEyLjIpLiAgU2VlIFNl Y3Rpb24gNS4xMCBmb3IgdGhlIHNlbWFudGljcyBvZiB0aGUgb3B0aW9ucwogICBkZWZpbmVkIGlu IHRoaXMgZG9jdW1lbnQuCgoKSGFydGtlICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE1heSAz MSwgMjAxMyAgICAgICAgICAgICAgICAgIFtQYWdlIDJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgIE5ldyBDb0FQIE1lc3NhZ2UgRm9ybWF0ICAgICAgICAgICBOb3ZlbWJlciAyMDEyCgoKICAg ICAgICAgICAgICAgICAgICAgMCAgIDEgICAyICAgMyAgIDQgICA1ICAgNiAgIDcKICAgICAgICAg ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKwogICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAg ICB8ICBPcHRpb24gRGVsdGEgfCBPcHRpb24gTGVuZ3RoIHwgICAxIGJ5dGUKICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICBc ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgICAgICAgICAgIC8gICAg ICAgICBPcHRpb24gRGVsdGEgICAgICAgICAgLyAgIDAtMiBieXRlcwogICAgICAgICAgICAgICAg ICAgXCAgICAgICAgICAoZXh0ZW5kZWQpICAgICAgICAgICBcCiAgICAgICAgICAgICAgICAgICAr LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICAgIFwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICAgICAgICAgICAgLyAgICAgICAg IE9wdGlvbiBMZW5ndGggICAgICAgICAvICAgMC0yIGJ5dGVzCiAgICAgICAgICAgICAgICAgICBc ICAgICAgICAgIChleHRlbmRlZCkgICAgICAgICAgIFwKICAgICAgICAgICAgICAgICAgICstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICAgICAgICAgICAgICAgICAgXCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgICAgICAgICAgICAvICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIC8KICAgICAgICAgICAgICAgICAgIFwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgXAogICAgICAgICAgICAgICAgICAgLyAgICAgICAgIE9wdGlvbiBWYWx1 ZSAgICAgICAgICAvICAgMCBvciBtb3JlIGJ5dGVzCiAgICAgICAgICAgICAgICAgICBcICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgICAgICAgICAgIC8gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgLwogICAgICAgICAgICAgICAgICAgXCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBcCiAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSsKCiAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDI6IE9wdGlv biBGb3JtYXQKCiAgIFRoZSBmaWVsZHMgaW4gYW4gb3B0aW9uIGFyZSBkZWZpbmVkIGFzIGZvbGxv d3M6CgogICBEZWx0YTogICAgNC1iaXQgdW5zaWduZWQgaW50ZWdlci4gIEluZGljYXRlcyB0aGUg ZGlmZmVyZW5jZSBiZXR3ZWVuCiAgICAgICAgICAgICB0aGUgT3B0aW9uIE51bWJlciBvZiB0aGlz IG9wdGlvbiBhbmQgdGhlIHByZXZpb3VzIG9wdGlvbgogICAgICAgICAgICAgKG9yIHplcm8gZm9y IHRoZSBmaXJzdCBvcHRpb24pLiAgSW4gb3RoZXIgd29yZHMsIHRoZSBPcHRpb24KICAgICAgICAg ICAgIE51bWJlciBpcyBjYWxjdWxhdGVkIGJ5IHNpbXBseSBzdW1taW5nIHRoZSBPcHRpb24gRGVs dGEKICAgICAgICAgICAgIGZpZWxkcyBvZiB0aGlzIGFuZCBwcmV2aW91cyBvcHRpb25zIGJlZm9y ZSBpdC4gIFRocmVlCiAgICAgICAgICAgICB2YWx1ZXMgYXJlIHJlc2VydmVkIGZvciBzcGVjaWFs IGNvbnN0cnVjdHM6CgogICAgICAgICAgICAgMTM6ICBBbiA4LWJpdCB1bnNpZ25lZCBpbnRlZ2Vy IGZvbGxvd3MgdGhlIGluaXRpYWwgYnl0ZSBhbmQKICAgICAgICAgICAgICAgICAgaW5kaWNhdGVz IHRoZSBPcHRpb24gRGVsdGEgbWludXMgMTMuCgogICAgICAgICAgICAgMTQ6ICBBIDE2LWJpdCB1 bnNpZ25lZCBpbnRlZ2VyIGZvbGxvd3MgdGhlIGluaXRpYWwgYnl0ZSBhbmQKICAgICAgICAgICAg ICAgICAgaW5kaWNhdGVzIHRoZSBPcHRpb24gRGVsdGEgbWludXMgMjY5LgoKICAgICAgICAgICAg IDE1OiAgUmVzZXJ2ZWQgZm9yIHRoZSBQYXlsb2FkIE1hcmtlcjsgc2VlIFNlY3Rpb24gMy40CiAg ICAgICAgICAgICAgICAgIGJlbG93LgoKICAgTGVuZ3RoOiAgIDQtYml0IHVuc2lnbmVkIGludGVn ZXIuICBJbmRpY2F0ZXMgdGhlIGxlbmd0aCBvZiB0aGUgT3B0aW9uCiAgICAgICAgICAgICBWYWx1 ZSwgaW4gYnl0ZXMuICBUaHJlZSB2YWx1ZXMgYXJlIHJlc2VydmVkIGZvciBzcGVjaWFsCiAgICAg ICAgICAgICBjb25zdHJ1Y3RzOgoKCgoKCkhhcnRrZSAgICAgICAgICAgICAgICAgICAgRXhwaXJl cyBNYXkgMzEsIDIwMTMgICAgICAgICAgICAgICAgICBbUGFnZSAzXQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgICBOZXcgQ29BUCBNZXNzYWdlIEZvcm1hdCAgICAgICAgICAgTm92ZW1iZXIgMjAx MgoKCiAgICAgICAgICAgICAxMzogIEFuIDgtYml0IHVuc2lnbmVkIGludGVnZXIgcHJlY2VkZXMg dGhlIE9wdGlvbiBWYWx1ZQogICAgICAgICAgICAgICAgICBhbmQgaW5kaWNhdGVzIHRoZSBPcHRp b24gTGVuZ3RoIG1pbnVzIDEzLgoKICAgICAgICAgICAgIDE0OiAgQSAxNi1iaXQgdW5zaWduZWQg aW50ZWdlciBwcmVjZWRlcyB0aGUgT3B0aW9uIFZhbHVlCiAgICAgICAgICAgICAgICAgIGFuZCBp bmRpY2F0ZXMgdGhlIE9wdGlvbiBMZW5ndGggbWludXMgMjY5LgoKICAgICAgICAgICAgIDE1OiAg UmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2UuICBJZiB0aGUgZmllbGQgaXMgc2V0IHRvIHRoaXMKICAg ICAgICAgICAgICAgICAgdmFsdWUsIGl0IE1VU1QgYmUgcHJvY2Vzc2VkIGFzIGEgbWVzc2FnZSBm b3JtYXQgZXJyb3IuCgogICBWYWx1ZTogICAgVGhlIGxlbmd0aCBhbmQgZm9ybWF0IG9mIHRoZSBP cHRpb24gVmFsdWUgZGVwZW5kcyBvbiB0aGUKICAgICAgICAgICAgIHJlc3BlY3RpdmUgb3B0aW9u LCB3aGljaCBNQVkgZGVmaW5lIHZhcmlhYmxlIGxlbmd0aCB2YWx1ZXMuCiAgICAgICAgICAgICBT ZWUgU2VjdGlvbiAzLjMgZm9yIHRoZSBmb3JtYXRzIHVzZWQgaW4gdGhpcyBkb2N1bWVudDsKICAg ICAgICAgICAgIG9wdGlvbnMgZGVmaW5lZCBpbiBvdGhlciBkb2N1bWVudHMgTUFZIG1ha2UgdXNl IG9mIG90aGVyCiAgICAgICAgICAgICBvcHRpb24gdmFsdWUgZm9ybWF0cy4KCjMuMy4gIE9wdGlv biBWYWx1ZSBGb3JtYXRzCgogICBUaGUgb3B0aW9ucyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQg bWFrZSB1c2Ugb2YgdGhlIGZvbGxvd2luZyBvcHRpb24KICAgdmFsdWUgZm9ybWF0cy4gLi4uCgoz LjQuICBQYXlsb2FkIEZvcm1hdAoKICAgRm9sbG93aW5nIHRoZSBoZWFkZXIgYW5kIG9wdGlvbnMg Y29tZXMgdGhlIG9wdGlvbmFsIHBheWxvYWQuICBJZgogICBwcmVzZW50LCBpdCBpcyBwcmVmaXhl ZCBieSBhIGZpeGVkLCBvbmUtYnl0ZSBQYXlsb2FkIE1hcmtlciAoMHhGRikKICAgd2hpY2ggaW5k aWNhdGVzIHRoZSBlbmQgb2YgdGhlIGxpc3Qgb2Ygb3B0aW9ucyBhbmQgdGhlIHN0YXJ0IG9mIHRo ZQogICBwYXlsb2FkLiAgVGhlIHBheWxvYWQgZGF0YSBleHRlbmRzIGZyb20gYWZ0ZXIgdGhlIG1h cmtlciB0byB0aGUgZW5kCiAgIG9mIHRoZSBVRFAgZGF0YWdyYW0sIGkuZS4sIHRoZSBQYXlsb2Fk IExlbmd0aCBpcyBjYWxjdWxhdGVkIGZyb20gdGhlCiAgIGRhdGFncmFtIHNpemUuCgogICAgICAg ICAgICAgICAgICAgICAwICAgMSAgIDIgICAzICAgNCAgIDUgICA2ICAgNwogICAgICAgICAgICAg ICAgICAgKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rCiAgICAgICAgICAgICAgICAg ICB8ICAgfCAgIHwgICB8ICAgfCAgIHwgICB8ICAgfCAgIHwKICAgICAgICAgICAgICAgICAgIHwg MSB8IDEgfCAxIHwgMSB8IDEgfCAxIHwgMSB8IDEgfCAgIDEgYnl0ZQogICAgICAgICAgICAgICAg ICAgfCAgIHwgICB8ICAgfCAgIHwgICB8ICAgfCAgIHwgICB8CiAgICAgICAgICAgICAgICAgICAr LS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSsKICAgICAgICAgICAgICAgICAgIFwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICAgICAgICAgICAgLyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAvCiAgICAgICAgICAgICAgICAgICBcICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgICAgICAgICAgIC8gICAgICAgICAgICBQYXls b2FkICAgICAgICAgICAgLyAgIDAgb3IgbW9yZSBieXRlcwogICAgICAgICAgICAgICAgICAgXCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgICAgICAgICAgICAvICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIC8KICAgICAgICAgICAgICAgICAgIFwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rCgogICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDM6IFBh eWxvYWQgRm9ybWF0CgogICBObyBkaXN0aW5jdGlvbiBpcyBiZWluZyBtYWRlIGJldHdlZW4gYSBt ZXNzYWdlIHdpdGggbm8gcGF5bG9hZCBhbmQgYQogICB6ZXJvLWxlbmd0aCBwYXlsb2FkLiAgRWl0 aGVyIGNhc2UgZGVub3RlcyBhIHplcm8tbGVuZ3RoIHBheWxvYWQuCgoKCkhhcnRrZSAgICAgICAg ICAgICAgICAgICAgRXhwaXJlcyBNYXkgMzEsIDIwMTMgICAgICAgICAgICAgICAgICBbUGFnZSA0 XQo= --e89a8ff244fb4cfdb504cf89d968-- From cabo@tzi.org Wed Nov 28 11:24:16 2012 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 5C12D21F84D0 for ; Wed, 28 Nov 2012 11:24:16 -0800 (PST) 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 SJyW+kvcKhjB for ; Wed, 28 Nov 2012 11:24:15 -0800 (PST) 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 D361F21F8597 for ; Wed, 28 Nov 2012 11:24:13 -0800 (PST) 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 qASJO6dQ009998 for ; Wed, 28 Nov 2012 20:24:06 +0100 (CET) Received: from [172.18.204.20] (unknown [81.253.36.0]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5233DDD0; Wed, 28 Nov 2012 20:24:03 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Carsten Bormann In-Reply-To: Date: Wed, 28 Nov 2012 20:23:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> <3DDE1B3C-CBF4-4773-A3C2-AA61856B270C@sensinode.com> <9FCF6E24-CE7C-4E26-887A-0918369C992D@tzi.org> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1499) Subject: [core] Are we ready for a consensus call? (Re: CoAP jump mechanism) 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, 28 Nov 2012 19:24:16 -0000 On Nov 28, 2012, at 09:20, Klaus Hartke wrote: > Instead of a 3-bit field for the token length (0-7) and reserve a bit, > we could alternatively use a 4-bit field and reserve lengths 9-15. OK, for now I'll assume that is the proposal, because the current range = (1-8 bytes explicit, 0 bytes default) was arrived at after quite some = discussion and nobody has argued for changing the Token size in a long = time. (We still could, but this is simply an orthogonal discussion from the = encoding change.) ** Editorial comments This little snippet still has somewhat out-of-character Figure 1, which = should be reverted to one that looks like most other header formats we = use in the IETF. (I know that it probably was a lot of work to come up = with the ASCII art...) (It also could use "Token (if present)" just to make sure that people = understand a zero-length Token is a rather normal situation; we are just = no longer making it "optional" because we no longer save a byte for the = option header when not actually sending it.) It might be useful to find a good place for a sentence such as "The sequence of options is terminated either by the end of the message = or by the Payload Marker". I don't think 3.4 defines a "Payload Format". (That comes after the = Payload Marker and is described by the Content-Format.) Instead, I think the Payload Marker could usefully be included in Figure = 1. s/with no payload and a zero-length payload./with no payload marker and = a payload marker followed by a zero-length payload./ or so. While we are at it, we might as well fix: s/this and previous/this and all previous/ (All these editorial fixes can, of course, be done by the editors later, = but it helps to work in parallel, and editorial clarity helps ensuring a = consensus is genuine.) ** Discussion here are ETSI COAP2 interop We have had some hallway discussions here today in the ETSI plugtest = event. ETSI plugtests are covered by an NDA, but I don't think I'm breaching = that by saying that the reception I saw was unanimously non-negative*) = and some participants even saw a chance to run some of the tests again = during the week with the new encoding (yes, swapping out the encoding is = that easy). ** WG chair hat on While the code changes are trivial, making this late change would, = again, break compatibility with all the tools already out there. (You may not be aware that one may already be installed on your = laptop...) So if the feedback continues to be positive, I would like to make an = explicit consensus call for this change soon. This will not need a two-week period,=20 Because it will be a short consensus call, you might want to answer it = (or prepare an answer) right away. Gr=FC=DFe, Carsten *) not everybody cared, so I couldn't say "unanimously positive", but = the average was perceptibly above zero. From zach@sensinode.com Wed Nov 28 13:06:28 2012 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 1553A21F85D9 for ; Wed, 28 Nov 2012 13:06:28 -0800 (PST) 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 C3LACl-QVyV3 for ; Wed, 28 Nov 2012 13:06:27 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 048AD21F85D2 for ; Wed, 28 Nov 2012 13:06:26 -0800 (PST) Received: from [192.168.254.26] (77.16.13.144.tmi.telenormobil.no [77.16.13.144]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id qASL6LB8016432; Wed, 28 Nov 2012 23:06:22 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Wed, 28 Nov 2012 22:06:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <598B2F5E-2DBD-4BF8-8703-1A33F404B5C1@sensinode.com> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> <3DDE1B3C-CBF4-4773-A3C2-AA61856B270C@sensinode.com> <9FCF6E24-CE7C-4E26-887A-0918369C992D@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org WG" Subject: Re: [core] Are we ready for a consensus call? (Re: CoAP jump mechanism) 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, 28 Nov 2012 21:06:28 -0000 On Nov 28, 2012, at 8:23 PM, Carsten Bormann wrote: > ** WG chair hat on >=20 > While the code changes are trivial, making this late change would, = again, break compatibility with all the tools already out there. > (You may not be aware that one may already be installed on your = laptop...) > So if the feedback continues to be positive, I would like to make an = explicit consensus call for this change soon. > This will not need a two-week period,=20 > Because it will be a short consensus call, you might want to answer it = (or prepare an answer) right away. And since coap-12 is only being interop tested right now, (right) now = would be the right time to make such a small update in coap-13 and fix = the issue for good. It will only get more painful to fix after a WGLC or = during the IESG process.... I can already state that I am in favor of = bringing this update into a quick coap-13 update, but would prefer that = to be done already next week. Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From jeroen.hoebeke@intec.ugent.be Thu Nov 29 03:12:56 2012 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 449E821F8A03 for ; Thu, 29 Nov 2012 03:12:56 -0800 (PST) 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 BGDGwGG+h9Yu for ; Thu, 29 Nov 2012 03:12:55 -0800 (PST) Received: from smtp2.ugent.be (smtp2.ugent.be [157.193.49.126]) by ietfa.amsl.com (Postfix) with ESMTP id DBD7B21F89F9 for ; Thu, 29 Nov 2012 03:12:49 -0800 (PST) Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp2.ugent.be (Postfix) with ESMTP id CB74712C33F; Thu, 29 Nov 2012 12:12:48 +0100 (CET) X-Virus-Scanned: by UGent DICT Received: from smtp2.ugent.be ([157.193.49.126]) by localhost (mcheck2.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id naTDtl65M3Mj; Thu, 29 Nov 2012 12:12:48 +0100 (CET) Received: from [10.200.6.2] (unknown [217.13.60.234]) (Authenticated sender: jjhoebek) by smtp2.ugent.be (Postfix) with ESMTPSA id 508A612C337; Thu, 29 Nov 2012 12:12:48 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Jeroen Hoebeke In-Reply-To: Date: Thu, 29 Nov 2012 12:12:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6AF38EAF-DB60-4D6F-AE99-5226034917DB@intec.ugent.be> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> <3DDE1B3C-CBF4-4773-A3C2-AA61856B270C@sensinode.com> <9FCF6E24-CE7C-4E26-887A-0918369C992D@tzi.org> To: Klaus Hartke X-Mailer: Apple Mail (2.1499) X-Miltered: at jchkm3 with ID 50B7432F.001 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 50B7432F.001 from unknown/unknown/217.13.60.234/[10.200.6.2]/ X-j-chkmail-Score: MSGID : 50B7432F.001 on smtp2.ugent.be : j-chkmail score : X : R=. U=. O=## B=0.000 -> S=0.166 X-j-chkmail-Status: Ham Cc: "core@ietf.org WG" Subject: Re: [core] CoAP jump mechanism 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, 29 Nov 2012 11:12:56 -0000 On 28 Nov 2012, at 09:20, Klaus Hartke wrote: > I've updated the text with the two changes (0xFF payload marker and > error unless reserved fields received as 0). Section 3.4 of the improved message format says that the payload marker = can be used even if the payload size is 0 bytes. This leaves open the possibility to use this marker again as an = end-of-options marker. Maybe the text should state explicitly that the = marker must not be used if there is no payload (0 bytes) in order to = have unambiguous messages. Kind regards, Jeroen From carine@jay.w3.org Thu Nov 29 02:00:46 2012 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 10F5F21F855D for ; Thu, 29 Nov 2012 02:00:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 mDPEfaXYNt85 for ; Thu, 29 Nov 2012 02:00:45 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 2E98C21F84C4 for ; Thu, 29 Nov 2012 02:00:44 -0800 (PST) Received: from carine by jay.w3.org with local (Exim 4.69) (envelope-from ) id 1Te0vB-0000Dd-8A for core@ietf.org; Thu, 29 Nov 2012 05:00:41 -0500 Date: Thu, 29 Nov 2012 05:00:41 -0500 From: Carine Bournez To: core@ietf.org Message-ID: <20121129100041.GA14246@jay.w3.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-Mailman-Approved-At: Thu, 29 Nov 2012 03:13:01 -0800 Subject: [core] W3C EXI WG review of IETF CoRE WG Internet Drafts 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, 29 Nov 2012 10:00:46 -0000 Dear CoRE WG members, The W3C EXI Working Group has reviewed two CoRE I-Ds: http://trac.tools.ietf.org/id/draft-doi-core-parameter-option-01.txt http://trac.tools.ietf.org/id/draft-doi-exi-messaging-requirements-00.txt Here is a summary of our discussions. About section 2 of "CoAP Content-Type Parameter Option" http://trac.tools.ietf.org/id/draft-doi-core-parameter-option-01.txt We believe that the choice of a content-type parameter is a good one (as long as it does get implemented effectively by endpoints). However, the cleanest way would be still to use a content-encoding mechanism rather than a separate content-type indicating that EXI is used. So instead of: 'Accept: application/example-exi;sv=1.4' we suggest: 'Accept: application/example;sv=1.4' 'Accept-encoding: exi' About the second I-D, "EXI Messaging Requirements" http://trac.tools.ietf.org/id/draft-doi-exi-messaging-requirements-00.txt For the schema versioning concern mentioned in section 2.1, we interpeted the text (in the light of the core-parameter-option I-D ) as "schemaId will be sent as a content-type parameter". We want to highlight the fact that in practice the idea of using a 'Major.Minor' version number might not be needed. For minor changes to the schema, it may be interesting to use the deviation capabilities of the EXI processors, rather than offering a new schema for the content-type and deploy the change on a lot of endpoints. It would be easier to advise users to change the schema (to be negotiated) only when really necessary, i.e. format changes enable measurable performance improvements. For the Efficient XML Interchange Working Group, -- Carine Bournez -+- W3C From yusuke.doi@toshiba.co.jp Thu Nov 29 06:16:49 2012 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 624C321F88DE for ; Thu, 29 Nov 2012 06:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 WoMaWAYDpxDD for ; Thu, 29 Nov 2012 06:16:49 -0800 (PST) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id B4CDC21F88C2 for ; Thu, 29 Nov 2012 06:16:48 -0800 (PST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id qATEGlC8029648 for ; Thu, 29 Nov 2012 23:16:47 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id qATEGlZU013281 for core@ietf.org; Thu, 29 Nov 2012 23:16:47 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id ZAA13278; Thu, 29 Nov 2012 23:16:47 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id qATEGkV1014483 for ; Thu, 29 Nov 2012 23:16:46 +0900 (JST) Received: by toshiba.co.jp id qATEGkf3012739; Thu, 29 Nov 2012 23:16:46 +0900 (JST) Date: Thu, 29 Nov 2012 23:16:45 +0900 (JST) Message-Id: <201211291416.qATEGkf3012739@toshiba.co.jp> To: carine@w3.org From: DOI Yusuke In-Reply-To: <20121129100041.GA14246@jay.w3.org> References: <20121129100041.GA14246@jay.w3.org> X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: core@ietf.org Subject: Re: [core] W3C EXI WG review of IETF CoRE WG Internet Drafts 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, 29 Nov 2012 14:16:49 -0000 Dear Carine, Thank you for the review. I think your comments are on rather broader topic compared to the core wg's scope. I wonder if we can continue this topic on this list. Should we move it to apps-discuss or else? (For example, Content-Type for schema-informed EXI was discussed in apps-discuss, not in core-wg). Regards, // Yusuke DOI , TOSHIBA R&D Center From cabo@tzi.org Thu Nov 29 08:59:27 2012 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 7BE3121F84E8 for ; Thu, 29 Nov 2012 08:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.794 X-Spam-Level: X-Spam-Status: No, score=-105.794 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_42=0.6, 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 QQODGUV1fulW for ; Thu, 29 Nov 2012 08:59:26 -0800 (PST) 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 9484621F8A34 for ; Thu, 29 Nov 2012 08:59:25 -0800 (PST) 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 qATGxCpv027808 for ; Thu, 29 Nov 2012 17:59:12 +0100 (CET) Received: from [10.200.12.5] (unknown [217.13.60.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9F8873C3; Thu, 29 Nov 2012 17:59:12 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Carsten Bormann In-Reply-To: Date: Thu, 29 Nov 2012 17:59:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> <3DDE1B3C-CBF4-4773-A3C2-AA61856B270C@sensinode.com> <9FCF6E24-CE7C-4E26-887A-0918369C992D@tzi.org> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1499) Subject: Re: [core] Are we ready for a consensus call? (Re: CoAP jump mechanism) 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, 29 Nov 2012 16:59:28 -0000 On Nov 28, 2012, at 20:23, Carsten Bormann wrote: > ** Discussion here are ETSI COAP2 interop A quick status update from Sophia Antipolis: It took me exactly 30 minutes to move the coap.me code from coap-12 to = the "Klaus encoding". (16 minutes of code writing and 14 minutes of debugging. Don't hire me = as a programmer...) We are now beginning the interop testing. Gr=FC=DFe, Carsten From cabo@tzi.org Fri Nov 30 01:14:01 2012 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 0331E21F84F1 for ; Fri, 30 Nov 2012 01:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.546 X-Spam-Level: X-Spam-Status: No, score=-103.546 tagged_above=-999 required=5 tests=[AWL=-2.297, BAYES_00=-2.599, GB_SUMOF=5, 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 0VnsFNW9i8W8 for ; Fri, 30 Nov 2012 01:14:00 -0800 (PST) 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 2890621F84E1 for ; Fri, 30 Nov 2012 01:13:59 -0800 (PST) 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 qAU9DqD7025489 for ; Fri, 30 Nov 2012 10:13:52 +0100 (CET) Received: from [10.200.12.5] (unknown [217.13.60.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3F4275C6; Fri, 30 Nov 2012 10:13:52 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Carsten Bormann In-Reply-To: Date: Fri, 30 Nov 2012 10:13:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> <3DDE1B3C-CBF4-4773-A3C2-AA61856B270C@sensinode.com> <9FCF6E24-CE7C-4E26-887A-0918369C992D@tzi.org> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1499) Subject: Re: [core] Are we ready for a consensus call? (Re: CoAP jump mechanism) 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, 30 Nov 2012 09:14:01 -0000 On Nov 29, 2012, at 17:59, Carsten Bormann wrote: > We are now beginning the interop testing. I can report that the first three pairings of tests are already = completed successfully, so far with no glitches at all. While this is ongoing, another data point. Klaus' encoding saves a byte when non-default tokens are present, and = uses an additional byte for non-zero-length payloads. (The other changes in efficiency are probably second-order.) It depends on your traffic mix whether that is a net lose or a net win. The corpus Klaus used for his original numbers might be more Token-heavy = than others, so I tried to run a more representative test. I used the pcap files from all the plugtest runs I personally = participated in on Wednesday and Thursday. That should be a good traffic mix, closer to what a mix of current = implementations is going to do. I tallied the sum of the message sizes and subtracted the sum of the = sizes of the payload, taking the original coap-12 messages and the same = messages converted into Klaus' encoding. In other words, I have, for both encodings, a sum of the sizes of the = header, the options, and (in case of Klaus' encoding) the payload = marker. =20 (I didn't want the actual payloads to be included, because they are = often just "hello world" style messages during the plug test. =20 So, relative to the total size of the packets, the increase will be = smaller.) The numbers: total_klaus_net 108751 total_12_net 106287 This seems to indicate that, for this traffic mix, we buy the decrease = in complexity by an increase of 2.3 % in header overhead. Obviously, this is just one more data point. =20 The ratio in sizes is quite stable when comparing Wednesday and Thursday = (different test peers). It may still be biased by properties of my implementation, both with = respect to the traffic mix originated from my implementation during the = plugtests and as a result of potential performance bugs in my Klaus = encoder (although the latter is not very plausible). Gr=FC=DFe, Carsten From cabo@tzi.org Fri Nov 30 02:02:06 2012 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 520C621F84F8 for ; Fri, 30 Nov 2012 02:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.472 X-Spam-Level: X-Spam-Status: No, score=-105.472 tagged_above=-999 required=5 tests=[AWL=0.777, 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 3SQascUQMPOi for ; Fri, 30 Nov 2012 02:02:05 -0800 (PST) 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 8A06521F84F3 for ; Fri, 30 Nov 2012 02:02:05 -0800 (PST) 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 qAUA21C4024844 for ; Fri, 30 Nov 2012 11:02:01 +0100 (CET) Received: from [10.200.12.5] (unknown [217.13.60.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 54C89643; Fri, 30 Nov 2012 11:02:01 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Nov 2012 11:02:00 +0100 To: "core@ietf.org WG" Message-Id: <5E28C76D-5E80-4EA0-9A9F-A8A930552099@tzi.org> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [core] Should DNS usage of CoAP implementations favor SRV? 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, 30 Nov 2012 10:02:06 -0000 CoAP is deliberately not tying itself to DNS in any major way. That is a good thing, as many CoAP deployments won't use DNS. But it also means we have never put any design work into the = relationship between CoAP and DNS. One thing I'm no longer sure about after this week's plugtest is that, = for those areas of application where DNS *is* appropriate, we should = just blindly continue the way HTTP uses the DNS. That has pretty much been an accident, and there never has been a chance = to retrofit something more sensible the way that MX was retrofit for = mail. We may not have to invent anything new, though, because SRV has now been = around a dozen of years. Is it time to put it to good use? Cullen has suggested in the WGLC = comments that we do that. If yes, we should specify how SRV is used with CoAP. _coap._udp? =20 (Note that this doesn't need to be part of the base spec, as the base = spec is not tied to DNS.) We most likely shouldn't go NAPTR, unlike, say, RFC 3263 does for SIP. What is the right way to use DTLS with SRV? (The related implementation issue that Klaus already brought up because = it occurs with AAAA as well: What is the best way to "try to connect" (RFC 2782) to choose one out of = multiple alternatives? "coap ping" was discovered as one way to aid this selection.) Gr=FC=DFe, Carsten From cabo@tzi.org Fri Nov 30 03:36:27 2012 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 BA74021F8659 for ; Fri, 30 Nov 2012 03:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.731 X-Spam-Level: X-Spam-Status: No, score=-105.731 tagged_above=-999 required=5 tests=[AWL=0.518, 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 eHum0b4L7aGf for ; Fri, 30 Nov 2012 03:36:27 -0800 (PST) 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 048F921F8508 for ; Fri, 30 Nov 2012 03:36:26 -0800 (PST) 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 qAUBaKSb015700 for ; Fri, 30 Nov 2012 12:36:20 +0100 (CET) Received: from [10.200.12.5] (unknown [217.13.60.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7087E70F; Fri, 30 Nov 2012 12:36:20 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Carsten Bormann In-Reply-To: Date: Fri, 30 Nov 2012 12:36:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <297446E8-BA81-4803-A63A-35211CF9D0AD@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> <3DDE1B3C-CBF4-4773-A3C2-AA61856B270C@sensinode.com> <9FCF6E24-CE7C-4E26-887A-0918369C992D@tzi.org> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1499) Subject: Re: [core] Are we ready for a consensus call? (Re: CoAP jump mechanism) 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, 30 Nov 2012 11:36:27 -0000 On Nov 30, 2012, at 10:13, Carsten Bormann wrote: > another data point And one more: code size. Jeroen Hoebeke reports about a quick experiment, where he isolated the = relevant code and compiled it for x68_64: > iot@ubuntu:~/coaptestcode$ size *.o > text data bss dec hex filename > 583 0 0 583 247 coapv12decode.o > 638 0 0 638 27e coapv12encode.o > 642 0 0 642 282 coapv13decode.o > 636 0 0 636 27c coapv13encode.o >=20 > Not sure where the difference in the decoding comes from=85 >=20 > In code lines (the actual encoding, decoding without the data = structures) > DECODING > v12 =3D 37 lines, new format =3D 43 lines > ENCODING: > v12 =3D 57 lines, new format =3D 42 lines >=20 > Overall impression: some small gain, the consistency between delta = encoding and length encoding in the options makes implementation easier=20= My own numbers (Ruby code with some copious diagnostics code, and = including empty lines where required by the coding conventions): parse_coap12 =3D 66 lines parse_klaus =3D 53 lines to_wire_coap12 =3D 67 lines to_wire_klaus =3D 55 lines I think we now have sufficient data to support the quantifiable part of = the decision. On the not so quantifiable side, it is hard to weigh "ease of = implementation" and "reduction of interoperability bugs", which both = argue for choosing the simpler design, against "running code" which, = even with the three new implementations is still in favor of the = existing one. (Why am I running this so meticulously? I'm personally way more = interested in how people actually make a decision on a design issue such = as this than in what the actual outcome is here. Does more real data = help or confuse?) Gr=FC=DFe, Carsten From jeroen.hoebeke@intec.ugent.be Fri Nov 30 05:13:51 2012 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 52A9C21F8588 for ; Fri, 30 Nov 2012 05:13:51 -0800 (PST) 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 jmSw82JhrkLv for ; Fri, 30 Nov 2012 05:13:50 -0800 (PST) Received: from smtp3.ugent.be (smtp3.ugent.be [157.193.49.127]) by ietfa.amsl.com (Postfix) with ESMTP id 4783E21F8566 for ; Fri, 30 Nov 2012 05:13:50 -0800 (PST) Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp3.ugent.be (Postfix) with ESMTP id 2F3ADC2AF; Fri, 30 Nov 2012 14:13:49 +0100 (CET) X-Virus-Scanned: by UGent DICT Received: from smtp3.ugent.be ([157.193.49.127]) by localhost (mcheck2.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id P1cKH6CdY1Qi; Fri, 30 Nov 2012 14:13:48 +0100 (CET) Received: from [172.29.8.214] (LLagny-156-36-9-136.w80-13.abo.wanadoo.fr [80.13.124.136]) (Authenticated sender: jjhoebek) by smtp3.ugent.be (Postfix) with ESMTPSA id 56E51C31E; Fri, 30 Nov 2012 14:13:21 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=windows-1252 From: Jeroen Hoebeke In-Reply-To: <297446E8-BA81-4803-A63A-35211CF9D0AD@tzi.org> Date: Fri, 30 Nov 2012 14:12:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <91DE1367-2A23-44BA-A2B4-21C2B7D8FFB6@intec.ugent.be> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> <3DDE1B3C-CBF4-4773-A3C2-AA61856B270C@sensinode.com> <9FCF6E24-CE7C-4E26-887A-0918369C992D@tzi.org> <297446E8-BA81-4803-A63A-35211CF9D0AD@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1499) X-Miltered: at jchkm1 with ID 50B8B0CE.000 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 50B8B0CE.000 from LLagny-156-36-9-136.w80-13.abo.wanadoo.fr/LLagny-156-36-9-136.w80-13.abo.wanadoo.fr/80.13.124.136/[172.29.8.214]/ X-j-chkmail-Score: MSGID : 50B8B0CE.000 on smtp3.ugent.be : j-chkmail score : X : R=. U=. O=## B=0.000 -> S=0.166 X-j-chkmail-Status: Ham Cc: "core@ietf.org WG" Subject: Re: [core] Are we ready for a consensus call? (Re: CoAP jump mechanism) 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, 30 Nov 2012 13:13:51 -0000 Hi I found some issues with the test decode/encode programs I (too) quickly = created. Using a fixed version, this is now the result: iot@ubuntu:~/coaptestcode$ size *.o text data bss dec hex filename =20 723 0 0 723 2d3 coapv12decode.o 634 0 0 634 27a coapv13decode.o 787 0 0 787 313 coapv12encode.o 758 0 0 758 2f6 coapv13encode.o In both cases a reduction in code size. =20 Kind regards, jeroen On 30 Nov 2012, at 12:36, Carsten Bormann wrote: > Jeroen Hoebeke reports about a quick experiment, where he isolated the = relevant code and compiled it for x68_64: >=20 >> iot@ubuntu:~/coaptestcode$ size *.o >> text data bss dec hex filename >> 583 0 0 583 247 coapv12decode.o >> 638 0 0 638 27e coapv12encode.o >> 642 0 0 642 282 coapv13decode.o >> 636 0 0 636 27c coapv13encode.o >>=20 >> Not sure where the difference in the decoding comes from=85 From hartke@tzi.org Fri Nov 30 05:48:31 2012 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 C73C221F85B4 for ; Fri, 30 Nov 2012 05:48:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.627 X-Spam-Level: X-Spam-Status: No, score=-0.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_SUMOF=5, HELO_EQ_DE=0.35, 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 s2o7BKtHdv4q for ; Fri, 30 Nov 2012 05:48:31 -0800 (PST) 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 9797C21F859E for ; Fri, 30 Nov 2012 05:48:30 -0800 (PST) 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 qAUDmNsE022124 for ; Fri, 30 Nov 2012 14:48:23 +0100 (CET) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E5095835 for ; Fri, 30 Nov 2012 14:48:22 +0100 (CET) Received: by mail-pb0-f44.google.com with SMTP id uo1so431361pbc.31 for ; Fri, 30 Nov 2012 05:48:20 -0800 (PST) Received: by 10.68.225.70 with SMTP id ri6mr5852559pbc.41.1354283300901; Fri, 30 Nov 2012 05:48:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.75.75 with HTTP; Fri, 30 Nov 2012 05:48:00 -0800 (PST) In-Reply-To: <6AF38EAF-DB60-4D6F-AE99-5226034917DB@intec.ugent.be> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> <3DDE1B3C-CBF4-4773-A3C2-AA61856B270C@sensinode.com> <9FCF6E24-CE7C-4E26-887A-0918369C992D@tzi.org> <6AF38EAF-DB60-4D6F-AE99-5226034917DB@intec.ugent.be> From: Klaus Hartke Date: Fri, 30 Nov 2012 14:48:00 +0100 Message-ID: To: "core@ietf.org WG" Content-Type: multipart/mixed; boundary=e89a8ff2556413537004cfb6a7e4 Subject: Re: [core] CoAP jump mechanism 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, 30 Nov 2012 13:48:31 -0000 --e89a8ff2556413537004cfb6a7e4 Content-Type: text/plain; charset=ISO-8859-1 I've created an updated version with the following technical changes and a few editorial changes: * Use a 4-bit field for the token length and reserve lengths 9-15. * The payload marker must not be used if there is no payload (0 bytes). Best regards, Klaus --e89a8ff2556413537004cfb6a7e4 Content-Type: text/plain; charset=US-ASCII; name="new-format-04.txt" Content-Disposition: attachment; filename="new-format-04.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ha5d7iqh0 SW50ZXJuZXQtRHJhZnQgICAgICAgICAgIE5ldyBDb0FQIE1lc3NhZ2UgRm9ybWF0ICAgICAgICAg ICBOb3ZlbWJlciAyMDEyCgoKMy4gIE1lc3NhZ2UgRm9ybWF0CgogICBDb0FQIG1lc3NhZ2VzIGFy ZSBlbmNvZGVkIGluIGEgc2ltcGxlIGJpbmFyeSBmb3JtYXQuICBFYWNoIG1lc3NhZ2UKICAgb2Nj dXBpZXMgdGhlIGRhdGEgc2VjdGlvbiBvZiBvbmUgVURQIGRhdGFncmFtLiAgVGhlIG1lc3NhZ2Ug Zm9ybWF0CiAgIHN0YXJ0cyB3aXRoIGEgaGVhZGVyIHdoaWNoIGlzIHZhcmlhYmxlIGluIGxlbmd0 aCBhbmQgY2FuIGJlIGJldHdlZW4gNAogICB0byAxMSBieXRlcyBsb25nLiAgRm9sbG93aW5nIHRo ZSBoZWFkZXIgY29tZXMgYSBzZXF1ZW5jZSBvZiB6ZXJvIG9yCiAgIG1vcmUgQ29BUCBPcHRpb25z IGluIFR5cGUtTGVuZ3RoLVZhbHVlIChUTFYpIGZvcm1hdCBhbmQgYW4gb3B0aW9uYWwKICAgcGF5 bG9hZCB3aGljaCB0YWtlcyB1cCB0aGUgcmVzdCBvZiB0aGUgZGF0YWdyYW0uCgogICBDb0FQIG1h eSBhbHNvIGJlIHVzZWQgb3ZlciBEYXRhZ3JhbSBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkgKERU TFMpOwogICBzZWUgU2VjdGlvbiA5LiAgSXQgY291bGQgYWxzbyBiZSB1c2VkIG92ZXIgb3RoZXIg dHJhbnNwb3J0cywgdGhlCiAgIHNwZWNpZmljYXRpb24gb2Ygd2hpY2ggaXMgb3V0IG9mIHRoaXMg ZG9jdW1lbnQncyBzY29wZS4KCjMuMS4gIEhlYWRlciBGb3JtYXQKCiAgIFRoZSBmb3JtYXQgb2Yg dGhlIGhlYWRlciBpcyBhcyBmb2xsb3dzOgoKICAgICAgICAgICAgICAgICAgICAgMCAgIDEgICAy ICAgMyAgIDQgICA1ICAgNiAgIDcKICAgICAgICAgICAgICAgICAgICstLS0tLS0tKy0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tKwogICAgICAgICAgICAgICAgICAgfCAgICAgICB8ICAgICAgIHwgICAg ICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICB8VmVyc2lvbnwgIFR5cGUgfCBUb2tlbiBM ZW5ndGggIHwgICAxIGJ5dGUKICAgICAgICAgICAgICAgICAgIHwgICAgICAgfCAgICAgICB8ICAg ICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgKy0tLS0tLS0rLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwKICAgICAgICAgICAgICAgICAgIHwgICAgIFJlcXVlc3QvUmVzcG9uc2UgQ29kZSAgICAg fCAgIDEgYnl0ZQogICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8CiAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSsKICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAog ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAg ICAgICAgICAgICstLS0gICAgICAgTWVzc2FnZSBJRCAgICAgICAgLS0tKyAgIDIgYnl0ZXMKICAg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAg ICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICAgICAgICAgICAgICAgICAg XCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgICAgICAgICAgICAvICAg ICAgICAgICAgIFRva2VuICAgICAgICAgICAgIC8gICAwLTggYnl0ZXMKICAgICAgICAgICAgICAg ICAgIFwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICAgICAgICAgICAg Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCgogICAgICAgICAgICAgICAgICAgICAg ICAgIEZpZ3VyZSAxOiBIZWFkZXIgRm9ybWF0CgogICBUaGUgZmllbGRzIGluIHRoZSBoZWFkZXIg YXJlIGRlZmluZWQgYXMgZm9sbG93czoKCiAgIFZlcnNpb246ICAyLWJpdCB1bnNpZ25lZCBpbnRl Z2VyLiAgSW5kaWNhdGVzIHRoZSBDb0FQIHZlcnNpb24gbnVtYmVyLgogICAgICAgICAgICAgSW1w bGVtZW50YXRpb25zIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBNVVNUIHNldCB0aGlzIGZpZWxkCiAg ICAgICAgICAgICB0byAxLiAgT3RoZXIgdmFsdWVzIGFyZSByZXNlcnZlZCBmb3IgZnV0dXJlIHZl cnNpb25zLgoKCgoKSGFydGtlICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bmUgMywgMjAx MyAgICAgICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIE5l dyBDb0FQIE1lc3NhZ2UgRm9ybWF0ICAgICAgICAgICBOb3ZlbWJlciAyMDEyCgoKICAgVHlwZTog ICAgIDItYml0IHVuc2lnbmVkIGludGVnZXIuICBJbmRpY2F0ZXMgaWYgdGhpcyBtZXNzYWdlIGlz IG9mCiAgICAgICAgICAgICB0eXBlIENvbmZpcm1hYmxlICgwKSwgTm9uLUNvbmZpcm1hYmxlICgx KSwgQWNrbm93bGVkZ2VtZW50CiAgICAgICAgICAgICAoMikgb3IgUmVzZXQgKDMpLiAgVGhlIHNl bWFudGljcyBvZiB0aGVzZSBtZXNzYWdlIHR5cGVzIGFyZQogICAgICAgICAgICAgZGVmaW5lZCBp biBTZWN0aW9uIDQuCgogICBUb2tlbiBMZW5ndGg6ICAzLWJpdCB1bnNpZ25lZCBpbnRlZ2VyLiAg SW5kaWNhdGVzIHRoZSBsZW5ndGggb2YgdGhlCiAgICAgICAgICAgICB2YXJpYWJsZS1sZW5ndGgg VG9rZW4gZmllbGQgKDAtOCBieXRlcykuICBMZW5ndGhzIDktMTUgYXJlCiAgICAgICAgICAgICBy ZXNlcnZlZCBhbmQgTVVTVCBiZSBwcm9jZXNzZWQgYXMgYSBtZXNzYWdlIGZvcm1hdCBlcnJvci4K CiAgIENvZGU6ICAgICA4LWJpdCB1bnNpZ25lZCBpbnRlZ2VyLiAgSW5kaWNhdGVzIGlmIHRoZSBt ZXNzYWdlIGNhcnJpZXMgYQogICAgICAgICAgICAgcmVxdWVzdCAoMS0zMSkgb3IgYSByZXNwb25z ZSAoNjQtMTkxKSwgb3IgaXMgZW1wdHkgKDApLgogICAgICAgICAgICAgQWxsIG90aGVyIHZhbHVl cyBhcmUgcmVzZXJ2ZWQuICBJbiBjYXNlIG9mIGEgcmVxdWVzdCwgdGhlCiAgICAgICAgICAgICBD b2RlIGZpZWxkIGluZGljYXRlcyB0aGUgUmVxdWVzdCBNZXRob2Q7IGluIGNhc2Ugb2YgYQogICAg ICAgICAgICAgcmVzcG9uc2UgYSBSZXNwb25zZSBDb2RlLiAgUG9zc2libGUgdmFsdWVzIGFyZSBt YWludGFpbmVkCiAgICAgICAgICAgICBpbiB0aGUgQ29BUCBDb2RlIFJlZ2lzdHJ5IChTZWN0aW9u IDEyLjEpLiAgVGhlIHNlbWFudGljcyBvZgogICAgICAgICAgICAgcmVxdWVzdHMgYW5kIHJlc3Bv bnNlcyBhcmUgZGVmaW5lZCBpbiBTZWN0aW9uIDUuCgogICBNZXNzYWdlIElEOiAgMTYtYml0IHVu c2lnbmVkIGludGVnZXIuICBVc2VkIGZvciB0aGUgZGV0ZWN0aW9uIG9mCiAgICAgICAgICAgICBt ZXNzYWdlIGR1cGxpY2F0aW9uLCBhbmQgdG8gbWF0Y2ggbWVzc2FnZXMgb2YgdHlwZQogICAgICAg ICAgICAgQWNrbm93bGVkZ2VtZW50L1Jlc2V0IHRvIG1lc3NhZ2VzIG9mIHR5cGUgQ29uZmlybWFi bGUvCiAgICAgICAgICAgICBOb24tQ29uZmlybWFibGUuICBUaGUgcnVsZXMgZm9yIGdlbmVyYXRp bmcgYSBNZXNzYWdlIElEIGFuZAogICAgICAgICAgICAgbWF0Y2hpbmcgbWVzc2FnZXMgYXJlIGRl ZmluZWQgaW4gU2VjdGlvbiA0LgoKICAgVG9rZW46ICAgIFVzZWQgdG8gY29ycmVsYXRlIHJlcXVl c3RzIGFuZCByZXNwb25zZXMuICBUaGUgcnVsZXMgZm9yCiAgICAgICAgICAgICBnZW5lcmF0aW5n IGEgVG9rZW4gYW5kIGNvcnJlbGF0aW5nIHJlcXVlc3RzIGFuZCByZXNwb25zZXMKICAgICAgICAg ICAgIGFyZSBkZWZpbmVkIGluIFNlY3Rpb24gNS4KCjMuMi4gIE9wdGlvbiBGb3JtYXQKCiAgIENv QVAgZGVmaW5lcyBhIG51bWJlciBvZiBvcHRpb25zIHdoaWNoIGNhbiBiZSBpbmNsdWRlZCBpbiBh IG1lc3NhZ2UuCiAgIEVhY2ggb3B0aW9uIGluc3RhbmNlIGluIGEgbWVzc2FnZSBzcGVjaWZpZXMg dGhlIE9wdGlvbiBOdW1iZXIgb2YgdGhlCiAgIGRlZmluZWQgQ29BUCBvcHRpb24sIHRoZSBsZW5n dGggb2YgdGhlIE9wdGlvbiBWYWx1ZSBhbmQgdGhlIE9wdGlvbgogICBWYWx1ZSBpdHNlbGYuCgog ICBJbnN0ZWFkIG9mIHNwZWNpZnlpbmcgdGhlIE9wdGlvbiBOdW1iZXIgZGlyZWN0bHksIHRoZSBp bnN0YW5jZXMgTVVTVAogICBhcHBlYXIgaW4gb3JkZXIgb2YgdGhlaXIgT3B0aW9uIE51bWJlcnMg YW5kIGEgZGVsdGEgZW5jb2RpbmcgaXMgdXNlZAogICBiZXR3ZWVuIHRoZW06IFRoZSBPcHRpb24g TnVtYmVyIGZvciBlYWNoIGluc3RhbmNlIGlzIGNhbGN1bGF0ZWQgYXMKICAgdGhlIHN1bSBvZiBp dHMgZGVsdGEgYW5kIHRoZSBPcHRpb24gTnVtYmVyIG9mIHRoZSBwcmVjZWRpbmcgaW5zdGFuY2UK ICAgaW4gdGhlIG1lc3NhZ2UuICBGb3IgdGhlIGZpcnN0IGluc3RhbmNlIGluIGEgbWVzc2FnZSwg YSBwcmVjZWRpbmcKICAgb3B0aW9uIGluc3RhbmNlIHdpdGggT3B0aW9uIE51bWJlciB6ZXJvIGlz IGFzc3VtZWQuICBNdWx0aXBsZQogICBpbnN0YW5jZXMgb2YgdGhlIHNhbWUgb3B0aW9uIGNhbiBi ZSBpbmNsdWRlZCBieSB1c2luZyBhIGRlbHRhIG9mCiAgIHplcm8uCgogICBPcHRpb24gTnVtYmVy cyBhcmUgbWFpbnRhaW5lZCBpbiB0aGUgQ29BUCBPcHRpb24gTnVtYmVyIFJlZ2lzdHJ5CiAgIChT ZWN0aW9uIDEyLjIpLiAgU2VlIFNlY3Rpb24gNS4xMCBmb3IgdGhlIHNlbWFudGljcyBvZiB0aGUg b3B0aW9ucwogICBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQuCgoKCgoKSGFydGtlICAgICAgICAg ICAgICAgICAgICBFeHBpcmVzIEp1bmUgMywgMjAxMyAgICAgICAgICAgICAgICAgIFtQYWdlIDJd CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIE5ldyBDb0FQIE1lc3NhZ2UgRm9ybWF0ICAgICAg ICAgICBOb3ZlbWJlciAyMDEyCgoKICAgICAgICAgICAgICAgICAgICAgMCAgIDEgICAyICAgMyAg IDQgICA1ICAgNiAgIDcKICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tKwogICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICB8CiAgICAgICAgICAgICAgICAgICB8ICBPcHRpb24gRGVsdGEgfCBPcHRpb24gTGVuZ3Ro IHwgICAxIGJ5dGUKICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgfAogICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0rCiAgICAgICAgICAgICAgICAgICBcICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwK ICAgICAgICAgICAgICAgICAgIC8gICAgICAgICBPcHRpb24gRGVsdGEgICAgICAgICAgLyAgIDAt MiBieXRlcwogICAgICAgICAgICAgICAgICAgXCAgICAgICAgICAoZXh0ZW5kZWQpICAgICAgICAg ICBcCiAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsK ICAgICAgICAgICAgICAgICAgIFwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAg ICAgICAgICAgICAgICAgLyAgICAgICAgIE9wdGlvbiBMZW5ndGggICAgICAgICAvICAgMC0yIGJ5 dGVzCiAgICAgICAgICAgICAgICAgICBcICAgICAgICAgIChleHRlbmRlZCkgICAgICAgICAgIFwK ICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICAg ICAgICAgICAgICAgICAgXCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAg ICAgICAgICAgICAvICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8KICAgICAgICAgICAg ICAgICAgIFwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICAgICAgICAg ICAgLyAgICAgICAgIE9wdGlvbiBWYWx1ZSAgICAgICAgICAvICAgMCBvciBtb3JlIGJ5dGVzCiAg ICAgICAgICAgICAgICAgICBcICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAg ICAgICAgICAgICAgIC8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLwogICAgICAgICAg ICAgICAgICAgXCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgICAgICAg ICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKCiAgICAgICAgICAgICAgICAg ICAgICAgICAgRmlndXJlIDI6IE9wdGlvbiBGb3JtYXQKCiAgIFRoZSBmaWVsZHMgaW4gYW4gb3B0 aW9uIGFyZSBkZWZpbmVkIGFzIGZvbGxvd3M6CgogICBEZWx0YTogICAgNC1iaXQgdW5zaWduZWQg aW50ZWdlci4gIEluZGljYXRlcyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuCiAgICAgICAgICAgICB0 aGUgT3B0aW9uIE51bWJlciBvZiB0aGlzIG9wdGlvbiBhbmQgdGhlIHByZXZpb3VzIG9wdGlvbgog ICAgICAgICAgICAgKG9yIHplcm8gZm9yIHRoZSBmaXJzdCBvcHRpb24pLiAgSW4gb3RoZXIgd29y ZHMsIHRoZSBPcHRpb24KICAgICAgICAgICAgIE51bWJlciBpcyBjYWxjdWxhdGVkIGJ5IHNpbXBs eSBzdW1taW5nIHRoZSBPcHRpb24gRGVsdGEKICAgICAgICAgICAgIGZpZWxkcyBvZiB0aGlzIGFu ZCBhbGwgcHJldmlvdXMgb3B0aW9ucyBiZWZvcmUgaXQuICBUaHJlZQogICAgICAgICAgICAgdmFs dWVzIGFyZSByZXNlcnZlZCBmb3Igc3BlY2lhbCBjb25zdHJ1Y3RzOgoKICAgICAgICAgICAgIDEz OiAgQW4gOC1iaXQgdW5zaWduZWQgaW50ZWdlciBmb2xsb3dzIHRoZSBpbml0aWFsIGJ5dGUgYW5k CiAgICAgICAgICAgICAgICAgIGluZGljYXRlcyB0aGUgT3B0aW9uIERlbHRhIG1pbnVzIDEzLgoK ICAgICAgICAgICAgIDE0OiAgQSAxNi1iaXQgdW5zaWduZWQgaW50ZWdlciBmb2xsb3dzIHRoZSBp bml0aWFsIGJ5dGUgYW5kCiAgICAgICAgICAgICAgICAgIGluZGljYXRlcyB0aGUgT3B0aW9uIERl bHRhIG1pbnVzIDI2OS4KCiAgICAgICAgICAgICAxNTogIFJlc2VydmVkIGZvciB0aGUgUGF5bG9h ZCBNYXJrZXI7IHNlZSBTZWN0aW9uIDMuNAogICAgICAgICAgICAgICAgICBiZWxvdy4KCiAgIExl bmd0aDogICA0LWJpdCB1bnNpZ25lZCBpbnRlZ2VyLiAgSW5kaWNhdGVzIHRoZSBsZW5ndGggb2Yg dGhlIE9wdGlvbgogICAgICAgICAgICAgVmFsdWUsIGluIGJ5dGVzLiAgVGhyZWUgdmFsdWVzIGFy ZSByZXNlcnZlZCBmb3Igc3BlY2lhbAogICAgICAgICAgICAgY29uc3RydWN0czoKCgoKCgpIYXJ0 a2UgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVuZSAzLCAyMDEzICAgICAgICAgICAgICAg ICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgTmV3IENvQVAgTWVzc2FnZSBG b3JtYXQgICAgICAgICAgIE5vdmVtYmVyIDIwMTIKCgogICAgICAgICAgICAgMTM6ICBBbiA4LWJp dCB1bnNpZ25lZCBpbnRlZ2VyIHByZWNlZGVzIHRoZSBPcHRpb24gVmFsdWUKICAgICAgICAgICAg ICAgICAgYW5kIGluZGljYXRlcyB0aGUgT3B0aW9uIExlbmd0aCBtaW51cyAxMy4KCiAgICAgICAg ICAgICAxNDogIEEgMTYtYml0IHVuc2lnbmVkIGludGVnZXIgcHJlY2VkZXMgdGhlIE9wdGlvbiBW YWx1ZQogICAgICAgICAgICAgICAgICBhbmQgaW5kaWNhdGVzIHRoZSBPcHRpb24gTGVuZ3RoIG1p bnVzIDI2OS4KCiAgICAgICAgICAgICAxNTogIFJlc2VydmVkIGZvciBmdXR1cmUgdXNlLiAgSWYg dGhlIGZpZWxkIGlzIHNldCB0byB0aGlzCiAgICAgICAgICAgICAgICAgIHZhbHVlLCBpdCBNVVNU IGJlIHByb2Nlc3NlZCBhcyBhIG1lc3NhZ2UgZm9ybWF0IGVycm9yLgoKICAgVmFsdWU6ICAgIFRo ZSBsZW5ndGggYW5kIGZvcm1hdCBvZiB0aGUgT3B0aW9uIFZhbHVlIGRlcGVuZHMgb24gdGhlCiAg ICAgICAgICAgICByZXNwZWN0aXZlIG9wdGlvbiwgd2hpY2ggTUFZIGRlZmluZSB2YXJpYWJsZSBs ZW5ndGggdmFsdWVzLgogICAgICAgICAgICAgU2VlIFNlY3Rpb24gMy4zIGZvciB0aGUgZm9ybWF0 cyB1c2VkIGluIHRoaXMgZG9jdW1lbnQ7CiAgICAgICAgICAgICBvcHRpb25zIGRlZmluZWQgaW4g b3RoZXIgZG9jdW1lbnRzIE1BWSBtYWtlIHVzZSBvZiBvdGhlcgogICAgICAgICAgICAgb3B0aW9u IHZhbHVlIGZvcm1hdHMuCgozLjMuICBPcHRpb24gVmFsdWUgRm9ybWF0cwoKICAgVGhlIG9wdGlv bnMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IG1ha2UgdXNlIG9mIHRoZSBmb2xsb3dpbmcgb3B0 aW9uCiAgIHZhbHVlIGZvcm1hdHMuIC4uLgoKMy40LiAgUGF5bG9hZCBGb3JtYXQKCiAgIEZvbGxv d2luZyB0aGUgaGVhZGVyIGFuZCBvcHRpb25zIGNvbWVzIHRoZSBvcHRpb25hbCBwYXlsb2FkLiAg SWYKICAgcHJlc2VudCwgaXQgaXMgcHJlZml4ZWQgYnkgYSBmaXhlZCwgb25lLWJ5dGUgUGF5bG9h ZCBNYXJrZXIgKDB4RkYpCiAgIHdoaWNoIGluZGljYXRlcyB0aGUgZW5kIG9mIG9wdGlvbnMgYW5k IHRoZSBzdGFydCBvZiB0aGUgcGF5bG9hZC4gIFRoZQogICBwYXlsb2FkIGRhdGEgZXh0ZW5kcyBm cm9tIGFmdGVyIHRoZSBtYXJrZXIgdG8gdGhlIGVuZCBvZiB0aGUgVURQCiAgIGRhdGFncmFtLCBp LmUuLCB0aGUgUGF5bG9hZCBMZW5ndGggaXMgY2FsY3VsYXRlZCBmcm9tIHRoZSBkYXRhZ3JhbQog ICBzaXplLiAgVGhlIGFic2VuY2UgdGhlIFBheWxvYWQgTWFya2VyIGRlbm90ZXMgYSB6ZXJvLWxl bmd0aCBwYXlsb2FkLgogICBBIG1hcmtlciBmb2xsb3dlZCBieSBhIHplcm8tbGVuZ3RoIHBheWxv YWQgTVVTVCBiZSBwcm9jZXNzZWQgYXMgYQogICBtZXNzYWdlIGZvcm1hdCBlcnJvci4KCiAgICAg ICAgICAgICAgICAgICAgIDAgICAxICAgMiAgIDMgICA0ICAgNSAgIDYgICA3CiAgICAgICAgICAg ICAgICAgICArLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSsKICAgICAgICAgICAgICAg ICAgIHwgICB8ICAgfCAgIHwgICB8ICAgfCAgIHwgICB8ICAgfAogICAgICAgICAgICAgICAgICAg fCAxIHwgMSB8IDEgfCAxIHwgMSB8IDEgfCAxIHwgMSB8ICAgMSBieXRlCiAgICAgICAgICAgICAg ICAgICB8ICAgfCAgIHwgICB8ICAgfCAgIHwgICB8ICAgfCAgIHwKICAgICAgICAgICAgICAgICAg ICstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKwogICAgICAgICAgICAgICAgICAgXCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgICAgICAgICAgICAvICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIC8KICAgICAgICAgICAgICAgICAgIFwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICAgICAgICAgICAgLyAgICAgICAgICAgIFBh eWxvYWQgICAgICAgICAgICAvICAgMSBvciBtb3JlIGJ5dGVzCiAgICAgICAgICAgICAgICAgICBc ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAgICAgICAgICAgICAgIC8gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgLwogICAgICAgICAgICAgICAgICAgXCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSsKCiAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMzog UGF5bG9hZCBGb3JtYXQKCgoKCkhhcnRrZSAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBKdW5l IDMsIDIwMTMgICAgICAgICAgICAgICAgICBbUGFnZSA0XQo= --e89a8ff2556413537004cfb6a7e4-- From cabo@tzi.org Fri Nov 30 06:10:16 2012 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 0CE3921F8A66 for ; Fri, 30 Nov 2012 06:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.805 X-Spam-Level: X-Spam-Status: No, score=-105.805 tagged_above=-999 required=5 tests=[AWL=0.444, 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 lyEP4qJDV9iF for ; Fri, 30 Nov 2012 06:10:15 -0800 (PST) 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 2D81D21F8A29 for ; Fri, 30 Nov 2012 06:10:15 -0800 (PST) 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 qAUEA5j8004433 for ; Fri, 30 Nov 2012 15:10:05 +0100 (CET) Received: from [10.200.12.5] (unknown [217.13.60.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3BFF287B; Fri, 30 Nov 2012 15:10:05 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Carsten Bormann In-Reply-To: Date: Fri, 30 Nov 2012 15:09:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <51803EE3-A997-4DA4-A918-83B0B5B82996@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> <3DDE1B3C-CBF4-4773-A3C2-AA61856B270C@sensinode.com> <9FCF6E24-CE7C-4E26-887A-0918369C992D@tzi.org> <6AF38EAF-DB60-4D6F-AE99-5226034917DB@intec.ugent.be> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1499) Subject: [core] Call for consensus: Should we switch out the option encoding? 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, 30 Nov 2012 14:10:16 -0000 On Nov 30, 2012, at 14:48, Klaus Hartke wrote: > Thanks, Klaus. =20 This version doesn't contain all the editorial fixes that were discussed = on the list, but these can be done in parallel to making the decision. Normally, we do minor technical decisions by having a discussion and = then simply putting in the new text into the next revision of a WG = draft. However, this is another breaking change, and although the IETF process = does allow us to make breaking changes as much as we want, reality = doesn't -- we should only make them if the benefits really justify the = cost of changing out all tools (including the WireShark that you = probably already have installed even if you don't know it), temporarily = partitioning the interop testing world into the laggards and the = radicals, making previous pcap files less useful for future tests etc. Other messages have discussed the quantifiable and not so quantifiable = advantages (and disadvantages) of the new proposal. I think I can already state consensus that the new proposal is simpler, = which fits the goals of the WG well. So my question to the WG is now: Do we as a WG have consensus to make = this change at this time? Whether you answer yes or no, it would be useful to add a line or so of = text indicating what motivates your decision. In order not to lose time, please send in your replies (with this = subject) to this mailing list by -> 2012-12-05, 23:59 UTC. This will enable us to announce a decision (and, I hope, get coap-13 = published) right on Sinterklaas. Gr=FC=DFe, Carsten From kerlyn2001@gmail.com Fri Nov 30 07:01:32 2012 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 53F3E21F8598 for ; Fri, 30 Nov 2012 07:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=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 AjcSEyfjUDZ1 for ; Fri, 30 Nov 2012 07:01:31 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id F296621F8590 for ; Fri, 30 Nov 2012 07:01:30 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so601941lbk.31 for ; Fri, 30 Nov 2012 07:01:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=fYicb45PSdXsqvcFl1jSH//RFyTbp386BjPkOWfn3mM=; b=Tt6I8fKOTq37MEiKUs/I6d1qpLFL/nQ6XF+JyGlrQM7lE7NHXyx17/xj+uNGVhazGV tKuGIxT+fWKVzQeAPPWbB+HSIWAREsnf0b4ioY8uJD4acgNIwuVe/Tr/pQH9CR30zhaJ 5mLnLLAMJK2gCMUpxCGnxrqPa2BatENLCu5d6HmgxvKOSbp8tv4YA9hJSuhSzhV75bKh RKkYWJhBOv+N+zmReF/VRAvYY/8RgCFomxbHODcRMI4aSs3jLHNnEgjdbjym6AyA8A3k nFgz2VTq1nt0eslbr1EOjXEnacwQ1vXuiPKn4nwv89Ht/vzMFZyOprcKRnXD7pm/zGnA KaKg== MIME-Version: 1.0 Received: by 10.152.104.240 with SMTP id gh16mr1497649lab.56.1354287689677; Fri, 30 Nov 2012 07:01:29 -0800 (PST) Received: by 10.112.104.38 with HTTP; Fri, 30 Nov 2012 07:01:29 -0800 (PST) In-Reply-To: <5E28C76D-5E80-4EA0-9A9F-A8A930552099@tzi.org> References: <5E28C76D-5E80-4EA0-9A9F-A8A930552099@tzi.org> Date: Fri, 30 Nov 2012 10:01:29 -0500 Message-ID: From: Kerry Lynn To: Carsten Bormann , core Content-Type: multipart/alternative; boundary=f46d04088e11aab99004cfb7acd1 Subject: Re: [core] Should DNS usage of CoAP implementations favor SRV? 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, 30 Nov 2012 15:01:32 -0000 --f46d04088e11aab99004cfb7acd1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Nov 30, 2012 at 5:02 AM, Carsten Bormann wrote: > CoAP is deliberately not tying itself to DNS in any major way. > That is a good thing, as many CoAP deployments won't use DNS. > But it also means we have never put any design work into the relationship > between CoAP and DNS. > > Peter, Anders, and I put out several CoRE drafts detailing how DNS could be used to advantage in networks of CoAP nodes. These have all expired but fo= r http://tools.ietf.org/html/draft-lynn-core-discovery-mapping-02.txt as it became clear to us that there was not much support for these ideas within the group. I am keeping the discovery-mapping I-D active because of its possible applicability in mixed populations of SEP 2.0 devices where XML, HTTP, and DNS are the baseline and it's expected that CoAP may find applicability. In that environment, we have extended DNS-SD/mDNS to discover REST function sets within a set of servers and the discovery-mapping I-D describes how to achieve semantic equivalence in the search down to that level of granularity using either DNS-SD/ mDNS or Core resource discovery. I hope to find a home for the SEP 2.0 DNS-SD/mDNS extensions discussion in the MDNSEXT WG when it is chartered. One thing I'm no longer sure about after this week's plugtest is that, for > those areas of application where DNS *is* appropriate, we should just > blindly continue the way HTTP uses the DNS. > That has pretty much been an accident, and there never has been a chance > to retrofit something more sensible the way that MX was retrofit for mail= . > We may not have to invent anything new, though, because SRV has now been > around a dozen of years. > Is it time to put it to good use? Cullen has suggested in the WGLC > comments that we do that. > > Cullen proposed an excellent scheme (literally) in http://tools.ietf.org/html/draft-jennings-http-srv in which he suggested http+srv could be used to advantage to bind a dynamic socket as well as an IP addres= s to an HTTP server location. Peter, Anders, and I developed this concept for CoAP in http://tools.ietf.org/html/draft-vanderstok-core-dna where, in particular, it will be necessary to dynamically assign ports in the IPHC compressible range and then discover this binding post-facto. Before this, Angelo & Co. described how coap+srv could be used in HTTP-to- CoAP mapping across a proxy where, one on side, the "host" production names a host record and on the other an SRV RR (which binds host & port). If yes, we should specify how SRV is used with CoAP. _coap._udp? > This is the conventional way that DNS-SD/mDNS names SRV/TXT records. I believe we'd also want to deploy PTR and TXT records in addition to SRV RRs to allow for wildcard and resource discovery, respectively. In practice, searching for PTR RRs named _coap._udp is too general; you'd want to constrain the search by using subtypes, e.g. light._sub._coap._udp. The discovery-mapping draft is a good starting point but it needs work. I hope it can at least stimulate some discussion on this topic. Regards, -K- (Note that this doesn't need to be part of the base spec, as the base spec > is not tied to DNS.) > We most likely shouldn't go NAPTR, unlike, say, RFC 3263 does for SIP. > What is the right way to use DTLS with SRV? > (The related implementation issue that Klaus already brought up because it > occurs with AAAA as well: > What is the best way to "try to connect" (RFC 2782) to choose one out of > multiple alternatives? > "coap ping" was discovered as one way to aid this selection.) > > Gr=FC=DFe, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --f46d04088e11aab99004cfb7acd1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Nov 30, 2012 at 5:02 AM, Carsten Bormann <cabo@tzi.org> w= rote:
CoAP is deliberately not tying itself to DNS in any major way.
That is a good thing, as many CoAP deployments won't use DNS.
But it also means we have never put any design work into the relationship b= etween CoAP and DNS.

<kel>
Peter, Anders, and I put o= ut several CoRE drafts detailing how DNS could be
used to advantage in n= etworks of CoAP nodes.=A0 These have all expired but for
http://too= ls.ietf.org/html/draft-lynn-core-discovery-mapping-02.txt as it became<= br> clear to us that there was not much support for these ideas within the grou= p.

I am keeping the discovery-mapping I-D active because of its poss= ible applicability
in mixed populations of SEP 2.0 devices where XML, HT= TP, and DNS are the
baseline and it's expected that CoAP may find applicability.=A0 In that= environment,
we have extended DNS-SD/mDNS to discover REST function set= s within a set
of servers and the discovery-mapping I-D describes how to= achieve semantic
equivalence in the search down to that level of granularity using either DN= S-SD/
mDNS or Core resource discovery.

I hope to find a home for = the SEP 2.0 DNS-SD/mDNS extensions discussion in
the MDNSEXT WG when it = is chartered.
</kel>

One thing I'm no longer sure about after this week's plugtest is th= at, for those areas of application where DNS *is* appropriate, we should ju= st blindly continue the way HTTP uses the DNS.
That has pretty much been an accident, and there never has been a chance to= retrofit something more sensible the way that MX was retrofit for mail. We may not have to invent anything new, though, because SRV has now been ar= ound a dozen of years.
Is it time to put it to good use? =A0Cullen has suggested in the WGLC comme= nts that we do that.

<kel>
Cullen proposed an excelle= nt scheme (literally) in
http://tools.ietf.org/html/draft-jennings-http-srv in w= hich he suggested http+srv
could be used to advantage to bind a dynamic socket as well as an IP addres= s
to an HTTP server location.

Peter, Anders, and I developed this= concept for CoAP in
http://tools.ietf.org/html/draft-vanderstok-core-dna wher= e, in particular, it will be
necessary to dynamically assign ports in the IPHC compressible range and th= en
discover this binding post-facto.

Before this, Angelo & Co= . described how coap+srv could be used in HTTP-to-
CoAP mapping across a= proxy where, one on side, the "host" production names
a host record and on the other an SRV RR (which binds host & port).
= </kel>

If yes, we should specify how SRV is used with CoAP. =A0_coap._udp?

<kel>
This is the conventional way that DNS-SD/m= DNS names SRV/TXT records.=A0 I
believe we'd also want to deploy PTR= and TXT records in addition to SRV RRs
to allow for wildcard and resource discovery, respectively.=A0 In practice,= searching
for PTR RRs named _coap._udp is too general; you'd want t= o constrain the search
by using subtypes, e.g. light._sub._coap._udp.
The discovery-mapping draft is a good starting point but it needs work.= =A0 I hope
it can at least stimulate some discussion on this topic.
<= br>Regards, -K-
</kel>

(Note that this doesn't need to be part of the base spec, as the base s= pec is not tied to DNS.)
We most likely shouldn't go NAPTR, unlike, say, RFC 3263 does for SIP.<= br> What is the right way to use DTLS with SRV?
=A0
(The related implementation issue that Klaus already brought up because it = occurs with AAAA as well:
What is the best way to "try to connect" (RFC 2782) to choose one= out of multiple alternatives?
"coap ping" was discovered as one way to aid this selection.)

Gr=FC=DFe, Carsten

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

--f46d04088e11aab99004cfb7acd1-- From tho@koanlogic.com Fri Nov 30 08:54:11 2012 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 7697B21F8B5A for ; Fri, 30 Nov 2012 08:54:11 -0800 (PST) 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 jyZN4B6xQ9DP for ; Fri, 30 Nov 2012 08:54:11 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A925221F8B56 for ; Fri, 30 Nov 2012 08:54:10 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so703704lbk.31 for ; Fri, 30 Nov 2012 08:54:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=QO4O8xp6urUwKuW3hJhcW2O+zyNVLXZLpo4ozgslx04=; b=jrV1y1kYraiRY47e8IqAktLE8QEWw87TivPSOW0oq9ghb9iDgxrVTKn3F7+4USTOA8 Av3yBi1yEtdy11+WapBouKXXDNSOVYVoXrW6Izri/dJMBa8xPbZSVPxKV8y/GKqyVQRC LHt/aRGQjanJr11jBrSPFskbqtAVjF7Bra1Eu4mnxA7Z5wsz7XSuJZFGNGx4aGfEx2fY xZUNOGvPjnDvxVRqidAGe1QmX6QcZb4+zl/hW4SjNLfKHLUCLYJAmZOq9Y6t6CB/nH8u KV9/Q1kKK8xdWGU4vxTyopAeVlBq4laW2hGrrrCgwb/9HdzTyK3RCZs3qksLDYH3d6V7 wnog== MIME-Version: 1.0 Received: by 10.152.104.44 with SMTP id gb12mr1893944lab.11.1354294449638; Fri, 30 Nov 2012 08:54:09 -0800 (PST) Received: by 10.114.2.195 with HTTP; Fri, 30 Nov 2012 08:54:09 -0800 (PST) X-Originating-IP: [81.134.152.4] In-Reply-To: <51803EE3-A997-4DA4-A918-83B0B5B82996@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> <3DDE1B3C-CBF4-4773-A3C2-AA61856B270C@sensinode.com> <9FCF6E24-CE7C-4E26-887A-0918369C992D@tzi.org> <6AF38EAF-DB60-4D6F-AE99-5226034917DB@intec.ugent.be> <51803EE3-A997-4DA4-A918-83B0B5B82996@tzi.org> Date: Fri, 30 Nov 2012 16:54:09 +0000 Message-ID: From: Thomas Fossati To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn6RIKEp3QpFebOgniXq0uk1bXrZUC1AtGep//JrxqlmlzZjPIdV3XoWxeFEDQWRFC8lsAU Cc: "core@ietf.org WG" Subject: Re: [core] Call for consensus: Should we switch out the option encoding? 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, 30 Nov 2012 16:54:11 -0000 On Fri, Nov 30, 2012 at 2:09 PM, Carsten Bormann wrote: > Other messages have discussed the quantifiable and not so quantifiable advantages (and disadvantages) of the new proposal. > I think I can already state consensus that the new proposal is simpler, which fits the goals of the WG well. I think we are still missing one very important datum on which to base an informed decision, i.e. an estimate of how many CoAP devices *based on -12* are really deployed in the real world (and by real world I mean out of test labs) at present. From cabo@tzi.org Fri Nov 30 09:22:24 2012 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 3A31521F897B for ; Fri, 30 Nov 2012 09:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_42=0.6, 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 7W4mQbXPNdHQ for ; Fri, 30 Nov 2012 09:22:20 -0800 (PST) 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 5F61021F8958 for ; Fri, 30 Nov 2012 09:22:20 -0800 (PST) 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 qAUHM7uG008284; Fri, 30 Nov 2012 18:22:07 +0100 (CET) Received: from [172.18.204.33] (unknown [81.253.19.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 57E519A2; Fri, 30 Nov 2012 18:22:07 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Fri, 30 Nov 2012 18:22:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <19F717BA-F509-49BF-8073-77A218A67B53@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> <3DDE1B3C-CBF4-4773-A3C2-AA61856B270C@sensinode.com> <9FCF6E24-CE7C-4E26-887A-0918369C992D@tzi.org> <6AF38EAF-DB60-4D6F-AE99-5226034917DB@intec.ugen t.be> <51803EE3-A997-4DA4-A918-83B0B5B82996@tzi.org> To: Thomas Fossati X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] Call for consensus: Should we switch out the option encoding? 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, 30 Nov 2012 17:22:24 -0000 On Nov 30, 2012, at 17:54, Thomas Fossati wrote: > On Fri, Nov 30, 2012 at 2:09 PM, Carsten Bormann wrote: >> Other messages have discussed the quantifiable and not so = quantifiable advantages (and disadvantages) of the new proposal. >> I think I can already state consensus that the new proposal is = simpler, which fits the goals of the WG well. >=20 > I think we are still missing one very important datum on which to base > an informed decision, i.e. an estimate of how many CoAP devices *based > on -12* are really deployed in the real world (and by real world I > mean out of test labs) at present. I believe for the purposes of this discussion we can act on the = assumption the number is zero. coap-12 was published October 1, 2012. Today is November 30, 2012. I know many people act fast, but not that fast. (Of course, the technical details have been known a bit longer, but not = much.) (Deploying based on Internet-Drafts that haven't even been passed up to = the IESG is reasonable only if you have a great update mechanism...) No, it's not deployments I'm concerned about, but existing = infrastructure on the development side. One breaking change didn't seem to be too big a deal for the developers = present in Vancouver (August 2012). Another one four months later, maybe a bit more. =20 But please answer from what you know about *your* environment, not by = imagining what problems other people could have. (They will, or at least should, speak up on their own...) So, just as a template for potential input, let me give my personal = view: -- I won't have any problems with my own stuff. New code already done = (those 30 minutes). I'll just need to set the date when I switch over = coap.me. -- New code for Copper has been done today, I hope Matthias has = published it or will do so tomorrow. =20 -- Wireshark will need another update. Both the C language and the Lua = dissectors probably will need a couple of weeks before they are = available again in any new encodings; and you might have to recompile on = your own (for the C version) before it trickles through to the next = release. -- IRISA will have to update their tool, too. Sorry, guys... -- I will have to collect a couple new pcaps to use as a corpus for = further development. Or write a converter (shudder). -- (And then there is a little bit of editorial work still to be done on = the spec.) -- I will have to give lectures, write articles and books etc. about = this, so I'd love to regain some simplicity. -- There are always some detractors who will use this event as a = demonstration that we are unstable, unreasonable, and irresponsible. I = think we can deal with them. But your situation may be different, and I don't want to influence you = here. Gr=FC=DFe, Carsten From tho@koanlogic.com Fri Nov 30 10:21:50 2012 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 F025B21F8AF5 for ; Fri, 30 Nov 2012 10:21:50 -0800 (PST) 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 o6c8Pgwi4l+S for ; Fri, 30 Nov 2012 10:21:50 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3699521F8AE9 for ; Fri, 30 Nov 2012 10:21:49 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so775237lbk.31 for ; Fri, 30 Nov 2012 10:21:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=LxMGbxFuOJ24U+NBxrAalzRxfacYU8RzgkSVmCtxyow=; b=Kxz51661X/nVx1/eEexQVdIld9mgIPZPH3N/Tf9mGUafU64/qE8j01XPiQvu1LeuA3 dQwQ+PoRTTTP+ZVbnOsku8SuUQjef2qalJmdddkrdcc835SKFtLuYvISLxd4TT5iy8U5 14gxyS41J7RhjvPUIXG9y1ZPQwPHvjm1IXookCKdFc7AjOBcGV90ITJOUc3SaJ73f3DI rN3lHk88K0HrPnxQcCENgVql4wB/HfuoqUdZXvlp3jlQpxnU4C5xL6Ie7LV2UyyRxyqp 4/FXpa8jYhEgQMRHey/nTmsYJghG4cnmTAT9457he+o2E2sdtY8TrvIZfaFWGmcI70/C 6Kyg== MIME-Version: 1.0 Received: by 10.152.105.33 with SMTP id gj1mr2090523lab.49.1354299708770; Fri, 30 Nov 2012 10:21:48 -0800 (PST) Received: by 10.114.2.195 with HTTP; Fri, 30 Nov 2012 10:21:48 -0800 (PST) X-Originating-IP: [81.134.152.4] In-Reply-To: <19F717BA-F509-49BF-8073-77A218A67B53@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> <3DDE1B3C-CBF4-4773-A3C2-AA61856B270C@sensinode.com> <9FCF6E24-CE7C-4E26-887A-0918369C992D@tzi.org> <51803EE3-A997-4DA4-A918-83B0B5B82996@tzi.org> <19F717BA-F509-49BF-8073-77A218A67B53@tzi.org> Date: Fri, 30 Nov 2012 18:21:48 +0000 Message-ID: From: Thomas Fossati To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlExq18JdgGVmh4NTMSQHaSRpyiq9vY+akTGJEdv1HeNu2gEWOIam/RoxRWFoD3pnIvllcr Cc: "core@ietf.org WG" Subject: Re: [core] Call for consensus: Should we switch out the option encoding? 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, 30 Nov 2012 18:21:51 -0000 Ok, so I'm strongly in favour of changing the option encoding to the one proposed by Klaus -- modulo the *small* set of tweaks that the WG has agreed on. I'm concerned with easing the future adoption of CoAP rather than any other consideration, and I think that a simple to implement spec is key in this regard.