From Mohana.Jeyatharan@sg.panasonic.com Sun May 9 18:32:52 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5D1928C108 for ; Sun, 9 May 2010 18:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.731 X-Spam-Level: ** X-Spam-Status: No, score=2.731 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0woIar8nGyzA for ; Sun, 9 May 2010 18:32:52 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id E29DD28C107 for ; Sun, 9 May 2010 18:32:51 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id o4A1Wdo2017207 for ; Mon, 10 May 2010 10:32:39 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili04) with ESMTP id o4A1Wb819008 for ; Mon, 10 May 2010 10:32:38 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 May 2010 09:33:19 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD0414DEC2@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Query on draft-struek-6lowapp-smartenergy-00 Thread-Index: Acrv4MU1cZ0dL7crS3qYpuROfEAhJw== From: "Mohana Jeyatharan" To: Subject: [core] Query on draft-struek-6lowapp-smartenergy-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 01:32:52 -0000 Hi,=20 The requirements draft (draft-struek-6lowapp-smartenergy-00) pertaining to smart energy related requirements in HAN is a useful piece of information. It is stated in section 2.2, application protocol requirements for SE device to SE device communication. However, in the draft there is no use case explained as to why such smart energy related communication takes place between devices in the HAN. What is this SE device? My understanding is that they are home appliances. My assumption is that SE devices are the nodes in 6LowPAN and not the routers (forwarders) nor the edge router which defines the border of the 6LowPAN. Is the smart meter also considered as the SE device? Section 1(introduction) outlines general benefits of the smart energy communication and the communication end points looks like utilities and consumers/equipment(appliances). However, although SE to SE communication requirements are mentioned in section 2 there is no explanation given as to the validity of the use case pertaining to smart energy management. Also it is mentioned SE device to server communication. What is this server? Is it the edge router whuch acts as a sink or the server in utlility? If someone could shed more light on this it is useful. BR, Mohana From d.sturek@att.net Sun May 9 20:12:31 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50A563A6ACE for ; Sun, 9 May 2010 20:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.648 X-Spam-Level: X-Spam-Status: No, score=0.648 tagged_above=-999 required=5 tests=[AWL=-1.137, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LMzUmBkSAPP for ; Sun, 9 May 2010 20:12:30 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 9FB983A6AD0 for ; Sun, 9 May 2010 20:12:30 -0700 (PDT) Received: (qmail 56593 invoked from network); 10 May 2010 03:12:17 -0000 Received: from adsl-69-233-151-131.dsl.sndg02.pacbell.net (d.sturek@69.233.151.131 with login) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 09 May 2010 20:12:17 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: kGo.dSAVM1nXeLmhPRo4WRffUVQgS1fkgzFiYAKTIXNaV1zx_1bUc1Ips93PVQ1ZnzvCIjU2483LEnXrHzg1E2qPj0x5cFpxV27AT84y_EtfrBHF8XtrRxfSGEYpFbZeB9sbZ_rfET3Epcmd4TtAplJfIqQO7e7tzwUrdBRJ1sGnGYPPUvd9J1wqjeVF5Gj3JpOaZfbO3rN1Xo1luT388Fqsm5ZfSOPGzDRbPpFWXv2GJ1R4wy7ooMhFc3OqJRNIvoTWzZz4q5kz4eoOYGpc9CsQ654nV.DaVddffnITOf1MP.cWV2g- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Mohana Jeyatharan'" , References: <5F09D220B62F79418461A978CA0921BD0414DEC2@pslexc01.psl.local> In-Reply-To: <5F09D220B62F79418461A978CA0921BD0414DEC2@pslexc01.psl.local> Date: Sun, 9 May 2010 20:12:14 -0700 Message-ID: <001901caefee$977eb980$c67c2c80$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: Acrv4MU1cZ0dL7crS3qYpuROfEAhJwADZAbA Content-Language: en-us Subject: Re: [core] Query on draft-struek-6lowapp-smartenergy-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 03:12:31 -0000 Hi Mohana, You should read the use cases for Smart Grid HAN deployments. Specifically, the ZigBee/HomePlug Market Requirements Document Use Cases will explain what the communication exchange scenarios are. Don -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Mohana Jeyatharan Sent: Sunday, May 09, 2010 6:33 PM To: core@ietf.org Subject: [core] Query on draft-struek-6lowapp-smartenergy-00 Hi, The requirements draft (draft-struek-6lowapp-smartenergy-00) pertaining to smart energy related requirements in HAN is a useful piece of information. It is stated in section 2.2, application protocol requirements for SE device to SE device communication. However, in the draft there is no use case explained as to why such smart energy related communication takes place between devices in the HAN. What is this SE device? My understanding is that they are home appliances. My assumption is that SE devices are the nodes in 6LowPAN and not the routers (forwarders) nor the edge router which defines the border of the 6LowPAN. Is the smart meter also considered as the SE device? Section 1(introduction) outlines general benefits of the smart energy communication and the communication end points looks like utilities and consumers/equipment(appliances). However, although SE to SE communication requirements are mentioned in section 2 there is no explanation given as to the validity of the use case pertaining to smart energy management. Also it is mentioned SE device to server communication. What is this server? Is it the edge router whuch acts as a sink or the server in utlility? If someone could shed more light on this it is useful. BR, Mohana _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From Mohana.Jeyatharan@sg.panasonic.com Sun May 9 20:45:06 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9424428B56A for ; Sun, 9 May 2010 20:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.751 X-Spam-Level: ** X-Spam-Status: No, score=2.751 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLBlJhTFTkaL for ; Sun, 9 May 2010 20:45:05 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 7A6423A657C for ; Sun, 9 May 2010 20:45:05 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id o4A3ip66008305; Mon, 10 May 2010 12:44:51 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili02) with ESMTP id o4A3ieV24091; Mon, 10 May 2010 12:44:41 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 May 2010 11:45:26 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD0414DF69@pslexc01.psl.local> In-Reply-To: <001901caefee$977eb980$c67c2c80$@sturek@att.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Query on draft-struek-6lowapp-smartenergy-00 Thread-Index: Acrv4MU1cZ0dL7crS3qYpuROfEAhJwADZAbAAAEooqA= References: <5F09D220B62F79418461A978CA0921BD0414DEC2@pslexc01.psl.local> <001901caefee$977eb980$c67c2c80$@sturek@att.net> From: "Mohana Jeyatharan" To: , Subject: Re: [core] Query on draft-struek-6lowapp-smartenergy-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 03:45:06 -0000 Hi Don, Thank you for your response. Will check the market requirement document for the communication scenarios. BR, Mohana > -----Original Message----- > From: Don Sturek [mailto:d.sturek@att.net] > Sent: Monday, May 10, 2010 11:12 AM > To: Mohana Jeyatharan; core@ietf.org > Subject: RE: [core] Query on draft-struek-6lowapp-smartenergy-00 >=20 > Hi Mohana, >=20 > You should read the use cases for Smart Grid HAN deployments. > Specifically, > the ZigBee/HomePlug Market Requirements Document Use Cases will explain > what > the communication exchange scenarios are. >=20 > Don >=20 >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of > Mohana Jeyatharan > Sent: Sunday, May 09, 2010 6:33 PM > To: core@ietf.org > Subject: [core] Query on draft-struek-6lowapp-smartenergy-00 >=20 > Hi, >=20 > The requirements draft (draft-struek-6lowapp-smartenergy-00) pertaining > to smart energy related requirements in HAN is a useful piece of > information. >=20 > It is stated in section 2.2, application protocol requirements for SE > device to SE device communication. However, in the draft there is no > use case explained as to why such smart energy related communication > takes place between devices in the HAN. What is this SE device? My > understanding is that they are home appliances. My assumption is that SE > devices are the nodes in 6LowPAN and not the routers (forwarders) nor > the edge router which defines the border of the 6LowPAN. Is the smart > meter also considered as the SE device? >=20 > Section 1(introduction) outlines general benefits of the smart energy > communication and the communication end points looks like utilities and > consumers/equipment(appliances). However, although SE to SE > communication requirements are mentioned in section 2 there is no > explanation given > as to the validity of the use case pertaining to smart energy > management. >=20 > Also it is mentioned SE device to server communication. > What is this server? Is it the edge router whuch acts as a sink or the > server in utlility? >=20 > If someone could shed more light on this it is useful. >=20 > BR, > Mohana > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From zach@sensinode.com Mon May 10 00:25:17 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15D8E28C128 for ; Mon, 10 May 2010 00:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSVoGau5zPJ3 for ; Mon, 10 May 2010 00:25:15 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 9C2F128C14F for ; Mon, 10 May 2010 00:19:44 -0700 (PDT) Received: from [62.145.172.51] ([62.145.172.51]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o4A7JT7F007121 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 10 May 2010 10:19:29 +0300 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 10 May 2010 10:19:30 +0300 References: <20100510070525.4102628C0CE@core3.amsl.com> To: core Message-Id: Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [core] Fwd: New Version Notification for draft-shelby-core-coap-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 07:25:17 -0000 Hi, Version -01 of draft-shelby-core-coap is now available: http://www.ietf.org/id/draft-shelby-core-coap-01.txt This has gone through a lot of little revisions after Anaheim based on = the list discussions, comments on -00, discussions with the chairs and = quite a bit of implementation validation. We hope -01 fixes most of the = issues and provides the main improvements requested so far. My goal is = to keep this stable for a longer time to give people a chance to get = some implementation experience (have heard of 5 implementations so far). = Next update planned before the Maastricht cutoff. Here is a summary of the major changes in -01: - Method names now GET, PUT, POST, DELETE - Unified the message header and added a notify message type. - Completed the SUBMIT method and option - Improved the option TLV header, added Etag, Date and = Subscription-lifetime Options - Added a Magic byte header for TCP and packed UDP - Wrote initial subscription, discovery and proxy sections - Plenty of simplification, optimization and bug fixes=20 And of course still plenty of TODOs, the main ones are: - HTTP Mapping - Proxying - Complete Examples section=20 - Define the TLS and DTLS bindings (help!)=20 Zach, Brian and Don Begin forwarded message: > From: IETF I-D Submission Tool > Date: May 10, 2010 10:05:25 GMT+03:00 > To: zach@sensinode.com > Cc: brian@skyfoundry.com,d.sturek@att.net > Subject: New Version Notification for draft-shelby-core-coap-01=20 >=20 >=20 > A new version of I-D, draft-shelby-core-coap-01.txt has been = successfully submitted by Zach Shelby and posted to the IETF repository. >=20 > Filename: draft-shelby-core-coap > Revision: 01 > Title: Constrained Application Protocol (CoAP) > Creation_date: 2010-05-10 > WG ID: Independent Submission > Number_of_pages: 33 >=20 > Abstract: > This document specifies the Constrained Application Protocol (CoAP), > a specialized transfer protocol for use with constrained networks and > nodes for machine-to-machine applications such as smart energy and > building automation. These constrained nodes often have 8-bit > microcontrollers with small amounts of ROM and RAM, while networks > such as 6LoWPAN often have high packet error rates and typical > throughput of 10s of kbps. CoAP provides request/reply and > subscribe/notify interaction models between appliciation end-points, > supports built-in resource discovery, and includes key web concepts > such as URIs and RESTful methods. CoAP easily translates to HTTP for > integration with the web while meeting specialized requirements such > as multicast support, very low overhead and simplicity for > constrained environments. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 --=20 Zach Shelby, Head of Research, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From cabo@tzi.org Mon May 10 09:51:30 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 503643A6A5A for ; Mon, 10 May 2010 09:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.415 X-Spam-Level: X-Spam-Status: No, score=-4.415 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3RuEcwoyAHq for ; Mon, 10 May 2010 09:51:29 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id DB0783A6A56 for ; Mon, 10 May 2010 09:51:28 -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 o4AGp8Ka012280 for ; Mon, 10 May 2010 18:51:08 +0200 (CEST) Received: from [192.168.217.101] (p5489AF27.dip.t-dialin.net [84.137.175.39]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id C6F2DD7BA; Mon, 10 May 2010 18:51:07 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 10 May 2010 18:51:06 +0200 To: core Message-Id: <3BB5F67A-9E57-4F81-B7C5-ABB1E136DAAC@tzi.org> Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [core] Selecting a WG document for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 16:51:30 -0000 The CORE WG has a milestone to select a WG document for CoAP in April: http://datatracker.ietf.org/wg/core/charter/ ... Apr 2010 Select WG document for basis of the CoAP protocol Of the various documents that have been contributed, = draft-shelby-core-coap has significant discussion, as well as the = largest number of updates (including a previous version that was still = called -6lowapp-coap). Today, another updated version of that draft was announced. See http://www.ietf.org/mail-archive/web/core/current/msg00138.html for the announcement and http://tools.ietf.org/html/draft-shelby-core-coap-01 for the draft itself. However, as the authors say, there are still significant TODOs. Are we in a state yet where we can say whether this is the right = direction for the WG to take? If yes, is it the right direction? Should we adopt it as a WG document? If you don't think we can say yet, is there a set of technical decisions = you would like the authors to take with priority? Note that once a document has become a WG document, the authors act as = editors for the working group, making (and usually fleshing out the = details of) any change that the WG decides it needs. If you think we can still improve the draft, this is not an obstacle to = making it a WG document. But of course we shouldn't do that if we intend to reverse its = fundamental technical direction. In order to stay roughly in sync with our milestones, we should reach at = a decision on how to go forward this week. Gruesse, Carsten From matthieu.vial@fr.non.schneider-electric.com Tue May 11 01:12:32 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B5103A6B18; Tue, 11 May 2010 01:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.965 X-Spam-Level: X-Spam-Status: No, score=0.965 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMOwT-BFA-xH; Tue, 11 May 2010 01:12:28 -0700 (PDT) Received: from mailX02.eud.schneider-electric.com (mailx02.eud.schneider-electric.com [205.167.7.38]) by core3.amsl.com (Postfix) with ESMTP id 3ADC83A6B2E; Tue, 11 May 2010 01:12:21 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX02.eud.schneider-electric.com with ESMTP id 2010051110053097-152305 ; Tue, 11 May 2010 10:05:30 +0200 In-Reply-To: To: Zach Shelby X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: matthieu.vial@fr.non.schneider-electric.com Date: Tue, 11 May 2010 10:11:56 +0200 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 11/05/2010 10:12:03, Itemize by SMTP Server on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 11/05/2010 10:05:31, Serialize by Router on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 11/05/2010 10:05:38 Content-type: multipart/related; Boundary="0__=4EBBFD8CDFCAEB398f9e8a93df938690918c4EBBFD8CDFCAEB39" Cc: core-bounces@ietf.org, core Subject: [core] RE Fwd: New Version Notification for draft-shelby-core-coap-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 08:12:33 -0000 --0__=4EBBFD8CDFCAEB398f9e8a93df938690918c4EBBFD8CDFCAEB39 Content-type: multipart/alternative; Boundary="1__=4EBBFD8CDFCAEB398f9e8a93df938690918c4EBBFD8CDFCAEB39" --1__=4EBBFD8CDFCAEB398f9e8a93df938690918c4EBBFD8CDFCAEB39 Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=ISO-8859-1 Hi, First of all congratulations for your work. I have few comments about the subscribe/notify mechanism and the resour= ce directory. As far as I understand the specification, a client will receive its notifications on the same port as the subscribe request. As an implemen= ter I would like to handle all asynchronous notifications on a dedicated po= rt and perform synchronous GET, POST, PUT, DELETE on a different port. The= current specification allows to do this for the UDP binding as it is connectionless but for the TCP binding I must keep the connection I use= d for the subscribe request alive. Just tell me if it is not the good approach because I know TCP is not a major concern for COAP. How can I define a fine grained notification? Is it completlty left to = the application so I must define a message format to describe precise notification rules and include this message into the subscribe payload = or will you provide a framework later? Typical notification options would = be: minimal delay between 2 notifications to prevent from overwhelming the network, an increment as the minimal change for noisy inputs, a maximum= delay between notifications for periodic notifications and keep alive signals ... How do you manage the lifetime of resources in the resource directory? The /.well-known/resources will probably not change very often so a sim= ple subscription/notification would be useless. Moreover a periodic POST fr= om devices seems not very efficient because the link format is quite verbo= se to be repeated without a real need. We could reuse the cacheability of = COAP to avoid large data transfer but only the get method is cacheable. That= means the directory agent should have a list of all devices. This imply= some kind of registration mechanism to the directory. Best regards, Matthieu VIAL = Zach Shelby = = A Envoy=E9 par : core = core-bounces@ietf = cc .org = Ob= jet [core] Fwd: New Version = 10/05/2010 09:19 Notification for = draft-shelby-core-coap-01 = = = = = = = Hi, Version -01 of draft-shelby-core-coap is now available: http://www.ietf.org/id/draft-shelby-core-coap-01.txt This has gone through a lot of little revisions after Anaheim based on = the list discussions, comments on -00, discussions with the chairs and quit= e a bit of implementation validation. We hope -01 fixes most of the issues = and provides the main improvements requested so far. My goal is to keep thi= s stable for a longer time to give people a chance to get some implementa= tion experience (have heard of 5 implementations so far). Next update planne= d before the Maastricht cutoff. Here is a summary of the major changes in -01: - Method names now GET, PUT, POST, DELETE - Unified the message header and added a notify message type. - Completed the SUBMIT method and option - Improved the option TLV header, added Etag, Date and Subscription-lifetime Options - Added a Magic byte header for TCP and packed UDP - Wrote initial subscription, discovery and proxy sections - Plenty of simplification, optimization and bug fixes And of course still plenty of TODOs, the main ones are: - HTTP Mapping - Proxying - Complete Examples section - Define the TLS and DTLS bindings (help!) Zach, Brian and Don Begin forwarded message: > From: IETF I-D Submission Tool > Date: May 10, 2010 10:05:25 GMT+03:00 > To: zach@sensinode.com > Cc: brian@skyfoundry.com,d.sturek@att.net > Subject: New Version Notification for draft-shelby-core-coap-01 > > > A new version of I-D, draft-shelby-core-coap-01.txt has been successf= ully submitted by Zach Shelby and posted to the IETF repository. > > Filename: draft-shelby-core-coap > Revision: 01 > Title: Constrained Application Protocol (CoAP)= > Creation_date: 2010-05-10 > WG ID: Independent Submission > Number_of_pages: 33 > > Abstract: > This document specifies the Constrained Application Protocol (CoAP), > a specialized transfer protocol for use with constrained networks and= > nodes for machine-to-machine applications such as smart energy and > building automation. These constrained nodes often have 8-bit > microcontrollers with small amounts of ROM and RAM, while networks > such as 6LoWPAN often have high packet error rates and typical > throughput of 10s of kbps. CoAP provides request/reply and > subscribe/notify interaction models between appliciation end-points, > supports built-in resource discovery, and includes key web concepts > such as URIs and RESTful methods. CoAP easily translates to HTTP for= > integration with the web while meeting specialized requirements such > as multicast support, very low overhead and simplicity for > constrained environments. > > > > The IETF Secretariat. > > -- Zach Shelby, Head of Research, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ = --1__=4EBBFD8CDFCAEB398f9e8a93df938690918c4EBBFD8CDFCAEB39 Content-transfer-encoding: quoted-printable Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline

Hi,

First of all congratulations for your work.

I have few comments about the subscribe/notify mechanism and the resour= ce directory.

As far as I understand the specification, a client will receive its not= ifications on the same port as the subscribe request. As an implementer= I would like to handle all asynchronous notifications on a dedicated p= ort and perform synchronous GET, POST, PUT, DELETE on a different port.= The current specification allows to do this for the UDP binding as it = is connectionless but for the TCP binding I must keep the connection I = used for the subscribe request alive. Just tell me if it is not the goo= d approach because I know TCP is not a major concern for COAP.

How can I define a fine grained notification? Is it completlty left to = the application so I must define a message format to describe precise n= otification rules and include this message into the subscribe payload o= r will you provide a framework later? Typical notification options woul= d be: minimal delay between 2 notifications to prevent from overwhelmin= g the network, an increment as the minimal change for noisy inputs, a m= aximum delay between notifications for periodic notifications and keep = alive signals ...

How do you manage the lifetime of resources in the resource directory? = The /.well-known/resources will probably not change very often so a sim= ple subscription/notification would be useless. Moreover a periodic POS= T from devices seems not very efficient because the link format is quit= e verbose to be repeated without a real need. We could reuse the cachea= bility of COAP to avoid large data transfer but only the get method is = cacheable. That means the directory agent should have a list of all dev= ices. This imply some kind of registration mechanism to the directory.<= br>
Best regards,
Matthieu VIAL


3D"InactiveZach Shelby <zach@sensinode.com&g= t;




=
          Zach Shelby <zach@sensinode.com>
          Envoy=E9 par : core-bounces@ietf.org

          10/05/2010 09:19

 =
3D=
A
3D""
core <core@ietf.org>
3D=
cc
3D""
3D=
Objet
3D""
[core] Fwd: New Version Notification for draft-shelby-= core-coap-01
3D=3D""

Hi,

Version -01 of draft-shelby-core-coap is now available:

http://www.ietf.org/id/draft-shelby-core-coap-01.txt
This has gone through a lot of little revisions after Anaheim based on = the list discussions, comments on -00, discussions with the chairs and = quite a bit of implementation validation. We hope -01 fixes most of the= issues and provides the main improvements requested so far. My goal is= to keep this stable for a longer time to give people a chance to get s= ome implementation experience (have heard of 5 implementations so far).= Next update planned before the Maastricht cutoff.

Here is a summary of the major changes in -01:

- Method names now GET, PUT, POST, DELETE
- Unified the message header and added a notify message type.
- Completed the SUBMIT method and option
- Improved the option TLV header, added Etag, Date and Subscription-lif= etime Options
- Added a Magic byte header for TCP and packed UDP
- Wrote initial subscription, discovery and proxy sections
- Plenty of simplification, optimization and bug fixes

And of course still plenty of TODOs, the main ones are:

- HTTP Mapping
- Proxying
- Complete Examples section
- Define the TLS and DTLS bindings (help!)

Zach, Brian and Don

Begin forwarded message:

> From: IETF I-D Submission Tool <idsubmission@ietf.org>
> Date: May 10, 2010 10:05:25 GMT+03:00
> To: zach@sensinode.com
> Cc: brian@skyfoundry.com,d.sturek@att.net
> Subject: New Version Notification for draft-shelby-core-coap-01 >
>
> A new version of I-D, draft-shelby-core-coap-01.txt has been succe= ssfully submitted by Zach Shelby and posted to the IETF repository.
= >
> Filename:  draft-shelby-core-coap
> Revision:  01
> Title:  Constrained Application Protocol (CoAP)
> Creation_date:  2010-05-10
> WG ID:  Independent Submission
> Number_of_pages: 33
>
> Abstract:
> This document specifies the Constrained Application Protocol (CoAP= ),
> a specialized transfer protocol for use with constrained networks = and
> nodes for machine-to-machine applications such as smart energy and=
> building automation.  These constrained nodes often have 8-bi= t
> microcontrollers with small amounts of ROM and RAM, while networks=
> such as 6LoWPAN often have high packet error rates and typical
= > throughput of 10s of kbps.  CoAP provides request/reply and > subscribe/notify interaction models between appliciation end-point= s,
> supports built-in resource discovery, and includes key web concept= s
> such as URIs and RESTful methods.  CoAP easily translates to = HTTP for
> integration with the web while meeting specialized requirements su= ch
> as multicast support, very low overhead and simplicity for
> constrained environments.
>
>
>
> The IETF Secretariat.
>
>

--
Zach Shelby, Head of Research, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net=  - My book "6LoWPAN: The Wireless Embedded Internet"
= Mobile: +358 40 7796297

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

______________________________________________________________________<= br> This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________<= br>
= --1__=4EBBFD8CDFCAEB398f9e8a93df938690918c4EBBFD8CDFCAEB39-- --0__=4EBBFD8CDFCAEB398f9e8a93df938690918c4EBBFD8CDFCAEB39 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=4EBBFD8CDFCAEB398@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=4EBBFD8CDFCAEB398f9e8a93df938690918c4EBBFD8CDFCAEB39 Content-type: image/gif; name="pic31998.gif" Content-Disposition: inline; filename="pic31998.gif" Content-ID: <2__=4EBBFD8CDFCAEB398@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=4EBBFD8CDFCAEB398f9e8a93df938690918c4EBBFD8CDFCAEB39 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=4EBBFD8CDFCAEB398@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=4EBBFD8CDFCAEB398f9e8a93df938690918c4EBBFD8CDFCAEB39-- From therbst@silverspringnet.com Tue May 11 08:49:45 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44B733A69E8 for ; Tue, 11 May 2010 08:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+koKM71fvwC for ; Tue, 11 May 2010 08:49:44 -0700 (PDT) Received: from bachelor.silverspringnet.com (bachelor.silverspringnet.com [69.36.245.73]) by core3.amsl.com (Postfix) with ESMTP id 9039D3A6958 for ; Tue, 11 May 2010 08:49:44 -0700 (PDT) Received: from IT-EXCA-01.silverspringnet.com ([10.200.1.60]) by bachelor.silverspringnet.com (8.14.1/8.13.8) with ESMTP id o4BFnEgM000434 for ; Tue, 11 May 2010 08:49:24 -0700 (PDT) Received: from IT-EXMB-01.silverspringnet.com ([fe80::b81e:2d5b:d263:6c44]) by IT-EXCA-01.silverspringnet.com ([::1]) with mapi; Tue, 11 May 2010 08:49:14 -0700 From: Thomas Herbst To: "core@ietf.org" Date: Tue, 11 May 2010 08:49:10 -0700 Thread-Topic: Core UDP vs TCP : Redux Thread-Index: AcrxIX9QnEVhlnKvTMi9kQtypEJB8w== Message-ID: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {82BA785E-6160-4AC2-AFF7-7CA8E27F0777} x-cr-hashedpuzzle: CUTQ CmRq DLO1 Dfu1 EdYQ Fgt4 F+vd GFZ7 G5VM HYne Hrgc IFGK JAbJ J+IJ K0Zw LJtG; 1; YwBvAHIAZQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {82BA785E-6160-4AC2-AFF7-7CA8E27F0777}; dABoAGUAcgBiAHMAdABAAHMAaQBsAHYAZQByAHMAcAByAGkAbgBnAG4AZQB0AC4AYwBvAG0A; Tue, 11 May 2010 15:49:10 GMT;QwBvAHIAZQAgAFUARABQACAAdgBzACAAVABDAFAAIAA6ACAAUgBlAGQAdQB4AA== acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 15:49:45 -0000 After the discussion in Anaheim, I'm surprised that we need yet another rev= isit to UDP and TCP for CORE. The Right Solution(tm) might well be to fix TCP such that it doesn't lose i= ts brains every time you drop a packet, and we could end up with an end-to-= end system where constrained devices might reasonably provide services to n= ormal hosts in the regular Internet, However, transport work is out of sco= pe for this WG. The second most right solution would be to implement CORE with a reliable U= DP protocol, as is done in much of the draft. The "optional" TCP portions = of the draft are mostly increased complexity for no added benefit. If a dev= ice is capable of running TCP and the network it works on is capable of sup= porting TCP, you should just open a connection to Port 80 and use HTTP (or = the TCP port/protocol of your choice). There are many protocols a host MAY= implement and it is not appropriate for the draft to enumerate them. =20 Let's remove all of the sections related to TCP in the draft. tom =20 From dotis@mail-abuse.org Tue May 11 12:58:58 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00A093A6BEA for ; Tue, 11 May 2010 12:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.818 X-Spam-Level: X-Spam-Status: No, score=-3.818 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IrYX1rCcXlX for ; Tue, 11 May 2010 12:58:57 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 2F2363A69ED for ; Tue, 11 May 2010 12:58:57 -0700 (PDT) Received: from sjc-office-nat-223.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 288C9A944C7 for ; Tue, 11 May 2010 18:09:01 +0000 (UTC) Message-ID: <4BE99D3C.9050902@mail-abuse.org> Date: Tue, 11 May 2010 11:09:00 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: core@ietf.org References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> In-Reply-To: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 19:58:58 -0000 On 5/11/10 8:49 AM, Thomas Herbst wrote: > After the discussion in Anaheim, I'm surprised that we need yet another revisit to UDP and TCP for CORE. > > The Right Solution(tm) might well be to fix TCP such that it doesn't lose its brains every time you drop a packet, and we could end up with an end-to-end system where constrained devices might reasonably provide services to normal hosts in the regular Internet, However, transport work is out of scope for this WG. > > The second most right solution would be to implement CORE with a reliable UDP protocol, as is done in much of the draft. The "optional" TCP portions of the draft are mostly increased complexity for no added benefit. If a device is capable of running TCP and the network it works on is capable of supporting TCP, you should just open a connection to Port 80 and use HTTP (or the TCP port/protocol of your choice). There are many protocols a host MAY implement and it is not appropriate for the draft to enumerate them. > > Let's remove all of the sections related to TCP in the draft. > Agreed. -Doug From Michael.Stuber@itron.com Tue May 11 13:29:18 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 214653A6C40 for ; Tue, 11 May 2010 13:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5Kxd42o2Q36 for ; Tue, 11 May 2010 13:29:17 -0700 (PDT) Received: from mailer-1.itron.com (mailer-1.itron.com [198.182.8.123]) by core3.amsl.com (Postfix) with ESMTP id 0D1AB28C1C3 for ; Tue, 11 May 2010 13:26:56 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-hashedpuzzle: A0kI B2oS B9hu CZKy C2z9 DJ+7 D7ba EN4P EkNN Ekq5 E9Os HSwv JBbj JVRw J82X KIBe; 1; YwBvAHIAZQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {7A44E07F-D806-40AE-B449-59C18F1CA129}; bQBpAGMAaABhAGUAbAAuAHMAdAB1AGIAZQByAEAAaQB0AHIAbwBuAC4AYwBvAG0A; Tue, 11 May 2010 20:26:43 GMT; UgBFADoAIABbAGMAbwByAGUAXQAgAEMAbwByAGUAIABVAEQAUAAgAHYAcwAgAFQAQwBQACAAOgAgAFIAZQBkAHUAeAA= x-cr-puzzleid: {7A44E07F-D806-40AE-B449-59C18F1CA129} Content-class: urn:content-classes:message Date: Tue, 11 May 2010 13:26:43 -0700 Message-ID: <05C6A38D732F1144A8C4016BA4416BFE02D034DB@SPO-EXVS-02.itron.com> In-Reply-To: <4BE99D3C.9050902@mail-abuse.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Core UDP vs TCP : Redux Thread-Index: AcrxRGfu3eaAdi6dTz6D9rRHHf5KGAAA88+A References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <4BE99D3C.9050902@mail-abuse.org> From: "Stuber, Michael" To: Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 20:29:18 -0000 > > Let's remove all of the sections related to TCP in the draft. > =20 +1 From zach@sensinode.com Tue May 11 14:07:17 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 116463A684C for ; Tue, 11 May 2010 14:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBTGt3mdVosM for ; Tue, 11 May 2010 14:07:15 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 0555F3A6A0F for ; Tue, 11 May 2010 14:07:10 -0700 (PDT) Received: from [192.168.1.3] (line-5505.dyn.kponet.fi [85.29.67.213]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o4BL6rcO028603 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 May 2010 00:06:54 +0300 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> Date: Wed, 12 May 2010 00:06:57 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com> References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> To: Thomas Herbst X-Mailer: Apple Mail (2.1077) Cc: "core@ietf.org" Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 21:07:17 -0000 +1 Through writing a few revisions of these specs, I have also already = found TCP to be really awkward. And the TCP negotiation discussions at = the mike in Anaheim made me even more skeptical. Tom is right, if you = need TCP then just use HTTP ;-)=20 Zach=20 On May 11, 2010, at 18:49 , Thomas Herbst wrote: > After the discussion in Anaheim, I'm surprised that we need yet = another revisit to UDP and TCP for CORE. >=20 > The Right Solution(tm) might well be to fix TCP such that it doesn't = lose its brains every time you drop a packet, and we could end up with = an end-to-end system where constrained devices might reasonably provide = services to normal hosts in the regular Internet, However, transport = work is out of scope for this WG. >=20 > The second most right solution would be to implement CORE with a = reliable UDP protocol, as is done in much of the draft. The "optional" = TCP portions of the draft are mostly increased complexity for no added = benefit. If a device is capable of running TCP and the network it works = on is capable of supporting TCP, you should just open a connection to = Port 80 and use HTTP (or the TCP port/protocol of your choice). There = are many protocols a host MAY implement and it is not appropriate for = the draft to enumerate them. =20 >=20 > Let's remove all of the sections related to TCP in the draft. >=20 > tom >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Head of Research, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From zach@sensinode.com Tue May 11 14:19:08 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1426D3A6942 for ; Tue, 11 May 2010 14:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[AWL=-0.499, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PD5LgGoRRhe for ; Tue, 11 May 2010 14:19:06 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 639163A6A88 for ; Tue, 11 May 2010 14:16:56 -0700 (PDT) Received: from [192.168.1.3] (line-5505.dyn.kponet.fi [85.29.67.213]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o4BLGeEY028796 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 May 2010 00:16:40 +0300 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Zach Shelby In-Reply-To: Date: Wed, 12 May 2010 00:16:43 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <595F6A4B-511C-439C-A0C2-43C10998B1FA@sensinode.com> References: To: matthieu.vial@fr.non.schneider-electric.com X-Mailer: Apple Mail (2.1077) Cc: core Subject: Re: [core] RE Fwd: New Version Notification for draft-shelby-core-coap-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 21:19:08 -0000 Hi, On May 11, 2010, at 11:11 , matthieu.vial@fr.non.schneider-electric.com = wrote: > Hi, >=20 > First of all congratulations for your work. >=20 > I have few comments about the subscribe/notify mechanism and the = resource directory. >=20 > As far as I understand the specification, a client will receive its = notifications on the same port as the subscribe request. As an = implementer I would like to handle all asynchronous notifications on a = dedicated port and perform synchronous GET, POST, PUT, DELETE on a = different port. The current specification allows to do this for the UDP = binding as it is connectionless but for the TCP binding I must keep the = connection I used for the subscribe request alive. Just tell me if it is = not the good approach because I know TCP is not a major concern for = COAP. Argh, yet again some problems with TCP. Surely a way to make that work = of course, but it would need more text...=20 >=20 > How can I define a fine grained notification? Is it completlty left to = the application so I must define a message format to describe precise = notification rules and include this message into the subscribe payload = or will you provide a framework later? Typical notification options = would be: minimal delay between 2 notifications to prevent from = overwhelming the network, an increment as the minimal change for noisy = inputs, a maximum delay between notifications for periodic notifications = and keep alive signals ... For sure MIN_NOTIFY_INTERVAL and MAX_NOTIFY_INTERVAL variables should be = added, maybe with a recommended default. With regards to having more = knobs to turn here, I could envision having e.g. a Subscription-interval = Option in addition to Subscription-lifetime. Now that said, anything = more complicated is probably out of scope for CoRE. At least the = transfer protocol shouldn't involve itself with data thresholds etc. =20 >=20 > How do you manage the lifetime of resources in the resource directory? = The /.well-known/resources will probably not change very often so a = simple subscription/notification would be useless. Moreover a periodic = POST from devices seems not very efficient because the link format is = quite verbose to be repeated without a real need. We could reuse the = cacheability of COAP to avoid large data transfer but only the get = method is cacheable. That means the directory agent should have a list = of all devices. This imply some kind of registration mechanism to the = directory. This is a good discussion to have. At least the Etag can help here to = prevent all data from being sent each time, and even a subscription = could be useful in some cases. What I also had in mind was that a = directory can act as a RESTful repository which can store the = descriptions of others. In the end here we have to make an analysis of = real resource discovery scenarios, how they work with these mechanisms, = and then see if we're really missing something. Someone should write a = draft like that by the way...=20 Zach >=20 > Best regards, > Matthieu VIAL >=20 >=20 > Zach Shelby >=20 >=20 >=20 >=20 > Zach Shelby =20 > Envoy=E9 par : core-bounces@ietf.org > 10/05/2010 09:19 >=20 > > A > > core > > cc > > > Objet > > [core] Fwd: New Version Notification for draft-shelby-core-coap-01 > >=20 > Hi, >=20 > Version -01 of draft-shelby-core-coap is now available: >=20 > http://www.ietf.org/id/draft-shelby-core-coap-01.txt >=20 > This has gone through a lot of little revisions after Anaheim based on = the list discussions, comments on -00, discussions with the chairs and = quite a bit of implementation validation. We hope -01 fixes most of the = issues and provides the main improvements requested so far. My goal is = to keep this stable for a longer time to give people a chance to get = some implementation experience (have heard of 5 implementations so far). = Next update planned before the Maastricht cutoff. >=20 > Here is a summary of the major changes in -01: >=20 > - Method names now GET, PUT, POST, DELETE > - Unified the message header and added a notify message type. > - Completed the SUBMIT method and option > - Improved the option TLV header, added Etag, Date and = Subscription-lifetime Options > - Added a Magic byte header for TCP and packed UDP > - Wrote initial subscription, discovery and proxy sections > - Plenty of simplification, optimization and bug fixes=20 >=20 > And of course still plenty of TODOs, the main ones are: >=20 > - HTTP Mapping > - Proxying > - Complete Examples section=20 > - Define the TLS and DTLS bindings (help!)=20 >=20 > Zach, Brian and Don >=20 > Begin forwarded message: >=20 > > From: IETF I-D Submission Tool > > Date: May 10, 2010 10:05:25 GMT+03:00 > > To: zach@sensinode.com > > Cc: brian@skyfoundry.com,d.sturek@att.net > > Subject: New Version Notification for draft-shelby-core-coap-01=20 > >=20 > >=20 > > A new version of I-D, draft-shelby-core-coap-01.txt has been = successfully submitted by Zach Shelby and posted to the IETF repository. > >=20 > > Filename: draft-shelby-core-coap > > Revision: 01 > > Title: Constrained Application Protocol (CoAP) > > Creation_date: 2010-05-10 > > WG ID: Independent Submission > > Number_of_pages: 33 > >=20 > > Abstract: > > This document specifies the Constrained Application Protocol (CoAP), > > a specialized transfer protocol for use with constrained networks = and > > nodes for machine-to-machine applications such as smart energy and > > building automation. These constrained nodes often have 8-bit > > microcontrollers with small amounts of ROM and RAM, while networks > > such as 6LoWPAN often have high packet error rates and typical > > throughput of 10s of kbps. CoAP provides request/reply and > > subscribe/notify interaction models between appliciation end-points, > > supports built-in resource discovery, and includes key web concepts > > such as URIs and RESTful methods. CoAP easily translates to HTTP = for > > integration with the web while meeting specialized requirements such > > as multicast support, very low overhead and simplicity for > > constrained environments. > >=20 > >=20 > >=20 > > The IETF Secretariat. > >=20 > >=20 >=20 > --=20 > Zach Shelby, Head of Research, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > ______________________________________________________________________ >=20 --=20 Zach Shelby, Head of Research, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From cabo@tzi.org Tue May 11 14:38:18 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F9803A68F3 for ; Tue, 11 May 2010 14:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[AWL=-0.637, BAYES_40=-0.185, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtu+fNxOCTsr for ; Tue, 11 May 2010 14:38:17 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 0320A3A6A56 for ; Tue, 11 May 2010 14:38:10 -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 o4BLbtVV018099; Tue, 11 May 2010 23:37:56 +0200 (CEST) Received: from [192.168.217.101] (p5489F409.dip.t-dialin.net [84.137.244.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 7A249DF75; Tue, 11 May 2010 23:37:55 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com> Date: Tue, 11 May 2010 23:37:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com> To: Zach Shelby X-Mailer: Apple Mail (2.1078) Cc: "core@ietf.org" Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 21:38:18 -0000 On May 11, 2010, at 23:06, Zach Shelby wrote: > I have also already found TCP to be really awkward (No WG chair hat) The reason why I thought it would be a good idea to have TCP as an = option in there was to fend off tendencies to reinvent TCP on top of = UDP. If we can agree not to do that, I'm certainly fine with throwing = out TCP. But once people do start to argue for reinventing TCP, we'll = need to put the original back in. (Rationale: 1) DTSTTCPW (Do the simplest thing that could possibly work.) 2) We can always put TCP back in later in a v2 of the protocol, once we = know more about the applications and their real requirements from actual = deployments and whether having TCP is a good thing.) Gruesse, Carsten From robby.simpson@ge.com Tue May 11 14:42:04 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31BF83A6A83 for ; Tue, 11 May 2010 14:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wohtP8bYTxYq for ; Tue, 11 May 2010 14:42:03 -0700 (PDT) Received: from exprod5og108.obsmtp.com (exprod5og108.obsmtp.com [64.18.0.186]) by core3.amsl.com (Postfix) with ESMTP id 9E97F3A6A59 for ; Tue, 11 May 2010 14:42:01 -0700 (PDT) Received: from source ([12.43.191.1]) (using TLSv1) by exprod5ob108.postini.com ([64.18.4.12]) with SMTP ID DSNKS+nPHthKHSNXhxaTErJCo/WvwOs11q+Z@postini.com; Tue, 11 May 2010 14:41:51 PDT Received: from unknown (HELO alpmlef08.e2k.ad.ge.com) ([3.159.18.17]) by Alpmlip06.e2k.ad.ge.com with ESMTP; 11 May 2010 17:41:49 -0400 Received: from ALPMLVEM04.e2k.ad.ge.com ([3.159.17.51]) by alpmlef08.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 May 2010 17:41:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 May 2010 17:41:09 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Core UDP vs TCP : Redux Thread-Index: AcrxUkHvG1/UxBUnR1uNWaNBmUljbAAACa5Q References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com><17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com> From: "Simpson, Robby (GE Energy Services)" To: "Carsten Bormann" , "Zach Shelby" X-OriginalArrivalTime: 11 May 2010 21:41:49.0425 (UTC) FILETIME=[C2F9E610:01CAF152] Cc: core@ietf.org Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 21:42:04 -0000 Carsten, For clarification, what are your metrics for "reinventing TCP"? Multiple packets? Flow control? Congestion control? Thanks, Robby =20 -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Tuesday, May 11, 2010 5:38 PM To: Zach Shelby Cc: core@ietf.org Subject: Re: [core] Core UDP vs TCP : Redux On May 11, 2010, at 23:06, Zach Shelby wrote: > I have also already found TCP to be really awkward (No WG chair hat) The reason why I thought it would be a good idea to have TCP as an option in there was to fend off tendencies to reinvent TCP on top of UDP. If we can agree not to do that, I'm certainly fine with throwing out TCP. But once people do start to argue for reinventing TCP, we'll need to put the original back in. (Rationale: 1) DTSTTCPW (Do the simplest thing that could possibly work.) 2) We can always put TCP back in later in a v2 of the protocol, once we know more about the applications and their real requirements from actual deployments and whether having TCP is a good thing.) Gruesse, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Tue May 11 14:53:27 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A8F43A6802 for ; Tue, 11 May 2010 14:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.72 X-Spam-Level: X-Spam-Status: No, score=-4.72 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_20=-0.74, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ovSWLiHegeJ for ; Tue, 11 May 2010 14:53:26 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 882963A682E for ; Tue, 11 May 2010 14:53:25 -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 o4BLr1qJ021792; Tue, 11 May 2010 23:53:02 +0200 (CEST) Received: from [192.168.217.101] (p5489F409.dip.t-dialin.net [84.137.244.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 8E664DF8D; Tue, 11 May 2010 23:53:01 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Tue, 11 May 2010 23:52:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com><17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com> To: "Simpson, Robby (GE Energy Services)" X-Mailer: Apple Mail (2.1078) Cc: core@ietf.org Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 21:53:27 -0000 On May 11, 2010, at 23:41, Simpson, Robby (GE Energy Services) wrote: > Carsten, >=20 > For clarification, what are your metrics for "reinventing TCP"? >=20 > Multiple packets? Flow control? Congestion control? Yes :-) I don't have a problem with a multi-packet exchange to effect a = transfer. But we should be very careful with what kind of state we expect the two = sides to build/maintain/keep for this. Running a congestion control algorithm instead of a simple lock-step = mechanism sounds wrong. Having any kind of flow control beyond the lock-step (e.g., windows) = sounds wrong. =20 Having to establish a "session", "connection", "association" to effect = the transfer sounds wrong. But I don't think of these as metrics, so if a good way to have these = multi-packet exchanges is proposed, let's look at the impact on nodes = and network instead of trying to decide whether it is too much like TCP. What do you think? Gruesse, Carsten From hgs@cs.columbia.edu Tue May 11 15:02:15 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C95E3A6BEB for ; Tue, 11 May 2010 15:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.175 X-Spam-Level: X-Spam-Status: No, score=-5.175 tagged_above=-999 required=5 tests=[AWL=-1.176, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ONzTfbFQZn9 for ; Tue, 11 May 2010 15:02:14 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id CF7863A6AA5 for ; Tue, 11 May 2010 15:02:13 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o4BM21N4017206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 11 May 2010 18:02:02 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com> Date: Tue, 11 May 2010 18:02:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9BB682AE-86C2-4054-8758-8E7C6AD10807@cs.columbia.edu> References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com> To: Zach Shelby X-Mailer: Apple Mail (2.1078) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Cc: "core@ietf.org" Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 22:02:15 -0000 This works as long as you can guarantee that the response is < MTU. = Doing your own fragmentation is a pain (you are then well on your way to = re-inventing TCP) and relying on IP fragmentation is unlikely to work in = "challenged" networks. Thus, these applicability limitations need to be = spelled out very clearly. This also has security implications - = obviously, TLS is out without TCP, but anything involving certificates = is also likely to be difficult to carry. Henning On May 11, 2010, at 5:06 PM, Zach Shelby wrote: > +1 >=20 > Through writing a few revisions of these specs, I have also already = found TCP to be really awkward. And the TCP negotiation discussions at = the mike in Anaheim made me even more skeptical. Tom is right, if you = need TCP then just use HTTP ;-)=20 >=20 > Zach=20 >=20 > On May 11, 2010, at 18:49 , Thomas Herbst wrote: >=20 >> After the discussion in Anaheim, I'm surprised that we need yet = another revisit to UDP and TCP for CORE. >>=20 >> The Right Solution(tm) might well be to fix TCP such that it doesn't = lose its brains every time you drop a packet, and we could end up with = an end-to-end system where constrained devices might reasonably provide = services to normal hosts in the regular Internet, However, transport = work is out of scope for this WG. >>=20 >> The second most right solution would be to implement CORE with a = reliable UDP protocol, as is done in much of the draft. The "optional" = TCP portions of the draft are mostly increased complexity for no added = benefit. If a device is capable of running TCP and the network it works = on is capable of supporting TCP, you should just open a connection to = Port 80 and use HTTP (or the TCP port/protocol of your choice). There = are many protocols a host MAY implement and it is not appropriate for = the draft to enumerate them. =20 >>=20 >> Let's remove all of the sections related to TCP in the draft. >>=20 >> tom >>=20 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 > --=20 > Zach Shelby, Head of Research, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 From therbst@silverspringnet.com Tue May 11 18:11:58 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 475103A6852 for ; Tue, 11 May 2010 18:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ey9AWq1qtc1L for ; Tue, 11 May 2010 18:11:56 -0700 (PDT) Received: from bachelor.silverspringnet.com (bachelor.silverspringnet.com [69.36.245.73]) by core3.amsl.com (Postfix) with ESMTP id 91F203A679C for ; Tue, 11 May 2010 18:11:56 -0700 (PDT) Received: from IT-EXCA-01.silverspringnet.com ([10.200.1.60]) by bachelor.silverspringnet.com (8.14.1/8.13.8) with ESMTP id o4C1BQoX027522; Tue, 11 May 2010 18:11:26 -0700 (PDT) Received: from IT-EXMB-01.silverspringnet.com ([fe80::b81e:2d5b:d263:6c44]) by IT-EXCA-01.silverspringnet.com ([::1]) with mapi; Tue, 11 May 2010 18:11:26 -0700 From: Thomas Herbst To: Henning Schulzrinne , Zach Shelby Date: Tue, 11 May 2010 18:11:25 -0700 Thread-Topic: [core] Core UDP vs TCP : Redux Thread-Index: AcrxVZiE2m9Oel2WT0WLurwy4pc6GwAGHQcg Message-ID: <485AF6ECE8D1954D996771CC49E996FDC0FE2568@IT-EXMB-01.silverspringnet.com> References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com> <9BB682AE-86C2-4054-8758-8E7C6AD10807@cs.columbia.edu> In-Reply-To: <9BB682AE-86C2-4054-8758-8E7C6AD10807@cs.columbia.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "core@ietf.org" Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 01:11:58 -0000 On TCP vs UDP - we need to pick one. Deciding to use both UDP and TCP is j= ust not making a decision. =20 You expect people who didn't include enough memory in their devices to impl= ement TCP to do both UDP and TCP?=20 On security, is there a problem w/ DTLS? tom -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Tuesday, May 11, 2010 3:02 PM To: Zach Shelby Cc: Thomas Herbst; core@ietf.org Subject: Re: [core] Core UDP vs TCP : Redux This works as long as you can guarantee that the response is < MTU. Doing y= our own fragmentation is a pain (you are then well on your way to re-invent= ing TCP) and relying on IP fragmentation is unlikely to work in "challenged= " networks. Thus, these applicability limitations need to be spelled out ve= ry clearly. This also has security implications - obviously, TLS is out wit= hout TCP, but anything involving certificates is also likely to be difficul= t to carry. Henning On May 11, 2010, at 5:06 PM, Zach Shelby wrote: > +1 >=20 > Through writing a few revisions of these specs, I have also already found= TCP to be really awkward. And the TCP negotiation discussions at the mike = in Anaheim made me even more skeptical. Tom is right, if you need TCP then = just use HTTP ;-)=20 >=20 > Zach=20 >=20 > On May 11, 2010, at 18:49 , Thomas Herbst wrote: >=20 >> After the discussion in Anaheim, I'm surprised that we need yet another = revisit to UDP and TCP for CORE. >>=20 >> The Right Solution(tm) might well be to fix TCP such that it doesn't los= e its brains every time you drop a packet, and we could end up with an end-= to-end system where constrained devices might reasonably provide services t= o normal hosts in the regular Internet, However, transport work is out of = scope for this WG. >>=20 >> The second most right solution would be to implement CORE with a reliabl= e UDP protocol, as is done in much of the draft. The "optional" TCP portio= ns of the draft are mostly increased complexity for no added benefit. If a = device is capable of running TCP and the network it works on is capable of = supporting TCP, you should just open a connection to Port 80 and use HTTP (= or the TCP port/protocol of your choice). There are many protocols a host = MAY implement and it is not appropriate for the draft to enumerate them. =20 >>=20 >> Let's remove all of the sections related to TCP in the draft. >>=20 >> tom >>=20 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 > --=20 > Zach Shelby, Head of Research, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 From Colin.OFlynn@atmel.com Tue May 11 18:18:11 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10C953A695B for ; Tue, 11 May 2010 18:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXeP6OvrLufE for ; Tue, 11 May 2010 18:18:07 -0700 (PDT) Received: from sjogate2.atmel.com (newsmtp5.atmel.com [204.2.163.5]) by core3.amsl.com (Postfix) with ESMTP id B6CF23A67B3 for ; Tue, 11 May 2010 18:18:07 -0700 (PDT) Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id o4C1Fb0U013681; Tue, 11 May 2010 18:15:39 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAF170.E4DE9240" Date: Tue, 11 May 2010 19:13:32 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Core UDP vs TCP : Redux Thread-Index: AcrxVZiE2m9Oel2WT0WLurwy4pc6GwAGHQcgAACSguw= References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com><17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><9BB682AE-86C2-4054-8758-8E7C6AD10807@cs.columbia.edu> <485AF6ECE8D1954D996771CC49E996FDC0FE2568@IT-EXMB-01.silverspringnet.com> From: "Oflynn, Colin" To: "Thomas Herbst" , "Henning Schulzrinne" , "Zach Shelby" Cc: core@ietf.org Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 01:18:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAF170.E4DE9240 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, >This works as long as you can guarantee that the response is < MTU. Which the current draft does. If we go the UDP route, I think we need to = add support for larger packets through some simple fragmentation. You won't need such large packets often! So it doesn't have to be very = efficient, just every so often you need to transmit a large frame for a = file load, encryption, etc.=20 Regards, -Colin -----Original Message----- From: core-bounces@ietf.org on behalf of Thomas Herbst Sent: Wed 12/05/2010 02:11 To: Henning Schulzrinne; Zach Shelby Cc: core@ietf.org Subject: Re: [core] Core UDP vs TCP : Redux =20 On TCP vs UDP - we need to pick one. Deciding to use both UDP and TCP = is just not making a decision. =20 You expect people who didn't include enough memory in their devices to = implement TCP to do both UDP and TCP?=20 On security, is there a problem w/ DTLS? tom -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Tuesday, May 11, 2010 3:02 PM To: Zach Shelby Cc: Thomas Herbst; core@ietf.org Subject: Re: [core] Core UDP vs TCP : Redux This works as long as you can guarantee that the response is < MTU. = Doing your own fragmentation is a pain (you are then well on your way to = re-inventing TCP) and relying on IP fragmentation is unlikely to work in = "challenged" networks. Thus, these applicability limitations need to be = spelled out very clearly. This also has security implications - = obviously, TLS is out without TCP, but anything involving certificates = is also likely to be difficult to carry. Henning On May 11, 2010, at 5:06 PM, Zach Shelby wrote: > +1 >=20 > Through writing a few revisions of these specs, I have also already = found TCP to be really awkward. And the TCP negotiation discussions at = the mike in Anaheim made me even more skeptical. Tom is right, if you = need TCP then just use HTTP ;-)=20 >=20 > Zach=20 >=20 > On May 11, 2010, at 18:49 , Thomas Herbst wrote: >=20 >> After the discussion in Anaheim, I'm surprised that we need yet = another revisit to UDP and TCP for CORE. >>=20 >> The Right Solution(tm) might well be to fix TCP such that it doesn't = lose its brains every time you drop a packet, and we could end up with = an end-to-end system where constrained devices might reasonably provide = services to normal hosts in the regular Internet, However, transport = work is out of scope for this WG. >>=20 >> The second most right solution would be to implement CORE with a = reliable UDP protocol, as is done in much of the draft. The "optional" = TCP portions of the draft are mostly increased complexity for no added = benefit. If a device is capable of running TCP and the network it works = on is capable of supporting TCP, you should just open a connection to = Port 80 and use HTTP (or the TCP port/protocol of your choice). There = are many protocols a host MAY implement and it is not appropriate for = the draft to enumerate them. =20 >>=20 >> Let's remove all of the sections related to TCP in the draft. >>=20 >> tom >>=20 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 > --=20 > Zach Shelby, Head of Research, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=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 ------_=_NextPart_001_01CAF170.E4DE9240 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [core] Core UDP vs TCP : Redux

Hello,

>This works as long as you can guarantee that the response is < = MTU.

Which the current draft does. If we go the UDP route, I think we need to = add support for larger packets through some simple fragmentation.

You won't need such large packets often! So it doesn't have to be very = efficient, just every so often you need to transmit a large frame for a = file load, encryption, etc.

Regards,

  -Colin


-----Original Message-----
From: core-bounces@ietf.org on behalf of Thomas Herbst
Sent: Wed 12/05/2010 02:11
To: Henning Schulzrinne; Zach Shelby
Cc: core@ietf.org
Subject: Re: [core] Core UDP vs TCP : Redux

On TCP vs UDP - we need to pick one.  Deciding to use both UDP and = TCP is just not making a decision. 

You expect people who didn't include enough memory in their devices to = implement TCP to do both UDP and TCP?

On security, is there a problem w/ DTLS?

tom

-----Original Message-----
From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
Sent: Tuesday, May 11, 2010 3:02 PM
To: Zach Shelby
Cc: Thomas Herbst; core@ietf.org
Subject: Re: [core] Core UDP vs TCP : Redux

This works as long as you can guarantee that the response is < MTU. = Doing your own fragmentation is a pain (you are then well on your way to = re-inventing TCP) and relying on IP fragmentation is unlikely to work in = "challenged" networks. Thus, these applicability limitations = need to be spelled out very clearly. This also has security implications = - obviously, TLS is out without TCP, but anything involving certificates = is also likely to be difficult to carry.

Henning

On May 11, 2010, at 5:06 PM, Zach Shelby wrote:

> +1
>
> Through writing a few revisions of these specs, I have also already = found TCP to be really awkward. And the TCP negotiation discussions at = the mike in Anaheim made me even more skeptical. Tom is right, if you = need TCP then just use HTTP ;-)
>
> Zach
>
> On May 11, 2010, at 18:49 , Thomas Herbst wrote:
>
>> After the discussion in Anaheim, I'm surprised that we need yet = another revisit to UDP and TCP for CORE.
>>
>> The Right Solution(tm) might well be to fix TCP such that it = doesn't lose its brains every time you drop a packet, and we could end = up with an end-to-end system where constrained devices might reasonably = provide services to normal hosts in the regular Internet,  However, = transport work is out of scope for this WG.
>>
>> The second most right solution would be to implement CORE with = a reliable UDP protocol, as is done in much of the draft.  The = "optional" TCP portions of the draft are mostly increased = complexity for no added benefit. If a device is capable of running TCP = and the network it works on is capable of supporting TCP, you should = just open a connection to Port 80 and use HTTP (or the TCP port/protocol = of your choice).  There are many protocols a host MAY implement and = it is not appropriate for the draft to enumerate them. 
>>
>> Let's remove all of the sections related to TCP in the = draft.
>>
>> tom
>>
>>
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/= mailman/listinfo/core
>
> --
> Zach Shelby, Head of Research, Sensinode Ltd.
> http://zachshelby.org  - = My blog "On the Internet of Things"
> http://6lowpan.net - My book = "6LoWPAN: The Wireless Embedded Internet"
> Mobile: +358 40 7796297
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/= mailman/listinfo/core
>

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

------_=_NextPart_001_01CAF170.E4DE9240-- From Colin.OFlynn@atmel.com Tue May 11 18:31:53 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52C173A6AB5 for ; Tue, 11 May 2010 18:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6hE-nNuhC74 for ; Tue, 11 May 2010 18:31:51 -0700 (PDT) Received: from sjogate2.atmel.com (newsmtp5.atmel.com [204.2.163.5]) by core3.amsl.com (Postfix) with ESMTP id 5E98D3A67AF for ; Tue, 11 May 2010 18:31:46 -0700 (PDT) Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id o4C1TIql014569; Tue, 11 May 2010 18:29:18 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAF172.CE33AE2C" Date: Tue, 11 May 2010 19:31:12 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] RE Fwd: New Version Notification fordraft-shelby-core-coap-01 Thread-Index: AcrxT5Zih37J+B37SPCqojfHJ9fKyAAIXqk8 References: <595F6A4B-511C-439C-A0C2-43C10998B1FA@sensinode.com> From: "Oflynn, Colin" To: "Zach Shelby" , Cc: core Subject: Re: [core] RE Fwd: New Version Notification fordraft-shelby-core-coap-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 01:31:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAF172.CE33AE2C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, >I could envision having e.g. a Subscription-interval Option in addition = to Subscription-lifetime. More buttons, people love buttons ;-) In all seriousness though: I think this can also be solved with REST = itself in a way. Perhaps elements that you can subscribe to have some = information you can get. They might have like a "subscribe options" that = lists various information & options. When you do the subscribe you use = those options as part of the subscribe message. So for instance you get the "subscription options" for a node, which = indicates it's "notify timebase" is in increments of 15 seconds. The = default is to notify at minimum every 4 timebases (ie: 60 seconds). Then = when you subscribe, you ask to subscribe with your minimum of 10 = timebases (150 seconds).=20 I would suggest keeping it as a general as possible. In this case you = have 'subscription options' a subscriber reads, then uses that to pass = some specific data/elements. We could define at as a start the "notify = timebase", "minimum notify time", and "maximum notify time". But you can = extend that later or move it to another draft... What do you think? Regards, -Colin -----Original Message----- From: core-bounces@ietf.org on behalf of Zach Shelby Sent: Tue 11/05/2010 22:16 To: matthieu.vial@fr.non.schneider-electric.com Cc: core Subject: Re: [core] RE Fwd: New Version Notification = fordraft-shelby-core-coap-01 =20 Hi, On May 11, 2010, at 11:11 , matthieu.vial@fr.non.schneider-electric.com = wrote: > Hi, >=20 > First of all congratulations for your work. >=20 > I have few comments about the subscribe/notify mechanism and the = resource directory. >=20 > As far as I understand the specification, a client will receive its = notifications on the same port as the subscribe request. As an = implementer I would like to handle all asynchronous notifications on a = dedicated port and perform synchronous GET, POST, PUT, DELETE on a = different port. The current specification allows to do this for the UDP = binding as it is connectionless but for the TCP binding I must keep the = connection I used for the subscribe request alive. Just tell me if it is = not the good approach because I know TCP is not a major concern for = COAP. Argh, yet again some problems with TCP. Surely a way to make that work = of course, but it would need more text...=20 >=20 > How can I define a fine grained notification? Is it completlty left to = the application so I must define a message format to describe precise = notification rules and include this message into the subscribe payload = or will you provide a framework later? Typical notification options = would be: minimal delay between 2 notifications to prevent from = overwhelming the network, an increment as the minimal change for noisy = inputs, a maximum delay between notifications for periodic notifications = and keep alive signals ... For sure MIN_NOTIFY_INTERVAL and MAX_NOTIFY_INTERVAL variables should be = added, maybe with a recommended default. With regards to having more = knobs to turn here, I could envision having e.g. a Subscription-interval = Option in addition to Subscription-lifetime. Now that said, anything = more complicated is probably out of scope for CoRE. At least the = transfer protocol shouldn't involve itself with data thresholds etc. =20 >=20 > How do you manage the lifetime of resources in the resource directory? = The /.well-known/resources will probably not change very often so a = simple subscription/notification would be useless. Moreover a periodic = POST from devices seems not very efficient because the link format is = quite verbose to be repeated without a real need. We could reuse the = cacheability of COAP to avoid large data transfer but only the get = method is cacheable. That means the directory agent should have a list = of all devices. This imply some kind of registration mechanism to the = directory. This is a good discussion to have. At least the Etag can help here to = prevent all data from being sent each time, and even a subscription = could be useful in some cases. What I also had in mind was that a = directory can act as a RESTful repository which can store the = descriptions of others. In the end here we have to make an analysis of = real resource discovery scenarios, how they work with these mechanisms, = and then see if we're really missing something. Someone should write a = draft like that by the way...=20 Zach >=20 > Best regards, > Matthieu VIAL >=20 >=20 > Zach Shelby >=20 >=20 >=20 >=20 > Zach Shelby =20 > Envoy=E9 par : core-bounces@ietf.org > 10/05/2010 09:19 >=20 > > A > > core > > cc > > > Objet > > [core] Fwd: New Version Notification for draft-shelby-core-coap-01 > >=20 > Hi, >=20 > Version -01 of draft-shelby-core-coap is now available: >=20 > http://www.ietf.org/id/draft-shelby-core-coap-01.txt >=20 > This has gone through a lot of little revisions after Anaheim based on = the list discussions, comments on -00, discussions with the chairs and = quite a bit of implementation validation. We hope -01 fixes most of the = issues and provides the main improvements requested so far. My goal is = to keep this stable for a longer time to give people a chance to get = some implementation experience (have heard of 5 implementations so far). = Next update planned before the Maastricht cutoff. >=20 > Here is a summary of the major changes in -01: >=20 > - Method names now GET, PUT, POST, DELETE > - Unified the message header and added a notify message type. > - Completed the SUBMIT method and option > - Improved the option TLV header, added Etag, Date and = Subscription-lifetime Options > - Added a Magic byte header for TCP and packed UDP > - Wrote initial subscription, discovery and proxy sections > - Plenty of simplification, optimization and bug fixes=20 >=20 > And of course still plenty of TODOs, the main ones are: >=20 > - HTTP Mapping > - Proxying > - Complete Examples section=20 > - Define the TLS and DTLS bindings (help!)=20 >=20 > Zach, Brian and Don >=20 > Begin forwarded message: >=20 > > From: IETF I-D Submission Tool > > Date: May 10, 2010 10:05:25 GMT+03:00 > > To: zach@sensinode.com > > Cc: brian@skyfoundry.com,d.sturek@att.net > > Subject: New Version Notification for draft-shelby-core-coap-01=20 > >=20 > >=20 > > A new version of I-D, draft-shelby-core-coap-01.txt has been = successfully submitted by Zach Shelby and posted to the IETF repository. > >=20 > > Filename: draft-shelby-core-coap > > Revision: 01 > > Title: Constrained Application Protocol (CoAP) > > Creation_date: 2010-05-10 > > WG ID: Independent Submission > > Number_of_pages: 33 > >=20 > > Abstract: > > This document specifies the Constrained Application Protocol (CoAP), > > a specialized transfer protocol for use with constrained networks = and > > nodes for machine-to-machine applications such as smart energy and > > building automation. These constrained nodes often have 8-bit > > microcontrollers with small amounts of ROM and RAM, while networks > > such as 6LoWPAN often have high packet error rates and typical > > throughput of 10s of kbps. CoAP provides request/reply and > > subscribe/notify interaction models between appliciation end-points, > > supports built-in resource discovery, and includes key web concepts > > such as URIs and RESTful methods. CoAP easily translates to HTTP = for > > integration with the web while meeting specialized requirements such > > as multicast support, very low overhead and simplicity for > > constrained environments. > >=20 > >=20 > >=20 > > The IETF Secretariat. > >=20 > >=20 >=20 > --=20 > Zach Shelby, Head of Research, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > ______________________________________________________________________ >=20 --=20 Zach Shelby, Head of Research, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------_=_NextPart_001_01CAF172.CE33AE2C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [core] RE Fwd: New Version Notification = fordraft-shelby-core-coap-01

Hello,

>I could envision having e.g. a Subscription-interval Option in = addition to Subscription-lifetime.

More buttons, people love buttons ;-)

In all seriousness though: I think this can also be solved with REST = itself in a way. Perhaps elements that you can subscribe to have some = information you can get. They might have like a "subscribe = options" that lists various information & options. When you do = the subscribe you use those options as part of the subscribe = message.

So for instance you get the "subscription options" for a node, = which indicates it's "notify timebase" is in increments of 15 = seconds. The default is to notify at minimum every 4 timebases (ie: 60 = seconds). Then when you subscribe, you ask to subscribe with your = minimum of 10 timebases (150 seconds).

I would suggest keeping it as a general as possible. In this case you = have 'subscription options' a subscriber reads, then uses that to pass = some specific data/elements. We could define at as a start the = "notify timebase", "minimum notify time", and = "maximum notify time". But you can extend that later or move = it to another draft... What do you think?

Regards,

  -Colin

-----Original Message-----
From: core-bounces@ietf.org on behalf of Zach Shelby
Sent: Tue 11/05/2010 22:16
To: matthieu.vial@fr.non.schneider-electric.com
Cc: core
Subject: Re: [core] RE Fwd: New Version Notification = fordraft-shelby-core-coap-01

Hi,

On May 11, 2010, at 11:11 , matthieu.vial@fr.non.schneider-electric.com = wrote:

> Hi,
>
> First of all congratulations for your work.
>
> I have few comments about the subscribe/notify mechanism and the = resource directory.
>
> As far as I understand the specification, a client will receive its = notifications on the same port as the subscribe request. As an = implementer I would like to handle all asynchronous notifications on a = dedicated port and perform synchronous GET, POST, PUT, DELETE on a = different port. The current specification allows to do this for the UDP = binding as it is connectionless but for the TCP binding I must keep the = connection I used for the subscribe request alive. Just tell me if it is = not the good approach because I know TCP is not a major concern for = COAP.

Argh, yet again some problems with TCP. Surely a way to make that work = of course, but it would need more text...

>
> How can I define a fine grained notification? Is it completlty left = to the application so I must define a message format to describe precise = notification rules and include this message into the subscribe payload = or will you provide a framework later? Typical notification options = would be: minimal delay between 2 notifications to prevent from = overwhelming the network, an increment as the minimal change for noisy = inputs, a maximum delay between notifications for periodic notifications = and keep alive signals ...

For sure MIN_NOTIFY_INTERVAL and MAX_NOTIFY_INTERVAL variables should be = added, maybe with a recommended default. With regards to having more = knobs to turn here, I could envision having e.g. a Subscription-interval = Option in addition to Subscription-lifetime. Now that said, anything = more complicated is probably out of scope for CoRE. At least the = transfer protocol shouldn't involve itself with data thresholds = etc. 

>
> How do you manage the lifetime of resources in the resource = directory? The /.well-known/resources will probably not change very = often so a simple subscription/notification would be useless. Moreover a = periodic POST from devices seems not very efficient because the link = format is quite verbose to be repeated without a real need. We could = reuse the cacheability of COAP to avoid large data transfer but only the = get method is cacheable. That means the directory agent should have a = list of all devices. This imply some kind of registration mechanism to = the directory.

This is a good discussion to have. At least the Etag can help here to = prevent all data from being sent each time, and even a subscription = could be useful in some cases. What I also had in mind was that a = directory can act as a RESTful repository which can store the = descriptions of others. In the end here we have to make an analysis of = real resource discovery scenarios, how they work with these mechanisms, = and then see if we're really missing something. Someone should write a = draft like that by the way...

Zach

>
> Best regards,
> Matthieu VIAL
>
>
> <graycol.gif>Zach Shelby <zach@sensinode.com>
>
>
>
>
> Zach Shelby <zach@sensinode.com>
> Envoy=E9 par : core-bounces@ietf.org
> 10/05/2010 09:19
>
> <ecblank.gif>
> A
> <ecblank.gif>
> core <core@ietf.org>
> <ecblank.gif>
> cc
> <ecblank.gif>
> <ecblank.gif>
> Objet
> <ecblank.gif>
> [core] Fwd: New Version Notification for = draft-shelby-core-coap-01
> <ecblank.gif> <ecblank.gif>
>
> Hi,
>
> Version -01 of draft-shelby-core-coap is now available:
>
> http://www.= ietf.org/id/draft-shelby-core-coap-01.txt
>
> This has gone through a lot of little revisions after Anaheim based = on the list discussions, comments on -00, discussions with the chairs = and quite a bit of implementation validation. We hope -01 fixes most of = the issues and provides the main improvements requested so far. My goal = is to keep this stable for a longer time to give people a chance to get = some implementation experience (have heard of 5 implementations so far). = Next update planned before the Maastricht cutoff.
>
> Here is a summary of the major changes in -01:
>
> - Method names now GET, PUT, POST, DELETE
> - Unified the message header and added a notify message type.
> - Completed the SUBMIT method and option
> - Improved the option TLV header, added Etag, Date and = Subscription-lifetime Options
> - Added a Magic byte header for TCP and packed UDP
> - Wrote initial subscription, discovery and proxy sections
> - Plenty of simplification, optimization and bug fixes
>
> And of course still plenty of TODOs, the main ones are:
>
> - HTTP Mapping
> - Proxying
> - Complete Examples section
> - Define the TLS and DTLS bindings (help!)
>
> Zach, Brian and Don
>
> Begin forwarded message:
>
> > From: IETF I-D Submission Tool = <idsubmission@ietf.org>
> > Date: May 10, 2010 10:05:25 GMT+03:00
> > To: zach@sensinode.com
> > Cc: brian@skyfoundry.com,d.sturek@att.net
> > Subject: New Version Notification for = draft-shelby-core-coap-01
> >
> >
> > A new version of I-D, draft-shelby-core-coap-01.txt has been = successfully submitted by Zach Shelby and posted to the IETF = repository.
> >
> > Filename:     draft-shelby-core-coap
> > Revision:     01
> > Title:        Constrained = Application Protocol (CoAP)
> > Creation_date:        = 2010-05-10
> > WG ID:        Independent = Submission
> > Number_of_pages: 33
> >
> > Abstract:
> > This document specifies the Constrained Application Protocol = (CoAP),
> > a specialized transfer protocol for use with constrained = networks and
> > nodes for machine-to-machine applications such as smart energy = and
> > building automation.  These constrained nodes often have = 8-bit
> > microcontrollers with small amounts of ROM and RAM, while = networks
> > such as 6LoWPAN often have high packet error rates and = typical
> > throughput of 10s of kbps.  CoAP provides request/reply = and
> > subscribe/notify interaction models between appliciation = end-points,
> > supports built-in resource discovery, and includes key web = concepts
> > such as URIs and RESTful methods.  CoAP easily translates = to HTTP for
> > integration with the web while meeting specialized = requirements such
> > as multicast support, very low overhead and simplicity for
> > constrained environments.
> >
> >
> >
> > The IETF Secretariat.
> >
> >
>
> --
> Zach Shelby, Head of Research, Sensinode Ltd.
> http://zachshelby.org  - = My blog "On the Internet of Things"
> http://6lowpan.net - My book = "6LoWPAN: The Wireless Embedded Internet"
> Mobile: +358 40 7796297
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/= mailman/listinfo/core
>
> = ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security = System.
> = ______________________________________________________________________ >

--
Zach Shelby, Head of Research, Sensinode Ltd.
http://zachshelby.org  - My = blog "On the Internet of Things"
http://6lowpan.net - My book = "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

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

------_=_NextPart_001_01CAF172.CE33AE2C-- From hgs@cs.columbia.edu Tue May 11 18:41:24 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8902A3A6C18 for ; Tue, 11 May 2010 18:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X20WoD6NqcHH for ; Tue, 11 May 2010 18:41:23 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 7B9A03A6AC3 for ; Tue, 11 May 2010 18:41:23 -0700 (PDT) Received: from new-host-3.home (pool-173-54-225-147.nwrknj.fios.verizon.net [173.54.225.147]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o4C1f9tE020025 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 11 May 2010 21:41:10 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: Date: Tue, 11 May 2010 21:41:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <49C9CCBE-B92F-43F0-9FB8-11DA83B4B075@cs.columbia.edu> References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com><17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><9BB682AE-86C2-4054-8758-8E7C6AD10807@cs.columbia.edu> <485AF6ECE8D1954D996771CC49E996FDC0FE2568@IT-EXMB-01.silverspringnet.com> To: "Oflynn, Colin" X-Mailer: Apple Mail (2.1078) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Cc: core@ietf.org Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 01:41:24 -0000 All I can say is that a lot of people thought that when we designed SIP = - and I think it's clear that the assumption turned out to be wrong = enough to cause grief. Doesn't mean that it will here, but I'd suggest = some realization that our collective crystal ball is a bit fuzzy. = Protocols, particularly successful ones, tend to get pushed to their = limits and beyond. (If you want, DNS, tftp and RSVP are other examples = where one could argue that this has caused significant pain.) Just to spin this direction forward: If you want fragmentation and = reliability, you have to be able to ack request individual fragments, as = you'll otherwise end up retransmitting the whole frame if one fragment = is lost, plus a total length field (so that the sender knows whether to = expect more fragments). Not overwhelming complexity, but probably = doubles the header size. Henning On May 11, 2010, at 9:13 PM, Oflynn, Colin wrote: > Hello, >=20 > >This works as long as you can guarantee that the response is < MTU. >=20 > Which the current draft does. If we go the UDP route, I think we need = to add support for larger packets through some simple fragmentation. >=20 > You won't need such large packets often! So it doesn't have to be very = efficient, just every so often you need to transmit a large frame for a = file load, encryption, etc. From dotis@mail-abuse.org Tue May 11 19:13:47 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C513428C0EF for ; Tue, 11 May 2010 19:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.823 X-Spam-Level: X-Spam-Status: No, score=-3.823 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEjmEJP+ZSUT for ; Tue, 11 May 2010 19:13:46 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 9230028C0EA for ; Tue, 11 May 2010 19:13:33 -0700 (PDT) Received: from sjc-office-nat-223.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 5B704A944FC for ; Wed, 12 May 2010 02:13:17 +0000 (UTC) Message-ID: <4BEA0EBD.8020502@mail-abuse.org> Date: Tue, 11 May 2010 19:13:17 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: core@ietf.org References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com><17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 02:13:48 -0000 On 5/11/10 2:52 PM, Carsten Bormann wrote: > On May 11, 2010, at 23:41, Simpson, Robby (GE Energy Services) wrote: > >> Carsten, >> >> For clarification, what are your metrics for "reinventing TCP"? >> >> Multiple packets? Flow control? Congestion control? >> > Yes :-) > > I don't have a problem with a multi-packet exchange to effect a transfer. > But we should be very careful with what kind of state we expect the two sides to build/maintain/keep for this. > Running a congestion control algorithm instead of a simple lock-step mechanism sounds wrong. > A byte stream is not a good approach in resource limited environments. However, framed data objects should not be exchanged in lock-step fashion either. By not requiring ordered delivery, offset with an ability for direct placement, buffering can be minimal. TLV framed exchanges can be regulated by chunks containing acks, credits with noted gaps and dups, for example. Whether this information is used to establish reliable delivery should be left to the application. The underlying transport can be kept simple, with perhaps negotiated dependence on whether the sender is to retry non-critical data. The protocol should be able to avoid congestion without being limited to lock-step exchanges as well. > Having any kind of flow control beyond the lock-step (e.g., windows) sounds wrong. > Disagree. These networks might be slow and may make use of multi-casting. Information exchange is not best done in lock-step, nor as a byte steam. > Having to establish a "session", "connection", "association" to effect the transfer sounds wrong. > Both security, performance, and reliability benefit by having more than just TFTP style exchanges. > But I don't think of these as metrics, so if a good way to have these multi-packet exchanges is proposed, let's look at the impact on nodes and network instead of trying to decide whether it is too much like TCP. > > What do you think? > Framed data objects with selective acks can make the best use of limited resources and slow networks, where TCP does not fit this mode of operation. It should also be noted that TLS remains possible without TCP. -Doug From L.Wood@surrey.ac.uk Tue May 11 23:26:19 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D76163A6C8F for ; Tue, 11 May 2010 23:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.788 X-Spam-Level: X-Spam-Status: No, score=-4.788 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZklfwU40Ztkt for ; Tue, 11 May 2010 23:26:18 -0700 (PDT) Received: from mail72.messagelabs.com (mail72.messagelabs.com [193.109.255.147]) by core3.amsl.com (Postfix) with ESMTP id 06E373A6C84 for ; Tue, 11 May 2010 23:25:47 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-4.tower-72.messagelabs.com!1273645536!11479969!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.35] Received: (qmail 13545 invoked from network); 12 May 2010 06:25:36 -0000 Received: from unknown (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-4.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 12 May 2010 06:25:36 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.69]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Wed, 12 May 2010 07:25:36 +0100 From: To: Date: Wed, 12 May 2010 07:25:33 +0100 Thread-Topic: [core] Core UDP vs TCP : Redux Thread-Index: Acrxm+5H63xOB4WWRQe6XFBsj5HrwQ== Message-ID: <0BCE0692-693C-4971-B10A-A94F5FD138CD@surrey.ac.uk> References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com><17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: core@ietf.org, L.Wood@surrey.ac.uk Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 06:26:20 -0000 On 11 May 2010, at 22:52, Carsten Bormann wrote: > I don't have a problem with a multi-packet exchange to effect a transfer. > But we should be very careful with what kind of state we expect the two s= ides to build/maintain/keep for this. > Running a congestion control algorithm instead of a simple lock-step mech= anism sounds wrong. > Having any kind of flow control beyond the lock-step (e.g., windows) soun= ds wrong. =20 > Having to establish a "session", "connection", "association" to effect th= e transfer sounds wrong. >=20 > But I don't think of these as metrics, so if a good way to have these mul= ti-packet exchanges is proposed, let's look at the impact on nodes and netw= ork instead of trying to decide whether it is too much like TCP. Some sort of connection is needed to deal with multi-packet exchanges. Sounds like the basic principles that went into designing Saratoga for UDO: http://tools.ietf.org/html/draft-wood-tsvwg-saratoga-05 http://info.ee.surrey.ac.uk/Personal/L.Wood/dtn/saratoga L. Lloyd Wood L.Wood@surrey.ac.uk http://sat-net.com/L.Wood From Colin.OFlynn@atmel.com Wed May 12 05:03:50 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 935943A68B9 for ; Wed, 12 May 2010 05:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P86kjqDsfeZY for ; Wed, 12 May 2010 05:03:49 -0700 (PDT) Received: from sjogate2.atmel.com (newsmtp5.atmel.com [204.2.163.5]) by core3.amsl.com (Postfix) with ESMTP id 4FE813A685B for ; Wed, 12 May 2010 05:03:43 -0700 (PDT) Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id o4CC1GgV005265; Wed, 12 May 2010 05:01:18 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAF1CB.178444A0" Date: Wed, 12 May 2010 06:03:10 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Core UDP vs TCP : Redux Thread-Index: Acrxm+5H63xOB4WWRQe6XFBsj5HrwQALYLeO References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com><17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com> <0BCE0692-693C-4971-B10A-A94F5FD138CD@surrey.ac.uk> From: "Oflynn, Colin" To: , Cc: core@ietf.org Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 12:03:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAF1CB.178444A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Do the limitations of a lock-step transfer matter in our limited = networks?=20 I see it like this: lock-step will have tiny code size. It is very very = simple to implement and understand. I don't see every transmission being = multi-packet, very very few transmissions would exceed the 1280 byte = limit using UDP. Most people doing consistently large packets would = probably be using real TCP or something else. What we want to define is = something that lets CoAP work with large packets, but is NOT supposed to = be used to stream video. When using CoAP that gives you reliability anyway, as you get the = HTTP/CoAP/OK in response. If you send a single packet, and you get OK, = then it all worked. It's only when you have a multi-packet message you = get into trouble, since you'd have to resend the entire message if you = don't get OK. As a code-size comparison: 6lowpan-hc takes around 6K flash on an AVR = device, but it gives you considerable compression that you use on = *every* packet. So this makes it very very useful, and worth 6K.=20 Regards, -Colin PS: The HSS Saratoga looks like much warmer diving then we've got in the = UK ;-) -----Original Message----- From: core-bounces@ietf.org on behalf of L.Wood@surrey.ac.uk Sent: Wed 12/05/2010 07:25 To: cabo@tzi.org Cc: core@ietf.org; L.Wood@surrey.ac.uk Subject: Re: [core] Core UDP vs TCP : Redux =20 On 11 May 2010, at 22:52, Carsten Bormann wrote: > I don't have a problem with a multi-packet exchange to effect a = transfer. > But we should be very careful with what kind of state we expect the = two sides to build/maintain/keep for this. > Running a congestion control algorithm instead of a simple lock-step = mechanism sounds wrong. > Having any kind of flow control beyond the lock-step (e.g., windows) = sounds wrong. =20 > Having to establish a "session", "connection", "association" to effect = the transfer sounds wrong. >=20 > But I don't think of these as metrics, so if a good way to have these = multi-packet exchanges is proposed, let's look at the impact on nodes = and network instead of trying to decide whether it is too much like TCP. Some sort of connection is needed to deal with multi-packet exchanges. Sounds like the basic principles that went into designing Saratoga for = UDO: http://tools.ietf.org/html/draft-wood-tsvwg-saratoga-05 http://info.ee.surrey.ac.uk/Personal/L.Wood/dtn/saratoga L. Lloyd Wood L.Wood@surrey.ac.uk http://sat-net.com/L.Wood _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------_=_NextPart_001_01CAF1CB.178444A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [core] Core UDP vs TCP : Redux

Hello,

Do the limitations of a lock-step transfer matter in our limited = networks?

I see it like this: lock-step will have tiny code size. It is very very = simple to implement and understand. I don't see every transmission being = multi-packet, very very few transmissions would exceed the 1280 byte = limit using UDP. Most people doing consistently large packets would = probably be using real TCP or something else. What we want to define is = something that lets CoAP work with large packets, but is NOT supposed to = be used to stream video.

When using CoAP that gives you reliability anyway, as you get the = HTTP/CoAP/OK in response. If you send a single packet, and you get OK, = then it all worked. It's only when you have a multi-packet message you = get into trouble, since you'd have to resend the entire message if you = don't get OK.

As a code-size comparison: 6lowpan-hc takes around 6K flash on an AVR = device, but it gives you considerable compression that you use on = *every* packet. So this makes it very very useful, and worth 6K.

Regards,

   -Colin

PS: The HSS Saratoga looks like much warmer diving then we've got in the = UK ;-)




-----Original Message-----
From: core-bounces@ietf.org on behalf of L.Wood@surrey.ac.uk
Sent: Wed 12/05/2010 07:25
To: cabo@tzi.org
Cc: core@ietf.org; L.Wood@surrey.ac.uk
Subject: Re: [core] Core UDP vs TCP : Redux


On 11 May 2010, at 22:52, Carsten Bormann wrote:

> I don't have a problem with a multi-packet exchange to effect a = transfer.
> But we should be very careful with what kind of state we expect the = two sides to build/maintain/keep for this.
> Running a congestion control algorithm instead of a simple = lock-step mechanism sounds wrong.
> Having any kind of flow control beyond the lock-step (e.g., = windows) sounds wrong. 
> Having to establish a "session", "connection", = "association" to effect the transfer sounds wrong.
>
> But I don't think of these as metrics, so if a good way to have = these multi-packet exchanges is proposed, let's look at the impact on = nodes and network instead of trying to decide whether it is too much = like TCP.

Some sort of connection is needed to deal with multi-packet = exchanges.

Sounds like the basic principles that went into designing Saratoga for = UDO:
http://t= ools.ietf.org/html/draft-wood-tsvwg-saratoga-05
http://= info.ee.surrey.ac.uk/Personal/L.Wood/dtn/saratoga

L.

Lloyd Wood
L.Wood@surrey.ac.uk
http://sat-net.com/L.Wood



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

------_=_NextPart_001_01CAF1CB.178444A0-- From guido.moritz@uni-rostock.de Wed May 12 07:03:32 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83E913A68FD for ; Wed, 12 May 2010 07:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMDSsoqSh6BQ for ; Wed, 12 May 2010 07:03:31 -0700 (PDT) Received: from ida.uni-rostock.de (ida.uni-rostock.de [139.30.8.34]) by core3.amsl.com (Postfix) with ESMTP id 584A23A6CB0 for ; Wed, 12 May 2010 06:53:43 -0700 (PDT) Received: from email2.uni-rostock.de (139.30.8.209) by ida.uni-rostock.de (139.30.8.162) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 12 May 2010 15:53:29 +0200 Received: from Schlappi (139.30.201.226) by email2.uni-rostock.de (139.30.8.210) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 12 May 2010 15:53:29 +0200 From: Guido Moritz To: References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com> In-Reply-To: <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com> Date: Wed, 12 May 2010 15:53:32 +0200 Message-ID: <004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrxTf4ak2qgmnhIQIqfo77oXw6hCAAiuZtg Content-Language: de Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 14:03:32 -0000 Sorry, but I would not agree to say 'when you are able to use TCP, you = are also able to use HTTP'. We made several measurements with UDP vs. TCP = and of course, connection setup takes longer for TCP. But a typical HTTP header = has a size >100 Byte (without any payload). Thus the connection setup = overhead is compensated due to large payload/headers itself. There might be application scenarios where the designer wants to have reliable communication, but still have small payload. I did not have read through the current core I-D extensively, but is it necessary to go so much into detail why to use UDP or TCP and how it = should be used? It might be reasonable to define a reliability (and maybe also fragmentation) extension to UDP and define UDP as the defualt, but why should TCP be forbidden at all? One may argue about SOAP Web services in several points, but their = binding concept is quite nice. SOAP can be bound to which transport mechanism = ever. This makes it applicable it different scenarios and the transport mechanisms/protocol can be changed without an effect on application = itself. Just my two cents, Guido > -----Urspr=FCngliche Nachricht----- > Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag = von Zach > Shelby > Gesendet: Dienstag, 11. Mai 2010 23:07 > An: Thomas Herbst > Cc: core@ietf.org > Betreff: Re: [core] Core UDP vs TCP : Redux >=20 > +1 >=20 > Through writing a few revisions of these specs, I have also already = found TCP > to be really awkward. And the TCP negotiation discussions at the mike = in > Anaheim made me even more skeptical. Tom is right, if you need TCP = then just > use HTTP ;-) >=20 > Zach >=20 > On May 11, 2010, at 18:49 , Thomas Herbst wrote: >=20 > > After the discussion in Anaheim, I'm surprised that we need yet = another > revisit to UDP and TCP for CORE. > > > > The Right Solution(tm) might well be to fix TCP such that it doesn't lose > its brains every time you drop a packet, and we could end up with an end-to- > end system where constrained devices might reasonably provide services = to > normal hosts in the regular Internet, However, transport work is out = of scope > for this WG. > > > > The second most right solution would be to implement CORE with a reliable > UDP protocol, as is done in much of the draft. The "optional" TCP portions of > the draft are mostly increased complexity for no added benefit. If a device is > capable of running TCP and the network it works on is capable of supporting > TCP, you should just open a connection to Port 80 and use HTTP (or the = TCP > port/protocol of your choice). There are many protocols a host MAY implement > and it is not appropriate for the draft to enumerate them. > > > > Let's remove all of the sections related to TCP in the draft. > > > > tom > > > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core >=20 > -- > Zach Shelby, Head of Research, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From L.Wood@surrey.ac.uk Wed May 12 07:44:21 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 810293A6BF0 for ; Wed, 12 May 2010 07:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.744 X-Spam-Level: X-Spam-Status: No, score=-4.744 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7cLMQ1Vj9IL for ; Wed, 12 May 2010 07:44:19 -0700 (PDT) Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with ESMTP id BA5313A6CCF for ; Wed, 12 May 2010 07:28:24 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-7.tower-82.messagelabs.com!1273674492!231314!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.31] Received: (qmail 25908 invoked from network); 12 May 2010 14:28:13 -0000 Received: from unknown (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-7.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 12 May 2010 14:28:13 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.69]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Wed, 12 May 2010 15:28:12 +0100 From: To: , Date: Wed, 12 May 2010 15:28:10 +0100 Thread-Topic: [core] Core UDP vs TCP : Redux Thread-Index: AcrxTf4ak2qgmnhIQIqfo77oXw6hCAAiuZtgAAERdbA= Message-ID: References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com> <004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de> In-Reply-To: <004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 14:44:21 -0000 HTTP doesn't _have_ to run over TCP: http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery-05 and decoupling HTTP from TCP would be a very good idea, as implementation w= ork to do so (e.g. HTTP over SCTP) is ongoing: http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/talks.html#htt= p-standalone The only SOAP binding I can find is that to HTTP: http://www.w3.org/TR/soap12-part2/#soapinhttp http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#transpbindframew which does place SOAP binding firmly at 'concept' stage - one example to cl= aim that an entire range of possibilities exist and are implementable. Another example of this 'concept' is BEEP's transport profiles, for which o= nly a mapping to TCP is actually defined. Because nobody uses BEEP. L. -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Gui= do Moritz Sent: 12 May 2010 14:54 To: core@ietf.org Subject: Re: [core] Core UDP vs TCP : Redux Sorry, but I would not agree to say 'when you are able to use TCP, you are = also able to use HTTP'. We made several measurements with UDP vs. TCP and o= f course, connection setup takes longer for TCP. But a typical HTTP header = has a size >100 Byte (without any payload). Thus the connection setup overh= ead is compensated due to large payload/headers itself. There might be appl= ication scenarios where the designer wants to have reliable communication, = but still have small payload. I did not have read through the current core I-D extensively, but is it nec= essary to go so much into detail why to use UDP or TCP and how it should be= used? It might be reasonable to define a reliability (and maybe also fragmentation) extension to UDP and define UDP as the defualt, but why shou= ld TCP be forbidden at all? One may argue about SOAP Web services in several points, but their binding = concept is quite nice. SOAP can be bound to which transport mechanism ever. This makes it applicable it different scenarios and the transport mechanism= s/protocol can be changed without an effect on application itself. Just my two cents, Guido > -----Urspr=FCngliche Nachricht----- > Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag=20 > von Zach > Shelby > Gesendet: Dienstag, 11. Mai 2010 23:07 > An: Thomas Herbst > Cc: core@ietf.org > Betreff: Re: [core] Core UDP vs TCP : Redux >=20 > +1 >=20 > Through writing a few revisions of these specs, I have also already=20 > found TCP > to be really awkward. And the TCP negotiation discussions at the mike=20 > in Anaheim made me even more skeptical. Tom is right, if you need TCP=20 > then just > use HTTP ;-) >=20 > Zach >=20 > On May 11, 2010, at 18:49 , Thomas Herbst wrote: >=20 > > After the discussion in Anaheim, I'm surprised that we need yet=20 > > another > revisit to UDP and TCP for CORE. > > > > The Right Solution(tm) might well be to fix TCP such that it doesn't lose > its brains every time you drop a packet, and we could end up with an end-to- > end system where constrained devices might reasonably provide services=20 > to normal hosts in the regular Internet, However, transport work is=20 > out of scope > for this WG. > > > > The second most right solution would be to implement CORE with a reliable > UDP protocol, as is done in much of the draft. The "optional" TCP portions of > the draft are mostly increased complexity for no added benefit. If a device is > capable of running TCP and the network it works on is capable of supporting > TCP, you should just open a connection to Port 80 and use HTTP (or the=20 > TCP port/protocol of your choice). There are many protocols a host=20 > MAY implement > and it is not appropriate for the draft to enumerate them. > > > > Let's remove all of the sections related to TCP in the draft. > > > > tom > > >=20 > -- > Zach Shelby, Head of Research, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 From fluffy@cisco.com Wed May 12 07:46:55 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C3D528C17E for ; Wed, 12 May 2010 07:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.947 X-Spam-Level: X-Spam-Status: No, score=-109.947 tagged_above=-999 required=5 tests=[AWL=0.652, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWM--us5vyE6 for ; Wed, 12 May 2010 07:46:54 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 6E13328C223 for ; Wed, 12 May 2010 07:31:15 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPtY6kurR7H+/2dsb2JhbACeLHGgcplugmGCMQSDQA X-IronPort-AV: E=Sophos;i="4.53,215,1272844800"; d="scan'208";a="255413906" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 12 May 2010 14:31:05 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4CEV4Ug026449; Wed, 12 May 2010 14:31:04 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Wed, 12 May 2010 08:31:04 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <97F2FD13-0024-422C-836E-DE2ED69BED84@cisco.com> References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com><17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com> To: "Simpson, Robby (GE Energy Services)" X-Mailer: Apple Mail (2.1078) Cc: core@ietf.org Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 14:46:55 -0000 On May 11, 2010, at 3:41 PM, Simpson, Robby (GE Energy Services) wrote: >=20 > For clarification, what are your metrics for "reinventing TCP"? Excellent question.=20 The IETF has a pretty involved process for defining any new algorithms = for transports. One of the reasons it is so involved is that people want = to make sure that the new algorithm does not adversely impact existing = transports. Clearly this WG would be the wrong place to do any new = algorithms.=20 That still allows us to use algorithms that have been done for other = things here. (For example, the tftp algorithm got mentioned in an = earlier thread.) We will want to coordinate closely with the transport = ADs on whatever we do but I don't see problems with simple reliability, = or some simple fragmentation based around existing technique - several = other WGs have done that. We pretty much have to use one of the = existing approaches to congestion control.=20 I suspect that if we started talking about features to improve the = transfer rate of data beyond the what simple algorithms give you, folks = would start really wondering if it would be better to use TCP. I know = that I would want to have a chat with the transport ADs before going = down any path like that. Cullen=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From Colin.OFlynn@atmel.com Wed May 12 08:34:35 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F61728C13C for ; Wed, 12 May 2010 08:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.958 X-Spam-Level: X-Spam-Status: No, score=-0.958 tagged_above=-999 required=5 tests=[AWL=-0.774, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQZ7J3C3Z851 for ; Wed, 12 May 2010 08:34:34 -0700 (PDT) Received: from sjogate2.atmel.com (newsmtp5.atmel.com [204.2.163.5]) by core3.amsl.com (Postfix) with ESMTP id E98D228C238 for ; Wed, 12 May 2010 08:22:46 -0700 (PDT) Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id o4CFKJ6Q000122; Wed, 12 May 2010 08:20:20 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAF1E6.E5B26894" Date: Wed, 12 May 2010 09:22:13 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Core UDP vs TCP : Redux Thread-Index: Acrx4fZLHeA+RHsQQ9ypGy3ZfVJqDwAA5qU2 References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com><17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com> <97F2FD13-0024-422C-836E-DE2ED69BED84@cisco.com> From: "Oflynn, Colin" To: "Cullen Jennings" , "Simpson, Robby (GE Energy Services)" Cc: core@ietf.org Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 15:34:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAF1E6.E5B26894 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, For the record on TFTP (which I think such a style would be good for = simple fragmentation): In our testing, with a real 802.15.4 network in test code (read: not = carefully optimized) we could get 5-7 Kbytes/sec with TFTP transferring = large files. This is using standard 512-byte TFTP fragmentation size. Regards, -Colin -----Original Message----- From: core-bounces@ietf.org on behalf of Cullen Jennings Sent: Wed 12/05/2010 15:31 To: Simpson, Robby (GE Energy Services) Cc: core@ietf.org Subject: Re: [core] Core UDP vs TCP : Redux =20 On May 11, 2010, at 3:41 PM, Simpson, Robby (GE Energy Services) wrote: >=20 > For clarification, what are your metrics for "reinventing TCP"? Excellent question.=20 The IETF has a pretty involved process for defining any new algorithms = for transports. One of the reasons it is so involved is that people want = to make sure that the new algorithm does not adversely impact existing = transports. Clearly this WG would be the wrong place to do any new = algorithms.=20 That still allows us to use algorithms that have been done for other = things here. (For example, the tftp algorithm got mentioned in an = earlier thread.) We will want to coordinate closely with the transport = ADs on whatever we do but I don't see problems with simple reliability, = or some simple fragmentation based around existing technique - several = other WGs have done that. We pretty much have to use one of the = existing approaches to congestion control.=20 I suspect that if we started talking about features to improve the = transfer rate of data beyond the what simple algorithms give you, folks = would start really wondering if it would be better to use TCP. I know = that I would want to have a chat with the transport ADs before going = down any path like that. Cullen=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------_=_NextPart_001_01CAF1E6.E5B26894 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [core] Core UDP vs TCP : Redux

Hello,

For the record on TFTP (which I think such a style would be good for = simple fragmentation):

In our testing, with a real 802.15.4 network in test code (read: not = carefully optimized) we could get 5-7 Kbytes/sec with TFTP transferring = large files. This is using standard 512-byte TFTP fragmentation = size.

Regards,

  -Colin

-----Original Message-----
From: core-bounces@ietf.org on behalf of Cullen Jennings
Sent: Wed 12/05/2010 15:31
To: Simpson, Robby (GE Energy Services)
Cc: core@ietf.org
Subject: Re: [core] Core UDP vs TCP : Redux


On May 11, 2010, at 3:41 PM, Simpson, Robby (GE Energy Services) = wrote:

>
> For clarification, what are your metrics for "reinventing = TCP"?


Excellent question.

The IETF has a pretty involved process for defining any new algorithms = for transports. One of the reasons it is so involved is that people want = to make sure that the new algorithm does not adversely impact existing = transports.  Clearly this WG would be the wrong place to do any new = algorithms.

That still allows us to use algorithms that have been done for other = things here. (For example, the tftp algorithm got mentioned in an = earlier thread.) We will want to coordinate closely with the transport = ADs on whatever we do but I don't see problems with simple reliability, = or some simple fragmentation based around existing technique - several = other WGs have done that.  We pretty much have to use one of the = existing approaches to congestion control.

I suspect that if we started talking about features to improve the = transfer rate of data beyond the what simple algorithms give you, folks = would start really wondering if it would be better to use TCP. I know = that I would want to have a chat with the transport ADs before going = down any path like that.

Cullen







Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=



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

------_=_NextPart_001_01CAF1E6.E5B26894-- From robert.cragie@gridmerge.com Wed May 12 14:46:28 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C95953A6956 for ; Wed, 12 May 2010 14:46:28 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zK96YXzNLZb4 for ; Wed, 12 May 2010 14:46:24 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id E8C173A696D for ; Wed, 12 May 2010 14:46:20 -0700 (PDT) Received: from [74.10.175.226] (helo=[192.168.108.191]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1OCJkm-0000b2-Nm for core@ietf.org; Wed, 12 May 2010 22:46:09 +0100 Message-ID: <4BEB219C.9010508@gridmerge.com> Date: Wed, 12 May 2010 22:46:04 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: core@ietf.org References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com><17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><9BB682AE-86C2-4054-8758-8E7C6AD10807@cs.columbia.edu> <485AF6ECE8D1954D996771CC49E996FDC0FE2568@IT-EXMB-01.silverspringnet.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030403030000060803020301" Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 21:46:28 -0000 This is a cryptographically signed message in MIME format. --------------ms030403030000060803020301 Content-Type: multipart/alternative; boundary="------------000706060007040406070508" This is a multi-part message in MIME format. --------------000706060007040406070508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable If we specify UDP only as transport, for delivery we need to consider=20 the following: 1. UDP is adequate for the transport's client applications delivery as= is 2. The transport's client applications provides delivery mechanisms appropriately according to their requirements 3. Creating a shim layer above UDP for improving delivery and providing a homogeneous interface to client applications 4. Creating a framework (SASL-like), separating the protocols and the mechanisms to promote reuse across applications. (1) may be the case in very simple delivery where it doesn't really=20 matter if the odd packet gets lost, e.g. non-critical temperature=20 readings. This could allow for very simple transmit-only devices. (2)=20 would make sense but could mean implementing multiple similar but subtly = different mechanisms multiple times in a device which serves different=20 applications. These may be pretty simple, including lock-step=20 transactions using 'short' packets, i.e. fitting into one UDP datagram.=20 (3) seems to be frowned upon and seems that it may be out of scope for=20 the WG, although would probably be more efficient on the basis that=20 there is a common set of requirements for reliable delivery. (4) could=20 work, providing a half-way between (2) and (3) Back to (2), for example, DTLS implements its own reliability mechanism=20 - could this be reused by other applications? I think the framework idea might be worth exploring further although I=20 am not entirely sure whether reliability mechanisms can be classified=20 appropriately with common interfaces in this way. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com On 12/05/2010 2:13 AM, Oflynn, Colin wrote: > > Hello, > > >This works as long as you can guarantee that the response is < MTU. > > Which the current draft does. If we go the UDP route, I think we need=20 > to add support for larger packets through some simple fragmentation. > > You won't need such large packets often! So it doesn't have to be very = > efficient, just every so often you need to transmit a large frame for=20 > a file load, encryption, etc. > > Regards, > > -Colin > > > -----Original Message----- > From: core-bounces@ietf.org on behalf of Thomas Herbst > Sent: Wed 12/05/2010 02:11 > To: Henning Schulzrinne; Zach Shelby > Cc: core@ietf.org > Subject: Re: [core] Core UDP vs TCP : Redux > > On TCP vs UDP - we need to pick one. Deciding to use both UDP and TCP = > is just not making a decision. > > You expect people who didn't include enough memory in their devices to = > implement TCP to do both UDP and TCP? > > On security, is there a problem w/ DTLS? > > tom > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, May 11, 2010 3:02 PM > To: Zach Shelby > Cc: Thomas Herbst; core@ietf.org > Subject: Re: [core] Core UDP vs TCP : Redux > > This works as long as you can guarantee that the response is < MTU.=20 > Doing your own fragmentation is a pain (you are then well on your way=20 > to re-inventing TCP) and relying on IP fragmentation is unlikely to=20 > work in "challenged" networks. Thus, these applicability limitations=20 > need to be spelled out very clearly. This also has security=20 > implications - obviously, TLS is out without TCP, but anything=20 > involving certificates is also likely to be difficult to carry. > > Henning > > On May 11, 2010, at 5:06 PM, Zach Shelby wrote: > > > +1 > > > > Through writing a few revisions of these specs, I have also already=20 > found TCP to be really awkward. And the TCP negotiation discussions at = > the mike in Anaheim made me even more skeptical. Tom is right, if you=20 > need TCP then just use HTTP ;-) > > > > Zach > > > > On May 11, 2010, at 18:49 , Thomas Herbst wrote: > > > >> After the discussion in Anaheim, I'm surprised that we need yet=20 > another revisit to UDP and TCP for CORE. > >> > >> The Right Solution(tm) might well be to fix TCP such that it=20 > doesn't lose its brains every time you drop a packet, and we could end = > up with an end-to-end system where constrained devices might=20 > reasonably provide services to normal hosts in the regular Internet, =20 > However, transport work is out of scope for this WG. > >> > >> The second most right solution would be to implement CORE with a=20 > reliable UDP protocol, as is done in much of the draft. The=20 > "optional" TCP portions of the draft are mostly increased complexity=20 > for no added benefit. If a device is capable of running TCP and the=20 > network it works on is capable of supporting TCP, you should just open = > a connection to Port 80 and use HTTP (or the TCP port/protocol of your = > choice). There are many protocols a host MAY implement and it is not=20 > appropriate for the draft to enumerate them. > >> > >> Let's remove all of the sections related to TCP in the draft. > >> > >> tom > >> > >> > >> _______________________________________________ > >> core mailing list > >> core@ietf.org > >> https://www.ietf.org/mailman/listinfo/core > > > > -- > > Zach Shelby, Head of Research, Sensinode Ltd. > > http://zachshelby.org - My blog "On the Internet of Things" > > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet= " > > Mobile: +358 40 7796297 > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > =20 --------------000706060007040406070508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If we specify UDP only as transport, for delivery we need to consider the following:
  1. UDP is adequate for the transport's client applications delivery as is
  2. The transport's client applications provides delivery mechanisms appropriately according to their requirements
  3. Creating a shim layer above UDP for improving delivery and providing a homogeneous interface to client applications
  4. Creating a framework (SASL-like), separating the protocols and the mechanisms to promote reuse across applications.
(1) may be the case in very simple delivery where it doesn't really matter if the odd packet gets lost, e.g. non-critical temperature readings. This could allow for very simple transmit-only devices. (2) would make sense but could mean implementing multiple similar but subtly different mechanisms multiple times in a device which serves different applications. These may be pretty simple, including lock-step transactions using 'short' packets, i.e. fitting into one UDP datagram. (3) seems to be frowned upon and seems that it may be out of scope for the WG, although would probably be more efficient on the basis that there is a common set of requirements for reliable delivery. (4) could work, providing a half-way between (2) and (3)

Back to (2), for example, DTLS implements its own reliability mechanism - could this be reused by other applications?

I think the framework idea might be worth exploring further although I am not entirely sure whether reliability mechanisms can be classified appropriately with common interfaces in this way.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com


On 12/05/2010 2:13 AM, Oflynn, Colin wrote:
RE: [core] Core UDP vs TCP : Redux

Hello,

>This works as long as you can guarantee that the response is < MTU.

Which the current draft does. If we go the UDP route, I think we need to add support for larger packets through some simple fragmentation.

You won't need such large packets often! So it doesn't have to be very efficient, just every so often you need to transmit a large frame for a file load, encryption, etc.

Regards,

  -Colin


-----Original Message-----
From: core-bounces@ietf.org on behalf of Thomas Herbst
Sent: Wed 12/05/2010 02:11
To: Henning Schulzrinne; Zach Shelby
Cc: c= ore@ietf.org
Subject: Re: [core] Core UDP vs TCP : Redux

On TCP vs UDP - we need to pick one.  Deciding to use both UDP and T= CP is just not making a decision. 

You expect people who didn't include enough memory in their devices to implement TCP to do both UDP and TCP?

On security, is there a problem w/ DTLS?

tom

-----Original Message-----
From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
Sent: Tuesday, May 11, 2010 3:02 PM
To: Zach Shelby
Cc: Thomas Herbst; core@ietf.org
Subject: Re: [core] Core UDP vs TCP : Redux

This works as long as you can guarantee that the response is < MTU. Doing your own fragmentation is a pain (you are then well on your way to re-inventing TCP) and relying on IP fragmentation is unlikely to work in "challenged" networks. Thus, these applicability limitations need to be spelled out very clearly. This also has security implications - obviously, TLS is out without TCP, but anything involving certificates is also likely to be difficult to carry.

Henning

On May 11, 2010, at 5:06 PM, Zach Shelby wrote:

> +1
>
> Through writing a few revisions of these specs, I have also already found TCP to be really awkward. And the TCP negotiation discussions at the mike in Anaheim made me even more skeptical. Tom is right, if you need TCP then just use HTTP ;-)
>
> Zach
>
> On May 11, 2010, at 18:49 , Thomas Herbst wrote:
>
>> After the discussion in Anaheim, I'm surprised that we need yet another revisit to UDP and TCP for CORE.
>>
>> The Right Solution(tm) might well be to fix TCP such that it doesn't lose its brains every time you drop a packet, and we could end up with an end-to-end system where constrained devices might reasonably provide services to normal hosts in the regular Internet,  However, transport work is out of scope for this WG.
>>
>> The second most right solution would be to implement CORE with a reliable UDP protocol, as is done in much of the draft.  The "optional" TCP portions of the draft are mostly increased complexity for no added benefit. If a device is capable of running TCP and the network it works on is capable of supporting TCP, you should just open a connection to Port 80 and use HTTP (or the TCP port/protocol of your choice).  There are many protocols a host MAY implement and it is no= t appropriate for the draft to enumerate them. 
>>
>> Let's remove all of the sections related to TCP in the draft. >>
>> tom
>>
>>
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org= /mailman/listinfo/core
>
> --
> Zach Shelby, Head of Research, Sensinode Ltd.
> http://za= chshelby.org  - My blog "On the Internet of Things"
> http://6lowp= an.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
>

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

 


_______________________________________________
core mailing list
core@=
ietf.org
https://www.ietf.org=
/mailman/listinfo/core
--------------000706060007040406070508-- --------------ms030403030000060803020301 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA1 MTIyMTQ2MDRaMCMGCSqGSIb3DQEJBDEWBBQVdiUh74szWKZUBsIfMSBpZ03o6DBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBALIsrqryLhpbEr0UVBHT96sxFxfMN7VUoknXoNkJuLE/iHmgoEmfH3vmuM/WqsxezoZo C/CxQEie9Kv+fbxax64DgEXBvIVWIzgmBK77vL4aZCqby3Q0b85wfFfasI2WKZ3weG1Ieasp fc1S6s38C/0MWAePGnijvfaBVleSh69LZ82NxOjKdM9donVPxg/HZmTK3ZvmG7d2U7icQFIg W/hq7tnSvMMbCWSawvLi+/hGYJvkcRiPP+BD4UE+3Sf8yRMlgAmgkcKifB88agyk70Nn2WKK tftGz+bzF8aaEi1yQq6PmlyqGxfg6DFw9YybMIJgHdfIUkPOcgETlR2ybokAAAAAAAA= --------------ms030403030000060803020301-- From angelo.castellani@gmail.com Thu May 13 04:29:42 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39BC83A6CAB for ; Thu, 13 May 2010 04:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.577 X-Spam-Level: X-Spam-Status: No, score=-0.577 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sovXHRLfJKcz for ; Thu, 13 May 2010 04:29:41 -0700 (PDT) Received: from mail-gx0-f216.google.com (mail-gx0-f216.google.com [209.85.217.216]) by core3.amsl.com (Postfix) with ESMTP id 3FEB73A6CC2 for ; Thu, 13 May 2010 04:24:25 -0700 (PDT) Received: by gxk8 with SMTP id 8so431050gxk.9 for ; Thu, 13 May 2010 04:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=5UCHvFshwMyXXjKZDTHbW8BJcLFyK9JhJdsDgR0bonE=; b=ok0sxmGATLqAT44vC77iJzCuLXAF5iadQAKu54s8Hgc8UvITGHZVMD8ZZuYG3YBkNA Vl1wNEdHeh3Yq2ESFN+WrEga3v0a7FEZMM9G4qA8flFObKRd1cjBYWXhdVMeDIaOyKuj 8R9g1DUwkMXDjo+UXGeArOMfajGA4b0FoIBN4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=RC1f7qro9hwwofEDbR9QIvF55V/vO5Wf0pX5w15SgmFMEFp0Luh2eR2LAoc3iUnANL eHMy9P/1fkKdmhInHSfj54gUkFDtmeb7onANZsAQR5mculY65sBVPOjTovpmeYDDgzhb PVAvUiY5gSGyrcX9H2jT1DCS7ml07cTbSwMyI= MIME-Version: 1.0 Received: by 10.90.213.7 with SMTP id l7mr242026agg.154.1273749852375; Thu, 13 May 2010 04:24:12 -0700 (PDT) Sender: angelo.castellani@gmail.com Received: by 10.90.26.2 with HTTP; Thu, 13 May 2010 04:24:12 -0700 (PDT) In-Reply-To: <3BB5F67A-9E57-4F81-B7C5-ABB1E136DAAC@tzi.org> References: <3BB5F67A-9E57-4F81-B7C5-ABB1E136DAAC@tzi.org> Date: Thu, 13 May 2010 13:24:12 +0200 X-Google-Sender-Auth: ydGminNSozRepI2unCynNSAIZDo Message-ID: From: "Angelo P. Castellani" To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core Subject: Re: [core] Selecting a WG document for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 11:29:42 -0000 Dear C. Bormann, all, before deciding for the final direction, I've the following observations about draft-shelby-core-coap-01 While I mostly share Zach's view of the protocol approach, and appreciate many aspects of the proposal, there are in my opinion still some open issues that need to be at least discussed before the current document can be selected. In particular, I would like to highlight the following: a) As it is now, it is not possible to have a straightforward translation of HTTP -> CoAP and viceversa: see http://www.ietf.org/mail-archive/web/core/current/msg00133.html (this impacts the scalability of the web service model too) b) Moreover, CoAP's implementation is not as simple as it should be. I've investigated the implementation and some design choices (as Options) are leading to very high program complexity (ROM) on a MSP430-based device. c) Finally when comparing HTTP message size with CoAP message size, the resulting compression isn't as good as you may expect. Example: HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B CoAP: 24 B with options parsing procedure requiring an added implementation complexity Addressing all these points potentially leads to major technical modifications (especially point a) on the current draft, hence it is appropriate in my opinion to discuss these points before making the final decision. Best regards, Angelo P. Castellani On Mon, May 10, 2010 at 18:51, Carsten Bormann wrote: > The CORE WG has a milestone to select a WG document for CoAP in April: > > http://datatracker.ietf.org/wg/core/charter/ > ... > Apr 2010 =A0 =A0 =A0 =A0Select WG document for basis of the CoAP protocol > > Of the various documents that have been contributed, draft-shelby-core-co= ap has significant discussion, as well as the largest number of updates (in= cluding a previous version that was still called -6lowapp-coap). > > Today, another updated version of that draft was announced. =A0See > http://www.ietf.org/mail-archive/web/core/current/msg00138.html > for the announcement and > http://tools.ietf.org/html/draft-shelby-core-coap-01 > for the draft itself. > > However, as the authors say, there are still significant TODOs. > > Are we in a state yet where we can say whether this is the right directio= n for the WG to take? > If yes, is it the right direction? =A0Should we adopt it as a WG document= ? > If you don't think we can say yet, is there a set of technical decisions = you would like the authors to take with priority? > > Note that once a document has become a WG document, the authors act as ed= itors for the working group, making (and usually fleshing out the details o= f) any change that the WG decides it needs. > If you think we can still improve the draft, this is not an obstacle to m= aking it a WG document. > But of course we shouldn't do that if we intend to reverse its fundamenta= l technical direction. > > In order to stay roughly in sync with our milestones, we should reach at = a decision on how to go forward this week. > > Gruesse, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From pab@peoplepowerco.com Thu May 13 07:35:42 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4255D3A6B39 for ; Thu, 13 May 2010 07:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.123 X-Spam-Level: **** X-Spam-Status: No, score=4.123 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoNe94RtsNcL for ; Thu, 13 May 2010 07:35:41 -0700 (PDT) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id 5BB923A6B5B for ; Thu, 13 May 2010 07:35:39 -0700 (PDT) Received: by ewy8 with SMTP id 8so550514ewy.28 for ; Thu, 13 May 2010 07:35:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.4 with SMTP id g4mr36840mui.80.1273761325120; Thu, 13 May 2010 07:35:25 -0700 (PDT) Received: by 10.103.212.5 with HTTP; Thu, 13 May 2010 07:35:25 -0700 (PDT) Date: Thu, 13 May 2010 09:35:25 -0500 Message-ID: From: Peter Bigot To: core@ietf.org Content-Type: multipart/alternative; boundary=00163642651b4ffde804867aab4a Subject: [core] Date option in draft-shelby-core-coap-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 14:35:42 -0000 --00163642651b4ffde804867aab4a Content-Type: text/plain; charset=ISO-8859-1 Section 3.3.6 introduces a Date option that can be used to timestamp a measurement. The description specifies that leap seconds are excluded. It's not crystal clear to me what "excluded" means in this situation. I don't see any discussion in the list archive. Pretending leap seconds don't exist (one sense of exclude) makes sense as it trivializes the translation between POSIX- time representations (seconds since 1970-01-01T00:00:00Z) and UTC-aligned wall clock times that people normally deal with: this becomes simple division and modulus operations with a little hassle imposed by leap years. On the other hand, the representation can express times that do not exist (23:59:59 when a negative leap second takes effect), and can be ambiguous (23:59:60 or a repeated 23:59:59 when a positive leap second takes effect). More importantly, simple subtraction of two event times does not necessarily result in the duration of the event. For an in-development system to which CoAP could apply, my recommendation was to use times expressed as atomic seconds since the POSIX epoch (thereby excluding leap second adjustments from the value). This does mean that translation to civil time requires knowledge of the number of leap seconds in effect at that time (currently UTC is 24 seconds behind TAI relative to the POSIX epoch). In return, devices that maintain an internal clock used to timestamp events do not need to be updated to take into account leap second adjustments, which can take a fair amount of code and support infrastructure to handle a very rare event. It also trivializes calculation of event durations, even when the duration spans application of a leap second. My feeling is that any software component that needs to translate between between device time and civil time can be expected to account for leap seconds, while those that are operating in a constrained environment would best be isolated from their effects. Note that GPS time is similarly measured in atomic seconds since an epoch (1980-01-06T00:00:00Z). So, do Date values in the proposed COAP match what you get from running "date +%s" on a Linux system synchronized to UTC, or are they that value plus 24? I read the draft as specifying the latter, which is my preference, but anticipate great confusion from people who haven't had to deal with leap seconds before. Recommend changing "number of seconds, excluding leap seconds, after" to "number of (atomic) seconds since". Peter --00163642651b4ffde804867aab4a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Section 3.3.6 introduces a Date option that can be used to timestamp a meas= urement.=A0 The description specifies that leap seconds are excluded.=A0 It= 's not crystal clear to me what "excluded" means in this situ= ation.=A0 I don't see any discussion in the list archive.

Pretending leap seconds don't exist (one sense of exclude) makes se= nse as it trivializes the translation between POSIX- time representations (= seconds since 1970-01-01T00:00:00Z) and UTC-aligned wall clock times that p= eople normally deal with: this becomes simple division and modulus operatio= ns with a little hassle imposed by leap years.=A0 On the other hand, the re= presentation can express times that do not exist (23:59:59 when a negative = leap second takes effect), and can be ambiguous (23:59:60 or a repeated 23:= 59:59 when a positive leap second takes effect).=A0 More importantly, simpl= e subtraction of two event times does not necessarily result in the duratio= n of the event.

For an in-development system to which CoAP could apply, my recommendati= on was to use times expressed as atomic seconds since the POSIX epoch (ther= eby excluding leap second adjustments from the value).=A0 This does mean th= at translation to civil time requires knowledge of the number of leap secon= ds in effect at that time (currently UTC is 24 seconds behind TAI relative = to the POSIX epoch).=A0 In return, devices that maintain an internal clock = used to timestamp events do not need to be updated to take into account lea= p second adjustments, which can take a fair amount of code and support infr= astructure to handle a very rare event.=A0 It also trivializes calculation = of event durations, even when the duration spans application of a leap seco= nd.

My feeling is that any software component that needs to translate betwe= en between device time and civil time can be expected to account for leap s= econds, while those that are operating in a constrained environment would b= est be isolated from their effects.=A0 Note that GPS time is similarly meas= ured in atomic seconds since an epoch (1980-01-06T00:00:00Z).

So, do Date values in the proposed COAP match what you get from running= "date +%s" on a Linux system synchronized to UTC, or are they th= at value plus 24?=A0 I read the draft as specifying the latter, which is my= preference, but anticipate great confusion from people who haven't had= to deal with leap seconds before.

Recommend changing "number of seconds, excluding leap seconds, aft= er" to "number of (atomic) seconds since".

Peter
<= div style=3D"visibility: hidden; display: inline;" id=3D"avg_ls_inline_popu= p"> --00163642651b4ffde804867aab4a-- From fluffy@cisco.com Thu May 13 07:57:29 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09B0B3A6B39 for ; Thu, 13 May 2010 07:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.709 X-Spam-Level: X-Spam-Status: No, score=-108.709 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2I0uBGXcWN1 for ; Thu, 13 May 2010 07:57:27 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id F16223A6B6C for ; Thu, 13 May 2010 07:57:21 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABuw60urR7Hu/2dsb2JhbACeIXGjA5k1hRIEg0A X-IronPort-AV: E=Sophos;i="4.53,223,1272844800"; d="scan'208";a="129262091" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 13 May 2010 14:57:12 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o4DEvBH3019265; Thu, 13 May 2010 14:57:11 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Thu, 13 May 2010 08:57:09 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <568AEFD6-974D-4790-A2F8-84305B990BA9@cisco.com> References: <3BB5F67A-9E57-4F81-B7C5-ABB1E136DAAC@tzi.org> To: "Angelo P. Castellani" X-Mailer: Apple Mail (2.1078) Cc: core Subject: Re: [core] Selecting a WG document for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 14:57:29 -0000 Angelo,=20 I may be reading too much in between the lines here, but I think you are = raising the overall design question of should we use some form of = compressed HTTP, where we preserver the semantics of HTTP but encode it = differently, or should we develop a protocol with a subset of the = semantics of HTTP. Perhaps I have this all wrong and you are not raising = that. Could you outline some proposed solutions to your a,b,c problems = below and perhaps say a bit more about what the problem is. Once I = understood a bit more about how you would propose to design the protocol = to mitigate these problems, I think that would help everyone make = informed choices.=20 Thanks, Cullen Few more questions inline .... On May 13, 2010, at 5:24 AM, Angelo P. Castellani wrote: > Dear C. Bormann, all, >=20 > before deciding for the final direction, I've the following > observations about draft-shelby-core-coap-01 >=20 > While I mostly share Zach's view of the protocol approach, and > appreciate many aspects of the proposal, there are in my opinion still > some open issues that need to be at least discussed before the current > document can be selected. >=20 > In particular, I would like to highlight the following: >=20 > a) As it is now, it is not possible to have a straightforward > translation of HTTP -> CoAP and viceversa: see > http://www.ietf.org/mail-archive/web/core/current/msg00133.html (this > impacts the scalability of the web service model too) On the topic of how to encode the URI. I think that needs discussion but = could easily happen (and would happen) even if the COAP document was = adopted as a WG item now.=20 >=20 > b) Moreover, CoAP's implementation is not as simple as it should be. > I've investigated the implementation and some design choices (as > Options) are leading to very high program complexity (ROM) on a > MSP430-based device. Can you say more - particularly about proposals to fix it? >=20 > c) Finally when comparing HTTP message size with CoAP message size, > the resulting compression isn't as good as you may expect. >=20 > Example: > HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B > CoAP: 24 B with options parsing procedure requiring an added > implementation complexity >=20 > Addressing all these points potentially leads to major technical > modifications (especially point a) on the current draft, hence it is > appropriate in my opinion to discuss these points before making the > final decision. >=20 > Best regards, >=20 > Angelo P. Castellani >=20 >=20 > On Mon, May 10, 2010 at 18:51, Carsten Bormann wrote: >> The CORE WG has a milestone to select a WG document for CoAP in = April: >>=20 >> http://datatracker.ietf.org/wg/core/charter/ >> ... >> Apr 2010 Select WG document for basis of the CoAP protocol >>=20 >> Of the various documents that have been contributed, = draft-shelby-core-coap has significant discussion, as well as the = largest number of updates (including a previous version that was still = called -6lowapp-coap). >>=20 >> Today, another updated version of that draft was announced. See >> http://www.ietf.org/mail-archive/web/core/current/msg00138.html >> for the announcement and >> http://tools.ietf.org/html/draft-shelby-core-coap-01 >> for the draft itself. >>=20 >> However, as the authors say, there are still significant TODOs. >>=20 >> Are we in a state yet where we can say whether this is the right = direction for the WG to take? >> If yes, is it the right direction? Should we adopt it as a WG = document? >> If you don't think we can say yet, is there a set of technical = decisions you would like the authors to take with priority? >>=20 >> Note that once a document has become a WG document, the authors act = as editors for the working group, making (and usually fleshing out the = details of) any change that the WG decides it needs. >> If you think we can still improve the draft, this is not an obstacle = to making it a WG document. >> But of course we shouldn't do that if we intend to reverse its = fundamental technical direction. >>=20 >> In order to stay roughly in sync with our milestones, we should reach = at a decision on how to go forward this week. >>=20 >> Gruesse, 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 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From Colin.OFlynn@atmel.com Thu May 13 08:17:25 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D23F3A68B0 for ; Thu, 13 May 2010 08:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.671 X-Spam-Level: X-Spam-Status: No, score=-0.671 tagged_above=-999 required=5 tests=[AWL=-0.673, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W96L-c8bAzCl for ; Thu, 13 May 2010 08:17:23 -0700 (PDT) Received: from sjogate2.atmel.com (newsmtp5.atmel.com [204.2.163.5]) by core3.amsl.com (Postfix) with ESMTP id D47003A693C for ; Thu, 13 May 2010 08:17:22 -0700 (PDT) Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id o4DFEuig007793 for ; Thu, 13 May 2010 08:15:03 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAF2AF.50364A7C" Date: Thu, 13 May 2010 09:16:51 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Core UDP vs TCP : Redux Thread-Index: AcryHJYGoEUBgmo0Q6mhVkcXbPhtiwAkeOP9 References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com><17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><9BB682AE-86C2-4054-8758-8E7C6AD10807@cs.columbia.edu> <485AF6ECE8D1954D996771CC49E996FDC0FE2568@IT-EXMB-01.silverspringnet.com> <4BEB219C.9010508@gridmerge.com> From: "Oflynn, Colin" To: , Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 15:17:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAF2AF.50364A7C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Robert, I think it makes sense to look at integrating such requirements into = CoAP itself (or whatever higher level protocol is used). How TFTP for = instance adds reliability & fragmentation onto UDP. core-coap-01 does have an "acknowledgement" flag, which when sent with a = request means it MUST generate a response. A simple fragmentation flag = could be added perhaps to support larger messages.=20 Which would be a combination of 3 & 4 maybe? Although I've not thought = about it very hard, so if I'm missing something obvious about why this = won't work be sure to call me out on that ;-) Regards, -Colin -----Original Message----- From: core-bounces@ietf.org on behalf of Robert Cragie Sent: Wed 12/05/2010 22:46 To: core@ietf.org Subject: Re: [core] Core UDP vs TCP : Redux =20 If we specify UDP only as transport, for delivery we need to consider=20 the following: 1. UDP is adequate for the transport's client applications delivery = as is 2. The transport's client applications provides delivery mechanisms appropriately according to their requirements 3. Creating a shim layer above UDP for improving delivery and providing a homogeneous interface to client applications 4. Creating a framework (SASL-like), separating the protocols and the mechanisms to promote reuse across applications. (1) may be the case in very simple delivery where it doesn't really=20 matter if the odd packet gets lost, e.g. non-critical temperature=20 readings. This could allow for very simple transmit-only devices. (2)=20 would make sense but could mean implementing multiple similar but subtly = different mechanisms multiple times in a device which serves different=20 applications. These may be pretty simple, including lock-step=20 transactions using 'short' packets, i.e. fitting into one UDP datagram.=20 (3) seems to be frowned upon and seems that it may be out of scope for=20 the WG, although would probably be more efficient on the basis that=20 there is a common set of requirements for reliable delivery. (4) could=20 work, providing a half-way between (2) and (3) Back to (2), for example, DTLS implements its own reliability mechanism=20 - could this be reused by other applications? I think the framework idea might be worth exploring further although I=20 am not entirely sure whether reliability mechanisms can be classified=20 appropriately with common interfaces in this way. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0) 1924 910888 http://www.gridmerge.com On 12/05/2010 2:13 AM, Oflynn, Colin wrote: > > Hello, > > >This works as long as you can guarantee that the response is < MTU. > > Which the current draft does. If we go the UDP route, I think we need=20 > to add support for larger packets through some simple fragmentation. > > You won't need such large packets often! So it doesn't have to be very = > efficient, just every so often you need to transmit a large frame for=20 > a file load, encryption, etc. > > Regards, > > -Colin > > > -----Original Message----- > From: core-bounces@ietf.org on behalf of Thomas Herbst > Sent: Wed 12/05/2010 02:11 > To: Henning Schulzrinne; Zach Shelby > Cc: core@ietf.org > Subject: Re: [core] Core UDP vs TCP : Redux > > On TCP vs UDP - we need to pick one. Deciding to use both UDP and TCP = > is just not making a decision. > > You expect people who didn't include enough memory in their devices to = > implement TCP to do both UDP and TCP? > > On security, is there a problem w/ DTLS? > > tom > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, May 11, 2010 3:02 PM > To: Zach Shelby > Cc: Thomas Herbst; core@ietf.org > Subject: Re: [core] Core UDP vs TCP : Redux > > This works as long as you can guarantee that the response is < MTU.=20 > Doing your own fragmentation is a pain (you are then well on your way=20 > to re-inventing TCP) and relying on IP fragmentation is unlikely to=20 > work in "challenged" networks. Thus, these applicability limitations=20 > need to be spelled out very clearly. This also has security=20 > implications - obviously, TLS is out without TCP, but anything=20 > involving certificates is also likely to be difficult to carry. > > Henning > > On May 11, 2010, at 5:06 PM, Zach Shelby wrote: > > > +1 > > > > Through writing a few revisions of these specs, I have also already=20 > found TCP to be really awkward. And the TCP negotiation discussions at = > the mike in Anaheim made me even more skeptical. Tom is right, if you=20 > need TCP then just use HTTP ;-) > > > > Zach > > > > On May 11, 2010, at 18:49 , Thomas Herbst wrote: > > > >> After the discussion in Anaheim, I'm surprised that we need yet=20 > another revisit to UDP and TCP for CORE. > >> > >> The Right Solution(tm) might well be to fix TCP such that it=20 > doesn't lose its brains every time you drop a packet, and we could end = > up with an end-to-end system where constrained devices might=20 > reasonably provide services to normal hosts in the regular Internet, =20 > However, transport work is out of scope for this WG. > >> > >> The second most right solution would be to implement CORE with a=20 > reliable UDP protocol, as is done in much of the draft. The=20 > "optional" TCP portions of the draft are mostly increased complexity=20 > for no added benefit. If a device is capable of running TCP and the=20 > network it works on is capable of supporting TCP, you should just open = > a connection to Port 80 and use HTTP (or the TCP port/protocol of your = > choice). There are many protocols a host MAY implement and it is not=20 > appropriate for the draft to enumerate them. > >> > >> Let's remove all of the sections related to TCP in the draft. > >> > >> tom > >> > >> > >> _______________________________________________ > >> core mailing list > >> core@ietf.org > >> https://www.ietf.org/mailman/listinfo/core > > > > -- > > Zach Shelby, Head of Research, Sensinode Ltd. > > http://zachshelby.org - My blog "On the Internet of Things" > > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded = Internet" > > Mobile: +358 40 7796297 > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > =20 ------_=_NextPart_001_01CAF2AF.50364A7C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [core] Core UDP vs TCP : Redux

Hi Robert,

I think it makes sense to look at integrating such requirements into = CoAP itself (or whatever higher level protocol is used). How TFTP for = instance adds reliability & fragmentation onto UDP.

core-coap-01 does have an "acknowledgement" flag, which when = sent with a request means it MUST generate a response. A simple = fragmentation flag could be added perhaps to support larger = messages.

Which would be a combination of 3 & 4 maybe? Although I've not = thought about it very hard, so if I'm missing something obvious about = why this won't work be sure to call me out on that ;-)

Regards,

   -Colin

-----Original Message-----
From: core-bounces@ietf.org on behalf of Robert Cragie
Sent: Wed 12/05/2010 22:46
To: core@ietf.org
Subject: Re: [core] Core UDP vs TCP : Redux

If we specify UDP only as transport, for delivery we need to = consider
the following:

   1. UDP is adequate for the transport's client applications = delivery as is
   2. The transport's client applications provides delivery = mechanisms
      appropriately according to their = requirements
   3. Creating a shim layer above UDP for improving delivery = and
      providing a homogeneous interface to = client applications
   4. Creating a framework (SASL-like), separating the = protocols and the
      mechanisms to promote reuse across = applications.

(1) may be the case in very simple delivery where it doesn't really
matter if the odd packet gets lost, e.g. non-critical temperature
readings. This could allow for very simple transmit-only devices. = (2)
would make sense but could mean implementing multiple similar but = subtly
different mechanisms multiple times in a device which serves = different
applications. These may be pretty simple, including lock-step
transactions using 'short' packets, i.e. fitting into one UDP = datagram.
(3) seems to be frowned upon and seems that it may be out of scope = for
the WG, although would probably be more efficient on the basis that
there is a common set of requirements for reliable delivery. (4) = could
work, providing a half-way between (2) and (3)

Back to (2), for example, DTLS implements its own reliability = mechanism
- could this be reused by other applications?

I think the framework idea might be worth exploring further although = I
am not entirely sure whether reliability mechanisms can be = classified
appropriately with common interfaces in this way.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com <http://www.gridmerge.com/>


On 12/05/2010 2:13 AM, Oflynn, Colin wrote:
>
> Hello,
>
> >This works as long as you can guarantee that the response is = < MTU.
>
> Which the current draft does. If we go the UDP route, I think we = need
> to add support for larger packets through some simple = fragmentation.
>
> You won't need such large packets often! So it doesn't have to be = very
> efficient, just every so often you need to transmit a large frame = for
> a file load, encryption, etc.
>
> Regards,
>
>   -Colin
>
>
> -----Original Message-----
> From: core-bounces@ietf.org on behalf of Thomas Herbst
> Sent: Wed 12/05/2010 02:11
> To: Henning Schulzrinne; Zach Shelby
> Cc: core@ietf.org
> Subject: Re: [core] Core UDP vs TCP : Redux
>
> On TCP vs UDP - we need to pick one.  Deciding to use both UDP = and TCP
> is just not making a decision.
>
> You expect people who didn't include enough memory in their devices = to
> implement TCP to do both UDP and TCP?
>
> On security, is there a problem w/ DTLS?
>
> tom
>
> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Tuesday, May 11, 2010 3:02 PM
> To: Zach Shelby
> Cc: Thomas Herbst; core@ietf.org
> Subject: Re: [core] Core UDP vs TCP : Redux
>
> This works as long as you can guarantee that the response is < = MTU.
> Doing your own fragmentation is a pain (you are then well on your = way
> to re-inventing TCP) and relying on IP fragmentation is unlikely = to
> work in "challenged" networks. Thus, these applicability = limitations
> need to be spelled out very clearly. This also has security
> implications - obviously, TLS is out without TCP, but anything
> involving certificates is also likely to be difficult to carry.
>
> Henning
>
> On May 11, 2010, at 5:06 PM, Zach Shelby wrote:
>
> > +1
> >
> > Through writing a few revisions of these specs, I have also = already
> found TCP to be really awkward. And the TCP negotiation discussions = at
> the mike in Anaheim made me even more skeptical. Tom is right, if = you
> need TCP then just use HTTP ;-)
> >
> > Zach
> >
> > On May 11, 2010, at 18:49 , Thomas Herbst wrote:
> >
> >> After the discussion in Anaheim, I'm surprised that we = need yet
> another revisit to UDP and TCP for CORE.
> >>
> >> The Right Solution(tm) might well be to fix TCP such that = it
> doesn't lose its brains every time you drop a packet, and we could = end
> up with an end-to-end system where constrained devices might
> reasonably provide services to normal hosts in the regular = Internet, 
> However, transport work is out of scope for this WG.
> >>
> >> The second most right solution would be to implement CORE = with a
> reliable UDP protocol, as is done in much of the draft.  = The
> "optional" TCP portions of the draft are mostly increased = complexity
> for no added benefit. If a device is capable of running TCP and = the
> network it works on is capable of supporting TCP, you should just = open
> a connection to Port 80 and use HTTP (or the TCP port/protocol of = your
> choice).  There are many protocols a host MAY implement and it = is not
> appropriate for the draft to enumerate them.
> >>
> >> Let's remove all of the sections related to TCP in the = draft.
> >>
> >> tom
> >>
> >>
> >> _______________________________________________
> >> core mailing list
> >> core@ietf.org
> >> https://www.ietf.org/= mailman/listinfo/core
> >
> > --
> > Zach Shelby, Head of Research, Sensinode Ltd.
> > http://zachshelby.org  - My blog = "On the Internet of Things"
> > http://6lowpan.net - My = book "6LoWPAN: The Wireless Embedded Internet"
> > Mobile: +358 40 7796297
> >
> > _______________________________________________
> > core mailing list
> > core@ietf.org
> > https://www.ietf.org/= mailman/listinfo/core
> >
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/= mailman/listinfo/core
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/= mailman/listinfo/core
>   

------_=_NextPart_001_01CAF2AF.50364A7C-- From angelo.castellani@gmail.com Fri May 14 01:50:37 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 059FC28C0EA for ; Fri, 14 May 2010 01:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.277 X-Spam-Level: X-Spam-Status: No, score=-0.277 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuB2oeR4rHOf for ; Fri, 14 May 2010 01:50:35 -0700 (PDT) Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com [209.85.211.173]) by core3.amsl.com (Postfix) with ESMTP id 2BE9F3A6A8B for ; Fri, 14 May 2010 01:50:35 -0700 (PDT) Received: by ywh3 with SMTP id 3so1244135ywh.31 for ; Fri, 14 May 2010 01:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=LDGU3YYfuaD15VbqcUl6+aFDHuHi9O2ZKyDCmiwYhHU=; b=UwGswV6WtS0B7PmSFELsysqQZWP0hbY2ifkHbfCuBPYfuBQZALufaanxAOrmRpDbEB syRy7XTus9Vcsimd7Mg/8FEHPF5bfcjLEEFd1WbOh77JmWRkZ5hWG1QiebDweNTt7Zuq xix0EimlT+03fv1ELhjEvfCPQOWwdcbTTPcnE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=JUSaI1fvyX6lLapJmRKLsJ4oFsEzTz2kW3QoT6Pv+K4B1oe2Wx1uCn4WBR76oIbV0/ NJdR3smLzP1Y7YN92EDRqI0G+H8LziP0bW2/dlPZW8TbiHgLsxH34GNMSzEdJOu/KqeI XWRuZTWj8EmX7tAGxkIubxHaWltExc+3oG5AU= MIME-Version: 1.0 Received: by 10.91.7.2 with SMTP id k2mr728325agi.108.1273827022170; Fri, 14 May 2010 01:50:22 -0700 (PDT) Sender: angelo.castellani@gmail.com Received: by 10.90.26.2 with HTTP; Fri, 14 May 2010 01:50:22 -0700 (PDT) In-Reply-To: <568AEFD6-974D-4790-A2F8-84305B990BA9@cisco.com> References: <3BB5F67A-9E57-4F81-B7C5-ABB1E136DAAC@tzi.org> <568AEFD6-974D-4790-A2F8-84305B990BA9@cisco.com> Date: Fri, 14 May 2010 10:50:22 +0200 X-Google-Sender-Auth: d_oJi9KNU3oo4_estnOE-3sO27s Message-ID: From: "Angelo P. Castellani" To: Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core Subject: Re: [core] Selecting a WG document for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 08:50:37 -0000 Cullen, thanks for the excellent understanding of my doubts. Point (a) is exactly about the very initial design approach to define a new realization of REST (e.g.: CRUD methods were defined instead of standard HTTP methods) instead of a feature-limited adaptation of HTTP itself to constrained host/network environments. There was even discussion on defining mapping of various protocols to CoAP without clear focus on HTTP translation. Doubts were raised that CoAP may be following the "reinvent HTTP" road, killing itself just as WAP did. Discussion on URI-Code/BinaryURI (as detailed in the Transparent proxying CoAP mail) is just the tip of the iceberg. Draft -01 has made some valid enhancements on this topic (see HTTP methods), however the whole document subtly imply this design objective throughout. In my humble opinion the direction that can be followed is: If HTTP/TCP is not viable on CoRE, we should find a way to adapt it to this environment. These days I was reading the R. Fielding PhD dissertation to fully understand why HTTP was designed in that way and what are the important principles to be preserved in a feature-limited compressed adaptation. Design philosophy: CoAP should be a *stateless* HTTP-translation and we should start by understanding how we can compress HTTP preserving its core principles to be *stateless*, providing an *uniform* interface to access *diverse* content organized in a *hierarchical* fashion, it should be easily *cacheable* and *translatable*. Being pratical: -* uniformity leads to only request and response (no notify, no other message types, REST should be only REQ/RES) -* hierarchy leads to URI and BinaryURI as in the transparent proxying discussion (no flat codes like URI-Code) -* stateless, translation, cacheability lead to URI->BinaryURI as a stateless mapping (avoid stateful tables) -* stateless and diversity suggest that content should be always fully described Content-Lenght (req), Content-Type (req) and Content-Enconding should be supported -* cacheable flag should be included always (not an option) -* stateless server and stateful resources? cookies are required (lets use binary cookies) Other considerations, important in my opinion, on the realization of the protocol (more technical here): -* translation and compression should focus on the URI =A0 a) It should be always present and not an option =A0 b) Using a flag we should understand whether we are using URI or the lossy BinaryURI encoding =A0 c) URI is ASCII-7 and is usually formed by chars, numbers and a few others? I propose to investigate compressed loss-less encodings. Now I can think at least two different encodings: =A0 =A0 =A0 i) Represent the / (supposed to be most frequent char in URI) using the left-most unused bit in the octet =A0 =A0 =A0 ii) Represent most frequent chars (regex format: [0-9a-zA-Z/]) using 6 bit encoding, use a NULL (\x00) octet to signal that an uncompressed char is following. Every 3 compressed chars we have 6 unused bits that can map another char (0.75 ratio in the best case, other cases to be evaluated). Maybe some predefined vocabularies can be agreed, and the used vocabulary chosen in a preceding field (vocabulary 2 example: [a-zA-Z%+._/\|=3D&?-]) -* option translation issues (addressing complex implementation), general rule avoid variable length options (harder to handle): =A0a) Messages with Payload should always carry Content-Length and Content-Type before the payload =A0b) Define which are the well-known request and response options we want to support, without merging them (it seems not a good choice because many are response specific only, and many other request specific only). =A0 =A0 =A0Well-known options present in the message should be represented in a binary bitmask (like in 6LoWPAN HC) and carried in-line (fixed-length is an important requirement, however variable length can be handled if cannot be avoided) When similar options are available may be beneficial to prefer the simplest and easiest to compress (fixed-length). Example: Last-Modified should be preferred to Etag, (1) it can be represented as an unsigned integer, (2) with a binary flag representing "Now" its insertion can be delegated to the HTTP translating entity, (3) supports conditional GET. =A0c) Other options compressed with the URI style encoding (better vocabulary here is [a-zA-Z%+._/\|=3D&?-]) I'm quite confident that the final compression ratio is good and, if properly investigated, it should retain the ability to do CoAP->HTTP translation too (Host option required). Moreover using CoAP realized like this leads to an easier straightforward C implementation, mainly thanks to many specific details especially bitmasks, fixed-length options, bitwise operations. I hope I was able to give an idea of my thinking on these issues. A more exhaustive and detailed list of the issues is not easy to provide by e-mail, but I will be happy to draft a document with more details if this is considered as an useful contribution to this discussion. Best, Angelo On Thu, May 13, 2010 at 16:57, Cullen Jennings wrote: > > Angelo, > > I may be reading too much in between the lines here, but I think you are = raising the overall design question of should we use some form of compresse= d HTTP, where we preserver the semantics of HTTP but encode it differently,= or should we develop a protocol with a subset of the semantics of HTTP. Pe= rhaps I have this all wrong and you are not raising that. Could you outline= some proposed solutions to your a,b,c problems below and perhaps say a bit= more about what the problem is. Once I understood a bit more about how you= would propose to design the protocol to mitigate these problems, I think t= hat would help everyone make informed choices. > > Thanks, Cullen > > Few more questions inline .... > > On May 13, 2010, at 5:24 AM, Angelo P. Castellani wrote: > >> Dear C. Bormann, all, >> >> before deciding for the final direction, I've the following >> observations about draft-shelby-core-coap-01 >> >> While I mostly share Zach's view of the protocol approach, and >> appreciate many aspects of the proposal, there are in my opinion still >> some open issues that need to be at least discussed before the current >> document can be selected. >> >> In particular, I would like to highlight the following: >> >> a) As it is now, it is not possible to have a straightforward >> translation of HTTP -> CoAP and viceversa: see >> http://www.ietf.org/mail-archive/web/core/current/msg00133.html (this >> impacts the scalability of the web service model too) > > On the topic of how to encode the URI. I think that needs discussion but = could easily happen (and would happen) even if the COAP document was adopte= d as a WG item now. > >> >> b) Moreover, CoAP's implementation is not as simple as it should be. >> I've investigated the implementation and some design choices (as >> Options) are leading to very high program complexity (ROM) on a >> MSP430-based device. > > Can you say more - particularly about proposals to fix it? > >> >> c) Finally when comparing HTTP message size with CoAP message size, >> the resulting compression isn't as good as you may expect. >> >> Example: >> HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B >> CoAP: 24 B with options parsing procedure requiring an added >> implementation complexity >> >> Addressing all these points potentially leads to major technical >> modifications (especially point a) on the current draft, hence it is >> appropriate in my opinion to discuss these points before making the >> final decision. >> >> Best regards, >> >> Angelo P. Castellani >> >> >> On Mon, May 10, 2010 at 18:51, Carsten Bormann wrote: >>> The CORE WG has a milestone to select a WG document for CoAP in April: >>> >>> http://datatracker.ietf.org/wg/core/charter/ >>> ... >>> Apr 2010 =A0 =A0 =A0 =A0Select WG document for basis of the CoAP protoc= ol >>> >>> Of the various documents that have been contributed, draft-shelby-core-= coap has significant discussion, as well as the largest number of updates (= including a previous version that was still called -6lowapp-coap). >>> >>> Today, another updated version of that draft was announced. =A0See >>> http://www.ietf.org/mail-archive/web/core/current/msg00138.html >>> for the announcement and >>> http://tools.ietf.org/html/draft-shelby-core-coap-01 >>> for the draft itself. >>> >>> However, as the authors say, there are still significant TODOs. >>> >>> Are we in a state yet where we can say whether this is the right direct= ion for the WG to take? >>> If yes, is it the right direction? =A0Should we adopt it as a WG docume= nt? >>> If you don't think we can say yet, is there a set of technical decision= s you would like the authors to take with priority? >>> >>> Note that once a document has become a WG document, the authors act as = editors for the working group, making (and usually fleshing out the details= of) any change that the WG decides it needs. >>> If you think we can still improve the draft, this is not an obstacle to= making it a WG document. >>> But of course we shouldn't do that if we intend to reverse its fundamen= tal technical direction. >>> >>> In order to stay roughly in sync with our milestones, we should reach a= t a decision on how to go forward this week. >>> >>> Gruesse, Carsten >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > From zach@sensinode.com Fri May 14 04:06:24 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E93D128C0DC for ; Fri, 14 May 2010 04:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.277 X-Spam-Level: X-Spam-Status: No, score=-0.277 tagged_above=-999 required=5 tests=[AWL=-1.578, BAYES_50=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hX5oXGVz3iWz for ; Fri, 14 May 2010 04:06:22 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 7BCF33A6AEB for ; Fri, 14 May 2010 04:06:13 -0700 (PDT) Received: from [192.168.1.2] (line-4979.dyn.kponet.fi [85.29.65.197]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o4EB5w18015402 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 May 2010 14:05:59 +0300 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Fri, 14 May 2010 14:06:11 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1EFE7D38-0894-4557-84F9-5553E5EF6A04@sensinode.com> References: <3BB5F67A-9E57-4F81-B7C5-ABB1E136DAAC@tzi.org> To: "Angelo P. Castellani" X-Mailer: Apple Mail (2.1077) Cc: core Subject: Re: [core] Selecting a WG document for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 11:06:24 -0000 Hi Angelo, On May 13, 2010, at 14:24 , Angelo P. Castellani wrote: > Dear C. Bormann, all, >=20 > before deciding for the final direction, I've the following > observations about draft-shelby-core-coap-01 >=20 > While I mostly share Zach's view of the protocol approach, and > appreciate many aspects of the proposal, there are in my opinion still > some open issues that need to be at least discussed before the current > document can be selected. Of course there are plenty of open issues. Remember that working group = documents still undertake as much change and improvement as the WG = wants, so by no means is coap-01 set in stone. I would expect at least = 5-10 more revisions still along the way. Already several of your ideas = have been integrated into coap-01, and several more are under = consideration, so it is coming along. Patience ;-)=20 >=20 > In particular, I would like to highlight the following: >=20 > a) As it is now, it is not possible to have a straightforward > translation of HTTP -> CoAP and viceversa: see > http://www.ietf.org/mail-archive/web/core/current/msg00133.html (this > impacts the scalability of the web service model too) In coap-01 the Method names are now identical to HTTP methods. The = Req/Res interaction is a direct translation. The URI hierarchy is = compatible, and the URI binary code format we are still working on = obviously. The only thing that takes some state to translate is = Subscribe/Notify. But note, Subscribe/Notify takes some state no matter = how you do it, even with HTTP-HTTP there is no clean and easy way to = handle subscriptions. =20 >=20 > b) Moreover, CoAP's implementation is not as simple as it should be. > I've investigated the implementation and some design choices (as > Options) are leading to very high program complexity (ROM) on a > MSP430-based device. This we can definitely improve, and already made several optimizations = from -00 to -01. Here I need some very concrete proposals though. Also = remember that many things are optional, for example subscribe/notify is = not required if you don't need it.=20 > c) Finally when comparing HTTP message size with CoAP message size, > the resulting compression isn't as good as you may expect. >=20 > Example: > HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B > CoAP: 24 B with options parsing procedure requiring an added > implementation complexity Right, that is not how it will work in practice. Working with a real = HTTP server that HTTP header will be more complex, and on the CoAP side = you would chose shorter URLs. The biggest improvement possible here is = from using binary coded URLs of course. We need to look at a wider range = of interactions and real HTTP headers as well to check that we are = efficient enough. =20 > Addressing all these points potentially leads to major technical > modifications (especially point a) on the current draft, hence it is > appropriate in my opinion to discuss these points before making the > final decision. I am not sure what else you have in mind for a). If we just forget about = Subscribe/Notify then you are good to go. But then you are also not = fulfilling the charter or the industry needs in that respect.=20 Thanks, Zach >=20 > Best regards, >=20 > Angelo P. Castellani >=20 >=20 > On Mon, May 10, 2010 at 18:51, Carsten Bormann wrote: >> The CORE WG has a milestone to select a WG document for CoAP in = April: >>=20 >> http://datatracker.ietf.org/wg/core/charter/ >> ... >> Apr 2010 Select WG document for basis of the CoAP protocol >>=20 >> Of the various documents that have been contributed, = draft-shelby-core-coap has significant discussion, as well as the = largest number of updates (including a previous version that was still = called -6lowapp-coap). >>=20 >> Today, another updated version of that draft was announced. See >> http://www.ietf.org/mail-archive/web/core/current/msg00138.html >> for the announcement and >> http://tools.ietf.org/html/draft-shelby-core-coap-01 >> for the draft itself. >>=20 >> However, as the authors say, there are still significant TODOs. >>=20 >> Are we in a state yet where we can say whether this is the right = direction for the WG to take? >> If yes, is it the right direction? Should we adopt it as a WG = document? >> If you don't think we can say yet, is there a set of technical = decisions you would like the authors to take with priority? >>=20 >> Note that once a document has become a WG document, the authors act = as editors for the working group, making (and usually fleshing out the = details of) any change that the WG decides it needs. >> If you think we can still improve the draft, this is not an obstacle = to making it a WG document. >> But of course we shouldn't do that if we intend to reverse its = fundamental technical direction. >>=20 >> In order to stay roughly in sync with our milestones, we should reach = at a decision on how to go forward this week. >>=20 >> Gruesse, 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 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From angelo.castellani@gmail.com Fri May 14 05:15:34 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29C3C3A6AC4 for ; Fri, 14 May 2010 05:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.053 X-Spam-Level: * X-Spam-Status: No, score=1.053 tagged_above=-999 required=5 tests=[AWL=-1.870, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4nUG6PIzMJ9 for ; Fri, 14 May 2010 05:15:32 -0700 (PDT) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.210.182]) by core3.amsl.com (Postfix) with ESMTP id B87693A6ACE for ; Fri, 14 May 2010 05:14:41 -0700 (PDT) Received: by yxe12 with SMTP id 12so1086287yxe.32 for ; Fri, 14 May 2010 05:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=Xu4eySzAsmZnjgG0tLwCQTvf+ezVuUgedifUDv/mne0=; b=KIKdP5eEhutVG551j0WvDgwode/kSdYr5BQkxEFOy2hojKFB7mQdHnW83fIFBCYX/Y Dide1d6LHoD2TfXPUPNZdo+HTVEzG3kQbhjUmTgAappQmtE3fgzQeKz3uoMDRcNyUnwu NP4PadzsYXaOXwb/eaCe1zkt38+QcdAPueKhM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=I8UuQpv0ebUPzLYRs2mRYGY7bMmTU0agroHIKtxdHYuGFSN7luHhrds3X1DbJWSz/6 9sg9zs1UoejD0r8gheCuQxPHfXjFq2THIA5MmZBE5iMC9z5+vJEtTBQ6h6TTtsUeePCK GHHJDcKmngZDxJUqlCsJdUhe8rVM5twlLmSNA= Received: by 10.91.109.2 with SMTP id l2mr916900agm.53.1273839267308; Fri, 14 May 2010 05:14:27 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.90.26.2 with HTTP; Fri, 14 May 2010 05:14:07 -0700 (PDT) In-Reply-To: <1EFE7D38-0894-4557-84F9-5553E5EF6A04@sensinode.com> References: <3BB5F67A-9E57-4F81-B7C5-ABB1E136DAAC@tzi.org> <1EFE7D38-0894-4557-84F9-5553E5EF6A04@sensinode.com> From: "Angelo P. Castellani" Date: Fri, 14 May 2010 14:14:07 +0200 X-Google-Sender-Auth: qGc-QeMJR3lNqjHPlmRIteFn5B0 Message-ID: To: Zach Shelby Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core Subject: Re: [core] Selecting a WG document for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 12:15:34 -0000 Zach, thanks for the comments, but please refer to my most recent e-mail for a more specific list of technical issues I'm pointing to. I want to do only a little integration to what I've written there. In my very personal opinion, to maximize adherence with the REST model and minimize implementation effort SUBSCRIBE and NOTIFY should be mapped to methods (as discussed many times together...). Uniform interface principle (Fielding PhD dissertation Section 5.1.5, "The central feature that distinguishes the REST architectural style [...]") states that to simplify the software architecture, resource interfaces/interfaces should be as general as possible. I agree with this principle in this specific case, mainly because handling a special message type for notify leads node software design to a more complex architecture. The reason is that this new message type requires special handling and introduces a complexity in the software modularization. Best, Angelo On Fri, May 14, 2010 at 13:06, Zach Shelby wrote: > Hi Angelo, > > On May 13, 2010, at 14:24 , Angelo P. Castellani wrote: > >> Dear C. Bormann, all, >> >> before deciding for the final direction, I've the following >> observations about draft-shelby-core-coap-01 >> >> While I mostly share Zach's view of the protocol approach, and >> appreciate many aspects of the proposal, there are in my opinion still >> some open issues that need to be at least discussed before the current >> document can be selected. > > Of course there are plenty of open issues. Remember that working group do= cuments still undertake as much change and improvement as the WG wants, so = by no means is coap-01 set in stone. I would expect at least 5-10 more revi= sions still along the way. Already several of your ideas have been integra= ted into coap-01, and several more are under consideration, so it is coming= along. Patience ;-) > >> >> In particular, I would like to highlight the following: >> >> a) As it is now, it is not possible to have a straightforward >> translation of HTTP -> CoAP and viceversa: see >> http://www.ietf.org/mail-archive/web/core/current/msg00133.html (this >> impacts the scalability of the web service model too) > > In coap-01 the Method names are now identical to HTTP methods. The Req/Re= s interaction is a direct translation. The URI hierarchy is compatible, and= the URI binary code format we are still working on obviously. The only thi= ng that takes some state to translate is Subscribe/Notify. But note, Subscr= ibe/Notify takes some state no matter how you do it, even with HTTP-HTTP th= ere is no clean and easy way to handle subscriptions. > >> >> b) Moreover, CoAP's implementation is not as simple as it should be. >> I've investigated the implementation and some design choices (as >> Options) are leading to very high program complexity (ROM) on a >> MSP430-based device. > > This we can definitely improve, and already made several optimizations fr= om -00 to -01. Here I need some very concrete proposals though. Also rememb= er that many things are optional, for example subscribe/notify is not requi= red if you don't need it. > >> c) Finally when comparing HTTP message size with CoAP message size, >> the resulting compression isn't as good as you may expect. >> >> Example: >> HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B >> CoAP: 24 B with options parsing procedure requiring an added >> implementation complexity > > Right, that is not how it will work in practice. Working with a real HTTP= server that HTTP header will be more complex, and on the CoAP side you wou= ld chose shorter URLs. The biggest improvement possible here is from using = binary coded URLs of course. We need to look at a wider range of interactio= ns and real HTTP headers as well to check that we are efficient enough. > >> Addressing all these points potentially leads to major technical >> modifications (especially point a) on the current draft, hence it is >> appropriate in my opinion to discuss these points before making the >> final decision. > > I am not sure what else you have in mind for a). If we just forget about = Subscribe/Notify then you are good to go. But then you are also not fulfill= ing the charter or the industry needs in that respect. > > Thanks, > Zach > >> >> Best regards, >> >> Angelo P. Castellani >> >> >> On Mon, May 10, 2010 at 18:51, Carsten Bormann wrote: >>> The CORE WG has a milestone to select a WG document for CoAP in April: >>> >>> http://datatracker.ietf.org/wg/core/charter/ >>> ... >>> Apr 2010 Select WG document for basis of the CoAP protocol >>> >>> Of the various documents that have been contributed, draft-shelby-core-= coap has significant discussion, as well as the largest number of updates (= including a previous version that was still called -6lowapp-coap). >>> >>> Today, another updated version of that draft was announced. See >>> http://www.ietf.org/mail-archive/web/core/current/msg00138.html >>> for the announcement and >>> http://tools.ietf.org/html/draft-shelby-core-coap-01 >>> for the draft itself. >>> >>> However, as the authors say, there are still significant TODOs. >>> >>> Are we in a state yet where we can say whether this is the right direct= ion for the WG to take? >>> If yes, is it the right direction? Should we adopt it as a WG document= ? >>> If you don't think we can say yet, is there a set of technical decision= s you would like the authors to take with priority? >>> >>> Note that once a document has become a WG document, the authors act as = editors for the working group, making (and usually fleshing out the details= of) any change that the WG decides it needs. >>> If you think we can still improve the draft, this is not an obstacle to= making it a WG document. >>> But of course we shouldn't do that if we intend to reverse its fundamen= tal technical direction. >>> >>> In order to stay roughly in sync with our milestones, we should reach a= t a decision on how to go forward this week. >>> >>> Gruesse, Carsten >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > From darco@deepdarc.com Fri May 14 13:23:43 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7FFB3A688A for ; Fri, 14 May 2010 13:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEyx1IVHOxbD for ; Fri, 14 May 2010 13:23:37 -0700 (PDT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id D5A813A67E5 for ; Fri, 14 May 2010 13:23:36 -0700 (PDT) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out4.apple.com (Postfix) with ESMTP id E2E7799C64C6; Fri, 14 May 2010 13:23:27 -0700 (PDT) X-AuditID: 1180711d-b7c17ae00000693e-d7-4bedb13f6119 Received: from bellatrix.apple.com (bellatrix.apple.com [17.202.32.104]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id 9D.5B.26942.F31BDEB4; Fri, 14 May 2010 13:23:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-8--791336185 From: Robert Quattlebaum In-Reply-To: Date: Fri, 14 May 2010 13:23:27 -0700 Message-Id: <180ECE5C-7013-4A75-BE1F-DD479C128C38@deepdarc.com> References: <3BB5F67A-9E57-4F81-B7C5-ABB1E136DAAC@tzi.org> <568AEFD6-974D-4790-A2F8-84305B990BA9@cisco.com> To: Angelo P. Castellani X-Mailer: Apple Mail (2.1078) X-Brightmail-Tracker: AAAAAQAAAZE= Cc: core Subject: Re: [core] Selecting a WG document for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 20:23:43 -0000 --Apple-Mail-8--791336185 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Pardon if my reasoning seems a bit scattered, I have a lot of thoughts = on the subject but not a lot of time to write this email. It was my hope that CoAP might be the protocol to which, if devices = conformed, I (as a consumer) would be able to know that they would be = able to interoperate=97perhaps not without configuration, but at least = after such manual configuration they would be able to communicate with = each other without a third device translating things. Things like light = switches, motion sensors, moisture detectors, appliances, thermostats, = etc. I was imagining something akin to a modernized, push version of = SNMP; at least in spirit. (See = for a = better example) My concern is that HTTP is a clearly client-server based protocol, with = a very clear delineation between the clients and the servers. With CoAP, = the cases where there is such a clear server/client delineation is = likely going to be much less common than cases where everyone is a peer. = Thus it seems reasonable to deviate (where appropriate) from the HTTP = model=97even in cases where there is no direct HTTP analogue. As such, I = think having a SUBSCRIBE or PAIR method makes sense. All of these devices are stateful to some degree, but there are two = types of state: volatile (runtime) state, and non-volatile = (configuration) state. I think that the subscriptions/pairings should be = a non-volatile state. e.g.: no expirations. But I digress... Taking a step back, what is the compelling use case for a strict mapping = between HTTP and CoAP? I think HTTP might be useful as a model, but I = haven't really understood why we should make mapping between the two a = design consideration. (As a related side observation, I think what would help is if we = developed some specific use cases for how CoAP is envisioned to be used) On May 14, 2010, at 1:50 AM, Angelo P. Castellani wrote: > Point (a) is exactly about the very initial design approach to define > a new realization of REST (e.g.: CRUD methods were defined instead of > standard HTTP methods) instead of a feature-limited adaptation of HTTP > itself to constrained host/network environments. >=20 > There was even discussion on defining mapping of various protocols to > CoAP without clear focus on HTTP translation. >=20 > Doubts were raised that CoAP may be following the "reinvent HTTP" > road, killing itself just as WAP did. Discussion on URI-Code/BinaryURI > (as detailed in the Transparent proxying CoAP mail) is just the tip of > the iceberg. >=20 > Draft -01 has made some valid enhancements on this topic (see HTTP > methods), however the whole document subtly imply this design > objective throughout. >=20 > In my humble opinion the direction that can be followed is: If > HTTP/TCP is not viable on CoRE, we should find a way to adapt it to > this environment. >=20 > These days I was reading the R. Fielding PhD dissertation to fully > understand why HTTP was designed in that way and what are the > important principles to be preserved in a feature-limited compressed > adaptation. >=20 > Design philosophy: CoAP should be a *stateless* HTTP-translation and > we should start by understanding how we can compress HTTP preserving > its core principles to be *stateless*, providing an *uniform* > interface to access *diverse* content organized in a *hierarchical* > fashion, it should be easily *cacheable* and *translatable*. >=20 > Being pratical: > -* uniformity leads to only request and response (no notify, no other > message types, REST should be only REQ/RES) >=20 > -* hierarchy leads to URI and BinaryURI as in the transparent proxying > discussion (no flat codes like URI-Code) >=20 > -* stateless, translation, cacheability lead to URI->BinaryURI as a > stateless mapping (avoid stateful tables) >=20 > -* stateless and diversity suggest that content should be always fully > described Content-Lenght (req), Content-Type (req) and > Content-Enconding should be supported >=20 > -* cacheable flag should be included always (not an option) >=20 > -* stateless server and stateful resources? cookies are required (lets > use binary cookies) >=20 >=20 > Other considerations, important in my opinion, on the realization of > the protocol (more technical here): >=20 > -* translation and compression should focus on the URI >=20 > a) It should be always present and not an option >=20 > b) Using a flag we should understand whether we are using URI or the > lossy BinaryURI encoding >=20 > c) URI is ASCII-7 and is usually formed by chars, numbers and a few > others? I propose to investigate compressed loss-less encodings. Now I > can think at least two different encodings: > i) Represent the / (supposed to be most frequent char in URI) > using the left-most unused bit in the octet > ii) Represent most frequent chars (regex format: [0-9a-zA-Z/]) > using 6 bit encoding, use a NULL (\x00) octet to signal that an > uncompressed char is following. Every 3 compressed chars we have 6 > unused bits that can map another char (0.75 ratio in the best case, > other cases to be evaluated). > Maybe some predefined vocabularies can be agreed, and the used > vocabulary chosen in a preceding field (vocabulary 2 example: > [a-zA-Z%+._/\|=3D&?-]) >=20 >=20 > -* option translation issues (addressing complex implementation), > general rule avoid variable length options (harder to handle): >=20 > a) Messages with Payload should always carry Content-Length and > Content-Type before the payload >=20 > b) Define which are the well-known request and response options we > want to support, without merging them (it seems not a good choice > because many are response specific only, and many other request > specific only). > Well-known options present in the message should be represented > in a binary bitmask (like in 6LoWPAN HC) and carried in-line > (fixed-length is an important requirement, however variable length can > be handled if cannot be avoided) > When similar options are available may be beneficial to prefer > the simplest and easiest to compress (fixed-length). > Example: Last-Modified should be preferred to Etag, (1) it can be > represented as an unsigned integer, (2) with a binary flag > representing "Now" its insertion can be delegated to the HTTP > translating entity, (3) supports conditional GET. >=20 > c) Other options compressed with the URI style encoding (better > vocabulary here is [a-zA-Z%+._/\|=3D&?-]) >=20 >=20 > I'm quite confident that the final compression ratio is good and, if > properly investigated, it should retain the ability to do CoAP->HTTP > translation too (Host option required). >=20 > Moreover using CoAP realized like this leads to an easier > straightforward C implementation, mainly thanks to many specific > details especially bitmasks, fixed-length options, bitwise operations. >=20 > I hope I was able to give an idea of my thinking on these issues. A > more exhaustive and detailed list of the issues is not easy to provide > by e-mail, but I will be happy to draft a document with more details > if this is considered as an useful contribution to this discussion. >=20 > Best, > Angelo >=20 > On Thu, May 13, 2010 at 16:57, Cullen Jennings = wrote: >>=20 >> Angelo, >>=20 >> I may be reading too much in between the lines here, but I think you = are raising the overall design question of should we use some form of = compressed HTTP, where we preserver the semantics of HTTP but encode it = differently, or should we develop a protocol with a subset of the = semantics of HTTP. Perhaps I have this all wrong and you are not raising = that. Could you outline some proposed solutions to your a,b,c problems = below and perhaps say a bit more about what the problem is. Once I = understood a bit more about how you would propose to design the protocol = to mitigate these problems, I think that would help everyone make = informed choices. >>=20 >> Thanks, Cullen >>=20 >> Few more questions inline .... >>=20 >> On May 13, 2010, at 5:24 AM, Angelo P. Castellani wrote: >>=20 >>> Dear C. Bormann, all, >>>=20 >>> before deciding for the final direction, I've the following >>> observations about draft-shelby-core-coap-01 >>>=20 >>> While I mostly share Zach's view of the protocol approach, and >>> appreciate many aspects of the proposal, there are in my opinion = still >>> some open issues that need to be at least discussed before the = current >>> document can be selected. >>>=20 >>> In particular, I would like to highlight the following: >>>=20 >>> a) As it is now, it is not possible to have a straightforward >>> translation of HTTP -> CoAP and viceversa: see >>> http://www.ietf.org/mail-archive/web/core/current/msg00133.html = (this >>> impacts the scalability of the web service model too) >>=20 >> On the topic of how to encode the URI. I think that needs discussion = but could easily happen (and would happen) even if the COAP document was = adopted as a WG item now. >>=20 >>>=20 >>> b) Moreover, CoAP's implementation is not as simple as it should be. >>> I've investigated the implementation and some design choices (as >>> Options) are leading to very high program complexity (ROM) on a >>> MSP430-based device. >>=20 >> Can you say more - particularly about proposals to fix it? >>=20 >>>=20 >>> c) Finally when comparing HTTP message size with CoAP message size, >>> the resulting compression isn't as good as you may expect. >>>=20 >>> Example: >>> HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B >>> CoAP: 24 B with options parsing procedure requiring an added >>> implementation complexity >>>=20 >>> Addressing all these points potentially leads to major technical >>> modifications (especially point a) on the current draft, hence it is >>> appropriate in my opinion to discuss these points before making the >>> final decision. >>>=20 >>> Best regards, >>>=20 >>> Angelo P. Castellani >>>=20 >>>=20 >>> On Mon, May 10, 2010 at 18:51, Carsten Bormann wrote: >>>> The CORE WG has a milestone to select a WG document for CoAP in = April: >>>>=20 >>>> http://datatracker.ietf.org/wg/core/charter/ >>>> ... >>>> Apr 2010 Select WG document for basis of the CoAP protocol >>>>=20 >>>> Of the various documents that have been contributed, = draft-shelby-core-coap has significant discussion, as well as the = largest number of updates (including a previous version that was still = called -6lowapp-coap). >>>>=20 >>>> Today, another updated version of that draft was announced. See >>>> http://www.ietf.org/mail-archive/web/core/current/msg00138.html >>>> for the announcement and >>>> http://tools.ietf.org/html/draft-shelby-core-coap-01 >>>> for the draft itself. >>>>=20 >>>> However, as the authors say, there are still significant TODOs. >>>>=20 >>>> Are we in a state yet where we can say whether this is the right = direction for the WG to take? >>>> If yes, is it the right direction? Should we adopt it as a WG = document? >>>> If you don't think we can say yet, is there a set of technical = decisions you would like the authors to take with priority? >>>>=20 >>>> Note that once a document has become a WG document, the authors act = as editors for the working group, making (and usually fleshing out the = details of) any change that the WG decides it needs. >>>> If you think we can still improve the draft, this is not an = obstacle to making it a WG document. >>>> But of course we shouldn't do that if we intend to reverse its = fundamental technical direction. >>>>=20 >>>> In order to stay roughly in sync with our milestones, we should = reach at a decision on how to go forward this week. >>>>=20 >>>> Gruesse, 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 >>=20 >>=20 >> Cullen Jennings >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>=20 >>=20 >>=20 >>=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 __________________ Robert Quattlebaum Jabber: darco@deepdarc.com eMail: darco@deepdarc.com www: http://www.deepdarc.com/ --Apple-Mail-8--791336185 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 h= ttp://www.ietf.org/mail-archive/web/core/current/msg00119.html> = for a better example)

My concern is that HTTP = is a clearly client-server based protocol, with a very clear delineation = between the clients and the servers. With CoAP, the cases where there is = such a clear server/client delineation is likely going to be much less = common than cases where everyone is a peer. Thus it seems reasonable to = deviate (where appropriate) from the HTTP model=97even in cases where = there is no direct HTTP analogue. As such, I think having a SUBSCRIBE or = PAIR method makes sense.

All of these devices = are stateful to some degree, but there are two types of state: volatile = (runtime) state, and non-volatile (configuration) state. I think = that the subscriptions/pairings should be a non-volatile state. e.g.: no = expirations. But I digress...

Taking a step = back, what is the compelling use case for a strict mapping between HTTP = and CoAP? I think HTTP might be useful as a model, but I haven't really = understood why we should make mapping between the two a design = consideration.

(As a related side observation, = I think what would help is if we developed some specific use cases for = how CoAP is envisioned to be used)

On May 14, = 2010, at 1:50 AM, Angelo P. Castellani wrote:

Point = (a) is exactly about the very initial design approach to define
a new = realization of REST (e.g.: CRUD methods were defined instead = of
standard HTTP methods) instead of a feature-limited adaptation of = HTTP
itself to constrained host/network environments.

There = was even discussion on defining mapping of various protocols to
CoAP = without clear focus on HTTP translation.

Doubts were raised that = CoAP may be following the "reinvent HTTP"
road, killing itself just = as WAP did. Discussion on URI-Code/BinaryURI
(as detailed in the = Transparent proxying CoAP mail) is just the tip of
the = iceberg.

Draft -01 has made some valid enhancements on this topic = (see HTTP
methods), however the whole document subtly imply this = design
objective throughout.

In my humble opinion the = direction that can be followed is: If
HTTP/TCP is not viable on CoRE, = we should find a way to adapt it to
this environment.

These = days I was reading the R. Fielding PhD dissertation to = fully
understand why HTTP was designed in that way and what are = the
important principles to be preserved in a feature-limited = compressed
adaptation.

Design philosophy: CoAP should be a = *stateless* HTTP-translation and
we should start by understanding how = we can compress HTTP preserving
its core principles to be = *stateless*, providing an *uniform*
interface to access *diverse* = content organized in a *hierarchical*
fashion, it should be easily = *cacheable* and *translatable*.

Being pratical:
-* uniformity = leads to only request and response (no notify, no other
message = types, REST should be only REQ/RES)

-* hierarchy leads to URI and = BinaryURI as in the transparent proxying
discussion (no flat codes = like URI-Code)

-* stateless, translation, cacheability lead to = URI->BinaryURI as a
stateless mapping (avoid stateful = tables)

-* stateless and diversity suggest that content should be = always fully
described Content-Lenght (req), Content-Type (req) = and
Content-Enconding should be supported

-* cacheable flag = should be included always (not an option)

-* stateless server and = stateful resources? cookies are required (lets
use binary = cookies)


Other considerations, important in my opinion, on = the realization of
the protocol (more technical here):

-* = translation and compression should focus on the URI

  a) It = should be always present and not an option

  b) Using a flag = we should understand whether we are using URI or the
lossy BinaryURI = encoding

  c) URI is ASCII-7 and is usually formed by chars, = numbers and a few
others? I propose to investigate compressed = loss-less encodings. Now I
can think at least two different = encodings:
      i) Represent the / (supposed to be = most frequent char in URI)
using the left-most unused bit in the = octet
      ii) Represent most frequent chars (regex = format: [0-9a-zA-Z/])
using 6 bit encoding, use a NULL (\x00) octet = to signal that an
uncompressed char is following. Every 3 compressed = chars we have 6
unused bits that can map another char (0.75 ratio in = the best case,
other cases to be evaluated).
=        Maybe some predefined = vocabularies can be agreed, and the used
vocabulary chosen in a = preceding field (vocabulary 2 = example:
[a-zA-Z%+._/\|=3D&?-])


-* option translation = issues (addressing complex implementation),
general rule avoid = variable length options (harder to handle):

 a) Messages = with Payload should always carry Content-Length and
Content-Type = before the payload

 b) Define which are the well-known = request and response options we
want to support, without merging them = (it seems not a good choice
because many are response specific only, = and many other request
specific only).
    =  Well-known options present in the message should be = represented
in a binary bitmask (like in 6LoWPAN HC) and carried = in-line
(fixed-length is an important requirement, however variable = length can
be handled if cannot be avoided)
=     When similar options are available may be = beneficial to prefer
the simplest and easiest to compress = (fixed-length).
    Example: Last-Modified = should be preferred to Etag, (1) it can be
represented as an unsigned = integer, (2) with a binary flag
representing "Now" its insertion can = be delegated to the HTTP
translating entity, (3) supports conditional = GET.

 c) Other options compressed with the URI style = encoding (better
vocabulary here is = [a-zA-Z%+._/\|=3D&?-])


I'm quite confident that the final = compression ratio is good and, if
properly investigated, it should = retain the ability to do CoAP->HTTP
translation too (Host option = required).

Moreover using CoAP realized like this leads to an = easier
straightforward C implementation, mainly thanks to many = specific
details especially bitmasks, fixed-length options, bitwise = operations.

I hope I was able to give an idea of my thinking on = these issues. A
more exhaustive and detailed list of the issues is = not easy to provide
by e-mail, but I will be happy to draft a = document with more details
if this is considered as an useful = contribution to this discussion.

Best,
Angelo

On Thu, = May 13, 2010 at 16:57, Cullen Jennings <fluffy@cisco.com> = wrote:

Angelo,

I may be = reading too much in between the lines here, but I think you are raising = the overall design question of should we use some form of compressed = HTTP, where we preserver the semantics of HTTP but encode it = differently, or should we develop a protocol with a subset of the = semantics of HTTP. Perhaps I have this all wrong and you are not raising = that. Could you outline some proposed solutions to your a,b,c problems = below and perhaps say a bit more about what the problem is. Once I = understood a bit more about how you would propose to design the protocol = to mitigate these problems, I think that would help everyone make = informed choices.

Thanks, = Cullen

Few more = questions inline ....

On May 13, = 2010, at 5:24 AM, Angelo P. Castellani = wrote:

Dear C. Bormann, = all,

before deciding for the final = direction, I've the following
observations about = draft-shelby-core-coap-01

While I mostly share Zach's view = of the protocol approach, and
appreciate many aspects of the = proposal, there are in my opinion = still
some open issues that need to be at least discussed before = the current
document can be = selected.

In particular, I would like to = highlight the following:

a) As it is now, it is not = possible to have a = straightforward
translation of HTTP -> CoAP = and viceversa: see
h= ttp://www.ietf.org/mail-archive/web/core/current/msg00133.html = (this
impacts the scalability of the web service model = too)

On the topic of = how to encode the URI. I think that needs discussion but could easily = happen (and would happen) even if the COAP document was adopted as a WG = item now.


b) Moreover, CoAP's = implementation is not as simple as it should = be.
I've investigated the implementation and some design = choices (as
Options) are leading to very = high program complexity (ROM) on = a
MSP430-based = device.

Can you say = more - particularly about proposals to fix = it?


c) Finally when comparing HTTP = message size with CoAP message = size,
the resulting compression isn't as good as you may = expect.

Example:
HTTP: GET /sensor/temp.xml = HTTP/1.0 =3D 32 B
CoAP: 24 B with options parsing = procedure requiring an added
implementation = complexity

Addressing all these points = potentially leads to major = technical
modifications (especially point = a) on the current draft, hence it = is
appropriate in my opinion to discuss these points before = making the
final = decision.

Best = regards,

Angelo P. = Castellani


On Mon, May 10, 2010 at 18:51, = Carsten Bormann <cabo@tzi.org> = wrote:
The CORE WG has a milestone to = select a WG document for CoAP in = April:

http://datatracker.i= etf.org/wg/core/charter/
...
Apr = 2010        Select WG document for basis of the CoAP = protocol

Of the = various documents that have been contributed, draft-shelby-core-coap has = significant discussion, as well as the largest number of updates = (including a previous version that was still called = -6lowapp-coap).

Today, = another updated version of that draft was announced. =  See
h= ttp://www.ietf.org/mail-archive/web/core/current/msg00138.html
for the announcement = and
http://tools= .ietf.org/html/draft-shelby-core-coap-01
=
for the draft = itself.

However,= as the authors say, there are still significant = TODOs.

Are we = in a state yet where we can say whether this is the right direction for = the WG to take?
If = yes, is it the right direction?  Should we adopt it as a WG = document?
If you = don't think we can say yet, is there a set of technical decisions you = would like the authors to take with = priority?

Note = that once a document has become a WG document, the authors act as = editors for the working group, making (and usually fleshing out the = details of) any change that the WG decides it = needs.
If you = think we can still improve the draft, this is not an obstacle to making = it a WG document.
But of = course we shouldn't do that if we intend to reverse its fundamental = technical = direction.

In = order to stay roughly in sync with our milestones, we should reach at a = decision on how to go forward this = week.

Gruesse,= Carsten

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

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


Cullen = Jennings
For corporate legal = information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html




___________________________________________= ____
core mailing list
core@ietf.org
https://www.ietf.org/ma= ilman/listinfo/core




= --Apple-Mail-8--791336185-- From d.sturek@att.net Fri May 14 13:33:52 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 778803A68BE for ; Fri, 14 May 2010 13:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.773 X-Spam-Level: X-Spam-Status: No, score=0.773 tagged_above=-999 required=5 tests=[AWL=-0.827, BAYES_40=-0.185, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qReGlvRMH3jS for ; Fri, 14 May 2010 13:33:36 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id EAF513A6403 for ; Fri, 14 May 2010 13:33:32 -0700 (PDT) Received: (qmail 1271 invoked from network); 14 May 2010 20:33:21 -0000 Received: from wsip-174-78-56-227.sd.sd.cox.net (d.sturek@174.78.56.227 with login) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 14 May 2010 13:33:21 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: R5LOX9oVM1k3EZfMjke8umjSC_M1s62_lWUy91Sqn.kAGr2wsq0qgsU7kVSJyEY1OmBXWSR5RpbQ_9FLFymgJiH71SnqOQGyv7Tk.R5wkg0Ww80eO4jE9paJH78cLMLQbodiDLMpFSSlH0zw9vKwf9NTn8hDK4b7eeotUgs0zeMbh3kxuHDyWg6b0fpRJhdnI4p_70BNPd.le6JHPv01LCLO_c6dGKkHsSnxm72lkJ4PLRMwzhJpF6EgPoXPmMuzOQy3SAV3lVpV1iQxOV.LyXneRmn2KvFaEhrDERRDTV0etgWZa9c- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Robert Quattlebaum'" , "'Angelo P. Castellani'" References: <3BB5F67A-9E57-4F81-B7C5-ABB1E136DAAC@tzi.org> <568AEFD6-974D-4790-A2F8-84305B990BA9@cisco.com> <180ECE5C-7013-4A75-BE1F-DD479C128C38@deepdarc.com> In-Reply-To: <180ECE5C-7013-4A75-BE1F-DD479C128C38@deepdarc.com> Date: Fri, 14 May 2010 13:33:20 -0700 Message-ID: <008301caf3a4$b1771d00$14655700$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0084_01CAF36A.05184500" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acrzo1oUyIz+2jPcTni1Ne6bi0D5aQAAM8xQ Content-Language: en-us Cc: 'core' Subject: Re: [core] Selecting a WG document for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 20:33:52 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0084_01CAF36A.05184500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Robert, Here are, I think, the assumptions with CoRE: 1) For constrained devices, we would like to re-use the web services application design paradigm from the wider internet. This would use HTTP 2) However, we would like to avoid burdening the constrained devices with many of the services that drive larger code size and complexity. 3) We would like to deploy CoRE using UDP to avoid overhead and complexity with TCP along with the issues around congestion control with TCP in mesh wireless networks. 4) We would like to re-use any security and other services applicable to web services. The better we can envision a mapping between CoRE and HTTP, the easier it will be to enable development on the wider internet to include devices with far less capabilities than are currently supported today. Don From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Robert Quattlebaum Sent: Friday, May 14, 2010 1:23 PM To: Angelo P. Castellani Cc: core Subject: Re: [core] Selecting a WG document for CoAP Pardon if my reasoning seems a bit scattered, I have a lot of thoughts on the subject but not a lot of time to write this email. It was my hope that CoAP might be the protocol to which, if devices conformed, I (as a consumer) would be able to know that they would be able to interoperate-perhaps not without configuration, but at least after such manual configuration they would be able to communicate with each other without a third device translating things. Things like light switches, motion sensors, moisture detectors, appliances, thermostats, etc. I was imagining something akin to a modernized, push version of SNMP; at least in spirit. (See for a better example) My concern is that HTTP is a clearly client-server based protocol, with a very clear delineation between the clients and the servers. With CoAP, the cases where there is such a clear server/client delineation is likely going to be much less common than cases where everyone is a peer. Thus it seems reasonable to deviate (where appropriate) from the HTTP model-even in cases where there is no direct HTTP analogue. As such, I think having a SUBSCRIBE or PAIR method makes sense. All of these devices are stateful to some degree, but there are two types of state: volatile (runtime) state, and non-volatile (configuration) state. I think that the subscriptions/pairings should be a non-volatile state. e.g.: no expirations. But I digress... Taking a step back, what is the compelling use case for a strict mapping between HTTP and CoAP? I think HTTP might be useful as a model, but I haven't really understood why we should make mapping between the two a design consideration. (As a related side observation, I think what would help is if we developed some specific use cases for how CoAP is envisioned to be used) On May 14, 2010, at 1:50 AM, Angelo P. Castellani wrote: Point (a) is exactly about the very initial design approach to define a new realization of REST (e.g.: CRUD methods were defined instead of standard HTTP methods) instead of a feature-limited adaptation of HTTP itself to constrained host/network environments. There was even discussion on defining mapping of various protocols to CoAP without clear focus on HTTP translation. Doubts were raised that CoAP may be following the "reinvent HTTP" road, killing itself just as WAP did. Discussion on URI-Code/BinaryURI (as detailed in the Transparent proxying CoAP mail) is just the tip of the iceberg. Draft -01 has made some valid enhancements on this topic (see HTTP methods), however the whole document subtly imply this design objective throughout. In my humble opinion the direction that can be followed is: If HTTP/TCP is not viable on CoRE, we should find a way to adapt it to this environment. These days I was reading the R. Fielding PhD dissertation to fully understand why HTTP was designed in that way and what are the important principles to be preserved in a feature-limited compressed adaptation. Design philosophy: CoAP should be a *stateless* HTTP-translation and we should start by understanding how we can compress HTTP preserving its core principles to be *stateless*, providing an *uniform* interface to access *diverse* content organized in a *hierarchical* fashion, it should be easily *cacheable* and *translatable*. Being pratical: -* uniformity leads to only request and response (no notify, no other message types, REST should be only REQ/RES) -* hierarchy leads to URI and BinaryURI as in the transparent proxying discussion (no flat codes like URI-Code) -* stateless, translation, cacheability lead to URI->BinaryURI as a stateless mapping (avoid stateful tables) -* stateless and diversity suggest that content should be always fully described Content-Lenght (req), Content-Type (req) and Content-Enconding should be supported -* cacheable flag should be included always (not an option) -* stateless server and stateful resources? cookies are required (lets use binary cookies) Other considerations, important in my opinion, on the realization of the protocol (more technical here): -* translation and compression should focus on the URI a) It should be always present and not an option b) Using a flag we should understand whether we are using URI or the lossy BinaryURI encoding c) URI is ASCII-7 and is usually formed by chars, numbers and a few others? I propose to investigate compressed loss-less encodings. Now I can think at least two different encodings: i) Represent the / (supposed to be most frequent char in URI) using the left-most unused bit in the octet ii) Represent most frequent chars (regex format: [0-9a-zA-Z/]) using 6 bit encoding, use a NULL (\x00) octet to signal that an uncompressed char is following. Every 3 compressed chars we have 6 unused bits that can map another char (0.75 ratio in the best case, other cases to be evaluated). Maybe some predefined vocabularies can be agreed, and the used vocabulary chosen in a preceding field (vocabulary 2 example: [a-zA-Z%+._/\|=&?-]) -* option translation issues (addressing complex implementation), general rule avoid variable length options (harder to handle): a) Messages with Payload should always carry Content-Length and Content-Type before the payload b) Define which are the well-known request and response options we want to support, without merging them (it seems not a good choice because many are response specific only, and many other request specific only). Well-known options present in the message should be represented in a binary bitmask (like in 6LoWPAN HC) and carried in-line (fixed-length is an important requirement, however variable length can be handled if cannot be avoided) When similar options are available may be beneficial to prefer the simplest and easiest to compress (fixed-length). Example: Last-Modified should be preferred to Etag, (1) it can be represented as an unsigned integer, (2) with a binary flag representing "Now" its insertion can be delegated to the HTTP translating entity, (3) supports conditional GET. c) Other options compressed with the URI style encoding (better vocabulary here is [a-zA-Z%+._/\|=&?-]) I'm quite confident that the final compression ratio is good and, if properly investigated, it should retain the ability to do CoAP->HTTP translation too (Host option required). Moreover using CoAP realized like this leads to an easier straightforward C implementation, mainly thanks to many specific details especially bitmasks, fixed-length options, bitwise operations. I hope I was able to give an idea of my thinking on these issues. A more exhaustive and detailed list of the issues is not easy to provide by e-mail, but I will be happy to draft a document with more details if this is considered as an useful contribution to this discussion. Best, Angelo On Thu, May 13, 2010 at 16:57, Cullen Jennings wrote: Angelo, I may be reading too much in between the lines here, but I think you are raising the overall design question of should we use some form of compressed HTTP, where we preserver the semantics of HTTP but encode it differently, or should we develop a protocol with a subset of the semantics of HTTP. Perhaps I have this all wrong and you are not raising that. Could you outline some proposed solutions to your a,b,c problems below and perhaps say a bit more about what the problem is. Once I understood a bit more about how you would propose to design the protocol to mitigate these problems, I think that would help everyone make informed choices. Thanks, Cullen Few more questions inline .... On May 13, 2010, at 5:24 AM, Angelo P. Castellani wrote: Dear C. Bormann, all, before deciding for the final direction, I've the following observations about draft-shelby-core-coap-01 While I mostly share Zach's view of the protocol approach, and appreciate many aspects of the proposal, there are in my opinion still some open issues that need to be at least discussed before the current document can be selected. In particular, I would like to highlight the following: a) As it is now, it is not possible to have a straightforward translation of HTTP -> CoAP and viceversa: see http://www.ietf.org/mail-archive/web/core/current/msg00133.html (this impacts the scalability of the web service model too) On the topic of how to encode the URI. I think that needs discussion but could easily happen (and would happen) even if the COAP document was adopted as a WG item now. b) Moreover, CoAP's implementation is not as simple as it should be. I've investigated the implementation and some design choices (as Options) are leading to very high program complexity (ROM) on a MSP430-based device. Can you say more - particularly about proposals to fix it? c) Finally when comparing HTTP message size with CoAP message size, the resulting compression isn't as good as you may expect. Example: HTTP: GET /sensor/temp.xml HTTP/1.0 = 32 B CoAP: 24 B with options parsing procedure requiring an added implementation complexity Addressing all these points potentially leads to major technical modifications (especially point a) on the current draft, hence it is appropriate in my opinion to discuss these points before making the final decision. Best regards, Angelo P. Castellani On Mon, May 10, 2010 at 18:51, Carsten Bormann wrote: The CORE WG has a milestone to select a WG document for CoAP in April: http://datatracker.ietf.org/wg/core/charter/ ... Apr 2010 Select WG document for basis of the CoAP protocol Of the various documents that have been contributed, draft-shelby-core-coap has significant discussion, as well as the largest number of updates (including a previous version that was still called -6lowapp-coap). Today, another updated version of that draft was announced. See http://www.ietf.org/mail-archive/web/core/current/msg00138.html for the announcement and http://tools.ietf.org/html/draft-shelby-core-coap-01 for the draft itself. However, as the authors say, there are still significant TODOs. Are we in a state yet where we can say whether this is the right direction for the WG to take? If yes, is it the right direction? Should we adopt it as a WG document? If you don't think we can say yet, is there a set of technical decisions you would like the authors to take with priority? Note that once a document has become a WG document, the authors act as editors for the working group, making (and usually fleshing out the details of) any change that the WG decides it needs. If you think we can still improve the draft, this is not an obstacle to making it a WG document. But of course we shouldn't do that if we intend to reverse its fundamental technical direction. In order to stay roughly in sync with our milestones, we should reach at a decision on how to go forward this week. Gruesse, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core __________________ Robert Quattlebaum Jabber: darco@deepdarc.com eMail: darco@deepdarc.com www: http://www.deepdarc.com/ ------=_NextPart_000_0084_01CAF36A.05184500 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Robert,

 

Here are, I think, the assumptions with = CoRE:

1)       For constrained devices, we would like to re-use = the web services application design paradigm from the wider internet.  This = would use HTTP

2)       However, we would like to avoid burdening the = constrained devices with many of the services that drive larger code size and = complexity.

3)       We would like to deploy CoRE using UDP to avoid = overhead and complexity with TCP along with the issues around congestion control = with TCP in mesh wireless networks.

4)      We would like to re-use any security and other services = applicable to web services.

 

The better we can envision a mapping between CoRE and = HTTP, the easier it will be to enable development on the wider internet to include devices with far less capabilities than are currently supported = today.


Don

 

 

From:= core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Robert Quattlebaum
Sent: Friday, May 14, 2010 1:23 PM
To: Angelo P. Castellani
Cc: core
Subject: Re: [core] Selecting a WG document for = CoAP

 

Pardon if my reasoning seems a bit scattered, I = have a lot of thoughts on the subject but not a lot of time to write this = email.

 

It was my hope that CoAP might be the protocol to = which, if devices conformed, I (as a consumer) would be able to know that they = would be able to interoperate—perhaps not without configuration, but at = least after such manual configuration they would be able to communicate with = each other without a third device translating things. Things like light = switches, motion sensors, moisture detectors, appliances, thermostats, etc. I was imagining something akin to a modernized, push version of SNMP; at least = in spirit. (See <= http://www.ietf.org/mail-archive/web/core/current/msg00119.html> for a better example)

 

My concern is that HTTP is a clearly client-server = based protocol, with a very clear delineation between the clients and the = servers. With CoAP, the cases where there is such a clear server/client = delineation is likely going to be much less common than cases where everyone is a peer. = Thus it seems reasonable to deviate (where appropriate) from the HTTP model—even in cases where there is no direct HTTP analogue. As = such, I think having a SUBSCRIBE or PAIR method makes sense.

 

All of these devices are stateful to some degree, = but there are two types of state: volatile (runtime) state, and non-volatile (configuration) state. I think that the subscriptions/pairings should be = a non-volatile state. e.g.: no expirations. But I = digress...

 

Taking a step back, what is the compelling use case = for a strict mapping between HTTP and CoAP? I think HTTP might be useful as a = model, but I haven't really understood why we should make mapping between the = two a design consideration.

 

(As a related side observation, I think what would = help is if we developed some specific use cases for how CoAP is envisioned to be = used)

 

On May 14, 2010, at 1:50 AM, Angelo P. Castellani = wrote:



Point (a) is exactly about the very initial design = approach to define
a new realization of REST (e.g.: CRUD methods were defined instead = of
standard HTTP methods) instead of a feature-limited adaptation of = HTTP
itself to constrained host/network environments.

There was even discussion on defining mapping of various protocols = to
CoAP without clear focus on HTTP translation.

Doubts were raised that CoAP may be following the "reinvent = HTTP"
road, killing itself just as WAP did. Discussion on = URI-Code/BinaryURI
(as detailed in the Transparent proxying CoAP mail) is just the tip = of
the iceberg.

Draft -01 has made some valid enhancements on this topic (see HTTP
methods), however the whole document subtly imply this design
objective throughout.

In my humble opinion the direction that can be followed is: If
HTTP/TCP is not viable on CoRE, we should find a way to adapt it to
this environment.

These days I was reading the R. Fielding PhD dissertation to fully
understand why HTTP was designed in that way and what are the
important principles to be preserved in a feature-limited compressed
adaptation.

Design philosophy: CoAP should be a *stateless* HTTP-translation and
we should start by understanding how we can compress HTTP preserving
its core principles to be *stateless*, providing an *uniform*
interface to access *diverse* content organized in a *hierarchical*
fashion, it should be easily *cacheable* and *translatable*.

Being pratical:
-* uniformity leads to only request and response (no notify, no = other
message types, REST should be only REQ/RES)

-* hierarchy leads to URI and BinaryURI as in the transparent = proxying
discussion (no flat codes like URI-Code)

-* stateless, translation, cacheability lead to URI->BinaryURI as = a
stateless mapping (avoid stateful tables)

-* stateless and diversity suggest that content should be always = fully
described Content-Lenght (req), Content-Type (req) and
Content-Enconding should be supported

-* cacheable flag should be included always (not an option)

-* stateless server and stateful resources? cookies are required = (lets
use binary cookies)


Other considerations, important in my opinion, on the realization of
the protocol (more technical here):

-* translation and compression should focus on the URI

  a) It should be always present and not an option

  b) Using a flag we should understand whether we are using URI or = the
lossy BinaryURI encoding

  c) URI is ASCII-7 and is usually formed by chars, numbers and a = few
others? I propose to investigate compressed loss-less encodings. Now = I
can think at least two different encodings:
      i) Represent the / (supposed to be most frequent = char in URI)
using the left-most unused bit in the octet
      ii) Represent most frequent chars (regex format: [0-9a-zA-Z/])
using 6 bit encoding, use a NULL (\x00) octet to signal that an
uncompressed char is following. Every 3 compressed chars we have 6
unused bits that can map another char (0.75 ratio in the best case,
other cases to be evaluated).
       Maybe some predefined = vocabularies can be agreed, and the used
vocabulary chosen in a preceding field (vocabulary 2 example:
[a-zA-Z%+._/\|=3D&?-])


-* option translation issues (addressing complex implementation),
general rule avoid variable length options (harder to handle):

 a) Messages with Payload should always carry Content-Length = and
Content-Type before the payload

 b) Define which are the well-known request and response options = we
want to support, without merging them (it seems not a good choice
because many are response specific only, and many other request
specific only).
     Well-known options present in the message should be represented
in a binary bitmask (like in 6LoWPAN HC) and carried in-line
(fixed-length is an important requirement, however variable length = can
be handled if cannot be avoided)
    When similar options are available may be = beneficial to prefer
the simplest and easiest to compress (fixed-length).
    Example: Last-Modified should be preferred to = Etag, (1) it can be
represented as an unsigned integer, (2) with a binary flag
representing "Now" its insertion can be delegated to the = HTTP
translating entity, (3) supports conditional GET.

 c) Other options compressed with the URI style encoding = (better
vocabulary here is [a-zA-Z%+._/\|=3D&?-])


I'm quite confident that the final compression ratio is good and, if
properly investigated, it should retain the ability to do = CoAP->HTTP
translation too (Host option required).

Moreover using CoAP realized like this leads to an easier
straightforward C implementation, mainly thanks to many specific
details especially bitmasks, fixed-length options, bitwise = operations.

I hope I was able to give an idea of my thinking on these issues. A
more exhaustive and detailed list of the issues is not easy to = provide
by e-mail, but I will be happy to draft a document with more details
if this is considered as an useful contribution to this discussion.

Best,
Angelo

On Thu, May 13, 2010 at 16:57, Cullen Jennings <fluffy@cisco.com> wrote:

 

Angelo,

 

I may be reading too much in between the lines = here, but I think you are raising the overall design question of should we use some = form of compressed HTTP, where we preserver the semantics of HTTP but encode it differently, or should we develop a protocol with a subset of the = semantics of HTTP. Perhaps I have this all wrong and you are not raising that. Could = you outline some proposed solutions to your a,b,c problems below and perhaps = say a bit more about what the problem is. Once I understood a bit more about = how you would propose to design the protocol to mitigate these problems, I think = that would help everyone make informed choices.

 

Thanks, Cullen

 

Few more questions inline ....

 

On May 13, 2010, at 5:24 AM, Angelo P. Castellani = wrote:

 

Dear C. Bormann, all,

 

before deciding for the final direction, I've the = following

observations about = draft-shelby-core-coap-01

 

While I mostly share Zach's view of the protocol = approach, and

appreciate many aspects of the proposal, there are = in my opinion still

some open issues that need to be at least discussed = before the current

document can be selected.

 

In particular, I would like to highlight the = following:

 

a) As it is now, it is not possible to have a straightforward

translation of HTTP -> CoAP and viceversa: = see

= http://www.ietf.org/mail-archive/web/core/current/msg00133.html (this

impacts the scalability of the web service model = too)

 

On the topic of how to encode the URI. I think that = needs discussion but could easily happen (and would happen) even if the COAP = document was adopted as a WG item now.

 

 

b) Moreover, CoAP's implementation is not as simple = as it should be.

I've investigated the implementation and some = design choices (as

Options) are leading to very high program = complexity (ROM) on a

MSP430-based device.

 

Can you say more - particularly about proposals to = fix it?

 

 

c) Finally when comparing HTTP message size with = CoAP message size,

the resulting compression isn't as good as you may = expect.

 

Example:

HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 = B

CoAP: 24 B with options parsing procedure requiring = an added

implementation complexity

 

Addressing all these points potentially leads to = major technical

modifications (especially point a) on the current = draft, hence it is

appropriate in my opinion to discuss these points = before making the

final decision.

 

Best regards,

 

Angelo P. Castellani

 

 

On Mon, May 10, 2010 at 18:51, Carsten Bormann = <cabo@tzi.org> wrote:

The CORE WG has a milestone to select a WG document = for CoAP in April:

 

http://datatracker.= ietf.org/wg/core/charter/

...

Apr 2010        Select WG = document for basis of the CoAP protocol

 

Of the various documents that have been = contributed, draft-shelby-core-coap has significant discussion, as well as the = largest number of updates (including a previous version that was still called -6lowapp-coap).

 

Today, another updated version of that draft was = announced.  See

= http://www.ietf.org/mail-archive/web/core/current/msg00138.html<= /o:p>

for the announcement and

http://tool= s.ietf.org/html/draft-shelby-core-coap-01

for the draft itself.

 

However, as the authors say, there are still = significant TODOs.

 

Are we in a state yet where we can say whether this = is the right direction for the WG to take?

If yes, is it the right direction?  Should we = adopt it as a WG document?

If you don't think we can say yet, is there a set = of technical decisions you would like the authors to take with = priority?

 

Note that once a document has become a WG document, = the authors act as editors for the working group, making (and usually fleshing out = the details of) any change that the WG decides it needs.

If you think we can still improve the draft, this = is not an obstacle to making it a WG document.

But of course we shouldn't do that if we intend to = reverse its fundamental technical direction.

 

In order to stay roughly in sync with our = milestones, we should reach at a decision on how to go forward this = week.

 

Gruesse, Carsten

 

_______________________________________________

core mailing list

core@ietf.org

https://www.ietf.org/= mailman/listinfo/core

 

_______________________________________________

core mailing list

core@ietf.org

https://www.ietf.org/= mailman/listinfo/core

 

 

Cullen Jennings

For corporate legal information go = to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 

 

 

 

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

 

__________________

Robert Quattlebaum

www:    http://www.deepdarc.com/

 

 

 

------=_NextPart_000_0084_01CAF36A.05184500-- From darco@deepdarc.com Fri May 14 14:04:54 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C91AB3A6888 for ; Fri, 14 May 2010 14:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.369 X-Spam-Level: X-Spam-Status: No, score=-4.369 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWoCn1bA5PcS for ; Fri, 14 May 2010 14:04:53 -0700 (PDT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 4CD583A6811 for ; Fri, 14 May 2010 14:04:53 -0700 (PDT) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out4.apple.com (Postfix) with ESMTP id 3D41799C8012; Fri, 14 May 2010 14:04:44 -0700 (PDT) X-AuditID: 1180711d-b7c17ae00000693e-f0-4bedbaecd65e Received: from bellatrix.apple.com (bellatrix.apple.com [17.202.32.104]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id 4B.A5.26942.CEABDEB4; Fri, 14 May 2010 14:04:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-10--788859373 From: Robert Quattlebaum In-Reply-To: <008301caf3a4$b1771d00$14655700$@sturek@att.net> Date: Fri, 14 May 2010 14:04:43 -0700 Message-Id: <6202F1D7-8652-4C38-922B-5B47A965423D@deepdarc.com> References: <3BB5F67A-9E57-4F81-B7C5-ABB1E136DAAC@tzi.org> <568AEFD6-974D-4790-A2F8-84305B990BA9@cisco.com> <180ECE5C-7013-4A75-BE1F-DD479C128C38@deepdarc.com> <008301caf3a4$b1771d00$14655700$@sturek@att.net> To: d.sturek@att.net X-Mailer: Apple Mail (2.1078) X-Brightmail-Tracker: AAAAAQAAAZE= Cc: 'core' Subject: Re: [core] Selecting a WG document for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 21:04:54 -0000 --Apple-Mail-10--788859373 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Don! On May 14, 2010, at 1:33 PM, Don Sturek wrote: > Here are, I think, the assumptions with CoRE: > 1) For constrained devices, we would like to re-use the web = services application design paradigm from the wider internet. This = would use HTTP > 2) However, we would like to avoid burdening the constrained = devices with many of the services that drive larger code size and = complexity. > 3) We would like to deploy CoRE using UDP to avoid overhead and = complexity with TCP along with the issues around congestion control with = TCP in mesh wireless networks. > 4) We would like to re-use any security and other services = applicable to web services. > =20 > The better we can envision a mapping between CoRE and HTTP, the easier = it will be to enable development on the wider internet to include = devices with far less capabilities than are currently supported today. I'm not trying to be difficult, I'm just trying to grok the paradigm = that is being proposed with CoAP. I'm having trouble imagining specific = use cases and how this mapping would be helpful to making the wider = internet include severely constrained devices. Would the border gateways = also have a CoAP->HTTP proxy? If that is not what is being proposed, = then it is still going to be significant work to get the wider internet = to adopt CoAP... I'm thinking that they just won't, because they won't = care.=20 __________________ Robert Quattlebaum Jabber: darco@deepdarc.com eMail: darco@deepdarc.com www: http://www.deepdarc.com/ --Apple-Mail-10--788859373 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Here are, I think, the assumptions with = CoRE:
1)       For constrained devices, we would like to = re-use the web services application design paradigm from the wider = internet.  This would use HTTP
       However, we would like to avoid burdening the = constrained devices with many of the services that drive larger code = size and complexity.
3)  We would like to deploy CoRE using UDP to = avoid overhead and complexity with TCP along with the issues around = congestion control with TCP in mesh wireless = networks.
4) We would like to re-use any security and other = services applicable to web services.
The = better we can envision a mapping between CoRE and HTTP, the easier it = will be to enable development on the wider internet to include devices = with far less capabilities than are currently supported = today.
<= br>
I'm not trying to be difficult, I'm just trying to grok = the paradigm that is being proposed with CoAP. I'm having trouble = imagining specific use cases and how this mapping would be helpful to = making the wider internet include severely constrained devices. Would = the border gateways also have a CoAP->HTTP proxy? If that is not what = is being proposed, then it is still going to be significant work to get = the wider internet to adopt CoAP... I'm thinking that they just won't, = because they won't care. 



= --Apple-Mail-10--788859373-- From d.sturek@att.net Fri May 14 16:25:50 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C6673A6837 for ; Fri, 14 May 2010 16:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.486 X-Spam-Level: X-Spam-Status: No, score=0.486 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyrOgQovA9u8 for ; Fri, 14 May 2010 16:25:44 -0700 (PDT) Received: from smtp110.sbc.mail.gq1.yahoo.com (smtp110.sbc.mail.gq1.yahoo.com [67.195.14.95]) by core3.amsl.com (Postfix) with SMTP id C2BDF3A6829 for ; Fri, 14 May 2010 16:25:44 -0700 (PDT) Received: (qmail 36049 invoked from network); 14 May 2010 23:25:33 -0000 Received: from wsip-174-78-56-227.sd.sd.cox.net (d.sturek@174.78.56.227 with login) by smtp110.sbc.mail.gq1.yahoo.com with SMTP; 14 May 2010 16:25:32 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: .NEKzikVM1mgwWvX_g55SZIjY7vpkxPMSqFgrNWOT.FzO4Q8T5piEjAhmTlWAiuweEL_PKO0QNr6Z_RjbrkSmLt2OASymRs_vxNYU8NHydGz71ui65MxogjYteiGcw1nun1BfabtL4DSkLZYoHj8LuKqx6.9Lj0ltzBhDb2hmhZpU6Ugq1Ndd_SAX1Q6jlPkYa9u1PXgGdVLBHwHQM42l6RIB.rmPZiz59jmDYjSL9VsIZZWMgwBNgcvNCcgDYTbDz2_X6zNMr_M0_HzFUo4BriQGkEMw4mInt7.8yueiIb7iN60IQ-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Robert Quattlebaum'" References: <3BB5F67A-9E57-4F81-B7C5-ABB1E136DAAC@tzi.org> <568AEFD6-974D-4790-A2F8-84305B990BA9@cisco.com> <180ECE5C-7013-4A75-BE1F-DD479C128C38@deepdarc.com> <008301caf3a4$b1771d00$14655700$@sturek@att.net> <6202F1D7-8652-4C38-922B-5B47A965423D@deepdarc.com> In-Reply-To: <6202F1D7-8652-4C38-922B-5B47A965423D@deepdarc.com> Date: Fri, 14 May 2010 16:25:31 -0700 Message-ID: <00f001caf3bc$bf6aa900$3e3ffb00$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F1_01CAF382.130BD100" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrzqRRaWm6KJ84aTm+QEwTAerI2QgADd/zw Content-Language: en-us Cc: 'core' Subject: Re: [core] Selecting a WG document for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 23:25:50 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00F1_01CAF382.130BD100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Robert, The original bar BOF and BOF discussed a device called "CoGII" which was a gateway from CoAP to and from HTTP. That feature was dropped out of the charter for CoRE. That said, I think the hope is that some type of obvious mapping is supported. If not, we have to hope CoRE takes off as a programming interface on the wider internet else CoRE will be supporting only machine to machine exchange. Don From: Robert Quattlebaum [mailto:darco@deepdarc.com] Sent: Friday, May 14, 2010 2:05 PM To: d.sturek@att.net Cc: 'Angelo P. Castellani'; 'core' Subject: Re: [core] Selecting a WG document for CoAP Hello Don! On May 14, 2010, at 1:33 PM, Don Sturek wrote: Here are, I think, the assumptions with CoRE: 1) For constrained devices, we would like to re-use the web services application design paradigm from the wider internet. This would use HTTP 2) However, we would like to avoid burdening the constrained devices with many of the services that drive larger code size and complexity. 3) We would like to deploy CoRE using UDP to avoid overhead and complexity with TCP along with the issues around congestion control with TCP in mesh wireless networks. 4) We would like to re-use any security and other services applicable to web services. The better we can envision a mapping between CoRE and HTTP, the easier it will be to enable development on the wider internet to include devices with far less capabilities than are currently supported today. I'm not trying to be difficult, I'm just trying to grok the paradigm that is being proposed with CoAP. I'm having trouble imagining specific use cases and how this mapping would be helpful to making the wider internet include severely constrained devices. Would the border gateways also have a CoAP->HTTP proxy? If that is not what is being proposed, then it is still going to be significant work to get the wider internet to adopt CoAP... I'm thinking that they just won't, because they won't care. __________________ Robert Quattlebaum Jabber: darco@deepdarc.com eMail: darco@deepdarc.com www: http://www.deepdarc.com/ ------=_NextPart_000_00F1_01CAF382.130BD100 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Robert,

 

The original bar BOF and BOF discussed a device called = “CoGII” which was a gateway from CoAP to and from HTTP.  That feature was = dropped out of the charter for CoRE.

 

That said, I think the hope is that some type of obvious = mapping is supported.  If not, we have to hope CoRE takes off as a = programming interface on the wider internet else CoRE will be supporting only = machine to machine exchange.

 

Don

 

 

From:= Robert = Quattlebaum [mailto:darco@deepdarc.com]
Sent: Friday, May 14, 2010 2:05 PM
To: d.sturek@att.net
Cc: 'Angelo P. Castellani'; 'core'
Subject: Re: [core] Selecting a WG document for = CoAP

 

Hello Don!

 

On May 14, 2010, at 1:33 PM, Don Sturek = wrote:



Here are, I think, the assumptions with CoRE:

1)       For constrained devices, we would like to re-use the web services application design = paradigm from the wider internet.  This would use HTTP

2)       However, we = would like to avoid burdening the constrained devices with many of the services = that drive larger code size and complexity.

3)       We would like to = deploy CoRE using UDP to avoid overhead and complexity with TCP along with the = issues around congestion control with TCP in mesh wireless = networks.

4)      We would like to = re-use any security and other services applicable to web = services.

 

The better we can envision a mapping between CoRE and = HTTP, the easier it will be to enable development on the wider internet to include devices with far less capabilities than are currently supported = today.

 

I'm not trying to be difficult, I'm just trying to = grok the paradigm that is being proposed with CoAP. I'm having trouble imagining specific use cases and how this mapping would be helpful to making the = wider internet include severely constrained devices. Would the border gateways = also have a CoAP->HTTP proxy? If that is not what is being proposed, then = it is still going to be significant work to get the wider internet to adopt = CoAP... I'm thinking that they just won't, because they won't = care. 

 

__________________

Robert Quattlebaum

www:    http://www.deepdarc.com/

 

 

 

------=_NextPart_000_00F1_01CAF382.130BD100-- From charles.palmer@onzo.com Sat May 15 05:07:15 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 331E03A6804 for ; Sat, 15 May 2010 05:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.301 X-Spam-Level: * X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7K5bEPiwoktT for ; Sat, 15 May 2010 05:07:12 -0700 (PDT) Received: from service38.mimecast.com (service38.mimecast.com [212.2.3.166]) by core3.amsl.com (Postfix) with SMTP id EEB9D3A681D for ; Sat, 15 May 2010 05:07:10 -0700 (PDT) Received: from onzosbs2k3.ONZO.local (217.138.5.2 [217.138.5.2]) by service38.mimecast.com; Sat, 15 May 2010 13:06:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 15 May 2010 13:06:55 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Selecting a WG document for CoAP Thread-Index: AcrzXymJJ03HfTKgSsyAPj23UsH0bQAwy+Kw References: <3BB5F67A-9E57-4F81-B7C5-ABB1E136DAAC@tzi.org> <1EFE7D38-0894-4557-84F9-5553E5EF6A04@sensinode.com> From: "Charles Palmer" To: "core" X-MC-Unique: 110051513065900202 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [core] Selecting a WG document for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 12:07:15 -0000 Dear all Those interested in the subscribe/notify discussion might like to look at the draft Smart Energy Profile 2.0 Application Protocol Specification. It is available here: http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicApp licationProfile.aspx It manages subscribe/notify by using POST. This seems to remove the need for SUBSCRIBE and notify. "Imagine a host A, which exposes a resource at http{s}://A/resource and a second host B, which wishes to learn of changes to this resource. To facilitate a subscription/ notification mechanism, A would expose a resource http{s}://A/sub and B would expose a resource http{s}://B/ntfy. To subscribe to notifications regarding http{s}://A/resource, B would send a POST to the address http{s}://A/sub/B containing the URI of the resource of interest (http{s}://A/resource) and the URI of B's notification resource (http{s}://B/ntfy). Following this subscription step, should A wish to notify B of a change to the resource addressed at http{s}://A/resource, A would send a POST to the address http{s}://B/ntfy containing the URI of the resource changed (http{s}://A/resource) and the URI of A's subscription resource (http{s}://A/sub/B), should A wish to change its subscription. The host B can then query the resource (or not) at its leisure." Sleepy nodes are not allowed to subscribe, and must poll. Regards - Charles Palmer=20 -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Angelo P. Castellani Sent: 14 May 2010 13:14 To: Zach Shelby Cc: core Subject: Re: [core] Selecting a WG document for CoAP Zach, thanks for the comments, but please refer to my most recent e-mail for a more specific list of technical issues I'm pointing to. I want to do only a little integration to what I've written there. In my very personal opinion, to maximize adherence with the REST model and minimize implementation effort SUBSCRIBE and NOTIFY should be mapped to methods (as discussed many times together...). Uniform interface principle (Fielding PhD dissertation Section 5.1.5, "The central feature that distinguishes the REST architectural style [...]") states that to simplify the software architecture, resource interfaces/interfaces should be as general as possible. I agree with this principle in this specific case, mainly because handling a special message type for notify leads node software design to a more complex architecture. The reason is that this new message type requires special handling and introduces a complexity in the software modularization. Best, Angelo On Fri, May 14, 2010 at 13:06, Zach Shelby wrote: > Hi Angelo, > > On May 13, 2010, at 14:24 , Angelo P. Castellani wrote: > >> Dear C. Bormann, all, >> >> before deciding for the final direction, I've the following >> observations about draft-shelby-core-coap-01 >> >> While I mostly share Zach's view of the protocol approach, and >> appreciate many aspects of the proposal, there are in my opinion still >> some open issues that need to be at least discussed before the current >> document can be selected. > > Of course there are plenty of open issues. Remember that working group documents still undertake as much change and improvement as the WG wants, so by no means is coap-01 set in stone. I would expect at least 5-10 more revisions still along the way. Already several of your ideas have been integrated into coap-01, and several more are under consideration, so it is coming along. Patience ;-) > >> >> In particular, I would like to highlight the following: >> >> a) As it is now, it is not possible to have a straightforward >> translation of HTTP -> CoAP and viceversa: see >> http://www.ietf.org/mail-archive/web/core/current/msg00133.html (this >> impacts the scalability of the web service model too) > > In coap-01 the Method names are now identical to HTTP methods. The Req/Res interaction is a direct translation. The URI hierarchy is compatible, and the URI binary code format we are still working on obviously. The only thing that takes some state to translate is Subscribe/Notify. But note, Subscribe/Notify takes some state no matter how you do it, even with HTTP-HTTP there is no clean and easy way to handle subscriptions. > >> >> b) Moreover, CoAP's implementation is not as simple as it should be. >> I've investigated the implementation and some design choices (as >> Options) are leading to very high program complexity (ROM) on a >> MSP430-based device. > > This we can definitely improve, and already made several optimizations from -00 to -01. Here I need some very concrete proposals though. Also remember that many things are optional, for example subscribe/notify is not required if you don't need it. > >> c) Finally when comparing HTTP message size with CoAP message size, >> the resulting compression isn't as good as you may expect. >> >> Example: >> HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B >> CoAP: 24 B with options parsing procedure requiring an added >> implementation complexity > > Right, that is not how it will work in practice. Working with a real HTTP server that HTTP header will be more complex, and on the CoAP side you would chose shorter URLs. The biggest improvement possible here is from using binary coded URLs of course. We need to look at a wider range of interactions and real HTTP headers as well to check that we are efficient enough. > >> Addressing all these points potentially leads to major technical >> modifications (especially point a) on the current draft, hence it is >> appropriate in my opinion to discuss these points before making the >> final decision. > > I am not sure what else you have in mind for a). If we just forget about Subscribe/Notify then you are good to go. But then you are also not fulfilling the charter or the industry needs in that respect. > > Thanks, > Zach > >> >> Best regards, >> >> Angelo P. Castellani >> >> >> On Mon, May 10, 2010 at 18:51, Carsten Bormann wrote: >>> The CORE WG has a milestone to select a WG document for CoAP in April: >>> >>> http://datatracker.ietf.org/wg/core/charter/ >>> ... >>> Apr 2010 Select WG document for basis of the CoAP protocol >>> >>> Of the various documents that have been contributed, draft-shelby-core-coap has significant discussion, as well as the largest number of updates (including a previous version that was still called -6lowapp-coap). >>> >>> Today, another updated version of that draft was announced. See >>> http://www.ietf.org/mail-archive/web/core/current/msg00138.html >>> for the announcement and >>> http://tools.ietf.org/html/draft-shelby-core-coap-01 >>> for the draft itself. >>> >>> However, as the authors say, there are still significant TODOs. >>> >>> Are we in a state yet where we can say whether this is the right direction for the WG to take? >>> If yes, is it the right direction? Should we adopt it as a WG document? >>> If you don't think we can say yet, is there a set of technical decisions you would like the authors to take with priority? >>> >>> Note that once a document has become a WG document, the authors act as editors for the working group, making (and usually fleshing out the details of) any change that the WG decides it needs. >>> If you think we can still improve the draft, this is not an obstacle to making it a WG document. >>> But of course we shouldn't do that if we intend to reverse its fundamental technical direction. >>> >>> In order to stay roughly in sync with our milestones, we should reach at a decision on how to go forward this week. >>> >>> Gruesse, Carsten >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core -------------------------------- Onzo is a limited company number 06097997 registered in England & Wales. Th= e =20 registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingd= om. This email message may contain confidential and/or privileged information, = and is intended solely for the addressee(s). If you have received this email in= =20 error, please notify Onzo immediately. Unauthorised copying, disclosure or= =20 distribution of the material in this email is forbidden. -------------------------------- From izuzak@gmail.com Sat May 15 06:29:04 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D52193A6971 for ; Sat, 15 May 2010 06:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-9BJxLvYjPP for ; Sat, 15 May 2010 06:29:03 -0700 (PDT) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id E40413A6A3A for ; Sat, 15 May 2010 06:29:02 -0700 (PDT) Received: by ewy8 with SMTP id 8so1169390ewy.28 for ; Sat, 15 May 2010 06:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=JiN1FeLYOs/I4WSDNCkNyx1al3u/esE8zWFxIEwKaIw=; b=bNVhr81Hd9HgqNBRx1UmgEr3JyMBfBnoD4NMBmS9Tk19SO/OAbnTe1SYQbIeSqElxF aHFKfK9/ChLguH1EKl5syoqYKTE5fR9kGJDe4Z/jA7Ttx3kSjrEsYbUqc4vrcMAKESiu Wh3JW48XgDE1b1+UrfykZIy3l0xB1cbyRRSME= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=KU+lpGMjU0ISt9GDPMcQTOZ+bdTk19Gm47FLj3vcKQQyyJBZoYUN25e5pra2QJlTDP /sk3U4Exg23L0zGpJ7Ce7Jo+TaQjaAkRzpTs1YYxtXFMOYQdXPfVPci6sydmc7n/WN2J z3eGmMbTjvghta1Gnaw3R86Ho93JMUcjDoP0c= Received: by 10.213.68.77 with SMTP id u13mr1026650ebi.9.1273930129386; Sat, 15 May 2010 06:28:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.34.13 with HTTP; Sat, 15 May 2010 06:28:19 -0700 (PDT) In-Reply-To: References: <3BB5F67A-9E57-4F81-B7C5-ABB1E136DAAC@tzi.org> <1EFE7D38-0894-4557-84F9-5553E5EF6A04@sensinode.com> From: =?UTF-8?B?SXZhbiDFvXXFvmFr?= Date: Sat, 15 May 2010 15:28:19 +0200 Message-ID: To: Charles Palmer , core Content-Type: text/plain; charset=UTF-8 Subject: Re: [core] Selecting a WG document for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 13:29:04 -0000 Hi Charles, all, On Sat, May 15, 2010 at 14:06, Charles Palmer wrote: > Dear all > > Those interested in the subscribe/notify discussion might like to look > at the draft Smart Energy Profile 2.0 Application Protocol > Specification. It is available here: > http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicApp > licationProfile.aspx > > It manages subscribe/notify by using POST. This seems to remove the need > for SUBSCRIBE and notify. > > "Imagine a host A, which exposes a resource at http{s}://A/resource and > a second host B, which wishes to learn of changes to this resource. To > facilitate a subscription/ notification mechanism, A would expose a > resource http{s}://A/sub and B would expose a resource http{s}://B/ntfy. > To subscribe to notifications regarding http{s}://A/resource, B would > send a POST to the address http{s}://A/sub/B containing the URI of the > resource of interest (http{s}://A/resource) and the URI of B's > notification resource (http{s}://B/ntfy). Following this subscription > step, should A wish to notify B of a change to the resource addressed at > http{s}://A/resource, A would send a POST to the address > http{s}://B/ntfy containing the URI of the resource changed > (http{s}://A/resource) and the URI of A's subscription resource > (http{s}://A/sub/B), should A wish to change its subscription. The host > B can then query the resource (or not) at its leisure." Underneath all this, as you probably know, is a simple concept called webhooks which are callbacks for HTTP, - http://webhooks.org. The webhooks community has also been iterating this design of a HTTP-level publish-subscribe mechanism for arbitrary content: http://webhooks.pbworks.com/RESTful-WebHooks Since the number of subscribers for a specific resource could potentially be very large (thus making the notification process costly), another thing to look at is PubSubHubBub which enables scalable distribution of notifications by use of intermediary hubs - http://code.google.com/p/pubsubhubbub/. In essence, PubSubHubBub is a protocol based on webhooks, so standard HTTP methods are used. Although currently supporting only subscribing to and notifying ATOM/RSS content, one of the the next versions will support arbitrary content. Best, Ivan From guido.moritz@uni-rostock.de Sun May 16 23:53:19 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2CB03A6866 for ; Sun, 16 May 2010 23:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_60=1, HELO_EQ_DE=0.35, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-5drH+QLaju for ; Sun, 16 May 2010 23:53:18 -0700 (PDT) Received: from ida.uni-rostock.de (ida.uni-rostock.de [139.30.8.34]) by core3.amsl.com (Postfix) with ESMTP id 8E8713A68AE for ; Sun, 16 May 2010 23:53:17 -0700 (PDT) Received: from email2.uni-rostock.de (139.30.8.209) by ida.uni-rostock.de (139.30.8.162) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 17 May 2010 08:53:08 +0200 Received: from Schlappi (139.30.201.226) by email2.uni-rostock.de (139.30.8.210) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 17 May 2010 08:53:07 +0200 From: Guido Moritz To: References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com> <004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de> In-Reply-To: Date: Mon, 17 May 2010 08:53:21 +0200 Message-ID: <002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrxTf4ak2qgmnhIQIqfo77oXw6hCAAiuZtgAAERdbAA6/6R0A== Content-Language: de Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 06:53:19 -0000 For example there is a SOAP-over-UDP binding defined at OASIS http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=3Dws-dd The intention is to carry UDP multicast and unicast discovery messages. See also SOAP over SMTP http://www.pocketsoap.com/specs/smtpbinding/ However, what is interesting to be agnostic of the transport protocol = and define dependencies in such bindings and not in the protocol itself. Guido > -----Urspr=FCngliche Nachricht----- > Von: L.Wood@surrey.ac.uk [mailto:L.Wood@surrey.ac.uk] > Gesendet: Mittwoch, 12. Mai 2010 16:28 > An: Guido Moritz; core@ietf.org > Betreff: RE: [core] Core UDP vs TCP : Redux >=20 > HTTP doesn't _have_ to run over TCP: > http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery-05 > and decoupling HTTP from TCP would be a very good idea, as = implementation work > to do so (e.g. HTTP over SCTP) is ongoing: > http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/talks.html#h= ttp - > standalone >=20 > The only SOAP binding I can find is that to HTTP: > http://www.w3.org/TR/soap12-part2/#soapinhttp > http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#transpbindframew >=20 > which does place SOAP binding firmly at 'concept' stage - one example = to claim > that an entire range of possibilities exist and are implementable. >=20 > Another example of this 'concept' is BEEP's transport profiles, for = which only > a mapping to TCP is actually defined. Because nobody uses BEEP. >=20 > L. >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Guido > Moritz > Sent: 12 May 2010 14:54 > To: core@ietf.org > Subject: Re: [core] Core UDP vs TCP : Redux >=20 > Sorry, but I would not agree to say 'when you are able to use TCP, you = are > also able to use HTTP'. We made several measurements with UDP vs. TCP = and of > course, connection setup takes longer for TCP. But a typical HTTP = header has a > size >100 Byte (without any payload). Thus the connection setup = overhead is > compensated due to large payload/headers itself. There might be application > scenarios where the designer wants to have reliable communication, but still > have small payload. >=20 > I did not have read through the current core I-D extensively, but is = it > necessary to go so much into detail why to use UDP or TCP and how it should be > used? It might be reasonable to define a reliability (and maybe also > fragmentation) extension to UDP and define UDP as the defualt, but why should > TCP be forbidden at all? >=20 > One may argue about SOAP Web services in several points, but their = binding > concept is quite nice. SOAP can be bound to which transport mechanism ever. > This makes it applicable it different scenarios and the transport > mechanisms/protocol can be changed without an effect on application itself. >=20 > Just my two cents, > Guido >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag > > von > Zach > > Shelby > > Gesendet: Dienstag, 11. Mai 2010 23:07 > > An: Thomas Herbst > > Cc: core@ietf.org > > Betreff: Re: [core] Core UDP vs TCP : Redux > > > > +1 > > > > Through writing a few revisions of these specs, I have also already > > found > TCP > > to be really awkward. And the TCP negotiation discussions at the = mike > > in Anaheim made me even more skeptical. Tom is right, if you need = TCP > > then > just > > use HTTP ;-) > > > > Zach > > > > On May 11, 2010, at 18:49 , Thomas Herbst wrote: > > > > > After the discussion in Anaheim, I'm surprised that we need yet > > > another > > revisit to UDP and TCP for CORE. > > > > > > The Right Solution(tm) might well be to fix TCP such that it = doesn't > lose > > its brains every time you drop a packet, and we could end up with an > end-to- > > end system where constrained devices might reasonably provide = services > > to normal hosts in the regular Internet, However, transport work is > > out of > scope > > for this WG. > > > > > > The second most right solution would be to implement CORE with a > reliable > > UDP protocol, as is done in much of the draft. The "optional" TCP > portions of > > the draft are mostly increased complexity for no added benefit. If a > device is > > capable of running TCP and the network it works on is capable of > supporting > > TCP, you should just open a connection to Port 80 and use HTTP (or = the > > TCP port/protocol of your choice). There are many protocols a host > > MAY > implement > > and it is not appropriate for the draft to enumerate them. > > > > > > Let's remove all of the sections related to TCP in the draft. > > > > > > tom > > > > > > > -- > > Zach Shelby, Head of Research, Sensinode Ltd. > > http://zachshelby.org - My blog "On the Internet of Things" > > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded = Internet" > > Mobile: +358 40 7796297 From d.sturek@att.net Mon May 17 05:43:08 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84F63A69B1 for ; Mon, 17 May 2010 05:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.804 X-Spam-Level: X-Spam-Status: No, score=-0.804 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEdsWQQ-qmp4 for ; Mon, 17 May 2010 05:43:07 -0700 (PDT) Received: from smtp124-mob.biz.mail.mud.yahoo.com (smtp124-mob.biz.mail.mud.yahoo.com [209.191.84.227]) by core3.amsl.com (Postfix) with SMTP id 487E83A69DF for ; Mon, 17 May 2010 05:37:28 -0700 (PDT) Received: (qmail 86169 invoked from network); 17 May 2010 12:37:17 -0000 Received: from bda-67-223-67-25.bise.na.blackberry.com (d.sturek@67.223.67.25 with xymcookie) by smtp124-mob.biz.mail.mud.yahoo.com with SMTP; 17 May 2010 05:37:17 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: Pjw6ZDsVM1lNKFxG25J2oM82bjVDss2Tey2COr_LGNHVQwNP05Qnkreq4Dq7qdyozOdWuca4ZOkaENf4ZiUULWw1KAQfnJ_ruvauRliMnB4OIeAqaIainWbz8.WNflhO7FJyX4KO2VRy2Bch2DREV8kAfHU7Ut414Go2eRupRi4YdY7YPvQ8eBdZOUTc60V_4Jq4HassBhZK7fjGZfCU0IX5PROS0KT4YbU4E4mk067PmDuX0UpwHgIhWxtc5Zb5AaYbR9xbGv4wqtkHxHK21RVwkcTCerl7ERmT8iQK2nD0LOOdaRQ- X-Yahoo-Newman-Property: ymail-3 X-rim-org-msg-ref-id: 2076146592 Message-ID: <2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de> In-Reply-To: <002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de> Sensitivity: Normal Importance: Normal To: "Guido Moritz" , core-bounces@ietf.org, core@ietf.org From: d.sturek@att.net Date: Mon, 17 May 2010 12:41:21 +0000 Content-Type: text/plain; charset="Windows-1252" MIME-Version: 1.0 Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 12:43:09 -0000 SGkgZ3VpZG8sDQoNCkkgdGhpbmsgdGhlIHRoaW5nIGlzIHRoaXMgaXMgbm90IHNvYXAgYnV0IHJl c3QuICBJdCBpcyBmaW5lIHRvIGNyZWF0ZSBtYXBwaW5ncyBidXQgbm90IHRvIGNoYW5nZSB0aGUg ZGVzaWduIGdvYWwgb2YgdXNpbmcgcmVzdC4NCg0KRG9uDQpTZW50IHZpYSBCbGFja0JlcnJ5IGZy b20gVC1Nb2JpbGUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEd1aWRvIE1v cml0eiA8Z3VpZG8ubW9yaXR6QHVuaS1yb3N0b2NrLmRlPg0KRGF0ZTogTW9uLCAxNyBNYXkgMjAx MCAwODo1MzoyMSANClRvOiA8Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbY29yZV0gQ29y ZSBVRFAgdnMgVENQIDogUmVkdXgNCg0KRm9yIGV4YW1wbGUgdGhlcmUgaXMgYSBTT0FQLW92ZXIt VURQIGJpbmRpbmcgZGVmaW5lZCBhdCBPQVNJUw0KaHR0cDovL3d3dy5vYXNpcy1vcGVuLm9yZy9j b21taXR0ZWVzL3RjX2hvbWUucGhwP3dnX2FiYnJldj13cy1kZA0KVGhlIGludGVudGlvbiBpcyB0 byBjYXJyeSBVRFAgbXVsdGljYXN0IGFuZCB1bmljYXN0IGRpc2NvdmVyeSBtZXNzYWdlcy4NCg0K U2VlIGFsc28gU09BUCBvdmVyIFNNVFAgaHR0cDovL3d3dy5wb2NrZXRzb2FwLmNvbS9zcGVjcy9z bXRwYmluZGluZy8NCg0KSG93ZXZlciwgd2hhdCBpcyBpbnRlcmVzdGluZyB0byBiZSBhZ25vc3Rp YyBvZiB0aGUgdHJhbnNwb3J0IHByb3RvY29sIGFuZA0KZGVmaW5lIGRlcGVuZGVuY2llcyBpbiBz dWNoIGJpbmRpbmdzIGFuZCBub3QgaW4gdGhlIHByb3RvY29sIGl0c2VsZi4NCg0KR3VpZG8NCg0K DQo+IC0tLS0tVXJzcHL8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KPiBWb246IEwuV29vZEBzdXJy ZXkuYWMudWsgW21haWx0bzpMLldvb2RAc3VycmV5LmFjLnVrXQ0KPiBHZXNlbmRldDogTWl0dHdv Y2gsIDEyLiBNYWkgMjAxMCAxNjoyOA0KPiBBbjogR3VpZG8gTW9yaXR6OyBjb3JlQGlldGYub3Jn DQo+IEJldHJlZmY6IFJFOiBbY29yZV0gQ29yZSBVRFAgdnMgVENQIDogUmVkdXgNCj4gDQo+IEhU VFAgZG9lc24ndF9oYXZlXyB0byBydW4gb3ZlciBUQ1A6DQo+IGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXdvb2QtZHRucmctaHR0cC1kdG4tZGVsaXZlcnktMDUNCj4gYW5kIGRlY291 cGxpbmcgSFRUUCBmcm9tIFRDUCB3b3VsZCBiZSBhIHZlcnkgZ29vZCBpZGVhLCBhcyBpbXBsZW1l bnRhdGlvbg0Kd29yaw0KPiB0byBkbyBzbyAoZS5nLiBIVFRQIG92ZXIgU0NUUCkgaXMgb25nb2lu ZzoNCj4NCmh0dHA6Ly9wZXJzb25hbC5lZS5zdXJyZXkuYWMudWsvUGVyc29uYWwvTC5Xb29kL3B1 YmxpY2F0aW9ucy90YWxrcy5odG1sI2h0dHANCi0NCj4gc3RhbmRhbG9uZQ0KPiANCj4gVGhlIG9u bHkgU09BUCBiaW5kaW5nIEkgY2FuIGZpbmQgaXMgdGhhdCB0byBIVFRQOg0KPiBodHRwOi8vd3d3 LnczLm9yZy9UUi9zb2FwMTItcGFydDIvI3NvYXBpbmh0dHANCj4gaHR0cDovL3d3dy53My5vcmcv VFIvMjAwNy9SRUMtc29hcDEyLXBhcnQxLTIwMDcwNDI3LyN0cmFuc3BiaW5kZnJhbWV3DQo+IA0K PiB3aGljaCBkb2VzIHBsYWNlIFNPQVAgYmluZGluZyBmaXJtbHkgYXQgJ2NvbmNlcHQnIHN0YWdl IC0gb25lIGV4YW1wbGUgdG8NCmNsYWltDQo+IHRoYXQgYW4gZW50aXJlIHJhbmdlIG9mIHBvc3Np YmlsaXRpZXMgZXhpc3QgYW5kIGFyZSBpbXBsZW1lbnRhYmxlLg0KPiANCj4gQW5vdGhlciBleGFt cGxlIG9mIHRoaXMgJ2NvbmNlcHQnIGlzIEJFRVAncyB0cmFuc3BvcnQgcHJvZmlsZXMsIGZvciB3 aGljaA0Kb25seQ0KPiBhIG1hcHBpbmcgdG8gVENQIGlzIGFjdHVhbGx5IGRlZmluZWQuIEJlY2F1 c2Ugbm9ib2R5IHVzZXMgQkVFUC4NCj4gDQo+IEwuDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjb3JlLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KR3VpZG8NCj4gTW9yaXR6DQo+IFNlbnQ6IDEyIE1h eSAyMDEwIDE0OjU0DQo+IFRvOiBjb3JlQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbY29yZV0g Q29yZSBVRFAgdnMgVENQIDogUmVkdXgNCj4gDQo+IFNvcnJ5LCBidXQgSSB3b3VsZCBub3QgYWdy ZWUgdG8gc2F5ICd3aGVuIHlvdSBhcmUgYWJsZSB0byB1c2UgVENQLCB5b3UgYXJlDQo+IGFsc28g YWJsZSB0byB1c2UgSFRUUCcuIFdlIG1hZGUgc2V2ZXJhbCBtZWFzdXJlbWVudHMgd2l0aCBVRFAg dnMuIFRDUCBhbmQNCm9mDQo+IGNvdXJzZSwgY29ubmVjdGlvbiBzZXR1cCB0YWtlcyBsb25nZXIg Zm9yIFRDUC4gQnV0IGEgdHlwaWNhbCBIVFRQIGhlYWRlcg0KaGFzIGENCj4gc2l6ZSA+MTAwIEJ5 dGUgKHdpdGhvdXQgYW55IHBheWxvYWQpLiBUaHVzIHRoZSBjb25uZWN0aW9uIHNldHVwIG92ZXJo ZWFkDQppcw0KPiBjb21wZW5zYXRlZCBkdWUgdG8gbGFyZ2UgcGF5bG9hZC9oZWFkZXJzIGl0c2Vs Zi4gVGhlcmUgbWlnaHQgYmUNCmFwcGxpY2F0aW9uDQo+IHNjZW5hcmlvcyB3aGVyZSB0aGUgZGVz aWduZXIgd2FudHMgdG8gaGF2ZSByZWxpYWJsZSBjb21tdW5pY2F0aW9uLCBidXQNCnN0aWxsDQo+ IGhhdmUgc21hbGwgcGF5bG9hZC4NCj4gDQo+IEkgZGlkIG5vdCBoYXZlIHJlYWQgdGhyb3VnaCB0 aGUgY3VycmVudCBjb3JlIEktRCBleHRlbnNpdmVseSwgYnV0IGlzIGl0DQo+IG5lY2Vzc2FyeSB0 byBnbyBzbyBtdWNoIGludG8gZGV0YWlsIHdoeSB0byB1c2UgVURQIG9yIFRDUCBhbmQgaG93IGl0 DQpzaG91bGQgYmUNCj4gdXNlZD8gSXQgbWlnaHQgYmUgcmVhc29uYWJsZSB0byBkZWZpbmUgYSBy ZWxpYWJpbGl0eSAoYW5kIG1heWJlIGFsc28NCj4gZnJhZ21lbnRhdGlvbikgZXh0ZW5zaW9uIHRv IFVEUCBhbmQgZGVmaW5lIFVEUCBhcyB0aGUgZGVmdWFsdCwgYnV0IHdoeQ0Kc2hvdWxkDQo+IFRD UCBiZSBmb3JiaWRkZW4gYXQgYWxsPw0KPiANCj4gT25lIG1heSBhcmd1ZSBhYm91dCBTT0FQIFdl YiBzZXJ2aWNlcyBpbiBzZXZlcmFsIHBvaW50cywgYnV0IHRoZWlyIGJpbmRpbmcNCj4gY29uY2Vw dCBpcyBxdWl0ZSBuaWNlLiBTT0FQIGNhbiBiZSBib3VuZCB0byB3aGljaCB0cmFuc3BvcnQgbWVj aGFuaXNtDQpldmVyLg0KPiBUaGlzIG1ha2VzIGl0IGFwcGxpY2FibGUgaXQgZGlmZmVyZW50IHNj ZW5hcmlvcyBhbmQgdGhlIHRyYW5zcG9ydA0KPiBtZWNoYW5pc21zL3Byb3RvY29sIGNhbiBiZSBj aGFuZ2VkIHdpdGhvdXQgYW4gZWZmZWN0IG9uIGFwcGxpY2F0aW9uDQppdHNlbGYuDQo+IA0KPiBK dXN0IG15IHR3byBjZW50cywNCj4gR3VpZG8NCj4gDQo+ID4gLS0tLS1VcnNwcvxuZ2xpY2hlIE5h Y2hyaWNodC0tLS0tDQo+ID4gVm9uOiBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjb3Jl LWJvdW5jZXNAaWV0Zi5vcmddIEltIEF1ZnRyYWcNCj4gPiB2b24NCj4gWmFjaA0KPiA+IFNoZWxi eQ0KPiA+IEdlc2VuZGV0OiBEaWVuc3RhZywgMTEuIE1haSAyMDEwIDIzOjA3DQo+ID4gQW46IFRo b21hcyBIZXJic3QNCj4gPiBDYzogY29yZUBpZXRmLm9yZw0KPiA+IEJldHJlZmY6IFJlOiBbY29y ZV0gQ29yZSBVRFAgdnMgVENQIDogUmVkdXgNCj4gPg0KPiA+ICsxDQo+ID4NCj4gPiBUaHJvdWdo IHdyaXRpbmcgYSBmZXcgcmV2aXNpb25zIG9mIHRoZXNlIHNwZWNzLCBJIGhhdmUgYWxzbyBhbHJl YWR5DQo+ID4gZm91bmQNCj4gVENQDQo+ID4gdG8gYmUgcmVhbGx5IGF3a3dhcmQuIEFuZCB0aGUg VENQIG5lZ290aWF0aW9uIGRpc2N1c3Npb25zIGF0IHRoZSBtaWtlDQo+ID4gaW4gQW5haGVpbSBt YWRlIG1lIGV2ZW4gbW9yZSBza2VwdGljYWwuIFRvbSBpcyByaWdodCwgaWYgeW91IG5lZWQgVENQ DQo+ID4gdGhlbg0KPiBqdXN0DQo+ID4gdXNlIEhUVFAgOy0pDQo+ID4NCj4gPiBaYWNoDQo+ID4N Cj4gPiBPbiBNYXkgMTEsIDIwMTAsIGF0IDE4OjQ5ICwgVGhvbWFzIEhlcmJzdCB3cm90ZToNCj4g Pg0KPiA+ID4gQWZ0ZXIgdGhlIGRpc2N1c3Npb24gaW4gQW5haGVpbSwgSSdtIHN1cnByaXNlZCB0 aGF0IHdlIG5lZWQgeWV0DQo+ID4gPiBhbm90aGVyDQo+ID4gcmV2aXNpdCB0byBVRFAgYW5kIFRD UCBmb3IgQ09SRS4NCj4gPiA+DQo+ID4gPiBUaGUgUmlnaHQgU29sdXRpb24odG0pIG1pZ2h0IHdl bGwgYmUgdG8gZml4IFRDUCBzdWNoIHRoYXQgaXQgZG9lc24ndA0KPiBsb3NlDQo+ID4gaXRzIGJy YWlucyBldmVyeSB0aW1lIHlvdSBkcm9wIGEgcGFja2V0LCBhbmQgd2UgY291bGQgZW5kIHVwIHdp dGggYW4NCj4gZW5kLXRvLQ0KPiA+IGVuZCBzeXN0ZW0gd2hlcmUgY29uc3RyYWluZWQgZGV2aWNl cyBtaWdodCByZWFzb25hYmx5IHByb3ZpZGUgc2VydmljZXMNCj4gPiB0byBub3JtYWwgaG9zdHMg aW4gdGhlIHJlZ3VsYXIgSW50ZXJuZXQsICBIb3dldmVyLCB0cmFuc3BvcnQgd29yayBpcw0KPiA+ IG91dCBvZg0KPiBzY29wZQ0KPiA+IGZvciB0aGlzIFdHLg0KPiA+ID4NCj4gPiA+IFRoZSBzZWNv bmQgbW9zdCByaWdodCBzb2x1dGlvbiB3b3VsZCBiZSB0byBpbXBsZW1lbnQgQ09SRSB3aXRoIGEN Cj4gcmVsaWFibGUNCj4gPiBVRFAgcHJvdG9jb2wsIGFzIGlzIGRvbmUgaW4gbXVjaCBvZiB0aGUg ZHJhZnQuICBUaGUgIm9wdGlvbmFsIiBUQ1ANCj4gcG9ydGlvbnMgb2YNCj4gPiB0aGUgZHJhZnQg YXJlIG1vc3RseSBpbmNyZWFzZWQgY29tcGxleGl0eSBmb3Igbm8gYWRkZWQgYmVuZWZpdC4gSWYg YQ0KPiBkZXZpY2UgaXMNCj4gPiBjYXBhYmxlIG9mIHJ1bm5pbmcgVENQIGFuZCB0aGUgbmV0d29y ayBpdCB3b3JrcyBvbiBpcyBjYXBhYmxlIG9mDQo+IHN1cHBvcnRpbmcNCj4gPiBUQ1AsIHlvdSBz aG91bGQganVzdCBvcGVuIGEgY29ubmVjdGlvbiB0byBQb3J0IDgwIGFuZCB1c2UgSFRUUCAob3Ig dGhlDQo+ID4gVENQIHBvcnQvcHJvdG9jb2wgb2YgeW91ciBjaG9pY2UpLiAgVGhlcmUgYXJlIG1h bnkgcHJvdG9jb2xzIGEgaG9zdA0KPiA+IE1BWQ0KPiBpbXBsZW1lbnQNCj4gPiBhbmQgaXQgaXMg bm90IGFwcHJvcHJpYXRlIGZvciB0aGUgZHJhZnQgdG8gZW51bWVyYXRlIHRoZW0uDQo+ID4gPg0K PiA+ID4gTGV0J3MgcmVtb3ZlIGFsbCBvZiB0aGUgc2VjdGlvbnMgcmVsYXRlZCB0byBUQ1AgaW4g dGhlIGRyYWZ0Lg0KPiA+ID4NCj4gPiA+IHRvbQ0KPiA+ID4NCj4gPg0KPiA+IC0tDQo+ID4gWmFj aCBTaGVsYnksIEhlYWQgb2YgUmVzZWFyY2gsIFNlbnNpbm9kZSBMdGQuDQo+ID4gaHR0cDovL3ph Y2hzaGVsYnkub3JnICAtIE15IGJsb2cgIk9uIHRoZSBJbnRlcm5ldCBvZiBUaGluZ3MiDQo+ID4g aHR0cDovLzZsb3dwYW4ubmV0IC0gTXkgYm9vayAiNkxvV1BBTjogVGhlIFdpcmVsZXNzIEVtYmVk ZGVkIEludGVybmV0Ig0KPiA+IE1vYmlsZTogKzM1OCA0MCA3Nzk2Mjk3DQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNvcmUgbWFpbGluZyBsaXN0 DQpjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nv cmUNCg== From guido.moritz@uni-rostock.de Mon May 17 06:58:11 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1DCE3A682D for ; Mon, 17 May 2010 06:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.95 X-Spam-Level: X-Spam-Status: No, score=-2.95 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDo7LsNTQNIu for ; Mon, 17 May 2010 06:58:10 -0700 (PDT) Received: from ida.uni-rostock.de (ida.uni-rostock.de [139.30.8.34]) by core3.amsl.com (Postfix) with ESMTP id 8AE033A6A0F for ; Mon, 17 May 2010 06:58:07 -0700 (PDT) Received: from email2.uni-rostock.de (139.30.8.209) by ida.uni-rostock.de (139.30.8.162) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 17 May 2010 15:57:52 +0200 Received: from Schlappi (139.30.201.226) by email2.uni-rostock.de (139.30.8.210) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 17 May 2010 15:57:52 +0200 From: Guido Moritz To: References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de> <2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry> In-Reply-To: <2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry> Date: Mon, 17 May 2010 15:58:05 +0200 Message-ID: <006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr1vbFVBl34iLLITuK1sBSl6DTocAACh2IQ Content-Language: de Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 13:58:12 -0000 Don REST (apples) is an architectural style, SOAP (oranges) is a protocol, = hard to compare apples and oranges. BTW, it is possible to use SOAP for a = RESTful design also. See WS-RA for example: http://www.w3.org/2008/08/ws/charter.html=20 But I didn't want to go to deep into this discussion. I just wanted to = ask if it is reasonable to bind the CORE protocol to UDP,TCP or whatever or = if it is possible to leave this open and design CORE extensible and = flexible enough. This is anyway not related to REST, SOA or any other = architecture, just a question of protocol design. Guido > -----Urspr=FCngliche Nachricht----- > Von: d.sturek@att.net [mailto:d.sturek@att.net] > Gesendet: Montag, 17. Mai 2010 14:41 > An: Guido Moritz; core-bounces@ietf.org; core@ietf.org > Betreff: Re: [core] Core UDP vs TCP : Redux >=20 > Hi guido, >=20 > I think the thing is this is not soap but rest. It is fine to create mappings > but not to change the design goal of using rest. >=20 > Don > Sent via BlackBerry from T-Mobile >=20 > -----Original Message----- > From: Guido Moritz > Date: Mon, 17 May 2010 08:53:21 > To: > Subject: Re: [core] Core UDP vs TCP : Redux >=20 > For example there is a SOAP-over-UDP binding defined at OASIS > http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=3Dws-dd > The intention is to carry UDP multicast and unicast discovery = messages. >=20 > See also SOAP over SMTP http://www.pocketsoap.com/specs/smtpbinding/ >=20 > However, what is interesting to be agnostic of the transport protocol = and > define dependencies in such bindings and not in the protocol itself. >=20 > Guido >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: L.Wood@surrey.ac.uk [mailto:L.Wood@surrey.ac.uk] > > Gesendet: Mittwoch, 12. Mai 2010 16:28 > > An: Guido Moritz; core@ietf.org > > Betreff: RE: [core] Core UDP vs TCP : Redux > > > > HTTP doesn't_have_ to run over TCP: > > http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery-05 > > and decoupling HTTP from TCP would be a very good idea, as implementation > work > > to do so (e.g. HTTP over SCTP) is ongoing: > > > http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/talks.html#h= ttp > - > > standalone > > > > The only SOAP binding I can find is that to HTTP: > > http://www.w3.org/TR/soap12-part2/#soapinhttp > > = http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#transpbindframew > > > > which does place SOAP binding firmly at 'concept' stage - one = example to > claim > > that an entire range of possibilities exist and are implementable. > > > > Another example of this 'concept' is BEEP's transport profiles, for which > only > > a mapping to TCP is actually defined. Because nobody uses BEEP. > > > > L. > > > > -----Original Message----- > > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of > Guido > > Moritz > > Sent: 12 May 2010 14:54 > > To: core@ietf.org > > Subject: Re: [core] Core UDP vs TCP : Redux > > > > Sorry, but I would not agree to say 'when you are able to use TCP, = you are > > also able to use HTTP'. We made several measurements with UDP vs. = TCP and > of > > course, connection setup takes longer for TCP. But a typical HTTP = header > has a > > size >100 Byte (without any payload). Thus the connection setup = overhead > is > > compensated due to large payload/headers itself. There might be > application > > scenarios where the designer wants to have reliable communication, = but > still > > have small payload. > > > > I did not have read through the current core I-D extensively, but is = it > > necessary to go so much into detail why to use UDP or TCP and how it > should be > > used? It might be reasonable to define a reliability (and maybe also > > fragmentation) extension to UDP and define UDP as the defualt, but = why > should > > TCP be forbidden at all? > > > > One may argue about SOAP Web services in several points, but their binding > > concept is quite nice. SOAP can be bound to which transport = mechanism > ever. > > This makes it applicable it different scenarios and the transport > > mechanisms/protocol can be changed without an effect on application > itself. > > > > Just my two cents, > > Guido > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im = Auftrag > > > von > > Zach > > > Shelby > > > Gesendet: Dienstag, 11. Mai 2010 23:07 > > > An: Thomas Herbst > > > Cc: core@ietf.org > > > Betreff: Re: [core] Core UDP vs TCP : Redux > > > > > > +1 > > > > > > Through writing a few revisions of these specs, I have also = already > > > found > > TCP > > > to be really awkward. And the TCP negotiation discussions at the = mike > > > in Anaheim made me even more skeptical. Tom is right, if you need = TCP > > > then > > just > > > use HTTP ;-) > > > > > > Zach > > > > > > On May 11, 2010, at 18:49 , Thomas Herbst wrote: > > > > > > > After the discussion in Anaheim, I'm surprised that we need yet > > > > another > > > revisit to UDP and TCP for CORE. > > > > > > > > The Right Solution(tm) might well be to fix TCP such that it = doesn't > > lose > > > its brains every time you drop a packet, and we could end up with = an > > end-to- > > > end system where constrained devices might reasonably provide = services > > > to normal hosts in the regular Internet, However, transport work = is > > > out of > > scope > > > for this WG. > > > > > > > > The second most right solution would be to implement CORE with a > > reliable > > > UDP protocol, as is done in much of the draft. The "optional" TCP > > portions of > > > the draft are mostly increased complexity for no added benefit. If = a > > device is > > > capable of running TCP and the network it works on is capable of > > supporting > > > TCP, you should just open a connection to Port 80 and use HTTP (or = the > > > TCP port/protocol of your choice). There are many protocols a = host > > > MAY > > implement > > > and it is not appropriate for the draft to enumerate them. > > > > > > > > Let's remove all of the sections related to TCP in the draft. > > > > > > > > tom > > > > > > > > > > -- > > > Zach Shelby, Head of Research, Sensinode Ltd. > > > http://zachshelby.org - My blog "On the Internet of Things" > > > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded = Internet" > > > Mobile: +358 40 7796297 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Mon May 17 07:27:38 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E65C43A6D14 for ; Mon, 17 May 2010 07:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.035 X-Spam-Level: X-Spam-Status: No, score=-4.035 tagged_above=-999 required=5 tests=[AWL=-0.986, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9bBFwNgcat0 for ; Mon, 17 May 2010 07:27:36 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id D717028C104 for ; Mon, 17 May 2010 07:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o4HENeWk001356; Mon, 17 May 2010 16:23:40 +0200 (CEST) Received: from [192.168.217.101] (p5489B387.dip.t-dialin.net [84.137.179.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 4C598D24B; Mon, 17 May 2010 16:23:40 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de> Date: Mon, 17 May 2010 16:23:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org> References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de> <2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry> <006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de> To: Guido Moritz X-Mailer: Apple Mail (2.1078) Cc: core@ietf.org Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 14:27:38 -0000 On May 17, 2010, at 15:58, Guido Moritz wrote: > I just wanted to ask > if it is reasonable to bind the CORE protocol to UDP,TCP or whatever = or if > it is possible to leave this open and design CORE extensible and = flexible > enough. It may be hard to meet the working group's objective of addressing = constrained node/networks while leaving the underlying protocol(s) open. = It may also be hard to meet this objective while inserting a = subprotocol as complex as SOAP into the stack. Gruesse, Carsten From d.sturek@att.net Mon May 17 07:44:54 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 192E73A6D0A for ; Mon, 17 May 2010 07:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQQUsYiWmbze for ; Mon, 17 May 2010 07:44:52 -0700 (PDT) Received: from smtp128-mob.biz.mail.mud.yahoo.com (smtp128-mob.biz.mail.mud.yahoo.com [209.191.85.15]) by core3.amsl.com (Postfix) with SMTP id 013873A680D for ; Mon, 17 May 2010 07:43:52 -0700 (PDT) Received: (qmail 69459 invoked from network); 17 May 2010 14:43:41 -0000 Received: from bda-67-223-67-25.bise.na.blackberry.com (d.sturek@67.223.67.25 with xymcookie) by smtp128-mob.biz.mail.mud.yahoo.com with SMTP; 17 May 2010 07:43:41 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: Bb3f6sgVM1lDrOBOtxcji429SGvae7XOIxUAIzOav4t9Th8TzHDUDHf7ZRtcDTSTRtcbqQ.FtUunJqmb..PT4ns88.467qpDgQgt_o7xCtXLfEMKWQT8OjHadXHKqXHwrPZ2PZWWiRGMxzrACGdVkTEUFxVSUPKZT.ww3Psr.ZOntR._3w6hUEwpqflPpVjxjBtStFvzR8I7MCTtFrcQqpquHGs2tluUQ7.a3W5j2pU.c1ciNTR_UQ5_PzCltsf.Y0s7DCNhZGFmlJMpg.pauyPP4g7Zl7pCeJrzQDVXve5UuNayBQ-- X-Yahoo-Newman-Property: ymail-3 X-rim-org-msg-ref-id: 933784992 Message-ID: <933784992-1274107417-cardhu_decombobulator_blackberry.rim.net-1548422594-@bda054.bisx.prod.on.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de><2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry><006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de> In-Reply-To: <006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de> Sensitivity: Normal Importance: Normal To: "Guido Moritz" , core-bounces@ietf.org, core@ietf.org From: d.sturek@att.net Date: Mon, 17 May 2010 14:47:45 +0000 Content-Type: text/plain; charset="Windows-1252" MIME-Version: 1.0 Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 14:44:54 -0000 SGkgZ3VpZG8sDQoNCk15IHBvaW50IGlzIHRoYXQgcmVzdCBhcmNoaXRlY3R1cmUgbWFwcGVkIHRv IG9uIG9uIHByb3RvY29sIGlzIG5vdCBzb2FwDQoNCkRvbg0KU2VudCB2aWEgQmxhY2tCZXJyeSBm cm9tIFQtTW9iaWxlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBHdWlkbyBN b3JpdHogPGd1aWRvLm1vcml0ekB1bmktcm9zdG9jay5kZT4NCkRhdGU6IE1vbiwgMTcgTWF5IDIw MTAgMTU6NTg6MDUgDQpUbzogPGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2NvcmVdIENv cmUgVURQIHZzIFRDUCA6IFJlZHV4DQoNCkRvbg0KDQpSRVNUIChhcHBsZXMpIGlzIGFuIGFyY2hp dGVjdHVyYWwgc3R5bGUsIFNPQVAgKG9yYW5nZXMpIGlzIGEgcHJvdG9jb2wsIGhhcmQNCnRvIGNv bXBhcmUgYXBwbGVzIGFuZCBvcmFuZ2VzLiBCVFcsIGl0IGlzIHBvc3NpYmxlIHRvIHVzZSBTT0FQ IGZvciBhIFJFU1RmdWwNCmRlc2lnbiBhbHNvLiBTZWUgV1MtUkEgZm9yIGV4YW1wbGU6DQpodHRw Oi8vd3d3LnczLm9yZy8yMDA4LzA4L3dzL2NoYXJ0ZXIuaHRtbCANCg0KQnV0IEkgZGlkbid0IHdh bnQgdG8gZ28gdG8gZGVlcCBpbnRvIHRoaXMgZGlzY3Vzc2lvbi4gSSBqdXN0IHdhbnRlZCB0byBh c2sNCmlmIGl0IGlzIHJlYXNvbmFibGUgdG8gYmluZCB0aGUgQ09SRSBwcm90b2NvbCB0byBVRFAs VENQIG9yIHdoYXRldmVyIG9yIGlmDQppdCBpcyBwb3NzaWJsZSB0byBsZWF2ZSB0aGlzIG9wZW4g YW5kIGRlc2lnbiBDT1JFIGV4dGVuc2libGUgYW5kIGZsZXhpYmxlDQplbm91Z2guIFRoaXMgaXMg YW55d2F5IG5vdCByZWxhdGVkIHRvIFJFU1QsIFNPQSBvciBhbnkgb3RoZXIgYXJjaGl0ZWN0dXJl LA0KanVzdCBhIHF1ZXN0aW9uIG9mIHByb3RvY29sIGRlc2lnbi4NCg0KR3VpZG8NCg0KPiAtLS0t LVVyc3By/G5nbGljaGUgTmFjaHJpY2h0LS0tLS0NCj4gVm9uOiBkLnN0dXJla0BhdHQubmV0IFtt YWlsdG86ZC5zdHVyZWtAYXR0Lm5ldF0NCj4gR2VzZW5kZXQ6IE1vbnRhZywgMTcuIE1haSAyMDEw IDE0OjQxDQo+IEFuOiBHdWlkbyBNb3JpdHo7IGNvcmUtYm91bmNlc0BpZXRmLm9yZzsgY29yZUBp ZXRmLm9yZw0KPiBCZXRyZWZmOiBSZTogW2NvcmVdIENvcmUgVURQIHZzIFRDUCA6IFJlZHV4DQo+ IA0KPiBIaSBndWlkbywNCj4gDQo+IEkgdGhpbmsgdGhlIHRoaW5nIGlzIHRoaXMgaXMgbm90IHNv YXAgYnV0IHJlc3QuICBJdCBpcyBmaW5lIHRvIGNyZWF0ZQ0KbWFwcGluZ3MNCj4gYnV0IG5vdCB0 byBjaGFuZ2UgdGhlIGRlc2lnbiBnb2FsIG9mIHVzaW5nIHJlc3QuDQo+IA0KPiBEb24NCj4gU2Vu dCB2aWEgQmxhY2tCZXJyeSBmcm9tIFQtTW9iaWxlDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBHdWlkbyBNb3JpdHogPGd1aWRvLm1vcml0ekB1bmktcm9zdG9jay5k ZT4NCj4gRGF0ZTogTW9uLCAxNyBNYXkgMjAxMCAwODo1MzoyMQ0KPiBUbzogPGNvcmVAaWV0Zi5v cmc+DQo+IFN1YmplY3Q6IFJlOiBbY29yZV0gQ29yZSBVRFAgdnMgVENQIDogUmVkdXgNCj4gDQo+ IEZvciBleGFtcGxlIHRoZXJlIGlzIGEgU09BUC1vdmVyLVVEUCBiaW5kaW5nIGRlZmluZWQgYXQg T0FTSVMNCj4gaHR0cDovL3d3dy5vYXNpcy1vcGVuLm9yZy9jb21taXR0ZWVzL3RjX2hvbWUucGhw P3dnX2FiYnJldj13cy1kZA0KPiBUaGUgaW50ZW50aW9uIGlzIHRvIGNhcnJ5IFVEUCBtdWx0aWNh c3QgYW5kIHVuaWNhc3QgZGlzY292ZXJ5IG1lc3NhZ2VzLg0KPiANCj4gU2VlIGFsc28gU09BUCBv dmVyIFNNVFAgaHR0cDovL3d3dy5wb2NrZXRzb2FwLmNvbS9zcGVjcy9zbXRwYmluZGluZy8NCj4g DQo+IEhvd2V2ZXIsIHdoYXQgaXMgaW50ZXJlc3RpbmcgdG8gYmUgYWdub3N0aWMgb2YgdGhlIHRy YW5zcG9ydCBwcm90b2NvbCBhbmQNCj4gZGVmaW5lIGRlcGVuZGVuY2llcyBpbiBzdWNoIGJpbmRp bmdzIGFuZCBub3QgaW4gdGhlIHByb3RvY29sIGl0c2VsZi4NCj4gDQo+IEd1aWRvDQo+IA0KPiAN Cj4gPiAtLS0tLVVyc3By/G5nbGljaGUgTmFjaHJpY2h0LS0tLS0NCj4gPiBWb246IEwuV29vZEBz dXJyZXkuYWMudWsgW21haWx0bzpMLldvb2RAc3VycmV5LmFjLnVrXQ0KPiA+IEdlc2VuZGV0OiBN aXR0d29jaCwgMTIuIE1haSAyMDEwIDE2OjI4DQo+ID4gQW46IEd1aWRvIE1vcml0ejsgY29yZUBp ZXRmLm9yZw0KPiA+IEJldHJlZmY6IFJFOiBbY29yZV0gQ29yZSBVRFAgdnMgVENQIDogUmVkdXgN Cj4gPg0KPiA+IEhUVFAgZG9lc24ndF9oYXZlXyB0byBydW4gb3ZlciBUQ1A6DQo+ID4gaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd29vZC1kdG5yZy1odHRwLWR0bi1kZWxpdmVyeS0w NQ0KPiA+IGFuZCBkZWNvdXBsaW5nIEhUVFAgZnJvbSBUQ1Agd291bGQgYmUgYSB2ZXJ5IGdvb2Qg aWRlYSwgYXMNCmltcGxlbWVudGF0aW9uDQo+IHdvcmsNCj4gPiB0byBkbyBzbyAoZS5nLiBIVFRQ IG92ZXIgU0NUUCkgaXMgb25nb2luZzoNCj4gPg0KPg0KaHR0cDovL3BlcnNvbmFsLmVlLnN1cnJl eS5hYy51ay9QZXJzb25hbC9MLldvb2QvcHVibGljYXRpb25zL3RhbGtzLmh0bWwjaHR0cA0KPiAt DQo+ID4gc3RhbmRhbG9uZQ0KPiA+DQo+ID4gVGhlIG9ubHkgU09BUCBiaW5kaW5nIEkgY2FuIGZp bmQgaXMgdGhhdCB0byBIVFRQOg0KPiA+IGh0dHA6Ly93d3cudzMub3JnL1RSL3NvYXAxMi1wYXJ0 Mi8jc29hcGluaHR0cA0KPiA+IGh0dHA6Ly93d3cudzMub3JnL1RSLzIwMDcvUkVDLXNvYXAxMi1w YXJ0MS0yMDA3MDQyNy8jdHJhbnNwYmluZGZyYW1ldw0KPiA+DQo+ID4gd2hpY2ggZG9lcyBwbGFj ZSBTT0FQIGJpbmRpbmcgZmlybWx5IGF0ICdjb25jZXB0JyBzdGFnZSAtIG9uZSBleGFtcGxlIHRv DQo+IGNsYWltDQo+ID4gdGhhdCBhbiBlbnRpcmUgcmFuZ2Ugb2YgcG9zc2liaWxpdGllcyBleGlz dCBhbmQgYXJlIGltcGxlbWVudGFibGUuDQo+ID4NCj4gPiBBbm90aGVyIGV4YW1wbGUgb2YgdGhp cyAnY29uY2VwdCcgaXMgQkVFUCdzIHRyYW5zcG9ydCBwcm9maWxlcywgZm9yDQp3aGljaA0KPiBv bmx5DQo+ID4gYSBtYXBwaW5nIHRvIFRDUCBpcyBhY3R1YWxseSBkZWZpbmVkLiBCZWNhdXNlIG5v Ym9keSB1c2VzIEJFRVAuDQo+ID4NCj4gPiBMLg0KPiA+DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPiBGcm9tOiBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjb3JlLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBHdWlkbw0KPiA+IE1vcml0eg0KPiA+IFNl bnQ6IDEyIE1heSAyMDEwIDE0OjU0DQo+ID4gVG86IGNvcmVAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0 OiBSZTogW2NvcmVdIENvcmUgVURQIHZzIFRDUCA6IFJlZHV4DQo+ID4NCj4gPiBTb3JyeSwgYnV0 IEkgd291bGQgbm90IGFncmVlIHRvIHNheSAnd2hlbiB5b3UgYXJlIGFibGUgdG8gdXNlIFRDUCwg eW91DQphcmUNCj4gPiBhbHNvIGFibGUgdG8gdXNlIEhUVFAnLiBXZSBtYWRlIHNldmVyYWwgbWVh c3VyZW1lbnRzIHdpdGggVURQIHZzLiBUQ1ANCmFuZA0KPiBvZg0KPiA+IGNvdXJzZSwgY29ubmVj dGlvbiBzZXR1cCB0YWtlcyBsb25nZXIgZm9yIFRDUC4gQnV0IGEgdHlwaWNhbCBIVFRQIGhlYWRl cg0KPiBoYXMgYQ0KPiA+IHNpemUgPjEwMCBCeXRlICh3aXRob3V0IGFueSBwYXlsb2FkKS4gVGh1 cyB0aGUgY29ubmVjdGlvbiBzZXR1cCBvdmVyaGVhZA0KPiBpcw0KPiA+IGNvbXBlbnNhdGVkIGR1 ZSB0byBsYXJnZSBwYXlsb2FkL2hlYWRlcnMgaXRzZWxmLiBUaGVyZSBtaWdodCBiZQ0KPiBhcHBs aWNhdGlvbg0KPiA+IHNjZW5hcmlvcyB3aGVyZSB0aGUgZGVzaWduZXIgd2FudHMgdG8gaGF2ZSBy ZWxpYWJsZSBjb21tdW5pY2F0aW9uLCBidXQNCj4gc3RpbGwNCj4gPiBoYXZlIHNtYWxsIHBheWxv YWQuDQo+ID4NCj4gPiBJIGRpZCBub3QgaGF2ZSByZWFkIHRocm91Z2ggdGhlIGN1cnJlbnQgY29y ZSBJLUQgZXh0ZW5zaXZlbHksIGJ1dCBpcyBpdA0KPiA+IG5lY2Vzc2FyeSB0byBnbyBzbyBtdWNo IGludG8gZGV0YWlsIHdoeSB0byB1c2UgVURQIG9yIFRDUCBhbmQgaG93IGl0DQo+IHNob3VsZCBi ZQ0KPiA+IHVzZWQ/IEl0IG1pZ2h0IGJlIHJlYXNvbmFibGUgdG8gZGVmaW5lIGEgcmVsaWFiaWxp dHkgKGFuZCBtYXliZSBhbHNvDQo+ID4gZnJhZ21lbnRhdGlvbikgZXh0ZW5zaW9uIHRvIFVEUCBh bmQgZGVmaW5lIFVEUCBhcyB0aGUgZGVmdWFsdCwgYnV0IHdoeQ0KPiBzaG91bGQNCj4gPiBUQ1Ag YmUgZm9yYmlkZGVuIGF0IGFsbD8NCj4gPg0KPiA+IE9uZSBtYXkgYXJndWUgYWJvdXQgU09BUCBX ZWIgc2VydmljZXMgaW4gc2V2ZXJhbCBwb2ludHMsIGJ1dCB0aGVpcg0KYmluZGluZw0KPiA+IGNv bmNlcHQgaXMgcXVpdGUgbmljZS4gU09BUCBjYW4gYmUgYm91bmQgdG8gd2hpY2ggdHJhbnNwb3J0 IG1lY2hhbmlzbQ0KPiBldmVyLg0KPiA+IFRoaXMgbWFrZXMgaXQgYXBwbGljYWJsZSBpdCBkaWZm ZXJlbnQgc2NlbmFyaW9zIGFuZCB0aGUgdHJhbnNwb3J0DQo+ID4gbWVjaGFuaXNtcy9wcm90b2Nv bCBjYW4gYmUgY2hhbmdlZCB3aXRob3V0IGFuIGVmZmVjdCBvbiBhcHBsaWNhdGlvbg0KPiBpdHNl bGYuDQo+ID4NCj4gPiBKdXN0IG15IHR3byBjZW50cywNCj4gPiBHdWlkbw0KPiA+DQo+ID4gPiAt LS0tLVVyc3By/G5nbGljaGUgTmFjaHJpY2h0LS0tLS0NCj4gPiA+IFZvbjogY29yZS1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSBJbSBBdWZ0cmFnDQo+ID4g PiB2b24NCj4gPiBaYWNoDQo+ID4gPiBTaGVsYnkNCj4gPiA+IEdlc2VuZGV0OiBEaWVuc3RhZywg MTEuIE1haSAyMDEwIDIzOjA3DQo+ID4gPiBBbjogVGhvbWFzIEhlcmJzdA0KPiA+ID4gQ2M6IGNv cmVAaWV0Zi5vcmcNCj4gPiA+IEJldHJlZmY6IFJlOiBbY29yZV0gQ29yZSBVRFAgdnMgVENQIDog UmVkdXgNCj4gPiA+DQo+ID4gPiArMQ0KPiA+ID4NCj4gPiA+IFRocm91Z2ggd3JpdGluZyBhIGZl dyByZXZpc2lvbnMgb2YgdGhlc2Ugc3BlY3MsIEkgaGF2ZSBhbHNvIGFscmVhZHkNCj4gPiA+IGZv dW5kDQo+ID4gVENQDQo+ID4gPiB0byBiZSByZWFsbHkgYXdrd2FyZC4gQW5kIHRoZSBUQ1AgbmVn b3RpYXRpb24gZGlzY3Vzc2lvbnMgYXQgdGhlIG1pa2UNCj4gPiA+IGluIEFuYWhlaW0gbWFkZSBt ZSBldmVuIG1vcmUgc2tlcHRpY2FsLiBUb20gaXMgcmlnaHQsIGlmIHlvdSBuZWVkIFRDUA0KPiA+ ID4gdGhlbg0KPiA+IGp1c3QNCj4gPiA+IHVzZSBIVFRQIDstKQ0KPiA+ID4NCj4gPiA+IFphY2gN Cj4gPiA+DQo+ID4gPiBPbiBNYXkgMTEsIDIwMTAsIGF0IDE4OjQ5ICwgVGhvbWFzIEhlcmJzdCB3 cm90ZToNCj4gPiA+DQo+ID4gPiA+IEFmdGVyIHRoZSBkaXNjdXNzaW9uIGluIEFuYWhlaW0sIEkn bSBzdXJwcmlzZWQgdGhhdCB3ZSBuZWVkIHlldA0KPiA+ID4gPiBhbm90aGVyDQo+ID4gPiByZXZp c2l0IHRvIFVEUCBhbmQgVENQIGZvciBDT1JFLg0KPiA+ID4gPg0KPiA+ID4gPiBUaGUgUmlnaHQg U29sdXRpb24odG0pIG1pZ2h0IHdlbGwgYmUgdG8gZml4IFRDUCBzdWNoIHRoYXQgaXQgZG9lc24n dA0KPiA+IGxvc2UNCj4gPiA+IGl0cyBicmFpbnMgZXZlcnkgdGltZSB5b3UgZHJvcCBhIHBhY2tl dCwgYW5kIHdlIGNvdWxkIGVuZCB1cCB3aXRoIGFuDQo+ID4gZW5kLXRvLQ0KPiA+ID4gZW5kIHN5 c3RlbSB3aGVyZSBjb25zdHJhaW5lZCBkZXZpY2VzIG1pZ2h0IHJlYXNvbmFibHkgcHJvdmlkZSBz ZXJ2aWNlcw0KPiA+ID4gdG8gbm9ybWFsIGhvc3RzIGluIHRoZSByZWd1bGFyIEludGVybmV0LCAg SG93ZXZlciwgdHJhbnNwb3J0IHdvcmsgaXMNCj4gPiA+IG91dCBvZg0KPiA+IHNjb3BlDQo+ID4g PiBmb3IgdGhpcyBXRy4NCj4gPiA+ID4NCj4gPiA+ID4gVGhlIHNlY29uZCBtb3N0IHJpZ2h0IHNv bHV0aW9uIHdvdWxkIGJlIHRvIGltcGxlbWVudCBDT1JFIHdpdGggYQ0KPiA+IHJlbGlhYmxlDQo+ ID4gPiBVRFAgcHJvdG9jb2wsIGFzIGlzIGRvbmUgaW4gbXVjaCBvZiB0aGUgZHJhZnQuICBUaGUg Im9wdGlvbmFsIiBUQ1ANCj4gPiBwb3J0aW9ucyBvZg0KPiA+ID4gdGhlIGRyYWZ0IGFyZSBtb3N0 bHkgaW5jcmVhc2VkIGNvbXBsZXhpdHkgZm9yIG5vIGFkZGVkIGJlbmVmaXQuIElmIGENCj4gPiBk ZXZpY2UgaXMNCj4gPiA+IGNhcGFibGUgb2YgcnVubmluZyBUQ1AgYW5kIHRoZSBuZXR3b3JrIGl0 IHdvcmtzIG9uIGlzIGNhcGFibGUgb2YNCj4gPiBzdXBwb3J0aW5nDQo+ID4gPiBUQ1AsIHlvdSBz aG91bGQganVzdCBvcGVuIGEgY29ubmVjdGlvbiB0byBQb3J0IDgwIGFuZCB1c2UgSFRUUCAob3Ig dGhlDQo+ID4gPiBUQ1AgcG9ydC9wcm90b2NvbCBvZiB5b3VyIGNob2ljZSkuICBUaGVyZSBhcmUg bWFueSBwcm90b2NvbHMgYSBob3N0DQo+ID4gPiBNQVkNCj4gPiBpbXBsZW1lbnQNCj4gPiA+IGFu ZCBpdCBpcyBub3QgYXBwcm9wcmlhdGUgZm9yIHRoZSBkcmFmdCB0byBlbnVtZXJhdGUgdGhlbS4N Cj4gPiA+ID4NCj4gPiA+ID4gTGV0J3MgcmVtb3ZlIGFsbCBvZiB0aGUgc2VjdGlvbnMgcmVsYXRl ZCB0byBUQ1AgaW4gdGhlIGRyYWZ0Lg0KPiA+ID4gPg0KPiA+ID4gPiB0b20NCj4gPiA+ID4NCj4g PiA+DQo+ID4gPiAtLQ0KPiA+ID4gWmFjaCBTaGVsYnksIEhlYWQgb2YgUmVzZWFyY2gsIFNlbnNp bm9kZSBMdGQuDQo+ID4gPiBodHRwOi8vemFjaHNoZWxieS5vcmcgIC0gTXkgYmxvZyAiT24gdGhl IEludGVybmV0IG9mIFRoaW5ncyINCj4gPiA+IGh0dHA6Ly82bG93cGFuLm5ldCAtIE15IGJvb2sg IjZMb1dQQU46IFRoZSBXaXJlbGVzcyBFbWJlZGRlZCBJbnRlcm5ldCINCj4gPiA+IE1vYmlsZTog KzM1OCA0MCA3Nzk2Mjk3DQo+IA0KPiANCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBjb3JlIG1haWxpbmcgbGlzdA0KPiBjb3JlQGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY29yZSBtYWlsaW5nIGxpc3QN CmNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29y ZQ0K From guido.moritz@uni-rostock.de Mon May 17 08:11:23 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D0823A6A93 for ; Mon, 17 May 2010 08:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.067 X-Spam-Level: X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSWvUV2ykvNB for ; Mon, 17 May 2010 08:11:22 -0700 (PDT) Received: from ida.uni-rostock.de (ida.uni-rostock.de [139.30.8.34]) by core3.amsl.com (Postfix) with ESMTP id 796A43A6CA1 for ; Mon, 17 May 2010 08:11:10 -0700 (PDT) Received: from email2.uni-rostock.de (139.30.8.209) by ida.uni-rostock.de (139.30.8.162) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 17 May 2010 17:11:00 +0200 Received: from Schlappi (139.30.201.226) by email2.uni-rostock.de (139.30.8.210) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 17 May 2010 17:11:00 +0200 From: Guido Moritz To: References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de> <2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry> <006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de> <041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org> In-Reply-To: <041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org> Date: Mon, 17 May 2010 17:11:14 +0200 Message-ID: <007c01caf5d3$30f026f0$92d074d0$@moritz@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr1zJc/bvdnn+5LQpypULdy1SC3ZQAA0P1w Content-Language: de Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 15:11:23 -0000 > It may also be hard to meet this objective while inserting a = subprotocol as complex as SOAP into the stack. I just went through the current COAP I-D and it is already quite = complex! It includes many mechanisms and concepts which are also included in SOAP = and other W3C/OASIS Web services specifications that I am familiar in due to = my background in DPWS.=20 Nevertheless, let's leave the discussion around SOAP, because there = seems to be many misunderstandings related to SOAP and what I wanted to point at. What I wanted to say is (and that is my still my opinion after reading current COAP I-D): there is no reason to bind COAP to UDP or TCP = exclusively or exclude one of them. COAP seems to describe many mechanisms for interaction with resources, eventing and discovery mechanisms, = mechanisms to avoid duplicated message processing etc. But all these mechanisms do not depend on the transport layer. Why should a node not support = interactions by using TCP or UDP at the same time for the same resource. Of course, not = the highly resource constrained one, but we are heading towards = heterogeneous device infrastructures where resource richer devices in the same network might be possible as well. Take the ideas or throw them away. But these are major decisions = concerning applicability of the resulting COAP. What made HTTP and REST in the WWW = such a success was that it is possible to run it over all kinds of = technologies and not to restrict it to specific message sizes. Let's say there is a = cool new wireless technology IEEE 802.15.XY which is capable of running = 6LoWPAN but with double of the frame size and data rate at same energy costs. = Will there be the next COAPXY for this new link layer because suddenly there = is double the bandwidth available? Again, Just my two cents ;) Guido > -----Urspr=FCngliche Nachricht----- > Von: Carsten Bormann [mailto:cabo@tzi.org] > Gesendet: Montag, 17. Mai 2010 16:24 > An: Guido Moritz > Cc: core@ietf.org > Betreff: Re: [core] Core UDP vs TCP : Redux >=20 > On May 17, 2010, at 15:58, Guido Moritz wrote: >=20 > > I just wanted to ask > > if it is reasonable to bind the CORE protocol to UDP,TCP or whatever = or if > > it is possible to leave this open and design CORE extensible and flexible > > enough. >=20 > It may be hard to meet the working group's objective of addressing constrained > node/networks while leaving the underlying protocol(s) open. It may = also be > hard to meet this objective while inserting a subprotocol as complex = as SOAP > into the stack. >=20 > Gruesse, Carsten From matthieu.vial@fr.non.schneider-electric.com Mon May 17 08:47:05 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC8103A6A95; Mon, 17 May 2010 08:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.115 X-Spam-Level: ** X-Spam-Status: No, score=2.115 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_50=0.001, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hvl0j+RIQIDi; Mon, 17 May 2010 08:47:03 -0700 (PDT) Received: from mailX03.eud.schneider-electric.com (mailx03.eud.schneider-electric.com [205.167.7.41]) by core3.amsl.com (Postfix) with ESMTP id 1FCF73A6D58; Mon, 17 May 2010 08:44:41 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX03.eud.schneider-electric.com with ESMTP id 2010051717350982-79044 ; Mon, 17 May 2010 17:35:09 +0200 In-Reply-To: To: "Charles Palmer" X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: matthieu.vial@fr.non.schneider-electric.com Date: Mon, 17 May 2010 17:44:27 +0200 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 17/05/2010 17:44:30, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 17/05/2010 17:35:09, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 17/05/2010 17:35:13 Content-type: multipart/related; Boundary="0__=4EBBFDB5DFC20EEE8f9e8a93df938690918c4EBBFDB5DFC20EEE" Cc: core-bounces@ietf.org, core Subject: Re: [core] Selecting a WG document for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 15:47:05 -0000 --0__=4EBBFDB5DFC20EEE8f9e8a93df938690918c4EBBFDB5DFC20EEE Content-type: multipart/alternative; Boundary="1__=4EBBFDB5DFC20EEE8f9e8a93df938690918c4EBBFDB5DFC20EEE" --1__=4EBBFDB5DFC20EEE8f9e8a93df938690918c4EBBFDB5DFC20EEE Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=ISO-8859-1 Hi, My comments about the subscribe/notify mechanism of Zigbee IP. Pros: - Derived from the webhooks concept - If used by CORE it will be easier to map to HTTP because it uses only= CRUD verbs. - The subscription message is extendable and could support advanced opt= ions (delays, increment, ...) - Only one listening port whatever the transport binding is. Cons: - No interoperability without well known URIs and a well defined subscription message format (Not sure CoAP draft is the right place to specify this). - XML/EXI is too complex to be the required format for the default subscription/notification mechanism. - The notification should not require a subsequent GET to retrieve the content. - Subresource subscription is redundant. Hope this could help, Matthieu = "Charles Palmer" = = A Envoy=E9 par : "core" = core-bounces@ietf = cc .org = Ob= jet Re: [core] Selecting a WG docume= nt 15/05/2010 14:06 for CoAP = = = = = = = Dear all Those interested in the subscribe/notify discussion might like to look at the draft Smart Energy Profile 2.0 Application Protocol Specification. It is available here: http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicAp= p licationProfile.aspx It manages subscribe/notify by using POST. This seems to remove the nee= d for SUBSCRIBE and notify. "Imagine a host A, which exposes a resource at http{s}://A/resource and= a second host B, which wishes to learn of changes to this resource. To facilitate a subscription/ notification mechanism, A would expose a resource http{s}://A/sub and B would expose a resource http{s}://B/ntfy= . To subscribe to notifications regarding http{s}://A/resource, B would send a POST to the address http{s}://A/sub/B containing the URI of the resource of interest (http{s}://A/resource) and the URI of B's notification resource (http{s}://B/ntfy). Following this subscription step, should A wish to notify B of a change to the resource addressed a= t http{s}://A/resource, A would send a POST to the address http{s}://B/ntfy containing the URI of the resource changed (http{s}://A/resource) and the URI of A's subscription resource (http{s}://A/sub/B), should A wish to change its subscription. The host= B can then query the resource (or not) at its leisure." Sleepy nodes are not allowed to subscribe, and must poll. Regards - Charles Palmer -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of= Angelo P. Castellani Sent: 14 May 2010 13:14 To: Zach Shelby Cc: core Subject: Re: [core] Selecting a WG document for CoAP Zach, thanks for the comments, but please refer to my most recent e-mail for a more specific list of technical issues I'm pointing to. I want to do only a little integration to what I've written there. In my very personal opinion, to maximize adherence with the REST model and minimize implementation effort SUBSCRIBE and NOTIFY should be mapped to methods (as discussed many times together...). Uniform interface principle (Fielding PhD dissertation Section 5.1.5, "The central feature that distinguishes the REST architectural style [...]") states that to simplify the software architecture, resource interfaces/interfaces should be as general as possible. I agree with this principle in this specific case, mainly because handling a special message type for notify leads node software design to a more complex architecture. The reason is that this new message type requires special handling and introduces a complexity in the software modularization. Best, Angelo On Fri, May 14, 2010 at 13:06, Zach Shelby wrote: > Hi Angelo, > > On May 13, 2010, at 14:24 , Angelo P. Castellani wrote: > >> Dear C. Bormann, all, >> >> before deciding for the final direction, I've the following >> observations about draft-shelby-core-coap-01 >> >> While I mostly share Zach's view of the protocol approach, and >> appreciate many aspects of the proposal, there are in my opinion still >> some open issues that need to be at least discussed before the current >> document can be selected. > > Of course there are plenty of open issues. Remember that working grou= p documents still undertake as much change and improvement as the WG wants, so by no means is coap-01 set in stone. I would expect at least 5-10 more revisions still along the way. Already several of your ideas= have been integrated into coap-01, and several more are under consideration, so it is coming along. Patience ;-) > >> >> In particular, I would like to highlight the following: >> >> a) As it is now, it is not possible to have a straightforward >> translation of HTTP -> CoAP and viceversa: see >> http://www.ietf.org/mail-archive/web/core/current/msg00133.html (thi= s >> impacts the scalability of the web service model too) > > In coap-01 the Method names are now identical to HTTP methods. The Req/Res interaction is a direct translation. The URI hierarchy is compatible, and the URI binary code format we are still working on obviously. The only thing that takes some state to translate is Subscribe/Notify. But note, Subscribe/Notify takes some state no matter= how you do it, even with HTTP-HTTP there is no clean and easy way to handle subscriptions. > >> >> b) Moreover, CoAP's implementation is not as simple as it should be.= >> I've investigated the implementation and some design choices (as >> Options) are leading to very high program complexity (ROM) on a >> MSP430-based device. > > This we can definitely improve, and already made several optimization= s from -00 to -01. Here I need some very concrete proposals though. Also remember that many things are optional, for example subscribe/notify is= not required if you don't need it. > >> c) Finally when comparing HTTP message size with CoAP message size, >> the resulting compression isn't as good as you may expect. >> >> Example: >> HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B >> CoAP: 24 B with options parsing procedure requiring an added >> implementation complexity > > Right, that is not how it will work in practice. Working with a real HTTP server that HTTP header will be more complex, and on the CoAP side= you would chose shorter URLs. The biggest improvement possible here is from using binary coded URLs of course. We need to look at a wider rang= e of interactions and real HTTP headers as well to check that we are efficient enough. > >> Addressing all these points potentially leads to major technical >> modifications (especially point a) on the current draft, hence it is= >> appropriate in my opinion to discuss these points before making the >> final decision. > > I am not sure what else you have in mind for a). If we just forget about Subscribe/Notify then you are good to go. But then you are also not fulfilling the charter or the industry needs in that respect. > > Thanks, > Zach > >> >> Best regards, >> >> Angelo P. Castellani >> >> >> On Mon, May 10, 2010 at 18:51, Carsten Bormann wrote:= >>> The CORE WG has a milestone to select a WG document for CoAP in April: >>> >>> http://datatracker.ietf.org/wg/core/charter/ >>> ... >>> Apr 2010 Select WG document for basis of the CoAP protocol >>> >>> Of the various documents that have been contributed, draft-shelby-core-coap has significant discussion, as well as the largest number of updates (including a previous version that was still called -6lowapp-coap). >>> >>> Today, another updated version of that draft was announced. See >>> http://www.ietf.org/mail-archive/web/core/current/msg00138.html >>> for the announcement and >>> http://tools.ietf.org/html/draft-shelby-core-coap-01 >>> for the draft itself. >>> >>> However, as the authors say, there are still significant TODOs. >>> >>> Are we in a state yet where we can say whether this is the right direction for the WG to take? >>> If yes, is it the right direction? Should we adopt it as a WG document? >>> If you don't think we can say yet, is there a set of technical decisions you would like the authors to take with priority? >>> >>> Note that once a document has become a WG document, the authors act= as editors for the working group, making (and usually fleshing out the details of) any change that the WG decides it needs. >>> If you think we can still improve the draft, this is not an obstacl= e to making it a WG document. >>> But of course we shouldn't do that if we intend to reverse its fundamental technical direction. >>> >>> In order to stay roughly in sync with our milestones, we should reach at a decision on how to go forward this week. >>> >>> Gruesse, Carsten >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet= " > Mobile: +358 40 7796297 > > _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core -------------------------------- Onzo is a limited company number 06097997 registered in England & Wales= . The registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingdom. This email message may contain confidential and/or privileged informati= on, and is intended solely for the addressee(s). If you have received this emai= l in error, please notify Onzo immediately. Unauthorised copying, disclosure= or distribution of the material in this email is forbidden. -------------------------------- _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ = --1__=4EBBFDB5DFC20EEE8f9e8a93df938690918c4EBBFDB5DFC20EEE Content-transfer-encoding: quoted-printable Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline

Hi,

My comments about the subscribe/notify mechanism of Zigbee IP.

Pros:
- Derived from the webhooks concept
- If used by CORE it will be easier to map to HTTP because it uses only= CRUD verbs.
- The subscription message is extendable and could support advanced opt= ions (delays, increment, ...)
- Only one listening port whatever the transport binding is.

Cons:
- No interoperability without well known URIs and a well defined subsc= ription message format (Not sure CoAP draft is the right place to speci= fy this).
- XML/EXI is too complex to be the required format for the default subs= cription/notification mechanism.
- The notification should not require a subsequent GET to retrieve the = content.
- Subresource subscription is redundant.

Hope this could help,
Matthieu


3D"Inactive"Charles Pa= lmer" <charles.palmer@onzo.com>




=
          "Charles Palmer" <charles.palmer@o= nzo.com>
          Envoy=E9 par : core-bounces@ietf.org

          15/05/2010 14:06

 =
3D=
A
3D""
"core" <core@ietf.org>
3D=
cc
3D""
3D=
Objet
3D""
Re: [core] Selecting a WG document for CoAP
3D=3D""

Dear all

Those interested in the subscribe/notify discussion might like to look<= br> at the draft Smart Energy Profile 2.0 Application Protocol
Specification. It is available here:
http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigB= eeSmartEnergy20PublicApp
licationProfile.aspx

It manages subscribe/notify by using POST. This seems to remove the nee= d
for SUBSCRIBE and notify.

"Imagine a host A, which exposes a resource at http{s}://A/resourc= e and
a second host B, which wishes to learn of changes to this resource. To<= br> facilitate a subscription/ notification mechanism, A would expose a
= resource http{s}://A/sub and B would expose a resource http{s}://B/ntfy= .
To subscribe to notifications regarding http{s}://A/resource, B would send a POST to the address http{s}://A/sub/B containing the URI of the<= br> resource of interest (http{s}://A/resource) and the URI of B's
notification resource (http{s}://B/ntfy). Following this subscription step, should A wish to notify B of a change to the resource addressed a= t
http{s}://A/resource, A would send a POST to the address
http{s}://B/ntfy containing the URI of the resource changed
(http{s}://A/resource) and the URI of A's subscription resource
(http{s}://A/sub/B), should A wish to change its subscription. The host=
B can then query the resource (or not) at its leisure."

Sleepy nodes are not allowed to subscribe, and must poll.

Regards - Charles Palmer

-----Original Message-----
From: core-bounces@ietf.org [m= ailto:core-bounces@ietf.org] On Behalf Of
Angelo P. Castellani
Sent: 14 May 2010 13:14
To: Zach Shelby
Cc: core
Subject: Re: [core] Selecting a WG document for CoAP

Zach,

thanks for the comments, but please refer to my most recent e-mail for<= br> a more specific list of technical issues I'm pointing to.

I want to do only a little integration to what I've written there.

In my very personal opinion, to maximize adherence with the REST model<= br> and minimize implementation effort SUBSCRIBE and NOTIFY should be
mapped to methods (as discussed many times together...).

Uniform interface principle (Fielding PhD dissertation Section 5.1.5, "The central feature that distinguishes the REST architectural sty= le
[...]") states that to simplify the software architecture, resourc= e
interfaces/interfaces should be as general as possible.

I agree with this principle in this specific case, mainly because
handling a special message type for notify leads node software design to a more complex architecture.

The reason is that this new message type requires special handling and<= br> introduces a complexity in the software modularization.

Best,
Angelo

On Fri, May 14, 2010 at 13:06, Zach Shelby <zach@sensinode.com> w= rote:
> Hi Angelo,
>
> On May 13, 2010, at 14:24 , Angelo P. Castellani wrote:
>
>> Dear C. Bormann, all,
>>
>> before deciding for the final direction, I've the following >> observations about draft-shelby-core-coap-01
>>
>> While I mostly share Zach's view of the protocol approach, and=
>> appreciate many aspects of the proposal, there are in my opini= on
still
>> some open issues that need to be at least discussed before the=
current
>> document can be selected.
>
> Of course there are plenty of open issues. Remember that working g= roup
documents still undertake as much change and improvement as the WG
wants, so by no means is coap-01 set in stone. I would expect at least<= br> 5-10 more revisions still along the way.  Already several of your = ideas
have been integrated into coap-01, and several more are under
consideration, so it is coming along. Patience ;-)
>
>>
>> In particular, I would like to highlight the following:
>>
>> a) As it is now, it is not possible to have a straightforward<= br> >> translation of HTTP -> CoAP and viceversa: see
>> http://www.ietf.org/mail-archive/web/core/curren= t/msg00133.html (this
>> impacts the scalability of the web service model too)
>
> In coap-01 the Method names are now identical to HTTP methods. The=
Req/Res interaction is a direct translation. The URI hierarchy is
compatible, and the URI binary code format we are still working on
obviously. The only thing that takes some state to translate is
Subscribe/Notify. But note, Subscribe/Notify takes some state no matter=
how you do it, even with HTTP-HTTP there is no clean and easy way to handle subscriptions.
>
>>
>> b) Moreover, CoAP's implementation is not as simple as it shou= ld be.
>> I've investigated the implementation and some design choices (= as
>> Options) are leading to very high program complexity (ROM) on = a
>> MSP430-based device.
>
> This we can definitely improve, and already made several optimizat= ions
from -00 to -01. Here I need some very concrete proposals though. Also<= br> remember that many things are optional, for example subscribe/notify is=
not required if you don't need it.
>
>> c) Finally when comparing HTTP message size with CoAP message = size,
>> the resulting compression isn't as good as you may expect.
= >>
>> Example:
>> HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B
>> CoAP: 24 B with options parsing procedure requiring an added >> implementation complexity
>
> Right, that is not how it will work in practice. Working with a re= al
HTTP server that HTTP header will be more complex, and on the CoAP side=
you would chose shorter URLs. The biggest improvement possible here is<= br> from using binary coded URLs of course. We need to look at a wider rang= e
of interactions and real HTTP headers as well to check that we are
efficient enough.
>
>> Addressing all these points potentially leads to major technic= al
>> modifications (especially point a) on the current draft, hence= it is
>> appropriate in my opinion to discuss these points before makin= g the
>> final decision.
>
> I am not sure what else you have in mind for a). If we just forget=
about Subscribe/Notify then you are good to go. But then you are also not fulfilling the charter or the industry needs in that respect.
>
> Thanks,
> Zach
>
>>
>> Best regards,
>>
>> Angelo P. Castellani
>>
>>
>> On Mon, May 10, 2010 at 18:51, Carsten Bormann <cabo@tzi.or= g> wrote:
>>> The CORE WG has a milestone to select a WG document for Co= AP in
April:
>>>
>>> http://datatracker.ietf.org/wg/core/charter/
>>> ...
>>> Apr 2010        Select WG document for= basis of the CoAP protocol
>>>
>>> Of the various documents that have been contributed,
draft-shelby-core-coap has significant discussion, as well as the
largest number of updates (including a previous version that was still<= br> called -6lowapp-coap).
>>>
>>> Today, another updated version of that draft was announced= .  See
>>> http://www.ietf.org/mail-archive/web/core/cu= rrent/msg00138.html
>>> for the announcement and
>>> http://tools.ietf.org/html/draft-shelby-core-coap-01
>>> for the draft itself.
>>>
>>> However, as the authors say, there are still significant T= ODOs.
>>>
>>> Are we in a state yet where we can say whether this is the= right
direction for the WG to take?
>>> If yes, is it the right direction?  Should we adopt i= t as a WG
document?
>>> If you don't think we can say yet, is there a set of techn= ical
decisions you would like the authors to take with priority?
>>>
>>> Note that once a document has become a WG document, the au= thors act
as editors for the working group, making (and usually fleshing out the<= br> details of) any change that the WG decides it needs.
>>> If you think we can still improve the draft, this is not a= n obstacle
to making it a WG document.
>>> But of course we shouldn't do that if we intend to reverse= its
fundamental technical direction.
>>>
>>> In order to stay roughly in sync with our milestones, we s= hould
reach at a decision on how to go forward this week.
>>>
>>> Gruesse, Carsten
>>>
>>> _______________________________________________
>>> core mailing list
>>> core@ietf.org
>>> https://www.ietf.org/mailman/listinfo/core
>>>
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
>
> --
> Zach Shelby, Chief Nerd, Sensinode Ltd.
> http://zachshelby.org  - My blog "On the Internet of Things"
> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"= ;
> Mobile: +358 40 7796297
>
>
_______________________________________________
core mailing list
core@ietf.org
https:/= /www.ietf.org/mailman/listinfo/core

--------------------------------
Onzo is a limited company number 06097997 registered in England & W= ales. The    
registered office is 6 Great Newport Street, London, WC2H 7JB, United K= ingdom.

This email message may contain confidential and/or privileged informati= on, and
is intended solely for the addressee(s). If you have received this emai= l in    
error, please notify Onzo immediately. Unauthorised copying, disclosure= or
distribution of the material in this email is forbidden.
--------------------------------

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

______________________________________________________________________<= br> This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________<= br>
= --1__=4EBBFDB5DFC20EEE8f9e8a93df938690918c4EBBFDB5DFC20EEE-- --0__=4EBBFDB5DFC20EEE8f9e8a93df938690918c4EBBFDB5DFC20EEE Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=4EBBFDB5DFC20EEE8@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=4EBBFDB5DFC20EEE8f9e8a93df938690918c4EBBFDB5DFC20EEE Content-type: image/gif; name="pic17861.gif" Content-Disposition: inline; filename="pic17861.gif" Content-ID: <2__=4EBBFDB5DFC20EEE8@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=4EBBFDB5DFC20EEE8f9e8a93df938690918c4EBBFDB5DFC20EEE Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=4EBBFDB5DFC20EEE8@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=4EBBFDB5DFC20EEE8f9e8a93df938690918c4EBBFDB5DFC20EEE-- From charles.palmer@onzo.com Mon May 17 08:50:03 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 290BE3A6D00 for ; Mon, 17 May 2010 08:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.451 X-Spam-Level: X-Spam-Status: No, score=0.451 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_50=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeAJGYG9D+Bn for ; Mon, 17 May 2010 08:50:00 -0700 (PDT) Received: from service38.mimecast.com (service38.mimecast.com [212.2.3.166]) by core3.amsl.com (Postfix) with SMTP id DC79C3A6D62 for ; Mon, 17 May 2010 08:47:57 -0700 (PDT) Received: from onzosbs2k3.ONZO.local (217.138.5.2 [217.138.5.2]) by service38.mimecast.com; Mon, 17 May 2010 16:47:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 17 May 2010 16:47:40 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Core UDP vs TCP : Redux Thread-Index: Acr1zJc/bvdnn+5LQpypULdy1SC3ZQAA0P1wAAFHDkA= References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de><2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry><006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de><041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org> <007c01caf5d3$30f026f0$92d074d0$@moritz@uni-rostock.de> From: "Charles Palmer" To: "core" X-MC-Unique: 110051716474500402 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 15:50:03 -0000 Hi folks Worth noting that the draft ZigBee Smart Energy 2.0 Application Protocol Sp= ecification is very good about not mandating the transport layer (although = it talks extensively about TLS - does this limit it to TCP?) The SE2.0 spec also makes reference to possibly using CoRE (see quote below= ). BTW how closely are we/should we be tracking SE2.0 work? I see several n= ames in both lists. I'd speculate that if CoRE is to be of use to ZigBee Sm= art Energy then CoRE needs to provide an easy transition. I guess SE2.0 plans to use HTTP/EXI/TCP/IP because they exist and work.=20 How disruptive would it be to design CoRE without reference to TCP/UDP, and= also design a "reliable UDP" and use this for CoRE?=20 >From SE2.0: "6.1 Protocol Flexibility The Smart Energy Profile is designed to implement a RESTful architecture. A= s such it is built around the core actions of GET, PUT, POST, and DELETE (a= s used in [REST]), with the addition of a lightweight subscription and noti= fication mechanism, as discussed above in =A77. It is not however, strictly= limited to HTTP. Any protocol that can implement the GET, PUT, POST, and D= ELETE command set can be used with SEP 2.0. It is expected that HTTP is the= preferred protocol for interactions with the broader Internet, and that pr= otocol translation services are provided when it is desired to link an SEP = system using another application protocol with HTTP based solutions. The li= ghtweight RESTful Constrained Application Protocol (CoAP) is one such alter= native to HTTP [COAP]. This protocol should be proxied to HTTP for interact= ions with the broader Internet, but may be applied end-to-end." Regards - Charles Palmer=20 -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Gui= do Moritz Sent: 17 May 2010 16:11 To: core@ietf.org Subject: Re: [core] Core UDP vs TCP : Redux > It may also be hard to meet this objective while inserting a subprotocol as complex as SOAP into the stack. I just went through the current COAP I-D and it is already quite complex! I= t includes many mechanisms and concepts which are also included in SOAP and other W3C/OASIS Web services specifications that I am familiar in due to my background in DPWS.=20 Nevertheless, let's leave the discussion around SOAP, because there seems t= o be many misunderstandings related to SOAP and what I wanted to point at. What I wanted to say is (and that is my still my opinion after reading current COAP I-D): there is no reason to bind COAP to UDP or TCP exclusivel= y or exclude one of them. COAP seems to describe many mechanisms for interaction with resources, eventing and discovery mechanisms, mechanisms t= o avoid duplicated message processing etc. But all these mechanisms do not depend on the transport layer. Why should a node not support interactions b= y using TCP or UDP at the same time for the same resource. Of course, not the highly resource constrained one, but we are heading towards heterogeneous device infrastructures where resource richer devices in the same network might be possible as well. Take the ideas or throw them away. But these are major decisions concerning applicability of the resulting COAP. What made HTTP and REST in the WWW suc= h a success was that it is possible to run it over all kinds of technologies and not to restrict it to specific message sizes. Let's say there is a cool new wireless technology IEEE 802.15.XY which is capable of running 6LoWPAN but with double of the frame size and data rate at same energy costs. Will there be the next COAPXY for this new link layer because suddenly there is double the bandwidth available? Again, Just my two cents ;) Guido > -----Urspr=FCngliche Nachricht----- > Von: Carsten Bormann [mailto:cabo@tzi.org] > Gesendet: Montag, 17. Mai 2010 16:24 > An: Guido Moritz > Cc: core@ietf.org > Betreff: Re: [core] Core UDP vs TCP : Redux >=20 > On May 17, 2010, at 15:58, Guido Moritz wrote: >=20 > > I just wanted to ask > > if it is reasonable to bind the CORE protocol to UDP,TCP or whatever or if > > it is possible to leave this open and design CORE extensible and flexible > > enough. >=20 > It may be hard to meet the working group's objective of addressing constrained > node/networks while leaving the underlying protocol(s) open. It may also be > hard to meet this objective while inserting a subprotocol as complex as SOAP > into the stack. >=20 > Gruesse, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core -------------------------------- Onzo is a limited company number 06097997 registered in England & Wales. Th= e =20 registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingd= om. This email message may contain confidential and/or privileged information, = and is intended solely for the addressee(s). If you have received this email in= =20 error, please notify Onzo immediately. Unauthorised copying, disclosure or= =20 distribution of the material in this email is forbidden. -------------------------------- From charles.palmer@onzo.com Mon May 17 08:57:24 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D5943A6A93 for ; Mon, 17 May 2010 08:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.086 X-Spam-Level: ** X-Spam-Status: No, score=2.086 tagged_above=-999 required=5 tests=[AWL=-1.635, BAYES_50=0.001, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHycoIguWfMu for ; Mon, 17 May 2010 08:57:21 -0700 (PDT) Received: from service38.mimecast.com (service38.mimecast.com [212.2.3.166]) by core3.amsl.com (Postfix) with SMTP id A14D33A6A71 for ; Mon, 17 May 2010 08:56:04 -0700 (PDT) Received: from onzosbs2k3.ONZO.local (217.138.5.2 [217.138.5.2]) by service38.mimecast.com; Mon, 17 May 2010 16:55:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 17 May 2010 16:55:42 +0100 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [core] Selecting a WG document for CoAP Thread-Index: Acr12JRx9Ph9sWWaRO2YyHYNHEGmUwAAD8oQ References: From: "Charles Palmer" To: X-MC-Unique: 110051716554700702 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CAF5D9.69034CBC" Cc: core-bounces@ietf.org, core Subject: Re: [core] Selecting a WG document for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 15:57:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAF5D9.69034CBC Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CAF5D9.69034CBC" ------_=_NextPart_002_01CAF5D9.69034CBC Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi Matthieu =20 I guess the decision on format of message content (e.g. XML/EXI or not) can= be taken independently of the POST/webhooks vs SUBSCRIBE/notify mechanism. =20 Could the second POST (effectively the Notify) be extended to include the c= hanged data, to avoid the subsequent GET? =20 Regards - Charles Palmer=20 Onzo Limited (Project Hydra Project Manager)=20 Woodthorpe, Calver Road, Baslow, Derbyshire, DE45 1RR, United Kingdom=20 Ph: +44 (0)1246 582 220, Mob: +44 (0)7977 577 627=20 Email: charles.palmer@onzo.com Skype: Acutetech =20 From: matthieu.vial@fr.non.schneider-electric.com [mailto:matthieu.vial@fr.= non.schneider-electric.com]=20 Sent: 17 May 2010 16:44 To: Charles Palmer Cc: core; core-bounces@ietf.org Subject: Re: [core] Selecting a WG document for CoAP =20 Hi, My comments about the subscribe/notify mechanism of Zigbee IP. Pros: - Derived from the webhooks concept - If used by CORE it will be easier to map to HTTP because it uses only CRU= D verbs. - The subscription message is extendable and could support advanced options= (delays, increment, ...)=20 - Only one listening port whatever the transport binding is. Cons: - No interoperability without well known URIs and a well defined subscripti= on message format (Not sure CoAP draft is the right place to specify this). - XML/EXI is too complex to be the required format for the default subscrip= tion/notification mechanism. - The notification should not require a subsequent GET to retrieve the cont= ent. - Subresource subscription is redundant. Hope this could help, Matthieu "Charles Palmer" "Charles Palmer" =20 Envoy=E9 par : core-bounces@ietf.org=20 15/05/2010 14:06 =20 A =20 "core" cc Objet Re: [core] Selecting a WG document for CoAP =20 Dear all Those interested in the subscribe/notify discussion might like to look at the draft Smart Energy Profile 2.0 Application Protocol Specification. It is available here: http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicApp licationProfile.aspx It manages subscribe/notify by using POST. This seems to remove the need for SUBSCRIBE and notify. "Imagine a host A, which exposes a resource at http{s}://A/resource and a second host B, which wishes to learn of changes to this resource. To facilitate a subscription/ notification mechanism, A would expose a resource http{s}://A/sub and B would expose a resource http{s}://B/ntfy. To subscribe to notifications regarding http{s}://A/resource, B would send a POST to the address http{s}://A/sub/B containing the URI of the resource of interest (http{s}://A/resource) and the URI of B's notification resource (http{s}://B/ntfy). Following this subscription step, should A wish to notify B of a change to the resource addressed at http{s}://A/resource, A would send a POST to the address http{s}://B/ntfy containing the URI of the resource changed (http{s}://A/resource) and the URI of A's subscription resource (http{s}://A/sub/B), should A wish to change its subscription. The host B can then query the resource (or not) at its leisure." Sleepy nodes are not allowed to subscribe, and must poll. Regards - Charles Palmer=20 -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Angelo P. Castellani Sent: 14 May 2010 13:14 To: Zach Shelby Cc: core Subject: Re: [core] Selecting a WG document for CoAP Zach, thanks for the comments, but please refer to my most recent e-mail for a more specific list of technical issues I'm pointing to. I want to do only a little integration to what I've written there. In my very personal opinion, to maximize adherence with the REST model and minimize implementation effort SUBSCRIBE and NOTIFY should be mapped to methods (as discussed many times together...). Uniform interface principle (Fielding PhD dissertation Section 5.1.5, "The central feature that distinguishes the REST architectural style [...]") states that to simplify the software architecture, resource interfaces/interfaces should be as general as possible. I agree with this principle in this specific case, mainly because handling a special message type for notify leads node software design to a more complex architecture. The reason is that this new message type requires special handling and introduces a complexity in the software modularization. Best, Angelo On Fri, May 14, 2010 at 13:06, Zach Shelby wrote: > Hi Angelo, > > On May 13, 2010, at 14:24 , Angelo P. Castellani wrote: > >> Dear C. Bormann, all, >> >> before deciding for the final direction, I've the following >> observations about draft-shelby-core-coap-01 >> >> While I mostly share Zach's view of the protocol approach, and >> appreciate many aspects of the proposal, there are in my opinion still >> some open issues that need to be at least discussed before the current >> document can be selected. > > Of course there are plenty of open issues. Remember that working group documents still undertake as much change and improvement as the WG wants, so by no means is coap-01 set in stone. I would expect at least 5-10 more revisions still along the way. Already several of your ideas have been integrated into coap-01, and several more are under consideration, so it is coming along. Patience ;-) > >> >> In particular, I would like to highlight the following: >> >> a) As it is now, it is not possible to have a straightforward >> translation of HTTP -> CoAP and viceversa: see >> http://www.ietf.org/mail-archive/web/core/current/msg00133.html (this >> impacts the scalability of the web service model too) > > In coap-01 the Method names are now identical to HTTP methods. The Req/Res interaction is a direct translation. The URI hierarchy is compatible, and the URI binary code format we are still working on obviously. The only thing that takes some state to translate is Subscribe/Notify. But note, Subscribe/Notify takes some state no matter how you do it, even with HTTP-HTTP there is no clean and easy way to handle subscriptions. > >> >> b) Moreover, CoAP's implementation is not as simple as it should be. >> I've investigated the implementation and some design choices (as >> Options) are leading to very high program complexity (ROM) on a >> MSP430-based device. > > This we can definitely improve, and already made several optimizations from -00 to -01. Here I need some very concrete proposals though. Also remember that many things are optional, for example subscribe/notify is not required if you don't need it. > >> c) Finally when comparing HTTP message size with CoAP message size, >> the resulting compression isn't as good as you may expect. >> >> Example: >> HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B >> CoAP: 24 B with options parsing procedure requiring an added >> implementation complexity > > Right, that is not how it will work in practice. Working with a real HTTP server that HTTP header will be more complex, and on the CoAP side you would chose shorter URLs. The biggest improvement possible here is from using binary coded URLs of course. We need to look at a wider range of interactions and real HTTP headers as well to check that we are efficient enough. > >> Addressing all these points potentially leads to major technical >> modifications (especially point a) on the current draft, hence it is >> appropriate in my opinion to discuss these points before making the >> final decision. > > I am not sure what else you have in mind for a). If we just forget about Subscribe/Notify then you are good to go. But then you are also not fulfilling the charter or the industry needs in that respect. > > Thanks, > Zach > >> >> Best regards, >> >> Angelo P. Castellani >> >> >> On Mon, May 10, 2010 at 18:51, Carsten Bormann wrote: >>> The CORE WG has a milestone to select a WG document for CoAP in April: >>> >>> http://datatracker.ietf.org/wg/core/charter/ >>> ... >>> Apr 2010 Select WG document for basis of the CoAP protocol >>> >>> Of the various documents that have been contributed, draft-shelby-core-coap has significant discussion, as well as the largest number of updates (including a previous version that was still called -6lowapp-coap). >>> >>> Today, another updated version of that draft was announced. See >>> http://www.ietf.org/mail-archive/web/core/current/msg00138.html >>> for the announcement and >>> http://tools.ietf.org/html/draft-shelby-core-coap-01 >>> for the draft itself. >>> >>> However, as the authors say, there are still significant TODOs. >>> >>> Are we in a state yet where we can say whether this is the right direction for the WG to take? >>> If yes, is it the right direction? Should we adopt it as a WG document? >>> If you don't think we can say yet, is there a set of technical decisions you would like the authors to take with priority? >>> >>> Note that once a document has become a WG document, the authors act as editors for the working group, making (and usually fleshing out the details of) any change that the WG decides it needs. >>> If you think we can still improve the draft, this is not an obstacle to making it a WG document. >>> But of course we shouldn't do that if we intend to reverse its fundamental technical direction. >>> >>> In order to stay roughly in sync with our milestones, we should reach at a decision on how to go forward this week. >>> >>> Gruesse, Carsten >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core -------------------------------- Onzo is a limited company number 06097997 registered in England & Wales. Th= e =20 registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingd= om. This email message may contain confidential and/or privileged information, = and is intended solely for the addressee(s). If you have received this email in= =20 error, please notify Onzo immediately. Unauthorised copying, disclosure or= =20 distribution of the material in this email is forbidden. -------------------------------- _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ -------------------------------- Onzo is a limited company number 06097997 registered in England & Wales. Th= e =20 registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingd= om. This email message may contain confidential and/or privileged information, = and is intended solely for the addressee(s). If you have received this email in= =20 error, please notify Onzo immediately. Unauthorised copying, disclosure or= =20 distribution of the material in this email is forbidden. -------------------------------- ------_=_NextPart_002_01CAF5D9.69034CBC Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable =20 =20

Hi Matthieu

 

I guess the decision on format of message content (e.g. XML/= EXI or not) can be taken independently of the POST/webhooks vs SUBSCRIBE/notify mechanism.

 

Could the second POST (effectively the Notify) be extended t= o include the changed data, to avoid the subsequent GET?

 

Regards - Charles Palmer
Onzo Limited (Project Hydra Project Manager)
Woodthorpe, Calver Road, Baslow, Derbyshire, DE45 1RR, United Kingdom
Ph: +44 (0)1246 582 220, Mob: +44 (0)7977 577 627
Email: charles.palmer@onzo.com Skype: Acutetech

 

From: matthieu.vial@fr.non.schneider-electric= .com [mailto:matthieu.vial@fr.non.schneider-electric.com]
Sent: 17 May 2010 16:44
To: Charles Palmer
Cc: core; core-bounces@ietf.org
Subject: Re: [core] Selecting a WG document for CoAP

 

Hi,

My comments about the subscribe/notify mechanism of Zigbee IP.

Pros:
- Derived from the webhooks concept
- If used by CORE it will be easier to map to HTTP because it uses only CRU= D verbs.
- The subscription message is extendable and could support advanced options (delays, increment, ...)
- Only one listening port whatever the transport binding is.

Cons:
- No interoperability without well known URIs and a well defined subscripti= on message format (Not sure CoAP draft is the right place to specify this). - XML/EXI is too complex to be the required format for the default subscription/notification mechanism.
- The notification should not require a subsequent GET to retrieve the cont= ent.
- Subresource subscription is redundant.

Hope this could help,
Matthieu


3D"Inactive"Charles Palmer" <charles.palmer@onzo.com>



"Charles Palmer" <charles.palmer@onzo.com>=
Envoy=E9 par : core-bounces@ietf.org

15/05/2= 010 14:06

A


"core" <core@ietf.org>=

cc

Objet


Re: [core] Selecting a WG document for= CoAP

 


Dear all

Those interested in the subscribe/notify discussion might like to look<= /tt>
at the draft Smart Energy Profile 2.0 Application Protocol
Specification. It is available here:
http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20Publi= cApp
licationProfile.aspx

It manages subscribe/notify by using POST. This seems to remove the nee= d
for SUBSCRIBE and notify.

"Imagine a host A, which exposes a resource at http{s}://A/resourc= e and
a second host B, which wishes to learn of changes to this resource. To<= /tt>
facilitate a subscription/ notification mechanism, A would expose a
resource http{s}://A/sub and B would expose a resource http{s}://B/ntfy= .
To subscribe to notifications regarding http{s}://A/resource, B would
send a POST to the address http{s}://A/sub/B containing the URI of the<= /tt>
resource of interest (http{s}://A/resource) and the URI of B's
notification resource (http{s}://B/ntfy). Following this subscription
step, should A wish to notify B of a change to the resource addressed a= t
http{s}://A/resource, A would send a POST to the address
http{s}://B/ntfy containing the URI of the resource changed
(http{s}://A/resource) and the URI of A's subscription resource (http{s}://A/sub/B), should A wish to change its subscription. The host=
B can then query the resource (or not) at its leisure."

Sleepy nodes are not allowed to subscribe, and must poll.

Regards - Charles Palmer

-----Original Message-----
From: core-bounces@ietf.org [m= ailto:core-bounces@ietf.org] On Behalf Of
Angelo P. Castellani
Sent: 14 May 2010 13:14
To: Zach Shelby
Cc: core
Subject: Re: [core] Selecting a WG document for CoAP

Zach,

thanks for the comments, but please refer to my most recent e-mail for<= /tt>
a more specific list of technical issues I'm pointing to.

I want to do only a little integration to what I've written there.=

In my very personal opinion, to maximize adherence with the REST model<= /tt>
and minimize implementation effort SUBSCRIBE and NOTIFY should be<= br> mapped to methods (as discussed many times together...).

Uniform interface principle (Fielding PhD dissertation Section 5.1.5,
"The central feature that distinguishes the REST architectural sty= le
[...]") states that to simplify the software architecture, resourc= e
interfaces/interfaces should be as general as possible.

I agree with this principle in this specific case, mainly because<= br> handling a special message type for notify leads node software design
to a more complex architecture.

The reason is that this new message type requires special handling and<= /tt>
introduces a complexity in the software modularization.

Best,
Angelo

On Fri, May 14, 2010 at 13:06, Zach Shelby <zach@sensinode.com> wrote:
> Hi Angelo,
>
> On May 13, 2010, at 14:24 , Angelo P. Castellani wrote:
>
>> Dear C. Bormann, all,
>>
>> before deciding for the final direction, I've the following
>> observations about draft-shelby-core-coap-01
>>
>> While I mostly share Zach's view of the protocol approach, and=
>> appreciate many aspects of the proposal, there are in my opini= on
still
>> some open issues that need to be at least discussed before the=
current
>> document can be selected.
>
> Of course there are plenty of open issues. Remember that working g= roup
documents still undertake as much change and improvement as the WG=
wants, so by no means is coap-01 set in stone. I would expect at least<= /tt>
5-10 more revisions still along the way.  Already several of your ideas
have been integrated into coap-01, and several more are under
consideration, so it is coming along. Patience ;-)
>
>>
>> In particular, I would like to highlight the following: >>
>> a) As it is now, it is not possible to have a straightforward<= /tt>
>> translation of HTTP -> CoAP and viceversa: see
>> ht= tp://www.ietf.org/mail-archive/web/core/current/msg00133.html (thi= s
>> impacts the scalability of the web service model too)
>
> In coap-01 the Method names are now identical to HTTP methods. The=
Req/Res interaction is a direct translation. The URI hierarchy is<= br> compatible, and the URI binary code format we are still working on=
obviously. The only thing that takes some state to translate is Subscribe/Notify. But note, Subscribe/Notify takes some state no matter=
how you do it, even with HTTP-HTTP there is no clean and easy way to
handle subscriptions.
>
>>
>> b) Moreover, CoAP's implementation is not as simple as it shou= ld be.
>> I've investigated the implementation and some design choices (= as
>> Options) are leading to very high program complexity (ROM) on = a
>> MSP430-based device.
>
> This we can definitely improve, and already made several optimizat= ions
from -00 to -01. Here I need some very concrete proposals though. Also<= /tt>
remember that many things are optional, for example subscribe/notify is=
not required if you don't need it.
>
>> c) Finally when comparing HTTP message size with CoAP message size,
>> the resulting compression isn't as good as you may expect.
>>
>> Example:
>> HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B
>> CoAP: 24 B with options parsing procedure requiring an added
>> implementation complexity
>
> Right, that is not how it will work in practice. Working with a re= al
HTTP server that HTTP header will be more complex, and on the CoAP side=
you would chose shorter URLs. The biggest improvement possible here is<= /tt>
from using binary coded URLs of course. We need to look at a wider rang= e
of interactions and real HTTP headers as well to check that we are=
efficient enough.
>
>> Addressing all these points potentially leads to major technic= al
>> modifications (especially point a) on the current draft, hence= it is
>> appropriate in my opinion to discuss these points before makin= g the
>> final decision.
>
> I am not sure what else you have in mind for a). If we just forget=
about Subscribe/Notify then you are good to go. But then you are also
not fulfilling the charter or the industry needs in that respect.<= br> >
> Thanks,
> Zach
>
>>
>> Best regards,
>>
>> Angelo P. Castellani
>>
>>
>> On Mon, May 10, 2010 at 18:51, Carsten Bormann <cabo@tzi.org> wrote:
>>> The CORE WG has a milestone to select a WG document for Co= AP in
April:
>>>
>>> h= ttp://datatracker.ietf.org/wg/core/charter/
>>> ...
>>> Apr 2010        Select WG document for basis of the CoAP protocol
>>>
>>> Of the various documents that have been contributed,<= br> draft-shelby-core-coap has significant discussion, as well as the<= br> largest number of updates (including a previous version that was still<= /tt>
called -6lowapp-coap).
>>>
>>> Today, another updated version of that draft was announced= .  See
>>> ht= tp://www.ietf.org/mail-archive/web/core/current/msg00138.html
>>> for the announcement and
>>> http://tools.ietf.org/html/draft-shelby-core-coap-01
>>> for the draft itself.
>>>
>>> However, as the authors say, there are still significant TODOs.
>>>
>>> Are we in a state yet where we can say whether this is the right
direction for the WG to take?
>>> If yes, is it the right direction?  Should we adopt i= t as a WG
document?
>>> If you don't think we can say yet, is there a set of techn= ical
decisions you would like the authors to take with priority?
>>>
>>> Note that once a document has become a WG document, the authors act
as editors for the working group, making (and usually fleshing out the<= /tt>
details of) any change that the WG decides it needs.
>>> If you think we can still improve the draft, this is not a= n obstacle
to making it a WG document.
>>> But of course we shouldn't do that if we intend to reverse= its
fundamental technical direction.
>>>
>>> In order to stay roughly in sync with our milestones, we should
reach at a decision on how to go forward this week.
>>>
>>> Gruesse, Carsten
>>>
>>> _______________________________________________
>>> core mailing list
>>> core@ietf.org
>>> htt= ps://www.ietf.org/mailman/listinfo/core
>>>
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https:/= /www.ietf.org/mailman/listinfo/core
>
> --
> Zach Shelby, Chief Nerd, Sensinode Ltd.
> http://zachshelby.org  = - My blog "On the Internet of Things"
> http://6lowpan.net - My bo= ok "6LoWPAN: The Wireless Embedded Internet"
> Mobile: +358 40 7796297
>
>
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf= .org/mailman/listinfo/core

--------------------------------
Onzo is a limited company number 06097997 registered in England & Wales. The    
registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingdom.

This email message may contain confidential and/or privileged informati= on, and
is intended solely for the addressee(s). If you have received this emai= l in    
error, please notify Onzo immediately. Unauthorised copying, disclosure= or
distribution of the material in this email is forbidden.
--------------------------------

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

______________________________________________________________________<= /tt>
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________<= /tt>


--------------------------------
Onzo is a limited company nu= mber 06097997 registered in England & Wales. The
registered office is 6 Great Newport Street, London, WC2H 7JB, Un= ited Kingdom.

This email message may contain confidential and/or privileged inf= ormation, and
is intended solely for the addressee(s). If you have received thi= s email in
error, please notify Onzo im= mediately. Unauthorised copying, disclosure or
distribution of the material in this email is forbidden.
--------------------------------
 ------_=_NextPart_002_01CAF5D9.69034CBC-- ------_=_NextPart_001_01CAF5D9.69034CBC Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------_=_NextPart_001_01CAF5D9.69034CBC Content-Type: image/png; name="image002.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.png Content-Location: image002.png iVBORw0KGgoAAAANSUhEUgAAADoAAAABCAMAAAC42E10AAAAAXNSR0ICQMB9xQAAAANQTFRFAAAA p3o92gAAAAF0Uk5TAEDm2GYAAAAJcEhZcwAADsQAAA7EAZUrDhsAAAAZdEVYdFNvZnR3YXJlAE1p Y3Jvc29mdCBPZmZpY2V/7TVxAAAADElEQVQY02NgIBsAAAA7AAFzMF3lAAAAAElFTkSuQmCC ------_=_NextPart_001_01CAF5D9.69034CBC Content-Type: image/png; name="image003.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image003.png Content-Location: image003.png iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAMAAAAoyzS7AAAAAXNSR0ICQMB9xQAAAANQTFRFAAAA p3o92gAAAAF0Uk5TAEDm2GYAAAAJcEhZcwAADsQAAA7EAZUrDhsAAAAZdEVYdFNvZnR3YXJlAE1p Y3Jvc29mdCBPZmZpY2V/7TVxAAAACklEQVQY02NgAAAAAgABmGNs1wAAAABJRU5ErkJggg== ------_=_NextPart_001_01CAF5D9.69034CBC-- From d.sturek@att.net Mon May 17 09:25:28 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3CFB28C1C9 for ; Mon, 17 May 2010 09:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.11 X-Spam-Level: * X-Spam-Status: No, score=1.11 tagged_above=-999 required=5 tests=[AWL=-1.274, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vaN0yeqQywV for ; Mon, 17 May 2010 09:25:27 -0700 (PDT) Received: from smtp108.sbc.mail.gq1.yahoo.com (smtp108.sbc.mail.gq1.yahoo.com [67.195.14.111]) by core3.amsl.com (Postfix) with SMTP id 1E92228C1CC for ; Mon, 17 May 2010 09:16:44 -0700 (PDT) Received: (qmail 43114 invoked from network); 17 May 2010 16:16:30 -0000 Received: from sfs-wifi-aruba-dhcp-130-212-158-90.sfsu.edu (d.sturek@130.212.158.90 with login) by smtp108.sbc.mail.gq1.yahoo.com with SMTP; 17 May 2010 09:16:30 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: ox2n7TEVM1kTC3td_DEcp8fxf9wKh.sV1QVavNsiBjlQZ0Ydq5hzU5pcJSrMs.vhcBEkJyFvfGTmL3UJSmKiOrrADDf0NUWod4uicgkIiI0RA7LVwdHrRvdDz6XD_qyLyig31.1WZ4zVtyyXbTsN5gOxLeoHYRPt1J6IxPdHcI4lF0crHGBFupJiaXDNQktrpL1KKXYpqAC.iWghVhKM0FjvXxHmYPAb.elTVXTCHKmKB12o_FCiZsPipoki_gKPvz3_gb1SGefoYeK9wOjWSgO7iQJd3lY9sd1dRR7YdpanJprCnOo- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Charles Palmer'" , "'core'" References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de><2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry><006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de><041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org> <007c01caf5d3$30f026f0$92d074d0$@moritz@uni-rostock.de> In-Reply-To: Date: Mon, 17 May 2010 09:16:28 -0700 Message-ID: <011601caf5dc$4ed71850$ec8548f0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr1zJc/bvdnn+5LQpypULdy1SC3ZQAA0P1wAAFHDkAAAZqG8A== Content-Language: en-us Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 16:25:28 -0000 Hi Charles, I think HTTP/TCP/IP/EXI was selected in Smart Energy 2.0 to provide a familiar programming environment for the headend systems. In general, = we (the SE 2.0 team) chose REST as the programming paradigm with HTTP/TCP = as "plan A" and CoRE/UDP as "plan B". Plan B is around ensuring that the = stack fits on small footprint devices (particularly those already fielded). = We (SE 2.0) are in the midst of interoperability testing of IEEE 802.15.4/6LowPAN/IPv6/TCP/HTTP so we should have some throughput/efficiency/code size issues shortly. In any case, we believe that CoRE is a fundamental feature needed to = deploy small footprint devices. Don -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Charles Palmer Sent: Monday, May 17, 2010 8:48 AM To: core Subject: Re: [core] Core UDP vs TCP : Redux Hi folks Worth noting that the draft ZigBee Smart Energy 2.0 Application Protocol Specification is very good about not mandating the transport layer = (although it talks extensively about TLS - does this limit it to TCP?) The SE2.0 spec also makes reference to possibly using CoRE (see quote below). BTW how closely are we/should we be tracking SE2.0 work? I see several names in both lists. I'd speculate that if CoRE is to be of use = to ZigBee Smart Energy then CoRE needs to provide an easy transition. I guess SE2.0 plans to use HTTP/EXI/TCP/IP because they exist and work.=20 How disruptive would it be to design CoRE without reference to TCP/UDP, = and also design a "reliable UDP" and use this for CoRE?=20 >From SE2.0: "6.1 Protocol Flexibility The Smart Energy Profile is designed to implement a RESTful = architecture. As such it is built around the core actions of GET, PUT, POST, and DELETE = (as used in [REST]), with the addition of a lightweight subscription and notification mechanism, as discussed above in =A77. It is not however, strictly limited to HTTP. Any protocol that can implement the GET, PUT, POST, and DELETE command set can be used with SEP 2.0. It is expected = that HTTP is the preferred protocol for interactions with the broader = Internet, and that protocol translation services are provided when it is desired = to link an SEP system using another application protocol with HTTP based solutions. The lightweight RESTful Constrained Application Protocol = (CoAP) is one such alternative to HTTP [COAP]. This protocol should be proxied = to HTTP for interactions with the broader Internet, but may be applied end-to-end." Regards - Charles Palmer=20 -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Guido Moritz Sent: 17 May 2010 16:11 To: core@ietf.org Subject: Re: [core] Core UDP vs TCP : Redux > It may also be hard to meet this objective while inserting a = subprotocol as complex as SOAP into the stack. I just went through the current COAP I-D and it is already quite = complex! It includes many mechanisms and concepts which are also included in SOAP = and other W3C/OASIS Web services specifications that I am familiar in due to = my background in DPWS.=20 Nevertheless, let's leave the discussion around SOAP, because there = seems to be many misunderstandings related to SOAP and what I wanted to point at. What I wanted to say is (and that is my still my opinion after reading current COAP I-D): there is no reason to bind COAP to UDP or TCP = exclusively or exclude one of them. COAP seems to describe many mechanisms for interaction with resources, eventing and discovery mechanisms, = mechanisms to avoid duplicated message processing etc. But all these mechanisms do not depend on the transport layer. Why should a node not support = interactions by using TCP or UDP at the same time for the same resource. Of course, not = the highly resource constrained one, but we are heading towards = heterogeneous device infrastructures where resource richer devices in the same network might be possible as well. Take the ideas or throw them away. But these are major decisions = concerning applicability of the resulting COAP. What made HTTP and REST in the WWW = such a success was that it is possible to run it over all kinds of = technologies and not to restrict it to specific message sizes. Let's say there is a = cool new wireless technology IEEE 802.15.XY which is capable of running = 6LoWPAN but with double of the frame size and data rate at same energy costs. = Will there be the next COAPXY for this new link layer because suddenly there = is double the bandwidth available? Again, Just my two cents ;) Guido > -----Urspr=FCngliche Nachricht----- > Von: Carsten Bormann [mailto:cabo@tzi.org] > Gesendet: Montag, 17. Mai 2010 16:24 > An: Guido Moritz > Cc: core@ietf.org > Betreff: Re: [core] Core UDP vs TCP : Redux >=20 > On May 17, 2010, at 15:58, Guido Moritz wrote: >=20 > > I just wanted to ask > > if it is reasonable to bind the CORE protocol to UDP,TCP or whatever = or if > > it is possible to leave this open and design CORE extensible and flexible > > enough. >=20 > It may be hard to meet the working group's objective of addressing constrained > node/networks while leaving the underlying protocol(s) open. It may = also be > hard to meet this objective while inserting a subprotocol as complex = as SOAP > into the stack. >=20 > Gruesse, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core -------------------------------- Onzo is a limited company number 06097997 registered in England & Wales. = The registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingdom. This email message may contain confidential and/or privileged = information, and is intended solely for the addressee(s). If you have received this email = in error, please notify Onzo immediately. Unauthorised copying, disclosure = or=20 distribution of the material in this email is forbidden. -------------------------------- _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From matthieu.vial@fr.non.schneider-electric.com Mon May 17 09:45:42 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 230143A6872; Mon, 17 May 2010 09:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.99 X-Spam-Level: ** X-Spam-Status: No, score=2.99 tagged_above=-999 required=5 tests=[AWL=-0.875, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdTe9cuJU+3E; Mon, 17 May 2010 09:45:39 -0700 (PDT) Received: from mailX03.eud.schneider-electric.com (mailx03.eud.schneider-electric.com [205.167.7.41]) by core3.amsl.com (Postfix) with ESMTP id 333453A688B; Mon, 17 May 2010 09:45:26 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX03.eud.schneider-electric.com with ESMTP id 2010051718355597-80151 ; Mon, 17 May 2010 18:35:55 +0200 In-Reply-To: To: "Charles Palmer" X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: matthieu.vial@fr.non.schneider-electric.com Date: Mon, 17 May 2010 18:45:13 +0200 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 17/05/2010 18:45:16, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 17/05/2010 18:35:56, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 17/05/2010 18:35:58 Content-type: multipart/related; Boundary="0__=4EBBFDB5DFCA354B8f9e8a93df938690918c4EBBFDB5DFCA354B" Cc: core-bounces@ietf.org, core Subject: Re: [core] Selecting a WG document for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 16:45:42 -0000 --0__=4EBBFDB5DFCA354B8f9e8a93df938690918c4EBBFDB5DFCA354B Content-type: multipart/alternative; Boundary="1__=4EBBFDB5DFCA354B8f9e8a93df938690918c4EBBFDB5DFCA354B" --1__=4EBBFDB5DFCA354B8f9e8a93df938690918c4EBBFDB5DFCA354B Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=ISO-8859-1 >I guess the decision on format of message content (e.g. XML/EXI or not= ) can be taken independently of the POST/webhooks vs SUBSCRIBE/notify mechanism. Of course but I have the feeling that interoperability between CoAP dev= ices may suffer from the webhooks approach because of a new message definiti= on whatever it is. I hope I'am wrong because I still prefer webhooks. >Could the second POST (effectively the Notify) be extended to include = the changed data, to avoid the subsequent GET? If the notification URI is different for each subscribed resource could= the POST content be as simple as the extra GET ? Best regards, Matthieu = "Charles Palmer" = = A Matthieu = 17/05/2010 17:55 Vial/FR/Non/Schneider@Europe = = cc "core" , = = Ob= jet RE: [core] Selecting a WG docume= nt for CoAP = = = = = = = From: matthieu.vial@fr.non.schneider-electric.com [mailto:matthieu.vial@fr.non.schneider-electric.com] Sent: 17 May 2010 16:44 To: Charles Palmer Cc: core; core-bounces@ietf.org Subject: Re: [core] Selecting a WG document for CoAP Hi, My comments about the subscribe/notify mechanism of Zigbee IP. Pros: - Derived from the webhooks concept - If used by CORE it will be easier to map to HTTP because it uses only= CRUD verbs. - The subscription message is extendable and could support advanced opt= ions (delays, increment, ...) - Only one listening port whatever the transport binding is. Cons: - No interoperability without well known URIs and a well defined subscription message format (Not sure CoAP draft is the right place to specify this). - XML/EXI is too complex to be the required format for the default subscription/notification mechanism. - The notification should not require a subsequent GET to retrieve the content. - Subresource subscription is redundant. Hope this could help, Matthieu Inactive hide details for "Charles Palmer" "Charles Palmer" = "Charles Palmer" = = Envoy=E9 par : = core-bounces@ietf.org = = A = 15/05/2010 14:06 "core" = = = cc = = Ob= jet = Re: [core] Selecting a = WG document for CoAP = = = = = = = = = = = Dear all Those interested in the subscribe/notify discussion might like to look at the draft Smart Energy Profile 2.0 Application Protocol Specification. It is available here: http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicAp= p licationProfile.aspx It manages subscribe/notify by using POST. This seems to remove the nee= d for SUBSCRIBE and notify. "Imagine a host A, which exposes a resource at http{s}://A/resource and= a second host B, which wishes to learn of changes to this resource. To facilitate a subscription/ notification mechanism, A would expose a resource http{s}://A/sub and B would expose a resource http{s}://B/ntfy= . To subscribe to notifications regarding http{s}://A/resource, B would send a POST to the address http{s}://A/sub/B containing the URI of the resource of interest (http{s}://A/resource) and the URI of B's notification resource (http{s}://B/ntfy). Following this subscription step, should A wish to notify B of a change to the resource addressed a= t http{s}://A/resource, A would send a POST to the address http{s}://B/ntfy containing the URI of the resource changed (http{s}://A/resource) and the URI of A's subscription resource (http{s}://A/sub/B), should A wish to change its subscription. The host= B can then query the resource (or not) at its leisure." Sleepy nodes are not allowed to subscribe, and must poll. Regards - Charles Palmer -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of= Angelo P. Castellani Sent: 14 May 2010 13:14 To: Zach Shelby Cc: core Subject: Re: [core] Selecting a WG document for CoAP Zach, thanks for the comments, but please refer to my most recent e-mail for a more specific list of technical issues I'm pointing to. I want to do only a little integration to what I've written there. In my very personal opinion, to maximize adherence with the REST model and minimize implementation effort SUBSCRIBE and NOTIFY should be mapped to methods (as discussed many times together...). Uniform interface principle (Fielding PhD dissertation Section 5.1.5, "The central feature that distinguishes the REST architectural style [...]") states that to simplify the software architecture, resource interfaces/interfaces should be as general as possible. I agree with this principle in this specific case, mainly because handling a special message type for notify leads node software design to a more complex architecture. The reason is that this new message type requires special handling and introduces a complexity in the software modularization. Best, Angelo On Fri, May 14, 2010 at 13:06, Zach Shelby wrote: > Hi Angelo, > > On May 13, 2010, at 14:24 , Angelo P. Castellani wrote: > >> Dear C. Bormann, all, >> >> before deciding for the final direction, I've the following >> observations about draft-shelby-core-coap-01 >> >> While I mostly share Zach's view of the protocol approach, and >> appreciate many aspects of the proposal, there are in my opinion still >> some open issues that need to be at least discussed before the current >> document can be selected. > > Of course there are plenty of open issues. Remember that working grou= p documents still undertake as much change and improvement as the WG wants, so by no means is coap-01 set in stone. I would expect at least 5-10 more revisions still along the way. Already several of your ideas= have been integrated into coap-01, and several more are under consideration, so it is coming along. Patience ;-) > >> >> In particular, I would like to highlight the following: >> >> a) As it is now, it is not possible to have a straightforward >> translation of HTTP -> CoAP and viceversa: see >> http://www.ietf.org/mail-archive/web/core/current/msg00133.html (thi= s >> impacts the scalability of the web service model too) > > In coap-01 the Method names are now identical to HTTP methods. The Req/Res interaction is a direct translation. The URI hierarchy is compatible, and the URI binary code format we are still working on obviously. The only thing that takes some state to translate is Subscribe/Notify. But note, Subscribe/Notify takes some state no matter= how you do it, even with HTTP-HTTP there is no clean and easy way to handle subscriptions. > >> >> b) Moreover, CoAP's implementation is not as simple as it should be.= >> I've investigated the implementation and some design choices (as >> Options) are leading to very high program complexity (ROM) on a >> MSP430-based device. > > This we can definitely improve, and already made several optimization= s from -00 to -01. Here I need some very concrete proposals though. Also remember that many things are optional, for example subscribe/notify is= not required if you don't need it. > >> c) Finally when comparing HTTP message size with CoAP message size, >> the resulting compression isn't as good as you may expect. >> >> Example: >> HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B >> CoAP: 24 B with options parsing procedure requiring an added >> implementation complexity > > Right, that is not how it will work in practice. Working with a real HTTP server that HTTP header will be more complex, and on the CoAP side= you would chose shorter URLs. The biggest improvement possible here is from using binary coded URLs of course. We need to look at a wider rang= e of interactions and real HTTP headers as well to check that we are efficient enough. > >> Addressing all these points potentially leads to major technical >> modifications (especially point a) on the current draft, hence it is= >> appropriate in my opinion to discuss these points before making the >> final decision. > > I am not sure what else you have in mind for a). If we just forget about Subscribe/Notify then you are good to go. But then you are also not fulfilling the charter or the industry needs in that respect. > > Thanks, > Zach > >> >> Best regards, >> >> Angelo P. Castellani >> >> >> On Mon, May 10, 2010 at 18:51, Carsten Bormann wrote:= >>> The CORE WG has a milestone to select a WG document for CoAP in April: >>> >>> http://datatracker.ietf.org/wg/core/charter/ >>> ... >>> Apr 2010 Select WG document for basis of the CoAP protocol >>> >>> Of the various documents that have been contributed, draft-shelby-core-coap has significant discussion, as well as the largest number of updates (including a previous version that was still called -6lowapp-coap). >>> >>> Today, another updated version of that draft was announced. See >>> http://www.ietf.org/mail-archive/web/core/current/msg00138.html >>> for the announcement and >>> http://tools.ietf.org/html/draft-shelby-core-coap-01 >>> for the draft itself. >>> >>> However, as the authors say, there are still significant TODOs. >>> >>> Are we in a state yet where we can say whether this is the right direction for the WG to take? >>> If yes, is it the right direction? Should we adopt it as a WG document? >>> If you don't think we can say yet, is there a set of technical decisions you would like the authors to take with priority? >>> >>> Note that once a document has become a WG document, the authors act= as editors for the working group, making (and usually fleshing out the details of) any change that the WG decides it needs. >>> If you think we can still improve the draft, this is not an obstacl= e to making it a WG document. >>> But of course we shouldn't do that if we intend to reverse its fundamental technical direction. >>> >>> In order to stay roughly in sync with our milestones, we should reach at a decision on how to go forward this week. >>> >>> Gruesse, Carsten >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet= " > Mobile: +358 40 7796297 > > _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core -------------------------------- Onzo is a limited company number 06097997 registered in England & Wales= . The registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingdom. This email message may contain confidential and/or privileged informati= on, and is intended solely for the addressee(s). If you have received this emai= l in error, please notify Onzo immediately. Unauthorised copying, disclosure= or distribution of the material in this email is forbidden. -------------------------------- _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ -------------------------------- Onzo is a limited company number 06097= 997 registered in England & Wales. The registered office is 6 Great Newport= Street, London, WC2H 7JB, United Kingdom. This email message may contai= n confidential and/or privileged information, and is intended solely for = the addressee(s). If you have received this email in error, please notify O= nzo immediately. Unauthorised copying, disclosure or distribution of the material in this email is forbidden. -------------------------------- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ = --1__=4EBBFDB5DFCA354B8f9e8a93df938690918c4EBBFDB5DFCA354B Content-transfer-encoding: quoted-printable Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline


>I guess the decision on format of message content (e.g. XML/EXI or = not) can be taken independently of the POST/webhooks vs SUBSCRIBE/notif= y mechanism.
Of course but I have the feeling that interoperability between CoAP dev= ices may suffer from the webhooks approach because of a new message def= inition whatever it is.
I hope I'am wrong because I still prefer webhooks.

>Could the second POST (effectively the Notify) be extended to inclu= de the changed data, to avoid the subsequent GET?
If the notification URI is different for each subscribed resource could= the POST content be as simple as the extra GET ?

Best regards,
Matthieu

3D"Inactive"Charles Pa= lmer" <charles.palmer@onzo.com>




=
          "Charles Palmer" <charles.palmer@o= nzo.com>

          17/05/2010 17:55

 = =
3D=
A
3D""
Matthieu Vial/FR/Non/Schneider@Europe
3D=
cc
3D""
"core" <core@ietf.org>, <core-bounc= es@ietf.org>
3D=
Objet
3D""
RE: [core] Selecting a WG document for CoAP
3D=3D""

From: matthieu.vial@fr.non.schneider-electric.com [mailto:matthieu.via= l@fr.non.schneider-electric.com]
Sent: 17 May 2010 16:44
To: Charles Palmer
Cc: core; core-bounces@ietf= .org
Subject: Re: [core] Selecti= ng a WG document for CoAP

Hi,

My comments about the subscribe/notify mechanism of Zigbee IP.

Pros:
- Derived from the webhooks concept
- If used by CORE it will be easier to map to HTTP because it uses only= CRUD verbs.
- The subscription message is extendable and could support advanced opt= ions (delays, increment, ...)
- Only one listening port whatever the transport binding is.

Cons:
- No interoperability without well known URIs and a well defined subscr= iption message format (Not sure CoAP draft is the right place to specif= y this).
- XML/EXI is too complex to be the required format for the default subs= cription/notification mechanism.
- The notification should not require a subsequent GET to retrieve the = content.
- Subresource subscription is redundant.

Hope this could help,
Matthieu


3D"Inactive"Charles Palmer" <charles.palmer@onzo.co= m>

=
"Charles Palmer" <charles.palmer@onzo.com>
Envoy=E9 par : core-bounces@ietf.org

15/05/2010 14:06

 =
A

"core" <core@ietf.org>
cc
Objet
<= font size=3D"4" face=3D"Times New Roman">
Re: [core] Selecting a WG document for CoAP


=
3D=3D""


Dear all

Those interested in the subscribe/notify discussion might like to look<= br> at the draft Smart Energy Profile 2.0 Application Protocol
Specification. It is available here:
http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEne= rgy20PublicApp
= licationProfile.aspx

It manages subscribe/notify by using POST. This seems to remove the nee= d
for SUBSCRIBE and notify.

"Imagine a host A, which exposes a resource at http{s}://A/resourc= e and
a second host B, which wishes to learn of changes to this resource. To<= br> facilitate a subscription/ notification mechanism, A would expose a
= resource http{s}://A/sub and B would expose a resource http{s}://B/ntfy= .
To subscribe to notifications regarding http{s}://A/resource, B would send a POST to the address http{s}://A/sub/B containing the URI of the<= br> resource of interest (http{s}://A/resource) and the URI of B's
notification resource (http{s}://B/ntfy). Following this subscription step, should A wish to notify B of a change to the resource addressed a= t
http{s}://A/resource, A would send a POST to the address
http{s}://B/ntfy containing the URI of the resource changed
(http{s}://A/resource) and the URI of A's subscription resource
(http{s}://A/sub/B), should A wish to change its subscription. The host=
B can then query the resource (or not) at its leisure."

Sleepy nodes are not allowed to subscribe, and must poll.

Regards - Charles Palmer

-----Original Message-----
From: core-bounces@ietf.org [mailto= :core-bounces@ietf.org] On Behalf Of
Angelo P. Castellani
Sent: 14 May 2010 13:14
To: Zach Shelby
Cc: core
Subject: Re: [core] Selecting a WG document for CoAP

Zach,

thanks for the comments, but please refer to my most recent e-mail for<= br> a more specific list of technical issues I'm pointing to.

I want to do only a little integration to what I've written there.

In my very personal opinion, to maximize adherence with the REST model<= br> and minimize implementation effort SUBSCRIBE and NOTIFY should be
mapped to methods (as discussed many times together...).

Uniform interface principle (Fielding PhD dissertation Section 5.1.5, "The central feature that distinguishes the REST architectural sty= le
[...]") states that to simplify the software architecture, resourc= e
interfaces/interfaces should be as general as possible.

I agree with this principle in this specific case, mainly because
handling a special message type for notify leads node software design to a more complex architecture.

The reason is that this new message type requires special handling and<= br> introduces a complexity in the software modularization.

Best,
Angelo

On Fri, May 14, 2010 at 13:06, Zach Shelby <zach@sensinode.com> w= rote:
> Hi Angelo,
>
> On May 13, 2010, at 14:24 , Angelo P. Castellani wrote:
>
>> Dear C. Bormann, all,
>>
>> before deciding for the final direction, I've the following >> observations about draft-shelby-core-coap-01
>>
>> While I mostly share Zach's view of the protocol approach, and=
>> appreciate many aspects of the proposal, there are in my opini= on
still
>> some open issues that need to be at least discussed before the=
current
>> document can be selected.
>
> Of course there are plenty of open issues. Remember that working g= roup
documents still undertake as much change and improvement as the WG
wants, so by no means is coap-01 set in stone. I would expect at least<= br> 5-10 more revisions still along the way. Already several of your ideas=
have been integrated into coap-01, and several more are under
consideration, so it is coming along. Patience ;-)
>
>>
>> In particular, I would like to highlight the following:
>>
>> a) As it is now, it is not possible to have a straightforward<= br> >> translation of HTTP -> CoAP and viceversa: see
>> http://www.ietf.org/mail-archive/web/core/current/msg00133.htm= l (this
>> impacts the scalability of the web service model too)
>
> In coap-01 the Method names are now identical to HTTP methods. The=
Req/Res interaction is a direct translation. The URI hierarchy is
compatible, and the URI binary code format we are still working on
obviously. The only thing that takes some state to translate is
Subscribe/Notify. But note, Subscribe/Notify takes some state no matter=
how you do it, even with HTTP-HTTP there is no clean and easy way to handle subscriptions.
>
>>
>> b) Moreover, CoAP's implementation is not as simple as it shou= ld be.
>> I've investigated the implementation and some design choices (= as
>> Options) are leading to very high program complexity (ROM) on = a
>> MSP430-based device.
>
> This we can definitely improve, and already made several optimizat= ions
from -00 to -01. Here I need some very concrete proposals though. Also<= br> remember that many things are optional, for example subscribe/notify is=
not required if you don't need it.
>
>> c) Finally when comparing HTTP message size with CoAP message = size,
>> the resulting compression isn't as good as you may expect.
= >>
>> Example:
>> HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B
>> CoAP: 24 B with options parsing procedure requiring an added >> implementation complexity
>
> Right, that is not how it will work in practice. Working with a re= al
HTTP server that HTTP header will be more complex, and on the CoAP side=
you would chose shorter URLs. The biggest improvement possible here is<= br> from using binary coded URLs of course. We need to look at a wider rang= e
of interactions and real HTTP headers as well to check that we are
efficient enough.
>
>> Addressing all these points potentially leads to major technic= al
>> modifications (especially point a) on the current draft, hence= it is
>> appropriate in my opinion to discuss these points before makin= g the
>> final decision.
>
> I am not sure what else you have in mind for a). If we just forget=
about Subscribe/Notify then you are good to go. But then you are also not fulfilling the charter or the industry needs in that respect.
>
> Thanks,
> Zach
>
>>
>> Best regards,
>>
>> Angelo P. Castellani
>>
>>
>> On Mon, May 10, 2010 at 18:51, Carsten Bormann <cabo@tzi.or= g> wrote:
>>> The CORE WG has a milestone to select a WG document for Co= AP in
April:
>>>
>>> http:/= /datatracker.ietf.org/wg/core/charter/
>>> ...
>>> Apr 2010 Select WG document for basis of the CoAP p= rotocol
>>>
>>> Of the various documents that have been contributed,
draft-shelby-core-coap has significant discussion, as well as the
largest number of updates (including a previous version that was still<= br> called -6lowapp-coap).
>>>
>>> Today, another updated version of that draft was announced= . See
>>> http://www.ietf.org/mail-archive/web/core/current/msg00138= .html
>>> for the announcement and
>>>
>>> for the draft itself.
>>>
>>> However, as the authors say, there are still significant T= ODOs.
>>>
>>> Are we in a state yet where we can say whether this is the= right
direction for the WG to take?
>>> If yes, is it the right direction? Should we adopt it as = a WG
document?
>>> If you don't think we can say yet, is there a set of techn= ical
decisions you would like the authors to take with priority?
>>>
>>> Note that once a document has become a WG document, the au= thors act
as editors for the working group, making (and usually fleshing out the<= br> details of) any change that the WG decides it needs.
>>> If you think we can still improve the draft, this is not a= n obstacle
to making it a WG document.
>>> But of course we shouldn't do that if we intend to reverse= its
fundamental technical direction.
>>>
>>> In order to stay roughly in sync with our milestones, we s= hould
reach at a decision on how to go forward this week.
>>>
>>> Gruesse, Carsten
>>>
>>> _______________________________________________
>>> core mailing list
>>> core@ietf.org
>>> https://= www.ietf.org/mailman/listinfo/core
>>>
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> = https://www.= ietf.org/mailman/listinfo/core
>
> --
> Zach Shelby, Chief Nerd, Sensinode Ltd.
> http://zachshelby.org= - My blog "On the Internet= of Things"
> http://6lowpan.net - My book "6LoWPAN: The Wireless E= mbedded Internet"
> Mobile: +358 40 7796297
>
>
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.= org/mailman/listinfo/core

--------------------------------
Onzo is a limited company number 06097997 registered in England & W= ales. The
registered office is 6 Great Newport Street, London, WC2H 7JB, United K= ingdom.

This email message may contain confidential and/or privileged informati= on, and
is intended solely for the addressee(s). If you have received this emai= l in
error, please notify Onzo immediately. Unauthorised copying, disclosure= or
distribution of the material in this email is forbidden.
--------------------------------

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

______________________________________________________________________<= br> This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________<= /font>


-------------------------------- Onzo<= /a> is a limited company number 0609799= 7 registered in England & Wales. The registered office is 6 Great N= ewport Street, London, WC2H 7JB, United Kingdom. This email message may= contain confidential and/or privileged information, and is intended so= lely for the addressee(s). If you have received this email in error, pl= ease notify Onzo immediately. Unauthorised copying, disclosure or distrib= ution of the material in this email is forbidden. ---------------------= -----------
______________________________________________________________________<= br> This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________<= /font>

= --1__=4EBBFDB5DFCA354B8f9e8a93df938690918c4EBBFDB5DFCA354B-- --0__=4EBBFDB5DFCA354B8f9e8a93df938690918c4EBBFDB5DFCA354B Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=4EBBFDB5DFCA354B8@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=4EBBFDB5DFCA354B8f9e8a93df938690918c4EBBFDB5DFCA354B Content-type: image/gif; name="pic18875.gif" Content-Disposition: inline; filename="pic18875.gif" Content-ID: <2__=4EBBFDB5DFCA354B8@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=4EBBFDB5DFCA354B8f9e8a93df938690918c4EBBFDB5DFCA354B Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=4EBBFDB5DFCA354B8@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=4EBBFDB5DFCA354B8f9e8a93df938690918c4EBBFDB5DFCA354B-- From cabo@tzi.org Mon May 17 09:59:11 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C95F3A68AD for ; Mon, 17 May 2010 09:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.994 X-Spam-Level: X-Spam-Status: No, score=-3.994 tagged_above=-999 required=5 tests=[AWL=-0.945, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAciSZ75WzEg for ; Mon, 17 May 2010 09:59:10 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id DED1A3A6783 for ; Mon, 17 May 2010 09:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o4HGwsD1007804; Mon, 17 May 2010 18:58:54 +0200 (CEST) Received: from [192.168.217.101] (p5489B387.dip.t-dialin.net [84.137.179.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id BA9F5D38E; Mon, 17 May 2010 18:58:53 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Mon, 17 May 2010 18:58:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3C20B7FD-CB93-43CC-83D2-3F4209CC5B84@tzi.org> References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de><2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry><006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de><041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org> <007c01caf5d3$30f026f0$92d074d0$@moritz@uni-rostock.de> To: "Charles Palmer" X-Mailer: Apple Mail (2.1078) Cc: core Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 16:59:11 -0000 On May 17, 2010, at 17:47, Charles Palmer wrote: > How disruptive would it be to design CoRE without reference to = TCP/UDP, and also design a "reliable UDP" and use this for CoRE?=20 I personally think CoAP needs to work with DTLS; if the WG moves in that = direction there will be some minimum requirement for independence from = the underlying protocol. However, what we expect from the underlying protocol has a big bearing = on CoAP itself. If we expect we can always move to TCP, there will be little need to = make CoAP operate on large representations with small underlying = interactions. I've heard a lot of pushback on assuming the availability = of TCP, so far. There is also the aspect of interoperability: One of the great = properties of the Web is that everybody uses the same stack, so all Web = clients and servers are interoperable, with IP providing the necessary = technological diversity. (On the other hand, this has made it near impossible to swap in, say, = SCTP.) Just standardizing CoAP without an "we expect this to run on UDP, unless = otherwise specified" would not achieve the same level of = interoperability. In any case, designing a reliable transport as a TCP = replacement and then a CoAP on top of either that or TCP is very much = not what the charter suggests we are supposed to do. Instead, we should look at how stateless CoAP really can be made -- I = think even TFTP has too much state (and thus isn't as trivial a file = transfer protocol as it could be). Gruesse, Carsten From Michael.Stuber@itron.com Mon May 17 15:30:24 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 354F33A6927 for ; Mon, 17 May 2010 15:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_50=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9apSUeDn23hm for ; Mon, 17 May 2010 15:30:22 -0700 (PDT) Received: from mailer-1.itron.com (mailer-1.itron.com [198.182.8.123]) by core3.amsl.com (Postfix) with ESMTP id B13BE3A6405 for ; Mon, 17 May 2010 15:30:19 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 May 2010 15:30:11 -0700 Message-ID: <05C6A38D732F1144A8C4016BA4416BFE02D5A50F@SPO-EXVS-02.itron.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Core UDP vs TCP : Redux Thread-Index: Acr1zJc/bvdnn+5LQpypULdy1SC3ZQAA0P1wAAFHDkAADlYSQA== References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de><2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry><006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de><041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org><007c01caf5d3$30f026f0$92d074d0$@moritz@uni-rostock.de> From: "Stuber, Michael" To: "Charles Palmer" , "core" Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 22:30:24 -0000 Quoting: "I guess SE2.0 plans to use HTTP/EXI/TCP/IP because they exist and = work." They exist and work on PCs and some embedded devices. There are open = questions as to how effective they will be in an 802.15.4 context, = especially when packet size constraints, device constraints, and network = scale are factored in. (Note: I'm not suggesting that HTTP doesn't = work, I'm suggesting that a lighter-weight solution like CoAP is a = better choice given the limitations in these networks, especially as = they are required to scale up.) That is why some of us are very = interested in CoAP. HTTP/EXI/TCP/IP can be made smaller with effort. = CoAP should be small from the outset. =20 Regarding your question of not having a UDP reference, I would argue = that we should recognize that this effort is explicitly for constrained = devices. As such, we should design the protocol with UDP as the = transport. These remain IP networks. Folks that want a different = performance profile can choose to run additional or alternate protocols. = We should focus on simple and lightweight protocols for constrained = devices. We should ensure that CoAP works over UDP, and we should state = that it is our target transport. Implementers, as always, can choose to = run over other transports, but that should be outside of our scope. -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Charles Palmer Sent: Monday, May 17, 2010 8:48 AM To: core Subject: Re: [core] Core UDP vs TCP : Redux Hi folks Worth noting that the draft ZigBee Smart Energy 2.0 Application Protocol = Specification is very good about not mandating the transport layer = (although it talks extensively about TLS - does this limit it to TCP?) The SE2.0 spec also makes reference to possibly using CoRE (see quote = below). BTW how closely are we/should we be tracking SE2.0 work? I see = several names in both lists. I'd speculate that if CoRE is to be of use = to ZigBee Smart Energy then CoRE needs to provide an easy transition. How disruptive would it be to design CoRE without reference to TCP/UDP, = and also design a "reliable UDP" and use this for CoRE?=20 >From SE2.0: "6.1 Protocol Flexibility The Smart Energy Profile is designed to implement a RESTful = architecture. As such it is built around the core actions of GET, PUT, = POST, and DELETE (as used in [REST]), with the addition of a lightweight = subscription and notification mechanism, as discussed above in =A77. It = is not however, strictly limited to HTTP. Any protocol that can = implement the GET, PUT, POST, and DELETE command set can be used with = SEP 2.0. It is expected that HTTP is the preferred protocol for = interactions with the broader Internet, and that protocol translation = services are provided when it is desired to link an SEP system using = another application protocol with HTTP based solutions. The lightweight = RESTful Constrained Application Protocol (CoAP) is one such alternative = to HTTP [COAP]. This protocol should be proxied to HTTP for interactions = with the broader Internet, but may be applied end-to-end." Regards - Charles Palmer=20 -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Guido Moritz Sent: 17 May 2010 16:11 To: core@ietf.org Subject: Re: [core] Core UDP vs TCP : Redux > It may also be hard to meet this objective while inserting a=20 > subprotocol as complex as SOAP into the stack. I just went through the current COAP I-D and it is already quite = complex! It includes many mechanisms and concepts which are also = included in SOAP and other W3C/OASIS Web services specifications that I = am familiar in due to my background in DPWS.=20 Nevertheless, let's leave the discussion around SOAP, because there = seems to be many misunderstandings related to SOAP and what I wanted to = point at. What I wanted to say is (and that is my still my opinion after reading = current COAP I-D): there is no reason to bind COAP to UDP or TCP = exclusively or exclude one of them. COAP seems to describe many = mechanisms for interaction with resources, eventing and discovery = mechanisms, mechanisms to avoid duplicated message processing etc. But = all these mechanisms do not depend on the transport layer. Why should a = node not support interactions by using TCP or UDP at the same time for = the same resource. Of course, not the highly resource constrained one, = but we are heading towards heterogeneous device infrastructures where = resource richer devices in the same network might be possible as well. Take the ideas or throw them away. But these are major decisions = concerning applicability of the resulting COAP. What made HTTP and REST = in the WWW such a success was that it is possible to run it over all = kinds of technologies and not to restrict it to specific message sizes. = Let's say there is a cool new wireless technology IEEE 802.15.XY which = is capable of running 6LoWPAN but with double of the frame size and data = rate at same energy costs. Will there be the next COAPXY for this new = link layer because suddenly there is double the bandwidth available? Again, Just my two cents ;) Guido > -----Urspr=FCngliche Nachricht----- > Von: Carsten Bormann [mailto:cabo@tzi.org] > Gesendet: Montag, 17. Mai 2010 16:24 > An: Guido Moritz > Cc: core@ietf.org > Betreff: Re: [core] Core UDP vs TCP : Redux >=20 > On May 17, 2010, at 15:58, Guido Moritz wrote: >=20 > > I just wanted to ask > > if it is reasonable to bind the CORE protocol to UDP,TCP or whatever = > > or if > > it is possible to leave this open and design CORE extensible and flexible > > enough. >=20 > It may be hard to meet the working group's objective of addressing constrained > node/networks while leaving the underlying protocol(s) open. It may=20 > also be > hard to meet this objective while inserting a subprotocol as complex=20 > as SOAP > into the stack. >=20 > Gruesse, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core -------------------------------- Onzo is a limited company number 06097997 registered in England & Wales. = The =20 registered office is 6 Great Newport Street, London, WC2H 7JB, United = Kingdom. This email message may contain confidential and/or privileged = information, and is intended solely for the addressee(s). If you have received this email = in =20 error, please notify Onzo immediately. Unauthorised copying, disclosure = or distribution of the material in this email is forbidden. -------------------------------- _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From gc355804@ohio.edu Mon May 17 15:53:12 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9703E3A6AF2 for ; Mon, 17 May 2010 15:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESQsULEQZPdm for ; Mon, 17 May 2010 15:53:11 -0700 (PDT) Received: from mx2.oit.ohio.edu (mx2.oit.ohio.edu [132.235.51.19]) by core3.amsl.com (Postfix) with ESMTP id C28B43A6AA8 for ; Mon, 17 May 2010 15:53:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQFAOdl8UuE6wiX/2dsb2JhbACRdoxztF+IXoUQBA X-IronPort-AV: E=Sophos;i="4.53,249,1272859200"; d="scan'208";a="42347612" Received: from oak3a.cats.ohiou.edu (HELO oak.cats.ohiou.edu) ([132.235.8.151]) by smtpout2.oit.ohio.edu with ESMTP; 17 May 2010 18:53:03 -0400 Received: from [10.1.42.116] (cpe-184-57-77-118.columbus.res.rr.com [184.57.77.118]) (authenticated bits=0) by oak.cats.ohiou.edu (8.13.1/8.13.1) with ESMTP id o4HMpG4C1630135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 17 May 2010 18:51:17 -0400 (EDT) Message-ID: <4BF1C85E.8090309@ohio.edu> Date: Mon, 17 May 2010 18:51:10 -0400 From: Gilbert Clark User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: core@ietf.org References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de><2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry><006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de><041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org> <007c01caf5d3$30f026f0$92d074d0$@moritz@uni-rostock.de> <3C20B7FD-CB93-43CC-83D2-3F4209CC5B84@tzi.org> In-Reply-To: <3C20B7FD-CB93-43CC-83D2-3F4209CC5B84@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 22:53:12 -0000 On 5/17/2010 12:58 PM, Carsten Bormann wrote: > On May 17, 2010, at 17:47, Charles Palmer wrote: > > >> How disruptive would it be to design CoRE without reference to TCP/UDP, and also design a "reliable UDP" and use this for CoRE? >> > I personally think CoAP needs to work with DTLS; if the WG moves in that direction there will be some minimum requirement for independence from the underlying protocol. > > Apologies in advance if I missed it, but has DCCP been considered? I know that it works with DTLS in theory (RFC 5238). Further, from the DCCP RFC (4340): "One DCCP design goal was to give most streaming UDP applications little reason not to switch to DCCP, once it is deployed. To facilitate this, DCCP was designed to have as little overhead as possible, both in terms of the packet header size and in terms of the state and CPU overhead required at end hosts." Also, assuming that TCP is not included in the final version(s) of the draft, would it be worthwhile to include a note in the RFC stating that running CoAP over TCP is not recommended? Best, Gilbert Clark Grad Student From Michael.Stuber@itron.com Mon May 17 15:58:52 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 229453A6B33 for ; Mon, 17 May 2010 15:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.054 X-Spam-Level: X-Spam-Status: No, score=-1.054 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCkv9NO+4uCz for ; Mon, 17 May 2010 15:58:51 -0700 (PDT) Received: from mailer-1.itron.com (mailer-1.itron.com [198.182.8.123]) by core3.amsl.com (Postfix) with ESMTP id 036293A6B31 for ; Mon, 17 May 2010 15:58:49 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 May 2010 15:58:41 -0700 Message-ID: <05C6A38D732F1144A8C4016BA4416BFE02D5A531@SPO-EXVS-02.itron.com> In-Reply-To: <3C20B7FD-CB93-43CC-83D2-3F4209CC5B84@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Core UDP vs TCP : Redux Thread-Index: Acr14kMw25NWzy2ZSNKbKahuoQEUIgAMaQzA References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de><2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry><006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de><041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org><007c01caf5d3$30f026f0$92d074d0$@moritz@uni-rostock.de> <3C20B7FD-CB93-43CC-83D2-3F4209CC5B84@tzi.org> From: "Stuber, Michael" To: "Carsten Bormann" , "Charles Palmer" Cc: core Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2010 22:58:52 -0000 -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann > I personally think CoAP needs to work with DTLS; if the WG moves in that direction there will be some minimum requirement for independence from the underlying protocol. We should look at this closely. If you examine DTLS -- and I admit I am NOT a TLS or DTLS expert -- it appears to simply be TLS over UDP. If I have read it correctly, it still creates and maintains a logical session, even if there is no session provided by the transport layer. I think we need to examine this closely before we choose to adopt it as our security mechanism. Note: I am not saying we should be incompatible with DTLS, I am simply saying that DTLS may not be the best choice for a native security mechanism for CoAP. From hgs@cs.columbia.edu Mon May 17 19:05:18 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30B6F3A688F for ; Mon, 17 May 2010 19:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGQLA8wlQu+L for ; Mon, 17 May 2010 19:05:17 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 68AC83A6853 for ; Mon, 17 May 2010 19:05:14 -0700 (PDT) Received: from new-host-3.home (pool-173-54-225-147.nwrknj.fios.verizon.net [173.54.225.147]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o4I255G9027264 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 17 May 2010 22:05:05 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <4BF1C85E.8090309@ohio.edu> Date: Mon, 17 May 2010 22:05:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de><2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry><006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de><041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org> <007c01caf5d3$30f026f0$92d074d0$@moritz@uni-rostock.de> <3C20B7FD-CB93-43CC-83D2-3F4209CC5B84@tzi.org> <4BF1C85E.8090309@ohio.edu> To: Gilbert Clark X-Mailer: Apple Mail (2.1078) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Cc: core@ietf.org Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 02:05:18 -0000 DCCP provides congestion control, but no reliability, and is designed, = as you quote below, for "streaming applications", such as audio and = video. This seems like a poor match to the needs of this application = domain. Henning On May 17, 2010, at 6:51 PM, Gilbert Clark wrote: > On 5/17/2010 12:58 PM, Carsten Bormann wrote: >> On May 17, 2010, at 17:47, Charles Palmer wrote: >>=20 >> =20 >>> How disruptive would it be to design CoRE without reference to = TCP/UDP, and also design a "reliable UDP" and use this for CoRE? >>> =20 >> I personally think CoAP needs to work with DTLS; if the WG moves in = that direction there will be some minimum requirement for independence = from the underlying protocol. >>=20 >> =20 >=20 > Apologies in advance if I missed it, but has DCCP been considered? >=20 > I know that it works with DTLS in theory (RFC 5238). Further, from = the DCCP RFC (4340): >=20 > "One DCCP design goal was to give most streaming UDP applications = little reason not to switch to DCCP, once it is deployed. To facilitate = this, DCCP was designed to have as little overhead as possible, both in = terms of the packet header size and in terms of the state and CPU = overhead required at end hosts." >=20 > Also, assuming that TCP is not included in the final version(s) of the = draft, would it be worthwhile to include a note in the RFC stating that = running CoAP over TCP is not recommended? >=20 > Best, > Gilbert Clark > Grad Student >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 From gc355804@ohio.edu Mon May 17 19:33:39 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 791153A688F for ; Mon, 17 May 2010 19:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ke+ruCYLh8sm for ; Mon, 17 May 2010 19:33:38 -0700 (PDT) Received: from mx2.oit.ohio.edu (mx2.oit.ohio.edu [132.235.51.19]) by core3.amsl.com (Postfix) with ESMTP id 3C84228C1AD for ; Mon, 17 May 2010 19:28:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAEqY8UuE6wiX/2dsb2JhbACea7JRiF6FEASPPA X-IronPort-AV: E=Sophos;i="4.53,251,1272859200"; d="scan'208";a="42361678" Received: from oak3a.cats.ohiou.edu (HELO oak.cats.ohiou.edu) ([132.235.8.151]) by smtpout2.oit.ohio.edu with ESMTP; 17 May 2010 22:28:05 -0400 Received: from [10.1.42.116] (cpe-184-57-77-118.columbus.res.rr.com [184.57.77.118]) (authenticated bits=0) by oak.cats.ohiou.edu (8.13.1/8.13.1) with ESMTP id o4I2RNRm1785299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 May 2010 22:27:39 -0400 (EDT) Message-ID: <4BF1FB04.2040403@ohio.edu> Date: Mon, 17 May 2010 22:27:16 -0400 From: Gilbert Clark User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Henning Schulzrinne References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de><2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry><006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de><041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org> <007c01caf5d3$30f026f0$92d074d0$@moritz@uni-rostock.de> <3C20B7FD-CB93-43CC-83D2-3F4209CC5B84@tzi.org> <4BF1C85E.8090309@ohio.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core@ietf.org Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 02:33:39 -0000 Point; only connection setup / teardown is reliable, so that doesn't really help. That was probably not the best suggestion :) --Gilbert On 5/17/2010 10:05 PM, Henning Schulzrinne wrote: > DCCP provides congestion control, but no reliability, and is designed, as you quote below, for "streaming applications", such as audio and video. This seems like a poor match to the needs of this application domain. > > Henning > > On May 17, 2010, at 6:51 PM, Gilbert Clark wrote: > > >> On 5/17/2010 12:58 PM, Carsten Bormann wrote: >> >>> On May 17, 2010, at 17:47, Charles Palmer wrote: >>> >>> >>> >>>> How disruptive would it be to design CoRE without reference to TCP/UDP, and also design a "reliable UDP" and use this for CoRE? >>>> >>>> >>> I personally think CoAP needs to work with DTLS; if the WG moves in that direction there will be some minimum requirement for independence from the underlying protocol. >>> >>> >>> >> Apologies in advance if I missed it, but has DCCP been considered? >> >> I know that it works with DTLS in theory (RFC 5238). Further, from the DCCP RFC (4340): >> >> "One DCCP design goal was to give most streaming UDP applications little reason not to switch to DCCP, once it is deployed. To facilitate this, DCCP was designed to have as little overhead as possible, both in terms of the packet header size and in terms of the state and CPU overhead required at end hosts." >> >> Also, assuming that TCP is not included in the final version(s) of the draft, would it be worthwhile to include a note in the RFC stating that running CoAP over TCP is not recommended? >> >> Best, >> Gilbert Clark >> Grad Student >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> > From L.Wood@surrey.ac.uk Mon May 17 21:40:08 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ED873A672E for ; Mon, 17 May 2010 21:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.669 X-Spam-Level: X-Spam-Status: No, score=-4.669 tagged_above=-999 required=5 tests=[AWL=-0.670, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDMqQQVUI47E for ; Mon, 17 May 2010 21:40:06 -0700 (PDT) Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with ESMTP id 080493A6BE7 for ; Mon, 17 May 2010 21:40:01 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-15.tower-82.messagelabs.com!1274157592!6520235!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.31] Received: (qmail 1519 invoked from network); 18 May 2010 04:39:52 -0000 Received: from unknown (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-15.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 18 May 2010 04:39:52 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.69]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Tue, 18 May 2010 05:39:52 +0100 From: To: , Date: Tue, 18 May 2010 05:39:51 +0100 Thread-Topic: [core] Core UDP vs TCP : Redux Thread-Index: Acr2E7hILkvhUx9FQXysZ8UHcrqMhAAL+ERg Message-ID: References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de><2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry><006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de><041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org> <007c01caf5d3$30f026f0$92d074d0$@moritz@uni-rostock.de> <3C20B7FD-CB93-43CC-83D2-3F4209CC5B84@tzi.org> <4BF1C85E.8090309@ohio.edu> In-Reply-To: <4BF1C85E.8090309@ohio.edu> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 04:40:08 -0000 That quote from RFC4340 is optimistic. DCCP has not been deployed in any si= gnificant amount. The remaining outstanding action in the DCCP WG, being debated, is to imple= ment an efficient DCCP-over-UDP tunnel to get through NAT and firewalls and= encourage DCCP adoption. Not being UDP is sufficient reason not to switch.= .. -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Gil= bert Clark Sent: 17 May 2010 23:51 To: core@ietf.org Subject: Re: [core] Core UDP vs TCP : Redux On 5/17/2010 12:58 PM, Carsten Bormann wrote: > On May 17, 2010, at 17:47, Charles Palmer wrote: > > =20 >> How disruptive would it be to design CoRE without reference to TCP/UDP, = and also design a "reliable UDP" and use this for CoRE? >> =20 > I personally think CoAP needs to work with DTLS; if the WG moves in that = direction there will be some minimum requirement for independence from the = underlying protocol. > > =20 Apologies in advance if I missed it, but has DCCP been considered? I know that it works with DTLS in theory (RFC 5238). Further, from the DCC= P RFC (4340): "One DCCP design goal was to give most streaming UDP applications little re= ason not to switch to DCCP, once it is deployed. To facilitate this, DCCP = was designed to have as little overhead as possible, both in terms of the p= acket header size and in terms of the state and CPU overhead required at en= d hosts." Also, assuming that TCP is not included in the final version(s) of the draf= t, would it be worthwhile to include a note in the RFC stating that running= CoAP over TCP is not recommended? Best, Gilbert Clark Grad Student _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From robert.cragie@gridmerge.com Mon May 17 22:42:45 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E7B43A67EC for ; Mon, 17 May 2010 22:42:45 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwlJmiJQg3k4 for ; Mon, 17 May 2010 22:42:43 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 002A53A6BDD for ; Mon, 17 May 2010 22:42:41 -0700 (PDT) Received: from 216-75-227-18.static.wiline.com ([216.75.227.18] helo=[192.168.5.111]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1OEFZK-0002Rf-Mm; Tue, 18 May 2010 06:42:19 +0100 Message-ID: <4BF228B7.8050000@gridmerge.com> Date: Tue, 18 May 2010 06:42:15 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Stuber, Michael" References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de><2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry><006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de><041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org><007c01caf5d3$30f026f0$92d074d0$@moritz@uni-rostock.de> <3C20B7FD-CB93-43CC-83D2-3F4209CC5B84@tzi.org> <05C6A38D732F1144A8C4016BA4416BFE02D5A531@SPO-EXVS-02.itron.com> In-Reply-To: <05C6A38D732F1144A8C4016BA4416BFE02D5A531@SPO-EXVS-02.itron.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040702060105030202050204" Cc: core Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 05:42:45 -0000 This is a cryptographically signed message in MIME format. --------------ms040702060105030202050204 Content-Type: multipart/alternative; boundary="------------020500030208080801080804" This is a multi-part message in MIME format. --------------020500030208080801080804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Michael, I think you have to have some notion of session between a pairwise=20 secure association even if it's as basic as maintaining a nonce=20 associated with a shared key to ensure non-repeatability for stream ciphe= rs. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 17/05/2010 11:58 PM, Stuber, Michael wrote: > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of= > Carsten Bormann > > =20 >> I personally think CoAP needs to work with DTLS; if the WG moves in >> =20 > that direction there will be some minimum requirement for independence > from the underlying protocol. > > We should look at this closely. If you examine DTLS -- and I admit I a= m > NOT a TLS or DTLS expert -- it appears to simply be TLS over UDP. If I= > have read it correctly, it still creates and maintains a logical > session, even if there is no session provided by the transport layer. = I > think we need to examine this closely before we choose to adopt it as > our security mechanism. > > Note: I am not saying we should be incompatible with DTLS, I am simply= > saying that DTLS may not be the best choice for a native security > mechanism for CoAP. > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > =20 --------------020500030208080801080804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Michael,

I think you have to have some notion of session between a pairwise secure association even if it's as basic as maintaining a nonce associated with a shared key to ensure non-repeatability for stream ciphers.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com


On 17/05/2010 11:58 PM, Stuber, Michael wrote: 
-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On =
Behalf Of
Carsten Bormann

  
I personally think CoAP needs to work with DTLS; if th=
e WG moves in
    
that direction there will be some minimum requirement fo=
r independence
from the underlying protocol.

We should look at this closely.  If you examine DTLS -- and I admit I am
NOT a TLS or DTLS expert -- it appears to simply be TLS over UDP.  If I
have read it correctly, it still creates and maintains a logical
session, even if there is no session provided by the transport layer.  I
think we need to examine this closely before we choose to adopt it as
our security mechanism.

Note:  I am not saying we should be incompatible with DTLS, I am simply
saying that DTLS may not be the best choice for a native security
mechanism for CoAP.
_______________________________________________
core mailing list
core@=
ietf.org
https://www.ietf.org/mailman/listinfo/core
--------------020500030208080801080804-- --------------ms040702060105030202050204 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA1 MTgwNTQyMTVaMCMGCSqGSIb3DQEJBDEWBBS8hERJGdGBr9lEqtDgLDQaIs1CpjBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAC1IeDs2y/ySx2VxrIb08ctK0+1d+2NEJECNeS6+Tj9MG+oFnOvlrSXVEcCqBlCxrp+C TNH2rpYRwF76EmeBHG/ldOteOcDbTVoMl/kU1dJBF2T+wgDzJRnr3mGFWObcIMawbl34y/fL lyRjnLW1sWF2zWsv2MAFQlGUBx4ZCg0U2qOif9wfAqcPnUWbgtfuGjsLdqq/EkTKnS33diq5 p8Pu/8F21rWD5jD0UBBiOv7Sw46pHybhoGk7EaQpcJjSYRqxOzQm4bY6glGMS8zHarnEPrZg BiDKnCcPuhNc6qWDRu6iqS82OcVZ9PrlHG1yvEJrMCn72HruCqV8VbflWGcAAAAAAAA= --------------ms040702060105030202050204-- From robert.cragie@gridmerge.com Mon May 17 22:49:53 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67B673A6BD8 for ; Mon, 17 May 2010 22:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AixrmNrUZgp for ; Mon, 17 May 2010 22:49:50 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 09EA83A6882 for ; Mon, 17 May 2010 22:49:50 -0700 (PDT) Received: from 216-75-227-18.static.wiline.com ([216.75.227.18] helo=[192.168.5.111]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1OEFgS-0005ua-UE for core@ietf.org; Tue, 18 May 2010 06:49:41 +0100 Message-ID: <4BF22A72.9050803@gridmerge.com> Date: Tue, 18 May 2010 06:49:38 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: core@ietf.org References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de> <2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry> <006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de> In-Reply-To: <006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040605050308050405030702" Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 05:49:53 -0000 This is a cryptographically signed message in MIME format. --------------ms040605050308050405030702 Content-Type: multipart/alternative; boundary="------------080202040101040103090303" This is a multi-part message in MIME format. --------------080202040101040103090303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Of course SOAP can be bound to almost anything as it basically uses=20 whatever it is bound to as a simple transport mechanism, e.g. let's just = use HTTP POST for everything. But that's not the point of using a=20 RESTful architecture. What's more important to consider is the=20 transactional model. HTTP generally has some restrictions as a=20 synchronous request/response protocol and the web model has unwittingly=20 made further restrictions on the client/server and threading models.=20 Whatever CoAP ends up being should be less restrictive on its=20 transactional model so it can potentially map to any underlying protocol.= Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 17/05/2010 2:58 PM, Guido Moritz wrote: > Don > > REST (apples) is an architectural style, SOAP (oranges) is a protocol, = hard > to compare apples and oranges. BTW, it is possible to use SOAP for a RE= STful > design also. See WS-RA for example: > http://www.w3.org/2008/08/ws/charter.html > > But I didn't want to go to deep into this discussion. I just wanted to = ask > if it is reasonable to bind the CORE protocol to UDP,TCP or whatever or= if > it is possible to leave this open and design CORE extensible and flexib= le > enough. This is anyway not related to REST, SOA or any other architectu= re, > just a question of protocol design. > > Guido > > =20 >> -----Urspr=FCngliche Nachricht----- >> Von:d.sturek@att.net [mailto:d.sturek@att.net] >> Gesendet: Montag, 17. Mai 2010 14:41 >> An: Guido Moritz;core-bounces@ietf.org;core@ietf.org >> Betreff: Re: [core] Core UDP vs TCP : Redux >> >> Hi guido, >> >> I think the thing is this is not soap but rest. It is fine to create >> =20 > mappings > =20 >> but not to change the design goal of using rest. >> >> Don >> Sent via BlackBerry from T-Mobile >> >> -----Original Message----- >> From: Guido Moritz >> Date: Mon, 17 May 2010 08:53:21 >> To: >> Subject: Re: [core] Core UDP vs TCP : Redux >> >> For example there is a SOAP-over-UDP binding defined at OASIS >> http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=3Dws-dd >> The intention is to carry UDP multicast and unicast discovery messages= =2E >> >> See also SOAP over SMTPhttp://www.pocketsoap.com/specs/smtpbinding/ >> >> However, what is interesting to be agnostic of the transport protocol = and >> define dependencies in such bindings and not in the protocol itself. >> >> Guido >> >> >> =20 >>> -----Urspr=FCngliche Nachricht----- >>> Von:L.Wood@surrey.ac.uk [mailto:L.Wood@surrey.ac.uk] >>> Gesendet: Mittwoch, 12. Mai 2010 16:28 >>> An: Guido Moritz;core@ietf.org >>> Betreff: RE: [core] Core UDP vs TCP : Redux >>> >>> HTTP doesn't_have_ to run over TCP: >>> http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery-05 >>> and decoupling HTTP from TCP would be a very good idea, as >>> =20 > implementation > =20 >> work >> =20 >>> to do so (e.g. HTTP over SCTP) is ongoing: >>> >>> =20 >> =20 > http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/talks.html= #http > =20 >> - >> =20 >>> standalone >>> >>> The only SOAP binding I can find is that to HTTP: >>> http://www.w3.org/TR/soap12-part2/#soapinhttp >>> http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#transpbindframew= >>> >>> which does place SOAP binding firmly at 'concept' stage - one example= to >>> =20 >> claim >> =20 >>> that an entire range of possibilities exist and are implementable. >>> >>> Another example of this 'concept' is BEEP's transport profiles, for >>> =20 > which > =20 >> only >> =20 >>> a mapping to TCP is actually defined. Because nobody uses BEEP. >>> >>> L. >>> >>> -----Original Message----- >>> From:core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of >>> =20 >> Guido >> =20 >>> Moritz >>> Sent: 12 May 2010 14:54 >>> To:core@ietf.org >>> Subject: Re: [core] Core UDP vs TCP : Redux >>> >>> Sorry, but I would not agree to say 'when you are able to use TCP, yo= u >>> =20 > are > =20 >>> also able to use HTTP'. We made several measurements with UDP vs. TCP= >>> =20 > and > =20 >> of >> =20 >>> course, connection setup takes longer for TCP. But a typical HTTP hea= der >>> =20 >> has a >> =20 >>> size>100 Byte (without any payload). Thus the connection setup overhe= ad >>> =20 >> is >> =20 >>> compensated due to large payload/headers itself. There might be >>> =20 >> application >> =20 >>> scenarios where the designer wants to have reliable communication, bu= t >>> =20 >> still >> =20 >>> have small payload. >>> >>> I did not have read through the current core I-D extensively, but is = it >>> necessary to go so much into detail why to use UDP or TCP and how it >>> =20 >> should be >> =20 >>> used? It might be reasonable to define a reliability (and maybe also >>> fragmentation) extension to UDP and define UDP as the defualt, but wh= y >>> =20 >> should >> =20 >>> TCP be forbidden at all? >>> >>> One may argue about SOAP Web services in several points, but their >>> =20 > binding > =20 >>> concept is quite nice. SOAP can be bound to which transport mechanism= >>> =20 >> ever. >> =20 >>> This makes it applicable it different scenarios and the transport >>> mechanisms/protocol can be changed without an effect on application >>> =20 >> itself. >> =20 >>> Just my two cents, >>> Guido >>> >>> =20 >>>> -----Urspr=FCngliche Nachricht----- >>>> Von:core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag= >>>> von >>>> =20 >>> Zach >>> =20 >>>> Shelby >>>> Gesendet: Dienstag, 11. Mai 2010 23:07 >>>> An: Thomas Herbst >>>> Cc:core@ietf.org >>>> Betreff: Re: [core] Core UDP vs TCP : Redux >>>> >>>> +1 >>>> >>>> Through writing a few revisions of these specs, I have also already >>>> found >>>> =20 >>> TCP >>> =20 >>>> to be really awkward. And the TCP negotiation discussions at the mik= e >>>> in Anaheim made me even more skeptical. Tom is right, if you need TC= P >>>> then >>>> =20 >>> just >>> =20 >>>> use HTTP ;-) >>>> >>>> Zach >>>> >>>> On May 11, 2010, at 18:49 , Thomas Herbst wrote: >>>> >>>> =20 >>>>> After the discussion in Anaheim, I'm surprised that we need yet >>>>> another >>>>> =20 >>>> revisit to UDP and TCP for CORE. >>>> =20 >>>>> The Right Solution(tm) might well be to fix TCP such that it doesn'= t >>>>> =20 >>> lose >>> =20 >>>> its brains every time you drop a packet, and we could end up with an= >>>> =20 >>> end-to- >>> =20 >>>> end system where constrained devices might reasonably provide servic= es >>>> to normal hosts in the regular Internet, However, transport work is= >>>> out of >>>> =20 >>> scope >>> =20 >>>> for this WG. >>>> =20 >>>>> The second most right solution would be to implement CORE with a >>>>> =20 >>> reliable >>> =20 >>>> UDP protocol, as is done in much of the draft. The "optional" TCP >>>> =20 >>> portions of >>> =20 >>>> the draft are mostly increased complexity for no added benefit. If a= >>>> =20 >>> device is >>> =20 >>>> capable of running TCP and the network it works on is capable of >>>> =20 >>> supporting >>> =20 >>>> TCP, you should just open a connection to Port 80 and use HTTP (or t= he >>>> TCP port/protocol of your choice). There are many protocols a host >>>> MAY >>>> =20 >>> implement >>> =20 >>>> and it is not appropriate for the draft to enumerate them. >>>> =20 >>>>> Let's remove all of the sections related to TCP in the draft. >>>>> >>>>> tom >>>>> >>>>> =20 >>>> -- >>>> Zach Shelby, Head of Research, Sensinode Ltd. >>>> http://zachshelby.org - My blog "On the Internet of Things" >>>> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Interne= t" >>>> Mobile: +358 40 7796297 >>>> =20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> =20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > =20 --------------080202040101040103090303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Of course SOAP can be bound to almost anything as it basically uses whatever it is bound to as a simple transport mechanism, e.g. let's just use HTTP POST for everything. But that's not the point of using a RESTful architecture. What's more important to consider is the transactional model. HTTP generally has some restrictions as a synchronous request/response protocol and the web model has unwittingly made further restrictions on the client/server and threading models. Whatever CoAP ends up being should be less restrictive on its transactional model so it can potentially map to any underlying protocol.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com


On 17/05/2010 2:58 PM, Guido Moritz wrote: 
Don

REST (apples) is an architectural style, SOAP (oranges) is a protocol, ha=
rd
to compare apples and oranges. BTW, it is possible to use SOAP for a REST=
ful
design also. See WS-RA for example:
http://www.w3.org/200=
8/08/ws/charter.html=20

But I didn't want to go to deep into this discussion. I just wanted to as=
k
if it is reasonable to bind the CORE protocol to UDP,TCP or whatever or i=
f
it is possible to leave this open and design CORE extensible and flexible=

enough. This is anyway not related to REST, SOA or any other architecture=
,
just a question of protocol design.

Guido

  
-----Ursprüngliche Nachricht-----
Von: d.sturek@att.net [mailto:=
d.sturek@att.net]
Gesendet: Montag, 17. Mai 2010 14:41
An: Guido Moritz; core-bounces@ietf.org; core@ie=
tf.org
Betreff: Re: [core] Core UDP vs TCP : Redux

Hi guido,

I think the thing is this is not soap but rest.  It is fine to create
    
mappings
  
but not to change the design goal of using rest.

Don
Sent via BlackBerry from T-Mobile

-----Original Message-----
From: Guido Moritz <guido.moritz@uni-rostock=
=2Ede>
Date: Mon, 17 May 2010 08:53:21
To: <=
core@ietf.org>
Subject: Re: [core] Core UDP vs TCP : Redux

For example there is a SOAP-over-UDP binding defined at OASIS
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=3Dws-dd
The intention is to carry UDP multicast and unicast discovery messages.

See also SOAP over SMTP http://www.pockets=
oap.com/specs/smtpbinding/

However, what is interesting to be agnostic of the transport protocol and=

define dependencies in such bindings and not in the protocol itself.

Guido


    
-----Ursprüngliche Nachricht-----
Von: L.Wood@surrey.ac.uk [mail=
to:L.Wood@surrey.ac.uk]
Gesendet: Mittwoch, 12. Mai 2010 16:28
An: Guido Moritz; core@ietf.org
Betreff: RE: [core] Core UDP vs TCP : Redux

HTTP doesn't_have_ to run over TCP:
http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery-05
and decoupling HTTP from TCP would be a very good idea, as
      
implementation
  
work
    
to do so (e.g. HTTP over SCTP) is ongoing:

      
    
http://personal.ee.surrey.ac.uk/Personal/L.Wood/publication=
s/talks.html#http
  
-
    
standalone

The only SOAP binding I can find is that to HTTP:
http://www.w3.org=
/TR/soap12-part2/#soapinhttp
http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#transpbindfra=
mew

which does place SOAP binding firmly at 'concept' stage - one example to
      
claim
    
that an entire range of possibilities exist and are =
implementable.

Another example of this 'concept' is BEEP's transport profiles, for
      
which
  
only
    
a mapping to TCP is actually defined. Because nobody=
 uses BEEP.

L.

-----Original Message-----
From: core-bounces@ietf.org [ma=
ilto:core-bounces@ietf.org] On Behalf Of
      
Guido
    
Moritz
Sent: 12 May 2010 14:54
To: c=
ore@ietf.org
Subject: Re: [core] Core UDP vs TCP : Redux

Sorry, but I would not agree to say 'when you are able to use TCP, you
      
are
  
also able to use HTTP'. We made several measurements=
 with UDP vs. TCP
      
and
  
of
    
course, connection setup takes longer for TCP. But a=
 typical HTTP header
      
has a
    
size >100 Byte (without any payload). Thus the co=
nnection setup overhead
      
is
    
compensated due to large payload/headers itself. The=
re might be
      
application
    
scenarios where the designer wants to have reliable =
communication, but
      
still
    
have small payload.

I did not have read through the current core I-D extensively, but is it
necessary to go so much into detail why to use UDP or TCP and how it
      
should be
    
used? It might be reasonable to define a reliability=
 (and maybe also
fragmentation) extension to UDP and define UDP as the defualt, but why
      
should
    
TCP be forbidden at all?

One may argue about SOAP Web services in several points, but their
      
binding
  
concept is quite nice. SOAP can be bound to which tr=
ansport mechanism
      
ever.
    
This makes it applicable it different scenarios and =
the transport
mechanisms/protocol can be changed without an effect on application
      
itself.
    
Just my two cents,
Guido

      
-----Ursprüngliche Nachricht-----
Von: core-bounces@ietf.org [ma=
ilto:core-bounces@ietf.org] Im Auftrag
von
        
Zach
      
Shelby
Gesendet: Dienstag, 11. Mai 2010 23:07
An: Thomas Herbst
Cc: c=
ore@ietf.org
Betreff: Re: [core] Core UDP vs TCP : Redux

+1

Through writing a few revisions of these specs, I have also already
found
        
TCP
      
to be really awkward. And the TCP negotiation disc=
ussions at the mike
in Anaheim made me even more skeptical. Tom is right, if you need TCP
then
        
just
      
use HTTP ;-)

Zach

On May 11, 2010, at 18:49 , Thomas Herbst wrote:

        
After the discussion in Anaheim, I'm surprised t=
hat we need yet
another
          
revisit to UDP and TCP for CORE.
        
The Right Solution(tm) might well be to fix TCP =
such that it doesn't
          
lose
      
its brains every time you drop a packet, and we co=
uld end up with an
        
end-to-
      
end system where constrained devices might reasona=
bly provide services
to normal hosts in the regular Internet,  However, transport work is
out of
        
scope
      
for this WG.
        
The second most right solution would be to imple=
ment CORE with a
          
reliable
      
UDP protocol, as is done in much of the draft.  Th=
e "optional" TCP
        
portions of
      
the draft are mostly increased complexity for no a=
dded benefit. If a
        
device is
      
capable of running TCP and the network it works on=
 is capable of
        
supporting
      
TCP, you should just open a connection to Port 80 =
and use HTTP (or the
TCP port/protocol of your choice).  There are many protocols a host
MAY
        
implement
      
and it is not appropriate for the draft to enumera=
te them.
        
Let's remove all of the sections related to TCP =
in the draft.

tom

          
--
Zach Shelby, Head of Research, Sensinode Ltd.
http://=
zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet=
"
Mobile: +358 40 7796297
        
_______________________________________________
core mailing list
core@=
ietf.org
https://www.ietf.org=
/mailman/listinfo/core
    
_______________________________________________
core mailing list
core@=
ietf.org
https://www.ietf.org=
/mailman/listinfo/core
--------------080202040101040103090303-- --------------ms040605050308050405030702 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA1 MTgwNTQ5MzhaMCMGCSqGSIb3DQEJBDEWBBTSCCeLq3pHAxj6eRu/wYvN8zo/WDBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAKX1F15UaXbTeXdO/XGwPjswL5ERqo6pysTulv7L/VIPL5at5TH6uq3VjO+ts21roatT 9ATM5514v9jKpOMVeNakyJyhwvmlbAqn8V7CsqFgK7KOfxIk2nsCEmJDBr5WtSLcBOCcAqyF QJh0tyM0pmHCM44xgtEUZhdM8K16HvKkJrvfWnJTaqqHZx1RFy7Bc7Gy7FiBdu7KpHJwVeq8 NPfg52dARTaIzFSdbJEkJqN+jVRoNr/jRS8SxCGl22N/pWx/i3zvKCaSZggFZHjF5azUoRY0 JHlPJJqBhpRDsRIc/CBVurKZxMf5CnPu+AuEZIJvKnVmraIGTkDcnqZlTXEAAAAAAAA= --------------ms040605050308050405030702-- From guido.moritz@uni-rostock.de Tue May 18 01:31:57 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7531128C17E for ; Tue, 18 May 2010 01:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_32=0.6, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1wTk6DItbQY for ; Tue, 18 May 2010 01:31:48 -0700 (PDT) Received: from ida.uni-rostock.de (ida.uni-rostock.de [139.30.8.34]) by core3.amsl.com (Postfix) with ESMTP id A6FF03A68A8 for ; Tue, 18 May 2010 01:27:57 -0700 (PDT) Received: from email1.uni-rostock.de (139.30.8.208) by ida.uni-rostock.de (139.30.8.162) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 18 May 2010 10:27:44 +0200 Received: from Schlappi (139.30.201.226) by email1.uni-rostock.de (139.30.8.210) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 18 May 2010 10:21:26 +0200 From: Guido Moritz To: References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de><2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry><006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de><041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org> <007c01caf5d3$30f026f0$92d074d0$@moritz@uni-rostock.de> <3C20B7FD-CB93-43CC-83D2-3F4209CC5B84@tzi.org> In-Reply-To: <3C20B7FD-CB93-43CC-83D2-3F4209CC5B84@tzi.org> Date: Tue, 18 May 2010 10:21:26 +0200 Message-ID: <002101caf663$1c251d30$546f5790$@moritz@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr14kyv39NSOyiHTBGOLspdW+HdUAAgMjPA Content-Language: de Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 08:31:57 -0000 >From the CORE charter: > 4) The core CoAP functionality MUST operate well over UDP and UDP = MUST > be implemented on CoAP Devices. There may be OPTIONAL functions in > CoAP (e.g. delivery of larger chunks of data) which if implemented = are > implemented over TCP. Applications which require the optional TCP > features will limit themselves to a narrower subset of deployment > cases. Running over TCP would narrow application scenarios? It would be more = than reasonable to design COAP while keeping UDP in mind. But as long as = there are no direct dependencies of COAP itself to the transport mechanisms, = don't restrict it. This in contrast would extend application scenarios, = because you can use COAP also if reliable transport layer is required in the scenario. Are there dependencies to UDP or is it only because the assumed infrastructure is highly constrained? Guido > -----Urspr=FCngliche Nachricht----- > Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag = von > Carsten Bormann > Gesendet: Montag, 17. Mai 2010 18:59 > An: Charles Palmer > Cc: core > Betreff: Re: [core] Core UDP vs TCP : Redux >=20 > On May 17, 2010, at 17:47, Charles Palmer wrote: >=20 > > How disruptive would it be to design CoRE without reference to = TCP/UDP, and > also design a "reliable UDP" and use this for CoRE? >=20 > I personally think CoAP needs to work with DTLS; if the WG moves in = that > direction there will be some minimum requirement for independence from = the > underlying protocol. >=20 > However, what we expect from the underlying protocol has a big bearing = on CoAP > itself. > If we expect we can always move to TCP, there will be little need to = make CoAP > operate on large representations with small underlying interactions. = I've > heard a lot of pushback on assuming the availability of TCP, so far. >=20 > There is also the aspect of interoperability: One of the great = properties of > the Web is that everybody uses the same stack, so all Web clients and servers > are interoperable, with IP providing the necessary technological diversity. > (On the other hand, this has made it near impossible to swap in, say, SCTP.) > Just standardizing CoAP without an "we expect this to run on UDP, = unless > otherwise specified" would not achieve the same level of = interoperability. >=20 > In any case, designing a reliable transport as a TCP replacement > and then a CoAP on top of either that or TCP is very much not what the charter > suggests we are supposed to do. > Instead, we should look at how stateless CoAP really can be made -- I think > even TFTP has too much state (and thus isn't as trivial a file = transfer > protocol as it could be). >=20 > Gruesse, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From Colin.OFlynn@atmel.com Tue May 18 06:32:05 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AE2B3A6C27 for ; Tue, 18 May 2010 06:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.237 X-Spam-Level: X-Spam-Status: No, score=-0.237 tagged_above=-999 required=5 tests=[AWL=-0.839, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWGBRqmLHFxg for ; Tue, 18 May 2010 06:32:04 -0700 (PDT) Received: from sjogate2.atmel.com (newsmtp5.atmel.com [204.2.163.5]) by core3.amsl.com (Postfix) with ESMTP id 8E9C33A6C3D for ; Tue, 18 May 2010 06:28:51 -0700 (PDT) Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id o4IDQRZ3028979; Tue, 18 May 2010 06:26:27 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAF68D.FCE5E675" Date: Tue, 18 May 2010 07:23:42 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Core UDP vs TCP : Redux Thread-Index: Acr14kyv39NSOyiHTBGOLspdW+HdUAAgMjPAAAqQDGU= References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de><2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry><006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de><041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org> <007c01caf5d3$30f026f0$92d074d0$@moritz@uni-rostock.de> <3C20B7FD-CB93-43CC-83D2-3F4209CC5B84@tzi.org> <002101caf663$1c251d30$546f5790$@moritz@uni-rostock.de> From: "Oflynn, Colin" To: "Guido Moritz" , Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 13:32:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAF68D.FCE5E675 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Are there dependencies to UDP or is it only because the assumed > infrastructure is highly constrained? My thoughts/feeling on the issue is that CoAP should be designed with a = highly constrained environment, and as such being bound to UDP makes it = a lot simpler. The resources which CoAP accesses SHOULD be accessible another in = another manner; most likely this is HTTP over TCP. Even though CoAP does = not map directly to HTTP, the requests are the same and thus I don't see = an issue here. Nodes which are highly constrained may only support CoAP; = larger nodes can support the full HTTP method. Of course the whole subscription/notify method might take some changes = to make it accessible via HTTP... but thats another thread. -Colin -----Original Message----- From: core-bounces@ietf.org on behalf of Guido Moritz Sent: Tue 18/05/2010 09:21 To: core@ietf.org Subject: Re: [core] Core UDP vs TCP : Redux =20 >From the CORE charter: > 4) The core CoAP functionality MUST operate well over UDP and UDP = MUST > be implemented on CoAP Devices. There may be OPTIONAL functions in > CoAP (e.g. delivery of larger chunks of data) which if implemented = are > implemented over TCP. Applications which require the optional TCP > features will limit themselves to a narrower subset of deployment > cases. Running over TCP would narrow application scenarios? It would be more = than reasonable to design COAP while keeping UDP in mind. But as long as = there are no direct dependencies of COAP itself to the transport mechanisms, = don't restrict it. This in contrast would extend application scenarios, = because you can use COAP also if reliable transport layer is required in the scenario. Are there dependencies to UDP or is it only because the assumed infrastructure is highly constrained? Guido > -----Urspr=FCngliche Nachricht----- > Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag = von > Carsten Bormann > Gesendet: Montag, 17. Mai 2010 18:59 > An: Charles Palmer > Cc: core > Betreff: Re: [core] Core UDP vs TCP : Redux >=20 > On May 17, 2010, at 17:47, Charles Palmer wrote: >=20 > > How disruptive would it be to design CoRE without reference to = TCP/UDP, and > also design a "reliable UDP" and use this for CoRE? >=20 > I personally think CoAP needs to work with DTLS; if the WG moves in = that > direction there will be some minimum requirement for independence from = the > underlying protocol. >=20 > However, what we expect from the underlying protocol has a big bearing = on CoAP > itself. > If we expect we can always move to TCP, there will be little need to = make CoAP > operate on large representations with small underlying interactions. = I've > heard a lot of pushback on assuming the availability of TCP, so far. >=20 > There is also the aspect of interoperability: One of the great = properties of > the Web is that everybody uses the same stack, so all Web clients and servers > are interoperable, with IP providing the necessary technological diversity. > (On the other hand, this has made it near impossible to swap in, say, SCTP.) > Just standardizing CoAP without an "we expect this to run on UDP, = unless > otherwise specified" would not achieve the same level of = interoperability. >=20 > In any case, designing a reliable transport as a TCP replacement > and then a CoAP on top of either that or TCP is very much not what the charter > suggests we are supposed to do. > Instead, we should look at how stateless CoAP really can be made -- I think > even TFTP has too much state (and thus isn't as trivial a file = transfer > protocol as it could be). >=20 > Gruesse, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------_=_NextPart_001_01CAF68D.FCE5E675 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [core] Core UDP vs TCP : Redux

> Are there dependencies to UDP or is it only = because the assumed
> infrastructure is highly constrained?

My thoughts/feeling on the issue is that CoAP should be designed with a = highly constrained environment, and as such being bound to UDP makes it = a lot simpler.

The resources which CoAP accesses SHOULD be accessible another in = another manner; most likely this is HTTP over TCP. Even though CoAP does = not map directly to HTTP, the requests are the same and thus I don't see = an issue here. Nodes which are highly constrained may only support CoAP; = larger nodes can support the full HTTP method.

Of course the whole subscription/notify method might take some changes = to make it accessible via HTTP... but thats another thread.

  -Colin


-----Original Message-----
From: core-bounces@ietf.org on behalf of Guido Moritz
Sent: Tue 18/05/2010 09:21
To: core@ietf.org
Subject: Re: [core] Core UDP vs TCP : Redux

>From the CORE charter:
>  4) The core CoAP functionality MUST operate well over UDP and = UDP MUST
>  be implemented on CoAP Devices. There may be OPTIONAL = functions in
>  CoAP (e.g. delivery of larger chunks of data) which if = implemented are
>  implemented over TCP. Applications which require the optional = TCP
>  features will limit themselves to a narrower subset of = deployment
>  cases.

Running over TCP would narrow application scenarios? It would be more = than
reasonable to design COAP while keeping UDP in mind. But as long as = there
are no direct dependencies of COAP itself to the transport mechanisms, = don't
restrict it. This in contrast would extend application scenarios, = because
you can use COAP also if reliable transport layer is required in the
scenario.

Are there dependencies to UDP or is it only because the assumed
infrastructure is highly constrained?

Guido

> -----Urspr=FCngliche Nachricht-----
> Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] = Im Auftrag von
> Carsten Bormann
> Gesendet: Montag, 17. Mai 2010 18:59
> An: Charles Palmer
> Cc: core
> Betreff: Re: [core] Core UDP vs TCP : Redux
>
> On May 17, 2010, at 17:47, Charles Palmer wrote:
>
> > How disruptive would it be to design CoRE without reference to = TCP/UDP,
and
> also design a "reliable UDP" and use this for CoRE?
>
> I personally think CoAP needs to work with DTLS; if the WG moves in = that
> direction there will be some minimum requirement for independence = from the
> underlying protocol.
>
> However, what we expect from the underlying protocol has a big = bearing on
CoAP
> itself.
> If we expect we can always move to TCP, there will be little need = to make
CoAP
> operate on large representations with small underlying = interactions.  I've
> heard a lot of pushback on assuming the availability of TCP, so = far.
>
> There is also the aspect of interoperability:  One of the = great properties
of
> the Web is that everybody uses the same stack, so all Web clients = and
servers
> are interoperable, with IP providing the necessary = technological
diversity.
> (On the other hand, this has made it near impossible to swap in, = say,
SCTP.)
> Just standardizing CoAP without an "we expect this to run on = UDP, unless
> otherwise specified" would not achieve the same level of = interoperability.
>
> <WG chair hat>In any case, designing a reliable transport as = a TCP
replacement
> and then a CoAP on top of either that or TCP is very much not what = the
charter
> suggests we are supposed to do.</WG chair hat>
> Instead, we should look at how stateless CoAP really can be made -- = I
think
> even TFTP has too much state (and thus isn't as trivial a file = transfer
> protocol as it could be).
>
> Gruesse, Carsten
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/= mailman/listinfo/core

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

------_=_NextPart_001_01CAF68D.FCE5E675-- From cabo@tzi.org Tue May 18 06:41:10 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21F1B3A69A5 for ; Tue, 18 May 2010 06:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.256 X-Spam-Level: X-Spam-Status: No, score=-4.256 tagged_above=-999 required=5 tests=[AWL=-0.607, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVv+UXstTN6V for ; Tue, 18 May 2010 06:41:09 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id AA0163A6BD6 for ; Tue, 18 May 2010 06:39:53 -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 o4IDdYor028528; Tue, 18 May 2010 15:39:34 +0200 (CEST) Received: from [192.168.217.101] (p5489A815.dip.t-dialin.net [84.137.168.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 4B0D1D9A2; Tue, 18 May 2010 15:39:34 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Tue, 18 May 2010 15:39:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de><2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry><006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de><041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org> <007c01caf5d3$30f026f0$92d074d0$@moritz@uni-rostock.de> <3C20B7FD-CB93-43CC-83D2-3F4209CC5B84@tzi.org> <002101caf663$1c251d30$546f5790$@moritz@uni-rostock.de> To: "Oflynn, Colin" X-Mailer: Apple Mail (2.1078) Cc: core Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 13:41:10 -0000 On May 18, 2010, at 15:23, Oflynn, Colin wrote: > The resources which CoAP accesses SHOULD be accessible another in = another manner; most likely this is HTTP over TCP. Even though CoAP does = not map directly to HTTP, the requests are the same and thus I don't see = an issue here. Nodes which are highly constrained may only support CoAP; = larger nodes can support the full HTTP method. That is an interesting point, as it means that our main charter item "CoAP protocol specification with mapping to HTTP Rest API" may need this mapping not only in a node that provides a proxy function, = but also possibly right in the origin servers. While this can be = trivially reduced to co-locating the proxy with the origin server, it = does provide a slightly different point of view on this mapping than I = previously had. Interesting! Gruesse, Carsten From robert.cragie@gridmerge.com Tue May 18 07:18:45 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B1903A686E for ; Tue, 18 May 2010 07:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.868 X-Spam-Level: X-Spam-Status: No, score=-1.868 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNUP-zj9yw3s for ; Tue, 18 May 2010 07:18:44 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 939B228C120 for ; Tue, 18 May 2010 07:15:35 -0700 (PDT) Received: from 216-75-227-18.static.wiline.com ([216.75.227.18] helo=[192.168.5.116]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1OENZt-0005kK-Lt for core@ietf.org; Tue, 18 May 2010 15:15:26 +0100 Message-ID: <4BF2A0FA.9050909@gridmerge.com> Date: Tue, 18 May 2010 15:15:22 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: core@ietf.org References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de><2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry><006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de><041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org> <007c01caf5d3$30f026f0$92d074d0$@moritz@uni-rostock.de> <3C20B7FD-CB93-43CC-83D2-3F4209CC5B84@tzi.org> <002101caf663$1c251d30$546f5790$@moritz@uni-rostock.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040205060309020808050100" Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 14:18:45 -0000 This is a cryptographically signed message in MIME format. --------------ms040205060309020808050100 Content-Type: multipart/alternative; boundary="------------030808000700040405000500" This is a multi-part message in MIME format. --------------030808000700040405000500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Carsten, "co-locating the proxy with the origin server" seems to be a paradox -=20 can you explain what you mean? For the moment, I can't see why you'd=20 need to do this. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 18/05/2010 2:39 PM, Carsten Bormann wrote: > On May 18, 2010, at 15:23, Oflynn, Colin wrote: > > =20 >> The resources which CoAP accesses SHOULD be accessible another in anot= her manner; most likely this is HTTP over TCP. Even though CoAP does not = map directly to HTTP, the requests are the same and thus I don't see an i= ssue here. Nodes which are highly constrained may only support CoAP; larg= er nodes can support the full HTTP method. >> =20 > That is an interesting point, as it means that our main charter item > "CoAP protocol specification with mapping to HTTP Rest API" > may need this mapping not only in a node that provides a proxy function= , but also possibly right in the origin servers. While this can be trivi= ally reduced to co-locating the proxy with the origin server, it does pro= vide a slightly different point of view on this mapping than I previously= had. Interesting! > > Gruesse, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > =20 --------------030808000700040405000500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Carsten,

"co-locating the proxy with the origin server" seems to be a paradox - can you explain what you mean? For the moment, I can't see why you'd need to do this.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com


On 18/05/2010 2:39 PM, Carsten Bormann wrote: 
On May 18, 2010, at 15:23, Oflynn, Colin wrote:

  
The resources which CoAP accesses SHOULD be accessible=
 another in another manner; most likely this is HTTP over TCP. Even thoug=
h CoAP does not map directly to HTTP, the requests are the same and thus =
I don't see an issue here. Nodes which are highly constrained may only su=
pport CoAP; larger nodes can support the full HTTP method.
    
That is an interesting point, as it means that our main charter item
"CoAP protocol specification with mapping to HTTP Rest API"
may need this mapping not only in a node that provides a proxy function, =
but also possibly right in the origin servers.  While this can be trivial=
ly reduced to co-locating the proxy with the origin server, it does provi=
de a slightly different point of view on this mapping than I previously h=
ad.  Interesting!

Gruesse, Carsten

_______________________________________________
core mailing list
core@=
ietf.org
https://www.ietf.org/mailman/listinfo/core
--------------030808000700040405000500-- --------------ms040205060309020808050100 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA1 MTgxNDE1MjJaMCMGCSqGSIb3DQEJBDEWBBQpnsYhuDud6Np6sWRGmY4UvsX9xzBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBADHi5kxAhDiq8R5oLTaLTVTAfd3peujsw9L+VxGOHOGcbkDyp0QP+38UwX9M2o+LMOEf /9yZL5/u2Ce0M1nwMclUUfEaChk5u2eQ9xdx7LRayuZ8uIVlXu0N9aBZFZB66POcaVetlztW PiOfAxiSQ5ZuYkGs8e1xWQfusjEV5Jrws26LMsDylz2IAn+F/ILONbwhu1L1qbn57wlOMHGf BRfqfMbctXqqgaXyrPI0m4aWpeq2ynKYW1H+6qc2q2a92LiWWHzQo5PzgtidReQUu61ZUPsE j+wq75uhb9lzyvsonJojHGnUgrBj2fyQcLFeNPl2J8+N0lnlcb5DEoux/RgAAAAAAAA= --------------ms040205060309020808050100-- From cabo@tzi.org Tue May 18 07:34:57 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21CD13A6A31 for ; Tue, 18 May 2010 07:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.533 X-Spam-Level: X-Spam-Status: No, score=-5.533 tagged_above=-999 required=5 tests=[AWL=0.716, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ULZ+6HOxcTt for ; Tue, 18 May 2010 07:34:56 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id AA0AA3A6C21 for ; Tue, 18 May 2010 07:27:40 -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 o4IERN61020393; Tue, 18 May 2010 16:27:23 +0200 (CEST) Received: from [192.168.217.101] (p5489A815.dip.t-dialin.net [84.137.168.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id B09ACDA33; Tue, 18 May 2010 16:27:22 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4BF2A0FA.9050909@gridmerge.com> Date: Tue, 18 May 2010 16:27:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7312D5B8-CB41-451B-ADD6-D7AD17BD2747@tzi.org> References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de><2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry><006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de><041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org> <007c01caf5d3$30f026f0$92d074d0$@moritz@uni-rostock.de> <3C20B7FD-CB93-43CC-83D2-3F4209CC5B84@tzi.org> <002101caf663$1c251d30$546f5790$@moritz@uni-rostock.de> <4BF2A0FA.9050909@gridmerge.com> To: robert.cragie@gridmerge.com X-Mailer: Apple Mail (2.1078) Cc: core@ietf.org Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 14:34:57 -0000 On May 18, 2010, at 16:15, Robert Cragie wrote: > "co-locating the proxy with the origin server" seems to be a paradox - = can you explain what you mean? For the moment, I can't see why you'd = need to do this. I just mentioned this as a trivial proof that of course the CoAP-to-HTTP = mapping would already specify one way to do the CoAP-to-HTTP switch on = the origin server, because you could do the colocation. But, yes, this = certainly can be modeled in a simpler way. The question is whether a = client would have to care whether the HTTP access is through a = (non-colocated) proxy to a CoAP-only origin server or right on the HTTP = service of the origin server. It would be nice if it didn't have to = care (except maybe for the URI). This creates some additional = objectives for the HTTP mapping that I wasn't aware of. Gruesse, Carsten From robby.simpson@ge.com Tue May 18 08:02:57 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEA0B3A69D5 for ; Tue, 18 May 2010 08:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.554 X-Spam-Level: X-Spam-Status: No, score=-4.554 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zE1-UJKw2R0i for ; Tue, 18 May 2010 08:02:56 -0700 (PDT) Received: from exprod5og104.obsmtp.com (exprod5og104.obsmtp.com [64.18.0.178]) by core3.amsl.com (Postfix) with ESMTP id 90D9828C128 for ; Tue, 18 May 2010 08:02:46 -0700 (PDT) Received: from source ([4.78.218.129]) (using TLSv1) by exprod5ob104.postini.com ([64.18.4.12]) with SMTP ID DSNKS/KsDkHYDoOcOYmYoMdau1Qcsf9dko7n@postini.com; Tue, 18 May 2010 08:02:39 PDT Received: from unknown (HELO alpmlef08.e2k.ad.ge.com) ([3.159.18.17]) by Cinmlip09.e2k.ad.ge.com with ESMTP; 18 May 2010 11:02:38 -0400 Received: from ALPMLVEM04.e2k.ad.ge.com ([3.159.17.50]) by alpmlef08.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 May 2010 11:02:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 May 2010 11:01:54 -0400 Message-ID: In-Reply-To: <7312D5B8-CB41-451B-ADD6-D7AD17BD2747@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CoAP-to-HTTP and Security (was RE: [core] Core UDP vs TCP : Redux) thread-index: Acr2l0s5l22P4azkSrC1Y4XM6olwiwAAz+RA References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de><2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry><006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de><041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org> <007c01caf5d3$30f026f0$92d074d0$@moritz@uni-rostock.de> <3C20B7FD-CB93-43CC-83D2-3F4209CC5B84@tzi.org> <002101caf663$1c251d30$546f5790$@moritz@uni-rostock.de> <4BF2A0FA.9050909@gridmerge.com> <7312D5B8-CB41-451B-ADD6-D7AD17BD2747@tzi.org> From: "Simpson, Robby (GE Energy Services)" To: "Carsten Bormann" , X-OriginalArrivalTime: 18 May 2010 15:02:37.0456 (UTC) FILETIME=[2761B900:01CAF69B] Cc: core@ietf.org Subject: [core] CoAP-to-HTTP and Security (was RE: Core UDP vs TCP : Redux) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 15:02:57 -0000 Thus far, from a security perspective, the only protocol I have seen floated is DTLS. If end-to-end security is desired, as well as translation from CoAP-to-HTTP and vice versa, how do we envision this occurring? Would the point of translation need to be a break in the end-to-end security? - Robby =20 -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Tuesday, May 18, 2010 10:27 AM To: robert.cragie@gridmerge.com Cc: core@ietf.org Subject: Re: [core] Core UDP vs TCP : Redux On May 18, 2010, at 16:15, Robert Cragie wrote: > "co-locating the proxy with the origin server" seems to be a paradox - can you explain what you mean? For the moment, I can't see why you'd need to do this. I just mentioned this as a trivial proof that of course the CoAP-to-HTTP mapping would already specify one way to do the CoAP-to-HTTP switch on the origin server, because you could do the colocation. But, yes, this certainly can be modeled in a simpler way. The question is whether a client would have to care whether the HTTP access is through a (non-colocated) proxy to a CoAP-only origin server or right on the HTTP service of the origin server. It would be nice if it didn't have to care (except maybe for the URI). This creates some additional objectives for the HTTP mapping that I wasn't aware of. Gruesse, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From Michael.Stuber@itron.com Tue May 18 08:29:19 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29F7B3A6828 for ; Tue, 18 May 2010 08:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.818 X-Spam-Level: X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[AWL=0.782, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfH1giUWlNo8 for ; Tue, 18 May 2010 08:29:17 -0700 (PDT) Received: from mailer-1.itron.com (mailer-1.itron.com [198.182.8.123]) by core3.amsl.com (Postfix) with ESMTP id 810773A680D for ; Tue, 18 May 2010 08:27:43 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 May 2010 08:27:35 -0700 Message-ID: <05C6A38D732F1144A8C4016BA4416BFE02D5A646@SPO-EXVS-02.itron.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] CoAP-to-HTTP and Security (was RE: Core UDP vs TCP : Redux) Thread-Index: Acr2l0s5l22P4azkSrC1Y4XM6olwiwAAz+RAAACzjEA= References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de><2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry><006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de><041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org> <007c01caf5d3$30f026f0$92d074d0$@moritz@uni-rostock.de> <3C20B7FD-CB93-43CC-83D2-3F4209CC5B84@tzi.org> <002101caf663$1c251d30$546f5790$@moritz@uni-rostock.de> <4BF2A0FA.9050909@gridmerge.com><7312D5B8-CB41-451B-ADD6-D7AD17BD2747@tzi.org> From: "Stuber, Michael" To: "Simpson, Robby (GE Energy Services)" , "Carsten Bormann" , Cc: core@ietf.org Subject: Re: [core] CoAP-to-HTTP and Security (was RE: Core UDP vs TCP : Redux) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 15:29:19 -0000 If we have a deployment model in which two protocols are used, for example CoAP with a HAN, and HTTP back to a central server, it seems we have two obvious choices: (1) Provide security within the application message contents (i.e. not the protocol itself), such that the contents are secured end-to-end. An example of this would be an encrypted file. It doesn't matter if it is sent over FTP, HTTP, or camel train, the contents is still encrypted and presumably only available to the sending and receiving parties with the secret key. (2) Accept a break a in the end-to-end security model at the translation node. The message is secured between the HAN and the translator, and the translator and the central server, but temporarily exposed within the translator itself as the contents are transformed from one protocol to another. Are there other approaches? I could imagine some function thing where the translator node allows a CoAP device to complete TLS negotiation with a HTTP server, but I wouldn't want to have to write it, and the possibility for opening a security hole seems pretty large to me. -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Simpson, Robby (GE Energy Services) Sent: Tuesday, May 18, 2010 8:02 AM To: Carsten Bormann; robert.cragie@gridmerge.com Cc: core@ietf.org Subject: [core] CoAP-to-HTTP and Security (was RE: Core UDP vs TCP : Redux) Thus far, from a security perspective, the only protocol I have seen floated is DTLS. If end-to-end security is desired, as well as translation from CoAP-to-HTTP and vice versa, how do we envision this occurring? Would the point of translation need to be a break in the end-to-end security? - Robby =20 -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Tuesday, May 18, 2010 10:27 AM To: robert.cragie@gridmerge.com Cc: core@ietf.org Subject: Re: [core] Core UDP vs TCP : Redux On May 18, 2010, at 16:15, Robert Cragie wrote: > "co-locating the proxy with the origin server" seems to be a paradox - can you explain what you mean? For the moment, I can't see why you'd need to do this. I just mentioned this as a trivial proof that of course the CoAP-to-HTTP mapping would already specify one way to do the CoAP-to-HTTP switch on the origin server, because you could do the colocation. But, yes, this certainly can be modeled in a simpler way. The question is whether a client would have to care whether the HTTP access is through a (non-colocated) proxy to a CoAP-only origin server or right on the HTTP service of the origin server. It would be nice if it didn't have to care (except maybe for the URI). This creates some additional objectives for the HTTP mapping that I wasn't aware of. Gruesse, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From scholza@in.tum.de Tue May 18 09:05:30 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECED73A6A87 for ; Tue, 18 May 2010 09:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.951 X-Spam-Level: X-Spam-Status: No, score=0.951 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ys-BQ0KZOna3 for ; Tue, 18 May 2010 09:05:29 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 084783A688E for ; Tue, 18 May 2010 09:04:37 -0700 (PDT) Received: from [172.30.2.214] (p54A31CE4.dip0.t-ipconnect.de [84.163.28.228]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.in.tum.de (Postfix) with ESMTP id 7C5D4DBA3 for ; Tue, 18 May 2010 18:04:27 +0200 (CEST) Message-ID: <4BF2BA8A.5020208@in.tum.de> Date: Tue, 18 May 2010 18:04:26 +0200 From: Andreas Scholz User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: core@ietf.org References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de> <2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry> <006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de> <041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org> <007c01caf5d3$30f026f0$92d074d0$@moritz@uni-rostock.de> In-Reply-To: <007c01caf5d3$30f026f0$92d074d0$@moritz@uni-rostock.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 16:05:31 -0000 I think Guido points out an important aspect: a resource constraint network will have to transmit and process data with fairly different characteristics A typical way to develop an automation application is to connect services (or function blocks, etc) together to a larger application. The data exchanged between these blocks will have different characteristics. Assume we have a automation application with the following structure: Process Sensor | Logic ---- Actuator | Switch The switch will require a reliable message transport (assuming e.g. a power off functionality). Assume the process sensor produces data frequently, in this case no reliability is required because some lost packets are tolerable. The connection between the Logic and the Actuator might require reliability again. Another aspect is security. Some of those links might require secure communications, others not. One possibility to solve these different requirements is to embed the specification of such requirements into the subscription mechanism. Based on these requirements different protocol bindings could be selected by COAP. If a node supports TCP and the user wants reliability, TCP is selected. If the node does not support TCP some kind of reliable UDP is selected. If no reliability is needed COAP selects pure UDP. To support such heterogeneous scenarios, COAP might not only need the flexibility to support different bindings, but might even need the flexibility to select different bindings for individual parts of the application (unless we want to (re-)implement each of these features in or on top of the application protocol) Coming back to the latest posts regarding security aspects: An end-to-end encryption could be one of the situations where you want to choose a specific protocol binding (e.g. SOAP + Web Service security standards, just to name a protocol suite that would support this kind of interaction). Guido Moritz schrieb: >> It may also be hard to meet this objective while inserting a subprotocol >> > as complex as SOAP into the stack. > I just went through the current COAP I-D and it is already quite complex! It > includes many mechanisms and concepts which are also included in SOAP and > other W3C/OASIS Web services specifications that I am familiar in due to my > background in DPWS. > > Nevertheless, let's leave the discussion around SOAP, because there seems to > be many misunderstandings related to SOAP and what I wanted to point at. > What I wanted to say is (and that is my still my opinion after reading > current COAP I-D): there is no reason to bind COAP to UDP or TCP exclusively > or exclude one of them. COAP seems to describe many mechanisms for > interaction with resources, eventing and discovery mechanisms, mechanisms to > avoid duplicated message processing etc. But all these mechanisms do not > depend on the transport layer. Why should a node not support interactions by > using TCP or UDP at the same time for the same resource. Of course, not the > highly resource constrained one, but we are heading towards heterogeneous > device infrastructures where resource richer devices in the same network > might be possible as well. > > Take the ideas or throw them away. But these are major decisions concerning > applicability of the resulting COAP. What made HTTP and REST in the WWW such > a success was that it is possible to run it over all kinds of technologies > and not to restrict it to specific message sizes. Let's say there is a cool > new wireless technology IEEE 802.15.XY which is capable of running 6LoWPAN > but with double of the frame size and data rate at same energy costs. Will > there be the next COAPXY for this new link layer because suddenly there is > double the bandwidth available? > > Again, > Just my two cents ;) > Guido > > >> -----Ursprüngliche Nachricht----- >> Von: Carsten Bormann [mailto:cabo@tzi.org] >> Gesendet: Montag, 17. Mai 2010 16:24 >> An: Guido Moritz >> Cc: core@ietf.org >> Betreff: Re: [core] Core UDP vs TCP : Redux >> >> On May 17, 2010, at 15:58, Guido Moritz wrote: >> >> >>> I just wanted to ask >>> if it is reasonable to bind the CORE protocol to UDP,TCP or whatever or >>> > if > >>> it is possible to leave this open and design CORE extensible and >>> > flexible > >>> enough. >>> >> It may be hard to meet the working group's objective of addressing >> > constrained > >> node/networks while leaving the underlying protocol(s) open. It may also >> > be > >> hard to meet this objective while inserting a subprotocol as complex as >> > SOAP > >> into the stack. >> >> Gruesse, Carsten >> > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > -- Andreas Scholz Lehrstuhl Informatik III Tel. +49 89 289-17292 TU München, Zimmer 02.11.037 FMI andreas.scholz@in.tum.de Boltzmannstr. 3, 85748 Garching From richard.kelsey@ember.com Tue May 18 09:08:07 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0DEE28C10B for ; Tue, 18 May 2010 09:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.12 X-Spam-Level: X-Spam-Status: No, score=-0.12 tagged_above=-999 required=5 tests=[AWL=-1.010, BAYES_05=-1.11, J_BACKHAIR_33=1, J_BACKHAIR_44=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAdhDwV5virH for ; Tue, 18 May 2010 09:08:07 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 7F42F3A6C3B for ; Tue, 18 May 2010 09:07:20 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 May 2010 12:10:38 -0400 Date: Tue, 18 May 2010 12:06:44 -0400 Message-Id: <87ocgdyz1n.fsf@kelsey-ws.hq.ember.com> To: "Stuber, Michael" In-reply-to: <05C6A38D732F1144A8C4016BA4416BFE02D5A646@SPO-EXVS-02.itron.com> (Michael.Stuber@itron.com) From: Richard Kelsey References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de><2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry><006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de><041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org> <007c01caf5d3$30f026f0$92d074d0$@moritz@uni-rostock.de> <3C20B7FD-CB93-43CC-83D2-3F4209CC5B84@tzi.org> <002101caf663$1c251d30$546f5790$@moritz@uni-rostock.de> <4BF2A0FA.9050909@gridmerge.com><7312D5B8-CB41-451B-ADD6-D7AD17BD2747@tzi.org> <05C6A38D732F1144A8C4016BA4416BFE02D5A646@SPO-EXVS-02.itron.com> X-OriginalArrivalTime: 18 May 2010 16:10:38.0912 (UTC) FILETIME=[A81E7C00:01CAF6A4] Cc: core@ietf.org Subject: Re: [core] CoAP-to-HTTP and Security (was RE: Core UDP vs TCP : Redux) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 16:08:07 -0000 > Date: Tue, 18 May 2010 08:27:35 -0700 > From: "Stuber, Michael" > > If we have a deployment model in which two protocols are used, for > example CoAP with a HAN, and HTTP back to a central server, it seems we > have two obvious choices: > (1) [...] > > (2) Accept a break a in the end-to-end security model at the > translation node. The message is secured between the HAN and the > translator, and the translator and the central server, but temporarily > exposed within the translator itself as the contents are transformed > from one protocol to another. The exposure can be minimized by putting the translator on the central server. This gives you machine-to-machine end-to-end security. The translator can take care of CORE<->HTTP (and possibly EXI<->XML), allowing the rest of the central server to remain blissfully ignorant of anything smaller than a PC or slower than 100Mb ethernet. -Richard Kelsey From cabo@tzi.org Tue May 18 09:36:16 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75E9B28C14E for ; Tue, 18 May 2010 09:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.815 X-Spam-Level: X-Spam-Status: No, score=-4.815 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_05=-1.11, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlD0S6wkz2AM for ; Tue, 18 May 2010 09:36:15 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id E3EED28C1E5 for ; Tue, 18 May 2010 09:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id o4IGUWlt015600 for ; Tue, 18 May 2010 18:30:32 +0200 (CEST) Received: from [192.168.217.101] (p5489A815.dip.t-dialin.net [84.137.168.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id D1961DB88; Tue, 18 May 2010 18:30:31 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <05C6A38D732F1144A8C4016BA4416BFE02D5A646@SPO-EXVS-02.itron.com> Date: Tue, 18 May 2010 18:30:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <56A5C17D-2637-4C9B-919E-A7575683085D@tzi.org> References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de><2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry><006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de><041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org> <007c01caf5d3$30f026f0$92d074d0$@moritz@uni-rostock.de> <3C20B7FD-CB93-43CC-83D2-3F4209CC5B84@tzi.org> <002101caf663$1c251d30$546f5790$@moritz@uni-rostock.de> <4BF2A0FA.9050909@gridmerge.com><7312D5B8-CB41-451B-ADD6-D7AD17BD2747@tzi.org> <05C6A38D732F1144A8C4016BA4416BFE02D5A646@SPO-EXVS-02.itron.com> To: core X-Mailer: Apple Mail (2.1078) Subject: Re: [core] CoAP-to-HTTP and Security (was RE: Core UDP vs TCP : Redux) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 16:36:16 -0000 On May 18, 2010, at 17:27, Stuber, Michael wrote: > (2) Accept a break a in the end-to-end security model at the > translation node. The message is secured between the HAN and the > translator, and the translator and the central server, but temporarily > exposed within the translator itself as the contents are transformed > from one protocol to another. One interesting aspect here is the trust model. E.g., the meter may trust the utility server, and the meter may trust = (maybe with a different trust model) the washing machine, but there = needn't be a trust relationship between the washing machine and the = utility server. This would already make the meter a natural point to = terminate (and proxy between) two separate security associations. =20 Of course, not every case where you would want to locate a proxy may be = so lucky. (But I think it is very useful to discuss architecture in specific = terms, not in generalizations that may or may not be relevant.) Gruesse, Carsten From charles.palmer@onzo.com Tue May 18 13:50:33 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE2E428C229 for ; Tue, 18 May 2010 13:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.271 X-Spam-Level: X-Spam-Status: No, score=0.271 tagged_above=-999 required=5 tests=[AWL=1.270, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aG6Z36tm7z7 for ; Tue, 18 May 2010 13:50:31 -0700 (PDT) Received: from service38.mimecast.com (service38.mimecast.com [212.2.3.166]) by core3.amsl.com (Postfix) with SMTP id D121728C1FD for ; Tue, 18 May 2010 13:47:39 -0700 (PDT) Received: from onzosbs2k3.ONZO.local (217.138.5.2 [217.138.5.2]) by service38.mimecast.com; Tue, 18 May 2010 21:47:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 May 2010 21:45:54 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] CoAP-to-HTTP and Security (was RE: Core UDP vs TCP :Redux) Thread-Index: Acr2qDs/dq8Uims+Sh2e7x2mu+QpFQAHIdCw References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de><2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry><006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de><041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org> <007c01caf5d3$30f026f0$92d074d0$@moritz@uni-rostock.de> <3C20B7FD-CB93-43CC-83D2-3F4209CC5B84@tzi.org> <002101caf663$1c251d30$546f5790$@moritz@uni-rostock.de> <4BF2A0FA.9050909@gridmerge.com><7312D5B8-CB41-451B-ADD6-D7AD17BD2747@tzi.org><05C6 A38D732F1144A8C4016BA4416BFE02D5A646@SPO-EXVS-02.itron.com> <56A5C17D-2637-4C9B-919E-A7575683085D@tzi.org> From: "Charles Palmer" To: "core" X-MC-Unique: 110051821473000802 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [core] CoAP-to-HTTP and Security (was RE: Core UDP vs TCP :Redux) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 20:50:33 -0000 Dear all My project (http://projecthydra.info/) is exploring the use of secure micros and smart card technology to provide tamper resistant hardware in (for example) smart meter applications and to allow secure, dynamic deployment of multiple applications ("value-added services" - such as telecare) onto (say) smart meters. The smart card industry have solved problems that are being discussed here and elsewhere, including how to provide separate (robust) security domains (one for each application) within a single resource constrained micro, how to provide (robust) end-to-end secure communications channels from one application to its off-card server through an un-trusted comms infrastructure, and how to do secure software deployments/updates, including updates where the application owner need not trust the card owner. GlobalPlatform is a key technology. To address the last point in this thread: GlobalPlatform assumes maximum paranoia and requires almost no trust. I would submit that in application spaces where billions of dollars are being transferred that is the right attitude. We are currently playing with ideas such as: 1 How to extend a smart card architecture (normally a host-card interface with a request initiated by a terminal and response provided by the smart card) to an architecture where the smart card also has to communicate with "devices" (smart meters, health-care devices). 2 How to map the GlobalPlatform capabilities onto CoRE or ZigBee SE2.0 application specifications. We'd be very interested in exploring these areas with CoRE participants, within this list or outside. Regards - Charles Palmer=20 -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: 18 May 2010 17:31 To: core Subject: Re: [core] CoAP-to-HTTP and Security (was RE: Core UDP vs TCP :Redux) On May 18, 2010, at 17:27, Stuber, Michael wrote: > =09(2)=09Accept a break a in the end-to-end security model at the > translation node. The message is secured between the HAN and the > translator, and the translator and the central server, but temporarily > exposed within the translator itself as the contents are transformed > from one protocol to another. One interesting aspect here is the trust model. E.g., the meter may trust the utility server, and the meter may trust (maybe with a different trust model) the washing machine, but there needn't be a trust relationship between the washing machine and the utility server. This would already make the meter a natural point to terminate (and proxy between) two separate security associations. =20 Of course, not every case where you would want to locate a proxy may be so lucky. (But I think it is very useful to discuss architecture in specific terms, not in generalizations that may or may not be relevant.) Gruesse, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core -------------------------------- Onzo is a limited company number 06097997 registered in England & Wales. Th= e =20 registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingd= om. This email message may contain confidential and/or privileged information, = and is intended solely for the addressee(s). If you have received this email in= =20 error, please notify Onzo immediately. Unauthorised copying, disclosure or= =20 distribution of the material in this email is forbidden. -------------------------------- From yoshihiro.ohba@toshiba.co.jp Tue May 18 21:07:15 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A3BF3A6901 for ; Tue, 18 May 2010 21:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4pSBai8Tc7T for ; Tue, 18 May 2010 21:07:13 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by core3.amsl.com (Postfix) with ESMTP id B505E3A68BF for ; Tue, 18 May 2010 21:07:13 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id o4J474ru019253; Wed, 19 May 2010 13:07:04 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id o4J474E3005745; Wed, 19 May 2010 13:07:04 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id PAA05743; Wed, 19 May 2010 13:07:04 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id o4J473wt024738; Wed, 19 May 2010 13:07:04 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id o4J46HGu023784; Wed, 19 May 2010 13:07:01 +0900 (JST) Received: from [133.196.17.73] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0L2N00LUIFFHDNC0@mail.po.toshiba.co.jp>; Wed, 19 May 2010 13:06:53 +0900 (JST) Date: Wed, 19 May 2010 13:06:51 +0900 From: Yoshihiro Ohba In-reply-to: <56A5C17D-2637-4C9B-919E-A7575683085D@tzi.org> To: Carsten Bormann Message-id: <4BF363DB.9010705@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <002b01caf58d$a3b0d770$eb128650$%moritz@uni-rostock.de> <2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry> <006901caf5c8$f9431d70$ebc95850$%moritz@uni-rostock.de> <041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org> <007c01caf5d3$30f026f0$92d074d0$%moritz@uni-rostock.de> <3C20B7FD-CB93-43CC-83D2-3F4209CC5B84@tzi.org> <002101caf663$1c251d30$546f5790$%moritz@uni-rostock.de> <4BF2A0FA.9050909@gridmerge.com> <7312D5B8-CB41-451B-ADD6-D7AD17BD2747@tzi.org> <05C6A38D732F1144A8C4016BA4416BFE02D5A646@SPO-EXVS-02.itron.com> <56A5C17D-2637-4C9B-919E-A7575683085D@tzi.org> User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) Cc: core Subject: Re: [core] CoAP-to-HTTP and Security (was RE: Core UDP vs TCP : Redux) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 04:07:15 -0000 What about if there is a relay or proxy between the meter and the central server? For example, ANSI C12.22 provides end-to-end data encryption. Of course security requirements depend on the trust model. Question: what is trust model of CORE? Thanks, Yoshihiro Ohba Carsten Bormann wrote: > On May 18, 2010, at 17:27, Stuber, Michael wrote: > >> (2) Accept a break a in the end-to-end security model at the >> translation node. The message is secured between the HAN and the >> translator, and the translator and the central server, but temporarily >> exposed within the translator itself as the contents are transformed >> from one protocol to another. > > One interesting aspect here is the trust model. > E.g., the meter may trust the utility server, and the meter may trust (maybe with a different trust model) the washing machine, but there needn't be a trust relationship between the washing machine and the utility server. This would already make the meter a natural point to terminate (and proxy between) two separate security associations. > > Of course, not every case where you would want to locate a proxy may be so lucky. > (But I think it is very useful to discuss architecture in specific terms, not in generalizations that may or may not be relevant.) > > Gruesse, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From zach@sensinode.com Mon May 24 06:46:17 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 868323A6BFA for ; Mon, 24 May 2010 06:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[AWL=-0.990, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sE7Lb87wM0e4 for ; Mon, 24 May 2010 06:46:15 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id C6DE33A6A45 for ; Mon, 24 May 2010 06:46:14 -0700 (PDT) Received: from [10.10.100.182] ([84.239.254.208]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o4ODjugo001178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 May 2010 16:45:57 +0300 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Mon, 24 May 2010 16:45:58 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7ACD74E5-787D-47A4-82BF-5A640396D546@sensinode.com> References: <3BB5F67A-9E57-4F81-B7C5-ABB1E136DAAC@tzi.org> <568AEFD6-974D-4790-A2F8-84305B990BA9@cisco.com> To: "Angelo P. Castellani" X-Mailer: Apple Mail (2.1078) Cc: core Subject: Re: [core] Selecting a WG document for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 13:46:17 -0000 Angelo, Thanks for the technical comments, now I better understand what you have = in mind.=20 On May 14, 2010, at 11:50 AM, Angelo P. Castellani wrote: > Cullen, >=20 > thanks for the excellent understanding of my doubts. >=20 > Point (a) is exactly about the very initial design approach to define > a new realization of REST (e.g.: CRUD methods were defined instead of > standard HTTP methods) instead of a feature-limited adaptation of HTTP > itself to constrained host/network environments. >=20 > There was even discussion on defining mapping of various protocols to > CoAP without clear focus on HTTP translation. HTTP translation is not the only goal of the WG. CoAP should work on its = own, and CoAP may very well be proxied with many protocols. However the = WG does have the requirement of defining an HTTP mapping for CoAP. We of = course want to make that as painless as possible! But it doesn't mean = that CoAP is HTTP.=20 > Doubts were raised that CoAP may be following the "reinvent HTTP" > road, killing itself just as WAP did. Discussion on URI-Code/BinaryURI > (as detailed in the Transparent proxying CoAP mail) is just the tip of > the iceberg. >=20 > Draft -01 has made some valid enhancements on this topic (see HTTP > methods), however the whole document subtly imply this design > objective throughout. Thanks. You mean GET, POST, PUT, DELETE? Sure, that makes an HTTP = mapping easier to understand. Otherwise I don't find coap-01 very = difficult to map to HTTP. Sure, Subscribe/Notify takes some effort, but = that even can't be mapped HTTP-HTTP today as there is no standard way to = do it ;-)=20 > In my humble opinion the direction that can be followed is: If > HTTP/TCP is not viable on CoRE, we should find a way to adapt it to > this environment. This was discussed at length during chartering, and we decided not to do = this. HTTP/TCP is a perfectly good solution on some kinds of devices and = networks, and it should be used as is there. CoRE is aiming at a special = class of constrained devices and networks.=20 >=20 > Design philosophy: CoAP should be a *stateless* HTTP-translation and > we should start by understanding how we can compress HTTP preserving > its core principles to be *stateless*, providing an *uniform* > interface to access *diverse* content organized in a *hierarchical* > fashion, it should be easily *cacheable* and *translatable*. All these things are already in our CoAP design philosophy - we are = making a RESTful protocol. However we are not compressing HTTP, or just = doing an HTTP translation. We are designing a RESTful protocol, which = *can* be mapped to HTTP.=20 Now apart from philosophy here, we are technically already very = close.... =20 > Being pratical: > -* uniformity leads to only request and response (no notify, no other > message types, REST should be only REQ/RES) Uniformity of what? Notify actually gives a uniform way of notifying = about a resource, and conceptually it does belong as a message. It is = clearly not Req/Res, please see the original list exchange started by = Robert Cragie. That is where we decided to make it a message instead of = a Method. > -* hierarchy leads to URI and BinaryURI as in the transparent proxying > discussion (no flat codes like URI-Code) URI-Code is just something we started with, I am open to any scheme. = Already your Sum Modulo-255 is being discussed, below it seems you are = suggesting a different one. =20 > -* stateless, translation, cacheability lead to URI->BinaryURI as a > stateless mapping (avoid stateful tables) Yep, you have a point there.=20 >=20 > -* stateless and diversity suggest that content should be always fully > described Content-Lenght (req), Content-Type (req) and > Content-Enconding should be supported Um, wrong. Content-Length and Content-Type are not always needed. We = already discussed on the list that we can do without Content-Encoding.=20= >=20 > -* cacheable flag should be included always (not an option) >=20 > -* stateless server and stateful resources? cookies are required (lets > use binary cookies) I need some more convincing here that we really need cookies. What is = the use case? > Other considerations, important in my opinion, on the realization of > the protocol (more technical here): >=20 > -* translation and compression should focus on the URI >=20 > a) It should be always present and not an option Why? If your URL is / then there is no reason to necessarily include it.=20= >=20 > b) Using a flag we should understand whether we are using URI or the > lossy BinaryURI encoding Possible, basically combining two options into one.=20 >=20 > c) URI is ASCII-7 and is usually formed by chars, numbers and a few > others? I propose to investigate compressed loss-less encodings. Now I > can think at least two different encodings: > i) Represent the / (supposed to be most frequent char in URI) > using the left-most unused bit in the octet > ii) Represent most frequent chars (regex format: [0-9a-zA-Z/]) > using 6 bit encoding, use a NULL (\x00) octet to signal that an > uncompressed char is following. Every 3 compressed chars we have 6 > unused bits that can map another char (0.75 ratio in the best case, > other cases to be evaluated). > Maybe some predefined vocabularies can be agreed, and the used > vocabulary chosen in a preceding field (vocabulary 2 example: > [a-zA-Z%+._/\|=3D&?-]) Sure, such an encoding could be used for all URIs, at least 7-bit ASCII = encoding would be easy and already now we are leaving out the / in = coap-01. This is a different issue to the Binary URI encoding. >=20 > -* option translation issues (addressing complex implementation), > general rule avoid variable length options (harder to handle): We can avoid most variable length options at cost to flexibility, sure. = URIs are an exception obviously.=20 > a) Messages with Payload should always carry Content-Length and > Content-Type before the payload I am not buying that. Content-Length is only needed when packing = multiple messages in a UDP payload or over a stream. In many = applications you don't explicitly need the Content-Type (and mapping = from HTTP you might not always get it). > b) Define which are the well-known request and response options we > want to support, without merging them (it seems not a good choice > because many are response specific only, and many other request > specific only). > Well-known options present in the message should be represented > in a binary bitmask (like in 6LoWPAN HC) and carried in-line > (fixed-length is an important requirement, however variable length can > be handled if cannot be avoided) > When similar options are available may be beneficial to prefer > the simplest and easiest to compress (fixed-length). > Example: Last-Modified should be preferred to Etag, (1) it can be > represented as an unsigned integer, (2) with a binary flag > representing "Now" its insertion can be delegated to the HTTP > translating entity, (3) supports conditional GET. This we can discuss. The working group is going to have to find a = balance between flexibility in options and efficiency/complexity. I = originally proposed (coap-req-01) having a totally fixed header with no = options, but the WG clearly wanted options. You can't have your cake and = eat it too. >=20 > c) Other options compressed with the URI style encoding (better > vocabulary here is [a-zA-Z%+._/\|=3D&?-]) >=20 >=20 > I'm quite confident that the final compression ratio is good and, if > properly investigated, it should retain the ability to do CoAP->HTTP > translation too (Host option required). There are all really optimizations, which I am confident we will work = through as a WG. I am also sure we can still simplify and improve coap!=20= >=20 > Moreover using CoAP realized like this leads to an easier > straightforward C implementation, mainly thanks to many specific > details especially bitmasks, fixed-length options, bitwise operations. >=20 > I hope I was able to give an idea of my thinking on these issues. A > more exhaustive and detailed list of the issues is not easy to provide > by e-mail, but I will be happy to draft a document with more details > if this is considered as an useful contribution to this discussion. All discussion and input are useful here. In the future it might be = easier to split this up into smaller subject threads rather than a large = list of issues all at once.=20 Thanks, Zach >=20 > Best, > Angelo >=20 > On Thu, May 13, 2010 at 16:57, Cullen Jennings = wrote: >>=20 >> Angelo, >>=20 >> I may be reading too much in between the lines here, but I think you = are raising the overall design question of should we use some form of = compressed HTTP, where we preserver the semantics of HTTP but encode it = differently, or should we develop a protocol with a subset of the = semantics of HTTP. Perhaps I have this all wrong and you are not raising = that. Could you outline some proposed solutions to your a,b,c problems = below and perhaps say a bit more about what the problem is. Once I = understood a bit more about how you would propose to design the protocol = to mitigate these problems, I think that would help everyone make = informed choices. >>=20 >> Thanks, Cullen >>=20 >> Few more questions inline .... >>=20 >> On May 13, 2010, at 5:24 AM, Angelo P. Castellani wrote: >>=20 >>> Dear C. Bormann, all, >>>=20 >>> before deciding for the final direction, I've the following >>> observations about draft-shelby-core-coap-01 >>>=20 >>> While I mostly share Zach's view of the protocol approach, and >>> appreciate many aspects of the proposal, there are in my opinion = still >>> some open issues that need to be at least discussed before the = current >>> document can be selected. >>>=20 >>> In particular, I would like to highlight the following: >>>=20 >>> a) As it is now, it is not possible to have a straightforward >>> translation of HTTP -> CoAP and viceversa: see >>> http://www.ietf.org/mail-archive/web/core/current/msg00133.html = (this >>> impacts the scalability of the web service model too) >>=20 >> On the topic of how to encode the URI. I think that needs discussion = but could easily happen (and would happen) even if the COAP document was = adopted as a WG item now. >>=20 >>>=20 >>> b) Moreover, CoAP's implementation is not as simple as it should be. >>> I've investigated the implementation and some design choices (as >>> Options) are leading to very high program complexity (ROM) on a >>> MSP430-based device. >>=20 >> Can you say more - particularly about proposals to fix it? >>=20 >>>=20 >>> c) Finally when comparing HTTP message size with CoAP message size, >>> the resulting compression isn't as good as you may expect. >>>=20 >>> Example: >>> HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B >>> CoAP: 24 B with options parsing procedure requiring an added >>> implementation complexity >>>=20 >>> Addressing all these points potentially leads to major technical >>> modifications (especially point a) on the current draft, hence it is >>> appropriate in my opinion to discuss these points before making the >>> final decision. >>>=20 >>> Best regards, >>>=20 >>> Angelo P. Castellani >>>=20 >>>=20 >>> On Mon, May 10, 2010 at 18:51, Carsten Bormann wrote: >>>> The CORE WG has a milestone to select a WG document for CoAP in = April: >>>>=20 >>>> http://datatracker.ietf.org/wg/core/charter/ >>>> ... >>>> Apr 2010 Select WG document for basis of the CoAP protocol >>>>=20 >>>> Of the various documents that have been contributed, = draft-shelby-core-coap has significant discussion, as well as the = largest number of updates (including a previous version that was still = called -6lowapp-coap). >>>>=20 >>>> Today, another updated version of that draft was announced. See >>>> http://www.ietf.org/mail-archive/web/core/current/msg00138.html >>>> for the announcement and >>>> http://tools.ietf.org/html/draft-shelby-core-coap-01 >>>> for the draft itself. >>>>=20 >>>> However, as the authors say, there are still significant TODOs. >>>>=20 >>>> Are we in a state yet where we can say whether this is the right = direction for the WG to take? >>>> If yes, is it the right direction? Should we adopt it as a WG = document? >>>> If you don't think we can say yet, is there a set of technical = decisions you would like the authors to take with priority? >>>>=20 >>>> Note that once a document has become a WG document, the authors act = as editors for the working group, making (and usually fleshing out the = details of) any change that the WG decides it needs. >>>> If you think we can still improve the draft, this is not an = obstacle to making it a WG document. >>>> But of course we shouldn't do that if we intend to reverse its = fundamental technical direction. >>>>=20 >>>> In order to stay roughly in sync with our milestones, we should = reach at a decision on how to go forward this week. >>>>=20 >>>> Gruesse, 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 >>=20 >>=20 >> Cullen Jennings >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>=20 >>=20 >>=20 >>=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From zach@sensinode.com Mon May 24 15:34:14 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9577D3A6D28 for ; Mon, 24 May 2010 15:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.67 X-Spam-Level: X-Spam-Status: No, score=0.67 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_PAST_06_12=1.069, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvO8F5vxxq1L for ; Mon, 24 May 2010 15:34:13 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id B04743A6CFB for ; Mon, 24 May 2010 15:34:11 -0700 (PDT) Received: from [192.168.13.99] (154.Red-88-1-185.dynamicIP.rima-tde.net [88.1.185.154]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o4OMXuWM018844 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 25 May 2010 01:34:00 +0300 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1078) From: Zach Shelby In-Reply-To: Date: Mon, 24 May 2010 18:14:43 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <355B1C46-98A8-4D4F-95B5-C011B2B81F92@sensinode.com> References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de><2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry><006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de><041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org> <007c01caf5d3$30f026f0$92d074d0$@moritz@uni-rostock.de> <3C20B7FD-CB93-43CC-83D2-3F4209CC5B84@tzi.org> <002101caf663$1c251d30$546f5790$@moritz@uni-rostock.de> To: core X-Mailer: Apple Mail (2.1078) Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 22:34:14 -0000 So what I heard people want here: 1. UDP as *the only* transport for simplicity and interoperability in = the spec (as long as we don't reinvent TCP). 2. CoAP to be transport independent as a protocol, thus allowing it to = be possibly used in other ways in the future. 3. A couple people think we might need a fragmentation feature for = responses with a payload size over the maximum.=20 4. DTLS might have complexity problems, should not be the only option = (Michael) 5. Some transport binding framework could be explored (Robert) I agree with 1 and 2, and my proposal would be to remove the = TCP-specific text and sections from the next version of CoAP. We can = make the protocol itself independent of UDP (it really already is), = however UDP must be specified for interoperability reasons. I propose we = anyways keep some text saying something like=20 "Although this document specifies CoAP over UDP, the protocol may also = be applicable over other transports such as TCP or SCTP. The = specification of such use is out of scope of this document.=20 This would at least give us a starting point. I don't see the need for = developing frameworks or negotiation of multiple bindings for CoAP, at = least not now. Regarding fragmentation, let's not jump the gun too soon here. For the = vast majority of constrained applications the 1280 byte maximum is more = than enough. For cases when it is not let's first see if it would make = sense to let the application deal with it. By the way, coap-01 has a = mistake with the 576B IPv4 maximum and 1280B IPv6 maximum. That doesn't = work for CoAP(IPv4)-CoAP(IPv6) proxying. Instead we should set both to = use the 1280 byte maximum. Regarding DTLS, we are specifying how to use it with CoAP as it is a = secure transport. I agree with Michael that DTLS may very well be too = much for many constrained devices, so we should make it clear that this = is not the only way to do security, IPSEC e.g. is equally applicable = (and probably simpler) but doesn't require any specification in the = document. A security analysis ID would be a big help for the WG..... Zach On May 18, 2010, at 4:23 PM, Oflynn, Colin wrote: > > Are there dependencies to UDP or is it only because the assumed > > infrastructure is highly constrained? >=20 > My thoughts/feeling on the issue is that CoAP should be designed with = a highly constrained environment, and as such being bound to UDP makes = it a lot simpler. >=20 > The resources which CoAP accesses SHOULD be accessible another in = another manner; most likely this is HTTP over TCP. Even though CoAP does = not map directly to HTTP, the requests are the same and thus I don't see = an issue here. Nodes which are highly constrained may only support CoAP; = larger nodes can support the full HTTP method. >=20 > Of course the whole subscription/notify method might take some changes = to make it accessible via HTTP... but thats another thread. >=20 > -Colin >=20 >=20 > -----Original Message----- > From: core-bounces@ietf.org on behalf of Guido Moritz > Sent: Tue 18/05/2010 09:21 > To: core@ietf.org > Subject: Re: [core] Core UDP vs TCP : Redux >=20 > =46rom the CORE charter: > > 4) The core CoAP functionality MUST operate well over UDP and UDP = MUST > > be implemented on CoAP Devices. There may be OPTIONAL functions in > > CoAP (e.g. delivery of larger chunks of data) which if implemented = are > > implemented over TCP. Applications which require the optional TCP > > features will limit themselves to a narrower subset of deployment > > cases. >=20 > Running over TCP would narrow application scenarios? It would be more = than > reasonable to design COAP while keeping UDP in mind. But as long as = there > are no direct dependencies of COAP itself to the transport mechanisms, = don't > restrict it. This in contrast would extend application scenarios, = because > you can use COAP also if reliable transport layer is required in the > scenario. >=20 > Are there dependencies to UDP or is it only because the assumed > infrastructure is highly constrained? >=20 > Guido >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag = von > > Carsten Bormann > > Gesendet: Montag, 17. Mai 2010 18:59 > > An: Charles Palmer > > Cc: core > > Betreff: Re: [core] Core UDP vs TCP : Redux > > > > On May 17, 2010, at 17:47, Charles Palmer wrote: > > > > > How disruptive would it be to design CoRE without reference to = TCP/UDP, > and > > also design a "reliable UDP" and use this for CoRE? > > > > I personally think CoAP needs to work with DTLS; if the WG moves in = that > > direction there will be some minimum requirement for independence = from the > > underlying protocol. > > > > However, what we expect from the underlying protocol has a big = bearing on > CoAP > > itself. > > If we expect we can always move to TCP, there will be little need to = make > CoAP > > operate on large representations with small underlying interactions. = I've > > heard a lot of pushback on assuming the availability of TCP, so far. > > > > There is also the aspect of interoperability: One of the great = properties > of > > the Web is that everybody uses the same stack, so all Web clients = and > servers > > are interoperable, with IP providing the necessary technological > diversity. > > (On the other hand, this has made it near impossible to swap in, = say, > SCTP.) > > Just standardizing CoAP without an "we expect this to run on UDP, = unless > > otherwise specified" would not achieve the same level of = interoperability. > > > > In any case, designing a reliable transport as a TCP > replacement > > and then a CoAP on top of either that or TCP is very much not what = the > charter > > suggests we are supposed to do. > > Instead, we should look at how stateless CoAP really can be made -- = I > think > > even TFTP has too much state (and thus isn't as trivial a file = transfer > > protocol as it could be). > > > > Gruesse, Carsten > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From zach@sensinode.com Mon May 24 15:37:11 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 466DC3A6B61 for ; Mon, 24 May 2010 15:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.52 X-Spam-Level: * X-Spam-Status: No, score=1.52 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_50=0.001, DATE_IN_PAST_06_12=1.069, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hioMrUNBf7zU for ; Mon, 24 May 2010 15:37:08 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 939CA3A67E5 for ; Mon, 24 May 2010 15:36:54 -0700 (PDT) Received: from [192.168.13.99] (154.Red-88-1-185.dynamicIP.rima-tde.net [88.1.185.154]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o4OMafQL018871 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 May 2010 01:36:43 +0300 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: Zach Shelby In-Reply-To: Date: Mon, 24 May 2010 18:49:34 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3602E0C6-1E2E-4164-A208-A874128325AF@sensinode.com> References: To: matthieu.vial@fr.non.schneider-electric.com X-Mailer: Apple Mail (2.1078) Cc: core Subject: Re: [core] Subscribe/Notify for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 22:37:11 -0000 (thread renamed) We have two different paths with regard to a subscribe/notify mechanism = for CoAP: 1. Use specific Subscription and Notify mechanisms for CoAP as HTTP = really does not include this concept.=20 1a) Notify as a message and SUBSCRIBE as a method. This is currently = used in coap-01.=20 1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but we = had a good list discussion about this leading to a. In practice it = doesn't make a big difference if notification is a message or method.=20 2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2.0 = proposal or GENA.=20 So far we have focused on 1 in the WG, and every now and again 2 comes = up. At least I am not convinced that we need to suffer the drawbacks of = HTTP here. Anyways 2 does not help our mapping to HTTP in reality very = much as there is no standard way of doing this over HTTP. Thus a = CoAP-HTTP proxy may end up anyways translating between multiple HTTP = frameworks depending on the application. So instead of doing a CoAP = Notify/Subscribe to Webhooks mapping, you will could end up having to do = a CoAP Webhooks to HTTP GENA mapping.=20 =46rom what I have heard so far 1 still seems like a wise choice, = although I need to look at Webhooks more deeply. In reality many = applications specify their own way of doing a push interface using REST = methods and specific payloads (ZigBee SE2.0 is such an example). That is = just fine, and might be used instead of a specific CoAP notify/subscribe = in that case. So 1 doesn't prevent the application using its own = mechanism, it just provides a native way for doing push. What do people think? Zach=20 On May 17, 2010, at 6:44 PM, matthieu.vial@fr.non.schneider-electric.com = wrote: > Hi, >=20 > My comments about the subscribe/notify mechanism of Zigbee IP. >=20 > Pros: > - Derived from the webhooks concept > - If used by CORE it will be easier to map to HTTP because it uses = only CRUD verbs. > - The subscription message is extendable and could support advanced = options (delays, increment, ...)=20 > - Only one listening port whatever the transport binding is. >=20 > Cons: > - No interoperability without well known URIs and a well defined = subscription message format (Not sure CoAP draft is the right place to = specify this). > - XML/EXI is too complex to be the required format for the default = subscription/notification mechanism. > - The notification should not require a subsequent GET to retrieve the = content. > - Subresource subscription is redundant. >=20 > Hope this could help, > Matthieu >=20 >=20 > "Charles Palmer" >=20 >=20 >=20 >=20 > "Charles Palmer" =20 > Envoy=E9 par : core-bounces@ietf.org > 15/05/2010 14:06 >=20 > > A > > "core" > > cc > > > Objet > > Re: [core] Selecting a WG document for CoAP > >=20 > Dear all >=20 > Those interested in the subscribe/notify discussion might like to look > at the draft Smart Energy Profile 2.0 Application Protocol > Specification. It is available here: > = http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicApp > licationProfile.aspx >=20 > It manages subscribe/notify by using POST. This seems to remove the = need > for SUBSCRIBE and notify. >=20 > "Imagine a host A, which exposes a resource at http{s}://A/resource = and > a second host B, which wishes to learn of changes to this resource. To > facilitate a subscription/ notification mechanism, A would expose a > resource http{s}://A/sub and B would expose a resource = http{s}://B/ntfy. > To subscribe to notifications regarding http{s}://A/resource, B would > send a POST to the address http{s}://A/sub/B containing the URI of the > resource of interest (http{s}://A/resource) and the URI of B's > notification resource (http{s}://B/ntfy). Following this subscription > step, should A wish to notify B of a change to the resource addressed = at > http{s}://A/resource, A would send a POST to the address > http{s}://B/ntfy containing the URI of the resource changed > (http{s}://A/resource) and the URI of A's subscription resource > (http{s}://A/sub/B), should A wish to change its subscription. The = host > B can then query the resource (or not) at its leisure." >=20 > Sleepy nodes are not allowed to subscribe, and must poll. >=20 > Regards - Charles Palmer=20 >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of > Angelo P. Castellani > Sent: 14 May 2010 13:14 > To: Zach Shelby > Cc: core > Subject: Re: [core] Selecting a WG document for CoAP >=20 > Zach, >=20 > thanks for the comments, but please refer to my most recent e-mail for > a more specific list of technical issues I'm pointing to. >=20 > I want to do only a little integration to what I've written there. >=20 > In my very personal opinion, to maximize adherence with the REST model > and minimize implementation effort SUBSCRIBE and NOTIFY should be > mapped to methods (as discussed many times together...). >=20 > Uniform interface principle (Fielding PhD dissertation Section 5.1.5, > "The central feature that distinguishes the REST architectural style > [...]") states that to simplify the software architecture, resource > interfaces/interfaces should be as general as possible. >=20 > I agree with this principle in this specific case, mainly because > handling a special message type for notify leads node software design > to a more complex architecture. >=20 > The reason is that this new message type requires special handling and > introduces a complexity in the software modularization. >=20 > Best, > Angelo >=20 > On Fri, May 14, 2010 at 13:06, Zach Shelby wrote: > > Hi Angelo, > > > > On May 13, 2010, at 14:24 , Angelo P. Castellani wrote: > > > >> Dear C. Bormann, all, > >> > >> before deciding for the final direction, I've the following > >> observations about draft-shelby-core-coap-01 > >> > >> While I mostly share Zach's view of the protocol approach, and > >> appreciate many aspects of the proposal, there are in my opinion > still > >> some open issues that need to be at least discussed before the > current > >> document can be selected. > > > > Of course there are plenty of open issues. Remember that working = group > documents still undertake as much change and improvement as the WG > wants, so by no means is coap-01 set in stone. I would expect at least > 5-10 more revisions still along the way. Already several of your = ideas > have been integrated into coap-01, and several more are under > consideration, so it is coming along. Patience ;-) > > > >> > >> In particular, I would like to highlight the following: > >> > >> a) As it is now, it is not possible to have a straightforward > >> translation of HTTP -> CoAP and viceversa: see > >> http://www.ietf.org/mail-archive/web/core/current/msg00133.html = (this > >> impacts the scalability of the web service model too) > > > > In coap-01 the Method names are now identical to HTTP methods. The > Req/Res interaction is a direct translation. The URI hierarchy is > compatible, and the URI binary code format we are still working on > obviously. The only thing that takes some state to translate is > Subscribe/Notify. But note, Subscribe/Notify takes some state no = matter > how you do it, even with HTTP-HTTP there is no clean and easy way to > handle subscriptions. > > > >> > >> b) Moreover, CoAP's implementation is not as simple as it should = be. > >> I've investigated the implementation and some design choices (as > >> Options) are leading to very high program complexity (ROM) on a > >> MSP430-based device. > > > > This we can definitely improve, and already made several = optimizations > from -00 to -01. Here I need some very concrete proposals though. Also > remember that many things are optional, for example subscribe/notify = is > not required if you don't need it. > > > >> c) Finally when comparing HTTP message size with CoAP message size, > >> the resulting compression isn't as good as you may expect. > >> > >> Example: > >> HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B > >> CoAP: 24 B with options parsing procedure requiring an added > >> implementation complexity > > > > Right, that is not how it will work in practice. Working with a real > HTTP server that HTTP header will be more complex, and on the CoAP = side > you would chose shorter URLs. The biggest improvement possible here is > from using binary coded URLs of course. We need to look at a wider = range > of interactions and real HTTP headers as well to check that we are > efficient enough. > > > >> Addressing all these points potentially leads to major technical > >> modifications (especially point a) on the current draft, hence it = is > >> appropriate in my opinion to discuss these points before making the > >> final decision. > > > > I am not sure what else you have in mind for a). If we just forget > about Subscribe/Notify then you are good to go. But then you are also > not fulfilling the charter or the industry needs in that respect. > > > > Thanks, > > Zach > > > >> > >> Best regards, > >> > >> Angelo P. Castellani > >> > >> > >> On Mon, May 10, 2010 at 18:51, Carsten Bormann = wrote: > >>> The CORE WG has a milestone to select a WG document for CoAP in > April: > >>> > >>> http://datatracker.ietf.org/wg/core/charter/ > >>> ... > >>> Apr 2010 Select WG document for basis of the CoAP protocol > >>> > >>> Of the various documents that have been contributed, > draft-shelby-core-coap has significant discussion, as well as the > largest number of updates (including a previous version that was still > called -6lowapp-coap). > >>> > >>> Today, another updated version of that draft was announced. See > >>> http://www.ietf.org/mail-archive/web/core/current/msg00138.html > >>> for the announcement and > >>> http://tools.ietf.org/html/draft-shelby-core-coap-01 > >>> for the draft itself. > >>> > >>> However, as the authors say, there are still significant TODOs. > >>> > >>> Are we in a state yet where we can say whether this is the right > direction for the WG to take? > >>> If yes, is it the right direction? Should we adopt it as a WG > document? > >>> If you don't think we can say yet, is there a set of technical > decisions you would like the authors to take with priority? > >>> > >>> Note that once a document has become a WG document, the authors = act > as editors for the working group, making (and usually fleshing out the > details of) any change that the WG decides it needs. > >>> If you think we can still improve the draft, this is not an = obstacle > to making it a WG document. > >>> But of course we shouldn't do that if we intend to reverse its > fundamental technical direction. > >>> > >>> In order to stay roughly in sync with our milestones, we should > reach at a decision on how to go forward this week. > >>> > >>> Gruesse, Carsten > >>> > >>> _______________________________________________ > >>> core mailing list > >>> core@ietf.org > >>> https://www.ietf.org/mailman/listinfo/core > >>> > >> _______________________________________________ > >> core mailing list > >> core@ietf.org > >> https://www.ietf.org/mailman/listinfo/core > > > > -- > > Zach Shelby, Chief Nerd, Sensinode Ltd. > > http://zachshelby.org - My blog "On the Internet of Things" > > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded = Internet" > > Mobile: +358 40 7796297 > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 > -------------------------------- > Onzo is a limited company number 06097997 registered in England & = Wales. The =20 > registered office is 6 Great Newport Street, London, WC2H 7JB, United = Kingdom. >=20 > This email message may contain confidential and/or privileged = information, and > is intended solely for the addressee(s). If you have received this = email in =20 > error, please notify Onzo immediately. Unauthorised copying, = disclosure or=20 > distribution of the material in this email is forbidden. > -------------------------------- >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > ______________________________________________________________________ >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From paduffy@cisco.com Mon May 24 19:48:17 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C16483A68B9 for ; Mon, 24 May 2010 19:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhyU6VUjOabY for ; Mon, 24 May 2010 19:48:15 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 4C8F43A6846 for ; Mon, 24 May 2010 19:48:15 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD/X+ktAZnwM/2dsb2JhbACdenGjfYFrCwGXfwKFEQQ X-IronPort-AV: E=Sophos;i="4.53,295,1272844800"; d="scan'208";a="114448344" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 25 May 2010 02:48:06 +0000 Received: from [10.86.241.9] (che-vpn-cluster-1-264.cisco.com [10.86.241.9]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4P2m6wt004327; Tue, 25 May 2010 02:48:06 GMT Message-ID: <4BFB3A66.5080700@cisco.com> Date: Mon, 24 May 2010 22:48:06 -0400 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Zach Shelby References: <3602E0C6-1E2E-4164-A208-A874128325AF@sensinode.com> In-Reply-To: <3602E0C6-1E2E-4164-A208-A874128325AF@sensinode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: core Subject: Re: [core] Subscribe/Notify for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 02:48:17 -0000 Recommend something like #2, primarily to avoid introducing non HTTP method semantics, simplifying HTTP/COAP translation.gateways, etc. On 5/24/2010 11:49 AM, Zach Shelby wrote: > (thread renamed) > > We have two different paths with regard to a subscribe/notify mechanism for CoAP: > > 1. Use specific Subscription and Notify mechanisms for CoAP as HTTP really does not include this concept. > 1a) Notify as a message and SUBSCRIBE as a method. This is currently used in coap-01. > 1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but we had a good list discussion about this leading to a. In practice it doesn't make a big difference if notification is a message or method. > > 2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2.0 proposal or GENA. > > So far we have focused on 1 in the WG, and every now and again 2 comes up. At least I am not convinced that we need to suffer the drawbacks of HTTP here. Anyways 2 does not help our mapping to HTTP in reality very much as there is no standard way of doing this over HTTP. Thus a CoAP-HTTP proxy may end up anyways translating between multiple HTTP frameworks depending on the application. So instead of doing a CoAP Notify/Subscribe to Webhooks mapping, you will could end up having to do a CoAP Webhooks to HTTP GENA mapping. > I don't understand this last para. If CoAP sticks to the semantics of the current HTTP methods, would this not offer a fairly straightforward translation to/from HTTP? > > From what I have heard so far 1 still seems like a wise choice, although I need to look at Webhooks more deeply. In reality many applications specify their own way of doing a push interface using REST methods and specific payloads (ZigBee SE2.0 is such an example). That is just fine, and might be used instead of a specific CoAP notify/subscribe in that case. So 1 doesn't prevent the application using its own mechanism, it just provides a native way for doing push. > > What do people think? > > Zach > > On May 17, 2010, at 6:44 PM, matthieu.vial@fr.non.schneider-electric.com wrote: > > >> Hi, >> >> My comments about the subscribe/notify mechanism of Zigbee IP. >> >> Pros: >> - Derived from the webhooks concept >> - If used by CORE it will be easier to map to HTTP because it uses only CRUD verbs. >> - The subscription message is extendable and could support advanced options (delays, increment, ...) >> - Only one listening port whatever the transport binding is. >> >> Cons: >> - No interoperability without well known URIs and a well defined subscription message format (Not sure CoAP draft is the right place to specify this). >> - XML/EXI is too complex to be the required format for the default subscription/notification mechanism. >> - The notification should not require a subsequent GET to retrieve the content. >> - Subresource subscription is redundant. >> >> Hope this could help, >> Matthieu >> >> >> "Charles Palmer" >> >> >> >> >> "Charles Palmer" >> Envoyé par : core-bounces@ietf.org >> 15/05/2010 14:06 >> >> >> A >> >> "core" >> >> cc >> >> >> Objet >> >> Re: [core] Selecting a WG document for CoAP >> >> >> Dear all >> >> Those interested in the subscribe/notify discussion might like to look >> at the draft Smart Energy Profile 2.0 Application Protocol >> Specification. It is available here: >> http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicApp >> licationProfile.aspx >> >> It manages subscribe/notify by using POST. This seems to remove the need >> for SUBSCRIBE and notify. >> >> "Imagine a host A, which exposes a resource at http{s}://A/resource and >> a second host B, which wishes to learn of changes to this resource. To >> facilitate a subscription/ notification mechanism, A would expose a >> resource http{s}://A/sub and B would expose a resource http{s}://B/ntfy. >> To subscribe to notifications regarding http{s}://A/resource, B would >> send a POST to the address http{s}://A/sub/B containing the URI of the >> resource of interest (http{s}://A/resource) and the URI of B's >> notification resource (http{s}://B/ntfy). Following this subscription >> step, should A wish to notify B of a change to the resource addressed at >> http{s}://A/resource, A would send a POST to the address >> http{s}://B/ntfy containing the URI of the resource changed >> (http{s}://A/resource) and the URI of A's subscription resource >> (http{s}://A/sub/B), should A wish to change its subscription. The host >> B can then query the resource (or not) at its leisure." >> >> Sleepy nodes are not allowed to subscribe, and must poll. >> >> Regards - Charles Palmer >> >> -----Original Message----- >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of >> Angelo P. Castellani >> Sent: 14 May 2010 13:14 >> To: Zach Shelby >> Cc: core >> Subject: Re: [core] Selecting a WG document for CoAP >> >> Zach, >> >> thanks for the comments, but please refer to my most recent e-mail for >> a more specific list of technical issues I'm pointing to. >> >> I want to do only a little integration to what I've written there. >> >> In my very personal opinion, to maximize adherence with the REST model >> and minimize implementation effort SUBSCRIBE and NOTIFY should be >> mapped to methods (as discussed many times together...). >> >> Uniform interface principle (Fielding PhD dissertation Section 5.1.5, >> "The central feature that distinguishes the REST architectural style >> [...]") states that to simplify the software architecture, resource >> interfaces/interfaces should be as general as possible. >> >> I agree with this principle in this specific case, mainly because >> handling a special message type for notify leads node software design >> to a more complex architecture. >> >> The reason is that this new message type requires special handling and >> introduces a complexity in the software modularization. >> >> Best, >> Angelo >> >> On Fri, May 14, 2010 at 13:06, Zach Shelby wrote: >> >>> Hi Angelo, >>> >>> On May 13, 2010, at 14:24 , Angelo P. Castellani wrote: >>> >>> >>>> Dear C. Bormann, all, >>>> >>>> before deciding for the final direction, I've the following >>>> observations about draft-shelby-core-coap-01 >>>> >>>> While I mostly share Zach's view of the protocol approach, and >>>> appreciate many aspects of the proposal, there are in my opinion >>>> >> still >> >>>> some open issues that need to be at least discussed before the >>>> >> current >> >>>> document can be selected. >>>> >>> Of course there are plenty of open issues. Remember that working group >>> >> documents still undertake as much change and improvement as the WG >> wants, so by no means is coap-01 set in stone. I would expect at least >> 5-10 more revisions still along the way. Already several of your ideas >> have been integrated into coap-01, and several more are under >> consideration, so it is coming along. Patience ;-) >> >>> >>>> In particular, I would like to highlight the following: >>>> >>>> a) As it is now, it is not possible to have a straightforward >>>> translation of HTTP -> CoAP and viceversa: see >>>> http://www.ietf.org/mail-archive/web/core/current/msg00133.html (this >>>> impacts the scalability of the web service model too) >>>> >>> In coap-01 the Method names are now identical to HTTP methods. The >>> >> Req/Res interaction is a direct translation. The URI hierarchy is >> compatible, and the URI binary code format we are still working on >> obviously. The only thing that takes some state to translate is >> Subscribe/Notify. But note, Subscribe/Notify takes some state no matter >> how you do it, even with HTTP-HTTP there is no clean and easy way to >> handle subscriptions. >> >>> >>>> b) Moreover, CoAP's implementation is not as simple as it should be. >>>> I've investigated the implementation and some design choices (as >>>> Options) are leading to very high program complexity (ROM) on a >>>> MSP430-based device. >>>> >>> This we can definitely improve, and already made several optimizations >>> >> from -00 to -01. Here I need some very concrete proposals though. Also >> remember that many things are optional, for example subscribe/notify is >> not required if you don't need it. >> >>> >>>> c) Finally when comparing HTTP message size with CoAP message size, >>>> the resulting compression isn't as good as you may expect. >>>> >>>> Example: >>>> HTTP: GET /sensor/temp.xml HTTP/1.0 = 32 B >>>> CoAP: 24 B with options parsing procedure requiring an added >>>> implementation complexity >>>> >>> Right, that is not how it will work in practice. Working with a real >>> >> HTTP server that HTTP header will be more complex, and on the CoAP side >> you would chose shorter URLs. The biggest improvement possible here is >> from using binary coded URLs of course. We need to look at a wider range >> of interactions and real HTTP headers as well to check that we are >> efficient enough. >> >>> >>>> Addressing all these points potentially leads to major technical >>>> modifications (especially point a) on the current draft, hence it is >>>> appropriate in my opinion to discuss these points before making the >>>> final decision. >>>> >>> I am not sure what else you have in mind for a). If we just forget >>> >> about Subscribe/Notify then you are good to go. But then you are also >> not fulfilling the charter or the industry needs in that respect. >> >>> Thanks, >>> Zach >>> >>> >>>> Best regards, >>>> >>>> Angelo P. Castellani >>>> >>>> >>>> On Mon, May 10, 2010 at 18:51, Carsten Bormann wrote: >>>> >>>>> The CORE WG has a milestone to select a WG document for CoAP in >>>>> >> April: >> >>>>> http://datatracker.ietf.org/wg/core/charter/ >>>>> ... >>>>> Apr 2010 Select WG document for basis of the CoAP protocol >>>>> >>>>> Of the various documents that have been contributed, >>>>> >> draft-shelby-core-coap has significant discussion, as well as the >> largest number of updates (including a previous version that was still >> called -6lowapp-coap). >> >>>>> Today, another updated version of that draft was announced. See >>>>> http://www.ietf.org/mail-archive/web/core/current/msg00138.html >>>>> for the announcement and >>>>> http://tools.ietf.org/html/draft-shelby-core-coap-01 >>>>> for the draft itself. >>>>> >>>>> However, as the authors say, there are still significant TODOs. >>>>> >>>>> Are we in a state yet where we can say whether this is the right >>>>> >> direction for the WG to take? >> >>>>> If yes, is it the right direction? Should we adopt it as a WG >>>>> >> document? >> >>>>> If you don't think we can say yet, is there a set of technical >>>>> >> decisions you would like the authors to take with priority? >> >>>>> Note that once a document has become a WG document, the authors act >>>>> >> as editors for the working group, making (and usually fleshing out the >> details of) any change that the WG decides it needs. >> >>>>> If you think we can still improve the draft, this is not an obstacle >>>>> >> to making it a WG document. >> >>>>> But of course we shouldn't do that if we intend to reverse its >>>>> >> fundamental technical direction. >> >>>>> In order to stay roughly in sync with our milestones, we should >>>>> >> reach at a decision on how to go forward this week. >> >>>>> Gruesse, Carsten >>>>> >>>>> _______________________________________________ >>>>> core mailing list >>>>> core@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/core >>>>> >>>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>> >>> -- >>> Zach Shelby, Chief Nerd, Sensinode Ltd. >>> http://zachshelby.org - My blog "On the Internet of Things" >>> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" >>> Mobile: +358 40 7796297 >>> >>> >>> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> -------------------------------- >> Onzo is a limited company number 06097997 registered in England& Wales. The >> registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingdom. >> >> This email message may contain confidential and/or privileged information, and >> is intended solely for the addressee(s). If you have received this email in >> error, please notify Onzo immediately. Unauthorised copying, disclosure or >> distribution of the material in this email is forbidden. >> -------------------------------- >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> ______________________________________________________________________ >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> > From paduffy@cisco.com Mon May 24 20:08:27 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EC1C3A7180 for ; Mon, 24 May 2010 20:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_50=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mf+JY3EPaaw for ; Mon, 24 May 2010 20:08:25 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 54D433A717C for ; Mon, 24 May 2010 20:07:10 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAP/a+ktAZnwN/2dsb2JhbACdenGjbYFrCwGYAoUTBA X-IronPort-AV: E=Sophos;i="4.53,295,1272844800"; d="scan'208";a="114318689" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 25 May 2010 03:07:01 +0000 Received: from [10.86.241.9] (che-vpn-cluster-1-264.cisco.com [10.86.241.9]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4P371xN005660; Tue, 25 May 2010 03:07:01 GMT Message-ID: <4BFB3ED5.5010101@cisco.com> Date: Mon, 24 May 2010 23:07:01 -0400 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Zach Shelby References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de><2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry><006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de><041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org> <007c01caf5d3$30f026f0$92d074d0$@moritz@uni-rostock.de> <3C20B7FD-CB93-43CC-83D2-3F4209CC5B84@tzi.org> <002101caf663$1c251d30$546f5790$@moritz@uni-rostock.de> <355B1C46-98A8-4D4F-95B5-C011B2B81F92@sensinode.com> In-Reply-To: <355B1C46-98A8-4D4F-95B5-C011B2B81F92@sensinode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: core Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 03:08:27 -0000 IMO any decision pro/con DTLS is premature. Use of DTLS is desirable as it "goes with the grain" of HTTP usage patterns. I believe the DTLS concerns revolve around how long a session can be kept alive. Or alternatively, over how long a period of time can I amortize/cache session information for a single (expensive) key establishment handshake. Yes, we need security expertise to answer this question. On 5/24/2010 11:14 AM, Zach Shelby wrote: > So what I heard people want here: > > 1. UDP as *the only* transport for simplicity and interoperability in the spec (as long as we don't reinvent TCP). > 2. CoAP to be transport independent as a protocol, thus allowing it to be possibly used in other ways in the future. > 3. A couple people think we might need a fragmentation feature for responses with a payload size over the maximum. > 4. DTLS might have complexity problems, should not be the only option (Michael) > 5. Some transport binding framework could be explored (Robert) > > I agree with 1 and 2, and my proposal would be to remove the TCP-specific text and sections from the next version of CoAP. We can make the protocol itself independent of UDP (it really already is), however UDP must be specified for interoperability reasons. I propose we anyways keep some text saying something like > > "Although this document specifies CoAP over UDP, the protocol may also be applicable over other transports such as TCP or SCTP. The specification of such use is out of scope of this document. > > This would at least give us a starting point. I don't see the need for developing frameworks or negotiation of multiple bindings for CoAP, at least not now. > > Regarding fragmentation, let's not jump the gun too soon here. For the vast majority of constrained applications the 1280 byte maximum is more than enough. For cases when it is not let's first see if it would make sense to let the application deal with it. By the way, coap-01 has a mistake with the 576B IPv4 maximum and 1280B IPv6 maximum. That doesn't work for CoAP(IPv4)-CoAP(IPv6) proxying. Instead we should set both to use the 1280 byte maximum. > > Regarding DTLS, we are specifying how to use it with CoAP as it is a secure transport. I agree with Michael that DTLS may very well be too much for many constrained devices, so we should make it clear that this is not the only way to do security, IPSEC e.g. is equally applicable (and probably simpler) but doesn't require any specification in the document. A security analysis ID would be a big help for the WG..... > > Zach > > On May 18, 2010, at 4:23 PM, Oflynn, Colin wrote: > > >>> Are there dependencies to UDP or is it only because the assumed >>> infrastructure is highly constrained? >>> >> My thoughts/feeling on the issue is that CoAP should be designed with a highly constrained environment, and as such being bound to UDP makes it a lot simpler. >> >> The resources which CoAP accesses SHOULD be accessible another in another manner; most likely this is HTTP over TCP. Even though CoAP does not map directly to HTTP, the requests are the same and thus I don't see an issue here. Nodes which are highly constrained may only support CoAP; larger nodes can support the full HTTP method. >> >> Of course the whole subscription/notify method might take some changes to make it accessible via HTTP... but thats another thread. >> >> -Colin >> >> >> -----Original Message----- >> From: core-bounces@ietf.org on behalf of Guido Moritz >> Sent: Tue 18/05/2010 09:21 >> To: core@ietf.org >> Subject: Re: [core] Core UDP vs TCP : Redux >> >> From the CORE charter: >> >>> 4) The core CoAP functionality MUST operate well over UDP and UDP MUST >>> be implemented on CoAP Devices. There may be OPTIONAL functions in >>> CoAP (e.g. delivery of larger chunks of data) which if implemented are >>> implemented over TCP. Applications which require the optional TCP >>> features will limit themselves to a narrower subset of deployment >>> cases. >>> >> Running over TCP would narrow application scenarios? It would be more than >> reasonable to design COAP while keeping UDP in mind. But as long as there >> are no direct dependencies of COAP itself to the transport mechanisms, don't >> restrict it. This in contrast would extend application scenarios, because >> you can use COAP also if reliable transport layer is required in the >> scenario. >> >> Are there dependencies to UDP or is it only because the assumed >> infrastructure is highly constrained? >> >> Guido >> >> >>> -----Ursprüngliche Nachricht----- >>> Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag von >>> Carsten Bormann >>> Gesendet: Montag, 17. Mai 2010 18:59 >>> An: Charles Palmer >>> Cc: core >>> Betreff: Re: [core] Core UDP vs TCP : Redux >>> >>> On May 17, 2010, at 17:47, Charles Palmer wrote: >>> >>> >>>> How disruptive would it be to design CoRE without reference to TCP/UDP, >>>> >> and >> >>> also design a "reliable UDP" and use this for CoRE? >>> >>> I personally think CoAP needs to work with DTLS; if the WG moves in that >>> direction there will be some minimum requirement for independence from the >>> underlying protocol. >>> >>> However, what we expect from the underlying protocol has a big bearing on >>> >> CoAP >> >>> itself. >>> If we expect we can always move to TCP, there will be little need to make >>> >> CoAP >> >>> operate on large representations with small underlying interactions. I've >>> heard a lot of pushback on assuming the availability of TCP, so far. >>> >>> There is also the aspect of interoperability: One of the great properties >>> >> of >> >>> the Web is that everybody uses the same stack, so all Web clients and >>> >> servers >> >>> are interoperable, with IP providing the necessary technological >>> >> diversity. >> >>> (On the other hand, this has made it near impossible to swap in, say, >>> >> SCTP.) >> >>> Just standardizing CoAP without an "we expect this to run on UDP, unless >>> otherwise specified" would not achieve the same level of interoperability. >>> >>> In any case, designing a reliable transport as a TCP >>> >> replacement >> >>> and then a CoAP on top of either that or TCP is very much not what the >>> >> charter >> >>> suggests we are supposed to do. >>> Instead, we should look at how stateless CoAP really can be made -- I >>> >> think >> >>> even TFTP has too much state (and thus isn't as trivial a file transfer >>> protocol as it could be). >>> >>> Gruesse, Carsten >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> > From therbst@silverspringnet.com Mon May 24 23:23:39 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D003A6877 for ; Mon, 24 May 2010 23:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.635 X-Spam-Level: X-Spam-Status: No, score=0.635 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jo4i5CWK9gvG for ; Mon, 24 May 2010 23:23:37 -0700 (PDT) Received: from bachelor.silverspringnet.com (bachelor.silverspringnet.com [69.36.245.73]) by core3.amsl.com (Postfix) with ESMTP id C6BCD3A6823 for ; Mon, 24 May 2010 23:23:37 -0700 (PDT) Received: from IT-EXCA-02.silverspringnet.com ([10.200.1.62]) by bachelor.silverspringnet.com (8.14.1/8.13.8) with ESMTP id o4P6N74Y022546; Mon, 24 May 2010 23:23:07 -0700 (PDT) Received: from IT-EXMB-01.silverspringnet.com ([fe80::b81e:2d5b:d263:6c44]) by IT-EXCA-02.silverspringnet.com ([::1]) with mapi; Mon, 24 May 2010 23:23:06 -0700 From: Thomas Herbst To: Zach Shelby , core Date: Mon, 24 May 2010 23:18:25 -0700 Thread-Topic: [core] Core UDP vs TCP : Redux Thread-Index: Acr7kUF74doNKJTvR3Kzy47+DbTxQwAQNPaG Message-ID: <485AF6ECE8D1954D996771CC49E996FDC0A8A4F4@IT-EXMB-01.silverspringnet.com> References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de><2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry><006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de><041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org> <007c01caf5d3$30f026f0$92d074d0$@moritz@uni-rostock.de> <3C20B7FD-CB93-43CC-83D2-3F4209CC5B84@tzi.org> <002101caf663$1c251d30$546f5790$@moritz@uni-rostock.de> , <355B1C46-98A8-4D4F-95B5-C011B2B81F92@sensinode.com> In-Reply-To: <355B1C46-98A8-4D4F-95B5-C011B2B81F92@sensinode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 06:23:39 -0000 IMHO, 1& 2 move the document forward significantly. For 3, fragmentation being an exercise for the user seems okay.=20 DTLS may well need more thought.=20 ________________________________________ From: core-bounces@ietf.org [core-bounces@ietf.org] On Behalf Of Zach Shelb= y [zach@sensinode.com] Sent: Monday, May 24, 2010 8:14 AM To: core Subject: Re: [core] Core UDP vs TCP : Redux So what I heard people want here: 1. UDP as *the only* transport for simplicity and interoperability in the s= pec (as long as we don't reinvent TCP). 2. CoAP to be transport independent as a protocol, thus allowing it to be p= ossibly used in other ways in the future. 3. A couple people think we might need a fragmentation feature for response= s with a payload size over the maximum. 4. DTLS might have complexity problems, should not be the only option (Mich= ael) 5. Some transport binding framework could be explored (Robert) I agree with 1 and 2, and my proposal would be to remove the TCP-specific t= ext and sections from the next version of CoAP. We can make the protocol it= self independent of UDP (it really already is), however UDP must be specifi= ed for interoperability reasons. I propose we anyways keep some text saying= something like "Although this document specifies CoAP over UDP, the protocol may also be a= pplicable over other transports such as TCP or SCTP. The specification of s= uch use is out of scope of this document. This would at least give us a starting point. I don't see the need for deve= loping frameworks or negotiation of multiple bindings for CoAP, at least no= t now. Regarding fragmentation, let's not jump the gun too soon here. For the vast= majority of constrained applications the 1280 byte maximum is more than en= ough. For cases when it is not let's first see if it would make sense to le= t the application deal with it. By the way, coap-01 has a mistake with the = 576B IPv4 maximum and 1280B IPv6 maximum. That doesn't work for CoAP(IPv4)-= CoAP(IPv6) proxying. Instead we should set both to use the 1280 byte maximu= m. Regarding DTLS, we are specifying how to use it with CoAP as it is a secure= transport. I agree with Michael that DTLS may very well be too much for ma= ny constrained devices, so we should make it clear that this is not the onl= y way to do security, IPSEC e.g. is equally applicable (and probably simple= r) but doesn't require any specification in the document. A security analys= is ID would be a big help for the WG..... Zach On May 18, 2010, at 4:23 PM, Oflynn, Colin wrote: > > Are there dependencies to UDP or is it only because the assumed > > infrastructure is highly constrained? > > My thoughts/feeling on the issue is that CoAP should be designed with a h= ighly constrained environment, and as such being bound to UDP makes it a lo= t simpler. > > The resources which CoAP accesses SHOULD be accessible another in another= manner; most likely this is HTTP over TCP. Even though CoAP does not map d= irectly to HTTP, the requests are the same and thus I don't see an issue he= re. Nodes which are highly constrained may only support CoAP; larger nodes = can support the full HTTP method. > > Of course the whole subscription/notify method might take some changes to= make it accessible via HTTP... but thats another thread. > > -Colin > > > -----Original Message----- > From: core-bounces@ietf.org on behalf of Guido Moritz > Sent: Tue 18/05/2010 09:21 > To: core@ietf.org > Subject: Re: [core] Core UDP vs TCP : Redux > > From the CORE charter: > > 4) The core CoAP functionality MUST operate well over UDP and UDP MUST > > be implemented on CoAP Devices. There may be OPTIONAL functions in > > CoAP (e.g. delivery of larger chunks of data) which if implemented are > > implemented over TCP. Applications which require the optional TCP > > features will limit themselves to a narrower subset of deployment > > cases. > > Running over TCP would narrow application scenarios? It would be more tha= n > reasonable to design COAP while keeping UDP in mind. But as long as there > are no direct dependencies of COAP itself to the transport mechanisms, do= n't > restrict it. This in contrast would extend application scenarios, because > you can use COAP also if reliable transport layer is required in the > scenario. > > Are there dependencies to UDP or is it only because the assumed > infrastructure is highly constrained? > > Guido > > > -----Urspr=FCngliche Nachricht----- > > Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag vo= n > > Carsten Bormann > > Gesendet: Montag, 17. Mai 2010 18:59 > > An: Charles Palmer > > Cc: core > > Betreff: Re: [core] Core UDP vs TCP : Redux > > > > On May 17, 2010, at 17:47, Charles Palmer wrote: > > > > > How disruptive would it be to design CoRE without reference to TCP/UD= P, > and > > also design a "reliable UDP" and use this for CoRE? > > > > I personally think CoAP needs to work with DTLS; if the WG moves in tha= t > > direction there will be some minimum requirement for independence from = the > > underlying protocol. > > > > However, what we expect from the underlying protocol has a big bearing = on > CoAP > > itself. > > If we expect we can always move to TCP, there will be little need to ma= ke > CoAP > > operate on large representations with small underlying interactions. I= 've > > heard a lot of pushback on assuming the availability of TCP, so far. > > > > There is also the aspect of interoperability: One of the great propert= ies > of > > the Web is that everybody uses the same stack, so all Web clients and > servers > > are interoperable, with IP providing the necessary technological > diversity. > > (On the other hand, this has made it near impossible to swap in, say, > SCTP.) > > Just standardizing CoAP without an "we expect this to run on UDP, unles= s > > otherwise specified" would not achieve the same level of interoperabili= ty. > > > > In any case, designing a reliable transport as a TCP > replacement > > and then a CoAP on top of either that or TCP is very much not what the > charter > > suggests we are supposed to do. > > Instead, we should look at how stateless CoAP really can be made -- I > think > > even TFTP has too much state (and thus isn't as trivial a file transfer > > protocol as it could be). > > > > Gruesse, Carsten > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From Colin.OFlynn@atmel.com Tue May 25 01:38:07 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C78E3A6D42 for ; Tue, 25 May 2010 01:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.097 X-Spam-Level: X-Spam-Status: No, score=-0.097 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdhpJS8vfuQa for ; Tue, 25 May 2010 01:38:05 -0700 (PDT) Received: from sjogate2.atmel.com (newsmtp5.atmel.com [204.2.163.5]) by core3.amsl.com (Postfix) with ESMTP id 3C8983A6917 for ; Tue, 25 May 2010 01:38:05 -0700 (PDT) Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id o4P8ZciL001471; Tue, 25 May 2010 01:35:39 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAFBE5.85945FD9" Date: Tue, 25 May 2010 02:37:34 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Core UDP vs TCP : Redux Thread-Index: Acr7kUF74doNKJTvR3Kzy47+DbTxQwAQNPaGAASgwCM= References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com><17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de><2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry><006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de><041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org><007c01caf5d3$30f026f0$92d074d0$@moritz@uni-rostock.de><3C20B7FD-CB93-43CC-83D2-3F4209CC5B84@tzi.org><002101caf663$1c251d30$546f5790$@moritz@uni-rostock.de>, <355B1C46-98A8-4D4F-95B5-C011B2B81F92@sensinode.com> <485AF6ECE8D1954D996771CC49E996FDC0A8A4F4@IT-EXMB-01.silverspringnet.com> From: "Oflynn, Colin" To: "Thomas Herbst" , "Zach Shelby" , "core" Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 08:38:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAFBE5.85945FD9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I think 3 (fragmentation) should still be included in CoAP if we are = proposing UDP. The main feature I'm thinking of is firmware updates = which would need larger responses. Again the fragmentation can be very simple (TFTP style), and if the user = requires anything more advanced it is their responsibility. However = leaving it to "users" probably means "not interpolatable", since then = their is basically different responses depending on the file size. Regards, -Colin -----Original Message----- From: core-bounces@ietf.org on behalf of Thomas Herbst Sent: Tue 25/05/2010 07:18 To: Zach Shelby; core Subject: Re: [core] Core UDP vs TCP : Redux =20 IMHO, 1& 2 move the document forward significantly. For 3, fragmentation being an exercise for the user seems okay.=20 DTLS may well need more thought.=20 ________________________________________ From: core-bounces@ietf.org [core-bounces@ietf.org] On Behalf Of Zach = Shelby [zach@sensinode.com] Sent: Monday, May 24, 2010 8:14 AM To: core Subject: Re: [core] Core UDP vs TCP : Redux So what I heard people want here: 1. UDP as *the only* transport for simplicity and interoperability in = the spec (as long as we don't reinvent TCP). 2. CoAP to be transport independent as a protocol, thus allowing it to = be possibly used in other ways in the future. 3. A couple people think we might need a fragmentation feature for = responses with a payload size over the maximum. 4. DTLS might have complexity problems, should not be the only option = (Michael) 5. Some transport binding framework could be explored (Robert) I agree with 1 and 2, and my proposal would be to remove the = TCP-specific text and sections from the next version of CoAP. We can = make the protocol itself independent of UDP (it really already is), = however UDP must be specified for interoperability reasons. I propose we = anyways keep some text saying something like "Although this document specifies CoAP over UDP, the protocol may also = be applicable over other transports such as TCP or SCTP. The = specification of such use is out of scope of this document. This would at least give us a starting point. I don't see the need for = developing frameworks or negotiation of multiple bindings for CoAP, at = least not now. Regarding fragmentation, let's not jump the gun too soon here. For the = vast majority of constrained applications the 1280 byte maximum is more = than enough. For cases when it is not let's first see if it would make = sense to let the application deal with it. By the way, coap-01 has a = mistake with the 576B IPv4 maximum and 1280B IPv6 maximum. That doesn't = work for CoAP(IPv4)-CoAP(IPv6) proxying. Instead we should set both to = use the 1280 byte maximum. Regarding DTLS, we are specifying how to use it with CoAP as it is a = secure transport. I agree with Michael that DTLS may very well be too = much for many constrained devices, so we should make it clear that this = is not the only way to do security, IPSEC e.g. is equally applicable = (and probably simpler) but doesn't require any specification in the = document. A security analysis ID would be a big help for the WG..... Zach On May 18, 2010, at 4:23 PM, Oflynn, Colin wrote: > > Are there dependencies to UDP or is it only because the assumed > > infrastructure is highly constrained? > > My thoughts/feeling on the issue is that CoAP should be designed with = a highly constrained environment, and as such being bound to UDP makes = it a lot simpler. > > The resources which CoAP accesses SHOULD be accessible another in = another manner; most likely this is HTTP over TCP. Even though CoAP does = not map directly to HTTP, the requests are the same and thus I don't see = an issue here. Nodes which are highly constrained may only support CoAP; = larger nodes can support the full HTTP method. > > Of course the whole subscription/notify method might take some changes = to make it accessible via HTTP... but thats another thread. > > -Colin > > > -----Original Message----- > From: core-bounces@ietf.org on behalf of Guido Moritz > Sent: Tue 18/05/2010 09:21 > To: core@ietf.org > Subject: Re: [core] Core UDP vs TCP : Redux > > From the CORE charter: > > 4) The core CoAP functionality MUST operate well over UDP and UDP = MUST > > be implemented on CoAP Devices. There may be OPTIONAL functions in > > CoAP (e.g. delivery of larger chunks of data) which if implemented = are > > implemented over TCP. Applications which require the optional TCP > > features will limit themselves to a narrower subset of deployment > > cases. > > Running over TCP would narrow application scenarios? It would be more = than > reasonable to design COAP while keeping UDP in mind. But as long as = there > are no direct dependencies of COAP itself to the transport mechanisms, = don't > restrict it. This in contrast would extend application scenarios, = because > you can use COAP also if reliable transport layer is required in the > scenario. > > Are there dependencies to UDP or is it only because the assumed > infrastructure is highly constrained? > > Guido > > > -----Urspr=FCngliche Nachricht----- > > Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag = von > > Carsten Bormann > > Gesendet: Montag, 17. Mai 2010 18:59 > > An: Charles Palmer > > Cc: core > > Betreff: Re: [core] Core UDP vs TCP : Redux > > > > On May 17, 2010, at 17:47, Charles Palmer wrote: > > > > > How disruptive would it be to design CoRE without reference to = TCP/UDP, > and > > also design a "reliable UDP" and use this for CoRE? > > > > I personally think CoAP needs to work with DTLS; if the WG moves in = that > > direction there will be some minimum requirement for independence = from the > > underlying protocol. > > > > However, what we expect from the underlying protocol has a big = bearing on > CoAP > > itself. > > If we expect we can always move to TCP, there will be little need to = make > CoAP > > operate on large representations with small underlying interactions. = I've > > heard a lot of pushback on assuming the availability of TCP, so far. > > > > There is also the aspect of interoperability: One of the great = properties > of > > the Web is that everybody uses the same stack, so all Web clients = and > servers > > are interoperable, with IP providing the necessary technological > diversity. > > (On the other hand, this has made it near impossible to swap in, = say, > SCTP.) > > Just standardizing CoAP without an "we expect this to run on UDP, = unless > > otherwise specified" would not achieve the same level of = interoperability. > > > > In any case, designing a reliable transport as a TCP > replacement > > and then a CoAP on top of either that or TCP is very much not what = the > charter > > suggests we are supposed to do. > > Instead, we should look at how stateless CoAP really can be made -- = I > think > > even TFTP has too much state (and thus isn't as trivial a file = transfer > > protocol as it could be). > > > > Gruesse, Carsten > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------_=_NextPart_001_01CAFBE5.85945FD9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [core] Core UDP vs TCP : Redux

Hello,

I think 3 (fragmentation) should still be included in CoAP if we are = proposing UDP. The main feature I'm thinking of is firmware updates = which would need larger responses.

Again the fragmentation can be very simple (TFTP style), and if the user = requires anything more advanced it is their responsibility. However = leaving it to "users" probably means "not = interpolatable", since then their is basically different responses = depending on the file size.

Regards,

  -Colin


-----Original Message-----
From: core-bounces@ietf.org on behalf of Thomas Herbst
Sent: Tue 25/05/2010 07:18
To: Zach Shelby; core
Subject: Re: [core] Core UDP vs TCP : Redux

IMHO, 1& 2 move the document forward significantly.
For 3,  fragmentation being an exercise for the user seems = okay.

DTLS may well need more thought.

________________________________________
From: core-bounces@ietf.org [core-bounces@ietf.org] On Behalf Of Zach = Shelby [zach@sensinode.com]
Sent: Monday, May 24, 2010 8:14 AM
To: core
Subject: Re: [core] Core UDP vs TCP : Redux

So what I heard people want here:

1. UDP as *the only* transport for simplicity and interoperability in = the spec (as long as we don't reinvent TCP).
2. CoAP to be transport independent as a protocol, thus allowing it to = be possibly used in other ways in the future.
3. A couple people think we might need a fragmentation feature for = responses with a payload size over the maximum.
4. DTLS might have complexity problems, should not be the only option = (Michael)
5. Some transport binding framework could be explored (Robert)

I agree with 1 and 2, and my proposal would be to remove the = TCP-specific text and sections from the next version of CoAP. We can = make the protocol itself independent of UDP (it really already is), = however UDP must be specified for interoperability reasons. I propose we = anyways keep some text saying something like

"Although this document specifies CoAP over UDP, the protocol may = also be applicable over other transports such as TCP or SCTP. The = specification of such use is out of scope of this document.

This would at least give us a starting point. I don't see the need for = developing frameworks or negotiation of multiple bindings for CoAP, at = least not now.

Regarding fragmentation, let's not jump the gun too soon here. For the = vast majority of constrained applications the 1280 byte maximum is more = than enough. For cases when it is not let's first see if it would make = sense to let the application deal with it. By the way, coap-01 has a = mistake with the 576B IPv4 maximum and 1280B IPv6 maximum. That doesn't = work for CoAP(IPv4)-CoAP(IPv6) proxying. Instead we should set both to = use the 1280 byte maximum.

Regarding DTLS, we are specifying how to use it with CoAP as it is a = secure transport. I agree with Michael that DTLS may very well be too = much for many constrained devices, so we should make it clear that this = is not the only way to do security, IPSEC e.g. is equally applicable = (and probably simpler) but doesn't require any specification in the = document. A security analysis ID would be a big help for the WG.....

Zach

On May 18, 2010, at 4:23 PM, Oflynn, Colin wrote:

> > Are there dependencies to UDP or is it only because the = assumed
> > infrastructure is highly constrained?
>
> My thoughts/feeling on the issue is that CoAP should be designed = with a highly constrained environment, and as such being bound to UDP = makes it a lot simpler.
>
> The resources which CoAP accesses SHOULD be accessible another in = another manner; most likely this is HTTP over TCP. Even though CoAP does = not map directly to HTTP, the requests are the same and thus I don't see = an issue here. Nodes which are highly constrained may only support CoAP; = larger nodes can support the full HTTP method.
>
> Of course the whole subscription/notify method might take some = changes to make it accessible via HTTP... but thats another thread.
>
>   -Colin
>
>
> -----Original Message-----
> From: core-bounces@ietf.org on behalf of Guido Moritz
> Sent: Tue 18/05/2010 09:21
> To: core@ietf.org
> Subject: Re: [core] Core UDP vs TCP : Redux
>
> From the CORE charter:
> >  4) The core CoAP functionality MUST operate well over = UDP and UDP MUST
> >  be implemented on CoAP Devices. There may be OPTIONAL = functions in
> >  CoAP (e.g. delivery of larger chunks of data) which if = implemented are
> >  implemented over TCP. Applications which require the = optional TCP
> >  features will limit themselves to a narrower subset of = deployment
> >  cases.
>
> Running over TCP would narrow application scenarios? It would be = more than
> reasonable to design COAP while keeping UDP in mind. But as long as = there
> are no direct dependencies of COAP itself to the transport = mechanisms, don't
> restrict it. This in contrast would extend application scenarios, = because
> you can use COAP also if reliable transport layer is required in = the
> scenario.
>
> Are there dependencies to UDP or is it only because the assumed
> infrastructure is highly constrained?
>
> Guido
>
> > -----Urspr=FCngliche Nachricht-----
> > Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] = Im Auftrag von
> > Carsten Bormann
> > Gesendet: Montag, 17. Mai 2010 18:59
> > An: Charles Palmer
> > Cc: core
> > Betreff: Re: [core] Core UDP vs TCP : Redux
> >
> > On May 17, 2010, at 17:47, Charles Palmer wrote:
> >
> > > How disruptive would it be to design CoRE without = reference to TCP/UDP,
> and
> > also design a "reliable UDP" and use this for = CoRE?
> >
> > I personally think CoAP needs to work with DTLS; if the WG = moves in that
> > direction there will be some minimum requirement for = independence from the
> > underlying protocol.
> >
> > However, what we expect from the underlying protocol has a big = bearing on
> CoAP
> > itself.
> > If we expect we can always move to TCP, there will be little = need to make
> CoAP
> > operate on large representations with small underlying = interactions.  I've
> > heard a lot of pushback on assuming the availability of TCP, = so far.
> >
> > There is also the aspect of interoperability:  One of the = great properties
> of
> > the Web is that everybody uses the same stack, so all Web = clients and
> servers
> > are interoperable, with IP providing the necessary = technological
> diversity.
> > (On the other hand, this has made it near impossible to swap = in, say,
> SCTP.)
> > Just standardizing CoAP without an "we expect this to run = on UDP, unless
> > otherwise specified" would not achieve the same level of = interoperability.
> >
> > <WG chair hat>In any case, designing a reliable = transport as a TCP
> replacement
> > and then a CoAP on top of either that or TCP is very much not = what the
> charter
> > suggests we are supposed to do.</WG chair hat>
> > Instead, we should look at how stateless CoAP really can be = made -- I
> think
> > even TFTP has too much state (and thus isn't as trivial a file = transfer
> > protocol as it could be).
> >
> > Gruesse, Carsten
> >
> > _______________________________________________
> > core mailing list
> > core@ietf.org
> > https://www.ietf.org/= mailman/listinfo/core
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/= mailman/listinfo/core
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/= mailman/listinfo/core

--
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My = blog "On the Internet of Things"
http://6lowpan.net - My book = "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

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

------_=_NextPart_001_01CAFBE5.85945FD9-- From dberenguer@usapiens.com Tue May 25 05:35:35 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DF723A73F6 for ; Tue, 25 May 2010 05:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.223 X-Spam-Level: * X-Spam-Status: No, score=1.223 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAfofdazVR4d for ; Tue, 25 May 2010 05:35:34 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 4644F3A7414 for ; Tue, 25 May 2010 05:32:23 -0700 (PDT) Received: by wwe15 with SMTP id 15so432169wwe.31 for ; Tue, 25 May 2010 05:32:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.86.10 with SMTP id v10mr4595639wee.183.1274790730516; Tue, 25 May 2010 05:32:10 -0700 (PDT) Received: by 10.216.19.143 with HTTP; Tue, 25 May 2010 05:32:09 -0700 (PDT) In-Reply-To: References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry> <041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org> <3C20B7FD-CB93-43CC-83D2-3F4209CC5B84@tzi.org> <355B1C46-98A8-4D4F-95B5-C011B2B81F92@sensinode.com> <485AF6ECE8D1954D996771CC49E996FDC0A8A4F4@IT-EXMB-01.silverspringnet.com> Date: Tue, 25 May 2010 14:32:09 +0200 Message-ID: From: Daniel Berenguer To: core Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 12:35:35 -0000 Maybe I'm misunderstanding something but, is CoAP supposed to give support for firmware upgrades? Wouldn't be easier to use proprietary schemas over TCP or just TFTP over UDP for transferring large packet blocks? Why overloading a M2M protocol like CoAP with such things? I agree with Zach in that interoperability is a priority so adding a explicit note about the recommended use of CoAP over UDP would be useful. Daniel. On 25 May 2010 10:37, Oflynn, Colin wrote: > Hello, > > I think 3 (fragmentation) should still be included in CoAP if we are > proposing UDP. The main feature I'm thinking of is firmware updates which > would need larger responses. > > Again the fragmentation can be very simple (TFTP style), and if the user > requires anything more advanced it is their responsibility. However leavi= ng > it to "users" probably means "not interpolatable", since then their is > basically different responses depending on the file size. > > Regards, > > =A0 -Colin > > > -----Original Message----- > From: core-bounces@ietf.org on behalf of Thomas Herbst > Sent: Tue 25/05/2010 07:18 > To: Zach Shelby; core > Subject: Re: [core] Core UDP vs TCP : Redux > > IMHO, 1& 2 move the document forward significantly. > For 3,=A0 fragmentation being an exercise for the user seems okay. > > DTLS may well need more thought. > > ________________________________________ > From: core-bounces@ietf.org [core-bounces@ietf.org] On Behalf Of Zach She= lby > [zach@sensinode.com] > Sent: Monday, May 24, 2010 8:14 AM > To: core > Subject: Re: [core] Core UDP vs TCP : Redux > > So what I heard people want here: > > 1. UDP as *the only* transport for simplicity and interoperability in the > spec (as long as we don't reinvent TCP). > 2. CoAP to be transport independent as a protocol, thus allowing it to be > possibly used in other ways in the future. > 3. A couple people think we might need a fragmentation feature for respon= ses > with a payload size over the maximum. > 4. DTLS might have complexity problems, should not be the only option > (Michael) > 5. Some transport binding framework could be explored (Robert) > > I agree with 1 and 2, and my proposal would be to remove the TCP-specific > text and sections from the next version of CoAP. We can make the protocol > itself independent of UDP (it really already is), however UDP must be > specified for interoperability reasons. I propose we anyways keep some te= xt > saying something like > > "Although this document specifies CoAP over UDP, the protocol may also be > applicable over other transports such as TCP or SCTP. The specification o= f > such use is out of scope of this document. > > This would at least give us a starting point. I don't see the need for > developing frameworks or negotiation of multiple bindings for CoAP, at le= ast > not now. > > Regarding fragmentation, let's not jump the gun too soon here. For the va= st > majority of constrained applications the 1280 byte maximum is more than > enough. For cases when it is not let's first see if it would make sense t= o > let the application deal with it. By the way, coap-01 has a mistake with = the > 576B IPv4 maximum and 1280B IPv6 maximum. That doesn't work for > CoAP(IPv4)-CoAP(IPv6) proxying. Instead we should set both to use the 128= 0 > byte maximum. > > Regarding DTLS, we are specifying how to use it with CoAP as it is a secu= re > transport. I agree with Michael that DTLS may very well be too much for m= any > constrained devices, so we should make it clear that this is not the only > way to do security, IPSEC e.g. is equally applicable (and probably simple= r) > but doesn't require any specification in the document. A security analysi= s > ID would be a big help for the WG..... > > Zach > > On May 18, 2010, at 4:23 PM, Oflynn, Colin wrote: > >> > Are there dependencies to UDP or is it only because the assumed >> > infrastructure is highly constrained? >> >> My thoughts/feeling on the issue is that CoAP should be designed with a >> highly constrained environment, and as such being bound to UDP makes it = a >> lot simpler. >> >> The resources which CoAP accesses SHOULD be accessible another in anothe= r >> manner; most likely this is HTTP over TCP. Even though CoAP does not map >> directly to HTTP, the requests are the same and thus I don't see an issu= e >> here. Nodes which are highly constrained may only support CoAP; larger n= odes >> can support the full HTTP method. >> >> Of course the whole subscription/notify method might take some changes t= o >> make it accessible via HTTP... but thats another thread. >> >>=A0=A0 -Colin >> >> >> -----Original Message----- >> From: core-bounces@ietf.org on behalf of Guido Moritz >> Sent: Tue 18/05/2010 09:21 >> To: core@ietf.org >> Subject: Re: [core] Core UDP vs TCP : Redux >> >> From the CORE charter: >> >=A0 4) The core CoAP functionality MUST operate well over UDP and UDP M= UST >> >=A0 be implemented on CoAP Devices. There may be OPTIONAL functions in >> >=A0 CoAP (e.g. delivery of larger chunks of data) which if implemented = are >> >=A0 implemented over TCP. Applications which require the optional TCP >> >=A0 features will limit themselves to a narrower subset of deployment >> >=A0 cases. >> >> Running over TCP would narrow application scenarios? It would be more th= an >> reasonable to design COAP while keeping UDP in mind. But as long as ther= e >> are no direct dependencies of COAP itself to the transport mechanisms, >> don't >> restrict it. This in contrast would extend application scenarios, becaus= e >> you can use COAP also if reliable transport layer is required in the >> scenario. >> >> Are there dependencies to UDP or is it only because the assumed >> infrastructure is highly constrained? >> >> Guido >> >> > -----Urspr=FCngliche Nachricht----- >> > Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag v= on >> > Carsten Bormann >> > Gesendet: Montag, 17. Mai 2010 18:59 >> > An: Charles Palmer >> > Cc: core >> > Betreff: Re: [core] Core UDP vs TCP : Redux >> > >> > On May 17, 2010, at 17:47, Charles Palmer wrote: >> > >> > > How disruptive would it be to design CoRE without reference to >> > > TCP/UDP, >> and >> > also design a "reliable UDP" and use this for CoRE? >> > >> > I personally think CoAP needs to work with DTLS; if the WG moves in th= at >> > direction there will be some minimum requirement for independence from >> > the >> > underlying protocol. >> > >> > However, what we expect from the underlying protocol has a big bearing >> > on >> CoAP >> > itself. >> > If we expect we can always move to TCP, there will be little need to >> > make >> CoAP >> > operate on large representations with small underlying interactions. >> > I've >> > heard a lot of pushback on assuming the availability of TCP, so far. >> > >> > There is also the aspect of interoperability:=A0 One of the great >> > properties >> of >> > the Web is that everybody uses the same stack, so all Web clients and >> servers >> > are interoperable, with IP providing the necessary technological >> diversity. >> > (On the other hand, this has made it near impossible to swap in, say, >> SCTP.) >> > Just standardizing CoAP without an "we expect this to run on UDP, unle= ss >> > otherwise specified" would not achieve the same level of >> > interoperability. >> > >> > In any case, designing a reliable transport as a TCP >> replacement >> > and then a CoAP on top of either that or TCP is very much not what the >> charter >> > suggests we are supposed to do. >> > Instead, we should look at how stateless CoAP really can be made -- I >> think >> > even TFTP has too much state (and thus isn't as trivial a file transfe= r >> > protocol as it could be). >> > >> > Gruesse, Carsten >> > >> > _______________________________________________ >> > core mailing list >> > core@ietf.org >> > https://www.ietf.org/mailman/listinfo/core >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org=A0 - 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 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > From charles.palmer@onzo.com Tue May 25 17:28:06 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A22573A7032 for ; Tue, 25 May 2010 17:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.301 X-Spam-Level: * X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZPi48gWJDoR for ; Tue, 25 May 2010 17:28:02 -0700 (PDT) Received: from service38.mimecast.com (service38.mimecast.com [212.2.3.166]) by core3.amsl.com (Postfix) with SMTP id 6E8A83A6A7A for ; Tue, 25 May 2010 15:23:19 -0700 (PDT) Received: from onzosbs2k3.ONZO.local (217.138.5.2 [217.138.5.2]) by service38.mimecast.com; Tue, 25 May 2010 23:23:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 May 2010 23:23:03 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Subscribe/Notify for CoAP Thread-Index: Acr7tLlcZ+YHmeyiTgep+C80I8UtyQAo9kxA References: <3602E0C6-1E2E-4164-A208-A874128325AF@sensinode.com> <4BFB3A66.5080700@cisco.com> From: "Charles Palmer" To: , "Zach Shelby" X-MC-Unique: 110052523230900302 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Cc: core Subject: Re: [core] Subscribe/Notify for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 00:28:06 -0000 Hi folks=20 It occurs to me that CoRE should be keeping a close eye on ZigBee SE2.0 wor= k, so that it is as easy as possible for ZigBee SE to use CoRE when ready. = That suggests to me that we should align with their subscribe/notify proces= s. Regards - Charles=20 -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Pau= l Duffy Sent: 25 May 2010 03:48 To: Zach Shelby Cc: core Subject: Re: [core] Subscribe/Notify for CoAP Recommend something like #2, primarily to avoid introducing non HTTP=20 method semantics, simplifying HTTP/COAP translation.gateways, etc. On 5/24/2010 11:49 AM, Zach Shelby wrote: > (thread renamed) > > We have two different paths with regard to a subscribe/notify mechanism f= or CoAP: > > 1. Use specific Subscription and Notify mechanisms for CoAP as HTTP reall= y does not include this concept. > 1a) Notify as a message and SUBSCRIBE as a method. This is currently used= in coap-01. > 1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but we had= a good list discussion about this leading to a. In practice it doesn't mak= e a big difference if notification is a message or method. > > 2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2.0 prop= osal or GENA. > > So far we have focused on 1 in the WG, and every now and again 2 comes up= . At least I am not convinced that we need to suffer the drawbacks of HTTP = here. Anyways 2 does not help our mapping to HTTP in reality very much as t= here is no standard way of doing this over HTTP. Thus a CoAP-HTTP proxy may= end up anyways translating between multiple HTTP frameworks depending on t= he application. So instead of doing a CoAP Notify/Subscribe to Webhooks map= ping, you will could end up having to do a CoAP Webhooks to HTTP GENA mappi= ng. > =20 I don't understand this last para. If CoAP sticks to the semantics of=20 the current HTTP methods, would this not offer a fairly straightforward=20 translation to/from HTTP? > > From what I have heard so far 1 still seems like a wise choice, althoug= h I need to look at Webhooks more deeply. In reality many applications spec= ify their own way of doing a push interface using REST methods and specific= payloads (ZigBee SE2.0 is such an example). That is just fine, and might b= e used instead of a specific CoAP notify/subscribe in that case. So 1 doesn= 't prevent the application using its own mechanism, it just provides a nati= ve way for doing push. > > What do people think? > > Zach > > On May 17, 2010, at 6:44 PM, matthieu.vial@fr.non.schneider-electric.com = wrote: > > =20 >> Hi, >> >> My comments about the subscribe/notify mechanism of Zigbee IP. >> >> Pros: >> - Derived from the webhooks concept >> - If used by CORE it will be easier to map to HTTP because it uses only = CRUD verbs. >> - The subscription message is extendable and could support advanced opti= ons (delays, increment, ...) >> - Only one listening port whatever the transport binding is. >> >> Cons: >> - No interoperability without well known URIs and a well defined subscri= ption message format (Not sure CoAP draft is the right place to specify thi= s). >> - XML/EXI is too complex to be the required format for the default subsc= ription/notification mechanism. >> - The notification should not require a subsequent GET to retrieve the c= ontent. >> - Subresource subscription is redundant. >> >> Hope this could help, >> Matthieu >> >> >> "Charles Palmer" >> >> >> >> >> "Charles Palmer" >> Envoy=E9 par : core-bounces@ietf.org >> 15/05/2010 14:06 >> >> >> A >> >> "core" >> >> cc >> >> >> Objet >> >> Re: [core] Selecting a WG document for CoAP >> =09 >> >> Dear all >> >> Those interested in the subscribe/notify discussion might like to look >> at the draft Smart Energy Profile 2.0 Application Protocol >> Specification. It is available here: >> http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicApp >> licationProfile.aspx >> >> It manages subscribe/notify by using POST. This seems to remove the need >> for SUBSCRIBE and notify. >> >> "Imagine a host A, which exposes a resource at http{s}://A/resource and >> a second host B, which wishes to learn of changes to this resource. To >> facilitate a subscription/ notification mechanism, A would expose a >> resource http{s}://A/sub and B would expose a resource http{s}://B/ntfy. >> To subscribe to notifications regarding http{s}://A/resource, B would >> send a POST to the address http{s}://A/sub/B containing the URI of the >> resource of interest (http{s}://A/resource) and the URI of B's >> notification resource (http{s}://B/ntfy). Following this subscription >> step, should A wish to notify B of a change to the resource addressed at >> http{s}://A/resource, A would send a POST to the address >> http{s}://B/ntfy containing the URI of the resource changed >> (http{s}://A/resource) and the URI of A's subscription resource >> (http{s}://A/sub/B), should A wish to change its subscription. The host >> B can then query the resource (or not) at its leisure." >> >> Sleepy nodes are not allowed to subscribe, and must poll. >> >> Regards - Charles Palmer >> >> -----Original Message----- >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of >> Angelo P. Castellani >> Sent: 14 May 2010 13:14 >> To: Zach Shelby >> Cc: core >> Subject: Re: [core] Selecting a WG document for CoAP >> >> Zach, >> >> thanks for the comments, but please refer to my most recent e-mail for >> a more specific list of technical issues I'm pointing to. >> >> I want to do only a little integration to what I've written there. >> >> In my very personal opinion, to maximize adherence with the REST model >> and minimize implementation effort SUBSCRIBE and NOTIFY should be >> mapped to methods (as discussed many times together...). >> >> Uniform interface principle (Fielding PhD dissertation Section 5.1.5, >> "The central feature that distinguishes the REST architectural style >> [...]") states that to simplify the software architecture, resource >> interfaces/interfaces should be as general as possible. >> >> I agree with this principle in this specific case, mainly because >> handling a special message type for notify leads node software design >> to a more complex architecture. >> >> The reason is that this new message type requires special handling and >> introduces a complexity in the software modularization. >> >> Best, >> Angelo >> >> On Fri, May 14, 2010 at 13:06, Zach Shelby wrote: >> =20 >>> Hi Angelo, >>> >>> On May 13, 2010, at 14:24 , Angelo P. Castellani wrote: >>> >>> =20 >>>> Dear C. Bormann, all, >>>> >>>> before deciding for the final direction, I've the following >>>> observations about draft-shelby-core-coap-01 >>>> >>>> While I mostly share Zach's view of the protocol approach, and >>>> appreciate many aspects of the proposal, there are in my opinion >>>> =20 >> still >> =20 >>>> some open issues that need to be at least discussed before the >>>> =20 >> current >> =20 >>>> document can be selected. >>>> =20 >>> Of course there are plenty of open issues. Remember that working group >>> =20 >> documents still undertake as much change and improvement as the WG >> wants, so by no means is coap-01 set in stone. I would expect at least >> 5-10 more revisions still along the way. Already several of your ideas >> have been integrated into coap-01, and several more are under >> consideration, so it is coming along. Patience ;-) >> =20 >>> =20 >>>> In particular, I would like to highlight the following: >>>> >>>> a) As it is now, it is not possible to have a straightforward >>>> translation of HTTP -> CoAP and viceversa: see >>>> http://www.ietf.org/mail-archive/web/core/current/msg00133.html (this >>>> impacts the scalability of the web service model too) >>>> =20 >>> In coap-01 the Method names are now identical to HTTP methods. The >>> =20 >> Req/Res interaction is a direct translation. The URI hierarchy is >> compatible, and the URI binary code format we are still working on >> obviously. The only thing that takes some state to translate is >> Subscribe/Notify. But note, Subscribe/Notify takes some state no matter >> how you do it, even with HTTP-HTTP there is no clean and easy way to >> handle subscriptions. >> =20 >>> =20 >>>> b) Moreover, CoAP's implementation is not as simple as it should be. >>>> I've investigated the implementation and some design choices (as >>>> Options) are leading to very high program complexity (ROM) on a >>>> MSP430-based device. >>>> =20 >>> This we can definitely improve, and already made several optimizations >>> =20 >> from -00 to -01. Here I need some very concrete proposals though. Also >> remember that many things are optional, for example subscribe/notify is >> not required if you don't need it. >> =20 >>> =20 >>>> c) Finally when comparing HTTP message size with CoAP message size, >>>> the resulting compression isn't as good as you may expect. >>>> >>>> Example: >>>> HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B >>>> CoAP: 24 B with options parsing procedure requiring an added >>>> implementation complexity >>>> =20 >>> Right, that is not how it will work in practice. Working with a real >>> =20 >> HTTP server that HTTP header will be more complex, and on the CoAP side >> you would chose shorter URLs. The biggest improvement possible here is >> from using binary coded URLs of course. We need to look at a wider range >> of interactions and real HTTP headers as well to check that we are >> efficient enough. >> =20 >>> =20 >>>> Addressing all these points potentially leads to major technical >>>> modifications (especially point a) on the current draft, hence it is >>>> appropriate in my opinion to discuss these points before making the >>>> final decision. >>>> =20 >>> I am not sure what else you have in mind for a). If we just forget >>> =20 >> about Subscribe/Notify then you are good to go. But then you are also >> not fulfilling the charter or the industry needs in that respect. >> =20 >>> Thanks, >>> Zach >>> >>> =20 >>>> Best regards, >>>> >>>> Angelo P. Castellani >>>> >>>> >>>> On Mon, May 10, 2010 at 18:51, Carsten Bormann wrote: >>>> =20 >>>>> The CORE WG has a milestone to select a WG document for CoAP in >>>>> =20 >> April: >> =20 >>>>> http://datatracker.ietf.org/wg/core/charter/ >>>>> ... >>>>> Apr 2010 Select WG document for basis of the CoAP protocol >>>>> >>>>> Of the various documents that have been contributed, >>>>> =20 >> draft-shelby-core-coap has significant discussion, as well as the >> largest number of updates (including a previous version that was still >> called -6lowapp-coap). >> =20 >>>>> Today, another updated version of that draft was announced. See >>>>> http://www.ietf.org/mail-archive/web/core/current/msg00138.html >>>>> for the announcement and >>>>> http://tools.ietf.org/html/draft-shelby-core-coap-01 >>>>> for the draft itself. >>>>> >>>>> However, as the authors say, there are still significant TODOs. >>>>> >>>>> Are we in a state yet where we can say whether this is the right >>>>> =20 >> direction for the WG to take? >> =20 >>>>> If yes, is it the right direction? Should we adopt it as a WG >>>>> =20 >> document? >> =20 >>>>> If you don't think we can say yet, is there a set of technical >>>>> =20 >> decisions you would like the authors to take with priority? >> =20 >>>>> Note that once a document has become a WG document, the authors act >>>>> =20 >> as editors for the working group, making (and usually fleshing out the >> details of) any change that the WG decides it needs. >> =20 >>>>> If you think we can still improve the draft, this is not an obstacle >>>>> =20 >> to making it a WG document. >> =20 >>>>> But of course we shouldn't do that if we intend to reverse its >>>>> =20 >> fundamental technical direction. >> =20 >>>>> In order to stay roughly in sync with our milestones, we should >>>>> =20 >> reach at a decision on how to go forward this week. >> =20 >>>>> Gruesse, Carsten >>>>> >>>>> _______________________________________________ >>>>> core mailing list >>>>> core@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/core >>>>> >>>>> =20 >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>> =20 >>> -- >>> Zach Shelby, Chief Nerd, Sensinode Ltd. >>> http://zachshelby.org - My blog "On the Internet of Things" >>> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" >>> Mobile: +358 40 7796297 >>> >>> >>> =20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> -------------------------------- >> Onzo is a limited company number 06097997 registered in England& Wales.= The >> registered office is 6 Great Newport Street, London, WC2H 7JB, United Ki= ngdom. >> >> This email message may contain confidential and/or privileged informatio= n, and >> is intended solely for the addressee(s). If you have received this email= in >> error, please notify Onzo immediately. Unauthorised copying, disclosure = or >> distribution of the material in this email is forbidden. >> -------------------------------- >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> ______________________________________________________________________ >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> =20 > =20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core -------------------------------- Onzo is a limited company number 06097997 registered in England & Wales. Th= e =20 registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingd= om. This email message may contain confidential and/or privileged information, = and is intended solely for the addressee(s). If you have received this email in= =20 error, please notify Onzo immediately. Unauthorised copying, disclosure or= =20 distribution of the material in this email is forbidden. -------------------------------- From paduffy@cisco.com Tue May 25 17:28:59 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40FD83A65A6 for ; Tue, 25 May 2010 17:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjcbvTC75o3C for ; Tue, 25 May 2010 17:28:49 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A14CC3A6AB3 for ; Tue, 25 May 2010 15:31:27 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAL/s+0urRN+J/2dsb2JhbACeGXGnC4FuCwGXeQKFEQQ X-IronPort-AV: E=Sophos;i="4.53,299,1272844800"; d="scan'208";a="535176023" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 25 May 2010 22:31:19 +0000 Received: from [10.86.249.191] (bxb-vpn3-447.cisco.com [10.86.249.191]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o4PMVIvB015940; Tue, 25 May 2010 22:31:18 GMT Message-ID: <4BFC4FB5.9020102@cisco.com> Date: Tue, 25 May 2010 18:31:17 -0400 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Charles Palmer References: <3602E0C6-1E2E-4164-A208-A874128325AF@sensinode.com> <4BFB3A66.5080700@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: core Subject: Re: [core] Subscribe/Notify for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 00:28:59 -0000 On 5/25/2010 6:23 PM, Charles Palmer wrote: > Hi folks > > It occurs to me that CoRE should be keeping a close eye on ZigBee SE2.0 work, so that it is as easy as possible for ZigBee SE to use CoRE when ready. That suggests to me that we should align with their subscribe/notify process. > Which is based upon existing HTTP methods and not introducing new methods to support subscriptions. The intent is to make it possible to interchange HTTP and COAP as necessary/appropriate. > Regards - Charles > > > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Paul Duffy > Sent: 25 May 2010 03:48 > To: Zach Shelby > Cc: core > Subject: Re: [core] Subscribe/Notify for CoAP > > Recommend something like #2, primarily to avoid introducing non HTTP > method semantics, simplifying HTTP/COAP translation.gateways, etc. > > > On 5/24/2010 11:49 AM, Zach Shelby wrote: > >> (thread renamed) >> >> We have two different paths with regard to a subscribe/notify mechanism for CoAP: >> >> 1. Use specific Subscription and Notify mechanisms for CoAP as HTTP really does not include this concept. >> 1a) Notify as a message and SUBSCRIBE as a method. This is currently used in coap-01. >> 1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but we had a good list discussion about this leading to a. In practice it doesn't make a big difference if notification is a message or method. >> >> 2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2.0 proposal or GENA. >> >> So far we have focused on 1 in the WG, and every now and again 2 comes up. At least I am not convinced that we need to suffer the drawbacks of HTTP here. Anyways 2 does not help our mapping to HTTP in reality very much as there is no standard way of doing this over HTTP. Thus a CoAP-HTTP proxy may end up anyways translating between multiple HTTP frameworks depending on the application. So instead of doing a CoAP Notify/Subscribe to Webhooks mapping, you will could end up having to do a CoAP Webhooks to HTTP GENA mapping. >> >> > > I don't understand this last para. If CoAP sticks to the semantics of > the current HTTP methods, would this not offer a fairly straightforward > translation to/from HTTP? > > > >>> From what I have heard so far 1 still seems like a wise choice, although I need to look at Webhooks more deeply. In reality many applications specify their own way of doing a push interface using REST methods and specific payloads (ZigBee SE2.0 is such an example). That is just fine, and might be used instead of a specific CoAP notify/subscribe in that case. So 1 doesn't prevent the application using its own mechanism, it just provides a native way for doing push. >>> >> What do people think? >> >> Zach >> >> On May 17, 2010, at 6:44 PM, matthieu.vial@fr.non.schneider-electric.com wrote: >> >> >> >>> Hi, >>> >>> My comments about the subscribe/notify mechanism of Zigbee IP. >>> >>> Pros: >>> - Derived from the webhooks concept >>> - If used by CORE it will be easier to map to HTTP because it uses only CRUD verbs. >>> - The subscription message is extendable and could support advanced options (delays, increment, ...) >>> - Only one listening port whatever the transport binding is. >>> >>> Cons: >>> - No interoperability without well known URIs and a well defined subscription message format (Not sure CoAP draft is the right place to specify this). >>> - XML/EXI is too complex to be the required format for the default subscription/notification mechanism. >>> - The notification should not require a subsequent GET to retrieve the content. >>> - Subresource subscription is redundant. >>> >>> Hope this could help, >>> Matthieu >>> >>> >>> "Charles Palmer" >>> >>> >>> >>> >>> "Charles Palmer" >>> Envoyé par : core-bounces@ietf.org >>> 15/05/2010 14:06 >>> >>> >>> A >>> >>> "core" >>> >>> cc >>> >>> >>> Objet >>> >>> Re: [core] Selecting a WG document for CoAP >>> >>> >>> Dear all >>> >>> Those interested in the subscribe/notify discussion might like to look >>> at the draft Smart Energy Profile 2.0 Application Protocol >>> Specification. It is available here: >>> http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicApp >>> licationProfile.aspx >>> >>> It manages subscribe/notify by using POST. This seems to remove the need >>> for SUBSCRIBE and notify. >>> >>> "Imagine a host A, which exposes a resource at http{s}://A/resource and >>> a second host B, which wishes to learn of changes to this resource. To >>> facilitate a subscription/ notification mechanism, A would expose a >>> resource http{s}://A/sub and B would expose a resource http{s}://B/ntfy. >>> To subscribe to notifications regarding http{s}://A/resource, B would >>> send a POST to the address http{s}://A/sub/B containing the URI of the >>> resource of interest (http{s}://A/resource) and the URI of B's >>> notification resource (http{s}://B/ntfy). Following this subscription >>> step, should A wish to notify B of a change to the resource addressed at >>> http{s}://A/resource, A would send a POST to the address >>> http{s}://B/ntfy containing the URI of the resource changed >>> (http{s}://A/resource) and the URI of A's subscription resource >>> (http{s}://A/sub/B), should A wish to change its subscription. The host >>> B can then query the resource (or not) at its leisure." >>> >>> Sleepy nodes are not allowed to subscribe, and must poll. >>> >>> Regards - Charles Palmer >>> >>> -----Original Message----- >>> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of >>> Angelo P. Castellani >>> Sent: 14 May 2010 13:14 >>> To: Zach Shelby >>> Cc: core >>> Subject: Re: [core] Selecting a WG document for CoAP >>> >>> Zach, >>> >>> thanks for the comments, but please refer to my most recent e-mail for >>> a more specific list of technical issues I'm pointing to. >>> >>> I want to do only a little integration to what I've written there. >>> >>> In my very personal opinion, to maximize adherence with the REST model >>> and minimize implementation effort SUBSCRIBE and NOTIFY should be >>> mapped to methods (as discussed many times together...). >>> >>> Uniform interface principle (Fielding PhD dissertation Section 5.1.5, >>> "The central feature that distinguishes the REST architectural style >>> [...]") states that to simplify the software architecture, resource >>> interfaces/interfaces should be as general as possible. >>> >>> I agree with this principle in this specific case, mainly because >>> handling a special message type for notify leads node software design >>> to a more complex architecture. >>> >>> The reason is that this new message type requires special handling and >>> introduces a complexity in the software modularization. >>> >>> Best, >>> Angelo >>> >>> On Fri, May 14, 2010 at 13:06, Zach Shelby wrote: >>> >>> >>>> Hi Angelo, >>>> >>>> On May 13, 2010, at 14:24 , Angelo P. Castellani wrote: >>>> >>>> >>>> >>>>> Dear C. Bormann, all, >>>>> >>>>> before deciding for the final direction, I've the following >>>>> observations about draft-shelby-core-coap-01 >>>>> >>>>> While I mostly share Zach's view of the protocol approach, and >>>>> appreciate many aspects of the proposal, there are in my opinion >>>>> >>>>> >>> still >>> >>> >>>>> some open issues that need to be at least discussed before the >>>>> >>>>> >>> current >>> >>> >>>>> document can be selected. >>>>> >>>>> >>>> Of course there are plenty of open issues. Remember that working group >>>> >>>> >>> documents still undertake as much change and improvement as the WG >>> wants, so by no means is coap-01 set in stone. I would expect at least >>> 5-10 more revisions still along the way. Already several of your ideas >>> have been integrated into coap-01, and several more are under >>> consideration, so it is coming along. Patience ;-) >>> >>> >>>> >>>> >>>>> In particular, I would like to highlight the following: >>>>> >>>>> a) As it is now, it is not possible to have a straightforward >>>>> translation of HTTP -> CoAP and viceversa: see >>>>> http://www.ietf.org/mail-archive/web/core/current/msg00133.html (this >>>>> impacts the scalability of the web service model too) >>>>> >>>>> >>>> In coap-01 the Method names are now identical to HTTP methods. The >>>> >>>> >>> Req/Res interaction is a direct translation. The URI hierarchy is >>> compatible, and the URI binary code format we are still working on >>> obviously. The only thing that takes some state to translate is >>> Subscribe/Notify. But note, Subscribe/Notify takes some state no matter >>> how you do it, even with HTTP-HTTP there is no clean and easy way to >>> handle subscriptions. >>> >>> >>>> >>>> >>>>> b) Moreover, CoAP's implementation is not as simple as it should be. >>>>> I've investigated the implementation and some design choices (as >>>>> Options) are leading to very high program complexity (ROM) on a >>>>> MSP430-based device. >>>>> >>>>> >>>> This we can definitely improve, and already made several optimizations >>>> >>>> >>> from -00 to -01. Here I need some very concrete proposals though. Also >>> remember that many things are optional, for example subscribe/notify is >>> not required if you don't need it. >>> >>> >>>> >>>> >>>>> c) Finally when comparing HTTP message size with CoAP message size, >>>>> the resulting compression isn't as good as you may expect. >>>>> >>>>> Example: >>>>> HTTP: GET /sensor/temp.xml HTTP/1.0 = 32 B >>>>> CoAP: 24 B with options parsing procedure requiring an added >>>>> implementation complexity >>>>> >>>>> >>>> Right, that is not how it will work in practice. Working with a real >>>> >>>> >>> HTTP server that HTTP header will be more complex, and on the CoAP side >>> you would chose shorter URLs. The biggest improvement possible here is >>> from using binary coded URLs of course. We need to look at a wider range >>> of interactions and real HTTP headers as well to check that we are >>> efficient enough. >>> >>> >>>> >>>> >>>>> Addressing all these points potentially leads to major technical >>>>> modifications (especially point a) on the current draft, hence it is >>>>> appropriate in my opinion to discuss these points before making the >>>>> final decision. >>>>> >>>>> >>>> I am not sure what else you have in mind for a). If we just forget >>>> >>>> >>> about Subscribe/Notify then you are good to go. But then you are also >>> not fulfilling the charter or the industry needs in that respect. >>> >>> >>>> Thanks, >>>> Zach >>>> >>>> >>>> >>>>> Best regards, >>>>> >>>>> Angelo P. Castellani >>>>> >>>>> >>>>> On Mon, May 10, 2010 at 18:51, Carsten Bormann wrote: >>>>> >>>>> >>>>>> The CORE WG has a milestone to select a WG document for CoAP in >>>>>> >>>>>> >>> April: >>> >>> >>>>>> http://datatracker.ietf.org/wg/core/charter/ >>>>>> ... >>>>>> Apr 2010 Select WG document for basis of the CoAP protocol >>>>>> >>>>>> Of the various documents that have been contributed, >>>>>> >>>>>> >>> draft-shelby-core-coap has significant discussion, as well as the >>> largest number of updates (including a previous version that was still >>> called -6lowapp-coap). >>> >>> >>>>>> Today, another updated version of that draft was announced. See >>>>>> http://www.ietf.org/mail-archive/web/core/current/msg00138.html >>>>>> for the announcement and >>>>>> http://tools.ietf.org/html/draft-shelby-core-coap-01 >>>>>> for the draft itself. >>>>>> >>>>>> However, as the authors say, there are still significant TODOs. >>>>>> >>>>>> Are we in a state yet where we can say whether this is the right >>>>>> >>>>>> >>> direction for the WG to take? >>> >>> >>>>>> If yes, is it the right direction? Should we adopt it as a WG >>>>>> >>>>>> >>> document? >>> >>> >>>>>> If you don't think we can say yet, is there a set of technical >>>>>> >>>>>> >>> decisions you would like the authors to take with priority? >>> >>> >>>>>> Note that once a document has become a WG document, the authors act >>>>>> >>>>>> >>> as editors for the working group, making (and usually fleshing out the >>> details of) any change that the WG decides it needs. >>> >>> >>>>>> If you think we can still improve the draft, this is not an obstacle >>>>>> >>>>>> >>> to making it a WG document. >>> >>> >>>>>> But of course we shouldn't do that if we intend to reverse its >>>>>> >>>>>> >>> fundamental technical direction. >>> >>> >>>>>> In order to stay roughly in sync with our milestones, we should >>>>>> >>>>>> >>> reach at a decision on how to go forward this week. >>> >>> >>>>>> Gruesse, Carsten >>>>>> >>>>>> _______________________________________________ >>>>>> core mailing list >>>>>> core@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/core >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> core mailing list >>>>> core@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/core >>>>> >>>>> >>>> -- >>>> Zach Shelby, Chief Nerd, Sensinode Ltd. >>>> http://zachshelby.org - My blog "On the Internet of Things" >>>> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" >>>> Mobile: +358 40 7796297 >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >>> -------------------------------- >>> Onzo is a limited company number 06097997 registered in England& Wales. The >>> registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingdom. >>> >>> This email message may contain confidential and/or privileged information, and >>> is intended solely for the addressee(s). If you have received this email in >>> error, please notify Onzo immediately. Unauthorised copying, disclosure or >>> distribution of the material in this email is forbidden. >>> -------------------------------- >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >>> ______________________________________________________________________ >>> This email has been scanned by the MessageLabs Email Security System. >>> ______________________________________________________________________ >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >>> >> >> > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > -------------------------------- > Onzo is a limited company number 06097997 registered in England& Wales. The > registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingdom. > > This email message may contain confidential and/or privileged information, and > is intended solely for the addressee(s). If you have received this email in > error, please notify Onzo immediately. Unauthorised copying, disclosure or > distribution of the material in this email is forbidden. > -------------------------------- > > > From zach@sensinode.com Tue May 25 17:34:55 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94DE63A6D22 for ; Tue, 25 May 2010 17:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjddtUw0+zpw for ; Tue, 25 May 2010 17:34:53 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 841D53A779E for ; Tue, 25 May 2010 15:41:51 -0700 (PDT) Received: from [192.168.13.111] (135.Red-88-11-88.dynamicIP.rima-tde.net [88.11.88.135]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o4PMfFIS010065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 May 2010 01:41:24 +0300 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: Zach Shelby In-Reply-To: Date: Wed, 26 May 2010 00:41:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <324781C3-5548-474D-8995-EC327ED08209@sensinode.com> References: <3602E0C6-1E2E-4164-A208-A874128325AF@sensinode.com> <4BFB3A66.5080700@cisco.com> To: "Charles Palmer" X-Mailer: Apple Mail (2.1078) Cc: core Subject: Re: [core] Subscribe/Notify for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 00:34:55 -0000 Hi, On May 26, 2010, at 12:23 AM, Charles Palmer wrote: > Hi folks=20 >=20 > It occurs to me that CoRE should be keeping a close eye on ZigBee = SE2.0 work, so that it is as easy as possible for ZigBee SE to use CoRE = when ready. That suggests to me that we should align with their = subscribe/notify process. >=20 I am not sure I understand that. I mean, ZigBee SE2.0 is defining an = application specific subscribe/notify mechanism for that purpose so far = for HTTP. This uses standard HTTP methods and some custom payload and = REST interfaces. CoAP Req/Res is already totally compatible with SE2.0 = in that respect, so alignment is already OK there. Nothing stopping = someone from using SE2.0 over CoAP. Specifying a native susbcription/notify into CoAP is another matter. We = can't adopt a solution specific to one application as that won't solve = the problems of other applications nor general HTTP mapping at all = (probably would make it worse). It seems that for the near future there = will be a bunch of HTTP push mechanisms in use without any clear = standard appearing - or am I wrong there? Zach > Regards - Charles=20 >=20 >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Paul Duffy > Sent: 25 May 2010 03:48 > To: Zach Shelby > Cc: core > Subject: Re: [core] Subscribe/Notify for CoAP >=20 > Recommend something like #2, primarily to avoid introducing non HTTP=20= > method semantics, simplifying HTTP/COAP translation.gateways, etc. >=20 >=20 > On 5/24/2010 11:49 AM, Zach Shelby wrote: >> (thread renamed) >>=20 >> We have two different paths with regard to a subscribe/notify = mechanism for CoAP: >>=20 >> 1. Use specific Subscription and Notify mechanisms for CoAP as HTTP = really does not include this concept. >> 1a) Notify as a message and SUBSCRIBE as a method. This is currently = used in coap-01. >> 1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but we = had a good list discussion about this leading to a. In practice it = doesn't make a big difference if notification is a message or method. >>=20 >> 2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2.0 = proposal or GENA. >>=20 >> So far we have focused on 1 in the WG, and every now and again 2 = comes up. At least I am not convinced that we need to suffer the = drawbacks of HTTP here. Anyways 2 does not help our mapping to HTTP in = reality very much as there is no standard way of doing this over HTTP. = Thus a CoAP-HTTP proxy may end up anyways translating between multiple = HTTP frameworks depending on the application. So instead of doing a CoAP = Notify/Subscribe to Webhooks mapping, you will could end up having to do = a CoAP Webhooks to HTTP GENA mapping. >>=20 >=20 >=20 > I don't understand this last para. If CoAP sticks to the semantics of=20= > the current HTTP methods, would this not offer a fairly = straightforward=20 > translation to/from HTTP? >=20 >=20 >>> =46rom what I have heard so far 1 still seems like a wise choice, = although I need to look at Webhooks more deeply. In reality many = applications specify their own way of doing a push interface using REST = methods and specific payloads (ZigBee SE2.0 is such an example). That is = just fine, and might be used instead of a specific CoAP notify/subscribe = in that case. So 1 doesn't prevent the application using its own = mechanism, it just provides a native way for doing push. >>=20 >> What do people think? >>=20 >> Zach >>=20 >> On May 17, 2010, at 6:44 PM, = matthieu.vial@fr.non.schneider-electric.com wrote: >>=20 >>=20 >>> Hi, >>>=20 >>> My comments about the subscribe/notify mechanism of Zigbee IP. >>>=20 >>> Pros: >>> - Derived from the webhooks concept >>> - If used by CORE it will be easier to map to HTTP because it uses = only CRUD verbs. >>> - The subscription message is extendable and could support advanced = options (delays, increment, ...) >>> - Only one listening port whatever the transport binding is. >>>=20 >>> Cons: >>> - No interoperability without well known URIs and a well defined = subscription message format (Not sure CoAP draft is the right place to = specify this). >>> - XML/EXI is too complex to be the required format for the default = subscription/notification mechanism. >>> - The notification should not require a subsequent GET to retrieve = the content. >>> - Subresource subscription is redundant. >>>=20 >>> Hope this could help, >>> Matthieu >>>=20 >>>=20 >>> "Charles Palmer" >>>=20 >>>=20 >>>=20 >>>=20 >>> "Charles Palmer" >>> Envoy=E9 par : core-bounces@ietf.org >>> 15/05/2010 14:06 >>>=20 >>> >>> A >>> >>> "core" >>> >>> cc >>> >>> >>> Objet >>> >>> Re: [core] Selecting a WG document for CoAP >>> >>>=20 >>> Dear all >>>=20 >>> Those interested in the subscribe/notify discussion might like to = look >>> at the draft Smart Energy Profile 2.0 Application Protocol >>> Specification. It is available here: >>> = http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicApp >>> licationProfile.aspx >>>=20 >>> It manages subscribe/notify by using POST. This seems to remove the = need >>> for SUBSCRIBE and notify. >>>=20 >>> "Imagine a host A, which exposes a resource at http{s}://A/resource = and >>> a second host B, which wishes to learn of changes to this resource. = To >>> facilitate a subscription/ notification mechanism, A would expose a >>> resource http{s}://A/sub and B would expose a resource = http{s}://B/ntfy. >>> To subscribe to notifications regarding http{s}://A/resource, B = would >>> send a POST to the address http{s}://A/sub/B containing the URI of = the >>> resource of interest (http{s}://A/resource) and the URI of B's >>> notification resource (http{s}://B/ntfy). Following this = subscription >>> step, should A wish to notify B of a change to the resource = addressed at >>> http{s}://A/resource, A would send a POST to the address >>> http{s}://B/ntfy containing the URI of the resource changed >>> (http{s}://A/resource) and the URI of A's subscription resource >>> (http{s}://A/sub/B), should A wish to change its subscription. The = host >>> B can then query the resource (or not) at its leisure." >>>=20 >>> Sleepy nodes are not allowed to subscribe, and must poll. >>>=20 >>> Regards - Charles Palmer >>>=20 >>> -----Original Message----- >>> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of >>> Angelo P. Castellani >>> Sent: 14 May 2010 13:14 >>> To: Zach Shelby >>> Cc: core >>> Subject: Re: [core] Selecting a WG document for CoAP >>>=20 >>> Zach, >>>=20 >>> thanks for the comments, but please refer to my most recent e-mail = for >>> a more specific list of technical issues I'm pointing to. >>>=20 >>> I want to do only a little integration to what I've written there. >>>=20 >>> In my very personal opinion, to maximize adherence with the REST = model >>> and minimize implementation effort SUBSCRIBE and NOTIFY should be >>> mapped to methods (as discussed many times together...). >>>=20 >>> Uniform interface principle (Fielding PhD dissertation Section = 5.1.5, >>> "The central feature that distinguishes the REST architectural style >>> [...]") states that to simplify the software architecture, resource >>> interfaces/interfaces should be as general as possible. >>>=20 >>> I agree with this principle in this specific case, mainly because >>> handling a special message type for notify leads node software = design >>> to a more complex architecture. >>>=20 >>> The reason is that this new message type requires special handling = and >>> introduces a complexity in the software modularization. >>>=20 >>> Best, >>> Angelo >>>=20 >>> On Fri, May 14, 2010 at 13:06, Zach Shelby = wrote: >>>=20 >>>> Hi Angelo, >>>>=20 >>>> On May 13, 2010, at 14:24 , Angelo P. Castellani wrote: >>>>=20 >>>>=20 >>>>> Dear C. Bormann, all, >>>>>=20 >>>>> before deciding for the final direction, I've the following >>>>> observations about draft-shelby-core-coap-01 >>>>>=20 >>>>> While I mostly share Zach's view of the protocol approach, and >>>>> appreciate many aspects of the proposal, there are in my opinion >>>>>=20 >>> still >>>=20 >>>>> some open issues that need to be at least discussed before the >>>>>=20 >>> current >>>=20 >>>>> document can be selected. >>>>>=20 >>>> Of course there are plenty of open issues. Remember that working = group >>>>=20 >>> documents still undertake as much change and improvement as the WG >>> wants, so by no means is coap-01 set in stone. I would expect at = least >>> 5-10 more revisions still along the way. Already several of your = ideas >>> have been integrated into coap-01, and several more are under >>> consideration, so it is coming along. Patience ;-) >>>=20 >>>>=20 >>>>> In particular, I would like to highlight the following: >>>>>=20 >>>>> a) As it is now, it is not possible to have a straightforward >>>>> translation of HTTP -> CoAP and viceversa: see >>>>> http://www.ietf.org/mail-archive/web/core/current/msg00133.html = (this >>>>> impacts the scalability of the web service model too) >>>>>=20 >>>> In coap-01 the Method names are now identical to HTTP methods. The >>>>=20 >>> Req/Res interaction is a direct translation. The URI hierarchy is >>> compatible, and the URI binary code format we are still working on >>> obviously. The only thing that takes some state to translate is >>> Subscribe/Notify. But note, Subscribe/Notify takes some state no = matter >>> how you do it, even with HTTP-HTTP there is no clean and easy way to >>> handle subscriptions. >>>=20 >>>>=20 >>>>> b) Moreover, CoAP's implementation is not as simple as it should = be. >>>>> I've investigated the implementation and some design choices (as >>>>> Options) are leading to very high program complexity (ROM) on a >>>>> MSP430-based device. >>>>>=20 >>>> This we can definitely improve, and already made several = optimizations >>>>=20 >>> from -00 to -01. Here I need some very concrete proposals though. = Also >>> remember that many things are optional, for example subscribe/notify = is >>> not required if you don't need it. >>>=20 >>>>=20 >>>>> c) Finally when comparing HTTP message size with CoAP message = size, >>>>> the resulting compression isn't as good as you may expect. >>>>>=20 >>>>> Example: >>>>> HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B >>>>> CoAP: 24 B with options parsing procedure requiring an added >>>>> implementation complexity >>>>>=20 >>>> Right, that is not how it will work in practice. Working with a = real >>>>=20 >>> HTTP server that HTTP header will be more complex, and on the CoAP = side >>> you would chose shorter URLs. The biggest improvement possible here = is >>> from using binary coded URLs of course. We need to look at a wider = range >>> of interactions and real HTTP headers as well to check that we are >>> efficient enough. >>>=20 >>>>=20 >>>>> Addressing all these points potentially leads to major technical >>>>> modifications (especially point a) on the current draft, hence it = is >>>>> appropriate in my opinion to discuss these points before making = the >>>>> final decision. >>>>>=20 >>>> I am not sure what else you have in mind for a). If we just forget >>>>=20 >>> about Subscribe/Notify then you are good to go. But then you are = also >>> not fulfilling the charter or the industry needs in that respect. >>>=20 >>>> Thanks, >>>> Zach >>>>=20 >>>>=20 >>>>> Best regards, >>>>>=20 >>>>> Angelo P. Castellani >>>>>=20 >>>>>=20 >>>>> On Mon, May 10, 2010 at 18:51, Carsten Bormann = wrote: >>>>>=20 >>>>>> The CORE WG has a milestone to select a WG document for CoAP in >>>>>>=20 >>> April: >>>=20 >>>>>> http://datatracker.ietf.org/wg/core/charter/ >>>>>> ... >>>>>> Apr 2010 Select WG document for basis of the CoAP protocol >>>>>>=20 >>>>>> Of the various documents that have been contributed, >>>>>>=20 >>> draft-shelby-core-coap has significant discussion, as well as the >>> largest number of updates (including a previous version that was = still >>> called -6lowapp-coap). >>>=20 >>>>>> Today, another updated version of that draft was announced. See >>>>>> http://www.ietf.org/mail-archive/web/core/current/msg00138.html >>>>>> for the announcement and >>>>>> http://tools.ietf.org/html/draft-shelby-core-coap-01 >>>>>> for the draft itself. >>>>>>=20 >>>>>> However, as the authors say, there are still significant TODOs. >>>>>>=20 >>>>>> Are we in a state yet where we can say whether this is the right >>>>>>=20 >>> direction for the WG to take? >>>=20 >>>>>> If yes, is it the right direction? Should we adopt it as a WG >>>>>>=20 >>> document? >>>=20 >>>>>> If you don't think we can say yet, is there a set of technical >>>>>>=20 >>> decisions you would like the authors to take with priority? >>>=20 >>>>>> Note that once a document has become a WG document, the authors = act >>>>>>=20 >>> as editors for the working group, making (and usually fleshing out = the >>> details of) any change that the WG decides it needs. >>>=20 >>>>>> If you think we can still improve the draft, this is not an = obstacle >>>>>>=20 >>> to making it a WG document. >>>=20 >>>>>> But of course we shouldn't do that if we intend to reverse its >>>>>>=20 >>> fundamental technical direction. >>>=20 >>>>>> In order to stay roughly in sync with our milestones, we should >>>>>>=20 >>> reach at a decision on how to go forward this week. >>>=20 >>>>>> Gruesse, Carsten >>>>>>=20 >>>>>> _______________________________________________ >>>>>> core mailing list >>>>>> core@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/core >>>>>>=20 >>>>>>=20 >>>>> _______________________________________________ >>>>> core mailing list >>>>> core@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/core >>>>>=20 >>>> -- >>>> Zach Shelby, Chief Nerd, Sensinode Ltd. >>>> http://zachshelby.org - My blog "On the Internet of Things" >>>> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded = Internet" >>>> Mobile: +358 40 7796297 >>>>=20 >>>>=20 >>>>=20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>>=20 >>> -------------------------------- >>> Onzo is a limited company number 06097997 registered in England& = Wales. The >>> registered office is 6 Great Newport Street, London, WC2H 7JB, = United Kingdom. >>>=20 >>> This email message may contain confidential and/or privileged = information, and >>> is intended solely for the addressee(s). If you have received this = email in >>> error, please notify Onzo immediately. Unauthorised copying, = disclosure or >>> distribution of the material in this email is forbidden. >>> -------------------------------- >>>=20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>>=20 >>> = ______________________________________________________________________ >>> This email has been scanned by the MessageLabs Email Security = System. >>> = ______________________________________________________________________ >>>=20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>>=20 >>=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 > -------------------------------- > Onzo is a limited company number 06097997 registered in England & = Wales. The =20 > registered office is 6 Great Newport Street, London, WC2H 7JB, United = Kingdom. >=20 > This email message may contain confidential and/or privileged = information, and > is intended solely for the addressee(s). If you have received this = email in =20 > error, please notify Onzo immediately. Unauthorised copying, = disclosure or=20 > distribution of the material in this email is forbidden. > -------------------------------- >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From paduffy@cisco.com Tue May 25 17:35:24 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 131573A6B1C for ; Tue, 25 May 2010 17:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.299 X-Spam-Level: X-Spam-Status: No, score=-8.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKE7Jqrtqg7v for ; Tue, 25 May 2010 17:35:21 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 548803A77C5 for ; Tue, 25 May 2010 15:47:15 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAH/w+0tAZnwN/2dsb2JhbACeGXGmb4FuCwGXegKFEQQ X-IronPort-AV: E=Sophos;i="4.53,300,1272844800"; d="scan'208";a="114804831" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 25 May 2010 22:47:06 +0000 Received: from [10.86.249.191] (bxb-vpn3-447.cisco.com [10.86.249.191]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4PMl5EL016358; Tue, 25 May 2010 22:47:06 GMT Message-ID: <4BFC5368.2010602@cisco.com> Date: Tue, 25 May 2010 18:47:04 -0400 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Zach Shelby References: <3602E0C6-1E2E-4164-A208-A874128325AF@sensinode.com> <4BFB3A66.5080700@cisco.com> <324781C3-5548-474D-8995-EC327ED08209@sensinode.com> In-Reply-To: <324781C3-5548-474D-8995-EC327ED08209@sensinode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: core Subject: Re: [core] Subscribe/Notify for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 00:35:24 -0000 On 5/25/2010 6:41 PM, Zach Shelby wrote: > Hi, > > On May 26, 2010, at 12:23 AM, Charles Palmer wrote: > > >> Hi folks >> >> It occurs to me that CoRE should be keeping a close eye on ZigBee SE2.0 work, so that it is as easy as possible for ZigBee SE to use CoRE when ready. That suggests to me that we should align with their subscribe/notify process. >> >> > I am not sure I understand that. I mean, ZigBee SE2.0 is defining an application specific subscribe/notify mechanism for that purpose so far for HTTP. This uses standard HTTP methods and some custom payload and REST interfaces. CoAP Req/Res is already totally compatible with SE2.0 in that respect, so alignment is already OK there. Nothing stopping someone from using SE2.0 over CoAP. > > Specifying a native susbcription/notify into CoAP is another matter. We can't adopt a solution specific to one application as that won't solve the problems of other applications nor general HTTP mapping at all (probably would make it worse). It seems that for the near future there will be a bunch of HTTP push mechanisms in use without any clear standard appearing - or am I wrong there? > If COAP extends HTTP semantics with new subscription methods, it will not be possible to easily interchange HTTP/COAP, and translation gateways will become more complex to implement. > Zach > > >> Regards - Charles >> >> >> -----Original Message----- >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Paul Duffy >> Sent: 25 May 2010 03:48 >> To: Zach Shelby >> Cc: core >> Subject: Re: [core] Subscribe/Notify for CoAP >> >> Recommend something like #2, primarily to avoid introducing non HTTP >> method semantics, simplifying HTTP/COAP translation.gateways, etc. >> >> >> On 5/24/2010 11:49 AM, Zach Shelby wrote: >> >>> (thread renamed) >>> >>> We have two different paths with regard to a subscribe/notify mechanism for CoAP: >>> >>> 1. Use specific Subscription and Notify mechanisms for CoAP as HTTP really does not include this concept. >>> 1a) Notify as a message and SUBSCRIBE as a method. This is currently used in coap-01. >>> 1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but we had a good list discussion about this leading to a. In practice it doesn't make a big difference if notification is a message or method. >>> >>> 2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2.0 proposal or GENA. >>> >>> So far we have focused on 1 in the WG, and every now and again 2 comes up. At least I am not convinced that we need to suffer the drawbacks of HTTP here. Anyways 2 does not help our mapping to HTTP in reality very much as there is no standard way of doing this over HTTP. Thus a CoAP-HTTP proxy may end up anyways translating between multiple HTTP frameworks depending on the application. So instead of doing a CoAP Notify/Subscribe to Webhooks mapping, you will could end up having to do a CoAP Webhooks to HTTP GENA mapping. >>> >>> >> >> I don't understand this last para. If CoAP sticks to the semantics of >> the current HTTP methods, would this not offer a fairly straightforward >> translation to/from HTTP? >> >> >> >>>> From what I have heard so far 1 still seems like a wise choice, although I need to look at Webhooks more deeply. In reality many applications specify their own way of doing a push interface using REST methods and specific payloads (ZigBee SE2.0 is such an example). That is just fine, and might be used instead of a specific CoAP notify/subscribe in that case. So 1 doesn't prevent the application using its own mechanism, it just provides a native way for doing push. >>>> >>> What do people think? >>> >>> Zach >>> >>> On May 17, 2010, at 6:44 PM, matthieu.vial@fr.non.schneider-electric.com wrote: >>> >>> >>> >>>> Hi, >>>> >>>> My comments about the subscribe/notify mechanism of Zigbee IP. >>>> >>>> Pros: >>>> - Derived from the webhooks concept >>>> - If used by CORE it will be easier to map to HTTP because it uses only CRUD verbs. >>>> - The subscription message is extendable and could support advanced options (delays, increment, ...) >>>> - Only one listening port whatever the transport binding is. >>>> >>>> Cons: >>>> - No interoperability without well known URIs and a well defined subscription message format (Not sure CoAP draft is the right place to specify this). >>>> - XML/EXI is too complex to be the required format for the default subscription/notification mechanism. >>>> - The notification should not require a subsequent GET to retrieve the content. >>>> - Subresource subscription is redundant. >>>> >>>> Hope this could help, >>>> Matthieu >>>> >>>> >>>> "Charles Palmer" >>>> >>>> >>>> >>>> >>>> "Charles Palmer" >>>> Envoyé par : core-bounces@ietf.org >>>> 15/05/2010 14:06 >>>> >>>> >>>> A >>>> >>>> "core" >>>> >>>> cc >>>> >>>> >>>> Objet >>>> >>>> Re: [core] Selecting a WG document for CoAP >>>> >>>> >>>> Dear all >>>> >>>> Those interested in the subscribe/notify discussion might like to look >>>> at the draft Smart Energy Profile 2.0 Application Protocol >>>> Specification. It is available here: >>>> http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicApp >>>> licationProfile.aspx >>>> >>>> It manages subscribe/notify by using POST. This seems to remove the need >>>> for SUBSCRIBE and notify. >>>> >>>> "Imagine a host A, which exposes a resource at http{s}://A/resource and >>>> a second host B, which wishes to learn of changes to this resource. To >>>> facilitate a subscription/ notification mechanism, A would expose a >>>> resource http{s}://A/sub and B would expose a resource http{s}://B/ntfy. >>>> To subscribe to notifications regarding http{s}://A/resource, B would >>>> send a POST to the address http{s}://A/sub/B containing the URI of the >>>> resource of interest (http{s}://A/resource) and the URI of B's >>>> notification resource (http{s}://B/ntfy). Following this subscription >>>> step, should A wish to notify B of a change to the resource addressed at >>>> http{s}://A/resource, A would send a POST to the address >>>> http{s}://B/ntfy containing the URI of the resource changed >>>> (http{s}://A/resource) and the URI of A's subscription resource >>>> (http{s}://A/sub/B), should A wish to change its subscription. The host >>>> B can then query the resource (or not) at its leisure." >>>> >>>> Sleepy nodes are not allowed to subscribe, and must poll. >>>> >>>> Regards - Charles Palmer >>>> >>>> -----Original Message----- >>>> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of >>>> Angelo P. Castellani >>>> Sent: 14 May 2010 13:14 >>>> To: Zach Shelby >>>> Cc: core >>>> Subject: Re: [core] Selecting a WG document for CoAP >>>> >>>> Zach, >>>> >>>> thanks for the comments, but please refer to my most recent e-mail for >>>> a more specific list of technical issues I'm pointing to. >>>> >>>> I want to do only a little integration to what I've written there. >>>> >>>> In my very personal opinion, to maximize adherence with the REST model >>>> and minimize implementation effort SUBSCRIBE and NOTIFY should be >>>> mapped to methods (as discussed many times together...). >>>> >>>> Uniform interface principle (Fielding PhD dissertation Section 5.1.5, >>>> "The central feature that distinguishes the REST architectural style >>>> [...]") states that to simplify the software architecture, resource >>>> interfaces/interfaces should be as general as possible. >>>> >>>> I agree with this principle in this specific case, mainly because >>>> handling a special message type for notify leads node software design >>>> to a more complex architecture. >>>> >>>> The reason is that this new message type requires special handling and >>>> introduces a complexity in the software modularization. >>>> >>>> Best, >>>> Angelo >>>> >>>> On Fri, May 14, 2010 at 13:06, Zach Shelby wrote: >>>> >>>> >>>>> Hi Angelo, >>>>> >>>>> On May 13, 2010, at 14:24 , Angelo P. Castellani wrote: >>>>> >>>>> >>>>> >>>>>> Dear C. Bormann, all, >>>>>> >>>>>> before deciding for the final direction, I've the following >>>>>> observations about draft-shelby-core-coap-01 >>>>>> >>>>>> While I mostly share Zach's view of the protocol approach, and >>>>>> appreciate many aspects of the proposal, there are in my opinion >>>>>> >>>>>> >>>> still >>>> >>>> >>>>>> some open issues that need to be at least discussed before the >>>>>> >>>>>> >>>> current >>>> >>>> >>>>>> document can be selected. >>>>>> >>>>>> >>>>> Of course there are plenty of open issues. Remember that working group >>>>> >>>>> >>>> documents still undertake as much change and improvement as the WG >>>> wants, so by no means is coap-01 set in stone. I would expect at least >>>> 5-10 more revisions still along the way. Already several of your ideas >>>> have been integrated into coap-01, and several more are under >>>> consideration, so it is coming along. Patience ;-) >>>> >>>> >>>>> >>>>>> In particular, I would like to highlight the following: >>>>>> >>>>>> a) As it is now, it is not possible to have a straightforward >>>>>> translation of HTTP -> CoAP and viceversa: see >>>>>> http://www.ietf.org/mail-archive/web/core/current/msg00133.html (this >>>>>> impacts the scalability of the web service model too) >>>>>> >>>>>> >>>>> In coap-01 the Method names are now identical to HTTP methods. The >>>>> >>>>> >>>> Req/Res interaction is a direct translation. The URI hierarchy is >>>> compatible, and the URI binary code format we are still working on >>>> obviously. The only thing that takes some state to translate is >>>> Subscribe/Notify. But note, Subscribe/Notify takes some state no matter >>>> how you do it, even with HTTP-HTTP there is no clean and easy way to >>>> handle subscriptions. >>>> >>>> >>>>> >>>>>> b) Moreover, CoAP's implementation is not as simple as it should be. >>>>>> I've investigated the implementation and some design choices (as >>>>>> Options) are leading to very high program complexity (ROM) on a >>>>>> MSP430-based device. >>>>>> >>>>>> >>>>> This we can definitely improve, and already made several optimizations >>>>> >>>>> >>>> from -00 to -01. Here I need some very concrete proposals though. Also >>>> remember that many things are optional, for example subscribe/notify is >>>> not required if you don't need it. >>>> >>>> >>>>> >>>>>> c) Finally when comparing HTTP message size with CoAP message size, >>>>>> the resulting compression isn't as good as you may expect. >>>>>> >>>>>> Example: >>>>>> HTTP: GET /sensor/temp.xml HTTP/1.0 = 32 B >>>>>> CoAP: 24 B with options parsing procedure requiring an added >>>>>> implementation complexity >>>>>> >>>>>> >>>>> Right, that is not how it will work in practice. Working with a real >>>>> >>>>> >>>> HTTP server that HTTP header will be more complex, and on the CoAP side >>>> you would chose shorter URLs. The biggest improvement possible here is >>>> from using binary coded URLs of course. We need to look at a wider range >>>> of interactions and real HTTP headers as well to check that we are >>>> efficient enough. >>>> >>>> >>>>> >>>>>> Addressing all these points potentially leads to major technical >>>>>> modifications (especially point a) on the current draft, hence it is >>>>>> appropriate in my opinion to discuss these points before making the >>>>>> final decision. >>>>>> >>>>>> >>>>> I am not sure what else you have in mind for a). If we just forget >>>>> >>>>> >>>> about Subscribe/Notify then you are good to go. But then you are also >>>> not fulfilling the charter or the industry needs in that respect. >>>> >>>> >>>>> Thanks, >>>>> Zach >>>>> >>>>> >>>>> >>>>>> Best regards, >>>>>> >>>>>> Angelo P. Castellani >>>>>> >>>>>> >>>>>> On Mon, May 10, 2010 at 18:51, Carsten Bormann wrote: >>>>>> >>>>>> >>>>>>> The CORE WG has a milestone to select a WG document for CoAP in >>>>>>> >>>>>>> >>>> April: >>>> >>>> >>>>>>> http://datatracker.ietf.org/wg/core/charter/ >>>>>>> ... >>>>>>> Apr 2010 Select WG document for basis of the CoAP protocol >>>>>>> >>>>>>> Of the various documents that have been contributed, >>>>>>> >>>>>>> >>>> draft-shelby-core-coap has significant discussion, as well as the >>>> largest number of updates (including a previous version that was still >>>> called -6lowapp-coap). >>>> >>>> >>>>>>> Today, another updated version of that draft was announced. See >>>>>>> http://www.ietf.org/mail-archive/web/core/current/msg00138.html >>>>>>> for the announcement and >>>>>>> http://tools.ietf.org/html/draft-shelby-core-coap-01 >>>>>>> for the draft itself. >>>>>>> >>>>>>> However, as the authors say, there are still significant TODOs. >>>>>>> >>>>>>> Are we in a state yet where we can say whether this is the right >>>>>>> >>>>>>> >>>> direction for the WG to take? >>>> >>>> >>>>>>> If yes, is it the right direction? Should we adopt it as a WG >>>>>>> >>>>>>> >>>> document? >>>> >>>> >>>>>>> If you don't think we can say yet, is there a set of technical >>>>>>> >>>>>>> >>>> decisions you would like the authors to take with priority? >>>> >>>> >>>>>>> Note that once a document has become a WG document, the authors act >>>>>>> >>>>>>> >>>> as editors for the working group, making (and usually fleshing out the >>>> details of) any change that the WG decides it needs. >>>> >>>> >>>>>>> If you think we can still improve the draft, this is not an obstacle >>>>>>> >>>>>>> >>>> to making it a WG document. >>>> >>>> >>>>>>> But of course we shouldn't do that if we intend to reverse its >>>>>>> >>>>>>> >>>> fundamental technical direction. >>>> >>>> >>>>>>> In order to stay roughly in sync with our milestones, we should >>>>>>> >>>>>>> >>>> reach at a decision on how to go forward this week. >>>> >>>> >>>>>>> Gruesse, Carsten >>>>>>> >>>>>>> _______________________________________________ >>>>>>> core mailing list >>>>>>> core@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/core >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> core mailing list >>>>>> core@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/core >>>>>> >>>>>> >>>>> -- >>>>> Zach Shelby, Chief Nerd, Sensinode Ltd. >>>>> http://zachshelby.org - My blog "On the Internet of Things" >>>>> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" >>>>> Mobile: +358 40 7796297 >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>> >>>> -------------------------------- >>>> Onzo is a limited company number 06097997 registered in England& Wales. The >>>> registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingdom. >>>> >>>> This email message may contain confidential and/or privileged information, and >>>> is intended solely for the addressee(s). If you have received this email in >>>> error, please notify Onzo immediately. Unauthorised copying, disclosure or >>>> distribution of the material in this email is forbidden. >>>> -------------------------------- >>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>> >>>> ______________________________________________________________________ >>>> This email has been scanned by the MessageLabs Email Security System. >>>> ______________________________________________________________________ >>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>> >>>> >>> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> -------------------------------- >> Onzo is a limited company number 06097997 registered in England& Wales. The >> registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingdom. >> >> This email message may contain confidential and/or privileged information, and >> is intended solely for the addressee(s). If you have received this email in >> error, please notify Onzo immediately. Unauthorised copying, disclosure or >> distribution of the material in this email is forbidden. >> -------------------------------- >> >> > From apezzuto@cisco.com Tue May 25 23:17:27 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1B473A6897 for ; Tue, 25 May 2010 23:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2EjQpyTbrzL for ; Tue, 25 May 2010 23:17:25 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id A4BC13A6893 for ; Tue, 25 May 2010 23:17:24 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8BAPxZ/EuQ/uCWe2dsb2JhbACeGhUBARYiBhylYZlzAoURBA X-IronPort-AV: E=Sophos;i="4.53,302,1272844800"; d="scan'208";a="7790565" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 26 May 2010 05:38:13 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4Q6HEVD022745; Wed, 26 May 2010 06:17:14 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 May 2010 08:17:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 May 2010 08:17:17 +0200 Message-ID: <0D212BD466921646B58854FB79092CEC0216121C@XMB-AMS-106.cisco.com> In-Reply-To: <4BFC5368.2010602@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Subscribe/Notify for CoAP Thread-Index: Acr8a1VwqqPM5o0/QreVZLIoBryI4gAKmEdg References: <3602E0C6-1E2E-4164-A208-A874128325AF@sensinode.com><4BFB3A66.5080700@cisco.com><324781C3-5548-474D-8995-EC327ED08209@sensinode.com> <4BFC5368.2010602@cisco.com> From: "Adriano Pezzuto (apezzuto)" To: "Paul Duffy (paduffy)" , "Zach Shelby" X-OriginalArrivalTime: 26 May 2010 06:17:14.0755 (UTC) FILETIME=[15B14530:01CAFC9B] Cc: core Subject: Re: [core] Subscribe/Notify for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 06:17:27 -0000 Hi, it looks to me that CoAP should use an explicit sub/notify mechanism = since this is the core of the machine-to-machine interaction model. HTTP suffers of this lack and we have seen a plethora of solutions to = give an asynch taste to it. Webhooks and websockets are only the lasts = of the list. As someone has already pointed out on this list, it is theoretically = possible to describe sub/notify using only CRUD methods but it looks a = little bit tricky and verbose. Now we have a chance to build from scratch a new protocol with and I = think using explicit sub/notify methods with a clear and well defined = semantic is the best option. It is easily understanding from every = developer and will prevent to build other fanny solutions on top of the = CoAP. HTTP does not have this well defined semantic and (for hundreds of = other reasons also) it is not used as wide protocol for = machine-to-machine communication. CoAP - as binary protocol - and with an explicit asynch model has a = chance to be a really wide protocol for M2M communication not only for = constrained environments. my 2 cents - adriano -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Paul Duffy (paduffy) Sent: mercoled=EC 26 maggio 2010 0.47 To: Zach Shelby Cc: core Subject: Re: [core] Subscribe/Notify for CoAP On 5/25/2010 6:41 PM, Zach Shelby wrote: > Hi, > > On May 26, 2010, at 12:23 AM, Charles Palmer wrote: > > =20 >> Hi folks >> >> It occurs to me that CoRE should be keeping a close eye on ZigBee = SE2.0 work, so that it is as easy as possible for ZigBee SE to use CoRE = when ready. That suggests to me that we should align with their = subscribe/notify process. >> >> =20 > I am not sure I understand that. I mean, ZigBee SE2.0 is defining an = application specific subscribe/notify mechanism for that purpose so far = for HTTP. This uses standard HTTP methods and some custom payload and = REST interfaces. CoAP Req/Res is already totally compatible with SE2.0 = in that respect, so alignment is already OK there. Nothing stopping = someone from using SE2.0 over CoAP. > > Specifying a native susbcription/notify into CoAP is another matter. = We can't adopt a solution specific to one application as that won't = solve the problems of other applications nor general HTTP mapping at all = (probably would make it worse). It seems that for the near future there = will be a bunch of HTTP push mechanisms in use without any clear = standard appearing - or am I wrong there? > =20 If COAP extends HTTP semantics with new subscription methods, it will=20 not be possible to easily interchange HTTP/COAP, and translation=20 gateways will become more complex to implement. > Zach > > =20 >> Regards - Charles >> >> >> -----Original Message----- >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Paul Duffy >> Sent: 25 May 2010 03:48 >> To: Zach Shelby >> Cc: core >> Subject: Re: [core] Subscribe/Notify for CoAP >> >> Recommend something like #2, primarily to avoid introducing non HTTP >> method semantics, simplifying HTTP/COAP translation.gateways, etc. >> >> >> On 5/24/2010 11:49 AM, Zach Shelby wrote: >> =20 >>> (thread renamed) >>> >>> We have two different paths with regard to a subscribe/notify = mechanism for CoAP: >>> >>> 1. Use specific Subscription and Notify mechanisms for CoAP as HTTP = really does not include this concept. >>> 1a) Notify as a message and SUBSCRIBE as a method. This is currently = used in coap-01. >>> 1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but = we had a good list discussion about this leading to a. In practice it = doesn't make a big difference if notification is a message or method. >>> >>> 2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2.0 = proposal or GENA. >>> >>> So far we have focused on 1 in the WG, and every now and again 2 = comes up. At least I am not convinced that we need to suffer the = drawbacks of HTTP here. Anyways 2 does not help our mapping to HTTP in = reality very much as there is no standard way of doing this over HTTP. = Thus a CoAP-HTTP proxy may end up anyways translating between multiple = HTTP frameworks depending on the application. So instead of doing a CoAP = Notify/Subscribe to Webhooks mapping, you will could end up having to do = a CoAP Webhooks to HTTP GENA mapping. >>> >>> =20 >> >> I don't understand this last para. If CoAP sticks to the semantics = of >> the current HTTP methods, would this not offer a fairly = straightforward >> translation to/from HTTP? >> >> >> =20 >>>> From what I have heard so far 1 still seems like a wise choice, = although I need to look at Webhooks more deeply. In reality many = applications specify their own way of doing a push interface using REST = methods and specific payloads (ZigBee SE2.0 is such an example). That is = just fine, and might be used instead of a specific CoAP notify/subscribe = in that case. So 1 doesn't prevent the application using its own = mechanism, it just provides a native way for doing push. >>>> =20 >>> What do people think? >>> >>> Zach >>> >>> On May 17, 2010, at 6:44 PM, = matthieu.vial@fr.non.schneider-electric.com wrote: >>> >>> >>> =20 >>>> Hi, >>>> >>>> My comments about the subscribe/notify mechanism of Zigbee IP. >>>> >>>> Pros: >>>> - Derived from the webhooks concept >>>> - If used by CORE it will be easier to map to HTTP because it uses = only CRUD verbs. >>>> - The subscription message is extendable and could support advanced = options (delays, increment, ...) >>>> - Only one listening port whatever the transport binding is. >>>> >>>> Cons: >>>> - No interoperability without well known URIs and a well defined = subscription message format (Not sure CoAP draft is the right place to = specify this). >>>> - XML/EXI is too complex to be the required format for the default = subscription/notification mechanism. >>>> - The notification should not require a subsequent GET to retrieve = the content. >>>> - Subresource subscription is redundant. >>>> >>>> Hope this could help, >>>> Matthieu >>>> >>>> >>>> "Charles Palmer" >>>> >>>> >>>> >>>> >>>> "Charles Palmer" >>>> Envoy=E9 par : core-bounces@ietf.org >>>> 15/05/2010 14:06 >>>> >>>> >>>> A >>>> >>>> "core" >>>> >>>> cc >>>> >>>> >>>> Objet >>>> >>>> Re: [core] Selecting a WG document for CoAP >>>> >>>> >>>> Dear all >>>> >>>> Those interested in the subscribe/notify discussion might like to = look >>>> at the draft Smart Energy Profile 2.0 Application Protocol >>>> Specification. It is available here: >>>> = http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicApp >>>> licationProfile.aspx >>>> >>>> It manages subscribe/notify by using POST. This seems to remove the = need >>>> for SUBSCRIBE and notify. >>>> >>>> "Imagine a host A, which exposes a resource at http{s}://A/resource = and >>>> a second host B, which wishes to learn of changes to this resource. = To >>>> facilitate a subscription/ notification mechanism, A would expose a >>>> resource http{s}://A/sub and B would expose a resource = http{s}://B/ntfy. >>>> To subscribe to notifications regarding http{s}://A/resource, B = would >>>> send a POST to the address http{s}://A/sub/B containing the URI of = the >>>> resource of interest (http{s}://A/resource) and the URI of B's >>>> notification resource (http{s}://B/ntfy). Following this = subscription >>>> step, should A wish to notify B of a change to the resource = addressed at >>>> http{s}://A/resource, A would send a POST to the address >>>> http{s}://B/ntfy containing the URI of the resource changed >>>> (http{s}://A/resource) and the URI of A's subscription resource >>>> (http{s}://A/sub/B), should A wish to change its subscription. The = host >>>> B can then query the resource (or not) at its leisure." >>>> >>>> Sleepy nodes are not allowed to subscribe, and must poll. >>>> >>>> Regards - Charles Palmer >>>> >>>> -----Original Message----- >>>> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On = Behalf Of >>>> Angelo P. Castellani >>>> Sent: 14 May 2010 13:14 >>>> To: Zach Shelby >>>> Cc: core >>>> Subject: Re: [core] Selecting a WG document for CoAP >>>> >>>> Zach, >>>> >>>> thanks for the comments, but please refer to my most recent e-mail = for >>>> a more specific list of technical issues I'm pointing to. >>>> >>>> I want to do only a little integration to what I've written there. >>>> >>>> In my very personal opinion, to maximize adherence with the REST = model >>>> and minimize implementation effort SUBSCRIBE and NOTIFY should be >>>> mapped to methods (as discussed many times together...). >>>> >>>> Uniform interface principle (Fielding PhD dissertation Section = 5.1.5, >>>> "The central feature that distinguishes the REST architectural = style >>>> [...]") states that to simplify the software architecture, resource >>>> interfaces/interfaces should be as general as possible. >>>> >>>> I agree with this principle in this specific case, mainly because >>>> handling a special message type for notify leads node software = design >>>> to a more complex architecture. >>>> >>>> The reason is that this new message type requires special handling = and >>>> introduces a complexity in the software modularization. >>>> >>>> Best, >>>> Angelo >>>> >>>> On Fri, May 14, 2010 at 13:06, Zach Shelby = wrote: >>>> >>>> =20 >>>>> Hi Angelo, >>>>> >>>>> On May 13, 2010, at 14:24 , Angelo P. Castellani wrote: >>>>> >>>>> >>>>> =20 >>>>>> Dear C. Bormann, all, >>>>>> >>>>>> before deciding for the final direction, I've the following >>>>>> observations about draft-shelby-core-coap-01 >>>>>> >>>>>> While I mostly share Zach's view of the protocol approach, and >>>>>> appreciate many aspects of the proposal, there are in my opinion >>>>>> >>>>>> =20 >>>> still >>>> >>>> =20 >>>>>> some open issues that need to be at least discussed before the >>>>>> >>>>>> =20 >>>> current >>>> >>>> =20 >>>>>> document can be selected. >>>>>> >>>>>> =20 >>>>> Of course there are plenty of open issues. Remember that working = group >>>>> >>>>> =20 >>>> documents still undertake as much change and improvement as the WG >>>> wants, so by no means is coap-01 set in stone. I would expect at = least >>>> 5-10 more revisions still along the way. Already several of your = ideas >>>> have been integrated into coap-01, and several more are under >>>> consideration, so it is coming along. Patience ;-) >>>> >>>> =20 >>>>> =20 >>>>>> In particular, I would like to highlight the following: >>>>>> >>>>>> a) As it is now, it is not possible to have a straightforward >>>>>> translation of HTTP -> CoAP and viceversa: see >>>>>> http://www.ietf.org/mail-archive/web/core/current/msg00133.html = (this >>>>>> impacts the scalability of the web service model too) >>>>>> >>>>>> =20 >>>>> In coap-01 the Method names are now identical to HTTP methods. The >>>>> >>>>> =20 >>>> Req/Res interaction is a direct translation. The URI hierarchy is >>>> compatible, and the URI binary code format we are still working on >>>> obviously. The only thing that takes some state to translate is >>>> Subscribe/Notify. But note, Subscribe/Notify takes some state no = matter >>>> how you do it, even with HTTP-HTTP there is no clean and easy way = to >>>> handle subscriptions. >>>> >>>> =20 >>>>> =20 >>>>>> b) Moreover, CoAP's implementation is not as simple as it should = be. >>>>>> I've investigated the implementation and some design choices (as >>>>>> Options) are leading to very high program complexity (ROM) on a >>>>>> MSP430-based device. >>>>>> >>>>>> =20 >>>>> This we can definitely improve, and already made several = optimizations >>>>> >>>>> =20 >>>> from -00 to -01. Here I need some very concrete proposals though. = Also >>>> remember that many things are optional, for example = subscribe/notify is >>>> not required if you don't need it. >>>> >>>> =20 >>>>> =20 >>>>>> c) Finally when comparing HTTP message size with CoAP message = size, >>>>>> the resulting compression isn't as good as you may expect. >>>>>> >>>>>> Example: >>>>>> HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B >>>>>> CoAP: 24 B with options parsing procedure requiring an added >>>>>> implementation complexity >>>>>> >>>>>> =20 >>>>> Right, that is not how it will work in practice. Working with a = real >>>>> >>>>> =20 >>>> HTTP server that HTTP header will be more complex, and on the CoAP = side >>>> you would chose shorter URLs. The biggest improvement possible here = is >>>> from using binary coded URLs of course. We need to look at a wider = range >>>> of interactions and real HTTP headers as well to check that we are >>>> efficient enough. >>>> >>>> =20 >>>>> =20 >>>>>> Addressing all these points potentially leads to major technical >>>>>> modifications (especially point a) on the current draft, hence it = is >>>>>> appropriate in my opinion to discuss these points before making = the >>>>>> final decision. >>>>>> >>>>>> =20 >>>>> I am not sure what else you have in mind for a). If we just forget >>>>> >>>>> =20 >>>> about Subscribe/Notify then you are good to go. But then you are = also >>>> not fulfilling the charter or the industry needs in that respect. >>>> >>>> =20 >>>>> Thanks, >>>>> Zach >>>>> >>>>> >>>>> =20 >>>>>> Best regards, >>>>>> >>>>>> Angelo P. Castellani >>>>>> >>>>>> >>>>>> On Mon, May 10, 2010 at 18:51, Carsten Bormann = wrote: >>>>>> >>>>>> =20 >>>>>>> The CORE WG has a milestone to select a WG document for CoAP in >>>>>>> >>>>>>> =20 >>>> April: >>>> >>>> =20 >>>>>>> http://datatracker.ietf.org/wg/core/charter/ >>>>>>> ... >>>>>>> Apr 2010 Select WG document for basis of the CoAP = protocol >>>>>>> >>>>>>> Of the various documents that have been contributed, >>>>>>> >>>>>>> =20 >>>> draft-shelby-core-coap has significant discussion, as well as the >>>> largest number of updates (including a previous version that was = still >>>> called -6lowapp-coap). >>>> >>>> =20 >>>>>>> Today, another updated version of that draft was announced. See >>>>>>> http://www.ietf.org/mail-archive/web/core/current/msg00138.html >>>>>>> for the announcement and >>>>>>> http://tools.ietf.org/html/draft-shelby-core-coap-01 >>>>>>> for the draft itself. >>>>>>> >>>>>>> However, as the authors say, there are still significant TODOs. >>>>>>> >>>>>>> Are we in a state yet where we can say whether this is the right >>>>>>> >>>>>>> =20 >>>> direction for the WG to take? >>>> >>>> =20 >>>>>>> If yes, is it the right direction? Should we adopt it as a WG >>>>>>> >>>>>>> =20 >>>> document? >>>> >>>> =20 >>>>>>> If you don't think we can say yet, is there a set of technical >>>>>>> >>>>>>> =20 >>>> decisions you would like the authors to take with priority? >>>> >>>> =20 >>>>>>> Note that once a document has become a WG document, the authors = act >>>>>>> >>>>>>> =20 >>>> as editors for the working group, making (and usually fleshing out = the >>>> details of) any change that the WG decides it needs. >>>> >>>> =20 >>>>>>> If you think we can still improve the draft, this is not an = obstacle >>>>>>> >>>>>>> =20 >>>> to making it a WG document. >>>> >>>> =20 >>>>>>> But of course we shouldn't do that if we intend to reverse its >>>>>>> >>>>>>> =20 >>>> fundamental technical direction. >>>> >>>> =20 >>>>>>> In order to stay roughly in sync with our milestones, we should >>>>>>> >>>>>>> =20 >>>> reach at a decision on how to go forward this week. >>>> >>>> =20 >>>>>>> Gruesse, Carsten >>>>>>> >>>>>>> _______________________________________________ >>>>>>> core mailing list >>>>>>> core@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/core >>>>>>> >>>>>>> >>>>>>> =20 >>>>>> _______________________________________________ >>>>>> core mailing list >>>>>> core@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/core >>>>>> >>>>>> =20 >>>>> -- >>>>> Zach Shelby, Chief Nerd, Sensinode Ltd. >>>>> http://zachshelby.org - My blog "On the Internet of Things" >>>>> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded = Internet" >>>>> Mobile: +358 40 7796297 >>>>> >>>>> >>>>> >>>>> =20 >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>> >>>> -------------------------------- >>>> Onzo is a limited company number 06097997 registered in England& = Wales. The >>>> registered office is 6 Great Newport Street, London, WC2H 7JB, = United Kingdom. >>>> >>>> This email message may contain confidential and/or privileged = information, and >>>> is intended solely for the addressee(s). If you have received this = email in >>>> error, please notify Onzo immediately. Unauthorised copying, = disclosure or >>>> distribution of the material in this email is forbidden. >>>> -------------------------------- >>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>> >>>> = ______________________________________________________________________ >>>> This email has been scanned by the MessageLabs Email Security = System. >>>> = ______________________________________________________________________ >>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>> >>>> =20 >>> =20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> -------------------------------- >> Onzo is a limited company number 06097997 registered in England& = Wales. The >> registered office is 6 Great Newport Street, London, WC2H 7JB, United = Kingdom. >> >> This email message may contain confidential and/or privileged = information, and >> is intended solely for the addressee(s). If you have received this = email in >> error, please notify Onzo immediately. Unauthorised copying, = disclosure or >> distribution of the material in this email is forbidden. >> -------------------------------- >> >> =20 > =20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From matthieu.vial@fr.non.schneider-electric.com Wed May 26 01:15:23 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9767B3A68BA; Wed, 26 May 2010 01:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.665 X-Spam-Level: X-Spam-Status: No, score=0.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krIm98tOcq7K; Wed, 26 May 2010 01:15:15 -0700 (PDT) Received: from mailX02.eud.schneider-electric.com (mailx02.eud.schneider-electric.com [205.167.7.38]) by core3.amsl.com (Postfix) with ESMTP id 3A4883A68B5; Wed, 26 May 2010 01:14:48 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX02.eud.schneider-electric.com with ESMTP id 2010052610072997-8595 ; Wed, 26 May 2010 10:07:29 +0200 In-Reply-To: To: "Charles Palmer" X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: matthieu.vial@fr.non.schneider-electric.com Date: Wed, 26 May 2010 10:14:33 +0200 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 26/05/2010 10:14:38, Itemize by SMTP Server on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 26/05/2010 10:07:30, Serialize by Router on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 26/05/2010 10:07:32 Content-type: multipart/related; Boundary="0__=4EBBFDBCDFBBF6518f9e8a93df938690918c4EBBFDBCDFBBF651" Cc: core-bounces@ietf.org, core Subject: Re: [core] Subscribe/Notify for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 08:15:25 -0000 --0__=4EBBFDBCDFBBF6518f9e8a93df938690918c4EBBFDBCDFBBF651 Content-type: multipart/alternative; Boundary="1__=4EBBFDBCDFBBF6518f9e8a93df938690918c4EBBFDBCDFBBF651" --1__=4EBBFDBCDFBBF6518f9e8a93df938690918c4EBBFDBCDFBBF651 Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=ISO-8859-1 Hi >It occurs to me that CoRE should be keeping a close eye on ZigBee SE2.= 0 work, so that it is as easy as possible for ZigBee SE to use CoRE when ready. That suggests to me that we should align with their subscribe/no= tify process. Does it mean that all CoAP nodes shall support XML/EXI? If so I am not = sure this is the right solution. I think we will achieve better interoperability between CoAP nodes with= a native solution. I also agree with Zach that alignement with HTTP is already there in CoAP. However if the native subscribe/notify is not enough extensible, many applications will fallback to a specific subscribe. Zigbee ZCL, bacnet,= have a higher degree of control for notifications than just a simple up= date (delays, values...). Maybe CORE shall provide at least guidelines to support extended controls on notification conditions. Regards, Matthieu = "Charles Palmer" = = A Envoy=E9 par : , "Zach She= lby" core-bounces@ietf = .org = cc core = Ob= jet 26/05/2010 00:23 Re: [core] Subscribe/Notify for = CoAP = = = = = = = Hi folks It occurs to me that CoRE should be keeping a close eye on ZigBee SE2.0= work, so that it is as easy as possible for ZigBee SE to use CoRE when ready. That suggests to me that we should align with their subscribe/no= tify process. Regards - Charles -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of= Paul Duffy Sent: 25 May 2010 03:48 To: Zach Shelby Cc: core Subject: Re: [core] Subscribe/Notify for CoAP Recommend something like #2, primarily to avoid introducing non HTTP method semantics, simplifying HTTP/COAP translation.gateways, etc. On 5/24/2010 11:49 AM, Zach Shelby wrote: > (thread renamed) > > We have two different paths with regard to a subscribe/notify mechani= sm for CoAP: > > 1. Use specific Subscription and Notify mechanisms for CoAP as HTTP really does not include this concept. > 1a) Notify as a message and SUBSCRIBE as a method. This is currently = used in coap-01. > 1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but we= had a good list discussion about this leading to a. In practice it doesn't = make a big difference if notification is a message or method. > > 2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2.0 proposal or GENA. > > So far we have focused on 1 in the WG, and every now and again 2 come= s up. At least I am not convinced that we need to suffer the drawbacks of= HTTP here. Anyways 2 does not help our mapping to HTTP in reality very = much as there is no standard way of doing this over HTTP. Thus a CoAP-HTTP p= roxy may end up anyways translating between multiple HTTP frameworks dependi= ng on the application. So instead of doing a CoAP Notify/Subscribe to Webh= ooks mapping, you will could end up having to do a CoAP Webhooks to HTTP GEN= A mapping. > I don't understand this last para. If CoAP sticks to the semantics of the current HTTP methods, would this not offer a fairly straightforward= translation to/from HTTP? > > From what I have heard so far 1 still seems like a wise choice, although I need to look at Webhooks more deeply. In reality many applications specify their own way of doing a push interface using REST= methods and specific payloads (ZigBee SE2.0 is such an example). That i= s just fine, and might be used instead of a specific CoAP notify/subscrib= e in that case. So 1 doesn't prevent the application using its own mechanism= , it just provides a native way for doing push. > > What do people think? > > Zach > > On May 17, 2010, at 6:44 PM, matthieu.vial@fr.non.schneider-electric.= com wrote: > > >> Hi, >> >> My comments about the subscribe/notify mechanism of Zigbee IP. >> >> Pros: >> - Derived from the webhooks concept >> - If used by CORE it will be easier to map to HTTP because it uses o= nly CRUD verbs. >> - The subscription message is extendable and could support advanced options (delays, increment, ...) >> - Only one listening port whatever the transport binding is. >> >> Cons: >> - No interoperability without well known URIs and a well defined subscription message format (Not sure CoAP draft is the right place to specify this). >> - XML/EXI is too complex to be the required format for the default subscription/notification mechanism. >> - The notification should not require a subsequent GET to retrieve t= he content. >> - Subresource subscription is redundant. >> >> Hope this could help, >> Matthieu >> >> >> "Charles Palmer" >> >> >> >> >> "Charles Palmer" >> Envoy=E9 par : core-bounces@ietf.org >> 15/05/2010 14:06 >> >> >> A >> >> "core" >> >> cc >> >> >> Objet >> >> Re: [core] Selecting a WG document for CoAP >> >> >> Dear all >> >> Those interested in the subscribe/notify discussion might like to lo= ok >> at the draft Smart Energy Profile 2.0 Application Protocol >> Specification. It is available here: >> http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20Publi= cApp >> licationProfile.aspx >> >> It manages subscribe/notify by using POST. This seems to remove the = need >> for SUBSCRIBE and notify. >> >> "Imagine a host A, which exposes a resource at http{s}://A/resource = and >> a second host B, which wishes to learn of changes to this resource. = To >> facilitate a subscription/ notification mechanism, A would expose a >> resource http{s}://A/sub and B would expose a resource http{s}://B/n= tfy. >> To subscribe to notifications regarding http{s}://A/resource, B woul= d >> send a POST to the address http{s}://A/sub/B containing the URI of t= he >> resource of interest (http{s}://A/resource) and the URI of B's >> notification resource (http{s}://B/ntfy). Following this subscriptio= n >> step, should A wish to notify B of a change to the resource addresse= d at >> http{s}://A/resource, A would send a POST to the address >> http{s}://B/ntfy containing the URI of the resource changed >> (http{s}://A/resource) and the URI of A's subscription resource >> (http{s}://A/sub/B), should A wish to change its subscription. The h= ost >> B can then query the resource (or not) at its leisure." >> >> Sleepy nodes are not allowed to subscribe, and must poll. >> >> Regards - Charles Palmer >> >> -----Original Message----- >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf= Of >> Angelo P. Castellani >> Sent: 14 May 2010 13:14 >> To: Zach Shelby >> Cc: core >> Subject: Re: [core] Selecting a WG document for CoAP >> >> Zach, >> >> thanks for the comments, but please refer to my most recent e-mail f= or >> a more specific list of technical issues I'm pointing to. >> >> I want to do only a little integration to what I've written there. >> >> In my very personal opinion, to maximize adherence with the REST mod= el >> and minimize implementation effort SUBSCRIBE and NOTIFY should be >> mapped to methods (as discussed many times together...). >> >> Uniform interface principle (Fielding PhD dissertation Section 5.1.5= , >> "The central feature that distinguishes the REST architectural style= >> [...]") states that to simplify the software architecture, resource >> interfaces/interfaces should be as general as possible. >> >> I agree with this principle in this specific case, mainly because >> handling a special message type for notify leads node software desig= n >> to a more complex architecture. >> >> The reason is that this new message type requires special handling a= nd >> introduces a complexity in the software modularization. >> >> Best, >> Angelo >> >> On Fri, May 14, 2010 at 13:06, Zach Shelby wrot= e: >> >>> Hi Angelo, >>> >>> On May 13, 2010, at 14:24 , Angelo P. Castellani wrote: >>> >>> >>>> Dear C. Bormann, all, >>>> >>>> before deciding for the final direction, I've the following >>>> observations about draft-shelby-core-coap-01 >>>> >>>> While I mostly share Zach's view of the protocol approach, and >>>> appreciate many aspects of the proposal, there are in my opinion >>>> >> still >> >>>> some open issues that need to be at least discussed before the >>>> >> current >> >>>> document can be selected. >>>> >>> Of course there are plenty of open issues. Remember that working gr= oup >>> >> documents still undertake as much change and improvement as the WG >> wants, so by no means is coap-01 set in stone. I would expect at lea= st >> 5-10 more revisions still along the way. Already several of your id= eas >> have been integrated into coap-01, and several more are under >> consideration, so it is coming along. Patience ;-) >> >>> >>>> In particular, I would like to highlight the following: >>>> >>>> a) As it is now, it is not possible to have a straightforward >>>> translation of HTTP -> CoAP and viceversa: see >>>> http://www.ietf.org/mail-archive/web/core/current/msg00133.html (t= his >>>> impacts the scalability of the web service model too) >>>> >>> In coap-01 the Method names are now identical to HTTP methods. The >>> >> Req/Res interaction is a direct translation. The URI hierarchy is >> compatible, and the URI binary code format we are still working on >> obviously. The only thing that takes some state to translate is >> Subscribe/Notify. But note, Subscribe/Notify takes some state no mat= ter >> how you do it, even with HTTP-HTTP there is no clean and easy way to= >> handle subscriptions. >> >>> >>>> b) Moreover, CoAP's implementation is not as simple as it should b= e. >>>> I've investigated the implementation and some design choices (as >>>> Options) are leading to very high program complexity (ROM) on a >>>> MSP430-based device. >>>> >>> This we can definitely improve, and already made several optimizati= ons >>> >> from -00 to -01. Here I need some very concrete proposals though. Al= so >> remember that many things are optional, for example subscribe/notify= is >> not required if you don't need it. >> >>> >>>> c) Finally when comparing HTTP message size with CoAP message size= , >>>> the resulting compression isn't as good as you may expect. >>>> >>>> Example: >>>> HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B >>>> CoAP: 24 B with options parsing procedure requiring an added >>>> implementation complexity >>>> >>> Right, that is not how it will work in practice. Working with a rea= l >>> >> HTTP server that HTTP header will be more complex, and on the CoAP s= ide >> you would chose shorter URLs. The biggest improvement possible here = is >> from using binary coded URLs of course. We need to look at a wider r= ange >> of interactions and real HTTP headers as well to check that we are >> efficient enough. >> >>> >>>> Addressing all these points potentially leads to major technical >>>> modifications (especially point a) on the current draft, hence it = is >>>> appropriate in my opinion to discuss these points before making th= e >>>> final decision. >>>> >>> I am not sure what else you have in mind for a). If we just forget >>> >> about Subscribe/Notify then you are good to go. But then you are als= o >> not fulfilling the charter or the industry needs in that respect. >> >>> Thanks, >>> Zach >>> >>> >>>> Best regards, >>>> >>>> Angelo P. Castellani >>>> >>>> >>>> On Mon, May 10, 2010 at 18:51, Carsten Bormann wrot= e: >>>> >>>>> The CORE WG has a milestone to select a WG document for CoAP in >>>>> >> April: >> >>>>> http://datatracker.ietf.org/wg/core/charter/ >>>>> ... >>>>> Apr 2010 Select WG document for basis of the CoAP protocol= >>>>> >>>>> Of the various documents that have been contributed, >>>>> >> draft-shelby-core-coap has significant discussion, as well as the >> largest number of updates (including a previous version that was sti= ll >> called -6lowapp-coap). >> >>>>> Today, another updated version of that draft was announced. See >>>>> http://www.ietf.org/mail-archive/web/core/current/msg00138.html >>>>> for the announcement and >>>>> http://tools.ietf.org/html/draft-shelby-core-coap-01 >>>>> for the draft itself. >>>>> >>>>> However, as the authors say, there are still significant TODOs. >>>>> >>>>> Are we in a state yet where we can say whether this is the right >>>>> >> direction for the WG to take? >> >>>>> If yes, is it the right direction? Should we adopt it as a WG >>>>> >> document? >> >>>>> If you don't think we can say yet, is there a set of technical >>>>> >> decisions you would like the authors to take with priority? >> >>>>> Note that once a document has become a WG document, the authors a= ct >>>>> >> as editors for the working group, making (and usually fleshing out t= he >> details of) any change that the WG decides it needs. >> >>>>> If you think we can still improve the draft, this is not an obsta= cle >>>>> >> to making it a WG document. >> >>>>> But of course we shouldn't do that if we intend to reverse its >>>>> >> fundamental technical direction. >> >>>>> In order to stay roughly in sync with our milestones, we should >>>>> >> reach at a decision on how to go forward this week. >> >>>>> Gruesse, Carsten >>>>> >>>>> _______________________________________________ >>>>> core mailing list >>>>> core@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/core >>>>> >>>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>> >>> -- >>> Zach Shelby, Chief Nerd, Sensinode Ltd. >>> http://zachshelby.org - My blog "On the Internet of Things" >>> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Intern= et" >>> Mobile: +358 40 7796297 >>> >>> >>> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> -------------------------------- >> Onzo is a limited company number 06097997 registered in England& Wa= les. The >> registered office is 6 Great Newport Street, London, WC2H 7JB, Unite= d Kingdom. >> >> This email message may contain confidential and/or privileged information, and >> is intended solely for the addressee(s). If you have received this e= mail in >> error, please notify Onzo immediately. Unauthorised copying, disclos= ure or >> distribution of the material in this email is forbidden. >> -------------------------------- >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> ____________________________________________________________________= __ >> This email has been scanned by the MessageLabs Email Security System= . >> ____________________________________________________________________= __ >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> > _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core -------------------------------- Onzo is a limited company number 06097997 registered in England & Wales= . The registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingdom. This email message may contain confidential and/or privileged informati= on, and is intended solely for the addressee(s). If you have received this emai= l in error, please notify Onzo immediately. Unauthorised copying, disclosure= or distribution of the material in this email is forbidden. -------------------------------- _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ = --1__=4EBBFDBCDFBBF6518f9e8a93df938690918c4EBBFDBCDFBBF651 Content-transfer-encoding: quoted-printable Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline
  1. request/response can be asynchronous or synchronous messages (as there is a transaction ID in there)
  2. notify is an asynchronous message
Derived methods:

I think it makes sense to add a pub/sub model as a useful mechanism for M2M.

So, looking at it the other way round: It will be entirely possible to translate whatever is currently built on HTTP to CoAP based on the above, with all its restrictions regarding synchronous and client/server transactions. What may be harder is to translate directly is a CoAP-based application to HTTP. So I guess the question is: Do we want to be hamstrung to synchronous client/server transactions as dictated by HTTP and provide a direct mapping to HTTP, then have to come up with similar kludges for asynchronous peer-to-peer transactions as has been done in numerous ways for HTTP, or do we want to define the protocol cleanly to start with and accept that some sort of transaction relaying/conversion would have to take place at a mapping node?

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com


On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote: 
Hi,
it looks to me that CoAP should use an explicit sub/notify mechanism sinc=
e this is the core of the machine-to-machine interaction model.
HTTP suffers of this lack and we have seen a plethora of solutions to giv=
e an asynch taste to it. Webhooks and websockets are only the lasts of th=
e list.
As someone has already pointed out on this list, it is theoretically poss=
ible to describe sub/notify using only CRUD methods but it looks a little=
 bit tricky and verbose.

Now we have a chance to build from scratch a new protocol with and I thin=
k using explicit sub/notify methods with a clear and well defined semanti=
c is the best option. It is easily understanding from every developer and=
 will prevent to build other fanny solutions on top of the CoAP. HTTP doe=
s not have this well defined semantic and (for hundreds of other reasons =
also) it is not used as wide protocol for machine-to-machine communicatio=
n.

CoAP - as binary protocol - and with an explicit asynch model has a chanc=
e to be a really wide protocol for M2M communication not only for constra=
ined environments.

my 2 cents

- adriano

-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On =
Behalf Of Paul Duffy (paduffy)
Sent: mercoledì 26 maggio 2010 0.47
To: Zach Shelby
Cc: core
Subject: Re: [core] Subscribe/Notify for CoAP

On 5/25/2010 6:41 PM, Zach Shelby wrote:
  
Hi,

On May 26, 2010, at 12:23 AM, Charles Palmer wrote:

  =20
    
Hi folks

It occurs to me that CoRE should be keeping a close eye on ZigBee SE2.0 w=
ork, so that it is as easy as possible for ZigBee SE to use CoRE when rea=
dy. That suggests to me that we should align with their subscribe/notify =
process.

    =20
      
I am not sure I understand that. I mean, ZigBee SE2.0 =
is defining an application specific subscribe/notify mechanism for that p=
urpose so far for HTTP. This uses standard HTTP methods and some custom p=
ayload and REST interfaces. CoAP Req/Res is already totally compatible wi=
th SE2.0 in that respect, so alignment is already OK there. Nothing stopp=
ing someone from using SE2.0 over CoAP.

Specifying a native susbcription/notify into CoAP is another matter. We c=
an't adopt a solution specific to one application as that won't solve the=
 problems of other applications nor general HTTP mapping at all (probably=
 would make it worse). It seems that for the near future there will be a =
bunch of HTTP push mechanisms in use without any clear standard appearing=
 - or am I wrong there?
  =20
    


If COAP extends HTTP semantics with new subscription methods, it will=20
not be possible to easily interchange HTTP/COAP, and translation=20
gateways will become more complex to implement.



  
Zach

  =20
    
Regards - Charles


-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On =
Behalf Of Paul Duffy
Sent: 25 May 2010 03:48
To: Zach Shelby
Cc: core
Subject: Re: [core] Subscribe/Notify for CoAP

Recommend something like #2, primarily to avoid introducing non HTTP
method semantics, simplifying HTTP/COAP translation.gateways, etc.


On 5/24/2010 11:49 AM, Zach Shelby wrote:
    =20
      
(thread renamed)

We have two different paths with regard to a subscribe/notify mechanism f=
or CoAP:

1. Use specific Subscription and Notify mechanisms for CoAP as HTTP reall=
y does not include this concept.
1a) Notify as a message and SUBSCRIBE as a method. This is currently used=
 in coap-01.
1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but we had=
 a good list discussion about this leading to a. In practice it doesn't m=
ake a big difference if notification is a message or method.

2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2.0 prop=
osal or GENA.

So far we have focused on 1 in the WG, and every now and again 2 comes up=
=2E At least I am not convinced that we need to suffer the drawbacks of H=
TTP here. Anyways 2 does not help our mapping to HTTP in reality very muc=
h as there is no standard way of doing this over HTTP. Thus a CoAP-HTTP p=
roxy may end up anyways translating between multiple HTTP frameworks depe=
nding on the application. So instead of doing a CoAP Notify/Subscribe to =
Webhooks mapping, you will could end up having to do a CoAP Webhooks to H=
TTP GENA mapping.

      =20
        
I don't understand this last para.  If CoAP sticks to the semantics of
the current HTTP methods, would this not offer a fairly straightforward
translation to/from HTTP?


    =20
      
 From what I have heard so far 1 still seems lik=
e a wise choice, although I need to look at Webhooks more deeply. In real=
ity many applications specify their own way of doing a push interface usi=
ng REST methods and specific payloads (ZigBee SE2.0 is such an example). =
That is just fine, and might be used instead of a specific CoAP notify/su=
bscribe in that case. So 1 doesn't prevent the application using its own =
mechanism, it just provides a native way for doing push.
        =20
          
What do people think?

Zach

On May 17, 2010, at 6:44 PM, matthieu.vial@fr.non=
=2Eschneider-electric.com wrote:


      =20
        
Hi,

My comments about the subscribe/notify mechanism of Zigbee IP.

Pros:
- Derived from the webhooks concept
- If used by CORE it will be easier to map to HTTP because it uses only C=
RUD verbs.
- The subscription message is extendable and could support advanced optio=
ns (delays, increment, ...)
- Only one listening port whatever the transport binding is.

Cons:
- No interoperability without well known URIs and a well defined subscrip=
tion message format (Not sure CoAP draft is the right place to specify th=
is).
- XML/EXI is too complex to be the required format for the default subscr=
iption/notification mechanism.
- The notification should not require a subsequent GET to retrieve the co=
ntent.
- Subresource subscription is redundant.

Hope this could help,
Matthieu


<graycol.gif>"Charles Palmer"<charles.palmer@onzo.com>




"Charles Palmer"<charles.palmer@onzo.com>
Envoyé par : core-bounces@ietf.org
15/05/2010 14:06

<ecblank.gif>
A
<ecblank.gif>
"core"&l=
t;core@ietf.org>
<ecblank.gif>
cc
<ecblank.gif>
<ecblank.gif>
Objet
<ecblank.gif>
Re: [core] Selecting a WG document for CoAP
<ecblank.gif>	<ecblank.gif>

Dear all

Those interested in the subscribe/notify discussion might like to look
at the draft Smart Energy Profile 2.0 Application Protocol
Specification. It is available here:
http://zigbee.org/Markets/Zig=
BeeSmartEnergy/ZigBeeSmartEnergy20PublicApp
licationProfile.aspx

It manages subscribe/notify by using POST. This seems to remove the need
for SUBSCRIBE and notify.

"Imagine a host A, which exposes a resource at http{s}://A/resource and
a second host B, which wishes to learn of changes to this resource. To
facilitate a subscription/ notification mechanism, A would expose a
resource http{s}://A/sub and B would expose a resource http{s}://B/ntfy.
To subscribe to notifications regarding http{s}://A/resource, B would
send a POST to the address http{s}://A/sub/B containing the URI of the
resource of interest (http{s}://A/resource) and the URI of B's
notification resource (http{s}://B/ntfy). Following this subscription
step, should A wish to notify B of a change to the resource addressed at
http{s}://A/resource, A would send a POST to the address
http{s}://B/ntfy containing the URI of the resource changed
(http{s}://A/resource) and the URI of A's subscription resource
(http{s}://A/sub/B), should A wish to change its subscription. The host
B can then query the resource (or not) at its leisure."

Sleepy nodes are not allowed to subscribe, and must poll.

Regards - Charles Palmer

-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On =
Behalf Of
Angelo P. Castellani
Sent: 14 May 2010 13:14
To: Zach Shelby
Cc: core
Subject: Re: [core] Selecting a WG document for CoAP

Zach,

thanks for the comments, but please refer to my most recent e-mail for
a more specific list of technical issues I'm pointing to.

I want to do only a little integration to what I've written there.

In my very personal opinion, to maximize adherence with the REST model
and minimize implementation effort SUBSCRIBE and NOTIFY should be
mapped to methods (as discussed many times together...).

Uniform interface principle (Fielding PhD dissertation Section 5.1.5,
"The central feature that distinguishes the REST architectural style
[...]") states that to simplify the software architecture, resource
interfaces/interfaces should be as general as possible.

I agree with this principle in this specific case, mainly because
handling a special message type for notify leads node software design
to a more complex architecture.

The reason is that this new message type requires special handling and
introduces a complexity in the software modularization.

Best,
Angelo

On Fri, May 14, 2010 at 13:06, Zach Shelby<zach@sensinode.com>   w=
rote:

        =20
          
Hi Angelo,

On May 13, 2010, at 14:24 , Angelo P. Castellani wrote:


          =20
            
Dear C. Bormann, all,

before deciding for the final direction, I've the following
observations about draft-shelby-core-coap-01

While I mostly share Zach's view of the protocol approach, and
appreciate many aspects of the proposal, there are in my opinion

            =20
              
still

        =20
          
some open issues that need to be at least di=
scussed before the

            =20
              
current

        =20
          
document can be selected.

            =20
              
Of course there are plenty of open issues. Rem=
ember that working group

          =20
            
documents still undertake as much change and imp=
rovement as the WG
wants, so by no means is coap-01 set in stone. I would expect at least
5-10 more revisions still along the way.  Already several of your ideas
have been integrated into coap-01, and several more are under
consideration, so it is coming along. Patience ;-)

        =20
          
          =20
            
In particular, I would like to highlight the=
 following:

a) As it is now, it is not possible to have a straightforward
translation of HTTP ->   CoAP and viceversa: see
http://www.ietf.org/mail-archive/web/c=
ore/current/msg00133.html (this
impacts the scalability of the web service model too)

            =20
              
In coap-01 the Method names are now identical =
to HTTP methods. The

          =20
            
Req/Res interaction is a direct translation. The=
 URI hierarchy is
compatible, and the URI binary code format we are still working on
obviously. The only thing that takes some state to translate is
Subscribe/Notify. But note, Subscribe/Notify takes some state no matter
how you do it, even with HTTP-HTTP there is no clean and easy way to
handle subscriptions.

        =20
          
          =20
            
b) Moreover, CoAP's implementation is not as=
 simple as it should be.
I've investigated the implementation and some design choices (as
Options) are leading to very high program complexity (ROM) on a
MSP430-based device.

            =20
              
This we can definitely improve, and already ma=
de several optimizations

          =20
            
from -00 to -01. Here I need some very concrete =
proposals though. Also
remember that many things are optional, for example subscribe/notify is
not required if you don't need it.

        =20
          
          =20
            
c) Finally when comparing HTTP message size =
with CoAP message size,
the resulting compression isn't as good as you may expect.

Example:
HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B
CoAP: 24 B with options parsing procedure requiring an added
implementation complexity

            =20
              
Right, that is not how it will work in practic=
e. Working with a real

          =20
            
HTTP server that HTTP header will be more comple=
x, and on the CoAP side
you would chose shorter URLs. The biggest improvement possible here is
from using binary coded URLs of course. We need to look at a wider range
of interactions and real HTTP headers as well to check that we are
efficient enough.

        =20
          
          =20
            
Addressing all these points potentially lead=
s to major technical
modifications (especially point a) on the current draft, hence it is
appropriate in my opinion to discuss these points before making the
final decision.

            =20
              
I am not sure what else you have in mind for a=
). If we just forget

          =20
            
about Subscribe/Notify then you are good to go. =
But then you are also
not fulfilling the charter or the industry needs in that respect.

        =20
          
Thanks,
Zach


          =20
            
Best regards,

Angelo P. Castellani


On Mon, May 10, 2010 at 18:51, Carsten Bormann<cabo@tzi.org>   wrote:

            =20
              
The CORE WG has a milestone to select a WG=
 document for CoAP in

              =20
                
April:

        =20
          
http://datatracker.ietf.or=
g/wg/core/charter/
=2E..
Apr 2010        Select WG document for basis of the CoAP protocol

Of the various documents that have been contributed,

              =20
                
draft-shelby-core-coap has significant discussio=
n, as well as the
largest number of updates (including a previous version that was still
called -6lowapp-coap).

        =20
          
Today, another updated version of that dra=
ft was announced.  See
http://www.ietf.org/mail-archive/web/c=
ore/current/msg00138.html
for the announcement and
http://tools.ietf.org/html/draft-shelby-core-coap=
-01
for the draft itself.

However, as the authors say, there are still significant TODOs.

Are we in a state yet where we can say whether this is the right

              =20
                
direction for the WG to take?

        =20
          
If yes, is it the right direction?  Should=
 we adopt it as a WG

              =20
                
document?

        =20
          
If you don't think we can say yet, is ther=
e a set of technical

              =20
                
decisions you would like the authors to take wit=
h priority?

        =20
          
Note that once a document has become a WG =
document, the authors act

              =20
                
as editors for the working group, making (and us=
ually fleshing out the
details of) any change that the WG decides it needs.

        =20
          
If you think we can still improve the draf=
t, this is not an obstacle

              =20
                
to making it a WG document.

        =20
          
But of course we shouldn't do that if we i=
ntend to reverse its

              =20
                
fundamental technical direction.

        =20
          
In order to stay roughly in sync with our =
milestones, we should

              =20
                
reach at a decision on how to go forward this we=
ek.

        =20
          
Gruesse, Carsten

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


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

            =20
              
--
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://=
zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet=
"
Mobile: +358 40 7796297



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

--------------------------------
Onzo is a limited company number 06097997 registered in England&   Wa=
les. The
registered office is 6 Great Newport Street, London, WC2H 7JB, United Kin=
gdom.

This email message may contain confidential and/or privileged information=
, and
is intended solely for the addressee(s). If you have received this email =
in
error, please notify Onzo immediately. Unauthorised copying, disclosure o=
r
distribution of the material in this email is forbidden.
--------------------------------

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

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________

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

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

--------------------------------
Onzo is a limited company number 06097997 registered in England&  Wal=
es. The
registered office is 6 Great Newport Street, London, WC2H 7JB, United Kin=
gdom.

This email message may contain confidential and/or privileged information=
, and
is intended solely for the addressee(s). If you have received this email =
in
error, please notify Onzo immediately. Unauthorised copying, disclosure o=
r
distribution of the material in this email is forbidden.
--------------------------------

    =20
      
  =20
    
_______________________________________________
core mailing list
core@=
ietf.org
https://www.ietf.org/mailman/listinfo/core
_______________________________________________
core mailing list
core@=
ietf.org
https://www.ietf.org/mailman/listinfo/core
--------------010705060600050603060108-- --------------ms090808020503020308020401 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA1 MjYxODA5MjNaMCMGCSqGSIb3DQEJBDEWBBQWvjguKjeGfRJAc5GDG6lPK5DaIjBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAHMpLB3VgPQknKDEk7M8TRd2mqXQsJCNFnSh5SpvXSdyr40HI17vTYdBmPeadw7kb+l2 hQHzoqxml0nFodBYCrOVYfOIXUnTsilMHVCRAcTmvp/9GswGwVi5aL3vulRNZ166YiOFGL3R 8M9DxcnRfy0kyLw5CLJSdYIkklDmeuwHpC4641ev5XTA0IKmddpvJMAGNg34/7bJCPIb6HjM tCsXVsrwByvqrTKSm6grSj28/RNqykPYr0ZWHcovQ9fa6xEO9KFuuQT8Ph8tn6gDYfHkv/3h fVqPFlTkhkgCZZb9nEceDBDsVVSs0skUzVlqdS+2zsvGbuZ8BCwsysAchesAAAAAAAA= --------------ms090808020503020308020401-- From fluffy@cisco.com Wed May 26 20:05:55 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D55FD3A63C9 for ; Wed, 26 May 2010 20:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.566 X-Spam-Level: X-Spam-Status: No, score=-108.566 tagged_above=-999 required=5 tests=[AWL=-0.567, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03Pj1NlewSdX for ; Wed, 26 May 2010 20:05:54 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D90993A67E2 for ; Wed, 26 May 2010 20:05:54 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAO9+/UurR7Hu/2dsb2JhbACeJnGmZpl/gm4Igh0Eg0I X-IronPort-AV: E=Sophos;i="4.53,308,1272844800"; d="scan'208";a="203412012" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 27 May 2010 03:05:38 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o4R35aeF004959; Thu, 27 May 2010 03:05:37 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Wed, 26 May 2010 21:05:36 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <0924B0BC-BFA7-40E5-8ED9-1AF27533F401@cisco.com> References: To: Peter Bigot X-Mailer: Apple Mail (2.1078) Cc: core@ietf.org Subject: Re: [core] Date option in draft-shelby-core-coap-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 03:05:56 -0000 Peter,=20 These are all excellent points and I think I (not Zach) am partial to = blame for the current text... I just pointed him towards some cut and = pasted text from some other RFC - I figured we needed something in the = draft as a starting point to get this conversation going. Dealing with = time is always complicated and even more so in this constrained = environment. If we start by looking at our constraints, I suspect we = come to the conclusions you suggested below.=20 My guess is that if we asked everyone, most people would say that we = could not require a COAP node to do any of the following. Some nodes = might do these but it would not be required 1) run NTP=20 2) have a table of when leap seconds were going to happened and way to = keep that table up to date=20 3) have a time source was more accurate than a simple non temperature = compensated crystal=20 4) have any clue about timezones=20 I really have no idea how some of these devices are even going to set = their time when they first get turned on other than perhaps looking at = the time of some other node.=20 All this leads me to wonder if we could get away with only having = relative times in CoAP.=20 On May 13, 2010, at 8:35 AM, Peter Bigot wrote: > Section 3.3.6 introduces a Date option that can be used to timestamp a = measurement. The description specifies that leap seconds are excluded. = It's not crystal clear to me what "excluded" means in this situation. I = don't see any discussion in the list archive. >=20 > Pretending leap seconds don't exist (one sense of exclude) makes sense = as it trivializes the translation between POSIX- time representations = (seconds since 1970-01-01T00:00:00Z) and UTC-aligned wall clock times = that people normally deal with: this becomes simple division and modulus = operations with a little hassle imposed by leap years. On the other = hand, the representation can express times that do not exist (23:59:59 = when a negative leap second takes effect), and can be ambiguous = (23:59:60 or a repeated 23:59:59 when a positive leap second takes = effect). More importantly, simple subtraction of two event times does = not necessarily result in the duration of the event. >=20 > For an in-development system to which CoAP could apply, my = recommendation was to use times expressed as atomic seconds since the = POSIX epoch (thereby excluding leap second adjustments from the value). = This does mean that translation to civil time requires knowledge of the = number of leap seconds in effect at that time (currently UTC is 24 = seconds behind TAI relative to the POSIX epoch). In return, devices = that maintain an internal clock used to timestamp events do not need to = be updated to take into account leap second adjustments, which can take = a fair amount of code and support infrastructure to handle a very rare = event. It also trivializes calculation of event durations, even when = the duration spans application of a leap second. >=20 > My feeling is that any software component that needs to translate = between between device time and civil time can be expected to account = for leap seconds, while those that are operating in a constrained = environment would best be isolated from their effects. Note that GPS = time is similarly measured in atomic seconds since an epoch = (1980-01-06T00:00:00Z). >=20 > So, do Date values in the proposed COAP match what you get from = running "date +%s" on a Linux system synchronized to UTC, or are they = that value plus 24? I read the draft as specifying the latter, which is = my preference, but anticipate great confusion from people who haven't = had to deal with leap seconds before. >=20 > Recommend changing "number of seconds, excluding leap seconds, after" = to "number of (atomic) seconds since". I suspect that using a EPOCH of 2010 instead of 1970 would reduce the = bits we need and also, more importantly, encourage people not to confuse = these times with "date +%s" times.=20 >=20 > Peter > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From pab@peoplepowerco.com Thu May 27 07:14:28 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 517DA3A6AEC for ; Thu, 27 May 2010 07:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.624 X-Spam-Level: X-Spam-Status: No, score=0.624 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91SVVEOB0RpR for ; Thu, 27 May 2010 07:14:24 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by core3.amsl.com (Postfix) with ESMTP id 5CD273A6943 for ; Thu, 27 May 2010 07:14:22 -0700 (PDT) Received: by fxm20 with SMTP id 20so24715fxm.27 for ; Thu, 27 May 2010 07:14:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.102.12.30 with SMTP id 30mr6832855mul.43.1274969648720; Thu, 27 May 2010 07:14:08 -0700 (PDT) Received: by 10.103.212.5 with HTTP; Thu, 27 May 2010 07:14:08 -0700 (PDT) In-Reply-To: <0924B0BC-BFA7-40E5-8ED9-1AF27533F401@cisco.com> References: <0924B0BC-BFA7-40E5-8ED9-1AF27533F401@cisco.com> Date: Thu, 27 May 2010 09:14:08 -0500 Message-ID: From: Peter Bigot To: Cullen Jennings Content-Type: multipart/alternative; boundary=00163646b9c802eb2e0487940160 Cc: core@ietf.org Subject: Re: [core] Date option in draft-shelby-core-coap-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 14:14:28 -0000 --00163646b9c802eb2e0487940160 Content-Type: text/plain; charset=ISO-8859-1 I doubt relative times would work, since every device would have its own zero, making coordination difficult. I agree with your assessment of what can be asked of COAP nodes with respect to time. Any requirement that the nodes operate with civil time (or UTC) would require something like 1, 2, or 4. If the phrasing I suggested were adopted, it would be the responsibility of whatever bridges between COAP and less constrained environments to make the necessary adjustments. 3 is more of an issue, as it implies the times on COAP nodes may drift so much leap days (let alone seconds) would be in the noise. But we have to draw the line somewhere. I recommend retaining the POSIX epoch of 1970. Moving to 2010 would not help much, as there are 86400 seconds in a day and 31536000 in a year, meaning neither 16 nor 24 bits are adequate for measuring reasonable time periods. Once we're at 32 bits, we might as well keep a standard epoch rather than create a new one. (We could move to GPS time, which has a different epoch and a different UTC offset, but I suspect most developers of COAP applications will be more familiar with POSIX.) Peter On Wed, May 26, 2010 at 10:05 PM, Cullen Jennings wrote: > > Peter, > > These are all excellent points and I think I (not Zach) am partial to blame > for the current text... I just pointed him towards some cut and pasted text > from some other RFC - I figured we needed something in the draft as a > starting point to get this conversation going. Dealing with time is always > complicated and even more so in this constrained environment. If we start by > looking at our constraints, I suspect we come to the conclusions you > suggested below. > > My guess is that if we asked everyone, most people would say that we could > not require a COAP node to do any of the following. Some nodes might do > these but it would not be required > > 1) run NTP > 2) have a table of when leap seconds were going to happened and way to keep > that table up to date > 3) have a time source was more accurate than a simple non temperature > compensated crystal > 4) have any clue about timezones > > I really have no idea how some of these devices are even going to set their > time when they first get turned on other than perhaps looking at the time of > some other node. > > All this leads me to wonder if we could get away with only having relative > times in CoAP. > > On May 13, 2010, at 8:35 AM, Peter Bigot wrote: > > > Section 3.3.6 introduces a Date option that can be used to timestamp a > measurement. The description specifies that leap seconds are excluded. > It's not crystal clear to me what "excluded" means in this situation. I > don't see any discussion in the list archive. > > > > Pretending leap seconds don't exist (one sense of exclude) makes sense as > it trivializes the translation between POSIX- time representations (seconds > since 1970-01-01T00:00:00Z) and UTC-aligned wall clock times that people > normally deal with: this becomes simple division and modulus operations with > a little hassle imposed by leap years. On the other hand, the > representation can express times that do not exist (23:59:59 when a negative > leap second takes effect), and can be ambiguous (23:59:60 or a repeated > 23:59:59 when a positive leap second takes effect). More importantly, > simple subtraction of two event times does not necessarily result in the > duration of the event. > > > > For an in-development system to which CoAP could apply, my recommendation > was to use times expressed as atomic seconds since the POSIX epoch (thereby > excluding leap second adjustments from the value). This does mean that > translation to civil time requires knowledge of the number of leap seconds > in effect at that time (currently UTC is 24 seconds behind TAI relative to > the POSIX epoch). In return, devices that maintain an internal clock used > to timestamp events do not need to be updated to take into account leap > second adjustments, which can take a fair amount of code and support > infrastructure to handle a very rare event. It also trivializes calculation > of event durations, even when the duration spans application of a leap > second. > > > > My feeling is that any software component that needs to translate between > between device time and civil time can be expected to account for leap > seconds, while those that are operating in a constrained environment would > best be isolated from their effects. Note that GPS time is similarly > measured in atomic seconds since an epoch (1980-01-06T00:00:00Z). > > > > So, do Date values in the proposed COAP match what you get from running > "date +%s" on a Linux system synchronized to UTC, or are they that value > plus 24? I read the draft as specifying the latter, which is my preference, > but anticipate great confusion from people who haven't had to deal with leap > seconds before. > > > > Recommend changing "number of seconds, excluding leap seconds, after" to > "number of (atomic) seconds since". > > I suspect that using a EPOCH of 2010 instead of 1970 would reduce the bits > we need and also, more importantly, encourage people not to confuse these > times with "date +%s" times. > > > > > Peter > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > --00163646b9c802eb2e0487940160 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I doubt relative times would work, since every device would have its own ze= ro, making coordination difficult.

I agree with your assessment of w= hat can be asked of COAP nodes with respect to time.=A0 Any requirement tha= t the nodes operate with civil time (or UTC) would require something like 1= , 2, or 4.
If the phrasing I suggested were adopted, it would be the responsibility of= whatever bridges between COAP and less constrained environments to make th= e necessary adjustments.

3 is more of an issue, as it implies the ti= mes on COAP nodes may drift so much leap days (let alone seconds) would be = in the noise.=A0 But we have to draw the line somewhere.

I recommend retaining the POSIX epoch of 1970.=A0 Moving to 2010 would = not help much, as there are 86400 seconds in a day and 31536000 in a year, = meaning neither 16 nor 24 bits are adequate for measuring reasonable time p= eriods.=A0 Once we're at 32 bits, we might as well keep a standard epoc= h rather than create a new one.=A0 (We could move to GPS time, which has a = different epoch and a different UTC offset, but I suspect most developers o= f COAP applications will be more familiar with POSIX.)

Peter

On Wed, May 26, 2010 at 10:05 P= M, Cullen Jennings <fluffy@cisco.com> wrote:

Peter,

These are all excellent points and I think I (not Zach) am partial to blame= for the current text... I just pointed him towards some cut and pasted tex= t from some other RFC - I figured we needed something in the draft as a sta= rting point to get this conversation going. Dealing with time is always com= plicated and even more so in this constrained environment. If we start by l= ooking at our constraints, I suspect we come to the conclusions you suggest= ed below.

My guess is that if we asked everyone, most people would say that we could = not require a COAP node to do any of the following. Some nodes might do the= se but it would not be required

1) run NTP
2) have a table of when leap seconds were going to happened and way to keep= that table up to date
3) have a time source was more accurate than a simple non temperature compe= nsated crystal
4) have any clue about timezones

I really have no idea how some of these devices are even going to set their= time when they first get turned on other than perhaps looking at the time = of some other node.

All this leads me to wonder if we could get away with only having relative = times in CoAP.

On May 13, 2010, at 8:35 AM, Peter Bigot wrote:

> Section 3.3.6 introduces a Date option that can be used to timestamp a= measurement. =A0The description specifies that leap seconds are excluded. = =A0It's not crystal clear to me what "excluded" means in this= situation. =A0I don't see any discussion in the list archive.
>
> Pretending leap seconds don't exist (one sense of exclude) makes s= ense as it trivializes the translation between POSIX- time representations = (seconds since 1970-01-01T00:00:00Z) and UTC-aligned wall clock times that = people normally deal with: this becomes simple division and modulus operati= ons with a little hassle imposed by leap years. =A0On the other hand, the r= epresentation can express times that do not exist (23:59:59 when a negative= leap second takes effect), and can be ambiguous (23:59:60 or a repeated 23= :59:59 when a positive leap second takes effect). =A0More importantly, simp= le subtraction of two event times does not necessarily result in the durati= on of the event.
>
> For an in-development system to which CoAP could apply, my recommendat= ion was to use times expressed as atomic seconds since the POSIX epoch (the= reby excluding leap second adjustments from the value). =A0This does mean t= hat translation to civil time requires knowledge of the number of leap seco= nds in effect at that time (currently UTC is 24 seconds behind TAI relative= to the POSIX epoch). =A0In return, devices that maintain an internal clock= used to timestamp events do not need to be updated to take into account le= ap second adjustments, which can take a fair amount of code and support inf= rastructure to handle a very rare event. =A0It also trivializes calculation= of event durations, even when the duration spans application of a leap sec= ond.
>
> My feeling is that any software component that needs to translate betw= een between device time and civil time can be expected to account for leap = seconds, while those that are operating in a constrained environment would = best be isolated from their effects. =A0Note that GPS time is similarly mea= sured in atomic seconds since an epoch (1980-01-06T00:00:00Z).
>
> So, do Date values in the proposed COAP match what you get from runnin= g "date +%s" on a Linux system synchronized to UTC, or are they t= hat value plus 24? =A0I read the draft as specifying the latter, which is m= y preference, but anticipate great confusion from people who haven't ha= d to deal with leap seconds before.
>
> Recommend changing "number of seconds, excluding leap seconds, af= ter" to "number of (atomic) seconds since".

I suspect that using a EPOCH of 2010 instead of 1970 would redu= ce the bits we need and also, more importantly, encourage people not to con= fuse these times with "date +%s" =A0times.

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


Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/c= ri/index.html




--00163646b9c802eb2e0487940160-- From apezzuto@cisco.com Thu May 27 11:09:20 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 856703A6BB9 for ; Thu, 27 May 2010 11:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.001 X-Spam-Level: * X-Spam-Status: No, score=1.001 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raV8MhbeNbp2 for ; Thu, 27 May 2010 11:09:17 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id E3EF43A68BB for ; Thu, 27 May 2010 11:08:46 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQBAOtR/kuQ/uCWe2dsb2JhbACBP4RMmBcVAQEWIgYcqEKaLwKCc4IeBA X-IronPort-AV: E=Sophos;i="4.53,312,1272844800"; d="scan'208,217";a="7918001" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 27 May 2010 17:29:27 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4RI8ZwJ013693; Thu, 27 May 2010 18:08:35 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 May 2010 20:08:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAFDC7.9FD53178" Date: Thu, 27 May 2010 20:08:34 +0200 Message-ID: <0D212BD466921646B58854FB79092CEC021F4C22@XMB-AMS-106.cisco.com> In-Reply-To: <4BFD63D3.3040207@gridmerge.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Subscribe/Notify for CoAP Thread-Index: Acr8/rNvbeGmOPYGQ42yb5K4ZXtbngAxbdrQ References: <3602E0C6-1E2E-4164-A208-A874128325AF@sensinode.com><4BFB3A66.5080700@cisco.com><324781C3-5548-474D-8995-EC327ED08209@sensinode.com> <4BFC5368.2010602@cisco.com> <0D212BD466921646B58854FB79092CEC0216121C@XMB-AMS-106.cisco.com> <4BFD63D3.3040207@gridmerge.com> From: "Adriano Pezzuto (apezzuto)" To: X-OriginalArrivalTime: 27 May 2010 18:08:35.0825 (UTC) FILETIME=[A0017610:01CAFDC7] Cc: core Subject: Re: [core] Subscribe/Notify for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 18:09:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAFDC7.9FD53178 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Robert, =20 in my personal opinion, the option 1a) brings some sort of ambiguity to = CoAP specs. =20 My be my understatement of new CoAP specs is not so deep, but now we = have 5 methods and 3 message types: request, response and notify. Which = methods are allowed with which messages types? I suppose you have to use PUT/POST method with notify message for asynch = data notification. How to make a subscribe? I suppose you would use a = SUBSCRIBE method with request/response message or SUBSCRIBE with notify = message? Also what about POST/DELETE methods in a notify message? They = not make any sense.. =20 I think the choice is between: option 1) -> only CRUD methods and option = 1b) -> CRUD + SUB/NOTIFY methods, keeping in mind cost/benefits of both = solutions. =20 Adriano =20 From: Robert Cragie [mailto:robert.cragie@gridmerge.com]=20 Sent: mercoled=EC 26 maggio 2010 20.09 To: Adriano Pezzuto (apezzuto) Cc: Paul Duffy (paduffy); Zach Shelby; core Subject: Re: [core] Subscribe/Notify for CoAP =20 Hi Adrian, I would also prefer to keep the protocol in CoAP asynchronous. You can = always map an asynchronous protocol to a synchronous one but, as we see = in HTTP, it always ends up as a kludge to do it the other way round. The = efforts which have been gone to to make HTTP quasi-asynchronous via all = the schemes mentioned below and many more besides (all non-interoperable = of course) is testament to how important this is for M2M communication. So, back to Zach's list, I favor 1a) for the following reasons: Foundation level of messages: 1. request/response can be asynchronous or synchronous messages (as = there is a transaction ID in there) 2. notify is an asynchronous message Derived methods: I think it makes sense to add a pub/sub model as a useful mechanism for = M2M. So, looking at it the other way round: It will be entirely possible to = translate whatever is currently built on HTTP to CoAP based on the = above, with all its restrictions regarding synchronous and client/server = transactions. What may be harder is to translate directly is a = CoAP-based application to HTTP. So I guess the question is: Do we want = to be hamstrung to synchronous client/server transactions as dictated by = HTTP and provide a direct mapping to HTTP, then have to come up with = similar kludges for asynchronous peer-to-peer transactions as has been = done in numerous ways for HTTP, or do we want to define the protocol = cleanly to start with and accept that some sort of transaction = relaying/conversion would have to take place at a mapping node? Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com =20 On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote:=20 Hi, it looks to me that CoAP should use an explicit sub/notify mechanism = since this is the core of the machine-to-machine interaction model. HTTP suffers of this lack and we have seen a plethora of solutions to = give an asynch taste to it. Webhooks and websockets are only the lasts = of the list. As someone has already pointed out on this list, it is theoretically = possible to describe sub/notify using only CRUD methods but it looks a = little bit tricky and verbose. =20 Now we have a chance to build from scratch a new protocol with and I = think using explicit sub/notify methods with a clear and well defined = semantic is the best option. It is easily understanding from every = developer and will prevent to build other fanny solutions on top of the = CoAP. HTTP does not have this well defined semantic and (for hundreds of = other reasons also) it is not used as wide protocol for = machine-to-machine communication. =20 CoAP - as binary protocol - and with an explicit asynch model has a = chance to be a really wide protocol for M2M communication not only for = constrained environments. =20 my 2 cents =20 - adriano =20 -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Paul Duffy (paduffy) Sent: mercoled=EC 26 maggio 2010 0.47 To: Zach Shelby Cc: core Subject: Re: [core] Subscribe/Notify for CoAP =20 On 5/25/2010 6:41 PM, Zach Shelby wrote: =20 Hi, =20 On May 26, 2010, at 12:23 AM, Charles Palmer wrote: =20 =20 =20 Hi folks =20 It occurs to me that CoRE should be keeping a close eye on ZigBee = SE2.0 work, so that it is as easy as possible for ZigBee SE to use CoRE = when ready. That suggests to me that we should align with their = subscribe/notify process. =20 =20 =20 I am not sure I understand that. I mean, ZigBee SE2.0 is defining an = application specific subscribe/notify mechanism for that purpose so far = for HTTP. This uses standard HTTP methods and some custom payload and = REST interfaces. CoAP Req/Res is already totally compatible with SE2.0 = in that respect, so alignment is already OK there. Nothing stopping = someone from using SE2.0 over CoAP. =20 Specifying a native susbcription/notify into CoAP is another matter. We = can't adopt a solution specific to one application as that won't solve = the problems of other applications nor general HTTP mapping at all = (probably would make it worse). It seems that for the near future there = will be a bunch of HTTP push mechanisms in use without any clear = standard appearing - or am I wrong there? =20 =20 =20 =20 =20 If COAP extends HTTP semantics with new subscription methods, it will=20 not be possible to easily interchange HTTP/COAP, and translation=20 gateways will become more complex to implement. =20 =20 =20 =20 Zach =20 =20 =20 Regards - Charles =20 =20 -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Paul Duffy Sent: 25 May 2010 03:48 To: Zach Shelby Cc: core Subject: Re: [core] Subscribe/Notify for CoAP =20 Recommend something like #2, primarily to avoid introducing non HTTP method semantics, simplifying HTTP/COAP translation.gateways, etc. =20 =20 On 5/24/2010 11:49 AM, Zach Shelby wrote: =20 =20 (thread renamed) =20 We have two different paths with regard to a subscribe/notify = mechanism for CoAP: =20 1. Use specific Subscription and Notify mechanisms for CoAP as HTTP = really does not include this concept. 1a) Notify as a message and SUBSCRIBE as a method. This is currently = used in coap-01. 1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but we = had a good list discussion about this leading to a. In practice it = doesn't make a big difference if notification is a message or method. =20 2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2.0 = proposal or GENA. =20 So far we have focused on 1 in the WG, and every now and again 2 = comes up. At least I am not convinced that we need to suffer the = drawbacks of HTTP here. Anyways 2 does not help our mapping to HTTP in = reality very much as there is no standard way of doing this over HTTP. = Thus a CoAP-HTTP proxy may end up anyways translating between multiple = HTTP frameworks depending on the application. So instead of doing a CoAP = Notify/Subscribe to Webhooks mapping, you will could end up having to do = a CoAP Webhooks to HTTP GENA mapping. =20 =20 =20 =20 I don't understand this last para. If CoAP sticks to the semantics of the current HTTP methods, would this not offer a fairly = straightforward translation to/from HTTP? =20 =20 =20 =20 From what I have heard so far 1 still seems like a wise choice, = although I need to look at Webhooks more deeply. In reality many = applications specify their own way of doing a push interface using REST = methods and specific payloads (ZigBee SE2.0 is such an example). That is = just fine, and might be used instead of a specific CoAP notify/subscribe = in that case. So 1 doesn't prevent the application using its own = mechanism, it just provides a native way for doing push. =20 =20 What do people think? =20 Zach =20 On May 17, 2010, at 6:44 PM, = matthieu.vial@fr.non.schneider-electric.com wrote: =20 =20 =20 =20 Hi, =20 My comments about the subscribe/notify mechanism of Zigbee IP. =20 Pros: - Derived from the webhooks concept - If used by CORE it will be easier to map to HTTP because it uses = only CRUD verbs. - The subscription message is extendable and could support advanced = options (delays, increment, ...) - Only one listening port whatever the transport binding is. =20 Cons: - No interoperability without well known URIs and a well defined = subscription message format (Not sure CoAP draft is the right place to = specify this). - XML/EXI is too complex to be the required format for the default = subscription/notification mechanism. - The notification should not require a subsequent GET to retrieve = the content. - Subresource subscription is redundant. =20 Hope this could help, Matthieu =20 =20 "Charles Palmer" = =20 =20 =20 =20 =20 "Charles Palmer" = =20 Envoy=E9 par : core-bounces@ietf.org 15/05/2010 14:06 =20 A "core" =20 cc Objet Re: [core] Selecting a WG document for CoAP =20 Dear all =20 Those interested in the subscribe/notify discussion might like to = look at the draft Smart Energy Profile 2.0 Application Protocol Specification. It is available here: = http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicApp licationProfile.aspx =20 It manages subscribe/notify by using POST. This seems to remove the = need for SUBSCRIBE and notify. =20 "Imagine a host A, which exposes a resource at http{s}://A/resource = and a second host B, which wishes to learn of changes to this resource. = To facilitate a subscription/ notification mechanism, A would expose a resource http{s}://A/sub and B would expose a resource = http{s}://B/ntfy. To subscribe to notifications regarding http{s}://A/resource, B = would send a POST to the address http{s}://A/sub/B containing the URI of = the resource of interest (http{s}://A/resource) and the URI of B's notification resource (http{s}://B/ntfy). Following this = subscription step, should A wish to notify B of a change to the resource = addressed at http{s}://A/resource, A would send a POST to the address http{s}://B/ntfy containing the URI of the resource changed (http{s}://A/resource) and the URI of A's subscription resource (http{s}://A/sub/B), should A wish to change its subscription. The = host B can then query the resource (or not) at its leisure." =20 Sleepy nodes are not allowed to subscribe, and must poll. =20 Regards - Charles Palmer =20 -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Angelo P. Castellani Sent: 14 May 2010 13:14 To: Zach Shelby Cc: core Subject: Re: [core] Selecting a WG document for CoAP =20 Zach, =20 thanks for the comments, but please refer to my most recent e-mail = for a more specific list of technical issues I'm pointing to. =20 I want to do only a little integration to what I've written there. =20 In my very personal opinion, to maximize adherence with the REST = model and minimize implementation effort SUBSCRIBE and NOTIFY should be mapped to methods (as discussed many times together...). =20 Uniform interface principle (Fielding PhD dissertation Section = 5.1.5, "The central feature that distinguishes the REST architectural style [...]") states that to simplify the software architecture, resource interfaces/interfaces should be as general as possible. =20 I agree with this principle in this specific case, mainly because handling a special message type for notify leads node software = design to a more complex architecture. =20 The reason is that this new message type requires special handling = and introduces a complexity in the software modularization. =20 Best, Angelo =20 On Fri, May 14, 2010 at 13:06, Zach Shelby = wrote: =20 =20 =20 Hi Angelo, =20 On May 13, 2010, at 14:24 , Angelo P. Castellani wrote: =20 =20 =20 =20 Dear C. Bormann, all, =20 before deciding for the final direction, I've the following observations about draft-shelby-core-coap-01 =20 While I mostly share Zach's view of the protocol approach, and appreciate many aspects of the proposal, there are in my opinion =20 =20 =20 still =20 =20 =20 some open issues that need to be at least discussed before the =20 =20 =20 current =20 =20 =20 document can be selected. =20 =20 =20 Of course there are plenty of open issues. Remember that working = group =20 =20 =20 documents still undertake as much change and improvement as the WG wants, so by no means is coap-01 set in stone. I would expect at = least 5-10 more revisions still along the way. Already several of your = ideas have been integrated into coap-01, and several more are under consideration, so it is coming along. Patience ;-) =20 =20 =20 =20 =20 In particular, I would like to highlight the following: =20 a) As it is now, it is not possible to have a straightforward translation of HTTP -> CoAP and viceversa: see http://www.ietf.org/mail-archive/web/core/current/msg00133.html = (this impacts the scalability of the web service model too) =20 =20 =20 In coap-01 the Method names are now identical to HTTP methods. The =20 =20 =20 Req/Res interaction is a direct translation. The URI hierarchy is compatible, and the URI binary code format we are still working on obviously. The only thing that takes some state to translate is Subscribe/Notify. But note, Subscribe/Notify takes some state no = matter how you do it, even with HTTP-HTTP there is no clean and easy way to handle subscriptions. =20 =20 =20 =20 =20 b) Moreover, CoAP's implementation is not as simple as it should = be. I've investigated the implementation and some design choices (as Options) are leading to very high program complexity (ROM) on a MSP430-based device. =20 =20 =20 This we can definitely improve, and already made several = optimizations =20 =20 =20 from -00 to -01. Here I need some very concrete proposals though. = Also remember that many things are optional, for example subscribe/notify = is not required if you don't need it. =20 =20 =20 =20 =20 c) Finally when comparing HTTP message size with CoAP message size, the resulting compression isn't as good as you may expect. =20 Example: HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B CoAP: 24 B with options parsing procedure requiring an added implementation complexity =20 =20 =20 Right, that is not how it will work in practice. Working with a = real =20 =20 =20 HTTP server that HTTP header will be more complex, and on the CoAP = side you would chose shorter URLs. The biggest improvement possible here = is from using binary coded URLs of course. We need to look at a wider = range of interactions and real HTTP headers as well to check that we are efficient enough. =20 =20 =20 =20 =20 Addressing all these points potentially leads to major technical modifications (especially point a) on the current draft, hence it = is appropriate in my opinion to discuss these points before making the final decision. =20 =20 =20 I am not sure what else you have in mind for a). If we just forget =20 =20 =20 about Subscribe/Notify then you are good to go. But then you are = also not fulfilling the charter or the industry needs in that respect. =20 =20 =20 Thanks, Zach =20 =20 =20 =20 Best regards, =20 Angelo P. Castellani =20 =20 On Mon, May 10, 2010 at 18:51, Carsten Bormann = wrote: =20 =20 =20 The CORE WG has a milestone to select a WG document for CoAP in =20 =20 =20 April: =20 =20 =20 http://datatracker.ietf.org/wg/core/charter/ ... Apr 2010 Select WG document for basis of the CoAP protocol =20 Of the various documents that have been contributed, =20 =20 =20 draft-shelby-core-coap has significant discussion, as well as the largest number of updates (including a previous version that was = still called -6lowapp-coap). =20 =20 =20 Today, another updated version of that draft was announced. See http://www.ietf.org/mail-archive/web/core/current/msg00138.html for the announcement and http://tools.ietf.org/html/draft-shelby-core-coap-01 for the draft itself. =20 However, as the authors say, there are still significant TODOs. =20 Are we in a state yet where we can say whether this is the right =20 =20 =20 direction for the WG to take? =20 =20 =20 If yes, is it the right direction? Should we adopt it as a WG =20 =20 =20 document? =20 =20 =20 If you don't think we can say yet, is there a set of technical =20 =20 =20 decisions you would like the authors to take with priority? =20 =20 =20 Note that once a document has become a WG document, the authors act =20 =20 =20 as editors for the working group, making (and usually fleshing out = the details of) any change that the WG decides it needs. =20 =20 =20 If you think we can still improve the draft, this is not an = obstacle =20 =20 =20 to making it a WG document. =20 =20 =20 But of course we shouldn't do that if we intend to reverse its =20 =20 =20 fundamental technical direction. =20 =20 =20 In order to stay roughly in sync with our milestones, we should =20 =20 =20 reach at a decision on how to go forward this week. =20 =20 =20 Gruesse, Carsten =20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =20 =20 =20 =20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =20 =20 =20 -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" = =20 http://6lowpan.net - My book " 6LoWPAN: = The Wireless Embedded Internet" Mobile: +358 40 7796297 =20 =20 =20 =20 =20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =20 -------------------------------- Onzo is a limited company number 06097997 registered in England& = Wales. The registered office is 6 Great Newport Street, London, WC2H 7JB, = United Kingdom. =20 This email message may contain confidential and/or privileged = information, and is intended solely for the addressee(s). If you have received this = email in error, please notify Onzo immediately. Unauthorised copying, = disclosure or distribution of the material in this email is forbidden. -------------------------------- =20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =20 = ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security = System. = ______________________________________________________________________ =20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =20 =20 =20 =20 =20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =20 -------------------------------- Onzo is a limited company number 06097997 registered in England& = Wales. The registered office is 6 Great Newport Street, London, WC2H 7JB, United = Kingdom. =20 This email message may contain confidential and/or privileged = information, and is intended solely for the addressee(s). If you have received this = email in error, please notify Onzo immediately. Unauthorised copying, = disclosure or distribution of the material in this email is forbidden. -------------------------------- =20 =20 =20 =20 =20 =20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =20 =20 ------_=_NextPart_001_01CAFDC7.9FD53178 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Robert,

 

in my personal opinion, the option 1a) brings some sort = of ambiguity to CoAP specs.

 

My be my understatement of new CoAP specs is not so deep, = =A0but now we have 5 methods and 3 message types: request, response and notify. = Which methods are allowed with which messages types?

I suppose you have to use PUT/POST method with notify = message for asynch data notification. How to make a subscribe? I suppose you = would use a SUBSCRIBE method with request/response message or SUBSCRIBE with = notify message? Also what about POST/DELETE methods in a notify message? They = not make any sense..

 

I think the choice is between: option 1) -> only CRUD = methods and option 1b) -> CRUD + SUB/NOTIFY methods, keeping in mind = cost/benefits of both solutions.

 

Adriano

 

From: Robert Cragie [mailto:robert.cragie@gridmerge.com]
Sent: mercoled=EC 26 maggio 2010 20.09
To: Adriano Pezzuto (apezzuto)
Cc: Paul Duffy (paduffy); Zach Shelby; core
Subject: Re: [core] Subscribe/Notify for = CoAP

 

Hi Adrian,

I would also prefer to keep the protocol in CoAP asynchronous. You can = always map an asynchronous protocol to a synchronous one but, as we see in = HTTP, it always ends up as a kludge to do it the other way round. The efforts = which have been gone to to make HTTP quasi-asynchronous via all the schemes = mentioned below and many more besides (all non-interoperable of course) is = testament to how important this is for M2M communication.

So, back to Zach's list, I favor 1a) for the following reasons:

Foundation level of messages:

  1. request/response can be asynchronous or synchronous messages (as there is a transaction ID in = there)
  2. notify is an asynchronous = message

Derived methods:

I think it makes sense to add a pub/sub model as a useful mechanism for = M2M.

So, looking at it the other way round: It will be entirely possible to translate whatever is currently built on HTTP to CoAP based on the = above, with all its restrictions regarding synchronous and client/server = transactions. What may be harder is to translate directly is a CoAP-based application to = HTTP. So I guess the question is: Do we want to be hamstrung to synchronous client/server transactions as dictated by HTTP and provide a direct = mapping to HTTP, then have to come up with similar kludges for asynchronous = peer-to-peer transactions as has been done in numerous ways for HTTP, or do we want = to define the protocol cleanly to start with and accept that some sort of transaction relaying/conversion would have to take place at a mapping = node?

Robert

Robert Cragie (Pacific Gas & = Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com


On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote: 

Hi,
it looks to me that CoAP should use an =
explicit sub/notify mechanism since this is the core of the =
machine-to-machine interaction model.
HTTP suffers =
of this lack and we have seen a plethora of solutions to give an asynch =
taste to it. Webhooks and websockets are only the lasts of the =
list.
As someone has already pointed out on this =
list, it is theoretically possible to describe sub/notify using only =
CRUD methods but it looks a little bit tricky and =
verbose.
 
Now we have a =
chance to build from scratch a new protocol with and I think using =
explicit sub/notify methods with a clear and well defined semantic is =
the best option. It is easily understanding from every developer and =
will prevent to build other fanny solutions on top of the CoAP. HTTP =
does not have this well defined semantic and (for hundreds of other =
reasons also) it is not used as wide protocol for machine-to-machine =
communication.
 
CoAP - =
as binary protocol - and with an explicit asynch model has a chance to =
be a really wide protocol for M2M communication not only for constrained =
environments.
 
my 2 =
cents
 
- =
adriano
 
-----Original =
Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] =
On Behalf Of Paul Duffy (paduffy)
Sent: mercoled=EC =
26 maggio 2010 0.47
To: Zach =
Shelby
Cc: core
Subject: Re: =
[core] Subscribe/Notify for =
CoAP
 
On 5/25/2010 6:41 =
PM, Zach Shelby wrote:
=A0 
Hi,
<= pre> 
On May 26, 2010, at 12:23 AM, Charles =
Palmer wrote:
 
=A0=A0 =

=A0=A0=A0=A0
Hi =
folks
 
It occurs to me =
that CoRE should be keeping a close eye on ZigBee SE2.0 work, so that it =
is as easy as possible for ZigBee SE to use CoRE when ready. That =
suggests to me that we should align with their subscribe/notify =
process.
 
=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0
I am not sure I understand that. I mean, ZigBee SE2.0 is defining =
an application specific subscribe/notify mechanism for that purpose so =
far for HTTP. This uses standard HTTP methods and some custom payload =
and REST interfaces. CoAP Req/Res is already totally compatible with =
SE2.0 in that respect, so alignment is already OK there. Nothing =
stopping someone from using SE2.0 over =
CoAP.
 
Specifying a =
native susbcription/notify into CoAP is another matter. We can't adopt a =
solution specific to one application as that won't solve the problems of =
other applications nor general HTTP mapping at all (probably would make =
it worse). It seems that for the near future there will be a bunch of =
HTTP push mechanisms in use without any clear standard appearing - or am =
I wrong there?
=A0=A0 =

=A0=A0=A0=A0
 
 
 <=
/o:p>
If COAP extends HTTP semantics with new subscription =
methods, it will 
not be possible to easily =
interchange HTTP/COAP, and translation 
gateways =
will become more complex to =
implement.
 
 
 
=A0 
Zach
= 
 
=A0=A0 =

=A0=A0=A0=A0
Regards =
- =
Charles
 
 
-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] =
On Behalf Of Paul Duffy
Sent: 25 May 2010 =
03:48
To: Zach Shelby
Cc: =
core
Subject: Re: [core] Subscribe/Notify for =
CoAP
 
Recommend =
something like #2, primarily to avoid introducing non =
HTTP
method semantics, simplifying HTTP/COAP =
translation.gateways, =
etc.
 
 
On 5/24/2010 11:49 AM, Zach Shelby =
wrote:
=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0



(thread =
renamed)
 
We have two =
different paths with regard to a subscribe/notify mechanism for =
CoAP:
 
1. Use specific =
Subscription and Notify mechanisms for CoAP as HTTP really does not =
include this concept.
1a) Notify as a message and =
SUBSCRIBE as a method. This is currently used in =
coap-01.
1b) NOTIFY and SUBSCRIBE as methods. This =
was used in coap-00, but we had a good list discussion about this =
leading to a. In practice it doesn't make a big difference if =
notification is a message or =
method.
 
2. Use an HTTP =
specific framework such as Webhooks, the ZigBee SE2.0 proposal or =
GENA.
 
So far we have =
focused on 1 in the WG, and every now and again 2 comes up. At least I =
am not convinced that we need to suffer the drawbacks of HTTP here. =
Anyways 2 does not help our mapping to HTTP in reality very much as =
there is no standard way of doing this over HTTP. Thus a CoAP-HTTP proxy =
may end up anyways translating between multiple HTTP frameworks =
depending on the application. So instead of doing a CoAP =
Notify/Subscribe to Webhooks mapping, you will could end up having to do =
a CoAP Webhooks to HTTP GENA =
mapping.
 
=A0=A0=A0=A0=A0=
=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0



 
I don't understand this last para.=A0 =
If CoAP sticks to the semantics of
the current HTTP =
methods, would this not offer a fairly =
straightforward
translation to/from =
HTTP?
 
 <=
/pre>
=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0






=A0From =
what I have heard so far 1 still seems like a wise choice, although I =
need to look at Webhooks more deeply. In reality many applications =
specify their own way of doing a push interface using REST methods and =
specific payloads (ZigBee SE2.0 is such an example). That is just fine, =
and might be used instead of a specific CoAP notify/subscribe in that =
case. So 1 doesn't prevent the application using its own mechanism, it =
just provides a native way for doing =
push.
=A0=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0



What do people =
think?
 
Zach
 
On May 17, 2010, at 6:44 PM, matthieu.vial=
@fr.non.schneider-electric.com =
wrote:
 
 =

=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0



Hi,
<=
pre> 
My comments about the subscribe/notify =
mechanism of Zigbee =
IP.
 
Pros:
- Derived from the webhooks concept
- If =
used by CORE it will be easier to map to HTTP because it uses only CRUD =
verbs.
- The subscription message is extendable and =
could support advanced options (delays, increment, =
...)
- Only one listening port whatever the =
transport binding =
is.
 
Cons:
- No interoperability without well known URIs and a well defined =
subscription message format (Not sure CoAP draft is the right place to =
specify this).
- XML/EXI is too complex to be the =
required format for the default subscription/notification =
mechanism.
- The notification should not require a =
subsequent GET to retrieve the content.
- =
Subresource subscription is =
redundant.
 
Hope this =
could =
help,
Matthieu
 
 
<graycol.gif>"Charles =
Palmer"<charles.palmer@onzo.com>
 
 
 
 
"Char=
les Palmer"<charles.palmer@onzo.com>
Envoy=E9 par : core-bounces@ietf.org
15/05/2010 =
14:06
 
<ecblank.gif>=
;
A
<ecblank.gif>
"core"<core@ietf.org>
<=
pre><ecblank.gif>
cc
<=
ecblank.gif>
<ecblank.gif>
=

Objet
<ecblank.gif>
=
Re: [core] Selecting a WG document for =
CoAP
<ecblank.gif> =
<ecblank.gif>
 
Dear=
 all
 
Those interested =
in the subscribe/notify discussion might like to =
look
at the draft Smart Energy Profile 2.0 =
Application Protocol
Specification. It is available =
here:
http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20P=
ublicApp
licationProfile.aspx
 
It manages subscribe/notify by using =
POST. This seems to remove the need
for SUBSCRIBE =
and =
notify.
 
"Imagine a =
host A, which exposes a resource at http{s}://A/resource =
and
a second host B, which wishes to learn of =
changes to this resource. To
facilitate a =
subscription/ notification mechanism, A would expose =
a
resource http{s}://A/sub and B would expose a =
resource http{s}://B/ntfy.
To subscribe to =
notifications regarding http{s}://A/resource, B =
would
send a POST to the address http{s}://A/sub/B =
containing the URI of the
resource of interest =
(http{s}://A/resource) and the URI of =
B's
notification resource (http{s}://B/ntfy). =
Following this subscription
step, should A wish to =
notify B of a change to the resource addressed =
at
http{s}://A/resource, A would send a POST to the =
address
http{s}://B/ntfy containing the URI of the =
resource changed
(http{s}://A/resource) and the URI =
of A's subscription resource
(http{s}://A/sub/B), =
should A wish to change its subscription. The =
host
B can then query the resource (or not) at its =
leisure."
 
Sleepy =
nodes are not allowed to subscribe, and must =
poll.
 
Regards - Charles =
Palmer
 
-----Original =
Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] =
On Behalf Of
Angelo P. =
Castellani
Sent: 14 May 2010 =
13:14
To: Zach Shelby
Cc: =
core
Subject: Re: [core] Selecting a WG document =
for =
CoAP
 
Zach,
 
thanks for the comments, but please =
refer to my most recent e-mail for
a more specific =
list of technical issues I'm pointing =
to.
 
I want to do only a =
little integration to what I've written =
there.
 
In my very =
personal opinion, to maximize adherence with the REST =
model
and minimize implementation effort SUBSCRIBE =
and NOTIFY should be
mapped to methods (as =
discussed many times =
together...).
 
Uniform =
interface principle (Fielding PhD dissertation Section =
5.1.5,
"The central feature that distinguishes =
the REST architectural style
[...]") states =
that to simplify the software architecture, =
resource
interfaces/interfaces should be as general =
as possible.
 
I agree =
with this principle in this specific case, mainly =
because
handling a special message type for notify =
leads node software design
to a more complex =
architecture.
 
The =
reason is that this new message type requires special handling =
and
introduces a complexity in the software =
modularization.
 
Best,
Angelo
 
On Fri, May 14, 2010 at 13:06, Zach Shelby<zach@sensinode.com>=A0=A0 =
wrote:
 
=A0=A0=A0=A0=A0=A0=
=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0



Hi =
Angelo,
 
On May 13, =
2010, at 14:24 , Angelo P. Castellani =
wrote:
 
 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0


Dear C. =
Bormann, all,
 
before =
deciding for the final direction, I've the =
following
observations about =
draft-shelby-core-coap-01
 
While I mostly share Zach's view of the protocol approach, =
and
appreciate many aspects of the proposal, there =
are in my =
opinion
 
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0






still
 
=A0=A0=A0=A0=A0=
=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0






some =
open issues that need to be at least discussed before =
the
 
=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0






current
 
=A0=A0=A0=A0=
=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0






document =
can be =
selected.
 
=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0



Of course there are plenty of open issues. Remember that working =
group
 
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0



documents still undertake as much change and improvement as the =
WG
wants, so by no means is coap-01 set in stone. I =
would expect at least
5-10 more revisions still =
along the way.=A0 Already several of your =
ideas
have been integrated into coap-01, and =
several more are under
consideration, so it is =
coming along. Patience =
;-)
 
=A0=A0=A0=A0=A0=A0=A0=
=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0



=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0


In =
particular, I would like to highlight the =
following:
 
a) As it is =
now, it is not possible to have a =
straightforward
translation of HTTP ->=A0=A0 =
CoAP and viceversa: see
=
http://www.ietf.org/mail-archive/web/core/current/msg00133.html =
(this
impacts the scalability of the web service =
model =
too)
 
=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0



In coap-01 the Method names are now identical to HTTP methods. =
The
 
=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0



Req/Res interaction is a direct translation. The URI hierarchy =
is
compatible, and the URI binary code format we =
are still working on
obviously. The only thing that =
takes some state to translate is
Subscribe/Notify. =
But note, Subscribe/Notify takes some state no =
matter
how you do it, even with HTTP-HTTP there is =
no clean and easy way to
handle =
subscriptions.
 
=A0=A0=A0=
=A0=A0=A0=A0 =
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0



=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0


b) =
Moreover, CoAP's implementation is not as simple as it should =
be.
I've investigated the implementation and some =
design choices (as
Options) are leading to very =
high program complexity (ROM) on a
MSP430-based =
device.
 
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0



This we can definitely improve, and already made several =
optimizations
 
=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0



from -00 to -01. Here I need some very concrete proposals though. =
Also
remember that many things are optional, for =
example subscribe/notify is
not required if you =
don't need =
it.
 
=A0=A0=A0=A0=A0=A0=A0=
=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0



=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0


c) =
Finally when comparing HTTP message size with CoAP message =
size,
the resulting compression isn't as good as =
you may =
expect.
 
Example:
HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 =
B
CoAP: 24 B with options parsing procedure =
requiring an added
implementation =
complexity
 
=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0



Right, that is not how it will work in practice. Working with a =
real
 
=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0



HTTP server that HTTP header will be more complex, and on the CoAP =
side
you would chose shorter URLs. The biggest =
improvement possible here is
from using binary =
coded URLs of course. We need to look at a wider =
range
of interactions and real HTTP headers as well =
to check that we are
efficient =
enough.
 
=A0=A0=A0=A0=A0=A0=
=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0



=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0


Addressing all these =
points potentially leads to major =
technical
modifications (especially point a) on the =
current draft, hence it is
appropriate in my =
opinion to discuss these points before making =
the
final =
decision.
 
=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0



I am not sure what else you have in mind for a). If we just =
forget
 
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0



about Subscribe/Notify then you are good to go. But then you are =
also
not fulfilling the charter or the industry =
needs in that =
respect.
 
=A0=A0=A0=A0=A0=
=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0



Thanks,
Zach
 
 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0


Best =
regards,
 
Angelo P. =
Castellani
 
 
On Mon, May 10, 2010 at 18:51, Carsten Bormann<cabo@tzi.org>=A0=A0 =
wrote:
 
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0



The CORE =
WG has a milestone to select a WG document for CoAP =
in
 
=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0









April:
 
=A0=A0=A0=A0=
=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0









http://datatracker.=
ietf.org/wg/core/charter/
...
Apr 2010=A0=A0=A0=A0=A0=A0=A0 Select WG document for basis of the =
CoAP protocol
 
Of the =
various documents that have been =
contributed,
 
=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0



draft-shelby-core-coap has significant discussion, as well as =
the
largest number of updates (including a previous =
version that was still
called =
-6lowapp-coap).
 
=A0=A0=A0=
=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
Today, =
another updated version of that draft was announced.=A0 =
See
=
http://www.ietf.org/mail-archive/web/core/current/msg00138.html<=
/o:p>
for the announcement and
http://tool=
s.ietf.org/html/draft-shelby-core-coap-01
for =
the draft =
itself.
 
However, as the =
authors say, there are still significant =
TODOs.
 
Are we in a =
state yet where we can say whether this is the =
right
 
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
direction for the WG to =
take?
 
=A0=A0=A0=A0=A0=A0=
=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
If yes, =
is it the right direction?=A0 Should we adopt it as a =
WG
 
=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
document?
 
=A0=A0=A0=
=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
If you =
don't think we can say yet, is there a set of =
technical
 
=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
decisions you would like the authors to take with =
priority?
 
=A0=A0=A0=A0=A0=
=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
Note =
that once a document has become a WG document, the authors =
act
 
=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
as editors for the working group, making (and usually fleshing out =
the
details of) any change that the WG decides it =
needs.
 
=A0=A0=A0=A0=A0=A0=
=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
If you =
think we can still improve the draft, this is not an =
obstacle
 
=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
to making it a WG =
document.
 
=A0=A0=A0=A0=A0=
=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
But of =
course we shouldn't do that if we intend to reverse =
its
 
=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
fundamental technical =
direction.
 
=A0=A0=A0=A0=A0=
=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
In order =
to stay roughly in sync with our milestones, we =
should
 
=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
reach at a decision on how to go forward this =
week.
 
=A0=A0=A0=A0=A0=A0=
=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
Gruesse, =
Carsten
 
________________=
_______________________________
core mailing =
list
core@ietf.org
https://www.ietf.org/=
mailman/listinfo/core
 
 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/=
mailman/listinfo/core
 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
--
Zach Shelby, Chief Nerd, Sensinode =
Ltd.
http://zachshelby.org=A0 - My blog =
"On the Internet of Things"
http://6lowpan.net - My book =
"6LoWPAN: The Wireless Embedded =
Internet"
Mobile: +358 40 =
7796297
 
 
 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/=
mailman/listinfo/core
 
--------------------------------
Onzo is a =
limited company number 06097997 registered in England&=A0=A0 Wales. =
The
registered office is 6 Great Newport Street, =
London, WC2H 7JB, United =
Kingdom.
 
This email =
message may contain confidential and/or privileged information, =
and
is intended solely for the addressee(s). If you =
have received this email in
error, please notify =
Onzo immediately. Unauthorised copying, disclosure =
or
distribution of the material in this email is =
forbidden.
--------------------------------
 
________________________________=
_______________
core mailing =
list
core@ietf.org
https://www.ietf.org/=
mailman/listinfo/core
 
______________________________________________________________________<= o:p>
This email has been scanned by the MessageLabs =
Email Security =
System.
____________________________________________=
__________________________
 
_______________________________________________
c=
ore mailing list
core@ietf.org
https://www.ietf.org/=
mailman/listinfo/core
 
=A0=A0=A0=A0=A0=A0=A0=A0 = 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/=
mailman/listinfo/core
 
--------------------------------
Onzo is a =
limited company number 06097997 registered in England&=A0 Wales. =
The
registered office is 6 Great Newport Street, =
London, WC2H 7JB, United =
Kingdom.
 
This email =
message may contain confidential and/or privileged information, =
and
is intended solely for the addressee(s). If you =
have received this email in
error, please notify =
Onzo immediately. Unauthorised copying, disclosure =
or
distribution of the material in this email is =
forbidden.
--------------------------------
 
=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0

Hi

>It occurs to me that CoRE should be keeping a close eye on ZigBee S= E2.0 work, so that it is as easy as possible for ZigBee SE to use CoRE = when ready. That suggests to me that we should align with their subscri= be/notify process.

Does it mean that all CoAP nodes shall support XML/EXI? If so I am = not sure this is the right solution.

I think we will achieve better interoperability between CoAP nodes = with a native solution. I also agree with Zach that alignement with HTT= P is already there in CoAP.
However if the native subscribe/notify is not enough extensible, ma= ny applications will fallback to a specific subscribe. Zigbee ZCL, bacn= et, have a higher degree of control for notifications than just a simpl= e update (delays, values...). Maybe CORE shall provide at least guideli= nes to support extended controls on notification conditions.

Regards,
Matthieu

3D"Inactive"Charles Pa= lmer" <charles.palmer@onzo.com>




=
          "Charles Palmer" <charles.palmer@o= nzo.com>
          Envoy=E9 par : core-bounces@ietf.org

          26/05/2010 00:23

 =
3D=
A
3D""
<paduffy@cisco.com>, "Zach Shelby" <= ;zach@sensinode.com>
3D=
cc
3D""
core <core@ietf.org>
3D=
Objet
3D""
Re: [core] Subscribe/Notify for CoAP
3D=3D""

Hi folks

It occurs to me that CoRE should be keeping a close eye on ZigBee SE2.0= work, so that it is as easy as possible for ZigBee SE to use CoRE when= ready. That suggests to me that we should align with their subscribe/n= otify process.

Regards - Charles


-----Original Message-----
From: core-bounces@ietf.org [m= ailto:core-bounces@ietf.org] On Behalf Of Paul Duffy
Sent: 25 May 2010 03:48
To: Zach Shelby
Cc: core
Subject: Re: [core] Subscribe/Notify for CoAP

Recommend something like #2, primarily to avoid introducing non HTTP method semantics, simplifying HTTP/COAP translation.gateways, etc.


On 5/24/2010 11:49 AM, Zach Shelby wrote:
> (thread renamed)
>
> We have two different paths with regard to a subscribe/notify mech= anism for CoAP:
>
> 1. Use specific Subscription and Notify mechanisms for CoAP as HTT= P really does not include this concept.
> 1a) Notify as a message and SUBSCRIBE as a method. This is current= ly used in coap-01.
> 1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but= we had a good list discussion about this leading to a. In practice it = doesn't make a big difference if notification is a message or method. >
> 2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2= .0 proposal or GENA.
>
> So far we have focused on 1 in the WG, and every now and again 2 c= omes up. At least I am not convinced that we need to suffer the drawbac= ks of HTTP here. Anyways 2 does not help our mapping to HTTP in reality= very much as there is no standard way of doing this over HTTP. Thus a = CoAP-HTTP proxy may end up anyways translating between multiple HTTP fr= ameworks depending on the application. So instead of doing a CoAP Notif= y/Subscribe to Webhooks mapping, you will could end up having to do a C= oAP Webhooks to HTTP GENA mapping.
>    


I don't understand this last para.  If CoAP sticks to the semantic= s of
the current HTTP methods, would this not offer a fairly straightforward=
translation to/from HTTP?


> > From what I have heard so far 1 still seems like a wise choic= e, although I need to look at Webhooks more deeply. In reality many app= lications specify their own way of doing a push interface using REST me= thods and specific payloads (ZigBee SE2.0 is such an example). That is = just fine, and might be used instead of a specific CoAP notify/subscrib= e in that case. So 1 doesn't prevent the application using its own mech= anism, it just provides a native way for doing push.
>
> What do people think?
>
> Zach
>
> On May 17, 2010, at 6:44 PM, matthieu.vial@fr.non.schneider-electr= ic.com wrote:
>
>    
>> Hi,
>>
>> My comments about the subscribe/notify mechanism of Zigbee IP.=
>>
>> Pros:
>> - Derived from the webhooks concept
>> - If used by CORE it will be easier to map to HTTP because it = uses only CRUD verbs.
>> - The subscription message is extendable and could support adv= anced options (delays, increment, ...)
>> - Only one listening port whatever the transport binding is. >>
>> Cons:
>> - No interoperability without well known URIs and a well defin= ed subscription message format (Not sure CoAP draft is the right place = to specify this).
>> - XML/EXI is too complex to be the required format for the def= ault subscription/notification mechanism.
>> - The notification should not require a subsequent GET to retr= ieve the content.
>> - Subresource subscription is redundant.
>>
>> Hope this could help,
>> Matthieu
>>
>>
>> <graycol.gif>"Charles Palmer"<charles.palme= r@onzo.com>
>>
>>
>>
>>
>> "Charles Palmer"<charles.palmer@onzo.com>
>> Envoy=E9 par : core-bounces@ietf.org
>> 15/05/2010 14:06
>>
>> <ecblank.gif>
>> A
>> <ecblank.gif>
>> "core"<core@ietf.org>
>> <ecblank.gif>
>> cc
>> <ecblank.gif>
>> <ecblank.gif>
>> Objet
>> <ecblank.gif>
>> Re: [core] Selecting a WG document for CoAP
>> <ecblank.gif> <ecblank.gif>
>>
>> Dear all
>>
>> Those interested in the subscribe/notify discussion might like= to look
>> at the draft Smart Energy Profile 2.0 Application Protocol
= >> Specification. It is available here:
>> http://zigbee.org/Markets/ZigBeeSmartEn= ergy/ZigBeeSmartEnergy20PublicApp
>> licationProfile.aspx
>>
>> It manages subscribe/notify by using POST. This seems to remov= e the need
>> for SUBSCRIBE and notify.
>>
>> "Imagine a host A, which exposes a resource at http{s}://= A/resource and
>> a second host B, which wishes to learn of changes to this reso= urce. To
>> facilitate a subscription/ notification mechanism, A would exp= ose a
>> resource http{s}://A/sub and B would expose a resource http{s}= ://B/ntfy.
>> To subscribe to notifications regarding http{s}://A/resource, = B would
>> send a POST to the address http{s}://A/sub/B containing the UR= I of the
>> resource of interest (http{s}://A/resource) and the URI of B's=
>> notification resource (http{s}://B/ntfy). Following this subsc= ription
>> step, should A wish to notify B of a change to the resource ad= dressed at
>> http{s}://A/resource, A would send a POST to the address
>> http{s}://B/ntfy containing the URI of the resource changed >> (http{s}://A/resource) and the URI of A's subscription resourc= e
>> (http{s}://A/sub/B), should A wish to change its subscription.= The host
>> B can then query the resource (or not) at its leisure." >>
>> Sleepy nodes are not allowed to subscribe, and must poll.
>>
>> Regards - Charles Palmer
>>
>> -----Original Message-----
>> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of
>> Angelo P. Castellani
>> Sent: 14 May 2010 13:14
>> To: Zach Shelby
>> Cc: core
>> Subject: Re: [core] Selecting a WG document for CoAP
>>
>> Zach,
>>
>> thanks for the comments, but please refer to my most recent e-= mail for
>> a more specific list of technical issues I'm pointing to.
>>
>> I want to do only a little integration to what I've written th= ere.
>>
>> In my very personal opinion, to maximize adherence with the RE= ST model
>> and minimize implementation effort SUBSCRIBE and NOTIFY should= be
>> mapped to methods (as discussed many times together...).
>>
>> Uniform interface principle (Fielding PhD dissertation Section= 5.1.5,
>> "The central feature that distinguishes the REST architec= tural style
>> [...]") states that to simplify the software architecture= , resource
>> interfaces/interfaces should be as general as possible.
>>
>> I agree with this principle in this specific case, mainly beca= use
>> handling a special message type for notify leads node software= design
>> to a more complex architecture.
>>
>> The reason is that this new message type requires special hand= ling and
>> introduces a complexity in the software modularization.
>>
>> Best,
>> Angelo
>>
>> On Fri, May 14, 2010 at 13:06, Zach Shelby<zach@sensinode.c= om>  wrote:
>>      
>>> Hi Angelo,
>>>
>>> On May 13, 2010, at 14:24 , Angelo P. Castellani wrote: >>>
>>>        
>>>> Dear C. Bormann, all,
>>>>
>>>> before deciding for the final direction, I've the foll= owing
>>>> observations about draft-shelby-core-coap-01
>>>>
>>>> While I mostly share Zach's view of the protocol appro= ach, and
>>>> appreciate many aspects of the proposal, there are in = my opinion
>>>>          
>> still
>>      
>>>> some open issues that need to be at least discussed be= fore the
>>>>          
>> current
>>      
>>>> document can be selected.
>>>>          
>>> Of course there are plenty of open issues. Remember that w= orking group
>>>        
>> documents still undertake as much change and improvement as th= e WG
>> wants, so by no means is coap-01 set in stone. I would expect = at least
>> 5-10 more revisions still along the way.  Already several= of your ideas
>> have been integrated into coap-01, and several more are under<= br> >> consideration, so it is coming along. Patience ;-)
>>      
>>>        
>>>> In particular, I would like to highlight the following= :
>>>>
>>>> a) As it is now, it is not possible to have a straight= forward
>>>> translation of HTTP ->  CoAP and viceversa: se= e
>>>> http://www.ietf.org/mail-archive/web/cor= e/current/msg00133.html (this
>>>> impacts the scalability of the web service model too)<= br> >>>>          
>>> In coap-01 the Method names are now identical to HTTP meth= ods. The
>>>        
>> Req/Res interaction is a direct translation. The URI hierarchy= is
>> compatible, and the URI binary code format we are still workin= g on
>> obviously. The only thing that takes some state to translate i= s
>> Subscribe/Notify. But note, Subscribe/Notify takes some state = no matter
>> how you do it, even with HTTP-HTTP there is no clean and easy = way to
>> handle subscriptions.
>>      
>>>        
>>>> b) Moreover, CoAP's implementation is not as simple as= it should be.
>>>> I've investigated the implementation and some design c= hoices (as
>>>> Options) are leading to very high program complexity (= ROM) on a
>>>> MSP430-based device.
>>>>          
>>> This we can definitely improve, and already made several o= ptimizations
>>>        
>> from -00 to -01. Here I need some very concrete proposals thou= gh. Also
>> remember that many things are optional, for example subscribe/= notify is
>> not required if you don't need it.
>>      
>>>        
>>>> c) Finally when comparing HTTP message size with CoAP = message size,
>>>> the resulting compression isn't as good as you may exp= ect.
>>>>
>>>> Example:
>>>> HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B
>>>> CoAP: 24 B with options parsing procedure requiring an= added
>>>> implementation complexity
>>>>          
>>> Right, that is not how it will work in practice. Working w= ith a real
>>>        
>> HTTP server that HTTP header will be more complex, and on the = CoAP side
>> you would chose shorter URLs. The biggest improvement possible= here is
>> from using binary coded URLs of course. We need to look at a w= ider range
>> of interactions and real HTTP headers as well to check that we= are
>> efficient enough.
>>      
>>>        
>>>> Addressing all these points potentially leads to major= technical
>>>> modifications (especially point a) on the current draf= t, hence it is
>>>> appropriate in my opinion to discuss these points befo= re making the
>>>> final decision.
>>>>          
>>> I am not sure what else you have in mind for a). If we jus= t forget
>>>        
>> about Subscribe/Notify then you are good to go. But then you a= re also
>> not fulfilling the charter or the industry needs in that respe= ct.
>>      
>>> Thanks,
>>> Zach
>>>
>>>        
>>>> Best regards,
>>>>
>>>> Angelo P. Castellani
>>>>
>>>>
>>>> On Mon, May 10, 2010 at 18:51, Carsten Bormann<cabo= @tzi.org>  wrote:
>>>>          
>>>>> The CORE WG has a milestone to select a WG documen= t for CoAP in
>>>>>            
>> April:
>>      
>>>>> http://datatracker.ietf.org/wg/core/charter/
>>>>> ...
>>>>> Apr 2010        Select WG docu= ment for basis of the CoAP protocol
>>>>>
>>>>> Of the various documents that have been contribute= d,
>>>>>            
>> draft-shelby-core-coap has significant discussion, as well as = the
>> largest number of updates (including a previous version that w= as still
>> called -6lowapp-coap).
>>      
>>>>> Today, another updated version of that draft was a= nnounced.  See
>>>>> http://www.ietf.org/mail-archive/web= /core/current/msg00138.html
>>>>> for the announcement and
>>>>> http://tools.ietf.org/html/draft-shelby-core-co= ap-01
>>>>> for the draft itself.
>>>>>
>>>>> However, as the authors say, there are still signi= ficant TODOs.
>>>>>
>>>>> Are we in a state yet where we can say whether thi= s is the right
>>>>>            
>> direction for the WG to take?
>>      
>>>>> If yes, is it the right direction?  Should we= adopt it as a WG
>>>>>            
>> document?
>>      
>>>>> If you don't think we can say yet, is there a set = of technical
>>>>>            
>> decisions you would like the authors to take with priority? >>      
>>>>> Note that once a document has become a WG document= , the authors act
>>>>>            
>> as editors for the working group, making (and usually fleshing= out the
>> details of) any change that the WG decides it needs.
>>      
>>>>> If you think we can still improve the draft, this = is not an obstacle
>>>>>            
>> to making it a WG document.
>>      
>>>>> But of course we shouldn't do that if we intend to= reverse its
>>>>>            
>> fundamental technical direction.
>>      
>>>>> In order to stay roughly in sync with our mileston= es, we should
>>>>>            
>> reach at a decision on how to go forward this week.
>>      
>>>>> Gruesse, Carsten
>>>>>
>>>>> _______________________________________________ >>>>> core mailing list
>>>>> core@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/core >>>>>
>>>>>            
>>>> _______________________________________________
>>>> core mailing list
>>>> core@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/core
>>>>          
>>> --
>>> Zach Shelby, Chief Nerd, Sensinode Ltd.
>>> http://zachshel= by.org  - My blog "On the Internet of Things&quo= t;
>>> http://6lowpan.net=  - My book "6LoWPAN: The Wireless Embedded Inter= net"
>>> Mobile: +358 40 7796297
>>>
>>>
>>>        
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
>>
>> --------------------------------
>> Onzo is a limited company number 06097997 registered in Englan= d&  Wales. The
>> registered office is 6 Great Newport Street, London, WC2H 7JB,= United Kingdom.
>>
>> This email message may contain confidential and/or privileged = information, and
>> is intended solely for the addressee(s). If you have received = this email in
>> error, please notify Onzo immediately. Unauthorised copying, d= isclosure or
>> distribution of the material in this email is forbidden.
>> --------------------------------
>>
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
>>
>> ______________________________________________________________= ________
>> This email has been scanned by the MessageLabs Email Security = System.
>> ______________________________________________________________= ________
>>
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
>>      
>    

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

--------------------------------
Onzo is a limited company number 06097997 registered in England & W= ales. The    
registered office is 6 Great Newport Street, London, WC2H 7JB, United K= ingdom.

This email message may contain confidential and/or privileged informati= on, and
is intended solely for the addressee(s). If you have received this emai= l in    
error, please notify Onzo immediately. Unauthorised copying, disclosure= or
distribution of the material in this email is forbidden.
--------------------------------

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

______________________________________________________________________<= br> This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________<= br>
= --1__=4EBBFDBCDFBBF6518f9e8a93df938690918c4EBBFDBCDFBBF651-- --0__=4EBBFDBCDFBBF6518f9e8a93df938690918c4EBBFDBCDFBBF651 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=4EBBFDBCDFBBF6518@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=4EBBFDBCDFBBF6518f9e8a93df938690918c4EBBFDBCDFBBF651 Content-type: image/gif; name="pic10195.gif" Content-Disposition: inline; filename="pic10195.gif" Content-ID: <2__=4EBBFDBCDFBBF6518@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=4EBBFDBCDFBBF6518f9e8a93df938690918c4EBBFDBCDFBBF651 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=4EBBFDBCDFBBF6518@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=4EBBFDBCDFBBF6518f9e8a93df938690918c4EBBFDBCDFBBF651-- From daniel.gavelle@jennic.com Wed May 26 01:42:04 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13CCC3A68B7 for ; Wed, 26 May 2010 01:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.154 X-Spam-Level: * X-Spam-Status: No, score=1.154 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHOvS+ws8QfV for ; Wed, 26 May 2010 01:42:02 -0700 (PDT) Received: from mail.jennic.com (proxy.jennic.co.uk [81.23.53.53]) by core3.amsl.com (Postfix) with ESMTP id 72D5E3A689E for ; Wed, 26 May 2010 01:42:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id 6AE469BE50A; Wed, 26 May 2010 09:41:52 +0100 (BST) Received: from mail.jennic.com ([127.0.0.1]) by localhost (smithers.jennic.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uKldF4NiNuG; Wed, 26 May 2010 09:41:52 +0100 (BST) Received: from [10.99.96.69] (snifflap01.jennic.com [10.99.96.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.jennic.com (Postfix) with ESMTPSA id 521389BE508; Wed, 26 May 2010 09:41:52 +0100 (BST) Message-ID: <4BFCDED0.2060605@jennic.com> Date: Wed, 26 May 2010 09:41:52 +0100 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Daniel Berenguer References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry> <041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org> <3C20B7FD-CB93-43CC-83D2-3F4209CC5B84@tzi.org> <355B1C46-98A8-4D4F-95B5-C011B2B81F92@sensinode.com> <485AF6ECE8D1954D996771CC49E996FDC0A8A4F4@IT-EXMB-01.silverspringnet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: core Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: daniel.gavelle@jennic.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 08:42:04 -0000 I also think that fragmentation should not be part of CoAP. Applications that need more than 1K of data per message are likely to be running on devices that can support TCP/HTTP. Firmware updates can use TFTP. I do think there would be interest in a separate effort to cover compressing HTTP/TCP. If this were done, CoAP could target the very restricted nodes and wouldn't need to attempt to address the next size up, where HTTP/TCP can be used but is inefficient. Daniel. Daniel Berenguer wrote: > Maybe I'm misunderstanding something but, is CoAP supposed to give > support for firmware upgrades? Wouldn't be easier to use proprietary > schemas over TCP or just TFTP over UDP for transferring large packet > blocks? Why overloading a M2M protocol like CoAP with such things? > > I agree with Zach in that interoperability is a priority so adding a > explicit note about the recommended use of CoAP over UDP would be > useful. > > Daniel. > > > On 25 May 2010 10:37, Oflynn, Colin wrote: >> Hello, >> >> I think 3 (fragmentation) should still be included in CoAP if we are >> proposing UDP. The main feature I'm thinking of is firmware updates which >> would need larger responses. >> >> Again the fragmentation can be very simple (TFTP style), and if the user >> requires anything more advanced it is their responsibility. However leaving >> it to "users" probably means "not interpolatable", since then their is >> basically different responses depending on the file size. >> >> Regards, >> >> -Colin >> >> >> -----Original Message----- >> From: core-bounces@ietf.org on behalf of Thomas Herbst >> Sent: Tue 25/05/2010 07:18 >> To: Zach Shelby; core >> Subject: Re: [core] Core UDP vs TCP : Redux >> >> IMHO, 1& 2 move the document forward significantly. >> For 3, fragmentation being an exercise for the user seems okay. >> >> DTLS may well need more thought. >> >> ________________________________________ >> From: core-bounces@ietf.org [core-bounces@ietf.org] On Behalf Of Zach Shelby >> [zach@sensinode.com] >> Sent: Monday, May 24, 2010 8:14 AM >> To: core >> Subject: Re: [core] Core UDP vs TCP : Redux >> >> So what I heard people want here: >> >> 1. UDP as *the only* transport for simplicity and interoperability in the >> spec (as long as we don't reinvent TCP). >> 2. CoAP to be transport independent as a protocol, thus allowing it to be >> possibly used in other ways in the future. >> 3. A couple people think we might need a fragmentation feature for responses >> with a payload size over the maximum. >> 4. DTLS might have complexity problems, should not be the only option >> (Michael) >> 5. Some transport binding framework could be explored (Robert) >> >> I agree with 1 and 2, and my proposal would be to remove the TCP-specific >> text and sections from the next version of CoAP. We can make the protocol >> itself independent of UDP (it really already is), however UDP must be >> specified for interoperability reasons. I propose we anyways keep some text >> saying something like >> >> "Although this document specifies CoAP over UDP, the protocol may also be >> applicable over other transports such as TCP or SCTP. The specification of >> such use is out of scope of this document. >> >> This would at least give us a starting point. I don't see the need for >> developing frameworks or negotiation of multiple bindings for CoAP, at least >> not now. >> >> Regarding fragmentation, let's not jump the gun too soon here. For the vast >> majority of constrained applications the 1280 byte maximum is more than >> enough. For cases when it is not let's first see if it would make sense to >> let the application deal with it. By the way, coap-01 has a mistake with the >> 576B IPv4 maximum and 1280B IPv6 maximum. That doesn't work for >> CoAP(IPv4)-CoAP(IPv6) proxying. Instead we should set both to use the 1280 >> byte maximum. >> >> Regarding DTLS, we are specifying how to use it with CoAP as it is a secure >> transport. I agree with Michael that DTLS may very well be too much for many >> constrained devices, so we should make it clear that this is not the only >> way to do security, IPSEC e.g. is equally applicable (and probably simpler) >> but doesn't require any specification in the document. A security analysis >> ID would be a big help for the WG..... >> >> Zach >> >> On May 18, 2010, at 4:23 PM, Oflynn, Colin wrote: >> >>>> Are there dependencies to UDP or is it only because the assumed >>>> infrastructure is highly constrained? >>> My thoughts/feeling on the issue is that CoAP should be designed with a >>> highly constrained environment, and as such being bound to UDP makes it a >>> lot simpler. >>> >>> The resources which CoAP accesses SHOULD be accessible another in another >>> manner; most likely this is HTTP over TCP. Even though CoAP does not map >>> directly to HTTP, the requests are the same and thus I don't see an issue >>> here. Nodes which are highly constrained may only support CoAP; larger nodes >>> can support the full HTTP method. >>> >>> Of course the whole subscription/notify method might take some changes to >>> make it accessible via HTTP... but thats another thread. >>> >>> -Colin >>> >>> >>> -----Original Message----- >>> From: core-bounces@ietf.org on behalf of Guido Moritz >>> Sent: Tue 18/05/2010 09:21 >>> To: core@ietf.org >>> Subject: Re: [core] Core UDP vs TCP : Redux >>> >>> From the CORE charter: >>>> 4) The core CoAP functionality MUST operate well over UDP and UDP MUST >>>> be implemented on CoAP Devices. There may be OPTIONAL functions in >>>> CoAP (e.g. delivery of larger chunks of data) which if implemented are >>>> implemented over TCP. Applications which require the optional TCP >>>> features will limit themselves to a narrower subset of deployment >>>> cases. >>> Running over TCP would narrow application scenarios? It would be more than >>> reasonable to design COAP while keeping UDP in mind. But as long as there >>> are no direct dependencies of COAP itself to the transport mechanisms, >>> don't >>> restrict it. This in contrast would extend application scenarios, because >>> you can use COAP also if reliable transport layer is required in the >>> scenario. >>> >>> Are there dependencies to UDP or is it only because the assumed >>> infrastructure is highly constrained? >>> >>> Guido >>> >>>> -----Ursprüngliche Nachricht----- >>>> Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag von >>>> Carsten Bormann >>>> Gesendet: Montag, 17. Mai 2010 18:59 >>>> An: Charles Palmer >>>> Cc: core >>>> Betreff: Re: [core] Core UDP vs TCP : Redux >>>> >>>> On May 17, 2010, at 17:47, Charles Palmer wrote: >>>> >>>>> How disruptive would it be to design CoRE without reference to >>>>> TCP/UDP, >>> and >>>> also design a "reliable UDP" and use this for CoRE? >>>> >>>> I personally think CoAP needs to work with DTLS; if the WG moves in that >>>> direction there will be some minimum requirement for independence from >>>> the >>>> underlying protocol. >>>> >>>> However, what we expect from the underlying protocol has a big bearing >>>> on >>> CoAP >>>> itself. >>>> If we expect we can always move to TCP, there will be little need to >>>> make >>> CoAP >>>> operate on large representations with small underlying interactions. >>>> I've >>>> heard a lot of pushback on assuming the availability of TCP, so far. >>>> >>>> There is also the aspect of interoperability: One of the great >>>> properties >>> of >>>> the Web is that everybody uses the same stack, so all Web clients and >>> servers >>>> are interoperable, with IP providing the necessary technological >>> diversity. >>>> (On the other hand, this has made it near impossible to swap in, say, >>> SCTP.) >>>> Just standardizing CoAP without an "we expect this to run on UDP, unless >>>> otherwise specified" would not achieve the same level of >>>> interoperability. >>>> >>>> In any case, designing a reliable transport as a TCP >>> replacement >>>> and then a CoAP on top of either that or TCP is very much not what the >>> charter >>>> suggests we are supposed to do. >>>> Instead, we should look at how stateless CoAP really can be made -- I >>> think >>>> even TFTP has too much state (and thus isn't as trivial a file transfer >>>> protocol as it could be). >>>> >>>> Gruesse, Carsten >>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >> -- >> Zach Shelby, Chief Nerd, Sensinode Ltd. >> http://zachshelby.org - My blog "On the Internet of Things" >> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" >> Mobile: +358 40 7796297 >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > -- __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ From angelo.castellani@gmail.com Wed May 26 03:09:24 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFB2D3A68E8 for ; Wed, 26 May 2010 03:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUr1XAylVRz1 for ; Wed, 26 May 2010 03:09:23 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 9D3613A68BD for ; Wed, 26 May 2010 03:09:21 -0700 (PDT) Received: by vws14 with SMTP id 14so2036484vws.31 for ; Wed, 26 May 2010 03:09:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=/u5/9RoW1eYVjfyXkyAgbjczz6FPhotemxsJ+h883rA=; b=mQjr59nGyiLflyLh+BwoBlnKJT/2IM3JvnmQGcrUbNqcqy4L7ja4Wh1Ku/0yCGNZvZ UKhgoGotlx3BNHLaSyWaYuSVlE9QnCjt+VYiVS/BaX0SJ1BCAQ2sqj96hCigYhxZQ+s7 TwA2QsCwlFVYGHvZpB/6YrQGt2OqFLSd/QUvU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=JpgQNSMeYv+7tic1NmMza3b+0qfv91TqnVZH20r7eSPEtsU7iTUj66QneMydBREOxd zFbX6+hHPsriTJmwue7n5KkKkDKwh3hXLw8Rb6QTExgxdY3eK5nMbs4bjVQA3rgOfayA i6aiN/LTzeVTVYnvOLoO4ykBLKaCgxvdbhHAg= MIME-Version: 1.0 Received: by 10.220.128.136 with SMTP id k8mr6091176vcs.198.1274868544875; Wed, 26 May 2010 03:09:04 -0700 (PDT) Sender: angelo.castellani@gmail.com Received: by 10.220.99.140 with HTTP; Wed, 26 May 2010 03:09:04 -0700 (PDT) In-Reply-To: <7ACD74E5-787D-47A4-82BF-5A640396D546@sensinode.com> References: <3BB5F67A-9E57-4F81-B7C5-ABB1E136DAAC@tzi.org> <568AEFD6-974D-4790-A2F8-84305B990BA9@cisco.com> <7ACD74E5-787D-47A4-82BF-5A640396D546@sensinode.com> Date: Wed, 26 May 2010 12:09:04 +0200 X-Google-Sender-Auth: eH9DQydJ1PbgoB3fWWfY2O2Z6G8 Message-ID: From: "Angelo P. Castellani" To: Zach Shelby Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core Subject: Re: [core] Selecting a WG document for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 10:09:24 -0000 Zach, thanks for the interesting discussion. In my opinion in the CoAP specification process HTTP interoperability should not be solved with a simple mapping between two different protocols. I think that can be more useful, reusable and interoperable to define a standard HTTP binary-compressed *bidirectional* translation of HTTP. After this is done we can focus on specific features (e.g. M2M communication through subscribe/notify, etc.) not included in the HTTP design goals. The current focus (not the result maybe) of coap-01 is quite different from this. Philosophy ended :) On Mon, May 24, 2010 at 15:45, Zach Shelby wrote: > Uniformity of what? Notify actually gives a uniform way of notifying abou= t a resource, and conceptually it does belong as a message. It is clearly n= ot Req/Res, please see the original list exchange started by Robert Cragie.= That is where we decided to make it a message instead of a Method. I can handle it as a different message type, but in my sw components interface specification this leads to the need to specify a completely different interface for pushing notifications to a resource. This introduces complexity in my constrained device software architecture. REQ/RES only interaction was selected to provide an uniform interface. That choice was an application of a well-known SW engineering principle: generalizing component interfaces simplifies the overall system architecture. > URI-Code is just something we started with, I am open to any scheme. Alre= ady your Sum Modulo-255 is being discussed, below it seems you are suggesti= ng a different one. Yes, I'm proposing actually two different formats. Depending upon the use case we can use one or the other. > Um, wrong. Content-Length and Content-Type are not always needed. We alre= ady discussed on the list that we can do without Content-Encoding. Right, Options bitmap fields are a very good solution for this kind of options then.. > I need some more convincing here that we really need cookies. What is the= use case? Suppose an user has a recurrent interaction with a generic resource, state informations about this interaction can be saved into a binary cookie and the complexity of memorizing that is left to the user not to the constrained device. > Sure, such an encoding could be used for all URIs, at least 7-bit ASCII e= ncoding would be easy and already now we are leaving out the / in coap-01. = This is a different issue to the Binary URI encoding. Yes is different, both are useful and depending upon the use-case we can choose which is better. CoAP -> HTTP translation requires the compressed URI format to interoperate with HTTP HTTP -> CoAP is supposed to use the BinaryURI format because if node resources have been added without collisions > This we can discuss. The working group is going to have to find a balance= between flexibility in options and efficiency/complexity. I originally pro= posed (coap-req-01) having a totally fixed header with no options, but the = WG clearly wanted options. You can't have your cake and eat it too. In my opinion split request and response options and put well-known Options in a bitmap is a very useful feature to reduce complexity and minimize packet size. If this is done, URI can be an Option because the result is quite the same :) > There are all really optimizations, which I am confident we will work thr= ough as a WG. I am also sure we can still simplify and improve coap! Sure, I'm quite interested in providing help, if I'm able to.. > All discussion and input are useful here. In the future it might be easie= r to split this up into smaller subject threads rather than a large list of= issues all at once. Thanks for the useful comments, sorry I will write the issues separately the next time.. Best, Angelo From fluffy@cisco.com Wed May 26 09:14:17 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 357D43A67B4 for ; Wed, 26 May 2010 09:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.117 X-Spam-Level: X-Spam-Status: No, score=-108.117 tagged_above=-999 required=5 tests=[AWL=-0.718, BAYES_50=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5BsRmzJaNSn for ; Wed, 26 May 2010 09:14:15 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 06C513A68DC for ; Wed, 26 May 2010 09:14:15 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,304,1272844800"; d="scan'208";a="203096484" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 26 May 2010 16:14:05 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4QGE4Nx014530; Wed, 26 May 2010 16:14:04 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <4BFB3ED5.5010101@cisco.com> Date: Wed, 26 May 2010 10:14:03 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <485AF6ECE8D1954D996771CC49E996FDC0F4BE30@IT-EXMB-01.silverspringnet.com> <17D5C562-AC60-43E7-B05F-B3F906693F99@sensinode.com><004801caf1da$822f4160$868dc420$@moritz@uni-rostock.de><002b01caf58d$a3b0d770$eb128650$@moritz@uni-rostock.de><2076146592-1274099833-cardhu_decombobulator_blackberry.rim.net-1047544741-@bda054.bisx.prod.on.blackberry><006901caf5c8$f9431d70$ebc95850$@moritz@uni-rostock.de><041A6061-2C61-43CA-8497-C5A978360FD4@tzi.org> <007c01caf5d3$30f026f0$92d074d0$@moritz@uni-rostock.de> <3C20B7FD-CB93-43CC-83D2-3F4209CC5B84@tzi.org> <002101caf663$1c251d30$546f5790$@moritz@uni-rostock.de> <355B1C46-98A8-4D4F-95B5-C011B2B81F92@sensinode.com> <4BFB3ED5.5010101@cisco.com> To: Paul Duffy , core X-Mailer: Apple Mail (2.1078) Subject: Re: [core] Core UDP vs TCP : Redux X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 16:14:17 -0000 Not arguing one way or the other about what we should do with security = but a few bits of information .... Michaels email nicely highlighted that we could use what I would call an = object security model where we secure the chunks of data being moved = around (his option 1) or use a session security model (his option 2). = Session security is often much easier to get to implemented and DTLS = would be the obvious candidate for this. Object security would have = advantages in a protocol that involves things like proxies, translators, = caches, nodes responding on behalf of other nodes that are powered off, = and multicast.=20 DTLS is simply TLS stuck on top of UDP. The reliability only covers the = TLS control messages but not the transported data so you still need to = deal with reliability & fragmentation the same as you would do for UDP.=20= =20 DTLS (and TLS) support session resumption so that you only have to do = expensive public key crypto the first time you ever connect to a given = server and after that it can be very fast. The people doing SIP over TLS = use this so that when a city looses power and all phones reboot at the = same time, the servers can keep up - it's easy and works well. The = client and server can decide how long to allow the cached info to be = used.=20 I'm not a security expert but if we have questions we need security = folks to answer, I can get the Sec ADs to find us someone to help. I = don't think we are at that point yet as I suspect there is a fair amount = of security expertise on this list. Let me know and I will make sure we = get the needed info. =20 Cullen On May 24, 2010, at 9:07 PM, Paul Duffy wrote: > IMO any decision pro/con DTLS is premature. Use of DTLS is desirable = as it "goes with the grain" of HTTP usage patterns. >=20 > I believe the DTLS concerns revolve around how long a session can be = kept alive. Or alternatively, over how long a period of time can I = amortize/cache session information for a single (expensive) key = establishment handshake. >=20 > Yes, we need security expertise to answer this question. >=20 >=20 > On 5/24/2010 11:14 AM, Zach Shelby wrote: >> So what I heard people want here: >>=20 >> 1. UDP as *the only* transport for simplicity and interoperability in = the spec (as long as we don't reinvent TCP). >> 2. CoAP to be transport independent as a protocol, thus allowing it = to be possibly used in other ways in the future. >> 3. A couple people think we might need a fragmentation feature for = responses with a payload size over the maximum. >> 4. DTLS might have complexity problems, should not be the only option = (Michael) >> 5. Some transport binding framework could be explored (Robert) >>=20 >> I agree with 1 and 2, and my proposal would be to remove the = TCP-specific text and sections from the next version of CoAP. We can = make the protocol itself independent of UDP (it really already is), = however UDP must be specified for interoperability reasons. I propose we = anyways keep some text saying something like >>=20 >> "Although this document specifies CoAP over UDP, the protocol may = also be applicable over other transports such as TCP or SCTP. The = specification of such use is out of scope of this document. >>=20 >> This would at least give us a starting point. I don't see the need = for developing frameworks or negotiation of multiple bindings for CoAP, = at least not now. >>=20 >> Regarding fragmentation, let's not jump the gun too soon here. For = the vast majority of constrained applications the 1280 byte maximum is = more than enough. For cases when it is not let's first see if it would = make sense to let the application deal with it. By the way, coap-01 has = a mistake with the 576B IPv4 maximum and 1280B IPv6 maximum. That = doesn't work for CoAP(IPv4)-CoAP(IPv6) proxying. Instead we should set = both to use the 1280 byte maximum. >>=20 >> Regarding DTLS, we are specifying how to use it with CoAP as it is a = secure transport. I agree with Michael that DTLS may very well be too = much for many constrained devices, so we should make it clear that this = is not the only way to do security, IPSEC e.g. is equally applicable = (and probably simpler) but doesn't require any specification in the = document. A security analysis ID would be a big help for the WG..... >>=20 >> Zach >>=20 >> On May 18, 2010, at 4:23 PM, Oflynn, Colin wrote: >>=20 >> =20 >>>> Are there dependencies to UDP or is it only because the assumed >>>> infrastructure is highly constrained? >>>> =20 >>> My thoughts/feeling on the issue is that CoAP should be designed = with a highly constrained environment, and as such being bound to UDP = makes it a lot simpler. >>>=20 >>> The resources which CoAP accesses SHOULD be accessible another in = another manner; most likely this is HTTP over TCP. Even though CoAP does = not map directly to HTTP, the requests are the same and thus I don't see = an issue here. Nodes which are highly constrained may only support CoAP; = larger nodes can support the full HTTP method. >>>=20 >>> Of course the whole subscription/notify method might take some = changes to make it accessible via HTTP... but thats another thread. >>>=20 >>> -Colin >>>=20 >>>=20 >>> -----Original Message----- >>> From: core-bounces@ietf.org on behalf of Guido Moritz >>> Sent: Tue 18/05/2010 09:21 >>> To: core@ietf.org >>> Subject: Re: [core] Core UDP vs TCP : Redux >>>=20 >>> =46rom the CORE charter: >>> =20 >>>> 4) The core CoAP functionality MUST operate well over UDP and UDP = MUST >>>> be implemented on CoAP Devices. There may be OPTIONAL functions in >>>> CoAP (e.g. delivery of larger chunks of data) which if implemented = are >>>> implemented over TCP. Applications which require the optional TCP >>>> features will limit themselves to a narrower subset of deployment >>>> cases. >>>> =20 >>> Running over TCP would narrow application scenarios? It would be = more than >>> reasonable to design COAP while keeping UDP in mind. But as long as = there >>> are no direct dependencies of COAP itself to the transport = mechanisms, don't >>> restrict it. This in contrast would extend application scenarios, = because >>> you can use COAP also if reliable transport layer is required in the >>> scenario. >>>=20 >>> Are there dependencies to UDP or is it only because the assumed >>> infrastructure is highly constrained? >>>=20 >>> Guido >>>=20 >>> =20 >>>> -----Urspr=FCngliche Nachricht----- >>>> Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im = Auftrag von >>>> Carsten Bormann >>>> Gesendet: Montag, 17. Mai 2010 18:59 >>>> An: Charles Palmer >>>> Cc: core >>>> Betreff: Re: [core] Core UDP vs TCP : Redux >>>>=20 >>>> On May 17, 2010, at 17:47, Charles Palmer wrote: >>>>=20 >>>> =20 >>>>> How disruptive would it be to design CoRE without reference to = TCP/UDP, >>>>> =20 >>> and >>> =20 >>>> also design a "reliable UDP" and use this for CoRE? >>>>=20 >>>> I personally think CoAP needs to work with DTLS; if the WG moves in = that >>>> direction there will be some minimum requirement for independence = from the >>>> underlying protocol. >>>>=20 >>>> However, what we expect from the underlying protocol has a big = bearing on >>>> =20 >>> CoAP >>> =20 >>>> itself. >>>> If we expect we can always move to TCP, there will be little need = to make >>>> =20 >>> CoAP >>> =20 >>>> operate on large representations with small underlying = interactions. I've >>>> heard a lot of pushback on assuming the availability of TCP, so = far. >>>>=20 >>>> There is also the aspect of interoperability: One of the great = properties >>>> =20 >>> of >>> =20 >>>> the Web is that everybody uses the same stack, so all Web clients = and >>>> =20 >>> servers >>> =20 >>>> are interoperable, with IP providing the necessary technological >>>> =20 >>> diversity. >>> =20 >>>> (On the other hand, this has made it near impossible to swap in, = say, >>>> =20 >>> SCTP.) >>> =20 >>>> Just standardizing CoAP without an "we expect this to run on UDP, = unless >>>> otherwise specified" would not achieve the same level of = interoperability. >>>>=20 >>>> In any case, designing a reliable transport as a TCP >>>> =20 >>> replacement >>> =20 >>>> and then a CoAP on top of either that or TCP is very much not what = the >>>> =20 >>> charter >>> =20 >>>> suggests we are supposed to do. >>>> Instead, we should look at how stateless CoAP really can be made -- = I >>>> =20 >>> think >>> =20 >>>> even TFTP has too much state (and thus isn't as trivial a file = transfer >>>> protocol as it could be). >>>>=20 >>>> Gruesse, 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 >>>=20 >>>=20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> =20 >> =20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From robert.cragie@gridmerge.com Wed May 26 11:09:45 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E81E93A6915 for ; Wed, 26 May 2010 11:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.152 X-Spam-Level: X-Spam-Status: No, score=0.152 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_50=0.001, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fG5HxRq42lV8 for ; Wed, 26 May 2010 11:09:41 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 8E17F3A6920 for ; Wed, 26 May 2010 11:09:40 -0700 (PDT) Received: from client-86-29-245-200.pete.adsl.virginmedia.com ([86.29.245.200] helo=[192.168.1.70]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1OHL2k-0000SM-IX; Wed, 26 May 2010 19:09:28 +0100 Message-ID: <4BFD63D3.3040207@gridmerge.com> Date: Wed, 26 May 2010 19:09:23 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Adriano Pezzuto (apezzuto)" References: <3602E0C6-1E2E-4164-A208-A874128325AF@sensinode.com><4BFB3A66.5080700@cisco.com><324781C3-5548-474D-8995-EC327ED08209@sensinode.com> <4BFC5368.2010602@cisco.com> <0D212BD466921646B58854FB79092CEC0216121C@XMB-AMS-106.cisco.com> In-Reply-To: <0D212BD466921646B58854FB79092CEC0216121C@XMB-AMS-106.cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090808020503020308020401" Cc: core Subject: Re: [core] Subscribe/Notify for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 18:09:45 -0000 This is a cryptographically signed message in MIME format. --------------ms090808020503020308020401 Content-Type: multipart/alternative; boundary="------------010705060600050603060108" This is a multi-part message in MIME format. --------------010705060600050603060108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Adrian, I would also prefer to keep the protocol in CoAP asynchronous. You can=20 always map an asynchronous protocol to a synchronous one but, as we see=20 in HTTP, it always ends up as a kludge to do it the other way round. The = efforts which have been gone to to make HTTP quasi-asynchronous via all=20 the schemes mentioned below and many more besides (all non-interoperable = of course) is testament to how important this is for M2M communication. So, back to Zach's list, I favor 1a) for the following reasons: Foundation level of messages: 1. request/response can be asynchronous or synchronous messages (as there is a transaction ID in there) 2. notify is an asynchronous message Derived methods: I think it makes sense to add a pub/sub model as a useful mechanism for M= 2M. So, looking at it the other way round: It will be entirely possible to=20 translate whatever is currently built on HTTP to CoAP based on the=20 above, with all its restrictions regarding synchronous and client/server = transactions. What may be harder is to translate directly is a=20 CoAP-based application to HTTP. So I guess the question is: Do we want=20 to be hamstrung to synchronous client/server transactions as dictated by = HTTP and provide a direct mapping to HTTP, then have to come up with=20 similar kludges for asynchronous peer-to-peer transactions as has been=20 done in numerous ways for HTTP, or do we want to define the protocol=20 cleanly to start with and accept that some sort of transaction=20 relaying/conversion would have to take place at a mapping node? Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote: > Hi, > it looks to me that CoAP should use an explicit sub/notify mechanism si= nce this is the core of the machine-to-machine interaction model. > HTTP suffers of this lack and we have seen a plethora of solutions to g= ive an asynch taste to it. Webhooks and websockets are only the lasts of = the list. > As someone has already pointed out on this list, it is theoretically po= ssible to describe sub/notify using only CRUD methods but it looks a litt= le bit tricky and verbose. > > Now we have a chance to build from scratch a new protocol with and I th= ink using explicit sub/notify methods with a clear and well defined seman= tic is the best option. It is easily understanding from every developer a= nd will prevent to build other fanny solutions on top of the CoAP. HTTP d= oes not have this well defined semantic and (for hundreds of other reason= s also) it is not used as wide protocol for machine-to-machine communicat= ion. > > CoAP - as binary protocol - and with an explicit asynch model has a cha= nce to be a really wide protocol for M2M communication not only for const= rained environments. > > my 2 cents > > - adriano > > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of= Paul Duffy (paduffy) > Sent: mercoled=EC 26 maggio 2010 0.47 > To: Zach Shelby > Cc: core > Subject: Re: [core] Subscribe/Notify for CoAP > > On 5/25/2010 6:41 PM, Zach Shelby wrote: > =20 >> Hi, >> >> On May 26, 2010, at 12:23 AM, Charles Palmer wrote: >> >> >> =20 >>> Hi folks >>> >>> It occurs to me that CoRE should be keeping a close eye on ZigBee SE2= =2E0 work, so that it is as easy as possible for ZigBee SE to use CoRE wh= en ready. That suggests to me that we should align with their subscribe/n= otify process. >>> >>> >>> =20 >> I am not sure I understand that. I mean, ZigBee SE2.0 is defining an a= pplication specific subscribe/notify mechanism for that purpose so far fo= r HTTP. This uses standard HTTP methods and some custom payload and REST = interfaces. CoAP Req/Res is already totally compatible with SE2.0 in that= respect, so alignment is already OK there. Nothing stopping someone from= using SE2.0 over CoAP. >> >> Specifying a native susbcription/notify into CoAP is another matter. W= e can't adopt a solution specific to one application as that won't solve = the problems of other applications nor general HTTP mapping at all (proba= bly would make it worse). It seems that for the near future there will be= a bunch of HTTP push mechanisms in use without any clear standard appear= ing - or am I wrong there? >> >> =20 > > > If COAP extends HTTP semantics with new subscription methods, it will > not be possible to easily interchange HTTP/COAP, and translation > gateways will become more complex to implement. > > > > =20 >> Zach >> >> >> =20 >>> Regards - Charles >>> >>> >>> -----Original Message----- >>> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Paul Duffy >>> Sent: 25 May 2010 03:48 >>> To: Zach Shelby >>> Cc: core >>> Subject: Re: [core] Subscribe/Notify for CoAP >>> >>> Recommend something like #2, primarily to avoid introducing non HTTP >>> method semantics, simplifying HTTP/COAP translation.gateways, etc. >>> >>> >>> On 5/24/2010 11:49 AM, Zach Shelby wrote: >>> >>> =20 >>>> (thread renamed) >>>> >>>> We have two different paths with regard to a subscribe/notify mechan= ism for CoAP: >>>> >>>> 1. Use specific Subscription and Notify mechanisms for CoAP as HTTP = really does not include this concept. >>>> 1a) Notify as a message and SUBSCRIBE as a method. This is currently= used in coap-01. >>>> 1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but w= e had a good list discussion about this leading to a. In practice it does= n't make a big difference if notification is a message or method. >>>> >>>> 2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2.0= proposal or GENA. >>>> >>>> So far we have focused on 1 in the WG, and every now and again 2 com= es up. At least I am not convinced that we need to suffer the drawbacks o= f HTTP here. Anyways 2 does not help our mapping to HTTP in reality very = much as there is no standard way of doing this over HTTP. Thus a CoAP-HTT= P proxy may end up anyways translating between multiple HTTP frameworks d= epending on the application. So instead of doing a CoAP Notify/Subscribe = to Webhooks mapping, you will could end up having to do a CoAP Webhooks t= o HTTP GENA mapping. >>>> >>>> >>>> =20 >>> I don't understand this last para. If CoAP sticks to the semantics o= f >>> the current HTTP methods, would this not offer a fairly straightforwa= rd >>> translation to/from HTTP? >>> >>> >>> >>> =20 >>>>> From what I have heard so far 1 still seems like a wise choice, = although I need to look at Webhooks more deeply. In reality many applicat= ions specify their own way of doing a push interface using REST methods a= nd specific payloads (ZigBee SE2.0 is such an example). That is just fine= , and might be used instead of a specific CoAP notify/subscribe in that c= ase. So 1 doesn't prevent the application using its own mechanism, it jus= t provides a native way for doing push. >>>>> >>>>> =20 >>>> What do people think? >>>> >>>> Zach >>>> >>>> On May 17, 2010, at 6:44 PM, matthieu.vial@fr.non.schneider-electric= =2Ecom wrote: >>>> >>>> >>>> >>>> =20 >>>>> Hi, >>>>> >>>>> My comments about the subscribe/notify mechanism of Zigbee IP. >>>>> >>>>> Pros: >>>>> - Derived from the webhooks concept >>>>> - If used by CORE it will be easier to map to HTTP because it uses = only CRUD verbs. >>>>> - The subscription message is extendable and could support advanced= options (delays, increment, ...) >>>>> - Only one listening port whatever the transport binding is. >>>>> >>>>> Cons: >>>>> - No interoperability without well known URIs and a well defined su= bscription message format (Not sure CoAP draft is the right place to spec= ify this). >>>>> - XML/EXI is too complex to be the required format for the default = subscription/notification mechanism. >>>>> - The notification should not require a subsequent GET to retrieve = the content. >>>>> - Subresource subscription is redundant. >>>>> >>>>> Hope this could help, >>>>> Matthieu >>>>> >>>>> >>>>> "Charles Palmer" >>>>> >>>>> >>>>> >>>>> >>>>> "Charles Palmer" >>>>> Envoy=E9 par : core-bounces@ietf.org >>>>> 15/05/2010 14:06 >>>>> >>>>> >>>>> A >>>>> >>>>> "core" >>>>> >>>>> cc >>>>> >>>>> >>>>> Objet >>>>> >>>>> Re: [core] Selecting a WG document for CoAP >>>>> >>>>> >>>>> Dear all >>>>> >>>>> Those interested in the subscribe/notify discussion might like to l= ook >>>>> at the draft Smart Energy Profile 2.0 Application Protocol >>>>> Specification. It is available here: >>>>> http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20Publ= icApp >>>>> licationProfile.aspx >>>>> >>>>> It manages subscribe/notify by using POST. This seems to remove the= need >>>>> for SUBSCRIBE and notify. >>>>> >>>>> "Imagine a host A, which exposes a resource at http{s}://A/resource= and >>>>> a second host B, which wishes to learn of changes to this resource.= To >>>>> facilitate a subscription/ notification mechanism, A would expose a= >>>>> resource http{s}://A/sub and B would expose a resource http{s}://B/= ntfy. >>>>> To subscribe to notifications regarding http{s}://A/resource, B wou= ld >>>>> send a POST to the address http{s}://A/sub/B containing the URI of = the >>>>> resource of interest (http{s}://A/resource) and the URI of B's >>>>> notification resource (http{s}://B/ntfy). Following this subscripti= on >>>>> step, should A wish to notify B of a change to the resource address= ed at >>>>> http{s}://A/resource, A would send a POST to the address >>>>> http{s}://B/ntfy containing the URI of the resource changed >>>>> (http{s}://A/resource) and the URI of A's subscription resource >>>>> (http{s}://A/sub/B), should A wish to change its subscription. The = host >>>>> B can then query the resource (or not) at its leisure." >>>>> >>>>> Sleepy nodes are not allowed to subscribe, and must poll. >>>>> >>>>> Regards - Charles Palmer >>>>> >>>>> -----Original Message----- >>>>> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behal= f Of >>>>> Angelo P. Castellani >>>>> Sent: 14 May 2010 13:14 >>>>> To: Zach Shelby >>>>> Cc: core >>>>> Subject: Re: [core] Selecting a WG document for CoAP >>>>> >>>>> Zach, >>>>> >>>>> thanks for the comments, but please refer to my most recent e-mail = for >>>>> a more specific list of technical issues I'm pointing to. >>>>> >>>>> I want to do only a little integration to what I've written there. >>>>> >>>>> In my very personal opinion, to maximize adherence with the REST mo= del >>>>> and minimize implementation effort SUBSCRIBE and NOTIFY should be >>>>> mapped to methods (as discussed many times together...). >>>>> >>>>> Uniform interface principle (Fielding PhD dissertation Section 5.1.= 5, >>>>> "The central feature that distinguishes the REST architectural styl= e >>>>> [...]") states that to simplify the software architecture, resource= >>>>> interfaces/interfaces should be as general as possible. >>>>> >>>>> I agree with this principle in this specific case, mainly because >>>>> handling a special message type for notify leads node software desi= gn >>>>> to a more complex architecture. >>>>> >>>>> The reason is that this new message type requires special handling = and >>>>> introduces a complexity in the software modularization. >>>>> >>>>> Best, >>>>> Angelo >>>>> >>>>> On Fri, May 14, 2010 at 13:06, Zach Shelby w= rote: >>>>> >>>>> >>>>> =20 >>>>>> Hi Angelo, >>>>>> >>>>>> On May 13, 2010, at 14:24 , Angelo P. Castellani wrote: >>>>>> >>>>>> >>>>>> >>>>>> =20 >>>>>>> Dear C. Bormann, all, >>>>>>> >>>>>>> before deciding for the final direction, I've the following >>>>>>> observations about draft-shelby-core-coap-01 >>>>>>> >>>>>>> While I mostly share Zach's view of the protocol approach, and >>>>>>> appreciate many aspects of the proposal, there are in my opinion >>>>>>> >>>>>>> >>>>>>> =20 >>>>> still >>>>> >>>>> >>>>> =20 >>>>>>> some open issues that need to be at least discussed before the >>>>>>> >>>>>>> >>>>>>> =20 >>>>> current >>>>> >>>>> >>>>> =20 >>>>>>> document can be selected. >>>>>>> >>>>>>> >>>>>>> =20 >>>>>> Of course there are plenty of open issues. Remember that working g= roup >>>>>> >>>>>> >>>>>> =20 >>>>> documents still undertake as much change and improvement as the WG >>>>> wants, so by no means is coap-01 set in stone. I would expect at le= ast >>>>> 5-10 more revisions still along the way. Already several of your i= deas >>>>> have been integrated into coap-01, and several more are under >>>>> consideration, so it is coming along. Patience ;-) >>>>> >>>>> >>>>> =20 >>>>>> >>>>>> =20 >>>>>>> In particular, I would like to highlight the following: >>>>>>> >>>>>>> a) As it is now, it is not possible to have a straightforward >>>>>>> translation of HTTP -> CoAP and viceversa: see >>>>>>> http://www.ietf.org/mail-archive/web/core/current/msg00133.html (= this >>>>>>> impacts the scalability of the web service model too) >>>>>>> >>>>>>> >>>>>>> =20 >>>>>> In coap-01 the Method names are now identical to HTTP methods. The= >>>>>> >>>>>> >>>>>> =20 >>>>> Req/Res interaction is a direct translation. The URI hierarchy is >>>>> compatible, and the URI binary code format we are still working on >>>>> obviously. The only thing that takes some state to translate is >>>>> Subscribe/Notify. But note, Subscribe/Notify takes some state no ma= tter >>>>> how you do it, even with HTTP-HTTP there is no clean and easy way t= o >>>>> handle subscriptions. >>>>> >>>>> >>>>> =20 >>>>>> >>>>>> =20 >>>>>>> b) Moreover, CoAP's implementation is not as simple as it should = be. >>>>>>> I've investigated the implementation and some design choices (as >>>>>>> Options) are leading to very high program complexity (ROM) on a >>>>>>> MSP430-based device. >>>>>>> >>>>>>> >>>>>>> =20 >>>>>> This we can definitely improve, and already made several optimizat= ions >>>>>> >>>>>> >>>>>> =20 >>>>> from -00 to -01. Here I need some very concrete proposals though. A= lso >>>>> remember that many things are optional, for example subscribe/notif= y is >>>>> not required if you don't need it. >>>>> >>>>> >>>>> =20 >>>>>> >>>>>> =20 >>>>>>> c) Finally when comparing HTTP message size with CoAP message siz= e, >>>>>>> the resulting compression isn't as good as you may expect. >>>>>>> >>>>>>> Example: >>>>>>> HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B >>>>>>> CoAP: 24 B with options parsing procedure requiring an added >>>>>>> implementation complexity >>>>>>> >>>>>>> >>>>>>> =20 >>>>>> Right, that is not how it will work in practice. Working with a re= al >>>>>> >>>>>> >>>>>> =20 >>>>> HTTP server that HTTP header will be more complex, and on the CoAP = side >>>>> you would chose shorter URLs. The biggest improvement possible here= is >>>>> from using binary coded URLs of course. We need to look at a wider = range >>>>> of interactions and real HTTP headers as well to check that we are >>>>> efficient enough. >>>>> >>>>> >>>>> =20 >>>>>> >>>>>> =20 >>>>>>> Addressing all these points potentially leads to major technical >>>>>>> modifications (especially point a) on the current draft, hence it= is >>>>>>> appropriate in my opinion to discuss these points before making t= he >>>>>>> final decision. >>>>>>> >>>>>>> >>>>>>> =20 >>>>>> I am not sure what else you have in mind for a). If we just forget= >>>>>> >>>>>> >>>>>> =20 >>>>> about Subscribe/Notify then you are good to go. But then you are al= so >>>>> not fulfilling the charter or the industry needs in that respect. >>>>> >>>>> >>>>> =20 >>>>>> Thanks, >>>>>> Zach >>>>>> >>>>>> >>>>>> >>>>>> =20 >>>>>>> Best regards, >>>>>>> >>>>>>> Angelo P. Castellani >>>>>>> >>>>>>> >>>>>>> On Mon, May 10, 2010 at 18:51, Carsten Bormann w= rote: >>>>>>> >>>>>>> >>>>>>> =20 >>>>>>>> The CORE WG has a milestone to select a WG document for CoAP in >>>>>>>> >>>>>>>> >>>>>>>> =20 >>>>> April: >>>>> >>>>> >>>>> =20 >>>>>>>> http://datatracker.ietf.org/wg/core/charter/ >>>>>>>> ... >>>>>>>> Apr 2010 Select WG document for basis of the CoAP protoco= l >>>>>>>> >>>>>>>> Of the various documents that have been contributed, >>>>>>>> >>>>>>>> >>>>>>>> =20 >>>>> draft-shelby-core-coap has significant discussion, as well as the >>>>> largest number of updates (including a previous version that was st= ill >>>>> called -6lowapp-coap). >>>>> >>>>> >>>>> =20 >>>>>>>> Today, another updated version of that draft was announced. See= >>>>>>>> http://www.ietf.org/mail-archive/web/core/current/msg00138.html >>>>>>>> for the announcement and >>>>>>>> http://tools.ietf.org/html/draft-shelby-core-coap-01 >>>>>>>> for the draft itself. >>>>>>>> >>>>>>>> However, as the authors say, there are still significant TODOs. >>>>>>>> >>>>>>>> Are we in a state yet where we can say whether this is the right= >>>>>>>> >>>>>>>> >>>>>>>> =20 >>>>> direction for the WG to take? >>>>> >>>>> >>>>> =20 >>>>>>>> If yes, is it the right direction? Should we adopt it as a WG >>>>>>>> >>>>>>>> >>>>>>>> =20 >>>>> document? >>>>> >>>>> >>>>> =20 >>>>>>>> If you don't think we can say yet, is there a set of technical >>>>>>>> >>>>>>>> >>>>>>>> =20 >>>>> decisions you would like the authors to take with priority? >>>>> >>>>> >>>>> =20 >>>>>>>> Note that once a document has become a WG document, the authors = act >>>>>>>> >>>>>>>> >>>>>>>> =20 >>>>> as editors for the working group, making (and usually fleshing out = the >>>>> details of) any change that the WG decides it needs. >>>>> >>>>> >>>>> =20 >>>>>>>> If you think we can still improve the draft, this is not an obst= acle >>>>>>>> >>>>>>>> >>>>>>>> =20 >>>>> to making it a WG document. >>>>> >>>>> >>>>> =20 >>>>>>>> But of course we shouldn't do that if we intend to reverse its >>>>>>>> >>>>>>>> >>>>>>>> =20 >>>>> fundamental technical direction. >>>>> >>>>> >>>>> =20 >>>>>>>> In order to stay roughly in sync with our milestones, we should >>>>>>>> >>>>>>>> >>>>>>>> =20 >>>>> reach at a decision on how to go forward this week. >>>>> >>>>> >>>>> =20 >>>>>>>> Gruesse, Carsten >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> core mailing list >>>>>>>> core@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/core >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> =20 >>>>>>> _______________________________________________ >>>>>>> core mailing list >>>>>>> core@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/core >>>>>>> >>>>>>> >>>>>>> =20 >>>>>> -- >>>>>> Zach Shelby, Chief Nerd, Sensinode Ltd. >>>>>> http://zachshelby.org - My blog "On the Internet of Things" >>>>>> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Inter= net" >>>>>> Mobile: +358 40 7796297 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> =20 >>>>> _______________________________________________ >>>>> core mailing list >>>>> core@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/core >>>>> >>>>> -------------------------------- >>>>> Onzo is a limited company number 06097997 registered in England& = Wales. The >>>>> registered office is 6 Great Newport Street, London, WC2H 7JB, Unit= ed Kingdom. >>>>> >>>>> This email message may contain confidential and/or privileged infor= mation, and >>>>> is intended solely for the addressee(s). If you have received this = email in >>>>> error, please notify Onzo immediately. Unauthorised copying, disclo= sure or >>>>> distribution of the material in this email is forbidden. >>>>> -------------------------------- >>>>> >>>>> _______________________________________________ >>>>> core mailing list >>>>> core@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/core >>>>> >>>>> ___________________________________________________________________= ___ >>>>> This email has been scanned by the MessageLabs Email Security Syste= m. >>>>> ___________________________________________________________________= ___ >>>>> >>>>> _______________________________________________ >>>>> core mailing list >>>>> core@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/core >>>>> >>>>> >>>>> =20 >>>> >>>> =20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >>> -------------------------------- >>> Onzo is a limited company number 06097997 registered in England& Wa= les. The >>> registered office is 6 Great Newport Street, London, WC2H 7JB, United= Kingdom. >>> >>> This email message may contain confidential and/or privileged informa= tion, and >>> is intended solely for the addressee(s). If you have received this em= ail in >>> error, please notify Onzo immediately. Unauthorised copying, disclosu= re or >>> distribution of the material in this email is forbidden. >>> -------------------------------- >>> >>> >>> =20 >> >> =20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > =20 --------------010705060600050603060108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Adrian,

I would also prefer to keep the protocol in CoAP asynchronous. You can always map an asynchronous protocol to a synchronous one but, as we see in HTTP, it always ends up as a kludge to do it the other way round. The efforts which have been gone to to make HTTP quasi-asynchronous via all the schemes mentioned below and many more besides (all non-interoperable of course) is testament to how important this is for M2M communication.

So, back to Zach's list, I favor 1a) for the following reasons:

Foundation level of messages:

=A0=A0 =

=A0=A0=A0=A0
 
________________________________________=
_______
core mailing list
core@ietf.org
https://www.ietf.org/=
mailman/listinfo/core
__________________________=
_____________________
core mailing =
list
core@ietf.org
https://www.ietf.org/=
mailman/listinfo/core
 
=A0 ------_=_NextPart_001_01CAFDC7.9FD53178-- From zach@sensinode.com Fri May 28 02:24:54 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4386D28C129 for ; Fri, 28 May 2010 02:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.301 X-Spam-Level: * X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7dyqRVQHLg8 for ; Fri, 28 May 2010 02:24:50 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 434F628C0E6 for ; Fri, 28 May 2010 02:19:43 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o4S9HrRb010436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 28 May 2010 12:17:53 +0300 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=windows-1252 From: Zach Shelby In-Reply-To: <0D212BD466921646B58854FB79092CEC021F4C22@XMB-AMS-106.cisco.com> Date: Fri, 28 May 2010 11:17:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1E96A4CF-F98A-4934-BBB6-1F201FCF85F2@sensinode.com> References: <3602E0C6-1E2E-4164-A208-A874128325AF@sensinode.com><4BFB3A66.5080700@cisco.com><324781C3-5548-474D-8995-EC327ED08209@sensinode.com> <4BFC5368.2010602@cisco.com> <0D212BD466921646B58854FB79092CEC0216121C@XMB-AMS-106.cisco.com> <4BFD63D3.3040207@gridmerge.com> <0D212BD466921646B58854FB79092CEC021F4C22@XMB-AMS-106.cisco.com> To: Adriano Pezzuto (apezzuto) X-Mailer: Apple Mail (2.1078) Cc: core Subject: Re: [core] Subscribe/Notify for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 09:24:54 -0000 Hi, On May 27, 2010, at 8:08 PM, Adriano Pezzuto (apezzuto) wrote: > Hi Robert, > =20 > in my personal opinion, the option 1a) brings some sort of ambiguity = to CoAP specs. > =20 > My be my understatement of new CoAP specs is not so deep, but now we = have 5 methods and 3 message types: request, response and notify. Which = methods are allowed with which messages types? > I suppose you have to use PUT/POST method with notify message for = asynch data notification. How to make a subscribe? I suppose you would = use a SUBSCRIBE method with request/response message or SUBSCRIBE with = notify message? Also what about POST/DELETE methods in a notify message? = They not make any sense.. Just for clarification, in coap-01 the Notify message has no method at = all. Correct, subscription is done with a Request using the SUBSCRIBE = method. Personally I have no problem with doing notify also as a method = (as in coap-00) if that is what we want as a working group. Robert had a = nice point that Notify does belong as a message type but functionally it = works well also as a method. Zach > I think the choice is between: option 1) -> only CRUD methods and = option 1b) -> CRUD + SUB/NOTIFY methods, keeping in mind cost/benefits = of both solutions. > =20 > Adriano > =20 > From: Robert Cragie [mailto:robert.cragie@gridmerge.com]=20 > Sent: mercoled=EC 26 maggio 2010 20.09 > To: Adriano Pezzuto (apezzuto) > Cc: Paul Duffy (paduffy); Zach Shelby; core > Subject: Re: [core] Subscribe/Notify for CoAP > =20 > Hi Adrian, >=20 > I would also prefer to keep the protocol in CoAP asynchronous. You can = always map an asynchronous protocol to a synchronous one but, as we see = in HTTP, it always ends up as a kludge to do it the other way round. The = efforts which have been gone to to make HTTP quasi-asynchronous via all = the schemes mentioned below and many more besides (all non-interoperable = of course) is testament to how important this is for M2M communication. >=20 > So, back to Zach's list, I favor 1a) for the following reasons: >=20 > Foundation level of messages: > =95 request/response can be asynchronous or synchronous messages = (as there is a transaction ID in there) > =95 notify is an asynchronous message > Derived methods: >=20 > I think it makes sense to add a pub/sub model as a useful mechanism = for M2M. >=20 > So, looking at it the other way round: It will be entirely possible to = translate whatever is currently built on HTTP to CoAP based on the = above, with all its restrictions regarding synchronous and client/server = transactions. What may be harder is to translate directly is a = CoAP-based application to HTTP. So I guess the question is: Do we want = to be hamstrung to synchronous client/server transactions as dictated by = HTTP and provide a direct mapping to HTTP, then have to come up with = similar kludges for asynchronous peer-to-peer transactions as has been = done in numerous ways for HTTP, or do we want to define the protocol = cleanly to start with and accept that some sort of transaction = relaying/conversion would have to take place at a mapping node? >=20 > Robert > Robert Cragie (Pacific Gas & Electric) >=20 > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 1924 910888 > +1 415 513 0064 > http://www.gridmerge.com >=20 >=20 > On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote: > Hi, > it looks to me that CoAP should use an explicit sub/notify mechanism = since this is the core of the machine-to-machine interaction model. > HTTP suffers of this lack and we have seen a plethora of solutions to = give an asynch taste to it. Webhooks and websockets are only the lasts = of the list. > As someone has already pointed out on this list, it is theoretically = possible to describe sub/notify using only CRUD methods but it looks a = little bit tricky and verbose. > =20 > Now we have a chance to build from scratch a new protocol with and I = think using explicit sub/notify methods with a clear and well defined = semantic is the best option. It is easily understanding from every = developer and will prevent to build other fanny solutions on top of the = CoAP. HTTP does not have this well defined semantic and (for hundreds of = other reasons also) it is not used as wide protocol for = machine-to-machine communication. > =20 > CoAP - as binary protocol - and with an explicit asynch model has a = chance to be a really wide protocol for M2M communication not only for = constrained environments. > =20 > my 2 cents > =20 > - adriano > =20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Paul Duffy (paduffy) > Sent: mercoled=EC 26 maggio 2010 0.47 > To: Zach Shelby > Cc: core > Subject: Re: [core] Subscribe/Notify for CoAP > =20 > On 5/25/2010 6:41 PM, Zach Shelby wrote: > =20 > Hi, > =20 > On May 26, 2010, at 12:23 AM, Charles Palmer wrote: > =20 > =20 > =20 > Hi folks > =20 > It occurs to me that CoRE should be keeping a close eye on ZigBee = SE2.0 work, so that it is as easy as possible for ZigBee SE to use CoRE = when ready. That suggests to me that we should align with their = subscribe/notify process. > =20 > =20 > =20 > I am not sure I understand that. I mean, ZigBee SE2.0 is defining an = application specific subscribe/notify mechanism for that purpose so far = for HTTP. This uses standard HTTP methods and some custom payload and = REST interfaces. CoAP Req/Res is already totally compatible with SE2.0 = in that respect, so alignment is already OK there. Nothing stopping = someone from using SE2.0 over CoAP. > =20 > Specifying a native susbcription/notify into CoAP is another matter. = We can't adopt a solution specific to one application as that won't = solve the problems of other applications nor general HTTP mapping at all = (probably would make it worse). It seems that for the near future there = will be a bunch of HTTP push mechanisms in use without any clear = standard appearing - or am I wrong there? > =20 > =20 > =20 > =20 > =20 > If COAP extends HTTP semantics with new subscription methods, it will=20= > not be possible to easily interchange HTTP/COAP, and translation=20 > gateways will become more complex to implement. > =20 > =20 > =20 > =20 > Zach > =20 > =20 > =20 > Regards - Charles > =20 > =20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Paul Duffy > Sent: 25 May 2010 03:48 > To: Zach Shelby > Cc: core > Subject: Re: [core] Subscribe/Notify for CoAP > =20 > Recommend something like #2, primarily to avoid introducing non HTTP > method semantics, simplifying HTTP/COAP translation.gateways, etc. > =20 > =20 > On 5/24/2010 11:49 AM, Zach Shelby wrote: > =20 > =20 > (thread renamed) > =20 > We have two different paths with regard to a subscribe/notify = mechanism for CoAP: > =20 > 1. Use specific Subscription and Notify mechanisms for CoAP as HTTP = really does not include this concept. > 1a) Notify as a message and SUBSCRIBE as a method. This is currently = used in coap-01. > 1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but we = had a good list discussion about this leading to a. In practice it = doesn't make a big difference if notification is a message or method. > =20 > 2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2.0 = proposal or GENA. > =20 > So far we have focused on 1 in the WG, and every now and again 2 comes = up. At least I am not convinced that we need to suffer the drawbacks of = HTTP here. Anyways 2 does not help our mapping to HTTP in reality very = much as there is no standard way of doing this over HTTP. Thus a = CoAP-HTTP proxy may end up anyways translating between multiple HTTP = frameworks depending on the application. So instead of doing a CoAP = Notify/Subscribe to Webhooks mapping, you will could end up having to do = a CoAP Webhooks to HTTP GENA mapping. > =20 > =20 > =20 > =20 > I don't understand this last para. If CoAP sticks to the semantics of > the current HTTP methods, would this not offer a fairly = straightforward > translation to/from HTTP? > =20 > =20 > =20 > =20 > =46rom what I have heard so far 1 still seems like a wise choice, = although I need to look at Webhooks more deeply. In reality many = applications specify their own way of doing a push interface using REST = methods and specific payloads (ZigBee SE2.0 is such an example). That is = just fine, and might be used instead of a specific CoAP notify/subscribe = in that case. So 1 doesn't prevent the application using its own = mechanism, it just provides a native way for doing push. > =20 > =20 > What do people think? > =20 > Zach > =20 > On May 17, 2010, at 6:44 PM, = matthieu.vial@fr.non.schneider-electric.com wrote: > =20 > =20 > =20 > =20 > Hi, > =20 > My comments about the subscribe/notify mechanism of Zigbee IP. > =20 > Pros: > - Derived from the webhooks concept > - If used by CORE it will be easier to map to HTTP because it uses = only CRUD verbs. > - The subscription message is extendable and could support advanced = options (delays, increment, ...) > - Only one listening port whatever the transport binding is. > =20 > Cons: > - No interoperability without well known URIs and a well defined = subscription message format (Not sure CoAP draft is the right place to = specify this). > - XML/EXI is too complex to be the required format for the default = subscription/notification mechanism. > - The notification should not require a subsequent GET to retrieve the = content. > - Subresource subscription is redundant. > =20 > Hope this could help, > Matthieu > =20 > =20 > "Charles Palmer" > =20 > =20 > =20 > =20 > "Charles Palmer" > Envoy=E9 par : core-bounces@ietf.org > 15/05/2010 14:06 > =20 > > A > > "core" > > cc > > > Objet > > Re: [core] Selecting a WG document for CoAP > > =20 > Dear all > =20 > Those interested in the subscribe/notify discussion might like to look > at the draft Smart Energy Profile 2.0 Application Protocol > Specification. It is available here: > = http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicApp > licationProfile.aspx > =20 > It manages subscribe/notify by using POST. This seems to remove the = need > for SUBSCRIBE and notify. > =20 > "Imagine a host A, which exposes a resource at http{s}://A/resource = and > a second host B, which wishes to learn of changes to this resource. To > facilitate a subscription/ notification mechanism, A would expose a > resource http{s}://A/sub and B would expose a resource = http{s}://B/ntfy. > To subscribe to notifications regarding http{s}://A/resource, B would > send a POST to the address http{s}://A/sub/B containing the URI of the > resource of interest (http{s}://A/resource) and the URI of B's > notification resource (http{s}://B/ntfy). Following this subscription > step, should A wish to notify B of a change to the resource addressed = at > http{s}://A/resource, A would send a POST to the address > http{s}://B/ntfy containing the URI of the resource changed > (http{s}://A/resource) and the URI of A's subscription resource > (http{s}://A/sub/B), should A wish to change its subscription. The = host > B can then query the resource (or not) at its leisure." > =20 > Sleepy nodes are not allowed to subscribe, and must poll. > =20 > Regards - Charles Palmer > =20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of > Angelo P. Castellani > Sent: 14 May 2010 13:14 > To: Zach Shelby > Cc: core > Subject: Re: [core] Selecting a WG document for CoAP > =20 > Zach, > =20 > thanks for the comments, but please refer to my most recent e-mail for > a more specific list of technical issues I'm pointing to. > =20 > I want to do only a little integration to what I've written there. > =20 > In my very personal opinion, to maximize adherence with the REST model > and minimize implementation effort SUBSCRIBE and NOTIFY should be > mapped to methods (as discussed many times together...). > =20 > Uniform interface principle (Fielding PhD dissertation Section 5.1.5, > "The central feature that distinguishes the REST architectural style > [...]") states that to simplify the software architecture, resource > interfaces/interfaces should be as general as possible. > =20 > I agree with this principle in this specific case, mainly because > handling a special message type for notify leads node software design > to a more complex architecture. > =20 > The reason is that this new message type requires special handling and > introduces a complexity in the software modularization. > =20 > Best, > Angelo > =20 > On Fri, May 14, 2010 at 13:06, Zach Shelby = wrote: > =20 > =20 > =20 > Hi Angelo, > =20 > On May 13, 2010, at 14:24 , Angelo P. Castellani wrote: > =20 > =20 > =20 > =20 > Dear C. Bormann, all, > =20 > before deciding for the final direction, I've the following > observations about draft-shelby-core-coap-01 > =20 > While I mostly share Zach's view of the protocol approach, and > appreciate many aspects of the proposal, there are in my opinion > =20 > =20 > =20 > still > =20 > =20 > =20 > some open issues that need to be at least discussed before the > =20 > =20 > =20 > current > =20 > =20 > =20 > document can be selected. > =20 > =20 > =20 > Of course there are plenty of open issues. Remember that working group > =20 > =20 > =20 > documents still undertake as much change and improvement as the WG > wants, so by no means is coap-01 set in stone. I would expect at least > 5-10 more revisions still along the way. Already several of your = ideas > have been integrated into coap-01, and several more are under > consideration, so it is coming along. Patience ;-) > =20 > =20 > =20 > =20 > =20 > In particular, I would like to highlight the following: > =20 > a) As it is now, it is not possible to have a straightforward > translation of HTTP -> CoAP and viceversa: see > http://www.ietf.org/mail-archive/web/core/current/msg00133.html (this > impacts the scalability of the web service model too) > =20 > =20 > =20 > In coap-01 the Method names are now identical to HTTP methods. The > =20 > =20 > =20 > Req/Res interaction is a direct translation. The URI hierarchy is > compatible, and the URI binary code format we are still working on > obviously. The only thing that takes some state to translate is > Subscribe/Notify. But note, Subscribe/Notify takes some state no = matter > how you do it, even with HTTP-HTTP there is no clean and easy way to > handle subscriptions. > =20 > =20 > =20 > =20 > =20 > b) Moreover, CoAP's implementation is not as simple as it should be. > I've investigated the implementation and some design choices (as > Options) are leading to very high program complexity (ROM) on a > MSP430-based device. > =20 > =20 > =20 > This we can definitely improve, and already made several optimizations > =20 > =20 > =20 > from -00 to -01. Here I need some very concrete proposals though. Also > remember that many things are optional, for example subscribe/notify = is > not required if you don't need it. > =20 > =20 > =20 > =20 > =20 > c) Finally when comparing HTTP message size with CoAP message size, > the resulting compression isn't as good as you may expect. > =20 > Example: > HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B > CoAP: 24 B with options parsing procedure requiring an added > implementation complexity > =20 > =20 > =20 > Right, that is not how it will work in practice. Working with a real > =20 > =20 > =20 > HTTP server that HTTP header will be more complex, and on the CoAP = side > you would chose shorter URLs. The biggest improvement possible here is > from using binary coded URLs of course. We need to look at a wider = range > of interactions and real HTTP headers as well to check that we are > efficient enough. > =20 > =20 > =20 > =20 > =20 > Addressing all these points potentially leads to major technical > modifications (especially point a) on the current draft, hence it is > appropriate in my opinion to discuss these points before making the > final decision. > =20 > =20 > =20 > I am not sure what else you have in mind for a). If we just forget > =20 > =20 > =20 > about Subscribe/Notify then you are good to go. But then you are also > not fulfilling the charter or the industry needs in that respect. > =20 > =20 > =20 > Thanks, > Zach > =20 > =20 > =20 > =20 > Best regards, > =20 > Angelo P. Castellani > =20 > =20 > On Mon, May 10, 2010 at 18:51, Carsten Bormann wrote: > =20 > =20 > =20 > The CORE WG has a milestone to select a WG document for CoAP in > =20 > =20 > =20 > April: > =20 > =20 > =20 > http://datatracker.ietf.org/wg/core/charter/ > ... > Apr 2010 Select WG document for basis of the CoAP protocol > =20 > Of the various documents that have been contributed, > =20 > =20 > =20 > draft-shelby-core-coap has significant discussion, as well as the > largest number of updates (including a previous version that was still > called -6lowapp-coap). > =20 > =20 > =20 > Today, another updated version of that draft was announced. See > http://www.ietf.org/mail-archive/web/core/current/msg00138.html > for the announcement and > http://tools.ietf.org/html/draft-shelby-core-coap-01 > for the draft itself. > =20 > However, as the authors say, there are still significant TODOs. > =20 > Are we in a state yet where we can say whether this is the right > =20 > =20 > =20 > direction for the WG to take? > =20 > =20 > =20 > If yes, is it the right direction? Should we adopt it as a WG > =20 > =20 > =20 > document? > =20 > =20 > =20 > If you don't think we can say yet, is there a set of technical > =20 > =20 > =20 > decisions you would like the authors to take with priority? > =20 > =20 > =20 > Note that once a document has become a WG document, the authors act > =20 > =20 > =20 > as editors for the working group, making (and usually fleshing out the > details of) any change that the WG decides it needs. > =20 > =20 > =20 > If you think we can still improve the draft, this is not an obstacle > =20 > =20 > =20 > to making it a WG document. > =20 > =20 > =20 > But of course we shouldn't do that if we intend to reverse its > =20 > =20 > =20 > fundamental technical direction. > =20 > =20 > =20 > In order to stay roughly in sync with our milestones, we should > =20 > =20 > =20 > reach at a decision on how to go forward this week. > =20 > =20 > =20 > Gruesse, Carsten > =20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > =20 > =20 > =20 > =20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > =20 > =20 > =20 > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > =20 > =20 > =20 > =20 > =20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > =20 > -------------------------------- > Onzo is a limited company number 06097997 registered in England& = Wales. The > registered office is 6 Great Newport Street, London, WC2H 7JB, United = Kingdom. > =20 > This email message may contain confidential and/or privileged = information, and > is intended solely for the addressee(s). If you have received this = email in > error, please notify Onzo immediately. Unauthorised copying, = disclosure or > distribution of the material in this email is forbidden. > -------------------------------- > =20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > =20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > ______________________________________________________________________ > =20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > =20 > =20 > =20 > =20 > =20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > =20 > -------------------------------- > Onzo is a limited company number 06097997 registered in England& = Wales. The > registered office is 6 Great Newport Street, London, WC2H 7JB, United = Kingdom. > =20 > This email message may contain confidential and/or privileged = information, and > is intended solely for the addressee(s). If you have received this = email in > error, please notify Onzo immediately. Unauthorised copying, = disclosure or > distribution of the material in this email is forbidden. > -------------------------------- > =20 > =20 > =20 > =20 > =20 > =20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > =20 > =20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From robert.cragie@gridmerge.com Fri May 28 02:53:28 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E1043A68C6 for ; Fri, 28 May 2010 02:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.302 X-Spam-Level: * X-Spam-Status: No, score=1.302 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gM3rO3tdrKME for ; Fri, 28 May 2010 02:53:24 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 973F63A68D6 for ; Fri, 28 May 2010 02:53:22 -0700 (PDT) Received: from client-82-26-176-40.pete.adsl.virginmedia.com ([82.26.176.40] helo=[192.168.1.70]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1OHwFX-0007ki-SC; Fri, 28 May 2010 10:53:10 +0100 Message-ID: <4BFF927F.1090208@gridmerge.com> Date: Fri, 28 May 2010 10:53:03 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Adriano Pezzuto (apezzuto)" References: <3602E0C6-1E2E-4164-A208-A874128325AF@sensinode.com><4BFB3A66.5080700@cisco.com><324781C3-5548-474D-8995-EC327ED08209@sensinode.com> <4BFC5368.2010602@cisco.com> <0D212BD466921646B58854FB79092CEC0216121C@XMB-AMS-106.cisco.com> <4BFD63D3.3040207@gridmerge.com> <0D212BD466921646B58854FB79092CEC021F4C22@XMB-AMS-106.cisco.com> In-Reply-To: <0D212BD466921646B58854FB79092CEC021F4C22@XMB-AMS-106.cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050308070407020607000203" Cc: core Subject: Re: [core] Subscribe/Notify for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 09:53:28 -0000 This is a cryptographically signed message in MIME format. --------------ms050308070407020607000203 Content-Type: multipart/alternative; boundary="------------070107090206070909090407" This is a multi-part message in MIME format. --------------070107090206070909090407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I think the point here is that there are two levels we are considering. At the lowest (foundation) level, there are the transaction messages as=20 described below. This provides a flexible mechanism for the application=20 with regard to synchronicity and threading. This is important for the=20 types of devices CoAP is being aimed at. Above that, the methods can be used according to the architectural=20 style. So in this case, it is RESTful (COnstrained Restful=20 Environments), which will naturally limit the number of methods and how=20 transactions occur. The actual architecture using a combination of the methods and messages=20 also depends on what is required at the application layer. Consider a=20 typical client which wants to subscribe to a resource. That client=20 controls the feed of data but needs a component which is capable of=20 handling (possibly buffering) the data it receives through=20 notifications. Is this a separate server? Or would we want to consider=20 it part of an enhanced client model which is able to process feeds of=20 data? These are the sort of models which have led to the myriad of=20 solutions (GENA, Webhooks, long polling, pubsubhubbub, RESTMS etc.)=20 based around HTTP which are all essentially ingenious ways of getting=20 around the limitations imposed by HTTP and how it is processed for=20 anything which deviates from the classic web page access model. I think the aim of CoAP should be clean from the word go with regard to=20 supporting these more peer-to-peer transactions, where the client can=20 exist on either entity and both entities can feed data to each other;=20 typical in M2M applications. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 27/05/2010 7:08 PM, Adriano Pezzuto (apezzuto) wrote: > > Hi Robert, > > in my personal opinion, the option 1a) brings some sort of ambiguity=20 > to CoAP specs. > > My be my understatement of new CoAP specs is not so deep, but now we=20 > have 5 methods and 3 message types: request, response and notify.=20 > Which methods are allowed with which messages types? > > I suppose you have to use PUT/POST method with notify message for=20 > asynch data notification. How to make a subscribe? I suppose you would = > use a SUBSCRIBE method with request/response message or SUBSCRIBE with = > notify message? Also what about POST/DELETE methods in a notify=20 > message? They not make any sense.. > > I think the choice is between: option 1) -> only CRUD methods and=20 > option 1b) -> CRUD + SUB/NOTIFY methods, keeping in mind cost/benefits = > of both solutions. > > Adriano > > *From:* Robert Cragie [mailto:robert.cragie@gridmerge.com] > *Sent:* mercoled=EC 26 maggio 2010 20.09 > *To:* Adriano Pezzuto (apezzuto) > *Cc:* Paul Duffy (paduffy); Zach Shelby; core > *Subject:* Re: [core] Subscribe/Notify for CoAP > > Hi Adrian, > > I would also prefer to keep the protocol in CoAP asynchronous. You can = > always map an asynchronous protocol to a synchronous one but, as we=20 > see in HTTP, it always ends up as a kludge to do it the other way=20 > round. The efforts which have been gone to to make HTTP=20 > quasi-asynchronous via all the schemes mentioned below and many more=20 > besides (all non-interoperable of course) is testament to how=20 > important this is for M2M communication. > > So, back to Zach's list, I favor 1a) for the following reasons: > > Foundation level of messages: > > 1. request/response can be asynchronous or synchronous messages (as > there is a transaction ID in there) > 2. notify is an asynchronous message > > Derived methods: > > I think it makes sense to add a pub/sub model as a useful mechanism=20 > for M2M. > > So, looking at it the other way round: It will be entirely possible to = > translate whatever is currently built on HTTP to CoAP based on the=20 > above, with all its restrictions regarding synchronous and=20 > client/server transactions. What may be harder is to translate=20 > directly is a CoAP-based application to HTTP. So I guess the question=20 > is: Do we want to be hamstrung to synchronous client/server=20 > transactions as dictated by HTTP and provide a direct mapping to HTTP, = > then have to come up with similar kludges for asynchronous=20 > peer-to-peer transactions as has been done in numerous ways for HTTP,=20 > or do we want to define the protocol cleanly to start with and accept=20 > that some sort of transaction relaying/conversion would have to take=20 > place at a mapping node? > > Robert > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 1924 910888 > +1 415 513 0064 > http://www.gridmerge.com > > > On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote: > > Hi, > it looks to me that CoAP should use an explicit sub/notify mechanism si= nce this is the core of the machine-to-machine interaction model. > HTTP suffers of this lack and we have seen a plethora of solutions to g= ive an asynch taste to it. Webhooks and websockets are only the lasts of = the list. > As someone has already pointed out on this list, it is theoretically po= ssible to describe sub/notify using only CRUD methods but it looks a litt= le bit tricky and verbose. > =20 > Now we have a chance to build from scratch a new protocol with and I th= ink using explicit sub/notify methods with a clear and well defined seman= tic is the best option. It is easily understanding from every developer a= nd will prevent to build other fanny solutions on top of the CoAP. HTTP d= oes not have this well defined semantic and (for hundreds of other reason= s also) it is not used as wide protocol for machine-to-machine communicat= ion. > =20 > CoAP - as binary protocol - and with an explicit asynch model has a cha= nce to be a really wide protocol for M2M communication not only for const= rained environments. > =20 > my 2 cents > =20 > - adriano > =20 > -----Original Message----- > From:core-bounces@ietf.org [mailto:cor= e-bounces@ietf.org] On Behalf Of Paul Duffy (paduffy) > Sent: mercoled=EC 26 maggio 2010 0.47 > To: Zach Shelby > Cc: core > Subject: Re: [core] Subscribe/Notify for CoAP > =20 > On 5/25/2010 6:41 PM, Zach Shelby wrote: > =20 > > Hi, > > =20 > > On May 26, 2010, at 12:23 AM, Charles Palmer wrote: > > =20 > > =20 > > =20 > > Hi folks > > =20 > > It occurs to me that CoRE should be keeping a close eye on ZigB= ee SE2.0 work, so that it is as easy as possible for ZigBee SE to use CoR= E when ready. That suggests to me that we should align with their subscri= be/notify process. > > =20 > > =20 > > =20 > > I am not sure I understand that. I mean, ZigBee SE2.0 is defining a= n application specific subscribe/notify mechanism for that purpose so far= for HTTP. This uses standard HTTP methods and some custom payload and RE= ST interfaces. CoAP Req/Res is already totally compatible with SE2.0 in t= hat respect, so alignment is already OK there. Nothing stopping someone f= rom using SE2.0 over CoAP. > > =20 > > Specifying a native susbcription/notify into CoAP is another matter= =2E We can't adopt a solution specific to one application as that won't s= olve the problems of other applications nor general HTTP mapping at all (= probably would make it worse). It seems that for the near future there wi= ll be a bunch of HTTP push mechanisms in use without any clear standard a= ppearing - or am I wrong there? > > =20 > > =20 > > =20 > =20 > =20 > If COAP extends HTTP semantics with new subscription methods, it will > not be possible to easily interchange HTTP/COAP, and translation > gateways will become more complex to implement. > =20 > =20 > =20 > =20 > > Zach > > =20 > > =20 > > =20 > > Regards - Charles > > =20 > > =20 > > -----Original Message----- > > From:core-bounces@ietf.org [ma= ilto:core-bounces@ietf.org] On Behalf Of Paul Duffy > > Sent: 25 May 2010 03:48 > > To: Zach Shelby > > Cc: core > > Subject: Re: [core] Subscribe/Notify for CoAP > > =20 > > Recommend something like #2, primarily to avoid introducing non= HTTP > > method semantics, simplifying HTTP/COAP translation.gateways, e= tc. > > =20 > > =20 > > On 5/24/2010 11:49 AM, Zach Shelby wrote: > > =20 > > =20 > > (thread renamed) > > =20 > > We have two different paths with regard to a subscribe/noti= fy mechanism for CoAP: > > =20 > > 1. Use specific Subscription and Notify mechanisms for CoAP= as HTTP really does not include this concept. > > 1a) Notify as a message and SUBSCRIBE as a method. This is = currently used in coap-01. > > 1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-= 00, but we had a good list discussion about this leading to a. In practic= e it doesn't make a big difference if notification is a message or method= =2E > > =20 > > 2. Use an HTTP specific framework such as Webhooks, the Zig= Bee SE2.0 proposal or GENA. > > =20 > > So far we have focused on 1 in the WG, and every now and ag= ain 2 comes up. At least I am not convinced that we need to suffer the dr= awbacks of HTTP here. Anyways 2 does not help our mapping to HTTP in real= ity very much as there is no standard way of doing this over HTTP. Thus a= CoAP-HTTP proxy may end up anyways translating between multiple HTTP fra= meworks depending on the application. So instead of doing a CoAP Notify/S= ubscribe to Webhooks mapping, you will could end up having to do a CoAP W= ebhooks to HTTP GENA mapping. > > =20 > > =20 > > =20 > > =20 > > I don't understand this last para. If CoAP sticks to the seman= tics of > > the current HTTP methods, would this not offer a fairly straigh= tforward > > translation to/from HTTP? > > =20 > > =20 > > =20 > > =20 > > From what I have heard so far 1 still seems like a wi= se choice, although I need to look at Webhooks more deeply. In reality ma= ny applications specify their own way of doing a push interface using RES= T methods and specific payloads (ZigBee SE2.0 is such an example). That i= s just fine, and might be used instead of a specific CoAP notify/subscrib= e in that case. So 1 doesn't prevent the application using its own mechan= ism, it just provides a native way for doing push. > > =20 > > =20 > > What do people think? > > =20 > > Zach > > =20 > > On May 17, 2010, at 6:44 PM,matthieu.vial@fr.non.schneider-= electric.com wrote= : > > =20 > > =20 > > =20 > > =20 > > Hi, > > =20 > > My comments about the subscribe/notify mechanism of Zig= bee IP. > > =20 > > Pros: > > - Derived from the webhooks concept > > - If used by CORE it will be easier to map to HTTP beca= use it uses only CRUD verbs. > > - The subscription message is extendable and could supp= ort advanced options (delays, increment, ...) > > - Only one listening port whatever the transport bindin= g is. > > =20 > > Cons: > > - No interoperability without well known URIs and a wel= l defined subscription message format (Not sure CoAP draft is the right p= lace to specify this). > > - XML/EXI is too complex to be the required format for = the default subscription/notification mechanism. > > - The notification should not require a subsequent GET = to retrieve the content. > > - Subresource subscription is redundant. > > =20 > > Hope this could help, > > Matthieu > > =20 > > =20 > > "Charles Palmer" = > > =20 > > =20 > > =20 > > =20 > > "Charles Palmer" > > Envoy=E9 par :core-bounces@ietf.org > > 15/05/2010 14:06 > > =20 > > > > A > > > > "core" > > > > cc > > > > > > Objet > > > > Re: [core] Selecting a WG document for CoAP > > > > =20 > > Dear all > > =20 > > Those interested in the subscribe/notify discussion mig= ht like to look > > at the draft Smart Energy Profile 2.0 Application Proto= col > > Specification. It is available here: > > http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmart= Energy20PublicApp > > licationProfile.aspx > > =20 > > It manages subscribe/notify by using POST. This seems t= o remove the need > > for SUBSCRIBE and notify. > > =20 > > "Imagine a host A, which exposes a resource at http{s}:= //A/resource and > > a second host B, which wishes to learn of changes to th= is resource. To > > facilitate a subscription/ notification mechanism, A wo= uld expose a > > resource http{s}://A/sub and B would expose a resource = http{s}://B/ntfy. > > To subscribe to notifications regarding http{s}://A/res= ource, B would > > send a POST to the address http{s}://A/sub/B containing= the URI of the > > resource of interest (http{s}://A/resource) and the URI= of B's > > notification resource (http{s}://B/ntfy). Following thi= s subscription > > step, should A wish to notify B of a change to the reso= urce addressed at > > http{s}://A/resource, A would send a POST to the addres= s > > http{s}://B/ntfy containing the URI of the resource cha= nged > > (http{s}://A/resource) and the URI of A's subscription = resource > > (http{s}://A/sub/B), should A wish to change its subscr= iption. The host > > B can then query the resource (or not) at its leisure."= > > =20 > > Sleepy nodes are not allowed to subscribe, and must pol= l. > > =20 > > Regards - Charles Palmer > > =20 > > -----Original Message----- > > From:core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of > > Angelo P. Castellani > > Sent: 14 May 2010 13:14 > > To: Zach Shelby > > Cc: core > > Subject: Re: [core] Selecting a WG document for CoAP > > =20 > > Zach, > > =20 > > thanks for the comments, but please refer to my most re= cent e-mail for > > a more specific list of technical issues I'm pointing t= o. > > =20 > > I want to do only a little integration to what I've wri= tten there. > > =20 > > In my very personal opinion, to maximize adherence with= the REST model > > and minimize implementation effort SUBSCRIBE and NOTIFY= should be > > mapped to methods (as discussed many times together...)= =2E > > =20 > > Uniform interface principle (Fielding PhD dissertation = Section 5.1.5, > > "The central feature that distinguishes the REST archit= ectural style > > [...]") states that to simplify the software architectu= re, resource > > interfaces/interfaces should be as general as possible.= > > =20 > > I agree with this principle in this specific case, main= ly because > > handling a special message type for notify leads node s= oftware design > > to a more complex architecture. > > =20 > > The reason is that this new message type requires speci= al handling and > > introduces a complexity in the software modularization.= > > =20 > > Best, > > Angelo > > =20 > > On Fri, May 14, 2010 at 13:06, Zach Shelby wrote: > > =20 > > =20 > > =20 > > Hi Angelo, > > =20 > > On May 13, 2010, at 14:24 , Angelo P. Castellani wr= ote: > > =20 > > =20 > > =20 > > =20 > > Dear C. Bormann, all, > > =20 > > before deciding for the final direction, I've t= he following > > observations about draft-shelby-core-coap-01 > > =20 > > While I mostly share Zach's view of the protoco= l approach, and > > appreciate many aspects of the proposal, there = are in my opinion > > =20 > > =20 > > =20 > > still > > =20 > > =20 > > =20 > > some open issues that need to be at least discu= ssed before the > > =20 > > =20 > > =20 > > current > > =20 > > =20 > > =20 > > document can be selected. > > =20 > > =20 > > =20 > > Of course there are plenty of open issues. Remember= that working group > > =20 > > =20 > > =20 > > documents still undertake as much change and improvemen= t as the WG > > wants, so by no means is coap-01 set in stone. I would = expect at least > > 5-10 more revisions still along the way. Already sever= al of your ideas > > have been integrated into coap-01, and several more are= under > > consideration, so it is coming along. Patience ;-) > > =20 > > =20 > > =20 > > =20 > > =20 > > In particular, I would like to highlight the fo= llowing: > > =20 > > a) As it is now, it is not possible to have a s= traightforward > > translation of HTTP -> CoAP and viceversa: s= ee > > http://www.ietf.org/mail-archive/web/core/curre= nt/msg00133.html (this > > impacts the scalability of the web service mode= l too) > > =20 > > =20 > > =20 > > In coap-01 the Method names are now identical to HT= TP methods. The > > =20 > > =20 > > =20 > > Req/Res interaction is a direct translation. The URI hi= erarchy is > > compatible, and the URI binary code format we are still= working on > > obviously. The only thing that takes some state to tran= slate is > > Subscribe/Notify. But note, Subscribe/Notify takes some= state no matter > > how you do it, even with HTTP-HTTP there is no clean an= d easy way to > > handle subscriptions. > > =20 > > =20 > > =20 > > =20 > > =20 > > b) Moreover, CoAP's implementation is not as si= mple as it should be. > > I've investigated the implementation and some d= esign choices (as > > Options) are leading to very high program compl= exity (ROM) on a > > MSP430-based device. > > =20 > > =20 > > =20 > > This we can definitely improve, and already made se= veral optimizations > > =20 > > =20 > > =20 > > from -00 to -01. Here I need some very concrete proposa= ls though. Also > > remember that many things are optional, for example sub= scribe/notify is > > not required if you don't need it. > > =20 > > =20 > > =20 > > =20 > > =20 > > c) Finally when comparing HTTP message size wit= h CoAP message size, > > the resulting compression isn't as good as you = may expect. > > =20 > > Example: > > HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B > > CoAP: 24 B with options parsing procedure requi= ring an added > > implementation complexity > > =20 > > =20 > > =20 > > Right, that is not how it will work in practice. Wo= rking with a real > > =20 > > =20 > > =20 > > HTTP server that HTTP header will be more complex, and = on the CoAP side > > you would chose shorter URLs. The biggest improvement p= ossible here is > > from using binary coded URLs of course. We need to look= at a wider range > > of interactions and real HTTP headers as well to check = that we are > > efficient enough. > > =20 > > =20 > > =20 > > =20 > > =20 > > Addressing all these points potentially leads t= o major technical > > modifications (especially point a) on the curre= nt draft, hence it is > > appropriate in my opinion to discuss these poin= ts before making the > > final decision. > > =20 > > =20 > > =20 > > I am not sure what else you have in mind for a). If= we just forget > > =20 > > =20 > > =20 > > about Subscribe/Notify then you are good to go. But the= n you are also > > not fulfilling the charter or the industry needs in tha= t respect. > > =20 > > =20 > > =20 > > Thanks, > > Zach > > =20 > > =20 > > =20 > > =20 > > Best regards, > > =20 > > Angelo P. Castellani > > =20 > > =20 > > On Mon, May 10, 2010 at 18:51, Carsten Bormann<= cabo@tzi.org> wrote: > > =20 > > =20 > > =20 > > The CORE WG has a milestone to select a WG = document for CoAP in > > =20 > > =20 > > =20 > > April: > > =20 > > =20 > > =20 > > http://datatracker.ietf.org/wg/core/charter= / > > ... > > Apr 2010 Select WG document for basi= s of the CoAP protocol > > =20 > > Of the various documents that have been con= tributed, > > =20 > > =20 > > =20 > > draft-shelby-core-coap has significant discussion, as w= ell as the > > largest number of updates (including a previous version= that was still > > called -6lowapp-coap). > > =20 > > =20 > > =20 > > Today, another updated version of that draf= t was announced. See > > http://www.ietf.org/mail-archive/web/core/c= urrent/msg00138.html > > for the announcement and > > http://tools.ietf.org/html/draft-shelby-cor= e-coap-01 > > for the draft itself. > > =20 > > However, as the authors say, there are stil= l significant TODOs. > > =20 > > Are we in a state yet where we can say whet= her this is the right > > =20 > > =20 > > =20 > > direction for the WG to take? > > =20 > > =20 > > =20 > > If yes, is it the right direction? Should = we adopt it as a WG > > =20 > > =20 > > =20 > > document? > > =20 > > =20 > > =20 > > If you don't think we can say yet, is there= a set of technical > > =20 > > =20 > > =20 > > decisions you would like the authors to take with prior= ity? > > =20 > > =20 > > =20 > > Note that once a document has become a WG d= ocument, the authors act > > =20 > > =20 > > =20 > > as editors for the working group, making (and usually f= leshing out the > > details of) any change that the WG decides it needs. > > =20 > > =20 > > =20 > > If you think we can still improve the draft= , this is not an obstacle > > =20 > > =20 > > =20 > > to making it a WG document. > > =20 > > =20 > > =20 > > But of course we shouldn't do that if we in= tend to reverse its > > =20 > > =20 > > =20 > > fundamental technical direction. > > =20 > > =20 > > =20 > > In order to stay roughly in sync with our m= ilestones, we should > > =20 > > =20 > > =20 > > reach at a decision on how to go forward this week. > > =20 > > =20 > > =20 > > Gruesse, Carsten > > =20 > > ___________________________________________= ____ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > =20 > > =20 > > =20 > > =20 > > _______________________________________________= > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > =20 > > =20 > > =20 > > -- > > Zach Shelby, Chief Nerd, Sensinode Ltd. > > http://zachshelby.org - My blog "On the Internet = of Things" > > http://6lowpan.net - My book " 6LoWPAN: The Wireless Embedded Internet" > > Mobile: +358 40 7796297 > > =20 > > =20 > > =20 > > =20 > > =20 > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > =20 > > -------------------------------- > > Onzo is a limited company number 06097997 registered in= England& Wales. The > > registered office is 6 Great Newport Street, London, WC= 2H 7JB, United Kingdom. > > =20 > > This email message may contain confidential and/or priv= ileged information, and > > is intended solely for the addressee(s). If you have re= ceived this email in > > error, please notify Onzo immediately. Unauthorised cop= ying, disclosure or > > distribution of the material in this email is forbidden= =2E > > -------------------------------- > > =20 > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > =20 > > _______________________________________________________= _______________ > > This email has been scanned by the MessageLabs Email Se= curity System. > > _______________________________________________________= _______________ > > =20 > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > =20 > > =20 > > =20 > > =20 > > =20 > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > =20 > > -------------------------------- > > Onzo is a limited company number 06097997 registered in England= & Wales. The > > registered office is 6 Great Newport Street, London, WC2H 7JB, = United Kingdom. > > =20 > > This email message may contain confidential and/or privileged i= nformation, and > > is intended solely for the addressee(s). If you have received t= his email in > > error, please notify Onzo immediately. Unauthorised copying, di= sclosure or > > distribution of the material in this email is forbidden. > > -------------------------------- > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > =20 > =20 --------------070107090206070909090407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think the point here is that there are two levels we are considering.
At the lowest (foundation) level, there are the transaction messages as described below. This provides a flexible mechanism for the application with regard to synchronicity and threading. This is important for the types of devices CoAP is being aimed at.

Above that, the methods can be used according to the architectural style. So in this case, it is RESTful (COnstrained Restful Environments), which will naturally limit the number of methods and how transactions occur.

The actual architecture using a combination of the methods and messages also depends on what is required at the application layer. Consider a typical client which wants to subscribe to a resource. That client controls the feed of data but needs a component which is capable of handling (possibly buffering) the data it receives through notifications. Is this a separate server? Or would we want to consider it part of an enhanced client model which is able to process feeds of data? These are the sort of models which have led to the myriad of solutions (GENA, Webhooks, long polling, pubsubhubbub, RESTMS etc.) based around HTTP which are all essentially ingenious ways of getting around the limitations imposed by HTTP and how it is processed for anything which deviates from the classic web page access model.

I think the aim of CoAP should be clean from the word go with regard to supporting these more peer-to-peer transactions, where the client can exist on either entity and both entities can feed data to each other; typical in M2M applications.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com


On 27/05/2010 7:08 PM, Adriano Pezzuto (apezzuto) wrote:

Hi Robert,

 

in my personal opinion, the option 1a) brings some sort of ambiguity to CoAP specs.

 

My be my understatement of new CoAP specs is not so deep,  but now we have 5 methods and 3 message types: request, response and notify. Which methods are allowed with which messages types?

I suppose you have to use PUT/POST method with notify message for asynch data notification. How to make a subscribe? I suppose you would use a SUBSCRIBE method with request/response message or SUBSCRIBE with notify message? Also what about POST/DELETE methods in a notify message? They not make any sense..

 

I think the choice is between: option 1) -> only CRUD methods and option 1b) -> CRUD + SUB/NOTIFY methods, keeping in mind cost/benefits of both solutions.

 

Adriano

 

From: Robert Cragie [mailto:robert.cragie@gridmerge.com]
Sent: mercoledì 26 maggio 2010 20.09
To: Adriano Pezzuto (apezzuto)
Cc: Paul Duffy (paduffy); Zach Shelby; core
Subject: Re: [core] Subscribe/Notify for CoAP<= /p>

 

Hi Adrian,

I would also prefer to keep the protocol in CoAP asynchronous. You can always map an asynchronous protocol to a synchronous one but, as we see in HTTP, it always ends up as a kludge to do it the other way round. The efforts which have been gone to to make HTTP quasi-asynchronous via all the schemes mentioned below and many more besides (all non-interoperable of course) is testament to how important this is for M2M communication.

So, back to Zach's list, I favor 1a) for the following reasons:

Foundation level of messages:

  1. request/response can be asynchrono= us or synchronous messages (as there is a transaction ID in there)
  2. notify is an asynchronous message<= o:p>

Derived methods:

I think it makes sense to add a pub/sub model as a useful mechanism for M2M.

So, looking at it the other way round: It will be entirely possible to translate whatever is currently built on HTTP to CoAP based on the above, with all its restrictions regarding synchronous and client/server transactions. What may be harder is to translate directly is a CoAP-based application to HTTP. So I guess the question is: Do we want to be hamstrung to synchronous client/server transactions as dictated by HTTP and provide a direct mapping to HTTP, then have to come up with similar kludges for asynchronous peer-to-peer transactions as has been done in numerous ways for HTTP, or do we want to define the protocol cleanly to start with and accept that some sort of transaction relaying/conversion would have to take place at a mapping node?

Robert

Robert Cragie (Pacific Gas & Electric)=

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://w= ww.gridmerge.com


On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote: 

Hi,
it looks to me that CoAP should use an explicit sub/notify mechani=
sm since this is the core of the machine-to-machine interaction model.
HTTP suffers of this lack and we have seen a plethora of solutions=
 to give an asynch taste to it. Webhooks and websockets are only the last=
s of the list.
As someone has already pointed out on this list, it is theoretical=
ly possible to describe sub/notify using only CRUD methods but it looks a=
 little bit tricky and verbose.
 
Now we have a chance to build from scratch a new protocol with and=
 I think using explicit sub/notify methods with a clear and well defined =
semantic is the best option. It is easily understanding from every develo=
per and will prevent to build other fanny solutions on top of the CoAP. H=
TTP does not have this well defined semantic and (for hundreds of other r=
easons also) it is not used as wide protocol for machine-to-machine commu=
nication.
 
CoAP - as binary protocol - and with an explicit asynch model has =
a chance to be a really wide protocol for M2M communication not only for =
constrained environments.
 
my 2 cents
 
- adriano
 
-----Original Message-----
From: core-bounces@ietf.org [mailto:co=
re-bounces@ietf.org] On Behalf Of Paul Duffy (paduffy)
  
Sent: mercoledì 26 maggio 2010 0.47

  
To: Zach Shelby

  
Cc: core

  
Subject: Re: [core] Subscribe/Notify for CoAP

  
 

  
On 5/25/2010 6:41 PM, Zach Shelby wrote:

  
  

  

    
Hi,

    
 

    
On May 26, 2010, at 12:23 AM, Charles Palmer wrote:
    
 

    
   

    
    

    

      
Hi folks

      
 

      
It occurs to me that CoRE should be keeping a close eye on Zig=
Bee SE2.0 work, so that it is as easy as possible for ZigBee SE to use Co=
RE when ready. That suggests to me that we should align with their subscr=
ibe/notify process.

      
 

      
     

      
      

    

    
I am not sure I understand that. I mean, ZigBee SE2.0 is definin=
g an application specific subscribe/notify mechanism for that purpose so =
far for HTTP. This uses standard HTTP methods and some custom payload and=
 REST interfaces. CoAP Req/Res is already totally compatible with SE2.0 i=
n that respect, so alignment is already OK there. Nothing stopping someon=
e from using SE2.0 over CoAP.

    
 

    
Specifying a native susbcription/notify into CoAP is another mat=
ter. We can't adopt a solution specific to one application as that won't =
solve the problems of other applications nor general HTTP mapping at all =
(probably would make it worse). It seems that for the near future there w=
ill be a bunch of HTTP push mechanisms in use without any clear standard =
appearing - or am I wrong there?

    
   

    
    

  

  
 

  
 

  
 

  
If COAP extends HTTP semantics with new subscription methods, it w=
ill 

  
not be possible to easily interchange HTTP/COAP, and translation <=
o:p>

  
gateways will become more complex to implement.

  
 

  
 

  
 

  
  

  

    
Zach

    
 

    
   

    
    

    

      
Regards - Charles

      
 

      
 

      
-----Original Message-----

      
From: core-bounces@ietf.org [mailto:co=
re-bounces@ietf.org] On Behalf Of Paul Duffy

      
Sent: 25 May 2010 03:48

      
To: Zach Shelby

      
Cc: core

      
Subject: Re: [core] Subscribe/Notify for CoAP
=

      
 

      
Recommend something like #2, primarily to avoid introducing no=
n HTTP

      
method semantics, simplifying HTTP/COAP translation.gateways, =
etc.

      
 

      
 

      
On 5/24/2010 11:49 AM, Zach Shelby wrote:

      
     

      
      

      

        
(thread renamed)

        
 

        
We have two different paths with regard to a subscribe/notif=
y mechanism for CoAP:

        
 

        
1. Use specific Subscription and Notify mechanisms for CoAP =
as HTTP really does not include this concept.

        
1a) Notify as a message and SUBSCRIBE as a method. This is c=
urrently used in coap-01.

        
1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-0=
0, but we had a good list discussion about this leading to a. In practice=
 it doesn't make a big difference if notification is a message or method.=


        
 

        
2. Use an HTTP specific framework such as Webhooks, the ZigB=
ee SE2.0 proposal or GENA.

        
 

        
So far we have focused on 1 in the WG, and every now and aga=
in 2 comes up. At least I am not convinced that we need to suffer the dra=
wbacks of HTTP here. Anyways 2 does not help our mapping to HTTP in reali=
ty very much as there is no standard way of doing this over HTTP. Thus a =
CoAP-HTTP proxy may end up anyways translating between multiple HTTP fram=
eworks depending on the application. So instead of doing a CoAP Notify/Su=
bscribe to Webhooks mapping, you will could end up having to do a CoAP We=
bhooks to HTTP GENA mapping.

        
 

        
       

        
        <=
/pre>
      

      
 

      
I don't understand this last para.  If CoAP sticks to the=
 semantics of

      
the current HTTP methods, would this not offer a fairly straig=
htforward

      
translation to/from HTTP?

      
 

      
 

      
     

      
      

      

        

          
 From what I have heard so far 1 still seems like a w=
ise choice, although I need to look at Webhooks more deeply. In reality m=
any applications specify their own way of doing a push interface using RE=
ST methods and specific payloads (ZigBee SE2.0 is such an example). That =
is just fine, and might be used instead of a specific CoAP notify/subscri=
be in that case. So 1 doesn't prevent the application using its own mecha=
nism, it just provides a native way for doing push.

          
         

          
         &nbs=
p;

        

        
What do people think?

        
 

        
Zach

        
 

        
On May 17, 2010, at 6:44 PM, matthieu.via=
l@fr.non.schneider-electric.com wrote:

        
 

        
 

        
       

        
        <=
/pre>
        

          
Hi,

          
 

          
My comments about the subscribe/notify mechanism of Zigbee=
 IP.

          
 

          
Pros:

          
- Derived from the webhooks concept

          
- If used by CORE it will be easier to map to HTTP because=
 it uses only CRUD verbs.

          
- The subscription message is extendable and could support=
 advanced options (delays, increment, ...)

          
- Only one listening port whatever the transport binding i=
s.

          
 

          
Cons:

          
- No interoperability without well known URIs and a well d=
efined subscription message format (Not sure CoAP draft is the right plac=
e to specify this).

          
- XML/EXI is too complex to be the required format for the=
 default subscription/notification mechanism.

          
- The notification should not require a subsequent GET to =
retrieve the content.

          
- Subresource subscription is redundant.

          
 

          
Hope this could help,

          
Matthieu

          
 

          
 

          
<graycol.gif>"Charles Palmer"<cha=
rles.palmer@onzo.com>

          
 

          
 

          
 

          
 

          
"Charles Palmer"<charles.palmer@onzo.com><=
/a>

          
Envoyé par : core-bounces@ietf.org

          
15/05/2010 14:06

          
 

          
<ecblank.gif>

          
A

          
<ecblank.gif>

          
"core"<core@ietf.org>
=

          
<ecblank.gif>

          
cc

          
<ecblank.gif>

          
<ecblank.gif>

          
Objet

          
<ecblank.gif>

          
Re: [core] Selecting a WG document for CoAP
          
<ecblank.gif> <ecblank.gif>

          
 

          
Dear all

          
 

          
Those interested in the subscribe/notify discussion might =
like to look

          
at the draft Smart Energy Profile 2.0 Application Protocol=


          
Specification. It is available here:

          
http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20=
PublicApp

          
licationProfile.aspx

          
 

          
It manages subscribe/notify by using POST. This seems to r=
emove the need

          
for SUBSCRIBE and notify.

          
 

          
"Imagine a host A, which exposes a resource at http{s}://A=
/resource and

          
a second host B, which wishes to learn of changes to this =
resource. To

          
facilitate a subscription/ notification mechanism, A would=
 expose a

          
resource http{s}://A/sub and B would expose a resource htt=
p{s}://B/ntfy.

          
To subscribe to notifications regarding http{s}://A/resour=
ce, B would

          
send a POST to the address http{s}://A/sub/B containing th=
e URI of the

          
resource of interest (http{s}://A/resource) and the URI of=
 B's

          
notification resource (http{s}://B/ntfy). Following this s=
ubscription

          
step, should A wish to notify B of a change to the resourc=
e addressed at

          
http{s}://A/resource, A would send a POST to the address

          
http{s}://B/ntfy containing the URI of the resource change=
d

          
(http{s}://A/resource) and the URI of A's subscription res=
ource

          
(http{s}://A/sub/B), should A wish to change its subscript=
ion. The host

          
B can then query the resource (or not) at its leisure."

          
 

          
Sleepy nodes are not allowed to subscribe, and must poll.<=
o:p>

          
 

          
Regards - Charles Palmer

          
 

          
-----Original Message-----

          
From: core-bounces@ietf.org [mailto:co=
re-bounces@ietf.org] On Behalf Of

          
Angelo P. Castellani

          
Sent: 14 May 2010 13:14

          
To: Zach Shelby

          
Cc: core

          
Subject: Re: [core] Selecting a WG document for CoAP<=
/o:p>

          
 

          
Zach,

          
 

          
thanks for the comments, but please refer to my most recen=
t e-mail for

          
a more specific list of technical issues I'm pointing to.<=
o:p>

          
 

          
I want to do only a little integration to what I've writte=
n there.

          
 

          
In my very personal opinion, to maximize adherence with th=
e REST model

          
and minimize implementation effort SUBSCRIBE and NOTIFY sh=
ould be

          
mapped to methods (as discussed many times together...).

          
 

          
Uniform interface principle (Fielding PhD dissertation Sec=
tion 5.1.5,

          
"The central feature that distinguishes the REST architect=
ural style

          
[...]") states that to simplify the software architecture,=
 resource

          
interfaces/interfaces should be as general as possible.

          
 

          
I agree with this principle in this specific case, mainly =
because

          
handling a special message type for notify leads node soft=
ware design

          
to a more complex architecture.

          
 

          
The reason is that this new message type requires special =
handling and

          
introduces a complexity in the software modularization.

          
 

          
Best,

          
Angelo

          
 

          
On Fri, May 14, 2010 at 13:06, Zach Shelby<zach@sen=
sinode.com>   wrote:

          
 

          
         

          
         &nbs=
p;

          

            
Hi Angelo,

            
 

            
On May 13, 2010, at 14:24 , Angelo P. Castellani wrote:<=
o:p>

            
 

            
 

            
         &n=
bsp; 

            
         &n=
bsp;  

            

              
Dear C. Bormann, all,

              
 

              
before deciding for the final direction, I've the foll=
owing

              
observations about draft-shelby-core-coap-01

              
 

              
While I mostly share Zach's view of the protocol appro=
ach, and

              
appreciate many aspects of the proposal, there are in =
my opinion

              
 

              
         =
    

              
         =
     

            

          

          
still

          
 

          
         

          
         &nbs=
p;

          

            

              
some open issues that need to be at least discussed be=
fore the

              
 

              
         =
    

              
         =
     

            

          

          
current

          
 

          
         

          
         &nbs=
p;

          

            

              
document can be selected.

              
 

              
         =
    

              
         =
     

            

            
Of course there are plenty of open issues. Remember that=
 working group

            
 

            
         &n=
bsp; 

            
         &n=
bsp;  

          

          
documents still undertake as much change and improvement a=
s the WG

          
wants, so by no means is coap-01 set in stone. I would exp=
ect at least

          
5-10 more revisions still along the way.  Already sev=
eral of your ideas

          
have been integrated into coap-01, and several more are un=
der

          
consideration, so it is coming along. Patience ;-)

          
 

          
         

          
         &nbs=
p;

          

            
         &n=
bsp; 

            
         &n=
bsp;  

            

              
In particular, I would like to highlight the following=
:

              
 

              
a) As it is now, it is not possible to have a straight=
forward

              
translation of HTTP ->   CoAP and vicever=
sa: see

              
http://www.ietf.org/mail-archive/web/core/current/msg00133.html (thi=
s

              
impacts the scalability of the web service model too)<=
o:p>

              
 

              
         =
    

              
         =
     

            

            
In coap-01 the Method names are now identical to HTTP me=
thods. The

            
 

            
         &n=
bsp; 

            
         &n=
bsp;  

          

          
Req/Res interaction is a direct translation. The URI hiera=
rchy is

          
compatible, and the URI binary code format we are still wo=
rking on

          
obviously. The only thing that takes some state to transla=
te is

          
Subscribe/Notify. But note, Subscribe/Notify takes some st=
ate no matter

          
how you do it, even with HTTP-HTTP there is no clean and e=
asy way to

          
handle subscriptions.

          
 

          
         

          
         &nbs=
p;

          

            
         &n=
bsp; 

            
         &n=
bsp;  

            

              
b) Moreover, CoAP's implementation is not as simple as=
 it should be.

              
I've investigated the implementation and some design c=
hoices (as

              
Options) are leading to very high program complexity (=
ROM) on a

              
MSP430-based device.

              
 

              
         =
    

              
         =
     

            

            
This we can definitely improve, and already made several=
 optimizations

            
 

            
         &n=
bsp; 

            
         &n=
bsp;  

          

          
from -00 to -01. Here I need some very concrete proposals =
though. Also

          
remember that many things are optional, for example subscr=
ibe/notify is

          
not required if you don't need it.

          
 

          
         

          
         &nbs=
p;

          

            
         &n=
bsp; 

            
         &n=
bsp;  

            

              
c) Finally when comparing HTTP message size with CoAP =
message size,

              
the resulting compression isn't as good as you may exp=
ect.

              
 

              
Example:

              
HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B

              
CoAP: 24 B with options parsing procedure requiring an=
 added

              
implementation complexity

              
 

              
         =
    

              
         =
     

            

            
Right, that is not how it will work in practice. Working=
 with a real

            
 

            
         &n=
bsp; 

            
         &n=
bsp;  

          

          
HTTP server that HTTP header will be more complex, and on =
the CoAP side

          
you would chose shorter URLs. The biggest improvement poss=
ible here is

          
from using binary coded URLs of course. We need to look at=
 a wider range

          
of interactions and real HTTP headers as well to check tha=
t we are

          
efficient enough.

          
 

          
         

          
         &nbs=
p;

          

            
         &n=
bsp; 

            
         &n=
bsp;  

            

              
Addressing all these points potentially leads to major=
 technical

              
modifications (especially point a) on the current draf=
t, hence it is

              
appropriate in my opinion to discuss these points befo=
re making the

              
final decision.

              
 

              
         =
    

              
         =
     

            

            
I am not sure what else you have in mind for a). If we j=
ust forget

            
 

            
         &n=
bsp; 

            
         &n=
bsp;  

          

          
about Subscribe/Notify then you are good to go. But then y=
ou are also

          
not fulfilling the charter or the industry needs in that r=
espect.

          
 

          
         

          
         &nbs=
p;

          

            
Thanks,

            
Zach

            
 

            
 

            
         &n=
bsp; 

            
         &n=
bsp;  

            

              
Best regards,

              
 

              
Angelo P. Castellani

              
 

              
 

              
On Mon, May 10, 2010 at 18:51, Carsten Bormann<cabo@tzi.org&g=
t;   wrote:

              
 

              
         =
    

              
         =
     

              
=

                
The CORE WG has a milestone to select a WG document =
for CoAP in

                
 

                
        &nbs=
p;      

                
        &nbs=
p;       

              

            

          

          
April:

          
 

          
         

          
         &nbs=
p;

          

            

              
=

                
http://datatracker=
=2Eietf.org/wg/core/charter/

                
...

                
Apr 2010        S=
elect WG document for basis of the CoAP protocol

                
 

                
Of the various documents that have been contributed,=


                
 

                
        &nbs=
p;      

                
        &nbs=
p;       

              

            

          

          
draft-shelby-core-coap has significant discussion, as well=
 as the

          
largest number of updates (including a previous version th=
at was still

          
called -6lowapp-coap).

          
 

          
         

          
         &nbs=
p;

          

            

              
=

                
Today, another updated version of that draft was ann=
ounced.  See

                
http://www.ietf.org/mail-archive/web/core/current/msg00138.html=


                
for the announcement and

                
http://too=
ls.ietf.org/html/draft-shelby-core-coap-01

                
for the draft itself.

                
 

                
However, as the authors say, there are still signifi=
cant TODOs.

                
 

                
Are we in a state yet where we can say whether this =
is the right

                
 

                
        &nbs=
p;      

                
        &nbs=
p;       

              

            

          

          
direction for the WG to take?

          
 

          
         

          
         &nbs=
p;

          

            

              
=

                
If yes, is it the right direction?  Should we a=
dopt it as a WG

                
 

                
        &nbs=
p;      

                
        &nbs=
p;       

              

            

          

          
document?

          
 

          
         

          
         &nbs=
p;

          

            

              
=

                
If you don't think we can say yet, is there a set of=
 technical

                
 

                
        &nbs=
p;      

                
        &nbs=
p;       

              

            

          

          
decisions you would like the authors to take with priority=
?

          
 

          
         

          
         &nbs=
p;

          

            

              
=

                
Note that once a document has become a WG document, =
the authors act

                
 

                
        &nbs=
p;      

                
        &nbs=
p;       

              

            

          

          
as editors for the working group, making (and usually fles=
hing out the

          
details of) any change that the WG decides it needs.<=
/o:p>

          
 

          
         

          
         &nbs=
p;

          

            

              
=

                
If you think we can still improve the draft, this is=
 not an obstacle

                
 

                
        &nbs=
p;      

                
        &nbs=
p;       

              

            

          

          
to making it a WG document.

          
 

          
         

          
         &nbs=
p;

          

            

              
=

                
But of course we shouldn't do that if we intend to r=
everse its

                
 

                
        &nbs=
p;      

                
        &nbs=
p;       

              

            

          

          
fundamental technical direction.

          
 

          
         

          
         &nbs=
p;

          

            

              
=

                
In order to stay roughly in sync with our milestones=
, we should

                
 

                
        &nbs=
p;      

                
        &nbs=
p;       

              

            

          

          
reach at a decision on how to go forward this week.

          
 

          
         

          
         &nbs=
p;

          

            

              
=

                
Gruesse, Carsten

                
 

                
_______________________________________________=


                
core mailing list

                
core@ietf.org

                
https://www.ietf.org=
/mailman/listinfo/core

                
 

                
 

                
        &nbs=
p;      

                
        &nbs=
p;       

              

              
_______________________________________________

              
core mailing list

              
core@ietf.org

              
https://www.ietf.org=
/mailman/listinfo/core

              
 

              
         =
    

              
         =
     

            

            
--

            
Zach Shelby, Chief Nerd, Sensinode Ltd.
=

            
http://zachshelby.org  - My blog "On the Internet of Things"=


            
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"

            
Mobile: +358 40 7796297

            
 

            
 

            
 

            
         &n=
bsp; 

            
         &n=
bsp;  

          

          
_______________________________________________=


          
core mailing list

          
=
core@ietf.org

          
https://www.ietf.org=
/mailman/listinfo/core

          
 

          
--------------------------------

          
Onzo is a limited company number 06097997 registered in En=
gland&   Wales. The

          
registered office is 6 Great Newport Street, London, WC2H =
7JB, United Kingdom.

          
 

          
This email message may contain confidential and/or privile=
ged information, and

          
is intended solely for the addressee(s). If you have recei=
ved this email in

          
error, please notify Onzo immediately. Unauthorised copyin=
g, disclosure or

          
distribution of the material in this email is forbidden.

          
--------------------------------

          
 

          
_______________________________________________=


          
core mailing list

          
=
core@ietf.org

          
https://www.ietf.org=
/mailman/listinfo/core

          
 

          
__________________________________________________________=
____________

          
This email has been scanned by the MessageLabs Email Secur=
ity System.

          
__________________________________________________________=
____________

          
 

          
_______________________________________________=


          
core mailing list

          
=
core@ietf.org

          
https://www.ietf.org=
/mailman/listinfo/core

          
 

          
         

          
         &nbs=
p;

        

        
       

        
        <=
/pre>
      

      
_______________________________________________
      
core mailing list

      
core=
@ietf.org

      
https://www.ietf.org=
/mailman/listinfo/core

      
 

      
--------------------------------

      
Onzo is a limited company number 06097997 registered in Englan=
d&  Wales. The

      
registered office is 6 Great Newport Street, London, WC2H 7JB,=
 United Kingdom.

      
 

      
This email message may contain confidential and/or privileged =
information, and

      
is intended solely for the addressee(s). If you have received =
this email in

      
error, please notify Onzo immediately. Unauthorised copying, d=
isclosure or

      
distribution of the material in this email is forbidden.<=
/o:p>

      
--------------------------------

      
 

      
     

      
      

    

    
   

    
    

  

  
 

  
_______________________________________________

  
core mailing list

  
core@iet=
f.org

  
https://www.ietf.org=
/mailman/listinfo/core

  
_______________________________________________

  
core mailing list

  
core@iet=
f.org

  
https://www.ietf.org=
/mailman/listinfo/core

  
 

  
 
--------------070107090206070909090407-- --------------ms050308070407020607000203 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA1 MjgwOTUzMDNaMCMGCSqGSIb3DQEJBDEWBBSAQpTQUfi9uZ0yJpflfr8c2hhjHzBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBABZjCLew3mo5SDn63kPSZAIXqiH4drBcAjK0WCVhZT45H3La19kUV7fMfCwZ8jXe+tcj lbbqIdDGQBZkRR1hIwdQpef4egD9WmgWVpBBZoezGHhquBjT2WI+w4Rv+mZLFu9LnpLRwf1g txlhyGvwTnsNlNtE8SSF552vs4Ov+kgCHcyBbEESMc9Ez1pKzcD4TxqUGata4adqJ7xEXuN2 SgfU9yT2F2z4veWrjnFxrl1xAS/7T0xZIrJPz4LqQcjZgcfW0KDg4y+Q6xX4ZVd/04k63+7R vsyFWU4OrfGzlc7yv7ad2Au+x3CTlCKWThNjg29bBknmIop7DiqebsbhkZsAAAAAAAA= --------------ms050308070407020607000203-- From apezzuto@cisco.com Fri May 28 03:51:10 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A8533A67FF for ; Fri, 28 May 2010 03:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=3.350, BAYES_50=0.001, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+wXL8PzIrS1 for ; Fri, 28 May 2010 03:51:04 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0263D3A67E5 for ; Fri, 28 May 2010 03:51:04 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIFAGs9/0urR7Hu/2dsb2JhbACBP4RNmBpxo32aLQKCc4IfBA X-IronPort-AV: E=Sophos;i="4.53,317,1272844800"; d="scan'208,217";a="536584788" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 28 May 2010 10:50:40 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o4SAodaG029249; Fri, 28 May 2010 10:50:39 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 May 2010 12:50:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAFE53.915C6D66" Date: Fri, 28 May 2010 12:50:20 +0200 Message-ID: <0D212BD466921646B58854FB79092CEC021F4E91@XMB-AMS-106.cisco.com> In-Reply-To: <4BFF927F.1090208@gridmerge.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Subscribe/Notify for CoAP Thread-Index: Acr+S5xOmLTNS4vzSsOAs3nxsuLG8QABNXgA References: <3602E0C6-1E2E-4164-A208-A874128325AF@sensinode.com><4BFB3A66.5080700@cisco.com><324781C3-5548-474D-8995-EC327ED08209@sensinode.com> <4BFC5368.2010602@cisco.com> <0D212BD466921646B58854FB79092CEC0216121C@XMB-AMS-106.cisco.com> <4BFD63D3.3040207@gridmerge.com> <0D212BD466921646B58854FB79092CEC021F4C22@XMB-AMS-106.cisco.com> <4BFF927F.1090208@gridmerge.com> From: "Adriano Pezzuto (apezzuto)" To: X-OriginalArrivalTime: 28 May 2010 10:50:21.0334 (UTC) FILETIME=[91AE4B60:01CAFE53] Cc: core Subject: Re: [core] Subscribe/Notify for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 10:51:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAFE53.915C6D66 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Roberto, I understand your point and personally agree on M2M is quite different = from web page model. On the architectural RESTful style, the method = information tells the server what to do with data kept in the URI = information. =20 So strictly speaking, both NOTIFY and SUBSCRIBE are message types not = methods! =20 Adriano=20 =20 From: Robert Cragie [mailto:robert.cragie@gridmerge.com]=20 Sent: venerd=EC 28 maggio 2010 11.53 To: Adriano Pezzuto (apezzuto) Cc: Paul Duffy (paduffy); Zach Shelby; core Subject: Re: [core] Subscribe/Notify for CoAP =20 I think the point here is that there are two levels we are considering. At the lowest (foundation) level, there are the transaction messages as = described below. This provides a flexible mechanism for the application = with regard to synchronicity and threading. This is important for the = types of devices CoAP is being aimed at. Above that, the methods can be used according to the architectural = style. So in this case, it is RESTful (COnstrained Restful = Environments), which will naturally limit the number of methods and how = transactions occur. The actual architecture using a combination of the methods and messages = also depends on what is required at the application layer. Consider a = typical client which wants to subscribe to a resource. That client = controls the feed of data but needs a component which is capable of = handling (possibly buffering) the data it receives through = notifications. Is this a separate server? Or would we want to consider = it part of an enhanced client model which is able to process feeds of = data? These are the sort of models which have led to the myriad of = solutions (GENA, Webhooks, long polling, pubsubhubbub, RESTMS etc.) = based around HTTP which are all essentially ingenious ways of getting = around the limitations imposed by HTTP and how it is processed for = anything which deviates from the classic web page access model. I think the aim of CoAP should be clean from the word go with regard to = supporting these more peer-to-peer transactions, where the client can = exist on either entity and both entities can feed data to each other; = typical in M2M applications. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com =20 On 27/05/2010 7:08 PM, Adriano Pezzuto (apezzuto) wrote:=20 Hi Robert, =20 in my personal opinion, the option 1a) brings some sort of ambiguity to = CoAP specs. =20 My be my understatement of new CoAP specs is not so deep, but now we = have 5 methods and 3 message types: request, response and notify. Which = methods are allowed with which messages types? I suppose you have to use PUT/POST method with notify message for asynch = data notification. How to make a subscribe? I suppose you would use a = SUBSCRIBE method with request/response message or SUBSCRIBE with notify = message? Also what about POST/DELETE methods in a notify message? They = not make any sense.. =20 I think the choice is between: option 1) -> only CRUD methods and option = 1b) -> CRUD + SUB/NOTIFY methods, keeping in mind cost/benefits of both = solutions. =20 Adriano =20 From: Robert Cragie [mailto:robert.cragie@gridmerge.com]=20 Sent: mercoled=EC 26 maggio 2010 20.09 To: Adriano Pezzuto (apezzuto) Cc: Paul Duffy (paduffy); Zach Shelby; core Subject: Re: [core] Subscribe/Notify for CoAP =20 Hi Adrian, I would also prefer to keep the protocol in CoAP asynchronous. You can = always map an asynchronous protocol to a synchronous one but, as we see = in HTTP, it always ends up as a kludge to do it the other way round. The = efforts which have been gone to to make HTTP quasi-asynchronous via all = the schemes mentioned below and many more besides (all non-interoperable = of course) is testament to how important this is for M2M communication. So, back to Zach's list, I favor 1a) for the following reasons: Foundation level of messages: 1. request/response can be asynchronous or synchronous messages (as = there is a transaction ID in there) 2. notify is an asynchronous message Derived methods: I think it makes sense to add a pub/sub model as a useful mechanism for = M2M. So, looking at it the other way round: It will be entirely possible to = translate whatever is currently built on HTTP to CoAP based on the = above, with all its restrictions regarding synchronous and client/server = transactions. What may be harder is to translate directly is a = CoAP-based application to HTTP. So I guess the question is: Do we want = to be hamstrung to synchronous client/server transactions as dictated by = HTTP and provide a direct mapping to HTTP, then have to come up with = similar kludges for asynchronous peer-to-peer transactions as has been = done in numerous ways for HTTP, or do we want to define the protocol = cleanly to start with and accept that some sort of transaction = relaying/conversion would have to take place at a mapping node? Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com =20 On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote:=20 Hi, it looks to me that CoAP should use an explicit sub/notify mechanism = since this is the core of the machine-to-machine interaction model. HTTP suffers of this lack and we have seen a plethora of solutions to = give an asynch taste to it. Webhooks and websockets are only the lasts = of the list. As someone has already pointed out on this list, it is theoretically = possible to describe sub/notify using only CRUD methods but it looks a = little bit tricky and verbose. =20 Now we have a chance to build from scratch a new protocol with and I = think using explicit sub/notify methods with a clear and well defined = semantic is the best option. It is easily understanding from every = developer and will prevent to build other fanny solutions on top of the = CoAP. HTTP does not have this well defined semantic and (for hundreds of = other reasons also) it is not used as wide protocol for = machine-to-machine communication. =20 CoAP - as binary protocol - and with an explicit asynch model has a = chance to be a really wide protocol for M2M communication not only for = constrained environments. =20 my 2 cents =20 - adriano =20 -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Paul Duffy (paduffy) Sent: mercoled=EC 26 maggio 2010 0.47 To: Zach Shelby Cc: core Subject: Re: [core] Subscribe/Notify for CoAP =20 On 5/25/2010 6:41 PM, Zach Shelby wrote: =20 Hi, =20 On May 26, 2010, at 12:23 AM, Charles Palmer wrote: =20 =20 =20 Hi folks =20 It occurs to me that CoRE should be keeping a close eye on ZigBee = SE2.0 work, so that it is as easy as possible for ZigBee SE to use CoRE = when ready. That suggests to me that we should align with their = subscribe/notify process. =20 =20 =20 I am not sure I understand that. I mean, ZigBee SE2.0 is defining an = application specific subscribe/notify mechanism for that purpose so far = for HTTP. This uses standard HTTP methods and some custom payload and = REST interfaces. CoAP Req/Res is already totally compatible with SE2.0 = in that respect, so alignment is already OK there. Nothing stopping = someone from using SE2.0 over CoAP. =20 Specifying a native susbcription/notify into CoAP is another matter. We = can't adopt a solution specific to one application as that won't solve = the problems of other applications nor general HTTP mapping at all = (probably would make it worse). It seems that for the near future there = will be a bunch of HTTP push mechanisms in use without any clear = standard appearing - or am I wrong there? =20 =20 =20 =20 =20 If COAP extends HTTP semantics with new subscription methods, it will=20 not be possible to easily interchange HTTP/COAP, and translation=20 gateways will become more complex to implement. =20 =20 =20 =20 Zach =20 =20 =20 Regards - Charles =20 =20 -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Paul Duffy Sent: 25 May 2010 03:48 To: Zach Shelby Cc: core Subject: Re: [core] Subscribe/Notify for CoAP =20 Recommend something like #2, primarily to avoid introducing non HTTP method semantics, simplifying HTTP/COAP translation.gateways, etc. =20 =20 On 5/24/2010 11:49 AM, Zach Shelby wrote: =20 =20 (thread renamed) =20 We have two different paths with regard to a subscribe/notify = mechanism for CoAP: =20 1. Use specific Subscription and Notify mechanisms for CoAP as HTTP = really does not include this concept. 1a) Notify as a message and SUBSCRIBE as a method. This is currently = used in coap-01. 1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but we = had a good list discussion about this leading to a. In practice it = doesn't make a big difference if notification is a message or method. =20 2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2.0 = proposal or GENA. =20 So far we have focused on 1 in the WG, and every now and again 2 = comes up. At least I am not convinced that we need to suffer the = drawbacks of HTTP here. Anyways 2 does not help our mapping to HTTP in = reality very much as there is no standard way of doing this over HTTP. = Thus a CoAP-HTTP proxy may end up anyways translating between multiple = HTTP frameworks depending on the application. So instead of doing a CoAP = Notify/Subscribe to Webhooks mapping, you will could end up having to do = a CoAP Webhooks to HTTP GENA mapping. =20 =20 =20 =20 I don't understand this last para. If CoAP sticks to the semantics of the current HTTP methods, would this not offer a fairly = straightforward translation to/from HTTP? =20 =20 =20 =20 From what I have heard so far 1 still seems like a wise choice, = although I need to look at Webhooks more deeply. In reality many = applications specify their own way of doing a push interface using REST = methods and specific payloads (ZigBee SE2.0 is such an example). That is = just fine, and might be used instead of a specific CoAP notify/subscribe = in that case. So 1 doesn't prevent the application using its own = mechanism, it just provides a native way for doing push. =20 =20 What do people think? =20 Zach =20 On May 17, 2010, at 6:44 PM, = matthieu.vial@fr.non.schneider-electric.com wrote: =20 =20 =20 =20 Hi, =20 My comments about the subscribe/notify mechanism of Zigbee IP. =20 Pros: - Derived from the webhooks concept - If used by CORE it will be easier to map to HTTP because it uses = only CRUD verbs. - The subscription message is extendable and could support advanced = options (delays, increment, ...) - Only one listening port whatever the transport binding is. =20 Cons: - No interoperability without well known URIs and a well defined = subscription message format (Not sure CoAP draft is the right place to = specify this). - XML/EXI is too complex to be the required format for the default = subscription/notification mechanism. - The notification should not require a subsequent GET to retrieve = the content. - Subresource subscription is redundant. =20 Hope this could help, Matthieu =20 =20 "Charles Palmer" = =20 =20 =20 =20 =20 "Charles Palmer" = =20 Envoy=E9 par : core-bounces@ietf.org 15/05/2010 14:06 =20 A "core" =20 cc Objet Re: [core] Selecting a WG document for CoAP =20 Dear all =20 Those interested in the subscribe/notify discussion might like to = look at the draft Smart Energy Profile 2.0 Application Protocol Specification. It is available here: = http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicApp licationProfile.aspx =20 It manages subscribe/notify by using POST. This seems to remove the = need for SUBSCRIBE and notify. =20 "Imagine a host A, which exposes a resource at http{s}://A/resource = and a second host B, which wishes to learn of changes to this resource. = To facilitate a subscription/ notification mechanism, A would expose a resource http{s}://A/sub and B would expose a resource = http{s}://B/ntfy. To subscribe to notifications regarding http{s}://A/resource, B = would send a POST to the address http{s}://A/sub/B containing the URI of = the resource of interest (http{s}://A/resource) and the URI of B's notification resource (http{s}://B/ntfy). Following this = subscription step, should A wish to notify B of a change to the resource = addressed at http{s}://A/resource, A would send a POST to the address http{s}://B/ntfy containing the URI of the resource changed (http{s}://A/resource) and the URI of A's subscription resource (http{s}://A/sub/B), should A wish to change its subscription. The = host B can then query the resource (or not) at its leisure." =20 Sleepy nodes are not allowed to subscribe, and must poll. =20 Regards - Charles Palmer =20 -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Angelo P. Castellani Sent: 14 May 2010 13:14 To: Zach Shelby Cc: core Subject: Re: [core] Selecting a WG document for CoAP =20 Zach, =20 thanks for the comments, but please refer to my most recent e-mail = for a more specific list of technical issues I'm pointing to. =20 I want to do only a little integration to what I've written there. =20 In my very personal opinion, to maximize adherence with the REST = model and minimize implementation effort SUBSCRIBE and NOTIFY should be mapped to methods (as discussed many times together...). =20 Uniform interface principle (Fielding PhD dissertation Section = 5.1.5, "The central feature that distinguishes the REST architectural style [...]") states that to simplify the software architecture, resource interfaces/interfaces should be as general as possible. =20 I agree with this principle in this specific case, mainly because handling a special message type for notify leads node software = design to a more complex architecture. =20 The reason is that this new message type requires special handling = and introduces a complexity in the software modularization. =20 Best, Angelo =20 On Fri, May 14, 2010 at 13:06, Zach Shelby = wrote: =20 =20 =20 Hi Angelo, =20 On May 13, 2010, at 14:24 , Angelo P. Castellani wrote: =20 =20 =20 =20 Dear C. Bormann, all, =20 before deciding for the final direction, I've the following observations about draft-shelby-core-coap-01 =20 While I mostly share Zach's view of the protocol approach, and appreciate many aspects of the proposal, there are in my opinion =20 =20 =20 still =20 =20 =20 some open issues that need to be at least discussed before the =20 =20 =20 current =20 =20 =20 document can be selected. =20 =20 =20 Of course there are plenty of open issues. Remember that working = group =20 =20 =20 documents still undertake as much change and improvement as the WG wants, so by no means is coap-01 set in stone. I would expect at = least 5-10 more revisions still along the way. Already several of your = ideas have been integrated into coap-01, and several more are under consideration, so it is coming along. Patience ;-) =20 =20 =20 =20 =20 In particular, I would like to highlight the following: =20 a) As it is now, it is not possible to have a straightforward translation of HTTP -> CoAP and viceversa: see http://www.ietf.org/mail-archive/web/core/current/msg00133.html = (this impacts the scalability of the web service model too) =20 =20 =20 In coap-01 the Method names are now identical to HTTP methods. The =20 =20 =20 Req/Res interaction is a direct translation. The URI hierarchy is compatible, and the URI binary code format we are still working on obviously. The only thing that takes some state to translate is Subscribe/Notify. But note, Subscribe/Notify takes some state no = matter how you do it, even with HTTP-HTTP there is no clean and easy way to handle subscriptions. =20 =20 =20 =20 =20 b) Moreover, CoAP's implementation is not as simple as it should = be. I've investigated the implementation and some design choices (as Options) are leading to very high program complexity (ROM) on a MSP430-based device. =20 =20 =20 This we can definitely improve, and already made several = optimizations =20 =20 =20 from -00 to -01. Here I need some very concrete proposals though. = Also remember that many things are optional, for example subscribe/notify = is not required if you don't need it. =20 =20 =20 =20 =20 c) Finally when comparing HTTP message size with CoAP message size, the resulting compression isn't as good as you may expect. =20 Example: HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B CoAP: 24 B with options parsing procedure requiring an added implementation complexity =20 =20 =20 Right, that is not how it will work in practice. Working with a = real =20 =20 =20 HTTP server that HTTP header will be more complex, and on the CoAP = side you would chose shorter URLs. The biggest improvement possible here = is from using binary coded URLs of course. We need to look at a wider = range of interactions and real HTTP headers as well to check that we are efficient enough. =20 =20 =20 =20 =20 Addressing all these points potentially leads to major technical modifications (especially point a) on the current draft, hence it = is appropriate in my opinion to discuss these points before making the final decision. =20 =20 =20 I am not sure what else you have in mind for a). If we just forget =20 =20 =20 about Subscribe/Notify then you are good to go. But then you are = also not fulfilling the charter or the industry needs in that respect. =20 =20 =20 Thanks, Zach =20 =20 =20 =20 Best regards, =20 Angelo P. Castellani =20 =20 On Mon, May 10, 2010 at 18:51, Carsten Bormann = wrote: =20 =20 =20 The CORE WG has a milestone to select a WG document for CoAP in =20 =20 =20 April: =20 =20 =20 http://datatracker.ietf.org/wg/core/charter/ ... Apr 2010 Select WG document for basis of the CoAP protocol =20 Of the various documents that have been contributed, =20 =20 =20 draft-shelby-core-coap has significant discussion, as well as the largest number of updates (including a previous version that was = still called -6lowapp-coap). =20 =20 =20 Today, another updated version of that draft was announced. See http://www.ietf.org/mail-archive/web/core/current/msg00138.html for the announcement and http://tools.ietf.org/html/draft-shelby-core-coap-01 for the draft itself. =20 However, as the authors say, there are still significant TODOs. =20 Are we in a state yet where we can say whether this is the right =20 =20 =20 direction for the WG to take? =20 =20 =20 If yes, is it the right direction? Should we adopt it as a WG =20 =20 =20 document? =20 =20 =20 If you don't think we can say yet, is there a set of technical =20 =20 =20 decisions you would like the authors to take with priority? =20 =20 =20 Note that once a document has become a WG document, the authors act =20 =20 =20 as editors for the working group, making (and usually fleshing out = the details of) any change that the WG decides it needs. =20 =20 =20 If you think we can still improve the draft, this is not an = obstacle =20 =20 =20 to making it a WG document. =20 =20 =20 But of course we shouldn't do that if we intend to reverse its =20 =20 =20 fundamental technical direction. =20 =20 =20 In order to stay roughly in sync with our milestones, we should =20 =20 =20 reach at a decision on how to go forward this week. =20 =20 =20 Gruesse, Carsten =20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =20 =20 =20 =20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =20 =20 =20 -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" = =20 http://6lowpan.net - My book " 6LoWPAN: = The Wireless Embedded Internet" Mobile: +358 40 7796297 =20 =20 =20 =20 =20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =20 -------------------------------- Onzo is a limited company number 06097997 registered in England& = Wales. The registered office is 6 Great Newport Street, London, WC2H 7JB, = United Kingdom. =20 This email message may contain confidential and/or privileged = information, and is intended solely for the addressee(s). If you have received this = email in error, please notify Onzo immediately. Unauthorised copying, = disclosure or distribution of the material in this email is forbidden. -------------------------------- =20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =20 = ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security = System. = ______________________________________________________________________ =20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =20 =20 =20 =20 =20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =20 -------------------------------- Onzo is a limited company number 06097997 registered in England& = Wales. The registered office is 6 Great Newport Street, London, WC2H 7JB, United = Kingdom. =20 This email message may contain confidential and/or privileged = information, and is intended solely for the addressee(s). If you have received this = email in error, please notify Onzo immediately. Unauthorised copying, = disclosure or distribution of the material in this email is forbidden. -------------------------------- =20 =20 =20 =20 =20 =20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =20 =20 ------_=_NextPart_001_01CAFE53.915C6D66 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Roberto,

I understand your point and personally agree on M2M is quite different = from web page model. On the architectural RESTful style, the method information = tells the server what to do with data kept in the URI = information.

 

So strictly speaking, both NOTIFY and SUBSCRIBE are message types not = =A0methods!

 

Adriano

 

From: Robert Cragie [mailto:robert.cragie@gridmerge.com]
Sent: venerd=EC 28 maggio 2010 11.53
To: Adriano Pezzuto (apezzuto)
Cc: Paul Duffy (paduffy); Zach Shelby; core
Subject: Re: [core] Subscribe/Notify for = CoAP

 

I think the point here is that there are two levels = we are considering.

At the lowest (foundation) level, there are the transaction messages as described below. This provides a flexible mechanism for the application = with regard to synchronicity and threading. This is important for the types = of devices CoAP is being aimed at.

Above that, the methods can be used according to the architectural = style. So in this case, it is RESTful (COnstrained Restful Environments), which will naturally limit the number of methods and how transactions occur.

The actual architecture using a combination of the methods and messages = also depends on what is required at the application layer. Consider a typical = client which wants to subscribe to a resource. That client controls the feed of = data but needs a component which is capable of handling (possibly buffering) = the data it receives through notifications. Is this a separate server? Or = would we want to consider it part of an enhanced client model which is able to = process feeds of data? These are the sort of models which have led to the myriad = of solutions (GENA, Webhooks, long polling, pubsubhubbub, RESTMS etc.) = based around HTTP which are all essentially ingenious ways of getting around = the limitations imposed by HTTP and how it is processed for anything which = deviates from the classic web page access model.

I think the aim of CoAP should be clean from the word go with regard to supporting these more peer-to-peer transactions, where the client can = exist on either entity and both entities can feed data to each other; typical in = M2M applications.

Robert

Robert Cragie (Pacific Gas & = Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com


On 27/05/2010 7:08 PM, Adriano Pezzuto (apezzuto) wrote:

Hi Robert,

 

in my personal opinion, the option 1a) brings some sort = of ambiguity to CoAP specs.

 

My be my understatement of new CoAP specs is not so deep,  but now we have 5 methods and 3 message types: request, response = and notify. Which methods are allowed with which messages = types?

I suppose you have to use PUT/POST method with notify = message for asynch data notification. How to make a subscribe? I suppose you = would use a SUBSCRIBE method with request/response message or SUBSCRIBE with = notify message? Also what about POST/DELETE methods in a notify message? They = not make any sense..

 

I think the choice is between: option 1) -> only CRUD = methods and option 1b) -> CRUD + SUB/NOTIFY methods, keeping in mind = cost/benefits of both solutions.

 

Adriano

 

From: Robert Cragie [mailto:robert.cragie@gridmerg= e.com]
Sent: mercoled=EC 26 maggio 2010 20.09
To: Adriano Pezzuto (apezzuto)
Cc: Paul Duffy (paduffy); Zach Shelby; core
Subject: Re: [core] Subscribe/Notify for = CoAP

 

Hi Adrian,

I would also prefer to keep the protocol in CoAP asynchronous. You can = always map an asynchronous protocol to a synchronous one but, as we see in = HTTP, it always ends up as a kludge to do it the other way round. The efforts = which have been gone to to make HTTP quasi-asynchronous via all the schemes = mentioned below and many more besides (all non-interoperable of course) is = testament to how important this is for M2M communication.

So, back to Zach's list, I favor 1a) for the following reasons:

Foundation level of messages:

  1. request/response can be asynchronous or synchronous messages (as there is a transaction ID = in there)
  2. notify is an = asynchronous message

Derived methods:

I think it makes sense to add a pub/sub model as a useful mechanism for = M2M.

So, looking at it the other way round: It will be entirely possible to translate whatever is currently built on HTTP to CoAP based on the = above, with all its restrictions regarding synchronous and client/server = transactions. What may be harder is to translate directly is a CoAP-based application to = HTTP. So I guess the question is: Do we want to be hamstrung to synchronous client/server transactions as dictated by HTTP and provide a direct = mapping to HTTP, then have to come up with similar kludges for asynchronous = peer-to-peer transactions as has been done in numerous ways for HTTP, or do we want = to define the protocol cleanly to start with and accept that some sort of transaction relaying/conversion would have to take place at a mapping = node?

Robert

Robert Cragie (Pacific Gas & = Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com


On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote: 

Hi,
it looks to me that CoAP should use an =
explicit sub/notify mechanism since this is the core of the =
machine-to-machine interaction model.
HTTP suffers =
of this lack and we have seen a plethora of solutions to give an asynch =
taste to it. Webhooks and websockets are only the lasts of the =
list.
As someone has already pointed out on this =
list, it is theoretically possible to describe sub/notify using only =
CRUD methods but it looks a little bit tricky and =
verbose.
 
Now we have a =
chance to build from scratch a new protocol with and I think using =
explicit sub/notify methods with a clear and well defined semantic is =
the best option. It is easily understanding from every developer and =
will prevent to build other fanny solutions on top of the CoAP. HTTP =
does not have this well defined semantic and (for hundreds of other =
reasons also) it is not used as wide protocol for machine-to-machine =
communication.
 
CoAP - =
as binary protocol - and with an explicit asynch model has a chance to =
be a really wide protocol for M2M communication not only for constrained =
environments.
 
my 2 =
cents
 
- =
adriano
 
-----Original =
Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] =
On Behalf Of Paul Duffy (paduffy)
Sent: mercoled=EC =
26 maggio 2010 0.47
To: Zach =
Shelby
Cc: core
Subject: Re: =
[core] Subscribe/Notify for =
CoAP
 
On 5/25/2010 6:41 =
PM, Zach Shelby wrote:
  
Hi,
<= pre> 
On May 26, 2010, at 12:23 AM, Charles =
Palmer =
wrote:
 
   =

    
Hi =
folks
 
It occurs to me =
that CoRE should be keeping a close eye on ZigBee SE2.0 work, so that it =
is as easy as possible for ZigBee SE to use CoRE when ready. That =
suggests to me that we should align with their subscribe/notify =
process.
 
  &nb=
sp;  =

      
I am not sure I understand that. I mean, ZigBee SE2.0 is defining =
an application specific subscribe/notify mechanism for that purpose so =
far for HTTP. This uses standard HTTP methods and some custom payload =
and REST interfaces. CoAP Req/Res is already totally compatible with =
SE2.0 in that respect, so alignment is already OK there. Nothing =
stopping someone from using SE2.0 over =
CoAP.
 
Specifying a =
native susbcription/notify into CoAP is another matter. We can't adopt a =
solution specific to one application as that won't solve the problems of =
other applications nor general HTTP mapping at all (probably would make =
it worse). It seems that for the near future there will be a bunch of =
HTTP push mechanisms in use without any clear standard appearing - or am =
I wrong there?
   =

    
 
 
 <=
/o:p>
If COAP extends HTTP semantics with new subscription =
methods, it will 
not be possible to easily =
interchange HTTP/COAP, and translation 
gateways =
will become more complex to =
implement.
 
 
 
  
Zach
= 
 
   =

    
Regards =
- =
Charles
 
 
-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] =
On Behalf Of Paul Duffy
Sent: 25 May 2010 =
03:48
To: Zach Shelby
Cc: =
core
Subject: Re: [core] Subscribe/Notify for =
CoAP
 
Recommend =
something like #2, primarily to avoid introducing non =
HTTP
method semantics, simplifying HTTP/COAP =
translation.gateways, =
etc.
 
 
On 5/24/2010 11:49 AM, Zach Shelby =
wrote:
     =

      


(thread =
renamed)
 
We have two =
different paths with regard to a subscribe/notify mechanism for =
CoAP:
 
1. Use specific =
Subscription and Notify mechanisms for CoAP as HTTP really does not =
include this concept.
1a) Notify as a message and =
SUBSCRIBE as a method. This is currently used in =
coap-01.
1b) NOTIFY and SUBSCRIBE as methods. This =
was used in coap-00, but we had a good list discussion about this =
leading to a. In practice it doesn't make a big difference if =
notification is a message or =
method.
 
2. Use an HTTP =
specific framework such as Webhooks, the ZigBee SE2.0 proposal or =
GENA.
 
So far we have =
focused on 1 in the WG, and every now and again 2 comes up. At least I =
am not convinced that we need to suffer the drawbacks of HTTP here. =
Anyways 2 does not help our mapping to HTTP in reality very much as =
there is no standard way of doing this over HTTP. Thus a CoAP-HTTP proxy =
may end up anyways translating between multiple HTTP frameworks =
depending on the application. So instead of doing a CoAP =
Notify/Subscribe to Webhooks mapping, you will could end up having to do =
a CoAP Webhooks to HTTP GENA =
mapping.
 
  &nb=
sp;    =

        



 
I don't understand this last =
para.  If CoAP sticks to the semantics of
the =
current HTTP methods, would this not offer a fairly =
straightforward
translation to/from =
HTTP?
 
 <=
/pre>
     =

      





 From what I =
have heard so far 1 still seems like a wise choice, although I need to =
look at Webhooks more deeply. In reality many applications specify their =
own way of doing a push interface using REST methods and specific =
payloads (ZigBee SE2.0 is such an example). That is just fine, and might =
be used instead of a specific CoAP notify/subscribe in that case. So 1 =
doesn't prevent the application using its own mechanism, it just =
provides a native way for doing =
push.
       &nbs=
p; =

        &nb=
sp; 



What do people =
think?
 
Zach
 
On May 17, 2010, at 6:44 PM, matthieu.vial=
@fr.non.schneider-electric.com =
wrote:
 
 =

       =

        



Hi,
<=
pre> 
My comments about the subscribe/notify =
mechanism of Zigbee =
IP.
 
Pros:
- Derived from the webhooks concept
- If =
used by CORE it will be easier to map to HTTP because it uses only CRUD =
verbs.
- The subscription message is extendable and =
could support advanced options (delays, increment, =
...)
- Only one listening port whatever the =
transport binding =
is.
 
Cons:
- No interoperability without well known URIs and a well defined =
subscription message format (Not sure CoAP draft is the right place to =
specify this).
- XML/EXI is too complex to be the =
required format for the default subscription/notification =
mechanism.
- The notification should not require a =
subsequent GET to retrieve the content.
- =
Subresource subscription is =
redundant.
 
Hope this =
could =
help,
Matthieu
 
 
<graycol.gif>"Charles =
Palmer"<charles.palmer@onzo.com>
 
 
 
 
"Char=
les Palmer"<charles.palmer@onzo.com>
Envoy=E9 par : core-bounces@ietf.org
15/05/2010 =
14:06
 
<ecblank.gif>=
;
A
<ecblank.gif>
"core"<core@ietf.org>
<=
pre><ecblank.gif>
cc
<=
ecblank.gif>
<ecblank.gif>
=

Objet
<ecblank.gif>
=
Re: [core] Selecting a WG document for =
CoAP
<ecblank.gif> =
<ecblank.gif>
 
Dear=
 all
 
Those interested =
in the subscribe/notify discussion might like to =
look
at the draft Smart Energy Profile 2.0 =
Application Protocol
Specification. It is available =
here:
http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20P=
ublicApp
licationProfile.aspx
 
It manages subscribe/notify by using =
POST. This seems to remove the need
for SUBSCRIBE =
and =
notify.
 
"Imagine a =
host A, which exposes a resource at http{s}://A/resource =
and
a second host B, which wishes to learn of =
changes to this resource. To
facilitate a =
subscription/ notification mechanism, A would expose =
a
resource http{s}://A/sub and B would expose a =
resource http{s}://B/ntfy.
To subscribe to =
notifications regarding http{s}://A/resource, B =
would
send a POST to the address http{s}://A/sub/B =
containing the URI of the
resource of interest =
(http{s}://A/resource) and the URI of =
B's
notification resource (http{s}://B/ntfy). =
Following this subscription
step, should A wish to =
notify B of a change to the resource addressed =
at
http{s}://A/resource, A would send a POST to the =
address
http{s}://B/ntfy containing the URI of the =
resource changed
(http{s}://A/resource) and the URI =
of A's subscription resource
(http{s}://A/sub/B), =
should A wish to change its subscription. The =
host
B can then query the resource (or not) at its =
leisure."
 
Sleepy =
nodes are not allowed to subscribe, and must =
poll.
 
Regards - Charles =
Palmer
 
-----Original =
Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] =
On Behalf Of
Angelo P. =
Castellani
Sent: 14 May 2010 =
13:14
To: Zach Shelby
Cc: =
core
Subject: Re: [core] Selecting a WG document =
for =
CoAP
 
Zach,
 
thanks for the comments, but please =
refer to my most recent e-mail for
a more specific =
list of technical issues I'm pointing =
to.
 
I want to do only a =
little integration to what I've written =
there.
 
In my very =
personal opinion, to maximize adherence with the REST =
model
and minimize implementation effort SUBSCRIBE =
and NOTIFY should be
mapped to methods (as =
discussed many times =
together...).
 
Uniform =
interface principle (Fielding PhD dissertation Section =
5.1.5,
"The central feature that distinguishes =
the REST architectural style
[...]") states =
that to simplify the software architecture, =
resource
interfaces/interfaces should be as general =
as possible.
 
I agree =
with this principle in this specific case, mainly =
because
handling a special message type for notify =
leads node software design
to a more complex =
architecture.
 
The =
reason is that this new message type requires special handling =
and
introduces a complexity in the software =
modularization.
 
Best,
Angelo
 
On Fri, May 14, 2010 at 13:06, Zach Shelby<zach@sensinode.com> &n=
bsp; =
wrote:
 
   =
;      =

        &nb=
sp; 



Hi =
Angelo,
 
On May 13, =
2010, at 14:24 , Angelo P. Castellani =
wrote:
 
 =

           =

        &nb=
sp;   



Dear C. =
Bormann, all,
 
before =
deciding for the final direction, I've the =
following
observations about =
draft-shelby-core-coap-01
 
While I mostly share Zach's view of the protocol approach, =
and
appreciate many aspects of the proposal, there =
are in my =
opinion
 
  &nbs=
p;          =

        &nb=
sp;     



still
 
  &=
nbsp;      =

        &nb=
sp; 
some =
open issues that need to be at least discussed before =
the
 
   &n=
bsp;         =

        &nb=
sp;     
current
 
  =
;       =

        &nb=
sp; 
document =
can be =
selected.
 
  &n=
bsp;          =

        &nb=
sp;     
Of course there are plenty of open issues. Remember that working =
group
 
   =
        =

        &nb=
sp;   
documents still undertake as much change and improvement as the =
WG
wants, so by no means is coap-01 set in stone. I =
would expect at least
5-10 more revisions still =
along the way.  Already several of your =
ideas
have been integrated into coap-01, and =
several more are under
consideration, so it is =
coming along. Patience =
;-)
 
   &n=
bsp;     =

        &nb=
sp; 
   &nb=
sp;       =

        &nb=
sp;   
In =
particular, I would like to highlight the =
following:
 
a) As it is =
now, it is not possible to have a =
straightforward
translation of HTTP =
->   CoAP and viceversa: see
=
http://www.ietf.org/mail-archive/web/core/current/msg00133.html =
(this
impacts the scalability of the web service =
model =
too)
 
   &=
nbsp;         =

        &nb=
sp;     
In coap-01 the Method names are now identical to HTTP methods. =
The
 
   &n=
bsp;       =

        &nb=
sp;   
Req/Res interaction is a direct translation. The URI hierarchy =
is
compatible, and the URI binary code format we =
are still working on
obviously. The only thing that =
takes some state to translate is
Subscribe/Notify. =
But note, Subscribe/Notify takes some state no =
matter
how you do it, even with HTTP-HTTP there is =
no clean and easy way to
handle =
subscriptions.
 
 &nb=
sp;      =
 
       &nb=
sp;  
   &nb=
sp;       =

        &nb=
sp;   
b) =
Moreover, CoAP's implementation is not as simple as it should =
be.
I've investigated the implementation and some =
design choices (as
Options) are leading to very =
high program complexity (ROM) on a
MSP430-based =
device.
 
  &nbs=
p;          =

        &nb=
sp;     
This we can definitely improve, and already made several =
optimizations
 
 &nbs=
p;         =

        &nb=
sp;   
from -00 to -01. Here I need some very concrete proposals though. =
Also
remember that many things are optional, for =
example subscribe/notify is
not required if you =
don't need =
it.
 
   &n=
bsp;     =

        &nb=
sp; 
   &nb=
sp;       =

        &nb=
sp;   
c) =
Finally when comparing HTTP message size with CoAP message =
size,
the resulting compression isn't as good as =
you may =
expect.
 
Example:
HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 =
B
CoAP: 24 B with options parsing procedure =
requiring an added
implementation =
complexity
 
  &=
nbsp;          =

        &nb=
sp;     
Right, that is not how it will work in practice. Working with a =
real
 
   &=
nbsp;       =

        &nb=
sp;   
HTTP server that HTTP header will be more complex, and on the CoAP =
side
you would chose shorter URLs. The biggest =
improvement possible here is
from using binary =
coded URLs of course. We need to look at a wider =
range
of interactions and real HTTP headers as well =
to check that we are
efficient =
enough.
 
  &nbs=
p;      =

        &nb=
sp; 
   &nb=
sp;       =

        &nb=
sp;   
Addressing all these =
points potentially leads to major =
technical
modifications (especially point a) on the =
current draft, hence it is
appropriate in my =
opinion to discuss these points before making =
the
final =
decision.
 
  &n=
bsp;          =

        &nb=
sp;     
I am not sure what else you have in mind for a). If we just =
forget
 
   =
;        =

        &nb=
sp;   
about Subscribe/Notify then you are good to go. But then you are =
also
not fulfilling the charter or the industry =
needs in that =
respect.
 
  &nb=
sp;      =

        &nb=
sp; 
Thanks,
Zach
 
 =

         &n=
bsp; =

        &nb=
sp;   



Best =
regards,
 
Angelo P. =
Castellani
 
 
On Mon, May 10, 2010 at 18:51, Carsten Bormann<cabo@tzi.org>   =
wrote:
 
   =
;          =

        &nb=
sp;     



The CORE =
WG has a milestone to select a WG document for CoAP =
in
 
   &nb=
sp;           =

        &nb=
sp;       









April:
 
  =
       =

        &nb=
sp; 









http://datatracker.=
ietf.org/wg/core/charter/
...
Apr 2010        Select WG document =
for basis of the CoAP =
protocol
 
Of the various =
documents that have been =
contributed,
 
  =
;            =
 =

        &nb=
sp;       
draft-shelby-core-coap has significant discussion, as well as =
the
largest number of updates (including a previous =
version that was still
called =
-6lowapp-coap).
 
 &n=
bsp;       =

        &nb=
sp; 
Today, =
another updated version of that draft was announced.  =
See
=
http://www.ietf.org/mail-archive/web/core/current/msg00138.html<=
/o:p>
for the announcement and
http://tool=
s.ietf.org/html/draft-shelby-core-coap-01
for =
the draft =
itself.
 
However, as the =
authors say, there are still significant =
TODOs.
 
Are we in a =
state yet where we can say whether this is the =
right
 
   =
            =

        &nb=
sp;       
direction for the WG to =
take?
 
   =
      =

        &nb=
sp; 
If yes, =
is it the right direction?  Should we adopt it as a =
WG
 
   &nb=
sp;           =

        &nb=
sp;       
document?
 
 &nb=
sp;       =

        &nb=
sp; 
If you =
don't think we can say yet, is there a set of =
technical
 
  &n=
bsp;            =

        &nb=
sp;       
decisions you would like the authors to take with =
priority?
 
  &n=
bsp;      =

        &nb=
sp; 
Note =
that once a document has become a WG document, the authors =
act
 
   &n=
bsp;           =

        &nb=
sp;       
as editors for the working group, making (and usually fleshing out =
the
details of) any change that the WG decides it =
needs.
 
   =
;      =

        &nb=
sp; 
If you =
think we can still improve the draft, this is not an =
obstacle
 
  &nb=
sp;            =

        &nb=
sp;       
to making it a WG =
document.
 
  &n=
bsp;      =

        &nb=
sp; 
But of =
course we shouldn't do that if we intend to reverse =
its
 
   &n=
bsp;           =

        &nb=
sp;       
fundamental technical =
direction.
 
  &=
nbsp;      =

        &nb=
sp; 
In order =
to stay roughly in sync with our milestones, we =
should
 
   =
;            =

        &nb=
sp;       
reach at a decision on how to go forward this =
week.
 
   =
      =

        &nb=
sp; 
Gruesse, =
Carsten
 
________________=
_______________________________
core mailing =
list
core@ietf.org
https://www.ietf.org/=
mailman/listinfo/core
 
 
       &=
nbsp;       =

        &nb=
sp;       
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/=
mailman/listinfo/core
 
            = ; = 
        &nb=
sp;     
--
Zach Shelby, Chief Nerd, Sensinode =
Ltd.
http://zachshelby.org  - My blog =
"On the Internet of Things"
http://6lowpan.net - My book =
"6LoWPAN: The Wireless Embedded =
Internet"
Mobile: +358 40 =
7796297
 
 
 
     &nb=
sp;     =

        &nb=
sp;   
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/=
mailman/listinfo/core
 
--------------------------------
Onzo is a =
limited company number 06097997 registered in England&   =
Wales. The
registered office is 6 Great Newport =
Street, London, WC2H 7JB, United =
Kingdom.
 
This email =
message may contain confidential and/or privileged information, =
and
is intended solely for the addressee(s). If you =
have received this email in
error, please notify =
Onzo immediately. Unauthorised copying, disclosure =
or
distribution of the material in this email is =
forbidden.
--------------------------------
 
________________________________=
_______________
core mailing =
list
core@ietf.org
https://www.ietf.org/=
mailman/listinfo/core
 
______________________________________________________________________<= o:p>
This email has been scanned by the MessageLabs =
Email Security =
System.
____________________________________________=
__________________________
 
_______________________________________________
c=
ore mailing list
core@ietf.org
https://www.ietf.org/=
mailman/listinfo/core
 
         = 
        &nb=
sp; 
       =

        
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/=
mailman/listinfo/core
 
--------------------------------
Onzo is a =
limited company number 06097997 registered in England&  Wales. =
The
registered office is 6 Great Newport Street, =
London, WC2H 7JB, United =
Kingdom.
 
This email =
message may contain confidential and/or privileged information, =
and
is intended solely for the addressee(s). If you =
have received this email in
error, please notify =
Onzo immediately. Unauthorised copying, disclosure =
or
distribution of the material in this email is =
forbidden.
--------------------------------
 
     =

      
   =

    
 
________________________________________=
_______
core mailing list
core@ietf.org
https://www.ietf.org/=
mailman/listinfo/core
__________________________=
_____________________
core mailing =
list
core@ietf.org
https://www.ietf.org/=
mailman/listinfo/core
 
 
------_=_NextPart_001_01CAFE53.915C6D66-- From matthieu.vial@fr.non.schneider-electric.com Fri May 28 04:52:01 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9775B3A689E; Fri, 28 May 2010 04:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.407 X-Spam-Level: ** X-Spam-Status: No, score=2.407 tagged_above=-999 required=5 tests=[AWL=-1.742, BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c30m-vPD3sVg; Fri, 28 May 2010 04:51:57 -0700 (PDT) Received: from mailX03.eud.schneider-electric.com (mailx03.eud.schneider-electric.com [205.167.7.41]) by core3.amsl.com (Postfix) with ESMTP id AAB3C3A6836; Fri, 28 May 2010 04:51:55 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX03.eud.schneider-electric.com with ESMTP id 2010052813415060-56535 ; Fri, 28 May 2010 13:41:50 +0200 In-Reply-To: <0D212BD466921646B58854FB79092CEC021F4E91@XMB-AMS-106.cisco.com> To: "Adriano Pezzuto (apezzuto)" X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: matthieu.vial@fr.non.schneider-electric.com Date: Fri, 28 May 2010 13:51:40 +0200 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 28/05/2010 13:51:45, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 28/05/2010 13:41:50, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 28/05/2010 13:41:51 Content-type: multipart/related; Boundary="0__=4EBBFDA2DFAD2C738f9e8a93df938690918c4EBBFDA2DFAD2C73" Cc: core-bounces@ietf.org, core Subject: Re: [core] Subscribe/Notify for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 11:52:01 -0000 --0__=4EBBFDA2DFAD2C738f9e8a93df938690918c4EBBFDA2DFAD2C73 Content-type: multipart/alternative; Boundary="1__=4EBBFDA2DFAD2C738f9e8a93df938690918c4EBBFDA2DFAD2C73" --1__=4EBBFDA2DFAD2C738f9e8a93df938690918c4EBBFDA2DFAD2C73 Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=ISO-8859-1 > So strictly speaking, both NOTIFY and SUBSCRIBE are message types not= methods! SUBSCRIBE can be just an asynchronous GET on update then I think it is= a method and NOTIFY is an asynchronous response so a message. But if we want to have selective notifications when a resource is creat= ed, updated or deleted then I think you're right NOTIFY and SUBSCRIBE are messages. Does that make sense ? Matthieu = "Adriano Pezzuto = (apezzuto)" = = Envoy=E9 par : = cc core-bounces@ietf core = .org Ob= jet Re: [core] Subscribe/Notify for = CoAP = 28/05/2010 12:50 = = = = = = Hi Roberto, I understand your point and personally agree on M2M is quite different = from web page model. On the architectural RESTful style, the method informat= ion tells the server what to do with data kept in the URI information. So strictly speaking, both NOTIFY and SUBSCRIBE are message types not methods! Adriano From: Robert Cragie [mailto:robert.cragie@gridmerge.com] Sent: venerd=EC 28 maggio 2010 11.53 To: Adriano Pezzuto (apezzuto) Cc: Paul Duffy (paduffy); Zach Shelby; core Subject: Re: [core] Subscribe/Notify for CoAP I think the point here is that there are two levels we are considering.= At the lowest (foundation) level, there are the transaction messages as= described below. This provides a flexible mechanism for the application= with regard to synchronicity and threading. This is important for the t= ypes of devices CoAP is being aimed at. Above that, the methods can be used according to the architectural styl= e. So in this case, it is RESTful (COnstrained Restful Environments), whic= h will naturally limit the number of methods and how transactions occur. The actual architecture using a combination of the methods and messages= also depends on what is required at the application layer. Consider a typical client which wants to subscribe to a resource. That client cont= rols the feed of data but needs a component which is capable of handling (possibly buffering) the data it receives through notifications. Is thi= s a separate server? Or would we want to consider it part of an enhanced cl= ient model which is able to process feeds of data? These are the sort of mod= els which have led to the myriad of solutions (GENA, Webhooks, long polling= , pubsubhubbub, RESTMS etc.) based around HTTP which are all essentially ingenious ways of getting around the limitations imposed by HTTP and ho= w it is processed for anything which deviates from the classic web page acce= ss model. I think the aim of CoAP should be clean from the word go with regard to= supporting these more peer-to-peer transactions, where the client can e= xist on either entity and both entities can feed data to each other; typical= in M2M applications. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 27/05/2010 7:08 PM, Adriano Pezzuto (apezzuto) wrote: Hi Robert, in my personal opinion, the option 1a) brings some sort of ambiguity to= CoAP specs. My be my understatement of new CoAP specs is not so deep, but now we h= ave 5 methods and 3 message types: request, response and notify. Which meth= ods are allowed with which messages types? I suppose you have to use PUT/POST method with notify message for async= h data notification. How to make a subscribe? I suppose you would use a SUBSCRIBE method with request/response message or SUBSCRIBE with notify= message? Also what about POST/DELETE methods in a notify message? They = not make any sense.. I think the choice is between: option 1) -> only CRUD methods and optio= n 1b) -> CRUD + SUB/NOTIFY methods, keeping in mind cost/benefits of both= solutions. Adriano From: Robert Cragie [mailto:robert.cragie@gridmerge.com] Sent: mercoled=EC 26 maggio 2010 20.09 To: Adriano Pezzuto (apezzuto) Cc: Paul Duffy (paduffy); Zach Shelby; core Subject: Re: [core] Subscribe/Notify for CoAP Hi Adrian, I would also prefer to keep the protocol in CoAP asynchronous. You can always map an asynchronous protocol to a synchronous one but, as we see= in HTTP, it always ends up as a kludge to do it the other way round. The efforts which have been gone to to make HTTP quasi-asynchronous via all= the schemes mentioned below and many more besides (all non-interoperable of= course) is testament to how important this is for M2M communication. So, back to Zach's list, I favor 1a) for the following reasons: Foundation level of messages: 1. request/response can be asynchronous or synchronous messages (as there is a transaction ID in there) 2. notify is an asynchronous message Derived methods: I think it makes sense to add a pub/sub model as a useful mechanism for= M2M. So, looking at it the other way round: It will be entirely possible to translate whatever is currently built on HTTP to CoAP based on the abov= e, with all its restrictions regarding synchronous and client/server transactions. What may be harder is to translate directly is a CoAP-bas= ed application to HTTP. So I guess the question is: Do we want to be hamst= rung to synchronous client/server transactions as dictated by HTTP and provi= de a direct mapping to HTTP, then have to come up with similar kludges for asynchronous peer-to-peer transactions as has been done in numerous way= s for HTTP, or do we want to define the protocol cleanly to start with an= d accept that some sort of transaction relaying/conversion would have to = take place at a mapping node? Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote: Hi, it looks to me that CoAP should use an explicit sub/notify mechanism si= nce this is the core of the machine-to-machine interaction model. HTTP suffers of this lack and we have seen a plethora of solutions to g= ive an asynch taste to it. Webhooks and websockets are only the lasts of th= e list. As someone has already pointed out on this list, it is theoretically possible to describe sub/notify using only CRUD methods but it looks a little bit tricky and verbose. Now we have a chance to build from scratch a new protocol with and I th= ink using explicit sub/notify methods with a clear and well defined semanti= c is the best option. It is easily understanding from every developer and wi= ll prevent to build other fanny solutions on top of the CoAP. HTTP does no= t have this well defined semantic and (for hundreds of other reasons also= ) it is not used as wide protocol for machine-to-machine communication. CoAP - as binary protocol - and with an explicit asynch model has a cha= nce to be a really wide protocol for M2M communication not only for constra= ined environments. my 2 cents - adriano -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of= Paul Duffy (paduffy) Sent: mercoled=EC 26 maggio 2010 0.47 To: Zach Shelby Cc: core Subject: Re: [core] Subscribe/Notify for CoAP On 5/25/2010 6:41 PM, Zach Shelby wrote: Hi, On May 26, 2010, at 12:23 AM, Charles Palmer wrote: Hi folks It occurs to me that CoRE should be keeping a close eye on ZigBee SE2.0 work, so that it is as easy as possible for Zi= gBee SE to use CoRE when ready. That suggests to me that we shou= ld align with their subscribe/notify process. I am not sure I understand that. I mean, ZigBee SE2.0 is defining= an application specific subscribe/notify mechanism for that purpose = so far for HTTP. This uses standard HTTP methods and some custom pay= load and REST interfaces. CoAP Req/Res is already totally compatible w= ith SE2.0 in that respect, so alignment is already OK there. Nothing stopping someone from using SE2.0 over CoAP. Specifying a native susbcription/notify into CoAP is another matt= er. We can't adopt a solution specific to one application as that won= 't solve the problems of other applications nor general HTTP mapping= at all (probably would make it worse). It seems that for the near fu= ture there will be a bunch of HTTP push mechanisms in use without any clear standard appearing - or am I wrong there? If COAP extends HTTP semantics with new subscription methods, it will not be possible to easily interchange HTTP/COAP, and translation gateways will become more complex to implement. Zach Regards - Charles -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] = On Behalf Of Paul Duffy Sent: 25 May 2010 03:48 To: Zach Shelby Cc: core Subject: Re: [core] Subscribe/Notify for CoAP Recommend something like #2, primarily to avoid introducing= non HTTP method semantics, simplifying HTTP/COAP translation.gateway= s, etc. On 5/24/2010 11:49 AM, Zach Shelby wrote: (thread renamed) We have two different paths with regard to a subscribe/notify mechanism for CoAP: 1. Use specific Subscription and Notify mechanisms fo= r CoAP as HTTP really does not include this concept. 1a) Notify as a message and SUBSCRIBE as a method. Th= is is currently used in coap-01. 1b) NOTIFY and SUBSCRIBE as methods. This was used in= coap-00, but we had a good list discussion about this= leading to a. In practice it doesn't make a big difference if notification is a message or method. 2. Use an HTTP specific framework such as Webhooks, t= he ZigBee SE2.0 proposal or GENA. So far we have focused on 1 in the WG, and every now = and again 2 comes up. At least I am not convinced that we= need to suffer the drawbacks of HTTP here. Anyways 2 = does not help our mapping to HTTP in reality very much as there is no standard way of doing this over HTTP. Thu= s a CoAP-HTTP proxy may end up anyways translating betwee= n multiple HTTP frameworks depending on the application= . So instead of doing a CoAP Notify/Subscribe to Webhooks mapping, you will could end up having to do a CoAP Webhooks to HTTP GENA mapping. I don't understand this last para. If CoAP sticks to the semantics of the current HTTP methods, would this not offer a fairly straightforward translation to/from HTTP? From what I have heard so far 1 still seems li= ke a wise choice, although I need to look at Webhook= s more deeply. In reality many applications speci= fy their own way of doing a push interface using R= EST methods and specific payloads (ZigBee SE2.0 is = such an example). That is just fine, and might be us= ed instead of a specific CoAP notify/subscribe in = that case. So 1 doesn't prevent the application usin= g its own mechanism, it just provides a native wa= y for doing push. What do people think? Zach On May 17, 2010, at 6:44 PM, matthieu.vial@fr.non.schneider-electric.com wrote: Hi, My comments about the subscribe/notify mechanis= m of Zigbee IP. Pros: - Derived from the webhooks concept - If used by CORE it will be easier to map to H= TTP because it uses only CRUD verbs. - The subscription message is extendable and co= uld support advanced options (delays, increment, ..= .) - Only one listening port whatever the transpor= t binding is. Cons: - No interoperability without well known URIs a= nd a well defined subscription message format (Not s= ure CoAP draft is the right place to specify this).= - XML/EXI is too complex to be the required for= mat for the default subscription/notification mechanism. - The notification should not require a subsequ= ent GET to retrieve the content. - Subresource subscription is redundant. Hope this could help, Matthieu "Charles Palmer" "Charles Palmer" Envoy=E9 par : core-bounces@ietf.org 15/05/2010 14:06 A "core" cc Objet Re: [core] Selecting a WG document for CoAP Dear all Those interested in the subscribe/notify discus= sion might like to look at the draft Smart Energy Profile 2.0 Applicati= on Protocol Specification. It is available here: http://zigbee.org/Markets/ZigBeeSmartEnergy/Zig= BeeSmartEnergy20PublicApp licationProfile.aspx It manages subscribe/notify by using POST. This= seems to remove the need for SUBSCRIBE and notify. "Imagine a host A, which exposes a resource at = http {s}://A/resource and a second host B, which wishes to learn of chang= es to this resource. To facilitate a subscription/ notification mechani= sm, A would expose a resource http{s}://A/sub and B would expose a resource http{s}://B/ntfy. To subscribe to notifications regarding http {s}://A/resource, B would send a POST to the address http{s}://A/sub/B containing the URI of the resource of interest (http{s}://A/resource) and= the URI of B's notification resource (http{s}://B/ntfy). Follo= wing this subscription step, should A wish to notify B of a change to = the resource addressed at http{s}://A/resource, A would send a POST to th= e address http{s}://B/ntfy containing the URI of the reso= urce changed (http{s}://A/resource) and the URI of A's subscription resource (http{s}://A/sub/B), should A wish to change it= s subscription. The host B can then query the resource (or not) at its leisure." Sleepy nodes are not allowed to subscribe, and = must poll. Regards - Charles Palmer -----Original Message----- From: core-bounces@ietf.org [ mailto:core-bounces@ietf.org] On Behalf Of Angelo P. Castellani Sent: 14 May 2010 13:14 To: Zach Shelby Cc: core Subject: Re: [core] Selecting a WG document for= CoAP Zach, thanks for the comments, but please refer to my= most recent e-mail for a more specific list of technical issues I'm pointing to. I want to do only a little integration to what = I've written there. In my very personal opinion, to maximize adhere= nce with the REST model and minimize implementation effort SUBSCRIBE an= d NOTIFY should be mapped to methods (as discussed many times together...). Uniform interface principle (Fielding PhD dissertation Section 5.1.5, "The central feature that distinguishes the RES= T architectural style [...]") states that to simplify the software architecture, resource interfaces/interfaces should be as general as possible. I agree with this principle in this specific ca= se, mainly because handling a special message type for notify lead= s node software design to a more complex architecture. The reason is that this new message type requir= es special handling and introduces a complexity in the software modularization. Best, Angelo On Fri, May 14, 2010 at 13:06, Zach Shelby wrote: Hi Angelo, On May 13, 2010, at 14:24 , Angelo P. Castellani wrote: Dear C. Bormann, all, before deciding for the final direction, I've the following observations about draft-shelby-core-coap-01 While I mostly share Zach's view of= the protocol approach, and appreciate many aspects of the proposal, there are in my opinion still some open issues that need to be at= least discussed before the current document can be selected. Of course there are plenty of open issues= . Remember that working group documents still undertake as much change and improvement as the WG wants, so by no means is coap-01 set in stone. = I would expect at least 5-10 more revisions still along the way. Alrea= dy several of your ideas have been integrated into coap-01, and several = more are under consideration, so it is coming along. Patience = ;-) In particular, I would like to highlight the following: a) As it is now, it is not possible= to have a straightforward translation of HTTP -> CoAP and viceversa: see http://www.ietf.org/mail-archive/we= b/core/current/msg00133.html (this impacts the scalability of the web service model too) In coap-01 the Method names are now ident= ical to HTTP methods. The Req/Res interaction is a direct translation. Th= e URI hierarchy is compatible, and the URI binary code format we a= re still working on obviously. The only thing that takes some state= to translate is Subscribe/Notify. But note, Subscribe/Notify ta= kes some state no matter how you do it, even with HTTP-HTTP there is no clean and easy way to handle subscriptions. b) Moreover, CoAP's implementation = is not as simple as it should be. I've investigated the implementatio= n and some design choices (as Options) are leading to very high program complexity (ROM) on a MSP430-based device. This we can definitely improve, and alrea= dy made several optimizations from -00 to -01. Here I need some very concrete= proposals though. Also remember that many things are optional, for exa= mple subscribe/notify is not required if you don't need it. c) Finally when comparing HTTP mess= age size with CoAP message size, the resulting compression isn't as = good as you may expect. Example: HTTP: GET /sensor/temp.xml HTTP/1.0= =3D 32 B CoAP: 24 B with options parsing procedure requiring an added implementation complexity Right, that is not how it will work in practice. Working with a real HTTP server that HTTP header will be more compl= ex, and on the CoAP side you would chose shorter URLs. The biggest improvement possible here is from using binary coded URLs of course. We need= to look at a wider range of interactions and real HTTP headers as well t= o check that we are efficient enough. Addressing all these points potenti= ally leads to major technical modifications (especially point a) = on the current draft, hence it is appropriate in my opinion to discus= s these points before making the final decision. I am not sure what else you have in mind = for a). If we just forget about Subscribe/Notify then you are good to go.= But then you are also not fulfilling the charter or the industry need= s in that respect. Thanks, Zach Best regards, Angelo P. Castellani On Mon, May 10, 2010 at 18:51, Cars= ten Bormann wrote: The CORE WG has a milestone t= o select a WG document for CoAP= in April: http://datatracker.ietf.org/w= g/core/charter/ ... Apr 2010 Select WG document for basis of the CoA= P protocol Of the various documents that= have been contributed, draft-shelby-core-coap has significant discussi= on, as well as the largest number of updates (including a previous= version that was still called -6lowapp-coap). Today, another updated versio= n of that draft was announced. Se= e http://www.ietf.org/mail-arch= ive/web/core/current/msg00138.html for the announcement and http://tools.ietf.org/html/dr= aft-shelby-core-coap-01 for the draft itself. However, as the authors say, there are still significant TODOs. Are we in a state yet where w= e can say whether this is the r= ight direction for the WG to take? If yes, is it the right direction? Should we adopt i= t as a WG document? If you don't think we can say= yet, is there a set of techni= cal decisions you would like the authors to take wi= th priority? Note that once a document has= become a WG document, the aut= hors act as editors for the working group, making (and usually fleshing out the details of) any change that the WG decides it needs. If you think we can still imp= rove the draft, this is not an obstacle to making it a WG document. But of course we shouldn't do= that if we intend to reverse = its fundamental technical direction. In order to stay roughly in s= ync with our milestones, we shoul= d reach at a decision on how to go forward this w= eek. Gruesse, Carsten _____________________________= __________________ core mailing list core@ietf.org https://www.ietf.org/mailman/= listinfo/core ___________________________________= ____________ core mailing list core@ietf.org https://www.ietf.org/mailman/listin= fo/core -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: Th= e Wireless Embedded Internet" Mobile: +358 40 7796297 _______________________________________________= core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core -------------------------------- Onzo is a limited company number 06097997 registered in England& Wales. The registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingdom. This email message may contain confidential and= /or privileged information, and is intended solely for the addressee(s). If you= have received this email in error, please notify Onzo immediately. Unauthor= ised copying, disclosure or distribution of the material in this email is forbidden. -------------------------------- _______________________________________________= core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core _______________________________________________= _______________________= This email has been scanned by the MessageLabs Email Security System. _______________________________________________= _______________________ _______________________________________________= core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core -------------------------------- Onzo is a limited company number 06097997 registered in England& Wales. The registered office is 6 Great Newport Street, London, WC2H 7= JB, United Kingdom. This email message may contain confidential and/or privileg= ed information, and is intended solely for the addressee(s). If you have receiv= ed this email in error, please notify Onzo immediately. Unauthorised copying= , disclosure or distribution of the material in this email is forbidden. -------------------------------- _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core = --1__=4EBBFDA2DFAD2C738f9e8a93df938690918c4EBBFDA2DFAD2C73 Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

> So strictly spe= aking, both NOTIFY and SUBSCRIBE are message types not =A0methods!
SUBSCRIBE can be just an asynchronous GET on update then I think it is a m= ethod and NOTIFY is an asynchronous response so a message.
But if we want to have selective notifications when a resource is created, = updated or deleted then I think you're right NOTIFY and SUBSCRIBE are messa= ges.

Does that make sense ?

Matthieu

3D"Inactive"Adriano Pez= zuto (apezzuto)" <apezzuto@cisco.com>




          "Adriano Pezzuto (apezzuto)" <apezzuto= @cisco.com>
          Envoy=E9 par : core-bounces@ietf.org

          28/05/2010 12:50
3D"=
A
3D""
<robert.cragie@gridmerge.com>
3D"=
cc
3D""
core <core@ietf.org>
3D"=
Objet
3D""
Re: [core] Subscribe/Notify for CoAP
3D""=3D""

Hi Roberto,
I understand your point= and personally agree on M2M is quite different from web page model. On the= architectural RESTful style, the method information tells the server what = to do with data kept in the URI information.

So strictly speaking, b= oth NOTIFY and SUBSCRIBE are message types not =A0methods!

Adriano

From: Robert Cragie [= mailto:robert.cragie@gridmerge.com]
Sent: venerd=EC 28 maggio 2010 = 11.53
To: Adriano Pezzuto (apezzuto)<= /font>
Cc: Paul Duffy (paduffy); Zach = Shelby; core
Subject: Re: [core] Subscribe/N= otify for CoAP

I think the point here is that th= ere are two levels we are considering.

At the lowest (foundation) level, there are the transaction messages as des= cribed below. This provides a flexible mechanism for the application with r= egard to synchronicity and threading. This is important for the types of de= vices CoAP is being aimed at.

Above that, the methods can be used according to the architectural style. S= o in this case, it is RESTful (COnstrained Restful Environments), which wil= l naturally limit the number of methods and how transactions occur.

The actual architecture using a combination of the methods and messages als= o depends on what is required at the application layer. Consider a typical = client which wants to subscribe to a resource. That client controls the fee= d of data but needs a component which is capable of handling (possibly buff= ering) the data it receives through notifications. Is this a separate serve= r? Or would we want to consider it part of an enhanced client model which i= s able to process feeds of data? These are the sort of models which have le= d to the myriad of solutions (GENA, Webhooks, long polling, pubsubhubbub, R= ESTMS etc.) based around HTTP which are all essentially ingenious ways of g= etting around the limitations imposed by HTTP and how it is processed for a= nything which deviates from the classic web page access model.

I think the aim of CoAP should be clean from the word go with regard to sup= porting these more peer-to-peer transactions, where the client can exist on= either entity and both entities can feed data to each other; typical in M2= M applications.

Robert

Robert Cragie (Pacific Gas & Elect= ric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com

On 27/05/2010 7:08 PM, Adriano Pezzuto (apezzuto) wrote:
Hi Robert,

in my personal opinion,= the option 1a) brings some sort of ambiguity to CoAP specs.

My be my understatement= of new CoAP specs is not so deep, but now we have 5 methods and 3 message= types: request, response and notify. Which methods are allowed with which = messages types?
I suppose you have to u= se PUT/POST method with notify message for asynch data notification. How to= make a subscribe? I suppose you would use a SUBSCRIBE method with request/= response message or SUBSCRIBE with notify message? Also what about POST/DEL= ETE methods in a notify message? They not make any sense..

I think the choice is b= etween: option 1) -> only CRUD methods and option 1b) -> CRUD + SUB/N= OTIFY methods, keeping in mind cost/benefits of both solutions.

Adriano

From: Robert Cragie [mailto:robert.= cragie@gridmerge.com]
Sent: mercoled=EC 26 maggio 201= 0 20.09
To: Adriano Pezzuto (apezzuto)<= /font>
Cc: Paul Duffy (paduffy); Zach = Shelby; core
Subject: Re: [core] Subscribe/N= otify for CoAP

Hi Adrian,

I would also prefer to keep the protocol in CoAP asynchronous. You can alwa= ys map an asynchronous protocol to a synchronous one but, as we see in HTTP= , it always ends up as a kludge to do it the other way round. The efforts w= hich have been gone to to make HTTP quasi-asynchronous via all the schemes = mentioned below and many more besides (all non-interoperable of course) is = testament to how important this is for M2M communication.

So, back to Zach's list, I favor 1a) for the following reasons:

Foundation level of messages:

    1. request/response can be as= ynchronous or synchronous messages (as there is a transaction ID in there)<= /font>
    2. notify is an asynchronous mess= age
Derived methods:

I think it makes sense to add a pub/sub model as a useful mechanism for M2M= .

So, looking at it the other way round: It will be entirely possible to tran= slate whatever is currently built on HTTP to CoAP based on the above, with = all its restrictions regarding synchronous and client/server transactions. = What may be harder is to translate directly is a CoAP-based application to = HTTP. So I guess the question is: Do we want to be hamstrung to synchronous= client/server transactions as dictated by HTTP and provide a direct mappin= g to HTTP, then have to come up with similar kludges for asynchronous peer-= to-peer transactions as has been done in numerous ways for HTTP, or do we w= ant to define the protocol cleanly to start with and accept that some sort = of transaction relaying/conversion would have to take place at a mapping no= de?

Robert

Robert Cragie (Pacific Gas & Elect= ric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com

On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote:
Hi,
it looks to me that CoAP should use a= n explicit sub/notify mechanism since this is the core of the machine-to-ma= chine interaction model.
HTTP suffers of this lack and we have= seen a plethora of solutions to give an asynch taste to it. Webhooks and w= ebsockets are only the lasts of the list.
As someone has already pointed out on= this list, it is theoretically possible to describe sub/notify using only = CRUD methods but it looks a little bit tricky and verbose.

Now we have a chance to build from sc= ratch a new protocol with and I think using explicit sub/notify methods wit= h a clear and well defined semantic is the best option. It is easily unders= tanding from every developer and will prevent to build other fanny solution= s on top of the CoAP. HTTP does not have this well defined semantic and (fo= r hundreds of other reasons also) it is not used as wide protocol for machi= ne-to-machine communication.

CoAP - as binary protocol - and with = an explicit asynch model has a chance to be a really wide protocol for M2M = communication not only for constrained environments.

my 2 cents

- adriano

-----Original Message-----
From: core-bounces@ietf.org= [mailto:core-bounces@ietf.org] On Behalf Of Paul Duffy (paduffy)=
Sent: mercoled=EC 26 maggio 2010 0.47=
To: Zach Shelby
Cc: core
Subject: Re: [core] Subscribe/Notify = for CoAP

On 5/25/2010 6:41 PM, Zach Shelby wro= te:




If COAP extends HTTP semantics with n= ew subscription methods, it will
not be possible to easily interchange= HTTP/COAP, and translation
gateways will become more complex to = implement.
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinf= o/core
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinf= o/core



=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
This email has been scanned by the MessageLabs Email Security System.
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
core mailing list
core@ietf.org
https://www= .ietf.org/mailman/listinfo/core

--1__=4EBBFDA2DFAD2C738f9e8a93df938690918c4EBBFDA2DFAD2C73-- --0__=4EBBFDA2DFAD2C738f9e8a93df938690918c4EBBFDA2DFAD2C73 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <2__=4EBBFDA2DFAD2C738@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=4EBBFDA2DFAD2C738f9e8a93df938690918c4EBBFDA2DFAD2C73 Content-type: image/gif; name="pic01723.gif" Content-Disposition: inline; filename="pic01723.gif" Content-ID: <3__=4EBBFDA2DFAD2C738@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=4EBBFDA2DFAD2C738f9e8a93df938690918c4EBBFDA2DFAD2C73 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <4__=4EBBFDA2DFAD2C738@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=4EBBFDA2DFAD2C738f9e8a93df938690918c4EBBFDA2DFAD2C73-- From robert.cragie@gridmerge.com Fri May 28 05:09:05 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1FE83A6822; Fri, 28 May 2010 05:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.744 X-Spam-Level: * X-Spam-Status: No, score=1.744 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlWmt14Uo9tU; Fri, 28 May 2010 05:09:00 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 81CC63A659B; Fri, 28 May 2010 05:08:59 -0700 (PDT) Received: from client-82-26-176-40.pete.adsl.virginmedia.com ([82.26.176.40] helo=[192.168.1.70]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1OHyMl-00031S-Oi; Fri, 28 May 2010 13:08:47 +0100 Message-ID: <4BFFB246.4010600@gridmerge.com> Date: Fri, 28 May 2010 13:08:38 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: matthieu.vial@fr.non.schneider-electric.com References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070209000403000202080409" Cc: core-bounces@ietf.org, core Subject: Re: [core] Subscribe/Notify for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 12:09:05 -0000 This is a cryptographically signed message in MIME format. --------------ms070209000403000202080409 Content-Type: multipart/alternative; boundary="------------050101090105090201020407" This is a multi-part message in MIME format. --------------050101090105090201020407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Matthieu, I am not sure what you mean here. Do you mean that some other client can = subscribe to be notified whenever some method is acted upon for a=20 particular resource? Can you describe the transaction model? Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 28/05/2010 12:51 PM, matthieu.vial@fr.non.schneider-electric.com wrote= : > > > So strictly speaking, both NOTIFY and SUBSCRIBE are message types=20 > not methods! > > SUBSCRIBE can be just an asynchronous GET on update then I think it is = > a method and NOTIFY is an asynchronous response so a message. > But if we want to have selective notifications when a resource is=20 > created, updated or deleted then I think you're right NOTIFY and=20 > SUBSCRIBE are messages. > > Does that make sense ? > > Matthieu > > Inactive hide details for "Adriano Pezzuto (apezzuto)"=20 > "Adriano Pezzuto (apezzuto)" > > > > > *"Adriano Pezzuto (apezzuto)" > * > Envoy=E9 par : core-bounces@ietf.org > > 28/05/2010 12:50 > > =09 > > A > =09 > > > cc > =09 > core > > Objet > =09 > Re: [core] Subscribe/Notify for CoAP > > =09 > > > Hi Roberto, > I understand your point and personally agree on M2M is quite different = > from web page model. On the architectural RESTful style, the method=20 > information tells the server what to do with data kept in the URI=20 > information. > > So strictly speaking, both NOTIFY and SUBSCRIBE are message types not=20 > methods! > > Adriano > > *From:* Robert Cragie [mailto:robert.cragie@gridmerge.com] * > Sent:* venerd=EC 28 maggio 2010 11.53* > To:* Adriano Pezzuto (apezzuto)* > Cc:* Paul Duffy (paduffy); Zach Shelby; core* > Subject:* Re: [core] Subscribe/Notify for CoAP > > I think the point here is that there are two levels we are considering.= > > At the lowest (foundation) level, there are the transaction messages=20 > as described below. This provides a flexible mechanism for the=20 > application with regard to synchronicity and threading. This is=20 > important for the types of devices CoAP is being aimed at. > > Above that, the methods can be used according to the architectural=20 > style. So in this case, it is RESTful (COnstrained Restful=20 > Environments), which will naturally limit the number of methods and=20 > how transactions occur. > > The actual architecture using a combination of the methods and=20 > messages also depends on what is required at the application layer.=20 > Consider a typical client which wants to subscribe to a resource. That = > client controls the feed of data but needs a component which is=20 > capable of handling (possibly buffering) the data it receives through=20 > notifications. Is this a separate server? Or would we want to consider = > it part of an enhanced client model which is able to process feeds of=20 > data? These are the sort of models which have led to the myriad of=20 > solutions (GENA, Webhooks, long polling, pubsubhubbub, RESTMS etc.)=20 > based around HTTP which are all essentially ingenious ways of getting=20 > around the limitations imposed by HTTP and how it is processed for=20 > anything which deviates from the classic web page access model. > > I think the aim of CoAP should be clean from the word go with regard=20 > to supporting these more peer-to-peer transactions, where the client=20 > can exist on either entity and both entities can feed data to each=20 > other; typical in M2M applications. > > Robert > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 1924 910888 > +1 415 513 0064_ > __http://www.gridmerge.com_ > > On 27/05/2010 7:08 PM, Adriano Pezzuto (apezzuto) wrote: > Hi Robert, > > in my personal opinion, the option 1a) brings some sort of ambiguity=20 > to CoAP specs. > > My be my understatement of new CoAP specs is not so deep, but now we=20 > have 5 methods and 3 message types: request, response and notify.=20 > Which methods are allowed with which messages types? > I suppose you have to use PUT/POST method with notify message for=20 > asynch data notification. How to make a subscribe? I suppose you would = > use a SUBSCRIBE method with request/response message or SUBSCRIBE with = > notify message? Also what about POST/DELETE methods in a notify=20 > message? They not make any sense.. > > I think the choice is between: option 1) -> only CRUD methods and=20 > option 1b) -> CRUD + SUB/NOTIFY methods, keeping in mind cost/benefits = > of both solutions. > > Adriano > > *From:* Robert Cragie [_mailto:robert.cragie@gridmerge.com_] * > Sent:* mercoled=EC 26 maggio 2010 20.09* > To:* Adriano Pezzuto (apezzuto)* > Cc:* Paul Duffy (paduffy); Zach Shelby; core* > Subject:* Re: [core] Subscribe/Notify for CoAP > > Hi Adrian, > > I would also prefer to keep the protocol in CoAP asynchronous. You can = > always map an asynchronous protocol to a synchronous one but, as we=20 > see in HTTP, it always ends up as a kludge to do it the other way=20 > round. The efforts which have been gone to to make HTTP=20 > quasi-asynchronous via all the schemes mentioned below and many more=20 > besides (all non-interoperable of course) is testament to how=20 > important this is for M2M communication. > > So, back to Zach's list, I favor 1a) for the following reasons: > > Foundation level of messages: > > 1. request/response can be asynchronous or synchronous messages > (as there is a transaction ID in there) > 2. notify is an asynchronous message=20 > > Derived methods: > > I think it makes sense to add a pub/sub model as a useful mechanism=20 > for M2M. > > So, looking at it the other way round: It will be entirely possible to = > translate whatever is currently built on HTTP to CoAP based on the=20 > above, with all its restrictions regarding synchronous and=20 > client/server transactions. What may be harder is to translate=20 > directly is a CoAP-based application to HTTP. So I guess the question=20 > is: Do we want to be hamstrung to synchronous client/server=20 > transactions as dictated by HTTP and provide a direct mapping to HTTP, = > then have to come up with similar kludges for asynchronous=20 > peer-to-peer transactions as has been done in numerous ways for HTTP,=20 > or do we want to define the protocol cleanly to start with and accept=20 > that some sort of transaction relaying/conversion would have to take=20 > place at a mapping node? > > Robert > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 1924 910888 > +1 415 513 0064_ > __http://www.gridmerge.com_ > > On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote: > Hi, > it looks to me that CoAP should use an explicit sub/notify mechanism=20 > since this is the core of the machine-to-machine interaction model. > HTTP suffers of this lack and we have seen a plethora of solutions to=20 > give an asynch taste to it. Webhooks and websockets are only the lasts = > of the list. > As someone has already pointed out on this list, it is theoretically=20 > possible to describe sub/notify using only CRUD methods but it looks a = > little bit tricky and verbose. > > Now we have a chance to build from scratch a new protocol with and I=20 > think using explicit sub/notify methods with a clear and well defined=20 > semantic is the best option. It is easily understanding from every=20 > developer and will prevent to build other fanny solutions on top of=20 > the CoAP. HTTP does not have this well defined semantic and (for=20 > hundreds of other reasons also) it is not used as wide protocol for=20 > machine-to-machine communication. > > CoAP - as binary protocol - and with an explicit asynch model has a=20 > chance to be a really wide protocol for M2M communication not only for = > constrained environments. > > my 2 cents > > - adriano > > -----Original Message----- > From: _core-bounces@ietf.org_ =20 > [_mailto:core-bounces@ietf.org_] On Behalf Of Paul Duffy (paduffy) > Sent: mercoled=EC 26 maggio 2010 0.47 > To: Zach Shelby > Cc: core > Subject: Re: [core] Subscribe/Notify for CoAP > > On 5/25/2010 6:41 PM, Zach Shelby wrote: > > Hi, > > On May 26, 2010, at 12:23 AM, Charles Palmer wrote: > > > Hi folks > > It occurs to me that CoRE should be keeping a > close eye on ZigBee SE2.0 work, so that it is > as easy as possible for ZigBee SE to use CoRE > when ready. That suggests to me that we should > align with their subscribe/notify process. > > > I am not sure I understand that. I mean, ZigBee SE2.0 is > defining an application specific subscribe/notify > mechanism for that purpose so far for HTTP. This uses > standard HTTP methods and some custom payload and REST > interfaces. CoAP Req/Res is already totally compatible > with SE2.0 in that respect, so alignment is already OK > there. Nothing stopping someone from using SE2.0 over CoAP.= > > Specifying a native susbcription/notify into CoAP is > another matter. We can't adopt a solution specific to one > application as that won't solve the problems of other > applications nor general HTTP mapping at all (probably > would make it worse). It seems that for the near future > there will be a bunch of HTTP push mechanisms in use > without any clear standard appearing - or am I wrong there?= > > > > > If COAP extends HTTP semantics with new subscription methods, it will > not be possible to easily interchange HTTP/COAP, and translation > gateways will become more complex to implement. > > > > Zach > > > Regards - Charles > > > -----Original Message----- > From: _core-bounces@ietf.org_ > > [_mailto:core-bounces@ietf.org_] On Behalf Of > Paul Duffy > Sent: 25 May 2010 03:48 > To: Zach Shelby > Cc: core > Subject: Re: [core] Subscribe/Notify for CoAP > > Recommend something like #2, primarily to > avoid introducing non HTTP > method semantics, simplifying HTTP/COAP > translation.gateways, etc. > > > On 5/24/2010 11:49 AM, Zach Shelby wrote: > > (thread renamed) > > We have two different paths with > regard to a subscribe/notify > mechanism for CoAP: > > 1. Use specific Subscription and > Notify mechanisms for CoAP as HTTP > really does not include this concep= t. > 1a) Notify as a message and > SUBSCRIBE as a method. This is > currently used in coap-01. > 1b) NOTIFY and SUBSCRIBE as > methods. This was used in coap-00, > but we had a good list discussion > about this leading to a. In > practice it doesn't make a big > difference if notification is a > message or method. > > 2. Use an HTTP specific framework > such as Webhooks, the ZigBee SE2.0 > proposal or GENA. > > So far we have focused on 1 in the > WG, and every now and again 2 > comes up. At least I am not > convinced that we need to suffer > the drawbacks of HTTP here. > Anyways 2 does not help our > mapping to HTTP in reality very > much as there is no standard way > of doing this over HTTP. Thus a > CoAP-HTTP proxy may end up anyways > translating between multiple HTTP > frameworks depending on the > application. So instead of doing a > CoAP Notify/Subscribe to Webhooks > mapping, you will could end up > having to do a CoAP Webhooks to > HTTP GENA mapping. > > > > I don't understand this last para. If CoAP > sticks to the semantics of > the current HTTP methods, would this not offer > a fairly straightforward > translation to/from HTTP? > > > > From what I have heard > so far 1 still seems > like a wise choice, > although I need to > look at Webhooks more > deeply. In reality > many applications > specify their own way > of doing a push > interface using REST > methods and specific > payloads (ZigBee SE2.0 > is such an example). > That is just fine, and > might be used instead > of a specific CoAP > notify/subscribe in > that case. So 1 > doesn't prevent the > application using its > own mechanism, it just > provides a native way > for doing push. > > What do people think? > > Zach > > On May 17, 2010, at 6:44 PM, > _matthieu.vial@fr.non.schneider-ele= ctric.com_ > > wrote: > > > > Hi, > > My comments about the > subscribe/notify > mechanism of Zigbee IP.= > > Pros: > - Derived from the > webhooks concept > - If used by CORE it > will be easier to map > to HTTP because it > uses only CRUD verbs. > - The subscription > message is extendable > and could support > advanced options > (delays, increment, ...= ) > - Only one listening > port whatever the > transport binding is. > > Cons: > - No interoperability > without well known > URIs and a well > defined subscription > message format (Not > sure CoAP draft is the > right place to specify > this). > - XML/EXI is too > complex to be the > required format for > the default > subscription/notificati= on > mechanism. > - The notification > should not require a > subsequent GET to > retrieve the content. > - Subresource > subscription is redunda= nt. > > Hope this could help, > Matthieu > > > "Charles > Palmer"__ > > > > > > "Charles > Palmer"__ > > Envoy=E9 par : > _core-bounces@ietf.org_= > 15/05/2010 14:06 > > > A > > "core"__= > > cc > > > Objet > > Re: [core] Selecting a > WG document for CoAP > > > > Dear all > > Those interested in > the subscribe/notify > discussion might like > to look > at the draft Smart > Energy Profile 2.0 > Application Protocol > Specification. It is > available here: > _http://zigbee.org/Mark= ets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicApp_ > licationProfile.aspx > > It manages > subscribe/notify by > using POST. This seems > to remove the need > for SUBSCRIBE and notif= y. > > "Imagine a host A, > which exposes a > resource at > http{s}://A/resource an= d > a second host B, which > wishes to learn of > changes to this > resource. To > facilitate a > subscription/ > notification > mechanism, A would > expose a > resource > http{s}://A/sub and B > would expose a > resource http{s}://B/nt= fy. > To subscribe to > notifications > regarding > http{s}://A/resource, > B would > send a POST to the > address > http{s}://A/sub/B > containing the URI of t= he > resource of interest > (http{s}://A/resource) > and the URI of B's > notification resource > (http{s}://B/ntfy). > Following this > subscription > step, should A wish to > notify B of a change > to the resource > addressed at > http{s}://A/resource, > A would send a POST to > the address > http{s}://B/ntfy > containing the URI of > the resource changed > (http{s}://A/resource) > and the URI of A's > subscription resource > (http{s}://A/sub/B), > should A wish to > change its > subscription. The host > B can then query the > resource (or not) at > its leisure." > > Sleepy nodes are not > allowed to subscribe, > and must poll. > > Regards - Charles Palme= r > > -----Original Message--= --- > From: > _core-bounces@ietf.org_= > [_mailto:core-bounces@i= etf.org_] > On Behalf Of > Angelo P. Castellani > Sent: 14 May 2010 13:14= > To: Zach Shelby > Cc: core > Subject: Re: [core] > Selecting a WG > document for CoAP > > Zach, > > thanks for the > comments, but please > refer to my most > recent e-mail for > a more specific list > of technical issues > I'm pointing to. > > I want to do only a > little integration to > what I've written there= =2E > > In my very personal > opinion, to maximize > adherence with the > REST model > and minimize > implementation effort > SUBSCRIBE and NOTIFY > should be > mapped to methods (as > discussed many times > together...). > > Uniform interface > principle (Fielding > PhD dissertation > Section 5.1.5, > "The central feature > that distinguishes the > REST architectural styl= e > [...]") states that to > simplify the software > architecture, resource > interfaces/interfaces > should be as general > as possible. > > I agree with this > principle in this > specific case, mainly > because > handling a special > message type for > notify leads node > software design > to a more complex > architecture. > > The reason is that > this new message type > requires special > handling and > introduces a > complexity in the > software modularization= =2E > > Best, > Angelo > > On Fri, May 14, 2010 > at 13:06, Zach > Shelby__ > > wrote: > > > Hi Angelo, > > On May 13, > 2010, at > 14:24 , > Angelo P. > Castellani > wrote: > > > > = Dear > = C. > = Bormann, > = all, > > = before > = deciding > = for > = the > = final > = direction, > = I've > = the > = following > = observations > = about > = draft-shelby-core-coap-01 > > = While > = I mostly > = share > = Zach's > = view > = of > = the > = protocol > = approach, > = and > = appreciate > = many > = aspects > = of > = the > = proposal, > = there > = are > = in > = my > = opinion > > > still > > > = some > = open > = issues > = that > = need > = to > = be > = at > = least > = discussed > = before > = the > > > current > > > = document > = can > = be > = selected. > > > Of course > there are > plenty of > open > issues. > Remember > that > working gro= up > > > documents still > undertake as much > change and improvement > as the WG > wants, so by no means > is coap-01 set in > stone. I would expect > at least > 5-10 more revisions > still along the way. > Already several of > your ideas > have been integrated > into coap-01, and > several more are under > consideration, so it > is coming along. > Patience ;-) > > > > = In > = particular, > = I would > = like > = to > = highlight > = the > = following: > > = a) > = As > = it > = is > = now, > = it > = is > = not > = possible > = to > = have > = a straightforward > = translation > = of > = HTTP > = -> > = CoAP > = and > = viceversa: > = see > = _http://www.ietf.org/mail-archive/web/core/current/msg00133.html_ > = (this > = impacts > = the > = scalability > = of > = the > = web > = service > = model > = too) > > > In coap-01 > the Method > names are > now > identical > to HTTP > methods. Th= e > > > Req/Res interaction is > a direct translation. > The URI hierarchy is > compatible, and the > URI binary code format > we are still working on= > obviously. The only > thing that takes some > state to translate is > Subscribe/Notify. But > note, Subscribe/Notify > takes some state no mat= ter > how you do it, even > with HTTP-HTTP there > is no clean and easy > way to > handle subscriptions. > > > > = b) > = Moreover, > = CoAP's > = implementation > = is > = not > = as > = simple > = as > = it > = should > = be. > = I've > = investigated > = the > = implementation > = and > = some > = design > = choices > = (as > = Options) > = are > = leading > = to > = very > = high > = program > = complexity > = (ROM) > = on > = a > = MSP430-based > = device. > > > This we > can > definitely > improve, > and > already > made > several > optimizatio= ns > > > from -00 to -01. Here > I need some very > concrete proposals > though. Also > remember that many > things are optional, > for example > subscribe/notify is > not required if you > don't need it. > > > > = c) > = Finally > = when > = comparing > = HTTP > = message > = size > = with > = CoAP > = message > = size, > = the > = resulting > = compression > = isn't > = as > = good > = as > = you > = may > = expect. > > = Example: > = HTTP: > = GET > = /sensor/temp.xml > = HTTP/1.0 > = =3D 32 > = B > = CoAP: > = 24 > = B with > = options > = parsing > = procedure > = requiring > = an > = added > = implementation > = complexity > > > Right, > that is > not how it > will work > in > practice. > Working > with a real= > > > HTTP server that HTTP > header will be more > complex, and on the > CoAP side > you would chose > shorter URLs. The > biggest improvement > possible here is > from using binary > coded URLs of course. > We need to look at a > wider range > of interactions and > real HTTP headers as > well to check that we a= re > efficient enough. > > > > = Addressing > = all > = these > = points > = potentially > = leads > = to > = major > = technical > = modifications > = (especially > = point > = a) > = on > = the > = current > = draft, > = hence > = it > = is > = appropriate > = in > = my > = opinion > = to > = discuss > = these > = points > = before > = making > = the > = final > = decision. > > > I am not > sure what > else you > have in > mind for > a). If we > just forget= > > > about Subscribe/Notify > then you are good to > go. But then you are al= so > not fulfilling the > charter or the > industry needs in that > respect. > > > Thanks, > Zach > > > > = Best > = regards, > > = Angelo > = P. > = Castellani > > > = On > = Mon, > = May > = 10, > = 2010 > = at > = 18:51, > = Carsten > = Bormann__ > = > = wrote: > > > = The > = CORE > = WG > = has > = a milestone > = to > = select > = a WG > = document > = for > = CoAP > = in > > > April: > > > = _http://datatracker.ietf.org/wg/core/charter/_ > = ... > = Apr > = 2010 > = Select > = WG > = document > = for > = basis > = of > = the > = CoAP > = protocol > > = Of > = the > = various > = documents > = that > = have > = been > = contributed, > > > draft-shelby-core-coap > has significant > discussion, as well as = the > largest number of > updates (including a > previous version that > was still > called -6lowapp-coap). > > > = Today, > = another > = updated > = version > = of > = that > = draft > = was > = announced. > = See > = _http://www.ietf.org/mail-archive/web/core/current/msg00138.= html_ > = for > = the > = announcement > = and > = _http://tools.ietf.org/html/draft-shelby-core-coap-01_ > = for > = the > = draft > = itself. > > = However, > = as > = the > = authors > = say, > = there > = are > = still > = significant > = TODOs. > > = Are > = we > = in > = a state > = yet > = where > = we > = can > = say > = whether > = this > = is > = the > = right > > > direction for the WG > to take? > > > = If > = yes, > = is > = it > = the > = right > = direction? > = Should > = we > = adopt > = it > = as > = a WG > > > document? > > > = If > = you > = don't > = think > = we > = can > = say > = yet, > = is > = there > = a set > = of > = technical > > > decisions you would > like the authors to > take with priority? > > > = Note > = that > = once > = a document > = has > = become > = a WG > = document, > = the > = authors > = act > > > as editors for the > working group, making > (and usually fleshing > out the > details of) any change > that the WG decides it > needs. > > > = If > = you > = think > = we > = can > = still > = improve > = the > = draft, > = this > = is > = not > = an > = obstacle > > > to making it a WG > document. > > > = But > = of > = course > = we > = shouldn't > = do > = that > = if > = we > = intend > = to > = reverse > = its > > > fundamental technical > direction. > > > = In > = order > = to > = stay > = roughly > = in > = sync > = with > = our > = milestones, > = we > = should > > > reach at a decision on > how to go forward this > week. > > > = Gruesse, > = Carsten > > = _______________________________________________ > = core > = mailing > = list > = _core@ietf.org_ > = > = _https://www.ietf.org/mailman/listinfo/core_ > > > > = _______________________________________________ > = core > = mailing > = list > = _core@ietf.org_ > = > = _https://www.ietf.org/mailman/listinfo/core_ > > > -- > Zach > Shelby, > Chief > Nerd, > Sensinode L= td. > _http://zac= hshelby.org_ > > - My blog > "On the > Internet > of > Things_"_ > > _http://6lo= wpan.net > - My book > "_ > 6LoWPAN: > The > Wireless > Embedded > Internet" > Mobile: > +358 40 > 7796297 > > > > > _______________________= ________________________ > core mailing list > _core@ietf.org_ > > _https://www.ietf.org/m= ailman/listinfo/core_ > > -----------------------= --------- > Onzo is a limited > company number > 06097997 registered in > England& Wales. The > registered office is 6 > Great Newport Street, > London, WC2H 7JB, > United Kingdom. > > This email message may > contain confidential > and/or privileged > information, and > is intended solely for > the addressee(s). If > you have received this > email in > error, please notify > Onzo immediately. > Unauthorised copying, > disclosure or > distribution of the > material in this email > is forbidden. > -----------------------= --------- > > _______________________= ________________________ > core mailing list > _core@ietf.org_ > > _https://www.ietf.org/m= ailman/listinfo/core_ > > _______________________= _______________________________________________ > This email has been > scanned by the > MessageLabs Email > Security System. > _______________________= _______________________________________________ > > _______________________= ________________________ > core mailing list > _core@ietf.org_ > > _https://www.ietf.org/m= ailman/listinfo/core_ > > > > _______________________________________________= > core mailing list > _core@ietf.org_ > _https://www.ietf.org/mailman/listinfo/core_ > > -------------------------------- > Onzo is a limited company number 06097997 > registered in England& Wales. The > registered office is 6 Great Newport Street, > London, WC2H 7JB, United Kingdom. > > This email message may contain confidential > and/or privileged information, and > is intended solely for the addressee(s). If > you have received this email in > error, please notify Onzo immediately. > Unauthorised copying, disclosure or > distribution of the material in this email is > forbidden. > -------------------------------- > > > > > _______________________________________________ > core mailing list > _core@ietf.org_ > _https://www.ietf.org/mailman/listinfo/core_ > _______________________________________________ > core mailing list > _core@ietf.org_ > _https://www.ietf.org/mailman/listinfo/core_ > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > _______________________________________________________________________= ______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --------------050101090105090201020407 Content-Type: multipart/related; boundary="------------040709040507000808040401" --------------040709040507000808040401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Matthieu,

I am not sure what you mean here. Do you mean that some other client can subscribe to be notified whenever some method is acted upon for a particular resource? Can you describe the transaction model?

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com


On 28/05/2010 12:51 PM, matthieu.vial@fr.non.sch= neider-electric.com wrote:

> So strictly= speaking, both NOTIFY and SUBSCRIBE are message types not  methods!<= /font>

SUBSCRIBE can be just an asynchronous GET on update then I think it is a method and NOTIFY is an asynchronous response so a message.
But if we want to have selective notifications when a resource is created, updated or deleted then I think you're right NOTIFY and SUBSCRIBE are messages.

Does that make sense ?

Matthieu

3D"Inactive"Adriano Pezzuto (apezzuto)" <= ;apezzuto@cisco.com>




=
3D""
A
 3D""
<robert.cragie@gridmerge.com><= /a>
3D""
cc
 3D""
core <core@ietf.org>
3D""
Objet
 3D""
Re: [core] Subscribe/Notify for CoAP
3D"" 3D""

Hi Roberto,<= br> I understand your p= oint and personally agree on M2M is quite different from web page model. On the architectural RESTful style, the method information tells the server what to do with data kept in the URI information.

So strictly speakin= g, both NOTIFY and SUBSCRIBE are message types not  methods!
=
Adriano
=
From: Robert Cragie [mailto:robert.cragie@gridmer= ge.com]
Sent: venerdì 28 maggi= o 2010 11.53
To: Adriano Pezzuto (apezzuto= )
Cc: Paul Duffy (paduffy); Zac= h Shelby; core
Subject: Re: [core] Subscribe/Notify for CoAP

I think the point here is tha= t there are two levels we are considering.

At the lowest (foundation) level, there are the transaction messages as described below. This provides a flexible mechanism for the application with regard to synchronicity and threading. This is important for the types of devices CoAP is being aimed at.

Above that, the methods can be used according to the architectural style. So in this case, it is RESTful (COnstrained Restful Environments), which will naturally limit the number of methods and how transactions occur.

The actual architecture using a combination of the methods and messages also depends on what is required at the application layer. Consider a typical client which wants to subscribe to a resource. That client controls the feed of data but needs a component which is capable of handling (possibly buffering) the data it receives through notifications. Is this a separate server? Or would we want to consider it part of an enhanced client model which is able to process feeds of data? These are the sort of models which have led to the myriad of solutions (GENA, Webhooks, long polling, pubsubhubbub, RESTMS etc.) based around HTTP which are all essentially ingenious ways of getting around the limitations imposed by HTTP and how it is processed for anything which deviates from the classic web page access model.

I think the aim of CoAP should be clean from the word go with regard to supporting these more peer-to-peer transactions, where the client can exist on either entity and both entities can feed data to each other; typical in M2M applications.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com

On 27/05/2010 7:08 PM, Adriano Pezzuto (apezzuto) wrote:
Hi Robert,
in my personal opin= ion, the option 1a) brings some sort of ambiguity to CoAP specs.

My be my understate= ment of new CoAP specs is not so deep, but now we have 5 methods and 3 message types: request, response and notify. Which methods are allowed with which messages types?
I suppose you have = to use PUT/POST method with notify message for asynch data notification. How to make a subscribe? I suppose you would use a SUBSCRIBE method with request/response message or SUBSCRIBE with notify message? Also what about POST/DELETE methods in a notify message? They not make any sense..

I think the choice = is between: option 1) -> only CRUD methods and option 1b) -> CRUD + SUB/NOTIFY methods, keeping in mind cost/benefits of both solutions.

Adriano

From: Robert Cragie [mailto:robert.cragie@gridmerge.com] =
Sent: mercoledì 26 mag= gio 2010 20.09
To: Adriano Pezzuto (apezzuto= )
Cc: Paul Duffy (paduffy); Zac= h Shelby; core
Subject: Re: [core] Subscribe/Notify for CoAP

Hi Adrian,

I would also prefer to keep the protocol in CoAP asynchronous. You can always map an asynchronous protocol to a synchronous one but, as we see in HTTP, it always ends up as a kludge to do it the other way round. The efforts which have been gone to to make HTTP quasi-asynchronous via all the schemes mentioned below and many more besides (all non-interoperable of course) is testament to how important this is for M2M communication.

So, back to Zach's list, I favor 1a) for the following reasons:

Foundation level of messages:

    1. request/response can be asynchronous or synchronous messages (as there is a transaction ID in there)
    2. notify is an asynchronous message
Derived methods:

I think it makes sense to add a pub/sub model as a useful mechanism for M2M.

So, looking at it the other way round: It will be entirely possible to translate whatever is currently built on HTTP to CoAP based on the above, with all its restrictions regarding synchronous and client/server transactions. What may be harder is to translate directly is a CoAP-based application to HTTP. So I guess the question is: Do we want to be hamstrung to synchronous client/server transactions as dictated by HTTP and provide a direct mapping to HTTP, then have to come up with similar kludges for asynchronous peer-to-peer transactions as has been done in numerous ways for HTTP, or do we want to define the protocol cleanly to start with and accept that some sort of transaction relaying/conversion would have to take place at a mapping node?

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com

On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote:
Hi,
it looks to me that CoAP should u= se an explicit sub/notify mechanism since this is the core of the machine-to-machine interaction model.
HTTP suffers of this lack and we have seen a plethora of solutions to give an asynch taste to it. Webhooks and websockets are only the lasts of the list.
As someone has already pointed ou= t on this list, it is theoretically possible to describe sub/notify using only CRUD methods but it looks a little bit tricky and verbose.
Now we have a chance to build fro= m scratch a new protocol with and I think using explicit sub/notify methods with a clear and well defined semantic is the best option. It is easily understanding from every developer and will prevent to build other fanny solutions on top of the CoAP. HTTP does not have this well defined semantic and (for hundreds of other reasons also) it is not used as wide protocol for machine-to-machine communication.

CoAP - as binary protocol - and with an explicit asynch model has a chance to be a really wide protocol for M2M communication not only for constrained environments.

my 2 cents

- adriano

-----Original Message-----=
From: core-bounces@ietf.org<= /font> [mailto:core-bounces@ietf.org] On Behalf Of Paul Duffy (paduffy)
Sent: mercoledì 26 maggio = 2010 0.47
To: Zach Shelby
Cc: core
Subject: Re: [core] Subscribe/Notify for CoAP

On 5/25/2010 6:41 PM, Zach Shelby= wrote:

      Hi,

      On May 26, 2010, at 12:23 AM,= Charles Palmer wrote:


          Hi folks

          It occurs to me that CoRE= should be keeping a close eye on ZigBee SE2.0 work, so that it is as easy as possible for ZigBee SE to use CoRE when ready. That suggests to me that we should align with their subscribe/notify process.


      I am not sure I understand that. I mean, ZigBee SE2.0 is defining an application specific subscribe/notify mechanism for that purpose so far for HTTP. This uses standard HTTP methods and some custom payload and REST interfaces. CoAP Req/Res is already totally compatible with SE2.0 in that respect, so alignment is already OK there. Nothing stopping someone from using SE2.0 over CoAP.

      Specifying a native susbcription/notify into CoAP is another matter. We can't adopt a solution specific to one application as that won't solve the problems of other applications nor general HTTP mapping at all (probably would make it worse). It seems that for the near future there will be a bunch of HTTP push mechanisms in use without any clear standard appearing - or am I wrong there?




If COAP extends HTTP semantics wi= th new subscription methods, it will
not be possible to easily interchange HTTP/COAP, and translation
gateways will become more complex= to implement.



      Zach


          Regards - Charles<= br>

          -----Original Message----= -
          From: core-bounces@ietf.org<= /font> [mailto:core-bounces@ietf.org] On Behalf Of Paul Duffy
          Sent: 25 May 2010 03:48
          To: Zach Shelby Cc: core
          Subject: Re: [core] Subscribe/Notify for CoAP

          Recommend something like #2, primarily to avoid introducing non HTTP
          method semantics, simplifying HTTP/COAP translation.gateways, etc.


          On 5/24/2010 11:49 AM, Za= ch Shelby wrote:

              (thread renamed)

              We have two different= paths with regard to a subscribe/notify mechanism for CoAP:

              1. Use specific Subscription and Notify mechanisms for CoAP as HTTP really does not include this concept.
              1a) Notify as a messa= ge and SUBSCRIBE as a method. This is currently used in coap-01.
              1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but we had a good list discussion about this leading to a. In practice it doesn't make a big difference if notification is a message or method.

              2. Use an HTTP specif= ic framework such as Webhooks, the ZigBee SE2.0 proposal or GENA.
              =
              So far we have focuse= d on 1 in the WG, and every now and again 2 comes up. At least I am not convinced that we need to suffer the drawbacks of HTTP here. Anyways 2 does not help our mapping to HTTP in reality very much as there is no standard way of doing this over HTTP. Thus a CoAP-HTTP proxy may end up anyways translating between multiple HTTP frameworks depending on the application. So instead of doing a CoAP Notify/Subscribe to Webhooks mapping, you will could end up having to do a CoAP Webhooks to HTTP GENA mapping.



          I don't understand this last para. If CoAP sticks to the semantics of
          the current HTTP methods,= would this not offer a fairly straightforward
          translation to/from HTTP?=



                  From what I have= heard so far 1 still seems like a wise choice, although I need to look at Webhooks more deeply. In reality many applications specify their own way of doing a push interface using REST methods and specific payloads (ZigBee SE2.0 is such an example). That is just fine, and might be used instead of a specific CoAP notify/subscribe in that case. So 1 doesn't prevent the application using its own mechanism, it just provides a native way for doing push.

              What do people think?=

              Zach

              On May 17, 2010, at 6:44 PM, matthieu.vial@fr.non.s= chneider-electric.com wrote:



                  Hi,

                  My comments about= the subscribe/notify mechanism of Zigbee IP.

                  Pros:
                  - Derived from th= e webhooks concept
                  - If used by CORE= it will be easier to map to HTTP because it uses only CRUD verbs.<= br> - The subscriptio= n message is extendable and could support advanced options (delays, increment, ...)
                  - Only one listening port whatever the transport binding is.

                  Cons:
                  - No interoperability without well known URIs and a well defined subscription message format (Not sure CoAP draft is the right place to specify this).
                  - XML/EXI is too complex to be the required format for the default subscription/notification mechanism.
                  - The notificatio= n should not require a subsequent GET to retrieve the content.
                  - Subresource subscription is redundant.

                  Hope this could help,
                  Matthieu

                  <graycol.gif&g= t;"Charles Palmer"<charles.palmer@onzo.com>




                  "Charles Palmer"<= /font><charles.palmer@onz= o.com>
                  Envoyé par= : core-bounces@ietf.org<= /font>
                  15/05/2010 14:06<= /font>

                  <ecblank.gif&g= t;
                  A
                  <ecblank.gif&g= t;
                  "core"<core@ietf.org><= /a>
                  <ecblank.gif&g= t;
                  cc
                  <ecblank.gif&g= t;
                  <ecblank.gif&g= t;
                  Objet
                  <ecblank.gif&g= t;
                  Re: [core] Selecting a WG document for CoAP
                  <ecblank.gif&g= t; <ecblank.gif>

                  Dear all
                  Those interested = in the subscribe/notify discussion might like to look
                  at the draft Smar= t Energy Profile 2.0 Application Protocol
                  Specification. It= is available here:
                  http://zigbee.org/Mark= ets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicApp
                  licationProfile.a= spx

                  It manages subscribe/notify by using POST. This seems to remove the need
                  for SUBSCRIBE and= notify.

                  "Imagine a host A= , which exposes a resource at http{s}://A/resource and
                  a second host B, which wishes to learn of changes to this resource. To
                  facilitate a subscription/ notification mechanism, A would expose a
                  resource http{s}://A/sub and B would expose a resource http{s}://B/ntfy. To subscribe to notifications regarding http{s}://A/resource, B would
                  send a POST to th= e address http{s}://A/sub/B containing the URI of the
                  resource of interest (http{s}://A/resource) and the URI of B's
                  notification resource (http{s}://B/ntfy). Following this subscription
                  step, should A wi= sh to notify B of a change to the resource addressed at
                  http{s}://A/resou= rce, A would send a POST to the address
                  http{s}://B/ntfy containing the URI of the resource changed
                  (http{s}://A/reso= urce) and the URI of A's subscription resource
                  (http{s}://A/sub/= B), should A wish to change its subscription. The host
                  B can then query the resource (or not) at its leisure."

                  Sleepy nodes are not allowed to subscribe, and must poll.

                  Regards - Charles= Palmer

                  -----Original Message-----
                  From: core-bounces@ietf.org<= /font> [mailto:core-bounces@ietf.org] On Behalf Of
                  Angelo P. Castell= ani
                  Sent: 14 May 2010= 13:14
                  To: Zach Shelby
                  Cc: core Subject: Re: [cor= e] Selecting a WG document for CoAP

                  Zach,

                  thanks for the comments, but please refer to my most recent e-mail for
                  a more specific list of technical issues I'm pointing to.

                  I want to do only= a little integration to what I've written there.

                  In my very person= al opinion, to maximize adherence with the REST model
                  and minimize implementation effort SUBSCRIBE and NOTIFY should be
                  mapped to methods= (as discussed many times together...).

                  Uniform interface= principle (Fielding PhD dissertation Section 5.1.5,
                  "The central feature that distinguishes the REST architectural style
                  [...]") states th= at to simplify the software architecture, resource
                  interfaces/interf= aces should be as general as possible.

                  I agree with this= principle in this specific case, mainly because
                  handling a specia= l message type for notify leads node software design
                  to a more complex= architecture.

                  The reason is tha= t this new message type requires special handling and
                  introduces a complexity in the software modularization.

                  Best,
                  Angelo
                  =
                  On Fri, May 14, 2010 at 13:06, Zach Shelby<zach@sensinode.com> wrote:


                      Hi Angelo,

                      On May 13, 2010, at 14:24 , Angelo P. Castellani wrote:



                          Dear C. Bormann, all,
                          <= br> before deciding for the final direction, I've the following
                          observati= ons about draft-shelby-core-coap-01
                          <= br> While I mostly share Zach's view of the protocol approach, and
                          appreciat= e many aspects of the proposal, there are in my opinion
                          <= br> <= br>
                  still


                          some open= issues that need to be at least discussed before the
                          <= br> <= br>
                  current

                          document can be selected.
                          <= br> <= br>
                      Of course the= re are plenty of open issues. Remember that working group


                  documents still undertake as much change and improvement as the WG
                  wants, so by no means is coap-01 set in stone. I would expect at least
                  5-10 more revisio= ns still along the way. Already several of your ideas
                  have been integrated into coap-01, and several more are under
                  consideration, so= it is coming along. Patience ;-)



                      In coap-01 th= e Method names are now identical to HTTP methods. The


                  Req/Res interacti= on is a direct translation. The URI hierarchy is
                  compatible, and t= he URI binary code format we are still working on
                  obviously. The on= ly thing that takes some state to translate is
                  Subscribe/Notify.= But note, Subscribe/Notify takes some state no matter
                  how you do it, ev= en with HTTP-HTTP there is no clean and easy way to
                  handle subscriptions.



                          b) Moreover, CoAP's implementation is not as simple as it should be.<= br> I've investigated the implementation and some design choices (as
                          Options) are leading to very high program complexity (ROM) on a
                          MSP430-ba= sed device.
                          <= br> <= br>
                      This we can definitely improve, and already made several optimizations


                  from -00 to -01. Here I need some very concrete proposals though. Also
                  remember that man= y things are optional, for example subscribe/notify is
                  not required if y= ou don't need it.



                          c) Finall= y when comparing HTTP message size with CoAP message size,
                          the resulting compression isn't as good as you may expect.
                          <= br> Example:<= /font>
                          HTTP: GET= /sensor/temp.xml HTTP/1.0 =3D 32 B
                          CoAP: 24 = B with options parsing procedure requiring an added
                          implement= ation complexity
                          <= br> <= br>
                      Right, that i= s not how it will work in practice. Working with a real


                  HTTP server that HTTP header will be more complex, and on the CoAP side
                  you would chose shorter URLs. The biggest improvement possible here is
                  from using binary= coded URLs of course. We need to look at a wider range
                  of interactions a= nd real HTTP headers as well to check that we are
                  efficient enough.=



                          Addressin= g all these points potentially leads to major technical
                          modificat= ions (especially point a) on the current draft, hence it is
                          appropria= te in my opinion to discuss these points before making the
                          final decision.
                          <= br> <= br>
                      I am not sure= what else you have in mind for a). If we just forget


                  about Subscribe/Notify then you are good to go. But then you are also not fulfilling th= e charter or the industry needs in that respect.


                      Thanks,
                      Zach


                          Best regards,
                          <= br> Angelo P.= Castellani
                          <= br> <= br> On Mon, M= ay 10, 2010 at 18:51, Carsten Bormann<cabo@tzi.org> wrote:
                          <= br> <= br>
                              The CORE WG has a milestone to select a WG document for CoAP in


                  April:
                  =

                  draft-shelby-core= -coap has significant discussion, as well as the
                  largest number of= updates (including a previous version that was still
                  called -6lowapp-coap).


                  direction for the= WG to take?


                              If ye= s, is it the right direction? Should we adopt it as a WG


                  document?<= br>

                              If yo= u don't think we can say yet, is there a set of technical


                  decisions you wou= ld like the authors to take with priority?


                              Note that once a document has become a WG document, the authors act
                              =

                  as editors for th= e working group, making (and usually fleshing out the
                  details of) any change that the WG decides it needs.


                              If yo= u think we can still improve the draft, this is not an obstacle


                  to making it a WG= document.


                              But o= f course we shouldn't do that if we intend to reverse its


                  fundamental technical direction.


                              In order to stay roughly in sync with our milestones, we should


                  reach at a decisi= on on how to go forward this week.


                  _________________= ______________________________
                  core mailing list=
                  core@ietf.org
                  https://www.ietf.org/mailman/list= info/core

                  -----------------= ---------------
                  Onzo is a limited= company number 06097997 registered in England& Wales. The
                  registered office= is 6 Great Newport Street, London, WC2H 7JB, United Kingdom.

                  This email messag= e may contain confidential and/or privileged information, and
                  is intended solel= y for the addressee(s). If you have received this email in
                  error, please notify Onzo immediately. Unauthorised copying, disclosure or
                  distribution of t= he material in this email is forbidden.
                  -----------------= ---------------

                  _________________= ______________________________
                  core mailing list=
                  core@ietf.org
                  https://www.ietf.org/mailman/list= info/core

                  _________________= _____________________________________________________
                  This email has be= en scanned by the MessageLabs Email Security System.
                  _________________= _____________________________________________________

                  _________________= ______________________________
                  core mailing list=
                  core@ietf.org
                  https://www.ietf.org/mailman/list= info/core



          _________________________= ______________________
          core mailing list<= br> core@ietf.org
          https://www.ietf.org/mailman/list= info/core

          -------------------------= -------
          Onzo is a limited company= number 06097997 registered in England& Wales. The
          registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingdom.

          This email message may contain confidential and/or privileged information, and
          is intended solely for th= e addressee(s). If you have received this email in
          error, please notify Onzo= immediately. Unauthorised copying, disclosure or
          distribution of the material in this email is forbidden.
          -------------------------= -------




_________________________________= ______________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/list= info/core
_________________________________= ______________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/list= info/core



______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System.
= _____________________________________________________________________________________________________________________
core mailing list
core@= ietf.org
https://www.ietf.org= /mailman/listinfo/core

--------------040709040507000808040401 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0Popwx UbpuZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --------------040709040507000808040401 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --------------040709040507000808040401-- --------------050101090105090201020407-- --------------ms070209000403000202080409 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA1 MjgxMjA4MzhaMCMGCSqGSIb3DQEJBDEWBBSMS89KEUViwxTjLqQSZyx8dKKWwzBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAIfdKZDLLn9AuO0zwUoemcVXGjcZbblFYfy9b0aQOUdEg700CvUzH8U4dckgmpskjMaT dU8mM+YqYs+y3RDZo6oE1aZGotcCEEZfrG7jmYFn8NXJwwfNZrGmATrGG/qY0Vayfh2/Kd1D XQlSCmaF4MiIbcUOsYX4TQL15a0R+jXp+nidtaiNoRr3uNdmoCAq/BhXNux86CiS+NbKHiYV Y2mndbu09nZOM7uk+UwTCMoqPCwpWv0DTk6Zeki3gmzFNSqIGXHC79P5AYUv2NzhJetOuWOn +pvGraYWG7IQDDn07nvyvIbLPyX8VG2fLPVUNdcHM1WeR+YH8WbRYg7Lb8sAAAAAAAA= --------------ms070209000403000202080409-- From apezzuto@cisco.com Fri May 28 05:09:54 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 324A03A689E for ; Fri, 28 May 2010 05:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=2.323, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4c92i0lHYQ8D for ; Fri, 28 May 2010 05:09:50 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 59E513A659B for ; Fri, 28 May 2010 05:09:49 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image001.gif, image003.png, image004.png : 105, 168, 166 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhELAP9O/0urR7Ht/2dsb2JhbABwT5BgjAdxpAeaKwKCc4IfBA X-IronPort-AV: E=Sophos;i="4.53,318,1272844800"; d="gif'147?png'147,150?scan'147,150,208,217,147,150";a="136465840" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 28 May 2010 12:09:35 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4SC9UuV027578; Fri, 28 May 2010 12:09:34 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 May 2010 14:08:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CAFE5E.8144BB5E" Date: Fri, 28 May 2010 14:08:37 +0200 Message-ID: <0D212BD466921646B58854FB79092CEC021F4EF2@XMB-AMS-106.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Subscribe/Notify for CoAP Thread-Index: Acr+XDNu32OEwOJKRd2ckxfl2g5YaAAAPlZw References: <0D212BD466921646B58854FB79092CEC021F4E91@XMB-AMS-106.cisco.com> From: "Adriano Pezzuto (apezzuto)" To: X-OriginalArrivalTime: 28 May 2010 12:08:38.0727 (UTC) FILETIME=[818B9570:01CAFE5E] Cc: core Subject: Re: [core] Subscribe/Notify for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 12:09:54 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAFE5E.8144BB5E Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CAFE5E.8144BB5E" ------_=_NextPart_002_01CAFE5E.8144BB5E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, with this flavor, the SUBSCRIBE may be replaced by a simple POST. So no = needs to have an explicit SUBSCRIBE method. If we want support a more oriented peer-to-peer transaction on CoAP, it = looks to me both SUB and NOTIFY should be treated as messages. =20 Adriano =20 From: matthieu.vial@fr.non.schneider-electric.com = [mailto:matthieu.vial@fr.non.schneider-electric.com]=20 Sent: venerd=EC 28 maggio 2010 13.52 To: Adriano Pezzuto (apezzuto) Cc: core; core-bounces@ietf.org; robert.cragie@gridmerge.com Subject: Re: [core] Subscribe/Notify for CoAP =20 > So strictly speaking, both NOTIFY and SUBSCRIBE are message types not = methods! SUBSCRIBE can be just an asynchronous GET on update then I think it is a = method and NOTIFY is an asynchronous response so a message. But if we want to have selective notifications when a resource is = created, updated or deleted then I think you're right NOTIFY and = SUBSCRIBE are messages. Does that make sense ? Matthieu "Adriano Pezzuto (apezzuto)" "Adriano Pezzuto (apezzuto)" =20 Envoy=E9 par : core-bounces@ietf.org=20 28/05/2010 12:50 =20 A =20 cc core Objet Re: [core] Subscribe/Notify for CoAP =20 Hi Roberto, I understand your point and personally agree on M2M is quite different = from web page model. On the architectural RESTful style, the method = information tells the server what to do with data kept in the URI = information. So strictly speaking, both NOTIFY and SUBSCRIBE are message types not = methods! Adriano=20 From: Robert Cragie [mailto:robert.cragie@gridmerge.com]=20 Sent: venerd=EC 28 maggio 2010 11.53 To: Adriano Pezzuto (apezzuto) Cc: Paul Duffy (paduffy); Zach Shelby; core Subject: Re: [core] Subscribe/Notify for CoAP I think the point here is that there are two levels we are considering. At the lowest (foundation) level, there are the transaction messages as = described below. This provides a flexible mechanism for the application = with regard to synchronicity and threading. This is important for the = types of devices CoAP is being aimed at. Above that, the methods can be used according to the architectural = style. So in this case, it is RESTful (COnstrained Restful = Environments), which will naturally limit the number of methods and how = transactions occur. The actual architecture using a combination of the methods and messages = also depends on what is required at the application layer. Consider a = typical client which wants to subscribe to a resource. That client = controls the feed of data but needs a component which is capable of = handling (possibly buffering) the data it receives through = notifications. Is this a separate server? Or would we want to consider = it part of an enhanced client model which is able to process feeds of = data? These are the sort of models which have led to the myriad of = solutions (GENA, Webhooks, long polling, pubsubhubbub, RESTMS etc.) = based around HTTP which are all essentially ingenious ways of getting = around the limitations imposed by HTTP and how it is processed for = anything which deviates from the classic web page access model. I think the aim of CoAP should be clean from the word go with regard to = supporting these more peer-to-peer transactions, where the client can = exist on either entity and both entities can feed data to each other; = typical in M2M applications. Robert=20 Robert Cragie (Pacific Gas & Electric)=20 Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com =20 On 27/05/2010 7:08 PM, Adriano Pezzuto (apezzuto) wrote:=20 Hi Robert, in my personal opinion, the option 1a) brings some sort of ambiguity to = CoAP specs. My be my understatement of new CoAP specs is not so deep, but now we = have 5 methods and 3 message types: request, response and notify. Which = methods are allowed with which messages types? I suppose you have to use PUT/POST method with notify message for asynch = data notification. How to make a subscribe? I suppose you would use a = SUBSCRIBE method with request/response message or SUBSCRIBE with notify = message? Also what about POST/DELETE methods in a notify message? They = not make any sense.. I think the choice is between: option 1) -> only CRUD methods and option = 1b) -> CRUD + SUB/NOTIFY methods, keeping in mind cost/benefits of both = solutions. Adriano From: Robert Cragie [mailto:robert.cragie@gridmerge.com = ]=20 Sent: mercoled=EC 26 maggio 2010 20.09 To: Adriano Pezzuto (apezzuto) Cc: Paul Duffy (paduffy); Zach Shelby; core Subject: Re: [core] Subscribe/Notify for CoAP Hi Adrian, I would also prefer to keep the protocol in CoAP asynchronous. You can = always map an asynchronous protocol to a synchronous one but, as we see = in HTTP, it always ends up as a kludge to do it the other way round. The = efforts which have been gone to to make HTTP quasi-asynchronous via all = the schemes mentioned below and many more besides (all non-interoperable = of course) is testament to how important this is for M2M communication. So, back to Zach's list, I favor 1a) for the following reasons: Foundation level of messages:=20 1. request/response can be asynchronous or synchronous messages (as = there is a transaction ID in there) 2. notify is an asynchronous message Derived methods: I think it makes sense to add a pub/sub model as a useful mechanism for = M2M. So, looking at it the other way round: It will be entirely possible to = translate whatever is currently built on HTTP to CoAP based on the = above, with all its restrictions regarding synchronous and client/server = transactions. What may be harder is to translate directly is a = CoAP-based application to HTTP. So I guess the question is: Do we want = to be hamstrung to synchronous client/server transactions as dictated by = HTTP and provide a direct mapping to HTTP, then have to come up with = similar kludges for asynchronous peer-to-peer transactions as has been = done in numerous ways for HTTP, or do we want to define the protocol = cleanly to start with and accept that some sort of transaction = relaying/conversion would have to take place at a mapping node? Robert=20 Robert Cragie (Pacific Gas & Electric)=20 Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com =20 On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote:=20 Hi, it looks to me that CoAP should use an explicit sub/notify mechanism = since this is the core of the machine-to-machine interaction model. HTTP suffers of this lack and we have seen a plethora of solutions to = give an asynch taste to it. Webhooks and websockets are only the lasts = of the list. As someone has already pointed out on this list, it is theoretically = possible to describe sub/notify using only CRUD methods but it looks a = little bit tricky and verbose. Now we have a chance to build from scratch a new protocol with and I = think using explicit sub/notify methods with a clear and well defined = semantic is the best option. It is easily understanding from every = developer and will prevent to build other fanny solutions on top of the = CoAP. HTTP does not have this well defined semantic and (for hundreds of = other reasons also) it is not used as wide protocol for = machine-to-machine communication. CoAP - as binary protocol - and with an explicit asynch model has a = chance to be a really wide protocol for M2M communication not only for = constrained environments. my 2 cents - adriano -----Original Message----- From: core-bounces@ietf.org = [mailto:core-bounces@ietf.org ] On Behalf = Of Paul Duffy (paduffy) Sent: mercoled=EC 26 maggio 2010 0.47 To: Zach Shelby Cc: core Subject: Re: [core] Subscribe/Notify for CoAP On 5/25/2010 6:41 PM, Zach Shelby wrote: Hi, On May 26, 2010, at 12:23 AM, Charles Palmer wrote: Hi folks It occurs to me that CoRE should be keeping a close eye on ZigBee SE2.0 = work, so that it is as easy as possible for ZigBee SE to use CoRE when = ready. That suggests to me that we should align with their = subscribe/notify process. I am not sure I understand that. I mean, ZigBee SE2.0 is defining an = application specific subscribe/notify mechanism for that purpose so far = for HTTP. This uses standard HTTP methods and some custom payload and = REST interfaces. CoAP Req/Res is already totally compatible with SE2.0 = in that respect, so alignment is already OK there. Nothing stopping = someone from using SE2.0 over CoAP. Specifying a native susbcription/notify into CoAP is another matter. We = can't adopt a solution specific to one application as that won't solve = the problems of other applications nor general HTTP mapping at all = (probably would make it worse). It seems that for the near future there = will be a bunch of HTTP push mechanisms in use without any clear = standard appearing - or am I wrong there? If COAP extends HTTP semantics with new subscription methods, it will=20 not be possible to easily interchange HTTP/COAP, and translation=20 gateways will become more complex to implement. Zach Regards - Charles -----Original Message----- From: core-bounces@ietf.org = [mailto:core-bounces@ietf.org ] On Behalf = Of Paul Duffy Sent: 25 May 2010 03:48 To: Zach Shelby Cc: core Subject: Re: [core] Subscribe/Notify for CoAP Recommend something like #2, primarily to avoid introducing non HTTP method semantics, simplifying HTTP/COAP translation.gateways, etc. On 5/24/2010 11:49 AM, Zach Shelby wrote: (thread renamed) We have two different paths with regard to a subscribe/notify mechanism = for CoAP: 1. Use specific Subscription and Notify mechanisms for CoAP as HTTP = really does not include this concept. 1a) Notify as a message and SUBSCRIBE as a method. This is currently = used in coap-01. 1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but we = had a good list discussion about this leading to a. In practice it = doesn't make a big difference if notification is a message or method. 2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2.0 = proposal or GENA. So far we have focused on 1 in the WG, and every now and again 2 comes = up. At least I am not convinced that we need to suffer the drawbacks of = HTTP here. Anyways 2 does not help our mapping to HTTP in reality very = much as there is no standard way of doing this over HTTP. Thus a = CoAP-HTTP proxy may end up anyways translating between multiple HTTP = frameworks depending on the application. So instead of doing a CoAP = Notify/Subscribe to Webhooks mapping, you will could end up having to do = a CoAP Webhooks to HTTP GENA mapping. I don't understand this last para. If CoAP sticks to the semantics of the current HTTP methods, would this not offer a fairly straightforward translation to/from HTTP? >From what I have heard so far 1 still seems like a wise choice, although = I need to look at Webhooks more deeply. In reality many applications = specify their own way of doing a push interface using REST methods and = specific payloads (ZigBee SE2.0 is such an example). That is just fine, = and might be used instead of a specific CoAP notify/subscribe in that = case. So 1 doesn't prevent the application using its own mechanism, it = just provides a native way for doing push. What do people think? Zach On May 17, 2010, at 6:44 PM, matthieu.vial@fr.non.schneider-electric.com = wrote: Hi, My comments about the subscribe/notify mechanism of Zigbee IP. Pros: - Derived from the webhooks concept - If used by CORE it will be easier to map to HTTP because it uses only = CRUD verbs. - The subscription message is extendable and could support advanced = options (delays, increment, ...) - Only one listening port whatever the transport binding is. Cons: - No interoperability without well known URIs and a well defined = subscription message format (Not sure CoAP draft is the right place to = specify this). - XML/EXI is too complex to be the required format for the default = subscription/notification mechanism. - The notification should not require a subsequent GET to retrieve the = content. - Subresource subscription is redundant. Hope this could help, Matthieu "Charles Palmer" = =20 "Charles Palmer" = =20 Envoy=E9 par : core-bounces@ietf.org =20 15/05/2010 14:06 A "core" =20 cc Objet Re: [core] Selecting a WG document for CoAP Dear all Those interested in the subscribe/notify discussion might like to look at the draft Smart Energy Profile 2.0 Application Protocol Specification. It is available here: http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicApp = =20 licationProfile.aspx It manages subscribe/notify by using POST. This seems to remove the need for SUBSCRIBE and notify. "Imagine a host A, which exposes a resource at http{s}://A/resource and a second host B, which wishes to learn of changes to this resource. To facilitate a subscription/ notification mechanism, A would expose a resource http{s}://A/sub and B would expose a resource http{s}://B/ntfy. To subscribe to notifications regarding http{s}://A/resource, B would send a POST to the address http{s}://A/sub/B containing the URI of the resource of interest (http{s}://A/resource) and the URI of B's notification resource (http{s}://B/ntfy). Following this subscription step, should A wish to notify B of a change to the resource addressed at http{s}://A/resource, A would send a POST to the address http{s}://B/ntfy containing the URI of the resource changed (http{s}://A/resource) and the URI of A's subscription resource (http{s}://A/sub/B), should A wish to change its subscription. The host B can then query the resource (or not) at its leisure." Sleepy nodes are not allowed to subscribe, and must poll. Regards - Charles Palmer -----Original Message----- From: core-bounces@ietf.org = [mailto:core-bounces@ietf.org ] On Behalf = Of Angelo P. Castellani Sent: 14 May 2010 13:14 To: Zach Shelby Cc: core Subject: Re: [core] Selecting a WG document for CoAP Zach, thanks for the comments, but please refer to my most recent e-mail for a more specific list of technical issues I'm pointing to. I want to do only a little integration to what I've written there. In my very personal opinion, to maximize adherence with the REST model and minimize implementation effort SUBSCRIBE and NOTIFY should be mapped to methods (as discussed many times together...). Uniform interface principle (Fielding PhD dissertation Section 5.1.5, "The central feature that distinguishes the REST architectural style [...]") states that to simplify the software architecture, resource interfaces/interfaces should be as general as possible. I agree with this principle in this specific case, mainly because handling a special message type for notify leads node software design to a more complex architecture. The reason is that this new message type requires special handling and introduces a complexity in the software modularization. Best, Angelo On Fri, May 14, 2010 at 13:06, Zach Shelby = wrote: Hi Angelo, On May 13, 2010, at 14:24 , Angelo P. Castellani wrote: Dear C. Bormann, all, before deciding for the final direction, I've the following observations about draft-shelby-core-coap-01 While I mostly share Zach's view of the protocol approach, and appreciate many aspects of the proposal, there are in my opinion still some open issues that need to be at least discussed before the current document can be selected. Of course there are plenty of open issues. Remember that working group documents still undertake as much change and improvement as the WG wants, so by no means is coap-01 set in stone. I would expect at least 5-10 more revisions still along the way. Already several of your ideas have been integrated into coap-01, and several more are under consideration, so it is coming along. Patience ;-) =20 In particular, I would like to highlight the following: a) As it is now, it is not possible to have a straightforward translation of HTTP -> CoAP and viceversa: see http://www.ietf.org/mail-archive/web/core/current/msg00133.html = (this impacts the scalability of the web service model too) In coap-01 the Method names are now identical to HTTP methods. The Req/Res interaction is a direct translation. The URI hierarchy is compatible, and the URI binary code format we are still working on obviously. The only thing that takes some state to translate is Subscribe/Notify. But note, Subscribe/Notify takes some state no matter how you do it, even with HTTP-HTTP there is no clean and easy way to handle subscriptions. =20 b) Moreover, CoAP's implementation is not as simple as it should be. I've investigated the implementation and some design choices (as Options) are leading to very high program complexity (ROM) on a MSP430-based device. This we can definitely improve, and already made several optimizations from -00 to -01. Here I need some very concrete proposals though. Also remember that many things are optional, for example subscribe/notify is not required if you don't need it. =20 c) Finally when comparing HTTP message size with CoAP message size, the resulting compression isn't as good as you may expect. Example: HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B CoAP: 24 B with options parsing procedure requiring an added implementation complexity Right, that is not how it will work in practice. Working with a real HTTP server that HTTP header will be more complex, and on the CoAP side you would chose shorter URLs. The biggest improvement possible here is from using binary coded URLs of course. We need to look at a wider range of interactions and real HTTP headers as well to check that we are efficient enough. =20 Addressing all these points potentially leads to major technical modifications (especially point a) on the current draft, hence it is appropriate in my opinion to discuss these points before making the final decision. I am not sure what else you have in mind for a). If we just forget about Subscribe/Notify then you are good to go. But then you are also not fulfilling the charter or the industry needs in that respect. Thanks, Zach Best regards, Angelo P. Castellani On Mon, May 10, 2010 at 18:51, Carsten Bormann = wrote: The CORE WG has a milestone to select a WG document for CoAP in April: http://datatracker.ietf.org/wg/core/charter/ = =20 ... Apr 2010 Select WG document for basis of the CoAP protocol Of the various documents that have been contributed, draft-shelby-core-coap has significant discussion, as well as the largest number of updates (including a previous version that was still called -6lowapp-coap). Today, another updated version of that draft was announced. See http://www.ietf.org/mail-archive/web/core/current/msg00138.html = =20 for the announcement and http://tools.ietf.org/html/draft-shelby-core-coap-01 = =20 for the draft itself. However, as the authors say, there are still significant TODOs. Are we in a state yet where we can say whether this is the right direction for the WG to take? If yes, is it the right direction? Should we adopt it as a WG document? If you don't think we can say yet, is there a set of technical decisions you would like the authors to take with priority? Note that once a document has become a WG document, the authors act as editors for the working group, making (and usually fleshing out the details of) any change that the WG decides it needs. If you think we can still improve the draft, this is not an obstacle to making it a WG document. But of course we shouldn't do that if we intend to reverse its fundamental technical direction. In order to stay roughly in sync with our milestones, we should reach at a decision on how to go forward this week. Gruesse, Carsten _______________________________________________ core mailing list core@ietf.org =20 https://www.ietf.org/mailman/listinfo/core = =20 _______________________________________________ core mailing list core@ietf.org =20 https://www.ietf.org/mailman/listinfo/core = =20 -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the = Internet of Things" =20 http://6lowpan.net - My book " 6LoWPAN: The = Wireless Embedded Internet" Mobile: +358 40 7796297 _______________________________________________ core mailing list core@ietf.org =20 https://www.ietf.org/mailman/listinfo/core = =20 -------------------------------- Onzo is a limited company number 06097997 registered in England& Wales. = The registered office is 6 Great Newport Street, London, WC2H 7JB, United = Kingdom. This email message may contain confidential and/or privileged = information, and is intended solely for the addressee(s). If you have received this email = in error, please notify Onzo immediately. Unauthorised copying, disclosure = or distribution of the material in this email is forbidden. -------------------------------- _______________________________________________ core mailing list core@ietf.org =20 https://www.ietf.org/mailman/listinfo/core = =20 ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ _______________________________________________ core mailing list core@ietf.org =20 https://www.ietf.org/mailman/listinfo/core = =20 =20 _______________________________________________ core mailing list core@ietf.org =20 https://www.ietf.org/mailman/listinfo/core = =20 -------------------------------- Onzo is a limited company number 06097997 registered in England& Wales. = The registered office is 6 Great Newport Street, London, WC2H 7JB, United = Kingdom. This email message may contain confidential and/or privileged = information, and is intended solely for the addressee(s). If you have received this email = in error, please notify Onzo immediately. Unauthorised copying, disclosure = or distribution of the material in this email is forbidden. -------------------------------- =20 _______________________________________________ core mailing list core@ietf.org =20 https://www.ietf.org/mailman/listinfo/core = =20 _______________________________________________ core mailing list core@ietf.org =20 https://www.ietf.org/mailman/listinfo/core = =20 ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. _________________________________________________________________________= ____________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------_=_NextPart_002_01CAFE5E.8144BB5E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

with this flavor, the SUBSCRIBE may be replaced by a = simple POST. So no needs to have an explicit SUBSCRIBE method.

If we want support a more oriented peer-to-peer = transaction on CoAP, it looks to me both SUB and NOTIFY should be treated as = messages.

 

Adriano

 

From:= matthieu.vial@fr.non.schneider-electric.com [mailto:matthieu.vial@fr.non.schneider-electric.com]
Sent: venerd=EC 28 maggio 2010 13.52
To: Adriano Pezzuto (apezzuto)
Cc: core; core-bounces@ietf.org; robert.cragie@gridmerge.com
Subject: Re: [core] Subscribe/Notify for = CoAP

 

> So strictly speaking, both NOTIFY and SUBSCRIBE are = message types not  methods!

SUBSCRIBE can be just an asynchronous GET on update then I think it is a = method and NOTIFY is an asynchronous response so a message.
But if we want to have selective notifications when a resource is = created, updated or deleted then I think you're right NOTIFY and SUBSCRIBE are = messages.

Does that make sense ?

Matthieu

3D"Inactive"Adriano Pezzuto (apezzuto)" <apezzuto@cisco.com>



"Adriano Pezzuto (apezzuto)" = <apezzuto@cisco.com>
Envoy=E9 par : = core-bounces@ietf.org

28/05/2010 12:50

A


<robert.cragie@gridmerge.com>

cc


core = <core@ietf.org>

Objet


Re: [core] Subscribe/Notify for = CoAP

 


Hi Roberto,
I understand your point and personally agree on M2M is quite different = from web page model. On the architectural RESTful style, the method information = tells the server what to do with data kept in the URI information.

So strictly speaking, both NOTIFY and SUBSCRIBE are message types not  methods!

Adriano

From:= Robert = Cragie [mailto:robert.cragie@gridmerg= e.com]
Sent: venerd=EC 28 maggio 2010 11.53
To: Adriano Pezzuto (apezzuto)
Cc: Paul Duffy (paduffy); Zach Shelby; core
Subject: Re: [core] Subscribe/Notify for CoAP

I think the point here is that there = are two levels we are considering.

At the lowest (foundation) level, there are the transaction messages as described below. This provides a flexible mechanism for the application = with regard to synchronicity and threading. This is important for the types = of devices CoAP is being aimed at.

Above that, the methods can be used according to the architectural = style. So in this case, it is RESTful (COnstrained Restful Environments), which will naturally limit the number of methods and how transactions occur.

The actual architecture using a combination of the methods and messages = also depends on what is required at the application layer. Consider a typical = client which wants to subscribe to a resource. That client controls the feed of = data but needs a component which is capable of handling (possibly buffering) = the data it receives through notifications. Is this a separate server? Or = would we want to consider it part of an enhanced client model which is able to = process feeds of data? These are the sort of models which have led to the myriad = of solutions (GENA, Webhooks, long polling, pubsubhubbub, RESTMS etc.) = based around HTTP which are all essentially ingenious ways of getting around = the limitations imposed by HTTP and how it is processed for anything which = deviates from the classic web page access model.

I think the aim of CoAP should be clean from the word go with regard to supporting these more peer-to-peer transactions, where the client can = exist on either entity and both entities can feed data to each other; typical in = M2M applications.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com

On 27/05/2010 7:08 PM, Adriano Pezzuto (apezzuto) wrote:
Hi Robert,

in my personal opinion, the option 1a) brings some sort of ambiguity to = CoAP specs.

My be my understatement of new CoAP specs is not so deep, but now we have 5 methods and 3 message types: request, response and notify. Which methods = are allowed with which messages types?
I suppose you have to use PUT/POST method with notify message for asynch = data notification. How to make a subscribe? I suppose you would use a = SUBSCRIBE method with request/response message or SUBSCRIBE with notify message? = Also what about POST/DELETE methods in a notify message? They not make any = sense..

I think the choice is between: option 1) -> only CRUD methods and = option 1b) -> CRUD + SUB/NOTIFY methods, keeping in mind cost/benefits of both solutions.

Adriano

From:= Robert = Cragie [mailto:robert.cragie@gridmerge.com]
Sent: mercoled=EC 26 maggio 2010 20.09
To: Adriano Pezzuto (apezzuto)
Cc: Paul Duffy (paduffy); Zach Shelby; core
Subject: Re: [core] Subscribe/Notify for CoAP

Hi Adrian,

I would also prefer to keep the protocol in CoAP asynchronous. You can = always map an asynchronous protocol to a synchronous one but, as we see in = HTTP, it always ends up as a kludge to do it the other way round. The efforts = which have been gone to to make HTTP quasi-asynchronous via all the schemes = mentioned below and many more besides (all non-interoperable of course) is = testament to how important this is for M2M communication.

So, back to Zach's list, I favor 1a) for the following reasons:

Foundation level of messages:

1. request/response can be asynchronous or synchronous messages (as there is a transaction = ID in there)
2. notify is an asynchronous = message

Derived = methods:

I think it makes sense to add a pub/sub model as a useful mechanism for = M2M.

So, looking at it the other way round: It will be entirely possible to translate whatever is currently built on HTTP to CoAP based on the = above, with all its restrictions regarding synchronous and client/server = transactions. What may be harder is to translate directly is a CoAP-based application to = HTTP. So I guess the question is: Do we want to be hamstrung to synchronous client/server transactions as dictated by HTTP and provide a direct = mapping to HTTP, then have to come up with similar kludges for asynchronous = peer-to-peer transactions as has been done in numerous ways for HTTP, or do we want = to define the protocol cleanly to start with and accept that some sort of transaction relaying/conversion would have to take place at a mapping = node?

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com

On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote:
Hi,
it looks to = me that CoAP should use an explicit sub/notify mechanism since this is the core = of the machine-to-machine interaction model.
HTTP suffers = of this lack and we have seen a plethora of solutions to give an asynch taste to = it. Webhooks and websockets are only the lasts of the list.
As someone = has already pointed out on this list, it is theoretically possible to describe = sub/notify using only CRUD methods but it looks a little bit tricky and = verbose.

Now we have a = chance to build from scratch a new protocol with and I think using explicit = sub/notify methods with a clear and well defined semantic is the best option. It is = easily understanding from every developer and will prevent to build other fanny = solutions on top of the CoAP. HTTP does not have this well defined semantic and = (for hundreds of other reasons also) it is not used as wide protocol for machine-to-machine communication.

CoAP - as = binary protocol - and with an explicit asynch model has a chance to be a really = wide protocol for M2M communication not only for constrained = environments.

my 2 = cents

- = adriano

-----Original Message-----
From: = core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Paul = Duffy (paduffy)
Sent: = mercoled=EC 26 maggio 2010 0.47
To: Zach = Shelby
Cc: = core
Subject: Re: = [core] Subscribe/Notify for CoAP

On 5/25/2010 = 6:41 PM, Zach Shelby wrote:

Hi,

On May 26, = 2010, at 12:23 AM, Charles Palmer wrote:

Hi folks

It occurs to = me that CoRE should be keeping a close eye on ZigBee SE2.0 work, so that it is = as easy as possible for ZigBee SE to use CoRE when ready. That suggests to me = that we should align with their subscribe/notify process.

I am not sure I understand that. I mean, ZigBee SE2.0 is defining an = application specific subscribe/notify mechanism for that purpose so far for HTTP. = This uses standard HTTP methods and some custom payload and REST interfaces. CoAP = Req/Res is already totally compatible with SE2.0 in that respect, so alignment = is already OK there. Nothing stopping someone from using SE2.0 over = CoAP.

Specifying a = native susbcription/notify into CoAP is another matter. We can't adopt a = solution specific to one application as that won't solve the problems of other applications nor general HTTP mapping at all (probably would make it = worse). It seems that for the near future there will be a bunch of HTTP push = mechanisms in use without any clear standard appearing - or am I wrong = there?




If COAP = extends HTTP semantics with new subscription methods, it will
not be = possible to easily interchange HTTP/COAP, and translation
gateways will = become more complex to implement.


Zach

Regards - Charles


-----Original = Message-----
From: = core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Paul = Duffy
Sent: 25 May = 2010 03:48
To: Zach = Shelby
Cc: = core
Subject: Re: = [core] Subscribe/Notify for CoAP

Recommend = something like #2, primarily to avoid introducing non HTTP
method = semantics, simplifying HTTP/COAP translation.gateways, etc.


On 5/24/2010 = 11:49 AM, Zach Shelby wrote:

(thread renamed)

We have two = different paths with regard to a subscribe/notify mechanism for CoAP:

1. Use = specific Subscription and Notify mechanisms for CoAP as HTTP really does not = include this concept.
1a) Notify as = a message and SUBSCRIBE as a method. This is currently used in = coap-01.
1b) NOTIFY = and SUBSCRIBE as methods. This was used in coap-00, but we had a good list discussion about this leading to a. In practice it doesn't make a big difference if notification is a message or method.

2. Use an = HTTP specific framework such as Webhooks, the ZigBee SE2.0 proposal or = GENA.

So far we = have focused on 1 in the WG, and every now and again 2 comes up. At least I am not = convinced that we need to suffer the drawbacks of HTTP here. Anyways 2 does not = help our mapping to HTTP in reality very much as there is no standard way of = doing this over HTTP. Thus a CoAP-HTTP proxy may end up anyways translating between multiple HTTP frameworks depending on the application. So instead of = doing a CoAP Notify/Subscribe to Webhooks mapping, you will could end up having = to do a CoAP Webhooks to HTTP GENA mapping.


I don't = understand this last para. If CoAP sticks to the semantics of
the current = HTTP methods, would this not offer a fairly straightforward
translation = to/from HTTP?


From what I have heard so far 1 still seems like a wise choice, although I = need to look at Webhooks more deeply. In reality many applications specify their = own way of doing a push interface using REST methods and specific payloads = (ZigBee SE2.0 is such an example). That is just fine, and might be used instead = of a specific CoAP notify/subscribe in that case. So 1 doesn't prevent the application using its own mechanism, it just provides a native way for = doing push.

What do people think?

Zach

On May 17, = 2010, at 6:44 PM, matthieu.vial@fr.non.schneider-electric.com wrote:


Hi,

My comments = about the subscribe/notify mechanism of Zigbee IP.

Pros:
- Derived = from the webhooks concept
- If used by = CORE it will be easier to map to HTTP because it uses only CRUD verbs.
- The = subscription message is extendable and could support advanced options (delays, = increment, ...)
- Only one = listening port whatever the transport binding is.

Cons:
- No = interoperability without well known URIs and a well defined subscription message format = (Not sure CoAP draft is the right place to specify this).
- XML/EXI is = too complex to be the required format for the default = subscription/notification mechanism.
- The = notification should not require a subsequent GET to retrieve the content.
- Subresource subscription is redundant.

Hope this = could help,
Matthieu


<graycol.gif>"Charles Palmer"<charles.palmer@onzo.com>




"Charles Palmer"<charles.palmer@onzo.com>
Envoy=E9 par = : core-bounces@ietf.org
15/05/2010 = 14:06

<ecblank.gif>
A
<ecblank.gif>
"core"<core@ietf.org>
<ecblank.gif>
cc
<ecblank.gif>
<ecblank.gif>
Objet
<ecblank.gif>
Re: [core] = Selecting a WG document for CoAP
<ecblank.gif> <ecblank.gif>

Dear = all

Those = interested in the subscribe/notify discussion might like to look
at the draft = Smart Energy Profile 2.0 Application Protocol
Specification. It is available here:
http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20Publ= icApp
licationProfile.aspx

It manages = subscribe/notify by using POST. This seems to remove the need
for SUBSCRIBE = and notify.

"Imagine = a host A, which exposes a resource at http{s}://A/resource and
a second host = B, which wishes to learn of changes to this resource. To
facilitate a subscription/ notification mechanism, A would expose a
resource http{s}://A/sub and B would expose a resource = http{s}://B/ntfy.
To subscribe = to notifications regarding http{s}://A/resource, B would
send a POST = to the address http{s}://A/sub/B containing the URI of the
resource of = interest (http{s}://A/resource) and the URI of B's
notification = resource (http{s}://B/ntfy). Following this subscription
step, should = A wish to notify B of a change to the resource addressed at
http{s}://A/resource, A would send a POST to the address
http{s}://B/ntfy containing the URI of the resource changed
(http{s}://A/resource) and the URI of A's subscription resource
(http{s}://A/sub/B), should A wish to change its subscription. The host
B can then = query the resource (or not) at its leisure."

Sleepy nodes = are not allowed to subscribe, and must poll.

Regards - = Charles Palmer

-----Original Message-----
From: = core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of
Angelo P. = Castellani
Sent: 14 May = 2010 13:14
To: Zach = Shelby
Cc: = core
Subject: Re: = [core] Selecting a WG document for CoAP

Zach,

thanks for = the comments, but please refer to my most recent e-mail for
a more = specific list of technical issues I'm pointing to.

I want to do = only a little integration to what I've written there.

In my very = personal opinion, to maximize adherence with the REST model
and minimize implementation effort SUBSCRIBE and NOTIFY should be
mapped to = methods (as discussed many times together...).

Uniform = interface principle (Fielding PhD dissertation Section 5.1.5,
"The = central feature that distinguishes the REST architectural style
[...]") = states that to simplify the software architecture, resource
interfaces/interfaces should be as general as possible.

I agree with = this principle in this specific case, mainly because
handling a = special message type for notify leads node software design
to a more = complex architecture.

The reason is = that this new message type requires special handling and
introduces a complexity in the software modularization.

Best,
Angelo

On Fri, May = 14, 2010 at 13:06, Zach Shelby<zach@sensinode.com> wrote:

Hi Angelo,

On May 13, = 2010, at 14:24 , Angelo P. Castellani wrote:


Dear C. Bormann, all,

before = deciding for the final direction, I've the following
observations = about draft-shelby-core-coap-01

While I = mostly share Zach's view of the protocol approach, and
appreciate = many aspects of the proposal, there are in my opinion

still

some open issues that need to be at least discussed before the

current

document can be selected.

Of course there are plenty of open issues. Remember that working = group

documents still undertake as much change and improvement as the WG
wants, so by = no means is coap-01 set in stone. I would expect at least
5-10 more = revisions still along the way. Already several of your ideas
have been = integrated into coap-01, and several more are under
consideration, so it is coming along. Patience ;-)

 

In particular, I would like to highlight the following:

a) As it is = now, it is not possible to have a straightforward
translation = of HTTP -> CoAP and viceversa: see
= http://www.ietf.org/mail-archive/web/core/current/msg00133.html (this
impacts the scalability of the web service model too)

In coap-01 the Method names are now identical to HTTP methods. = The

Req/Res interaction is a direct translation. The URI hierarchy is
compatible, = and the URI binary code format we are still working on
obviously. = The only thing that takes some state to translate is
Subscribe/Notify. But note, Subscribe/Notify takes some state no matter
how you do = it, even with HTTP-HTTP there is no clean and easy way to
handle = subscriptions.

 

b) Moreover, CoAP's implementation is not as simple as it should = be.
I've = investigated the implementation and some design choices (as
Options) are = leading to very high program complexity (ROM) on a
MSP430-based = device.

This we can definitely improve, and already made several = optimizations

from -00 to -01. Here I need some very concrete proposals though. = Also
remember that = many things are optional, for example subscribe/notify is
not required = if you don't need it.

 

c) Finally when comparing HTTP message size with CoAP message = size,
the resulting compression isn't as good as you may expect.

Example:
HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B
CoAP: 24 B = with options parsing procedure requiring an added
implementation complexity

Right, that is not how it will work in practice. Working with a real

HTTP server that HTTP header will be more complex, and on the CoAP = side
you would = chose shorter URLs. The biggest improvement possible here is
from using = binary coded URLs of course. We need to look at a wider range
of = interactions and real HTTP headers as well to check that we are
efficient = enough.

 

Addressing all these points potentially leads to major technical
modifications (especially point a) on the current draft, hence it is
appropriate = in my opinion to discuss these points before making the
final = decision.

I am not sure what else you have in mind for a). If we just = forget

about Subscribe/Notify then you are good to go. But then you are = also
not = fulfilling the charter or the industry needs in that respect.

Thanks,
Zach


Best regards,

Angelo P. = Castellani


On Mon, May = 10, 2010 at 18:51, Carsten Bormann<cabo@tzi.org> wrote:

The CORE WG has a milestone to select a WG document for CoAP in

April:

http://datatracker.ietf.org/wg/core/charter/
...
Apr 2010 = Select WG document for basis of the CoAP protocol

Of the = various documents that have been contributed,

draft-shelby-core-coap has significant discussion, as well as the
largest = number of updates (including a previous version that was still
called = -6lowapp-coap).

Today, another updated version of that draft was announced. See
= http://www.ietf.org/mail-archive/web/core/current/msg00138.html
for the = announcement and
http://tools.ietf.org/html/draft-shelby-core-coap-01
= for the draft = itself.

However, as = the authors say, there are still significant TODOs.

Are we in a = state yet where we can say whether this is the right

direction for the WG to take?

If yes, is it the right direction? Should we adopt it as a WG

document?

If you don't think we can say yet, is there a set of technical

decisions you would like the authors to take with priority?

Note that once a document has become a WG document, the authors = act

as editors for the working group, making (and usually fleshing out = the
details of) = any change that the WG decides it needs.

If you think we can still improve the draft, this is not an = obstacle

to making it a WG document.

But of course we shouldn't do that if we intend to reverse its

fundamental technical direction.

In order to stay roughly in sync with our milestones, we should

reach at a decision on how to go forward this week.

Gruesse, Carsten

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


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

--
Zach Shelby, = Chief Nerd, Sensinode Ltd.
http://zachshelby.org - My blog "On the Internet of = Things"
http://6lowpan.net - My book "6LoWPAN: The = Wireless Embedded Internet"
Mobile: +358 = 40 7796297



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

--------------------------------
Onzo is a = limited company number 06097997 registered in England& Wales. The
registered = office is 6 Great Newport Street, London, WC2H 7JB, United Kingdom.

This email = message may contain confidential and/or privileged information, and
is intended = solely for the addressee(s). If you have received this email in
error, please = notify Onzo immediately. Unauthorised copying, disclosure or
distribution = of the material in this email is forbidden.
--------------------------------

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

___________________________________________________________________= ___
This email = has been scanned by the MessageLabs Email Security System.
___________________________________________________________________= ___

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

 

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

--------------------------------
Onzo is a = limited company number 06097997 registered in England& Wales. The
registered = office is 6 Great Newport Street, London, WC2H 7JB, United Kingdom.

This email = message may contain confidential and/or privileged information, and
is intended = solely for the addressee(s). If you have received this email in
error, please = notify Onzo immediately. Unauthorised copying, disclosure or
distribution = of the material in this email is forbidden.
--------------------------------

 


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



______________________________________________________________________ This email has been scanned by the MessageLabs Email Security = System.
____________________________________________________________________________________________________________________= _
core mailing list
core@ietf.org
https://www.ietf.org/= mailman/listinfo/core

------_=_NextPart_002_01CAFE5E.8144BB5E-- ------_=_NextPart_001_01CAFE5E.8144BB5E Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------_=_NextPart_001_01CAFE5E.8144BB5E Content-Type: image/png; name="image003.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image003.png Content-Location: image003.png iVBORw0KGgoAAAANSUhEUgAAADoAAAABCAMAAAC42E10AAAAAXNSR0ICQMB9xQAAAANQTFRFAAAA p3o92gAAAAF0Uk5TAEDm2GYAAAAJcEhZcwAADsQAAA7EAZUrDhsAAAAZdEVYdFNvZnR3YXJlAE1p Y3Jvc29mdCBPZmZpY2V/7TVxAAAADElEQVQY02NgIBsAAAA7AAFzMF3lAAAAAElFTkSuQmCC ------_=_NextPart_001_01CAFE5E.8144BB5E Content-Type: image/png; name="image004.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image004.png Content-Location: image004.png iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAMAAAAoyzS7AAAAAXNSR0ICQMB9xQAAAANQTFRFAAAA p3o92gAAAAF0Uk5TAEDm2GYAAAAJcEhZcwAADsQAAA7EAZUrDhsAAAAZdEVYdFNvZnR3YXJlAE1p Y3Jvc29mdCBPZmZpY2V/7TVxAAAACklEQVQY02NgAAAAAgABmGNs1wAAAABJRU5ErkJggg== ------_=_NextPart_001_01CAFE5E.8144BB5E-- From matthieu.vial@fr.non.schneider-electric.com Fri May 28 05:39:52 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78EEF3A6781; Fri, 28 May 2010 05:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.836 X-Spam-Level: * X-Spam-Status: No, score=1.836 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raPUvMSL1nKI; Fri, 28 May 2010 05:39:48 -0700 (PDT) Received: from mailX02.eud.schneider-electric.com (mailx02.eud.schneider-electric.com [205.167.7.38]) by core3.amsl.com (Postfix) with ESMTP id 8FCA83A6820; Fri, 28 May 2010 05:39:45 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX02.eud.schneider-electric.com with ESMTP id 2010052814320649-89143 ; Fri, 28 May 2010 14:32:06 +0200 In-Reply-To: <4BFFB246.4010600@gridmerge.com> To: robert.cragie@gridmerge.com X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: matthieu.vial@fr.non.schneider-electric.com Date: Fri, 28 May 2010 14:39:14 +0200 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 28/05/2010 14:39:19, Itemize by SMTP Server on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 28/05/2010 14:32:06, Serialize by Router on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 28/05/2010 14:32:23 Content-type: multipart/related; Boundary="0__=4EBBFDA2DFD074F58f9e8a93df938690918c4EBBFDA2DFD074F5" Cc: core-bounces@ietf.org, core Subject: Re: [core] Subscribe/Notify for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 12:39:52 -0000 --0__=4EBBFDA2DFD074F58f9e8a93df938690918c4EBBFDA2DFD074F5 Content-type: multipart/alternative; Boundary="1__=4EBBFDA2DFD074F58f9e8a93df938690918c4EBBFDA2DFD074F5" --1__=4EBBFDA2DFD074F58f9e8a93df938690918c4EBBFDA2DFD074F5 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Robert, >I am not sure what you mean here. Do you mean that some other client can subscribe to be notified whenever some method is acted upon for a particular resource? Can you describe the transaction model? Excatly I want to be notified when a resource is deleted but not just updated for example. So I send a subscribe message and the method of that message is delete. But the main usage of subscribe will be notifications upon modification of a resource, so I'am fine with subscribe as method and notify as message. Dynamic resources will probably be part of a collection, so we can still monitor the modifications of the collection instead of an individual item. Matthieu Robert = Robert Cragie = A = Matthieu = 28/05/2010 14:08 Vial/FR/Non/Schneider@Europe = cc = "Adriano Pezzuto (apezzuto)" = Veuillez r=E9pondre , core = =20 =E0 , = =20 robert.cragie@gri core-bounces@ietf.org = dmerge.com Objet = Re: [core] Subscribe/Notify for = CoAP = = = = = = = Hi Matthieu, I am not sure what you mean here. Do you mean that some other client can subscribe to be notified whenever some method is acted upon for a particular resource? Can you describe the transaction model? Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 28/05/2010 12:51 PM, matthieu.vial@fr.non.schneider-electric.com wrote: > So strictly speaking, both NOTIFY and SUBSCRIBE are message types not methods! SUBSCRIBE can be just an asynchronous GET on update then I think it is a method and NOTIFY is an asynchronous response so a message. But if we want to have selective notifications when a resource is created, updated or deleted then I think you're right NOTIFY and SUBSCRIBE are messages. Does that make sense ? Matthieu Inactive hide details for "Adriano Pezzuto (apezzuto)" "Adriano Pezzuto (apezzuto)" = "Adriano Pezzuto = (apezzuto)" = = Envoy=E9 par : = A=20 core-bounces@iet = f.org = = 28/05/2010 12:50 cc = = core = = = Objet = = Re: [core] = Subscribe/Notify = for CoAP = = = = = = = Hi Roberto, I understand your point and personally agree on M2M is quite different from web page model. On the architectural RESTful style, the method information tells the server what to do with data kept in the URI information. So strictly speaking, both NOTIFY and SUBSCRIBE are message types not methods! Adriano From: Robert Cragie [mailto:robert.cragie@gridmerge.com] Sent: venerd=EC 28 maggio 2010 11.53 To: Adriano Pezzuto (apezzuto) Cc: Paul Duffy (paduffy); Zach Shelby; core Subject: Re: [core] Subscribe/Notify for CoAP I think the point here is that there are two levels we are considering. At the lowest (foundation) level, there are the transaction messages as described below. This provides a flexible mechanism for the application with regard to synchronicity and threading. This is important for the types of devices CoAP is being aimed at. Above that, the methods can be used according to the architectural style. So in this case, it is RESTful (COnstrained Restful Environments), which will naturally limit the number of methods and how transactions occur. The actual architecture using a combination of the methods and messages also depends on what is required at the application layer. Consider a typical client which wants to subscribe to a resource. That client controls the feed of data but needs a component which is capable of handling (possibly buffering) the data it receives through notifications. Is this a separate server? Or would we want to consider it part of an enhanced client model which is able to process feeds of data? These are the sort of models which have led to the myriad of solutions (GENA, Webhooks, long polling, pubsubhubbub, RESTMS etc.) based around HTTP which are all essentially ingenious ways of getting around the limitations imposed by HTTP and how it is processed for anything which deviates from the classic web page access model. I think the aim of CoAP should be clean from the word go with regard to supporting these more peer-to-peer transactions, where the client can exist on either entity and both entities can feed data to each other; typical in M2M applications. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 27/05/2010 7:08 PM, Adriano Pezzuto (apezzuto) wrote: Hi Robert, in my personal opinion, the option 1a) brings some sort of ambiguity to CoAP specs. My be my understatement of new CoAP specs is not so deep, but now we have 5 methods and 3 message types: request, response and notify. Which methods are allowed with which messages types? I suppose you have to use PUT/POST method with notify message for asynch data notification. How to make a subscribe? I suppose you would use a SUBSCRIBE method with request/response message or SUBSCRIBE with notify message? Also what about POST/DELETE methods in a notify message? They not make any sense.. I think the choice is between: option 1) -> only CRUD methods and option 1b) -> CRUD + SUB/NOTIFY methods, keeping in mind cost/benefits of both solutions. Adriano From: Robert Cragie [mailto:robert.cragie@gridmerge.com] Sent: mercoled=EC 26 maggio 2010 20.09 To: Adriano Pezzuto (apezzuto) Cc: Paul Duffy (paduffy); Zach Shelby; core Subject: Re: [core] Subscribe/Notify for CoAP Hi Adrian, I would also prefer to keep the protocol in CoAP asynchronous. You can always map an asynchronous protocol to a synchronous one but, as we see in HTTP, it always ends up as a kludge to do it the other way round. The efforts which have been gone to to make HTTP quasi-asynchronous via all the schemes mentioned below and many more besides (all non-interoperable of course) is testament to how important this is for M2M communication. So, back to Zach's list, I favor 1a) for the following reasons: Foundation level of messages: 1. request/response can be asynchronous or synchronous messages (as there is a transaction ID in there) 2. notify is an asynchronous message Derived methods: I think it makes sense to add a pub/sub model as a useful mechanism for M2M. So, looking at it the other way round: It will be entirely possible to translate whatever is currently built on HTTP to CoAP based on the above, with all its restrictions regarding synchronous and client/server transactions. What may be harder is to translate directly is a CoAP-based application to HTTP. So I guess the question is: Do we want to be hamstrung to synchronous client/server transactions as dictated by HTTP and provide a direct mapping to HTTP, then have to come up with similar kludges for asynchronous peer-to-peer transactions as has been done in numerous ways for HTTP, or do we want to define the protocol cleanly to start with and accept that some sort of transaction relaying/conversion would have to take place at a mapping node? Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote: Hi, it looks to me that CoAP should use an explicit sub/notify mechanism since this is the core of the machine-to-machine interaction model. HTTP suffers of this lack and we have seen a plethora of solutions to give an asynch taste to it. Webhooks and websockets are only the lasts of the list. As someone has already pointed out on this list, it is theoretically possible to describe sub/notify using only CRUD methods but it looks a little bit tricky and verbose. Now we have a chance to build from scratch a new protocol with and I think using explicit sub/notify methods with a clear and well defined semantic is the best option. It is easily understanding from every developer and will prevent to build other fanny solutions on top of the CoAP. HTTP does not have this well defined semantic and (for hundreds of other reasons also) it is not used as wide protocol for machine-to-machine communication. CoAP - as binary protocol - and with an explicit asynch model has a chance to be a really wide protocol for M2M communication not only for constrained environments. my 2 cents - adriano -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Paul Duffy (paduffy) Sent: mercoled=EC 26 maggio 2010 0.47 To: Zach Shelby Cc: core Subject: Re: [core] Subscribe/Notify for CoAP On 5/25/2010 6:41 PM, Zach Shelby wrote: Hi, On May 26, 2010, at 12:23 AM, Charles Palmer wrote: Hi folks It occurs to me that CoRE should be keeping a close eye on ZigBee SE2.0 work, so that it is as easy as possible for ZigBee SE to use CoRE when ready. That suggests to me that we should align with their subscribe/notify process. I am not sure I understand that. I mean, ZigBee SE2.0 is defining an application specific subscribe/notify mechanism for that purpose so far for HTTP. This uses standard HTTP methods and some custom payload and REST interfaces. CoAP Req/Res is already totally compatible with SE2.0 in that respect, so alignment is already OK there. Nothing stopping someone from using SE2.0 over CoAP. Specifying a native susbcription/notify into CoAP is another matter. We can't adopt a solution specific to one application as that won't solve the problems of other applications nor general HTTP mapping at all (probably would make it worse). It seems that for the near future there will be a bunch of HTTP push mechanisms in use without any clear standard appearing - or am I wrong there? If COAP extends HTTP semantics with new subscription methods, it will not be possible to easily interchange HTTP/COAP, and translation gateways will become more complex to implement. Zach Regards - Charles -----Original Message----- From: core-bounces@ietf.org [ mailto:core-bounces@ietf.org] On Behalf Of Paul Duffy Sent: 25 May 2010 03:48 To: Zach Shelby Cc: core Subject: Re: [core] Subscribe/Notify for CoAP Recommend something like #2, primarily to avoid introducing non HTTP method semantics, simplifying HTTP/COAP translation.gateways, etc. On 5/24/2010 11:49 AM, Zach Shelby wrote: (thread renamed) We have two different paths with regard to a subscribe/notify mechanism for CoAP: 1. Use specific Subscription and Notify mechanisms for CoAP as HTTP really does not include this concept. 1a) Notify as a message and SUBSCRIBE as a method. This is currently used in coap-01. 1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but we had a good list discussion about this leading to a. In practice it doesn't make a big difference if notification is a message or method. 2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2.0 proposal or GENA. So far we have focused on 1 in the WG, and every now and again 2 comes up. At least I am not convinced that we need to suffer the drawbacks of HTTP here. Anyways 2 does not help our mapping to HTTP in reality very much as there is no standard way of doing this over HTTP. Thus a CoAP-HTTP proxy may end up anyways translating between multiple HTTP frameworks depending on the application. So instead of doing a CoAP Notify/Subscribe to Webhooks mapping, you will could end up having to do a CoAP Webhooks to HTTP GENA mapping. I don't understand this last para. If CoAP sticks to the semantics of the current HTTP methods, would this not offer a fairly straightforward translation to/from HTTP? From what I have heard so far 1 still seems like a wise choice, although I need to look at Webhooks more deeply. In reality many applications specify their own way of doing a push interface using REST methods and specific payloads (ZigBee SE2.0 is such an example). That is just fine, and might be used instead of a specific CoAP notify/subscribe in that case. So 1 doesn't prevent the application using its own mechanism, it just provides a native way for doing push. What do people think? Zach On May 17, 2010, at 6:44 PM, matthieu.vial@fr.non.schneider-el= ectric.com wrote: Hi, My comments about the subscribe/notify mechanism of Zigbee IP. Pros: - Derived from the webhooks concept - If used by CORE it will be easier to map to HTTP because it uses only CRUD verbs. - The subscription message is extendable and could support advanced options (delays, increment, ...) - Only one listening port whatever the transport binding is. Cons: - No interoperability without well known URIs and a well defined subscription message format (Not sure CoAP draft is the right place to specify this). - XML/EXI is too complex to be the required format for the default subscription/notifica= tion mechanism. - The notification should not require a subsequent GET to retrieve the content. - Subresource subscription is redundant. Hope this could help, Matthieu "Charles Palmer" "Charles Palmer" Envoy=E9 par : core-bounces@ietf.org 15/05/2010 14:06 A "core" cc Objet Re: [core] Selecting a WG document for CoAP Dear all Those interested in the subscribe/notify discussion might like to look at the draft Smart Energy Profile 2.0 Application Protocol Specification. It is available here: http://zigbee.org/Mar= kets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicApp licationProfile.aspx It manages subscribe/notify by using POST. This seems to remove the need for SUBSCRIBE and notify. "Imagine a host A, which exposes a resource at http {s}://A/resource and a second host B, which wishes to learn of changes to this resource. To facilitate a subscription/ notification mechanism, A would expose a resource http {s}://A/sub and B would expose a resource http {s}://B/ntfy. To subscribe to notifications regarding http {s}://A/resource, B would send a POST to the address http {s}://A/sub/B containing the URI of the resource of interest (http {s}://A/resource) and the URI of B's notification resource (http{s}://B/ntfy). Following this subscription step, should A wish to notify B of a change to the resource addressed at http{s}://A/resource, A would send a POST to the address http{s}://B/ntfy containing the URI of the resource changed (http {s}://A/resource) and the URI of A's subscription resource (http{s}://A/sub/B), should A wish to change its subscription. The host B can then query the resource (or not) at its leisure." Sleepy nodes are not allowed to subscribe, and must poll. Regards - Charles Palmer -----Original Message----- From: core-bounces@ietf.org [ mailto:core-bounces@i= etf.org ] On Behalf Of Angelo P. Castellani Sent: 14 May 2010 13:14 To: Zach Shelby Cc: core Subject: Re: [core] Selecting a WG document for CoAP Zach, thanks for the comments, but please refer to my most recent e-mail for a more specific list of technical issues I'm pointing to. I want to do only a little integration to what I've written there. In my very personal opinion, to maximize adherence with the REST model and minimize implementation effort SUBSCRIBE and NOTIFY should be mapped to methods (as discussed many times together...). Uniform interface principle (Fielding PhD dissertation Section 5.1.5, "The central feature that distinguishes the REST architectural style [...]") states that to simplify the software architecture, resource interfaces/interfaces should be as general as possible. I agree with this principle in this specific case, mainly because handling a special message type for notify leads node software design to a more complex architecture. The reason is that this new message type requires special handling and introduces a complexity in the software modularization. Best, Angelo On Fri, May 14, 2010 at 13:06, Zach Shelby wrote: Hi Angelo, On May 13, 2010, at 14:24 , Angelo P. Castellani wrote: Dear C. Bormann, all, before deciding for the final direction, I've the following observations about draft-shelby-core-coap-01 While I mostly share Zach's view of the protocol approach, and appreciate many aspects of the proposal, there are in my opinion still some open issues that need to be at least discussed before the current document can be selected. Of course there are plenty of open issues. Remember that working group documents still undertake as much change and improvement as the WG wants, so by no means is coap-01 set in stone. I would expect at least 5-10 more revisions still along the way. Already several of your ideas have been integrated into coap-01, and several more are under consideration, so it is coming along. Patience ;-) In particular, I would like to highlight the following: a) As it is now, it is not possible to have a straightforward translation of HTTP -> CoAP and viceversa: see http://www.ietf.org/mail-archive/web/core/current/msg00133.html (this impacts the scalability of the web service model too) In coap-01 the Method names are now identical to HTTP methods. The Req/Res interaction is a direct translation. The URI hierarchy is compatible, and the URI binary code format we are still working on obviously. The only thing that takes some state to translate is Subscribe/Notify. But note, Subscribe/Notify takes some state no matter how you do it, even with HTTP-HTTP there is no clean and easy way to handle subscriptions. b) Moreover, CoAP's implementation is not as simple as it should be. I've investigated the implementation and some design choices (as Options) are leading to very high program complexity (ROM) on a MSP430-based device. This we can definitely improve, and already made several optimizations from -00 to -01. Here I need some very concrete proposals though. Also remember that many things are optional, for example subscribe/notify is not required if you don't need it. c) Finally when comparing HTTP message size with CoAP message size, the resulting compression isn't as good as you may expect. Example: HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B CoAP: 24 B with options parsing procedure requiring an added implementation complexity Right, that is not how it will work in practice. Working with a real HTTP server that HTTP header will be more complex, and on the CoAP side you would chose shorter URLs. The biggest improvement possible here is from using binary coded URLs of course. We need to look at a wider range of interactions and real HTTP headers as well to check that we are efficient enough. Addressing all these points potentially leads to major technical modifications (especially point a) on the current draft, hence it is appropriate in my opinion to discuss these points before making the final decision. I am not sure what else you have in mind for a). If we just forget about Subscribe/Notify then you are good to go. But then you are also not fulfilling the charter or the industry needs in that respect. Thanks, Zach Best regards, Angelo P. Castellani On Mon, May 10, 2010 at 18:51, Carsten Bormann wrote: The CORE WG has a milestone to select a WG document for CoAP in April: http://datatracker.ietf.org/wg/core/charter/ ... Apr 2010 Select WG document for basis of the CoAP protocol Of the various documents that have been contributed, draft-shelby-core-coap has significant discussion, as well as the largest number of updates (including a previous version that was still called -6lowapp-coap). Today, another updated version of that draft was announced. See http://www.ietf.org/mail-archive/web/core/current/msg00138.h= tml for the announcement and http://tools.ietf.org/html/draft-shelby-core-coap-01 for the draft itself. However, as the authors say, there are still significant TODOs. Are we in a state yet where we can say whether this is the right direction for the WG to take? If yes, is it the right direction? Should we adopt it as a WG document? If you don't think we can say yet, is there a set of technical decisions you would like the authors to take with priority? Note that once a document has become a WG document, the authors act as editors for the working group, making (and usually fleshing out the details of) any change that the WG decides it needs. If you think we can still improve the draft, this is not an obstacle to making it a WG document. But of course we shouldn't do that if we intend to reverse its fundamental technical direction. In order to stay roughly in sync with our milestones, we should reach at a decision on how to go forward this week. Gruesse, Carsten =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://za= chshelby.org - My blog "On the Internet of Things " http://6l= owpan.net - My book " 6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 =5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F core mailing list core@ietf.org https://www.ietf.org/= mailman/listinfo/core ---------------------= ----------- Onzo is a limited company number 06097997 registered in England& Wales. The registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingdom. This email message may contain confidential and/or privileged information, and is intended solely for the addressee(s). If you have received this email in error, please notify Onzo immediately. Unauthorised copying, disclosure or distribution of the material in this email is forbidden. ---------------------= ----------- =5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F core mailing list core@ietf.org https://www.ietf.org/= mailman/listinfo/core =5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F This email has been scanned by the MessageLabs Email Security System. =5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F core mailing list core@ietf.org https://www.ietf.org/= mailman/listinfo/core =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core -------------------------------- Onzo is a limited company number 06097997 registered in England& Wales. The registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingdom. This email message may contain confidential and/or privileged information, and is intended solely for the addressee(s). If you have received this email in error, please notify Onzo immediately. Unauthorised copying, disclosure or distribution of the material in this email is forbidden. -------------------------------- =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F This email has been scanned by the MessageLabs Email Security System. =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core --1__=4EBBFDA2DFD074F58f9e8a93df938690918c4EBBFDA2DFD074F5 Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Hi Robert,

>I am not sure what you mean here. Do you mean that some other client ca= n subscribe to be notified whenever some method is acted upon for a particu= lar resource? Can you describe the transaction model?
Excatly I want to be notified when a resource is deleted b= ut not just updated for example. So I send a subscribe message and the meth= od of that message is delete.

But the main usage of subscribe will be notifications upon= modification of a resource, so I'am fine with subscribe as method and noti= fy as message. Dynamic resources will probably be part of a collection, so = we can still monitor the modifications of the collection instead of an indi= vidual item.

Matthieu

Robert

3D"InactiveRobert Cragie <robert.cragie@g= ridmerge.com>




          Robert Cragie <robert.cragie@gridmerge.com>

          28/05/2010 14:08
          Veuillez r=E9pondre =E0
          robert.cragie@gridmerge.com
3D"=
A
3D""
Matthieu Vial/FR/Non/Schneider@Europe
3D"=
cc
3D""
"Adriano Pezzuto (apezzuto)" <apezzuto@cisco.= com>, core <core@ietf.org>, core-bounces@ietf.org
3D"=
Objet
3D""
Re: [core] Subscribe/Notify for CoAP
3D""=3D""

Hi Matthieu,

I am not sure what you mean here. Do you mean that some other client can su= bscribe to be notified whenever some method is acted upon for a particular = resource? Can you describe the transaction model?

Robert

Robert Cragie (Pacific Gas & Elect= ric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com


On 28/05/2010 12:51 PM, matthieu.vial@fr.n= on.schneider-electric.com wrote:

      > So strictly sp= eaking, both NOTIFY and SUBSCRIBE are message types not methods!

      SUBSCRIBE can be just an asynchronous GET on update then I think it is a me= thod and NOTIFY is an asynchronous response so a message.
      But if we want to have selective notifications when a resource is created, = updated or deleted then I think you're right NOTIFY and SUBSCRIBE are messa= ges.

      Does that make sense ?

      Matthieu

      3D"Inactive"Adriano Pezzuto (apezzuto)" <apezzuto@cisco.com>
      A

      <robert.cragie@gridmerge.com>
      cc

      core <core@i= etf.org>
      Objet

      Re: [core] Subscribe/Notify for CoAP

      Hi Roberto,
      I understand your point and personally agree on M2M is quite different from= web page model. On the architectural RESTful style, the method information= tells the server what to do with data kept in the URI information.      <= font size=3D"4">

      So strictly speaking, both NOTIFY and SUBSCRIBE are message types not meth= ods!

      Adriano

      From:       Robert Cragie [mailto:robert.cragie@gridmerge.com]       =
      Sent:       venerd=EC 28 maggio 2010 = 11.53
      To:       Adriano Pezzuto (apezzuto)<= /font>
      Cc:       Paul Duffy (paduffy); Zach = Shelby; core
      Subject:       Re: [core] Subscribe/N= otify for CoAP

      I think the point here is that there are two levels we are considering.

      At the lowest (foundation) level, there are the transaction messages as des= cribed below. This provides a flexible mechanism for the application with r= egard to synchronicity and threading. This is important for the types of de= vices CoAP is being aimed at.

      Above that, the methods can be used according to the architectural style. S= o in this case, it is RESTful (COnstrained Restful Environments), which wil= l naturally limit the number of methods and how transactions occur.

      The actual architecture using a combination of the methods and messages als= o depends on what is required at the application layer. Consider a typical = client which wants to subscribe to a resource. That client controls the fee= d of data but needs a component which is capable of handling (possibly buff= ering) the data it receives through notifications. Is this a separate serve= r? Or would we want to consider it part of an enhanced client model which i= s able to process feeds of data? These are the sort of models which have le= d to the myriad of solutions (GENA, Webhooks, long polling, pubsubhubbub, R= ESTMS etc.) based around HTTP which are all essentially ingenious ways of g= etting around the limitations imposed by HTTP and how it is processed for a= nything which deviates from the classic web page access model.

      I think the aim of CoAP should be clean from the word go with regard to sup= porting these more peer-to-peer transactions, where the client can exist on= either entity and both entities can feed data to each other; typical in M2= M applications.

      Robert

      Robert Cragie (Pacific Gas & Elect= ric)

      Gridmerge Ltd.
      89 Greenfield Crescent,
      Wakefield, WF4 4WA, UK
      +44 1924 910888
      +1 415 513 0064
      http://www.gridmerge.com

      On 27/05/2010 7:08 PM, Adriano Pezzuto (apezzuto) wrote:
      Hi Robert,

      in my personal opinion, the option 1a) brings some sort of ambiguity to CoA= P specs.

      My be my understatement of new CoAP specs is not so deep, but now we have 5= methods and 3 message types: request, response and notify. Which methods a= re allowed with which messages types?
      I suppose you have to use PUT/POST method with notify message for asynch da= ta notification. How to make a subscribe? I suppose you would use a SUBSCRI= BE method with request/response message or SUBSCRIBE with notify message? A= lso what about POST/DELETE methods in a notify message? They not make any s= ense..

      I think the choice is between: option 1) -> only CRUD methods and option= 1b) -> CRUD + SUB/NOTIFY methods, keeping in mind cost/benefits of both= solutions.

      Adriano

      From:       Robert Cragie [mailto:robert.cragie@gridmerge.com]       =
      Sent:       mercoled=EC 26 maggio 201= 0 20.09
      To:       Adriano Pezzuto (apezzuto)<= /font>
      Cc:       Paul Duffy (paduffy); Zach = Shelby; core
      Subject:       Re: [core] Subscribe/N= otify for CoAP

      Hi Adrian,

      I would also prefer to keep the protocol in CoAP asynchronous. You can alwa= ys map an asynchronous protocol to a synchronous one but, as we see in HTTP= , it always ends up as a kludge to do it the other way round. The efforts w= hich have been gone to to make HTTP quasi-asynchronous via all the schemes = mentioned below and many more besides (all non-interoperable of course) is = testament to how important this is for M2M communication.

      So, back to Zach's list, I favor 1a) for the following reasons:

      Foundation level of messages:

          1. re= quest/response can be asynchronous or synchronous messages (as there is a t= ransaction ID in there)
          2.           notify is an asynchrono= us message
      Derived methods:

      I think it makes sense to add a pub/sub model as a useful mechanism for M2M= .

      So, looking at it the other way round: It will be entirely possible to tran= slate whatever is currently built on HTTP to CoAP based on the above, with = all its restrictions regarding synchronous and client/server transactions. = What may be harder is to translate directly is a CoAP-based application to = HTTP. So I guess the question is: Do we want to be hamstrung to synchronous= client/server transactions as dictated by HTTP and provide a direct mappin= g to HTTP, then have to come up with similar kludges for asynchronous peer-= to-peer transactions as has been done in numerous ways for HTTP, or do we w= ant to define the protocol cleanly to start with and accept that some sort = of transaction relaying/conversion would have to take place at a mapping no= de?

      Robert

      Robert Cragie (Pacific Gas & Elect= ric)

      Gridmerge Ltd.
      89 Greenfield Crescent,
      Wakefield, WF4 4WA, UK
      +44 1924 910888
      +1 415 513 0064
      http://www.gridmerge.com

      On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote:
      Hi,
      it looks to me that CoAP should use an explicit sub/notify mechanism since = this is the core of the machine-to-machine interaction model.
      HTTP suffers of this lack and we have seen a plethora of solutions to give = an asynch taste to it. Webhooks and websockets are only the lasts of the li= st.
      As someone has already pointed out on this list, it is theoretically possib= le to describe sub/notify using only CRUD methods but it looks a little bit= tricky and verbose.

      Now we have a chance to build from scratch a new protocol with and I think = using explicit sub/notify methods with a clear and well defined semantic is= the best option. It is easily understanding from every developer and will = prevent to build other fanny solutions on top of the CoAP. HTTP does not ha= ve this well defined semantic and (for hundreds of other reasons also) it i= s not used as wide protocol for machine-to-machine communication.

      CoAP - as binary protocol - and with an explicit asynch model has a chance = to be a really wide protocol for M2M communication not only for constrained= environments.

      my 2 cents

      - adriano

      -----Original Message-----
      From:       core-bounces@ietf.org<= font size=3D"5" face=3D"Courier New"> [      mail= to:core-bounces@ietf.org

      On 5/25/2010 6:41 PM, Zach Shelby wrote:

              Hi,

              On May 26, 2010, at 12:23 AM, Charles Palmer wrote:              =

                      Hi folks<= br>
                      It occurs to me that CoRE should be keeping a close eye on ZigBee SE2.0 wor= k, so that it is as easy as possible for ZigBee SE to use CoRE when ready. = That suggests to me that we should align with their subscribe/notify proces= s.

              I am not sure I understand that. I me= an, ZigBee SE2.0 is defining an application specific subscribe/notify mecha= nism for that purpose so far for HTTP. This uses standard HTTP methods and = some custom payload and REST interfaces. CoAP Req/Res is already totally co= mpatible with SE2.0 in that respect, so alignment is already OK there. Noth= ing stopping someone from using SE2.0 over CoAP.

              Specifying a native susbcription/notify into CoAP is another matter. We can= 't adopt a solution specific to one application as that won't solve the pro= blems of other applications nor general HTTP mapping at all (probably would= make it worse). It seems that for the near future there will be a bunch of= HTTP push mechanisms in use without any clear standard appearing - or am I= wrong there?



      If COAP extends HTTP semantics with new subscription methods, it will
      not be possible to easily interchange HTTP/COAP, and translation
      gateways will become more complex to implement.
              Zach
                      Regards - Charles


                      -----Original Message-----
                      From:                       core-bounces@ietf.org<= font size=3D"5" face=3D"Courier New"> [mail= to:core-bounces@ietf.org

                      Recommend something like #2, primarily to avoid introducing non HTTP
                      method semantics, simplifying HTTP/COAP translation.gateways, etc.


                      On 5/24/2010 11:49 AM, Zach Shelby wrote:
                              (thread renamed)

                              We have two different paths with regard to a subscribe/notify mechanism for= CoAP:

                              1. Use specific Subscription and Notify mechanisms for CoAP as HTTP really = does not include this concept.
                              1a) Notify as a message and SUBSCRIBE as a method. This is currently used i= n coap-01.
                              1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but we had a= good list discussion about this leading to a. In practice it doesn't make = a big difference if notification is a message or method.

                              2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2.0 propos= al or GENA.

                              So far we have focused on 1 in the WG, and every now and again 2 comes up. = At least I am not convinced that we need to suffer the drawbacks of HTTP he= re. Anyways 2 does not help our mapping to HTTP in reality very much as the= re is no standard way of doing this over HTTP. Thus a CoAP-HTTP proxy may e= nd up anyways translating between multiple HTTP frameworks depending on the= application. So instead of doing a CoAP Notify/Subscribe to Webhooks mappi= ng, you will could end up having to do a CoAP Webhooks to HTTP GENA mapping= .


                      I don't understand this last para. If CoAP sticks to the semantics of
                      the current HTTP methods, would this not offer a fairly straightforward
                      translation to/from HTTP?
                                      From what I have heard so far 1 s= till seems like a wise choice, although I need to look at Webhooks more dee= ply. In reality many applications specify their own way of doing a push int= erface using REST methods and specific payloads (ZigBee SE2.0 is such an ex= ample). That is just fine, and might be used instead of a specific CoAP not= ify/subscribe in that case. So 1 doesn't prevent the application using its = own mechanism, it just provides a native way for doing push.
                              What do people think?

                              Zach

                              On May 17, 2010, at 6:44 PM,                               matthieu.vial@fr.non.schneider-electric.com wrote:
                                      Hi,

                                      My comments about the subscribe/notify mechanism of Zigbee IP.

                                      Pros:
                                      - Derived from the webhooks concept
                                      - If used by CORE it will be easier to map to HTTP because it uses only CRU= D verbs.
                                      - The subscription message is extendable and could support advanced options= (delays, increment, ...)
                                      - Only one listening port whatever the transport binding is.

                                      Cons:
                                      - No interoperability without well known URIs and a well defined subscripti= on message format (Not sure CoAP draft is the right place to specify this).=
                                      - XML/EXI is too complex to be the required format for the default subscrip= tion/notification mechanism.
                                      - The notification should not require a subsequent GET to retrieve the cont= ent.
                                      - Subresource subscription is redundant.

                                      Hope this could help,
                                      Matthieu


                                      <graycol.gif>"Charles Palmer"                                      <charles.palmer@onzo.com>




                                      "Charles Palmer"                                      <charles.pal= mer@onzo.com>
                                      Envoy=E9 par :                                       core-bounces@ietf.org=
                                      15/05/2010 14:06

                                      <ecblank.gif>
                                      A
                                      <ecblank.gif>
                                      "core"                                      <core@ietf.org>
                                      <ecblank.gif>
                                      cc
                                      <ecblank.gif>
                                      <ecblank.gif>
                                      Objet
                                      <ecblank.gif>
                                      Re: [core] Selecting a WG document for CoAP
                                      <ecblank.gif> <ecblank.gif>

                                      Dear all

                                      Those interested in the subscribe/notify discussion might like to look
                                      at the draft Smart Energy Profile 2.0 Application Protocol
                                      Specification. It is available here:
                                      http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicA= pp
                                      licationProfile.aspx

                                      It manages subscribe/notify by using POST. This seems to remove the need
                                      for SUBSCRIBE and notify.

                                      "Imagine a host A, which exposes a resource at http{s}://A/resource an= d
                                      a second host B, which wishes to learn of changes to this resource. To
                                      facilitate a subscription/ notification mechanism, A would expose a
                                      resource http{s}://A/sub and B would expose a resource http{s}://B/ntfy.
                                      To subscribe to notifications regarding http{s}://A/resource, B would
                                      send a POST to the address http{s}://A/sub/B containing the URI of the
                                      resource of interest (http{s}://A/resource) and the URI of B's
                                      notification resource (http{s}://B/ntfy). Following this subscription
                                      step, should A wish to notify B of a change to the resource addressed at
                                      http{s}://A/resource, A would send a POST to the address
                                      http{s}://B/ntfy containing the URI of the resource changed
                                      (http{s}://A/resource) and the URI of A's subscription resource
                                      (http{s}://A/sub/B), should A wish to change its subscription. The host
                                      B can then query the resource (or not) at its leisure."

                                      Sleepy nodes are not allowed to subscribe, and must poll.

                                      Regards - Charles Palmer

                                      -----Original Message-----
                                      From:                                       core-bounces@ietf.org<= font size=3D"5" face=3D"Courier New"> [mail= to:core-bounces@ietf.org

                                      Zach,

                                      thanks for the comments, but please refer to my most recent e-mail for
                                      a more specific list of technical issues I'm pointing to.

                                      I want to do only a little integration to what I've written there.

                                      In my very personal opinion, to maximize adherence with the REST model
                                      and minimize implementation effort SUBSCRIBE and NOTIFY should be
                                      mapped to methods (as discussed many times together...).

                                      Uniform interface principle (Fielding PhD dissertation Section 5.1.5,
                                      "The central feature that distinguishes the REST architectural style [...]") states that to simplify the software architecture, resource
                                      interfaces/interfaces should be as general as possible.

                                      I agree with this principle in this specific case, mainly because
                                      handling a special message type for notify leads node software design
                                      to a more complex architecture.

                                      The reason is that this new message type requires special handling and
                                      introduces a complexity in the software modularization.

                                      Best,
                                      Angelo

                                      On Fri, May 14, 2010 at 13:06, Zach Shelby                                      <= zach@sensinode.com>= wrote:
                                              Hi Angelo,

                                              On May 13, 2010, at 14:24 , Angelo P. Castellani wrote:
                                                      Dear C. Bormann, all,

                                                      before deciding for the final direction, I've the following
                                                      observations about draft-shelby-core-coap-01

                                                      While I mostly share Zach's view of the protocol approach, and
                                                      appreciate many aspects of the proposal, there are in my opinion

                                      still
                                                      some open issues that need to be = at least discussed before the

                                      current
                                                      document can be selected.<= font size=3D"4">

                                              Of course there are plenty of open is= sues. Remember that working group

                                      documents still undertake as much cha= nge and improvement as the WG
                                      wants, so by no means is coap-01 set in stone. I would expect at least
                                      5-10 more revisions still along the way. Already several of your ideas
                                      have been integrated into coap-01, and several more are under
                                      consideration, so it is coming along. Patience ;-)                                      <= br>
                                                      In particular, I would like to hi= ghlight the following:

                                                      a) As it is now, it is not possible to have a straightforward
                                                      translation of HTTP -> CoAP and viceversa: see
                                                      http= ://www.ietf.org/mail-archive/web/core/current/msg00133.html<= font size=3D"5" face=3D"Courier New"> (this
                                                      impacts the scalability of the web service model too)

                                              In coap-01 the Method names are now i= dentical to HTTP methods. The

                                      Req/Res interaction is a direct trans= lation. The URI hierarchy is
                                      compatible, and the URI binary code format we are still working on
                                      obviously. The only thing that takes some state to translate is
                                      Subscribe/Notify. But note, Subscribe/Notify takes some state no matter
                                      how you do it, even with HTTP-HTTP there is no clean and easy way to
                                      handle subscriptions.
                                                      b) Moreover, CoAP's implementatio= n is not as simple as it should be.
                                                      I've investigated the implementation and some design choices (as
                                                      Options) are leading to very high program complexity (ROM) on a
                                                      MSP430-based device.

                                              This we can definitely improve, and a= lready made several optimizations

                                      from -00 to -01. Here I need some ver= y concrete proposals though. Also
                                      remember that many things are optional, for example subscribe/notify is
                                      not required if you don't need it.
                                                      c) Finally when comparing HTTP me= ssage size with CoAP message size,
                                                      the resulting compression isn't as good as you may expect.

                                                      Example:
                                                      HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B
                                                      CoAP: 24 B with options parsing procedure requiring an added
                                                      implementation complexity

                                              Right, that is not how it will work i= n practice. Working with a real

                                      HTTP server that HTTP header will be = more complex, and on the CoAP side
                                      you would chose shorter URLs. The biggest improvement possible here is
                                      from using binary coded URLs of course. We need to look at a wider range
                                      of interactions and real HTTP headers as well to check that we are
                                      efficient enough.
                                                      Addressing all these points poten= tially leads to major technical
                                                      modifications (especially point a) on the current draft, hence it is
                                                      appropriate in my opinion to discuss these points before making the
                                                      final decision.

                                              I am not sure what else you have in m= ind for a). If we just forget

                                      about Subscribe/Notify then you are g= ood to go. But then you are also
                                      not fulfilling the charter or the industry needs in that respect.
                                              Thanks,
                                              Zach
                                                      Best regards,

                                                      Angelo P. Castellani


                                                      On Mon, May 10, 2010 at 18:51, Carsten Bormann                                                      <ca= bo@tzi.org> wrote:<= /font>
                                                              The CORE WG has a milestone to se= lect a WG document for CoAP in

                                      April:

                                       draft-shelby-core-coap has significan= t discussion, as well as the
                                      largest number of updates (including a previous version that was still
                                      called -6lowapp-coap).

                                                                             direction for the WG to take?<= font size=3D"4">
                                                              If yes, is it the right direction= ? Should we adopt it as a WG

                                      document?
                                                              If you don't think we can say yet= , is there a set of technical

                                      decisions you would like the authors = to take with priority?
                                                              Note that once a document has bec= ome a WG document, the authors act

                                      as editors for the working group, mak= ing (and usually fleshing out the
                                      details of) any change that the WG decides it needs.
                                                              If you think we can still improve= the draft, this is not an obstacle

                                      to making it a WG document.

                                                              But of course we shouldn't do tha= t if we intend to reverse its

                                      fundamental technical direction.
                                                              In order to stay roughly in sync = with our milestones, we should

                                      reach at a decision on how to go forw= ard this week.

                                       =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
                                      core mailing list
                                      core@ietf.org
                                      https://www.ietf.org/mail= man/listinfo/core

                                      --------------------------------
                                      Onzo is a limited company number 06097997 registered in England& Wales.= The
                                      registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingd= om.

                                      This email message may contain confidential and/or privileged information, = and
                                      is intended solely for the addressee(s). If you have received this email in=
                                      error, please notify Onzo immediately. Unauthorised copying, disclosure or<= br> distribution of the material in this email is forbidden.
                                      --------------------------------

                                      =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
                                      core mailing list
                                      core@ietf.org
                                      https://www.ietf.org/mail= man/listinfo/core

                                      =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
                                      This email has been scanned by the MessageLabs Email Security System.
                                      =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F

                                      =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
                                      core mailing list
                                      core@ietf.org
                                      https://www.ietf.org/mail= man/listinfo/core

                      =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
                      core mailing list
                      core@ietf.org
                      https://www.ietf.org/mail= man/listinfo/core

                      --------------------------------
                      Onzo is a limited company number 06097997 registered in England& Wales.= The
                      registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingd= om.

                      This email message may contain confidential and/or privileged information, = and
                      is intended solely for the addressee(s). If you have received this email in=
                      error, please notify Onzo immediately. Unauthorised copying, disclosure or<= br> distribution of the material in this email is forbidden.
                      --------------------------------


      =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
      core mailing list
      core@ietf.org
      https://www.ietf.org/mail= man/listinfo/core
      =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
      core mailing list
      core@ietf.org
      https://www.ietf.org/mail= man/listinfo/core



      =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
      This email has been scanned by the MessageLabs Email Security System.
      =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F      =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F
      core mailing list
      core@ietf.org
      = https://www.ietf.org/mailman/listinfo= /core

--1__=4EBBFDA2DFD074F58f9e8a93df938690918c4EBBFDA2DFD074F5-- --0__=4EBBFDA2DFD074F58f9e8a93df938690918c4EBBFDA2DFD074F5 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <2__=4EBBFDA2DFD074F58@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=4EBBFDA2DFD074F58f9e8a93df938690918c4EBBFDA2DFD074F5 Content-type: image/gif; name="pic29309.gif" Content-Disposition: inline; filename="pic29309.gif" Content-ID: <3__=4EBBFDA2DFD074F58@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=4EBBFDA2DFD074F58f9e8a93df938690918c4EBBFDA2DFD074F5 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <4__=4EBBFDA2DFD074F58@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=4EBBFDA2DFD074F58f9e8a93df938690918c4EBBFDA2DFD074F5-- From zach@sensinode.com Fri May 28 05:50:33 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 533BC3A6802 for ; Fri, 28 May 2010 05:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+qPqroHL24k for ; Fri, 28 May 2010 05:50:30 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 059613A6781 for ; Fri, 28 May 2010 05:50:29 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o4SCoAHT016048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 28 May 2010 15:50:10 +0300 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: Zach Shelby In-Reply-To: <0D212BD466921646B58854FB79092CEC021F4EF2@XMB-AMS-106.cisco.com> Date: Fri, 28 May 2010 15:50:12 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6A9FCAC7-E2FA-482D-ABFF-DB6B111A9EA2@sensinode.com> References: <0D212BD466921646B58854FB79092CEC021F4E91@XMB-AMS-106.cisco.com> <0D212BD466921646B58854FB79092CEC021F4EF2@XMB-AMS-106.cisco.com> To: Adriano Pezzuto (apezzuto) X-Mailer: Apple Mail (2.1078) Cc: core Subject: Re: [core] Subscribe/Notify for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 12:50:33 -0000 Hi, This is a really good conversation. One thing we need to do is remember = what our minimum requirements are for subscribe/notify and not try to = solve something more than we should. =46rom what I know it is sufficient = to be able to receive notifications when a URI changes or periodically. = You might consider new URIs under this URI path to be changes to a URI = though...=20 On May 28, 2010, at 3:08 PM, Adriano Pezzuto (apezzuto) wrote: > Hello, > with this flavor, the SUBSCRIBE may be replaced by a simple POST. So = no needs to have an explicit SUBSCRIBE method. This is what coap-01 assumes.=20 > If we want support a more oriented peer-to-peer transaction on CoAP, = it looks to me both SUB and NOTIFY should be treated as messages. The Request/Response model can be used peer-to-peer, and in CoAP you can = even use a Request asynchronously. Additionally, we want a native = RESTful subscribe/notify technique, that is, we want to subscribe to = resources and be susequently notified about those resources when they = change. In that sense, you can think of a subscription as a request to receive = asynchronous notifications about a resource (about a URI). This can be = achieved by: 1. as a SUBSCRIBE Request on the URI with some option indicating the = lifetime as in coap-01, 2. as a Subcsribe message (no methods) on the URI with some option,=20 3. or as a POST Request on the URI with options indicating that this is = actually a subscription and the lifetime. This bends the meaning of = POST quite a bit and might be prone to mistakes? The asynchronous response is a harder one. Can we bend the meaning of a = Request for making asynchronous notifications? Also a notification = includes a URI about a resource on the requestor, which is inverse from = normal Requests in REST. So the options here are: 1. as a Notify message about a URI (no methods) as in coap-01, 2. as a NOTIFY Request about a URI as was in coap-00, 3. hmmm... reusing CRUD methods really doesn't work for this one at = all...=20 I wonder what the HTTP designers would have done if this would have been = a requirement back then? Maybe we should ask them... Zach > =20 > Adriano > =20 > From: matthieu.vial@fr.non.schneider-electric.com = [mailto:matthieu.vial@fr.non.schneider-electric.com]=20 > Sent: venerd=EC 28 maggio 2010 13.52 > To: Adriano Pezzuto (apezzuto) > Cc: core; core-bounces@ietf.org; robert.cragie@gridmerge.com > Subject: Re: [core] Subscribe/Notify for CoAP > =20 > > So strictly speaking, both NOTIFY and SUBSCRIBE are message types = not methods! >=20 > SUBSCRIBE can be just an asynchronous GET on update then I think it is = a method and NOTIFY is an asynchronous response so a message. > But if we want to have selective notifications when a resource is = created, updated or deleted then I think you're right NOTIFY and = SUBSCRIBE are messages. >=20 > Does that make sense ? >=20 > Matthieu >=20 > "Adriano Pezzuto (apezzuto)" >=20 >=20 >=20 >=20 > "Adriano Pezzuto (apezzuto)" =20 > Envoy=E9 par : core-bounces@ietf.org > 28/05/2010 12:50 >=20 > > A > > > > cc > > core > > Objet > > Re: [core] Subscribe/Notify for CoAP > > >=20 > Hi Roberto, > I understand your point and personally agree on M2M is quite different = from web page model. On the architectural RESTful style, the method = information tells the server what to do with data kept in the URI = information. >=20 > So strictly speaking, both NOTIFY and SUBSCRIBE are message types not = methods! >=20 > Adriano=20 >=20 > From: Robert Cragie [mailto:robert.cragie@gridmerge.com]=20 > Sent: venerd=EC 28 maggio 2010 11.53 > To: Adriano Pezzuto (apezzuto) > Cc: Paul Duffy (paduffy); Zach Shelby; core > Subject: Re: [core] Subscribe/Notify for CoAP >=20 > I think the point here is that there are two levels we are = considering. >=20 > At the lowest (foundation) level, there are the transaction messages = as described below. This provides a flexible mechanism for the = application with regard to synchronicity and threading. This is = important for the types of devices CoAP is being aimed at. >=20 > Above that, the methods can be used according to the architectural = style. So in this case, it is RESTful (COnstrained Restful = Environments), which will naturally limit the number of methods and how = transactions occur. >=20 > The actual architecture using a combination of the methods and = messages also depends on what is required at the application layer. = Consider a typical client which wants to subscribe to a resource. That = client controls the feed of data but needs a component which is capable = of handling (possibly buffering) the data it receives through = notifications. Is this a separate server? Or would we want to consider = it part of an enhanced client model which is able to process feeds of = data? These are the sort of models which have led to the myriad of = solutions (GENA, Webhooks, long polling, pubsubhubbub, RESTMS etc.) = based around HTTP which are all essentially ingenious ways of getting = around the limitations imposed by HTTP and how it is processed for = anything which deviates from the classic web page access model. >=20 > I think the aim of CoAP should be clean from the word go with regard = to supporting these more peer-to-peer transactions, where the client can = exist on either entity and both entities can feed data to each other; = typical in M2M applications. >=20 > Robert >=20 > Robert Cragie (Pacific Gas & Electric) >=20 > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 1924 910888 > +1 415 513 0064 > http://www.gridmerge.com >=20 > On 27/05/2010 7:08 PM, Adriano Pezzuto (apezzuto) wrote:=20 > Hi Robert, >=20 > in my personal opinion, the option 1a) brings some sort of ambiguity = to CoAP specs. >=20 > My be my understatement of new CoAP specs is not so deep, but now we = have 5 methods and 3 message types: request, response and notify. Which = methods are allowed with which messages types? > I suppose you have to use PUT/POST method with notify message for = asynch data notification. How to make a subscribe? I suppose you would = use a SUBSCRIBE method with request/response message or SUBSCRIBE with = notify message? Also what about POST/DELETE methods in a notify message? = They not make any sense.. >=20 > I think the choice is between: option 1) -> only CRUD methods and = option 1b) -> CRUD + SUB/NOTIFY methods, keeping in mind cost/benefits = of both solutions. >=20 > Adriano >=20 > From: Robert Cragie [mailto:robert.cragie@gridmerge.com]=20 > Sent: mercoled=EC 26 maggio 2010 20.09 > To: Adriano Pezzuto (apezzuto) > Cc: Paul Duffy (paduffy); Zach Shelby; core > Subject: Re: [core] Subscribe/Notify for CoAP >=20 > Hi Adrian, >=20 > I would also prefer to keep the protocol in CoAP asynchronous. You can = always map an asynchronous protocol to a synchronous one but, as we see = in HTTP, it always ends up as a kludge to do it the other way round. The = efforts which have been gone to to make HTTP quasi-asynchronous via all = the schemes mentioned below and many more besides (all non-interoperable = of course) is testament to how important this is for M2M communication. >=20 > So, back to Zach's list, I favor 1a) for the following reasons: >=20 > Foundation level of messages: >=20 > 1. request/response can be asynchronous or synchronous messages (as = there is a transaction ID in there) > 2. notify is an asynchronous message > Derived methods: >=20 > I think it makes sense to add a pub/sub model as a useful mechanism = for M2M. >=20 > So, looking at it the other way round: It will be entirely possible to = translate whatever is currently built on HTTP to CoAP based on the = above, with all its restrictions regarding synchronous and client/server = transactions. What may be harder is to translate directly is a = CoAP-based application to HTTP. So I guess the question is: Do we want = to be hamstrung to synchronous client/server transactions as dictated by = HTTP and provide a direct mapping to HTTP, then have to come up with = similar kludges for asynchronous peer-to-peer transactions as has been = done in numerous ways for HTTP, or do we want to define the protocol = cleanly to start with and accept that some sort of transaction = relaying/conversion would have to take place at a mapping node? >=20 > Robert > Robert Cragie (Pacific Gas & Electric) >=20 > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 1924 910888 > +1 415 513 0064 > http://www.gridmerge.com >=20 > On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote:=20 > Hi, > it looks to me that CoAP should use an explicit sub/notify mechanism = since this is the core of the machine-to-machine interaction model. > HTTP suffers of this lack and we have seen a plethora of solutions to = give an asynch taste to it. Webhooks and websockets are only the lasts = of the list. > As someone has already pointed out on this list, it is theoretically = possible to describe sub/notify using only CRUD methods but it looks a = little bit tricky and verbose. >=20 > Now we have a chance to build from scratch a new protocol with and I = think using explicit sub/notify methods with a clear and well defined = semantic is the best option. It is easily understanding from every = developer and will prevent to build other fanny solutions on top of the = CoAP. HTTP does not have this well defined semantic and (for hundreds of = other reasons also) it is not used as wide protocol for = machine-to-machine communication. >=20 > CoAP - as binary protocol - and with an explicit asynch model has a = chance to be a really wide protocol for M2M communication not only for = constrained environments. >=20 > my 2 cents >=20 > - adriano >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Paul Duffy (paduffy) > Sent: mercoled=EC 26 maggio 2010 0.47 > To: Zach Shelby > Cc: core > Subject: Re: [core] Subscribe/Notify for CoAP >=20 > On 5/25/2010 6:41 PM, Zach Shelby wrote: >=20 > Hi, >=20 > On May 26, 2010, at 12:23 AM, Charles Palmer wrote: >=20 >=20 > Hi folks >=20 > It occurs to me that CoRE should be keeping a close eye on ZigBee = SE2.0 work, so that it is as easy as possible for ZigBee SE to use CoRE = when ready. That suggests to me that we should align with their = subscribe/notify process. >=20 >=20 > I am not sure I understand that. I mean, ZigBee SE2.0 is defining an = application specific subscribe/notify mechanism for that purpose so far = for HTTP. This uses standard HTTP methods and some custom payload and = REST interfaces. CoAP Req/Res is already totally compatible with SE2.0 = in that respect, so alignment is already OK there. Nothing stopping = someone from using SE2.0 over CoAP. >=20 > Specifying a native susbcription/notify into CoAP is another matter. = We can't adopt a solution specific to one application as that won't = solve the problems of other applications nor general HTTP mapping at all = (probably would make it worse). It seems that for the near future there = will be a bunch of HTTP push mechanisms in use without any clear = standard appearing - or am I wrong there? >=20 >=20 >=20 >=20 > If COAP extends HTTP semantics with new subscription methods, it will=20= > not be possible to easily interchange HTTP/COAP, and translation=20 > gateways will become more complex to implement. >=20 >=20 >=20 > Zach >=20 >=20 > Regards - Charles >=20 >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Paul Duffy > Sent: 25 May 2010 03:48 > To: Zach Shelby > Cc: core > Subject: Re: [core] Subscribe/Notify for CoAP >=20 > Recommend something like #2, primarily to avoid introducing non HTTP > method semantics, simplifying HTTP/COAP translation.gateways, etc. >=20 >=20 > On 5/24/2010 11:49 AM, Zach Shelby wrote: >=20 > (thread renamed) >=20 > We have two different paths with regard to a subscribe/notify = mechanism for CoAP: >=20 > 1. Use specific Subscription and Notify mechanisms for CoAP as HTTP = really does not include this concept. > 1a) Notify as a message and SUBSCRIBE as a method. This is currently = used in coap-01. > 1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but we = had a good list discussion about this leading to a. In practice it = doesn't make a big difference if notification is a message or method. >=20 > 2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2.0 = proposal or GENA. >=20 > So far we have focused on 1 in the WG, and every now and again 2 comes = up. At least I am not convinced that we need to suffer the drawbacks of = HTTP here. Anyways 2 does not help our mapping to HTTP in reality very = much as there is no standard way of doing this over HTTP. Thus a = CoAP-HTTP proxy may end up anyways translating between multiple HTTP = frameworks depending on the application. So instead of doing a CoAP = Notify/Subscribe to Webhooks mapping, you will could end up having to do = a CoAP Webhooks to HTTP GENA mapping. >=20 >=20 >=20 > I don't understand this last para. If CoAP sticks to the semantics of > the current HTTP methods, would this not offer a fairly = straightforward > translation to/from HTTP? >=20 >=20 >=20 > =46rom what I have heard so far 1 still seems like a wise choice, = although I need to look at Webhooks more deeply. In reality many = applications specify their own way of doing a push interface using REST = methods and specific payloads (ZigBee SE2.0 is such an example). That is = just fine, and might be used instead of a specific CoAP notify/subscribe = in that case. So 1 doesn't prevent the application using its own = mechanism, it just provides a native way for doing push. >=20 > What do people think? >=20 > Zach >=20 > On May 17, 2010, at 6:44 = PM,matthieu.vial@fr.non.schneider-electric.com wrote: >=20 >=20 >=20 > Hi, >=20 > My comments about the subscribe/notify mechanism of Zigbee IP. >=20 > Pros: > - Derived from the webhooks concept > - If used by CORE it will be easier to map to HTTP because it uses = only CRUD verbs. > - The subscription message is extendable and could support advanced = options (delays, increment, ...) > - Only one listening port whatever the transport binding is. >=20 > Cons: > - No interoperability without well known URIs and a well defined = subscription message format (Not sure CoAP draft is the right place to = specify this). > - XML/EXI is too complex to be the required format for the default = subscription/notification mechanism. > - The notification should not require a subsequent GET to retrieve the = content. > - Subresource subscription is redundant. >=20 > Hope this could help, > Matthieu >=20 >=20 > "Charles Palmer" >=20 >=20 >=20 >=20 > "Charles Palmer" > Envoy=E9 par : core-bounces@ietf.org > 15/05/2010 14:06 >=20 > > A > > "core" > > cc > > > Objet > > Re: [core] Selecting a WG document for CoAP > >=20 > Dear all >=20 > Those interested in the subscribe/notify discussion might like to look > at the draft Smart Energy Profile 2.0 Application Protocol > Specification. It is available here: > = http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicApp > licationProfile.aspx >=20 > It manages subscribe/notify by using POST. This seems to remove the = need > for SUBSCRIBE and notify. >=20 > "Imagine a host A, which exposes a resource at http{s}://A/resource = and > a second host B, which wishes to learn of changes to this resource. To > facilitate a subscription/ notification mechanism, A would expose a > resource http{s}://A/sub and B would expose a resource = http{s}://B/ntfy. > To subscribe to notifications regarding http{s}://A/resource, B would > send a POST to the address http{s}://A/sub/B containing the URI of the > resource of interest (http{s}://A/resource) and the URI of B's > notification resource (http{s}://B/ntfy). Following this subscription > step, should A wish to notify B of a change to the resource addressed = at > http{s}://A/resource, A would send a POST to the address > http{s}://B/ntfy containing the URI of the resource changed > (http{s}://A/resource) and the URI of A's subscription resource > (http{s}://A/sub/B), should A wish to change its subscription. The = host > B can then query the resource (or not) at its leisure." >=20 > Sleepy nodes are not allowed to subscribe, and must poll. >=20 > Regards - Charles Palmer >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of > Angelo P. Castellani > Sent: 14 May 2010 13:14 > To: Zach Shelby > Cc: core > Subject: Re: [core] Selecting a WG document for CoAP >=20 > Zach, >=20 > thanks for the comments, but please refer to my most recent e-mail for > a more specific list of technical issues I'm pointing to. >=20 > I want to do only a little integration to what I've written there. >=20 > In my very personal opinion, to maximize adherence with the REST model > and minimize implementation effort SUBSCRIBE and NOTIFY should be > mapped to methods (as discussed many times together...). >=20 > Uniform interface principle (Fielding PhD dissertation Section 5.1.5, > "The central feature that distinguishes the REST architectural style > [...]") states that to simplify the software architecture, resource > interfaces/interfaces should be as general as possible. >=20 > I agree with this principle in this specific case, mainly because > handling a special message type for notify leads node software design > to a more complex architecture. >=20 > The reason is that this new message type requires special handling and > introduces a complexity in the software modularization. >=20 > Best, > Angelo >=20 > On Fri, May 14, 2010 at 13:06, Zach Shelby wrote: >=20 >=20 > Hi Angelo, >=20 > On May 13, 2010, at 14:24 , Angelo P. Castellani wrote: >=20 >=20 >=20 > Dear C. Bormann, all, >=20 > before deciding for the final direction, I've the following > observations about draft-shelby-core-coap-01 >=20 > While I mostly share Zach's view of the protocol approach, and > appreciate many aspects of the proposal, there are in my opinion >=20 >=20 > still >=20 >=20 > some open issues that need to be at least discussed before the >=20 >=20 > current >=20 >=20 > document can be selected. >=20 >=20 > Of course there are plenty of open issues. Remember that working group >=20 >=20 > documents still undertake as much change and improvement as the WG > wants, so by no means is coap-01 set in stone. I would expect at least > 5-10 more revisions still along the way. Already several of your ideas > have been integrated into coap-01, and several more are under > consideration, so it is coming along. Patience ;-) >=20 >=20 > =20 > In particular, I would like to highlight the following: >=20 > a) As it is now, it is not possible to have a straightforward > translation of HTTP -> CoAP and viceversa: see > http://www.ietf.org/mail-archive/web/core/current/msg00133.html (this > impacts the scalability of the web service model too) >=20 >=20 > In coap-01 the Method names are now identical to HTTP methods. The >=20 >=20 > Req/Res interaction is a direct translation. The URI hierarchy is > compatible, and the URI binary code format we are still working on > obviously. The only thing that takes some state to translate is > Subscribe/Notify. But note, Subscribe/Notify takes some state no = matter > how you do it, even with HTTP-HTTP there is no clean and easy way to > handle subscriptions. >=20 >=20 > =20 > b) Moreover, CoAP's implementation is not as simple as it should be. > I've investigated the implementation and some design choices (as > Options) are leading to very high program complexity (ROM) on a > MSP430-based device. >=20 >=20 > This we can definitely improve, and already made several optimizations >=20 >=20 > from -00 to -01. Here I need some very concrete proposals though. Also > remember that many things are optional, for example subscribe/notify = is > not required if you don't need it. >=20 >=20 > =20 > c) Finally when comparing HTTP message size with CoAP message size, > the resulting compression isn't as good as you may expect. >=20 > Example: > HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B > CoAP: 24 B with options parsing procedure requiring an added > implementation complexity >=20 >=20 > Right, that is not how it will work in practice. Working with a real >=20 >=20 > HTTP server that HTTP header will be more complex, and on the CoAP = side > you would chose shorter URLs. The biggest improvement possible here is > from using binary coded URLs of course. We need to look at a wider = range > of interactions and real HTTP headers as well to check that we are > efficient enough. >=20 >=20 > =20 > Addressing all these points potentially leads to major technical > modifications (especially point a) on the current draft, hence it is > appropriate in my opinion to discuss these points before making the > final decision. >=20 >=20 > I am not sure what else you have in mind for a). If we just forget >=20 >=20 > about Subscribe/Notify then you are good to go. But then you are also > not fulfilling the charter or the industry needs in that respect. >=20 >=20 > Thanks, > Zach >=20 >=20 >=20 > Best regards, >=20 > Angelo P. Castellani >=20 >=20 > On Mon, May 10, 2010 at 18:51, Carsten Bormannwrote: >=20 >=20 > The CORE WG has a milestone to select a WG document for CoAP in >=20 >=20 > April: >=20 >=20 > http://datatracker.ietf.org/wg/core/charter/ > ... > Apr 2010 Select WG document for basis of the CoAP protocol >=20 > Of the various documents that have been contributed, >=20 >=20 > draft-shelby-core-coap has significant discussion, as well as the > largest number of updates (including a previous version that was still > called -6lowapp-coap). >=20 >=20 > Today, another updated version of that draft was announced. See > http://www.ietf.org/mail-archive/web/core/current/msg00138.html > for the announcement and > http://tools.ietf.org/html/draft-shelby-core-coap-01 > for the draft itself. >=20 > However, as the authors say, there are still significant TODOs. >=20 > Are we in a state yet where we can say whether this is the right >=20 >=20 > direction for the WG to take? >=20 >=20 > If yes, is it the right direction? Should we adopt it as a WG >=20 >=20 > document? >=20 >=20 > If you don't think we can say yet, is there a set of technical >=20 >=20 > decisions you would like the authors to take with priority? >=20 >=20 > Note that once a document has become a WG document, the authors act >=20 >=20 > as editors for the working group, making (and usually fleshing out the > details of) any change that the WG decides it needs. >=20 >=20 > If you think we can still improve the draft, this is not an obstacle >=20 >=20 > to making it a WG document. >=20 >=20 > But of course we shouldn't do that if we intend to reverse its >=20 >=20 > fundamental technical direction. >=20 >=20 > In order to stay roughly in sync with our milestones, we should >=20 >=20 > reach at a decision on how to go forward this week. >=20 >=20 > Gruesse, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 >=20 > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 >=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 > -------------------------------- > Onzo is a limited company number 06097997 registered in England& = Wales. The > registered office is 6 Great Newport Street, London, WC2H 7JB, United = Kingdom. >=20 > This email message may contain confidential and/or privileged = information, and > is intended solely for the addressee(s). If you have received this = email in > error, please notify Onzo immediately. Unauthorised copying, = disclosure or > distribution of the material in this email is forbidden. > -------------------------------- >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > ______________________________________________________________________ >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 >=20 > =20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 > -------------------------------- > Onzo is a limited company number 06097997 registered in England& = Wales. The > registered office is 6 Great Newport Street, London, WC2H 7JB, United = Kingdom. >=20 > This email message may contain confidential and/or privileged = information, and > is intended solely for the addressee(s). If you have received this = email in > error, please notify Onzo immediately. Unauthorised copying, = disclosure or > distribution of the material in this email is forbidden. > -------------------------------- >=20 >=20 > =20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > = __________________________________________________________________________= ___________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From angelo.castellani@gmail.com Fri May 28 06:13:40 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 259D23A68B9 for ; Fri, 28 May 2010 06:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.812 X-Spam-Level: * X-Spam-Status: No, score=1.812 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JDaB7eiC0+G for ; Fri, 28 May 2010 06:13:37 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id EB9A73A67EF for ; Fri, 28 May 2010 06:13:36 -0700 (PDT) Received: by gwj19 with SMTP id 19so908262gwj.31 for ; Fri, 28 May 2010 06:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=wwsoxd5YClEdddjO6XelXQpaSXJcHHFAObncrYhG+h0=; b=ggn1BlgB80CkZWgGpcAItSPAMuZKMF5f5P2l3x+YeoBNGx9tE0flo/8Wv7vgksFsHt fdISRWhwui92Yuip3Y3wIsEr10oPd5bBuLvnntmmVD2Lc2q0AoBW5rpaj058MRjyZ/Z4 hLXTX+oSZQQnxb3Tj25Z470xF2Q6J3aP2t5hQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=tN601I6eAfjc6DQa9lWC85Rtlm7XSePaIeLfqbKeSKwZ7oPQEq0rgdHiCTxNR7Slys qu18H1XaiCPXVqMIn9cfOQlQ+I8koWFR38jJo0+Lu771dToZAu8uTGgbLSoAbu1vtTap iu9aDujKwuXvt0NdvlulLBEeIIo8qX+YrMblU= MIME-Version: 1.0 Received: by 10.91.192.14 with SMTP id u14mr696145agp.98.1275052400131; Fri, 28 May 2010 06:13:20 -0700 (PDT) Sender: angelo.castellani@gmail.com Received: by 10.90.26.2 with HTTP; Fri, 28 May 2010 06:13:20 -0700 (PDT) In-Reply-To: <6A9FCAC7-E2FA-482D-ABFF-DB6B111A9EA2@sensinode.com> References: <0D212BD466921646B58854FB79092CEC021F4E91@XMB-AMS-106.cisco.com> <0D212BD466921646B58854FB79092CEC021F4EF2@XMB-AMS-106.cisco.com> <6A9FCAC7-E2FA-482D-ABFF-DB6B111A9EA2@sensinode.com> Date: Fri, 28 May 2010 15:13:20 +0200 X-Google-Sender-Auth: WBw-x1ZoiNOCOnyw7mHyB6BZHJo Message-ID: From: "Angelo P. Castellani" To: Zach Shelby Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core Subject: Re: [core] Subscribe/Notify for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 13:13:40 -0000 In my opinion Subscribe/Notify are special methods of interaction between resources. 1) SUBSCRIBE: Any resource A can send a Request to SUBSCRIBE with a resource B (to the resource B URI). When B receives the request, B can (should/must?) answer with a Response to the SUBSCRIBE Request, telling the result of the request (subscription accepted/denied/unsupported?). 2) NOTIFY: When subscription condition fires the resource B sends a NOTIFY Request to resource A URI. When A receives the request, A can (should/must?) answer with a Response to the NOTIFY Request, telling the result of the request (OK, cancel subscription, change notify options?). In each Request must be specified the URI of the resource doing the Request too (Option? From-URI?). Angelo On Fri, May 28, 2010 at 14:50, Zach Shelby wrote: > Hi, > > This is a really good conversation. One thing we need to do is remember w= hat our minimum requirements are for subscribe/notify and not try to solve = something more than we should. From what I know it is sufficient to be able= to receive notifications when a URI changes or periodically. You might con= sider new URIs under this URI path to be changes to a URI though... > > On May 28, 2010, at 3:08 PM, Adriano Pezzuto (apezzuto) wrote: > >> Hello, >> with this flavor, the SUBSCRIBE may be replaced by a simple POST. So no = needs to have an explicit SUBSCRIBE method. > > This is what coap-01 assumes. > >> If we want support a more oriented peer-to-peer transaction on CoAP, it = looks to me both SUB and NOTIFY should be treated as messages. > > The Request/Response model can be used peer-to-peer, and in CoAP you can = even use a Request asynchronously. Additionally, we want a native RESTful s= ubscribe/notify technique, that is, we want to subscribe to resources and b= e susequently notified about those resources when they change. > > In that sense, you can think of a subscription as a request to receive as= ynchronous notifications about a resource (about a URI). This can be achiev= ed by: > > 1. =A0as a SUBSCRIBE Request on the URI with some option indicating the l= ifetime as in coap-01, > 2. =A0as a Subcsribe message (no methods) on the URI with some option, > 3. =A0or as a POST Request on the URI with options indicating that this i= s actually a subscription and the lifetime. =A0This bends the meaning of PO= ST quite a bit and might be prone to mistakes? > > The asynchronous response is a harder one. Can we bend the meaning of a R= equest for making asynchronous notifications? Also a notification includes = a URI about a resource on the requestor, which is inverse from normal Reque= sts in REST. So the options here are: > > 1. as a Notify message about a URI (no methods) as in coap-01, > 2. as a NOTIFY Request about a URI as was in coap-00, > 3. hmmm... reusing CRUD methods really doesn't work for this one at all..= . > > I wonder what the HTTP designers would have done if this would have been = a requirement back then? Maybe we should ask them... > > Zach > >> >> Adriano >> >> From: matthieu.vial@fr.non.schneider-electric.com [mailto:matthieu.vial@= fr.non.schneider-electric.com] >> Sent: venerd=EC 28 maggio 2010 13.52 >> To: Adriano Pezzuto (apezzuto) >> Cc: core; core-bounces@ietf.org; robert.cragie@gridmerge.com >> Subject: Re: [core] Subscribe/Notify for CoAP >> >> > So strictly speaking, both NOTIFY and SUBSCRIBE are message types not = =A0methods! >> >> SUBSCRIBE can be just an asynchronous GET on update then I think it is a= method and NOTIFY is an asynchronous response so a message. >> But if we want to have selective notifications when a resource is create= d, updated or deleted then I think you're right NOTIFY and SUBSCRIBE are me= ssages. >> >> Does that make sense ? >> >> Matthieu >> >> "Adriano Pezzuto (apezzuto)" >> >> >> >> >> "Adriano Pezzuto (apezzuto)" >> Envoy=E9 par : core-bounces@ietf.org >> 28/05/2010 12:50 >> >> >> A >> >> >> >> cc >> >> core >> >> Objet >> >> Re: [core] Subscribe/Notify for CoAP >> >> >> >> Hi Roberto, >> I understand your point and personally agree on M2M is quite different f= rom web page model. On the architectural RESTful style, the method informat= ion tells the server what to do with data kept in the URI information. >> >> So strictly speaking, both NOTIFY and SUBSCRIBE are message types not = =A0methods! >> >> Adriano >> >> From: Robert Cragie [mailto:robert.cragie@gridmerge.com] >> Sent: venerd=EC 28 maggio 2010 11.53 >> To: Adriano Pezzuto (apezzuto) >> Cc: Paul Duffy (paduffy); Zach Shelby; core >> Subject: Re: [core] Subscribe/Notify for CoAP >> >> I think the point here is that there are two levels we are considering. >> >> At the lowest (foundation) level, there are the transaction messages as = described below. This provides a flexible mechanism for the application wit= h regard to synchronicity and threading. This is important for the types of= devices CoAP is being aimed at. >> >> Above that, the methods can be used according to the architectural style= . So in this case, it is RESTful (COnstrained Restful Environments), which = will naturally limit the number of methods and how transactions occur. >> >> The actual architecture using a combination of the methods and messages = also depends on what is required at the application layer. Consider a typic= al client which wants to subscribe to a resource. That client controls the = feed of data but needs a component which is capable of handling (possibly b= uffering) the data it receives through notifications. Is this a separate se= rver? Or would we want to consider it part of an enhanced client model whic= h is able to process feeds of data? These are the sort of models which have= led to the myriad of solutions (GENA, Webhooks, long polling, pubsubhubbub= , RESTMS etc.) based around HTTP which are all essentially ingenious ways o= f getting around the limitations imposed by HTTP and how it is processed fo= r anything which deviates from the classic web page access model. >> >> I think the aim of CoAP should be clean from the word go with regard to = supporting these more peer-to-peer transactions, where the client can exist= on either entity and both entities can feed data to each other; typical in= M2M applications. >> >> Robert >> >> Robert Cragie (Pacific Gas & Electric) >> >> Gridmerge Ltd. >> 89 Greenfield Crescent, >> Wakefield, WF4 4WA, UK >> +44 1924 910888 >> +1 415 513 0064 >> http://www.gridmerge.com >> >> On 27/05/2010 7:08 PM, Adriano Pezzuto (apezzuto) wrote: >> Hi Robert, >> >> in my personal opinion, the option 1a) brings some sort of ambiguity to = CoAP specs. >> >> My be my understatement of new CoAP specs is not so deep, but now we hav= e 5 methods and 3 message types: request, response and notify. Which method= s are allowed with which messages types? >> I suppose you have to use PUT/POST method with notify message for asynch= data notification. How to make a subscribe? I suppose you would use a SUBS= CRIBE method with request/response message or SUBSCRIBE with notify message= ? Also what about POST/DELETE methods in a notify message? They not make an= y sense.. >> >> I think the choice is between: option 1) -> only CRUD methods and option= 1b) -> CRUD + SUB/NOTIFY methods, keeping in mind cost/benefits of both so= lutions. >> >> Adriano >> >> From: Robert Cragie [mailto:robert.cragie@gridmerge.com] >> Sent: mercoled=EC 26 maggio 2010 20.09 >> To: Adriano Pezzuto (apezzuto) >> Cc: Paul Duffy (paduffy); Zach Shelby; core >> Subject: Re: [core] Subscribe/Notify for CoAP >> >> Hi Adrian, >> >> I would also prefer to keep the protocol in CoAP asynchronous. You can a= lways map an asynchronous protocol to a synchronous one but, as we see in H= TTP, it always ends up as a kludge to do it the other way round. The effort= s which have been gone to to make HTTP quasi-asynchronous via all the schem= es mentioned below and many more besides (all non-interoperable of course) = is testament to how important this is for M2M communication. >> >> So, back to Zach's list, I favor 1a) for the following reasons: >> >> Foundation level of messages: >> >> 1. request/response can be asynchronous or synchronous messages (as ther= e is a transaction ID in there) >> 2. notify is an asynchronous message >> Derived methods: >> >> I think it makes sense to add a pub/sub model as a useful mechanism for = M2M. >> >> So, looking at it the other way round: It will be entirely possible to t= ranslate whatever is currently built on HTTP to CoAP based on the above, wi= th all its restrictions regarding synchronous and client/server transaction= s. What may be harder is to translate directly is a CoAP-based application = to HTTP. So I guess the question is: Do we want to be hamstrung to synchron= ous client/server transactions as dictated by HTTP and provide a direct map= ping to HTTP, then have to come up with similar kludges for asynchronous pe= er-to-peer transactions as has been done in numerous ways for HTTP, or do w= e want to define the protocol cleanly to start with and accept that some so= rt of transaction relaying/conversion would have to take place at a mapping= node? >> >> Robert >> Robert Cragie (Pacific Gas & Electric) >> >> Gridmerge Ltd. >> 89 Greenfield Crescent, >> Wakefield, WF4 4WA, UK >> +44 1924 910888 >> +1 415 513 0064 >> http://www.gridmerge.com >> >> On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote: >> Hi, >> it looks to me that CoAP should use an explicit sub/notify mechanism sin= ce this is the core of the machine-to-machine interaction model. >> HTTP suffers of this lack and we have seen a plethora of solutions to gi= ve an asynch taste to it. Webhooks and websockets are only the lasts of the= list. >> As someone has already pointed out on this list, it is theoretically pos= sible to describe sub/notify using only CRUD methods but it looks a little = bit tricky and verbose. >> >> Now we have a chance to build from scratch a new protocol with and I thi= nk using explicit sub/notify methods with a clear and well defined semantic= is the best option. It is easily understanding from every developer and wi= ll prevent to build other fanny solutions on top of the CoAP. HTTP does not= have this well defined semantic and (for hundreds of other reasons also) i= t is not used as wide protocol for machine-to-machine communication. >> >> CoAP - as binary protocol - and with an explicit asynch model has a chan= ce to be a really wide protocol for M2M communication not only for constrai= ned environments. >> >> my 2 cents >> >> - adriano >> >> -----Original Message----- >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Paul Duffy (paduffy) >> Sent: mercoled=EC 26 maggio 2010 0.47 >> To: Zach Shelby >> Cc: core >> Subject: Re: [core] Subscribe/Notify for CoAP >> >> On 5/25/2010 6:41 PM, Zach Shelby wrote: >> >> Hi, >> >> On May 26, 2010, at 12:23 AM, Charles Palmer wrote: >> >> >> Hi folks >> >> It occurs to me that CoRE should be keeping a close eye on ZigBee SE2.0 = work, so that it is as easy as possible for ZigBee SE to use CoRE when read= y. That suggests to me that we should align with their subscribe/notify pro= cess. >> >> >> I am not sure I understand that. I mean, ZigBee SE2.0 is defining an app= lication specific subscribe/notify mechanism for that purpose so far for HT= TP. This uses standard HTTP methods and some custom payload and REST interf= aces. CoAP Req/Res is already totally compatible with SE2.0 in that respect= , so alignment is already OK there. Nothing stopping someone from using SE2= .0 over CoAP. >> >> Specifying a native susbcription/notify into CoAP is another matter. We = can't adopt a solution specific to one application as that won't solve the = problems of other applications nor general HTTP mapping at all (probably wo= uld make it worse). It seems that for the near future there will be a bunch= of HTTP push mechanisms in use without any clear standard appearing - or a= m I wrong there? >> >> >> >> >> If COAP extends HTTP semantics with new subscription methods, it will >> not be possible to easily interchange HTTP/COAP, and translation >> gateways will become more complex to implement. >> >> >> >> Zach >> >> >> Regards - Charles >> >> >> -----Original Message----- >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Paul Duffy >> Sent: 25 May 2010 03:48 >> To: Zach Shelby >> Cc: core >> Subject: Re: [core] Subscribe/Notify for CoAP >> >> Recommend something like #2, primarily to avoid introducing non HTTP >> method semantics, simplifying HTTP/COAP translation.gateways, etc. >> >> >> On 5/24/2010 11:49 AM, Zach Shelby wrote: >> >> (thread renamed) >> >> We have two different paths with regard to a subscribe/notify mechanism = for CoAP: >> >> 1. Use specific Subscription and Notify mechanisms for CoAP as HTTP real= ly does not include this concept. >> 1a) Notify as a message and SUBSCRIBE as a method. This is currently use= d in coap-01. >> 1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but we ha= d a good list discussion about this leading to a. In practice it doesn't ma= ke a big difference if notification is a message or method. >> >> 2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2.0 pro= posal or GENA. >> >> So far we have focused on 1 in the WG, and every now and again 2 comes u= p. At least I am not convinced that we need to suffer the drawbacks of HTTP= here. Anyways 2 does not help our mapping to HTTP in reality very much as = there is no standard way of doing this over HTTP. Thus a CoAP-HTTP proxy ma= y end up anyways translating between multiple HTTP frameworks depending on = the application. So instead of doing a CoAP Notify/Subscribe to Webhooks ma= pping, you will could end up having to do a CoAP Webhooks to HTTP GENA mapp= ing. >> >> >> >> I don't understand this last para. If CoAP sticks to the semantics of >> the current HTTP methods, would this not offer a fairly straightforward >> translation to/from HTTP? >> >> >> >> From what I have heard so far 1 still seems like a wise choice, although= I need to look at Webhooks more deeply. In reality many applications speci= fy their own way of doing a push interface using REST methods and specific = payloads (ZigBee SE2.0 is such an example). That is just fine, and might be= used instead of a specific CoAP notify/subscribe in that case. So 1 doesn'= t prevent the application using its own mechanism, it just provides a nativ= e way for doing push. >> >> What do people think? >> >> Zach >> >> On May 17, 2010, at 6:44 PM,matthieu.vial@fr.non.schneider-electric.com = wrote: >> >> >> >> Hi, >> >> My comments about the subscribe/notify mechanism of Zigbee IP. >> >> Pros: >> - Derived from the webhooks concept >> - If used by CORE it will be easier to map to HTTP because it uses only = CRUD verbs. >> - The subscription message is extendable and could support advanced opti= ons (delays, increment, ...) >> - Only one listening port whatever the transport binding is. >> >> Cons: >> - No interoperability without well known URIs and a well defined subscri= ption message format (Not sure CoAP draft is the right place to specify thi= s). >> - XML/EXI is too complex to be the required format for the default subsc= ription/notification mechanism. >> - The notification should not require a subsequent GET to retrieve the c= ontent. >> - Subresource subscription is redundant. >> >> Hope this could help, >> Matthieu >> >> >> "Charles Palmer" >> >> >> >> >> "Charles Palmer" >> Envoy=E9 par : core-bounces@ietf.org >> 15/05/2010 14:06 >> >> >> A >> >> "core" >> >> cc >> >> >> Objet >> >> Re: [core] Selecting a WG document for CoAP >> >> >> Dear all >> >> Those interested in the subscribe/notify discussion might like to look >> at the draft Smart Energy Profile 2.0 Application Protocol >> Specification. It is available here: >> http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicApp >> licationProfile.aspx >> >> It manages subscribe/notify by using POST. This seems to remove the need >> for SUBSCRIBE and notify. >> >> "Imagine a host A, which exposes a resource at http{s}://A/resource and >> a second host B, which wishes to learn of changes to this resource. To >> facilitate a subscription/ notification mechanism, A would expose a >> resource http{s}://A/sub and B would expose a resource http{s}://B/ntfy. >> To subscribe to notifications regarding http{s}://A/resource, B would >> send a POST to the address http{s}://A/sub/B containing the URI of the >> resource of interest (http{s}://A/resource) and the URI of B's >> notification resource (http{s}://B/ntfy). Following this subscription >> step, should A wish to notify B of a change to the resource addressed at >> http{s}://A/resource, A would send a POST to the address >> http{s}://B/ntfy containing the URI of the resource changed >> (http{s}://A/resource) and the URI of A's subscription resource >> (http{s}://A/sub/B), should A wish to change its subscription. The host >> B can then query the resource (or not) at its leisure." >> >> Sleepy nodes are not allowed to subscribe, and must poll. >> >> Regards - Charles Palmer >> >> -----Original Message----- >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of >> Angelo P. Castellani >> Sent: 14 May 2010 13:14 >> To: Zach Shelby >> Cc: core >> Subject: Re: [core] Selecting a WG document for CoAP >> >> Zach, >> >> thanks for the comments, but please refer to my most recent e-mail for >> a more specific list of technical issues I'm pointing to. >> >> I want to do only a little integration to what I've written there. >> >> In my very personal opinion, to maximize adherence with the REST model >> and minimize implementation effort SUBSCRIBE and NOTIFY should be >> mapped to methods (as discussed many times together...). >> >> Uniform interface principle (Fielding PhD dissertation Section 5.1.5, >> "The central feature that distinguishes the REST architectural style >> [...]") states that to simplify the software architecture, resource >> interfaces/interfaces should be as general as possible. >> >> I agree with this principle in this specific case, mainly because >> handling a special message type for notify leads node software design >> to a more complex architecture. >> >> The reason is that this new message type requires special handling and >> introduces a complexity in the software modularization. >> >> Best, >> Angelo >> >> On Fri, May 14, 2010 at 13:06, Zach Shelby wrote: >> >> >> Hi Angelo, >> >> On May 13, 2010, at 14:24 , Angelo P. Castellani wrote: >> >> >> >> Dear C. Bormann, all, >> >> before deciding for the final direction, I've the following >> observations about draft-shelby-core-coap-01 >> >> While I mostly share Zach's view of the protocol approach, and >> appreciate many aspects of the proposal, there are in my opinion >> >> >> still >> >> >> some open issues that need to be at least discussed before the >> >> >> current >> >> >> document can be selected. >> >> >> Of course there are plenty of open issues. Remember that working group >> >> >> documents still undertake as much change and improvement as the WG >> wants, so by no means is coap-01 set in stone. I would expect at least >> 5-10 more revisions still along the way. Already several of your ideas >> have been integrated into coap-01, and several more are under >> consideration, so it is coming along. Patience ;-) >> >> >> >> In particular, I would like to highlight the following: >> >> a) As it is now, it is not possible to have a straightforward >> translation of HTTP -> CoAP and viceversa: see >> http://www.ietf.org/mail-archive/web/core/current/msg00133.html (this >> impacts the scalability of the web service model too) >> >> >> In coap-01 the Method names are now identical to HTTP methods. The >> >> >> Req/Res interaction is a direct translation. The URI hierarchy is >> compatible, and the URI binary code format we are still working on >> obviously. The only thing that takes some state to translate is >> Subscribe/Notify. But note, Subscribe/Notify takes some state no matter >> how you do it, even with HTTP-HTTP there is no clean and easy way to >> handle subscriptions. >> >> >> >> b) Moreover, CoAP's implementation is not as simple as it should be. >> I've investigated the implementation and some design choices (as >> Options) are leading to very high program complexity (ROM) on a >> MSP430-based device. >> >> >> This we can definitely improve, and already made several optimizations >> >> >> from -00 to -01. Here I need some very concrete proposals though. Also >> remember that many things are optional, for example subscribe/notify is >> not required if you don't need it. >> >> >> >> c) Finally when comparing HTTP message size with CoAP message size, >> the resulting compression isn't as good as you may expect. >> >> Example: >> HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B >> CoAP: 24 B with options parsing procedure requiring an added >> implementation complexity >> >> >> Right, that is not how it will work in practice. Working with a real >> >> >> HTTP server that HTTP header will be more complex, and on the CoAP side >> you would chose shorter URLs. The biggest improvement possible here is >> from using binary coded URLs of course. We need to look at a wider range >> of interactions and real HTTP headers as well to check that we are >> efficient enough. >> >> >> >> Addressing all these points potentially leads to major technical >> modifications (especially point a) on the current draft, hence it is >> appropriate in my opinion to discuss these points before making the >> final decision. >> >> >> I am not sure what else you have in mind for a). If we just forget >> >> >> about Subscribe/Notify then you are good to go. But then you are also >> not fulfilling the charter or the industry needs in that respect. >> >> >> Thanks, >> Zach >> >> >> >> Best regards, >> >> Angelo P. Castellani >> >> >> On Mon, May 10, 2010 at 18:51, Carsten Bormannwrote: >> >> >> The CORE WG has a milestone to select a WG document for CoAP in >> >> >> April: >> >> >> http://datatracker.ietf.org/wg/core/charter/ >> ... >> Apr 2010 Select WG document for basis of the CoAP protocol >> >> Of the various documents that have been contributed, >> >> >> draft-shelby-core-coap has significant discussion, as well as the >> largest number of updates (including a previous version that was still >> called -6lowapp-coap). >> >> >> Today, another updated version of that draft was announced. See >> http://www.ietf.org/mail-archive/web/core/current/msg00138.html >> for the announcement and >> http://tools.ietf.org/html/draft-shelby-core-coap-01 >> for the draft itself. >> >> However, as the authors say, there are still significant TODOs. >> >> Are we in a state yet where we can say whether this is the right >> >> >> direction for the WG to take? >> >> >> If yes, is it the right direction? Should we adopt it as a WG >> >> >> document? >> >> >> If you don't think we can say yet, is there a set of technical >> >> >> decisions you would like the authors to take with priority? >> >> >> Note that once a document has become a WG document, the authors act >> >> >> as editors for the working group, making (and usually fleshing out the >> details of) any change that the WG decides it needs. >> >> >> If you think we can still improve the draft, this is not an obstacle >> >> >> to making it a WG document. >> >> >> But of course we shouldn't do that if we intend to reverse its >> >> >> fundamental technical direction. >> >> >> In order to stay roughly in sync with our milestones, we should >> >> >> reach at a decision on how to go forward this week. >> >> >> Gruesse, Carsten >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> >> -- >> Zach Shelby, Chief Nerd, Sensinode Ltd. >> http://zachshelby.org - My blog "On the Internet of Things" >> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" >> Mobile: +358 40 7796297 >> >> >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> -------------------------------- >> Onzo is a limited company number 06097997 registered in England& Wales. = The >> registered office is 6 Great Newport Street, London, WC2H 7JB, United Ki= ngdom. >> >> This email message may contain confidential and/or privileged informatio= n, and >> is intended solely for the addressee(s). If you have received this email= in >> error, please notify Onzo immediately. Unauthorised copying, disclosure = or >> distribution of the material in this email is forbidden. >> -------------------------------- >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> ______________________________________________________________________ >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> -------------------------------- >> Onzo is a limited company number 06097997 registered in England& Wales. = The >> registered office is 6 Great Newport Street, London, WC2H 7JB, United Ki= ngdom. >> >> This email message may contain confidential and/or privileged informatio= n, and >> is intended solely for the addressee(s). If you have received this email= in >> error, please notify Onzo immediately. Unauthorised copying, disclosure = or >> distribution of the material in this email is forbidden. >> -------------------------------- >> >> >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> ________________________________________________________________________= _____________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org =A0- 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 matthieu.vial@fr.non.schneider-electric.com Fri May 28 06:29:52 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4010F3A67EF for ; Fri, 28 May 2010 06:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.275 X-Spam-Level: ** X-Spam-Status: No, score=2.275 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_20=-0.74, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPMzBgoo3z3F for ; Fri, 28 May 2010 06:29:47 -0700 (PDT) Received: from mailX02.eud.schneider-electric.com (mailx02.eud.schneider-electric.com [205.167.7.38]) by core3.amsl.com (Postfix) with ESMTP id 593283A6804 for ; Fri, 28 May 2010 06:29:46 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX02.eud.schneider-electric.com with ESMTP id 2010052815171306-90718 ; Fri, 28 May 2010 15:17:13 +0200 In-Reply-To: <6A9FCAC7-E2FA-482D-ABFF-DB6B111A9EA2@sensinode.com> To: Zach Shelby X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: matthieu.vial@fr.non.schneider-electric.com Date: Fri, 28 May 2010 15:24:21 +0200 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 28/05/2010 15:24:26, Itemize by SMTP Server on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 28/05/2010 15:17:13, Serialize by Router on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 28/05/2010 15:22:23 Content-type: multipart/related; Boundary="0__=4EBBFDA2DFDAF18F8f9e8a93df938690918c4EBBFDA2DFDAF18F" Cc: core Subject: Re: [core] Subscribe/Notify for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 13:29:52 -0000 --0__=4EBBFDA2DFDAF18F8f9e8a93df938690918c4EBBFDA2DFDAF18F Content-type: multipart/alternative; Boundary="1__=4EBBFDA2DFDAF18F8f9e8a93df938690918c4EBBFDA2DFDAF18F" --1__=4EBBFDA2DFDAF18F8f9e8a93df938690918c4EBBFDA2DFDAF18F Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=ISO-8859-1 Hi, The Waka protocol from Roy Fielding has a new monitor verb http://en.wikipedia.org/wiki/Waka_%28protocol%29 Matthieu = Zach Shelby = = A Adriano Pezzuto (apezzuto) = 28/05/2010 14:50 = = cc Matthieu = Vial/FR/Non/Schneider@Europe, co= re = Ob= jet Re: [core] Subscribe/Notify for = CoAP = = = = = = = Hi, This is a really good conversation. One thing we need to do is remember= what our minimum requirements are for subscribe/notify and not try to s= olve something more than we should. From what I know it is sufficient to be = able to receive notifications when a URI changes or periodically. You might consider new URIs under this URI path to be changes to a URI though... On May 28, 2010, at 3:08 PM, Adriano Pezzuto (apezzuto) wrote: > Hello, > with this flavor, the SUBSCRIBE may be replaced by a simple POST. So = no needs to have an explicit SUBSCRIBE method. This is what coap-01 assumes. > If we want support a more oriented peer-to-peer transaction on CoAP, = it looks to me both SUB and NOTIFY should be treated as messages. The Request/Response model can be used peer-to-peer, and in CoAP you ca= n even use a Request asynchronously. Additionally, we want a native RESTf= ul subscribe/notify technique, that is, we want to subscribe to resources = and be susequently notified about those resources when they change. In that sense, you can think of a subscription as a request to receive asynchronous notifications about a resource (about a URI). This can be achieved by: 1. as a SUBSCRIBE Request on the URI with some option indicating the lifetime as in coap-01, 2. as a Subcsribe message (no methods) on the URI with some option, 3. or as a POST Request on the URI with options indicating that this i= s actually a subscription and the lifetime. This bends the meaning of PO= ST quite a bit and might be prone to mistakes? The asynchronous response is a harder one. Can we bend the meaning of a= Request for making asynchronous notifications? Also a notification incl= udes a URI about a resource on the requestor, which is inverse from normal Requests in REST. So the options here are: 1. as a Notify message about a URI (no methods) as in coap-01, 2. as a NOTIFY Request about a URI as was in coap-00, 3. hmmm... reusing CRUD methods really doesn't work for this one at all= ... I wonder what the HTTP designers would have done if this would have bee= n a requirement back then? Maybe we should ask them... Zach > > Adriano > > From: matthieu.vial@fr.non.schneider-electric.com [mailto:matthieu.vial@fr.non.schneider-electric.com] > Sent: venerd=EC 28 maggio 2010 13.52 > To: Adriano Pezzuto (apezzuto) > Cc: core; core-bounces@ietf.org; robert.cragie@gridmerge.com > Subject: Re: [core] Subscribe/Notify for CoAP > > > So strictly speaking, both NOTIFY and SUBSCRIBE are message types n= ot methods! > > SUBSCRIBE can be just an asynchronous GET on update then I think it i= s a method and NOTIFY is an asynchronous response so a message. > But if we want to have selective notifications when a resource is created, updated or deleted then I think you're right NOTIFY and SUBSCR= IBE are messages. > > Does that make sense ? > > Matthieu > > "Adriano Pezzuto (apezzuto)" > > > > > "Adriano Pezzuto (apezzuto)" > Envoy=E9 par : core-bounces@ietf.org > 28/05/2010 12:50 > > > A > > > > cc > > core > > Objet > > Re: [core] Subscribe/Notify for CoAP > > > > Hi Roberto, > I understand your point and personally agree on M2M is quite differen= t from web page model. On the architectural RESTful style, the method information tells the server what to do with data kept in the URI information. > > So strictly speaking, both NOTIFY and SUBSCRIBE are message types not= methods! > > Adriano > > From: Robert Cragie [mailto:robert.cragie@gridmerge.com] > Sent: venerd=EC 28 maggio 2010 11.53 > To: Adriano Pezzuto (apezzuto) > Cc: Paul Duffy (paduffy); Zach Shelby; core > Subject: Re: [core] Subscribe/Notify for CoAP > > I think the point here is that there are two levels we are considerin= g. > > At the lowest (foundation) level, there are the transaction messages = as described below. This provides a flexible mechanism for the application= with regard to synchronicity and threading. This is important for the t= ypes of devices CoAP is being aimed at. > > Above that, the methods can be used according to the architectural st= yle. So in this case, it is RESTful (COnstrained Restful Environments), whic= h will naturally limit the number of methods and how transactions occur. > > The actual architecture using a combination of the methods and messag= es also depends on what is required at the application layer. Consider a typical client which wants to subscribe to a resource. That client cont= rols the feed of data but needs a component which is capable of handling (possibly buffering) the data it receives through notifications. Is thi= s a separate server? Or would we want to consider it part of an enhanced cl= ient model which is able to process feeds of data? These are the sort of mod= els which have led to the myriad of solutions (GENA, Webhooks, long polling= , pubsubhubbub, RESTMS etc.) based around HTTP which are all essentially ingenious ways of getting around the limitations imposed by HTTP and ho= w it is processed for anything which deviates from the classic web page acce= ss model. > > I think the aim of CoAP should be clean from the word go with regard = to supporting these more peer-to-peer transactions, where the client can e= xist on either entity and both entities can feed data to each other; typical= in M2M applications. > > Robert > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 1924 910888 > +1 415 513 0064 > http://www.gridmerge.com > > On 27/05/2010 7:08 PM, Adriano Pezzuto (apezzuto) wrote: > Hi Robert, > > in my personal opinion, the option 1a) brings some sort of ambiguity = to CoAP specs. > > My be my understatement of new CoAP specs is not so deep, but now we = have 5 methods and 3 message types: request, response and notify. Which meth= ods are allowed with which messages types? > I suppose you have to use PUT/POST method with notify message for asy= nch data notification. How to make a subscribe? I suppose you would use a SUBSCRIBE method with request/response message or SUBSCRIBE with notify= message? Also what about POST/DELETE methods in a notify message? They = not make any sense.. > > I think the choice is between: option 1) -> only CRUD methods and opt= ion 1b) -> CRUD + SUB/NOTIFY methods, keeping in mind cost/benefits of both= solutions. > > Adriano > > From: Robert Cragie [mailto:robert.cragie@gridmerge.com] > Sent: mercoled=EC 26 maggio 2010 20.09 > To: Adriano Pezzuto (apezzuto) > Cc: Paul Duffy (paduffy); Zach Shelby; core > Subject: Re: [core] Subscribe/Notify for CoAP > > Hi Adrian, > > I would also prefer to keep the protocol in CoAP asynchronous. You ca= n always map an asynchronous protocol to a synchronous one but, as we see= in HTTP, it always ends up as a kludge to do it the other way round. The efforts which have been gone to to make HTTP quasi-asynchronous via all= the schemes mentioned below and many more besides (all non-interoperable of= course) is testament to how important this is for M2M communication. > > So, back to Zach's list, I favor 1a) for the following reasons: > > Foundation level of messages: > > 1. request/response can be asynchronous or synchronous messages (as t= here is a transaction ID in there) > 2. notify is an asynchronous message > Derived methods: > > I think it makes sense to add a pub/sub model as a useful mechanism f= or M2M. > > So, looking at it the other way round: It will be entirely possible t= o translate whatever is currently built on HTTP to CoAP based on the abov= e, with all its restrictions regarding synchronous and client/server transactions. What may be harder is to translate directly is a CoAP-bas= ed application to HTTP. So I guess the question is: Do we want to be hamst= rung to synchronous client/server transactions as dictated by HTTP and provi= de a direct mapping to HTTP, then have to come up with similar kludges for asynchronous peer-to-peer transactions as has been done in numerous way= s for HTTP, or do we want to define the protocol cleanly to start with an= d accept that some sort of transaction relaying/conversion would have to = take place at a mapping node? > > Robert > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 1924 910888 > +1 415 513 0064 > http://www.gridmerge.com > > On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote: > Hi, > it looks to me that CoAP should use an explicit sub/notify mechanism since this is the core of the machine-to-machine interaction model. > HTTP suffers of this lack and we have seen a plethora of solutions to= give an asynch taste to it. Webhooks and websockets are only the lasts = of the list. > As someone has already pointed out on this list, it is theoretically possible to describe sub/notify using only CRUD methods but it looks a little bit tricky and verbose. > > Now we have a chance to build from scratch a new protocol with and I think using explicit sub/notify methods with a clear and well defined semantic is the best option. It is easily understanding from every developer and will prevent to build other fanny solutions on top of the= CoAP. HTTP does not have this well defined semantic and (for hundreds o= f other reasons also) it is not used as wide protocol for machine-to-mach= ine communication. > > CoAP - as binary protocol - and with an explicit asynch model has a chance to be a really wide protocol for M2M communication not only for constrained environments. > > my 2 cents > > - adriano > > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Paul Duffy (paduffy) > Sent: mercoled=EC 26 maggio 2010 0.47 > To: Zach Shelby > Cc: core > Subject: Re: [core] Subscribe/Notify for CoAP > > On 5/25/2010 6:41 PM, Zach Shelby wrote: > > Hi, > > On May 26, 2010, at 12:23 AM, Charles Palmer wrote: > > > Hi folks > > It occurs to me that CoRE should be keeping a close eye on ZigBee SE2= .0 work, so that it is as easy as possible for ZigBee SE to use CoRE when ready. That suggests to me that we should align with their subscribe/no= tify process. > > > I am not sure I understand that. I mean, ZigBee SE2.0 is defining an application specific subscribe/notify mechanism for that purpose so far= for HTTP. This uses standard HTTP methods and some custom payload and REST interfaces. CoAP Req/Res is already totally compatible with SE2.0 in th= at respect, so alignment is already OK there. Nothing stopping someone fro= m using SE2.0 over CoAP. > > Specifying a native susbcription/notify into CoAP is another matter. = We can't adopt a solution specific to one application as that won't solve = the problems of other applications nor general HTTP mapping at all (probabl= y would make it worse). It seems that for the near future there will be a= bunch of HTTP push mechanisms in use without any clear standard appeari= ng - or am I wrong there? > > > > > If COAP extends HTTP semantics with new subscription methods, it will= > not be possible to easily interchange HTTP/COAP, and translation > gateways will become more complex to implement. > > > > Zach > > > Regards - Charles > > > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Paul Duffy > Sent: 25 May 2010 03:48 > To: Zach Shelby > Cc: core > Subject: Re: [core] Subscribe/Notify for CoAP > > Recommend something like #2, primarily to avoid introducing non HTTP > method semantics, simplifying HTTP/COAP translation.gateways, etc. > > > On 5/24/2010 11:49 AM, Zach Shelby wrote: > > (thread renamed) > > We have two different paths with regard to a subscribe/notify mechani= sm for CoAP: > > 1. Use specific Subscription and Notify mechanisms for CoAP as HTTP really does not include this concept. > 1a) Notify as a message and SUBSCRIBE as a method. This is currently = used in coap-01. > 1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but we= had a good list discussion about this leading to a. In practice it doesn't = make a big difference if notification is a message or method. > > 2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2.0 proposal or GENA. > > So far we have focused on 1 in the WG, and every now and again 2 come= s up. At least I am not convinced that we need to suffer the drawbacks of= HTTP here. Anyways 2 does not help our mapping to HTTP in reality very = much as there is no standard way of doing this over HTTP. Thus a CoAP-HTTP p= roxy may end up anyways translating between multiple HTTP frameworks dependi= ng on the application. So instead of doing a CoAP Notify/Subscribe to Webh= ooks mapping, you will could end up having to do a CoAP Webhooks to HTTP GEN= A mapping. > > > > I don't understand this last para. If CoAP sticks to the semantics of= > the current HTTP methods, would this not offer a fairly straightforwa= rd > translation to/from HTTP? > > > > From what I have heard so far 1 still seems like a wise choice, altho= ugh I need to look at Webhooks more deeply. In reality many applications specify their own way of doing a push interface using REST methods and specific payloads (ZigBee SE2.0 is such an example). That is just fine,= and might be used instead of a specific CoAP notify/subscribe in that case.= So 1 doesn't prevent the application using its own mechanism, it just prov= ides a native way for doing push. > > What do people think? > > Zach > > On May 17, 2010, at 6:44 PM,matthieu.vial@fr.non.schneider-electric.c= om wrote: > > > > Hi, > > My comments about the subscribe/notify mechanism of Zigbee IP. > > Pros: > - Derived from the webhooks concept > - If used by CORE it will be easier to map to HTTP because it uses on= ly CRUD verbs. > - The subscription message is extendable and could support advanced options (delays, increment, ...) > - Only one listening port whatever the transport binding is. > > Cons: > - No interoperability without well known URIs and a well defined subscription message format (Not sure CoAP draft is the right place to specify this). > - XML/EXI is too complex to be the required format for the default subscription/notification mechanism. > - The notification should not require a subsequent GET to retrieve th= e content. > - Subresource subscription is redundant. > > Hope this could help, > Matthieu > > > "Charles Palmer" > > > > > "Charles Palmer" > Envoy=E9 par : core-bounces@ietf.org > 15/05/2010 14:06 > > > A > > "core" > > cc > > > Objet > > Re: [core] Selecting a WG document for CoAP > > > Dear all > > Those interested in the subscribe/notify discussion might like to loo= k > at the draft Smart Energy Profile 2.0 Application Protocol > Specification. It is available here: > http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20Public= App > licationProfile.aspx > > It manages subscribe/notify by using POST. This seems to remove the n= eed > for SUBSCRIBE and notify. > > "Imagine a host A, which exposes a resource at http{s}://A/resource a= nd > a second host B, which wishes to learn of changes to this resource. T= o > facilitate a subscription/ notification mechanism, A would expose a > resource http{s}://A/sub and B would expose a resource http{s}://B/nt= fy. > To subscribe to notifications regarding http{s}://A/resource, B would= > send a POST to the address http{s}://A/sub/B containing the URI of th= e > resource of interest (http{s}://A/resource) and the URI of B's > notification resource (http{s}://B/ntfy). Following this subscription= > step, should A wish to notify B of a change to the resource addressed= at > http{s}://A/resource, A would send a POST to the address > http{s}://B/ntfy containing the URI of the resource changed > (http{s}://A/resource) and the URI of A's subscription resource > (http{s}://A/sub/B), should A wish to change its subscription. The ho= st > B can then query the resource (or not) at its leisure." > > Sleepy nodes are not allowed to subscribe, and must poll. > > Regards - Charles Palmer > > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of > Angelo P. Castellani > Sent: 14 May 2010 13:14 > To: Zach Shelby > Cc: core > Subject: Re: [core] Selecting a WG document for CoAP > > Zach, > > thanks for the comments, but please refer to my most recent e-mail fo= r > a more specific list of technical issues I'm pointing to. > > I want to do only a little integration to what I've written there. > > In my very personal opinion, to maximize adherence with the REST mode= l > and minimize implementation effort SUBSCRIBE and NOTIFY should be > mapped to methods (as discussed many times together...). > > Uniform interface principle (Fielding PhD dissertation Section 5.1.5,= > "The central feature that distinguishes the REST architectural style > [...]") states that to simplify the software architecture, resource > interfaces/interfaces should be as general as possible. > > I agree with this principle in this specific case, mainly because > handling a special message type for notify leads node software design= > to a more complex architecture. > > The reason is that this new message type requires special handling an= d > introduces a complexity in the software modularization. > > Best, > Angelo > > On Fri, May 14, 2010 at 13:06, Zach Shelby wrote:= > > > Hi Angelo, > > On May 13, 2010, at 14:24 , Angelo P. Castellani wrote: > > > > Dear C. Bormann, all, > > before deciding for the final direction, I've the following > observations about draft-shelby-core-coap-01 > > While I mostly share Zach's view of the protocol approach, and > appreciate many aspects of the proposal, there are in my opinion > > > still > > > some open issues that need to be at least discussed before the > > > current > > > document can be selected. > > > Of course there are plenty of open issues. Remember that working grou= p > > > documents still undertake as much change and improvement as the WG > wants, so by no means is coap-01 set in stone. I would expect at leas= t > 5-10 more revisions still along the way. Already several of your idea= s > have been integrated into coap-01, and several more are under > consideration, so it is coming along. Patience ;-) > > > > In particular, I would like to highlight the following: > > a) As it is now, it is not possible to have a straightforward > translation of HTTP -> CoAP and viceversa: see > http://www.ietf.org/mail-archive/web/core/current/msg00133.html (this= > impacts the scalability of the web service model too) > > > In coap-01 the Method names are now identical to HTTP methods. The > > > Req/Res interaction is a direct translation. The URI hierarchy is > compatible, and the URI binary code format we are still working on > obviously. The only thing that takes some state to translate is > Subscribe/Notify. But note, Subscribe/Notify takes some state no matt= er > how you do it, even with HTTP-HTTP there is no clean and easy way to > handle subscriptions. > > > > b) Moreover, CoAP's implementation is not as simple as it should be. > I've investigated the implementation and some design choices (as > Options) are leading to very high program complexity (ROM) on a > MSP430-based device. > > > This we can definitely improve, and already made several optimization= s > > > from -00 to -01. Here I need some very concrete proposals though. Als= o > remember that many things are optional, for example subscribe/notify = is > not required if you don't need it. > > > > c) Finally when comparing HTTP message size with CoAP message size, > the resulting compression isn't as good as you may expect. > > Example: > HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B > CoAP: 24 B with options parsing procedure requiring an added > implementation complexity > > > Right, that is not how it will work in practice. Working with a real > > > HTTP server that HTTP header will be more complex, and on the CoAP si= de > you would chose shorter URLs. The biggest improvement possible here i= s > from using binary coded URLs of course. We need to look at a wider ra= nge > of interactions and real HTTP headers as well to check that we are > efficient enough. > > > > Addressing all these points potentially leads to major technical > modifications (especially point a) on the current draft, hence it is > appropriate in my opinion to discuss these points before making the > final decision. > > > I am not sure what else you have in mind for a). If we just forget > > > about Subscribe/Notify then you are good to go. But then you are also= > not fulfilling the charter or the industry needs in that respect. > > > Thanks, > Zach > > > > Best regards, > > Angelo P. Castellani > > > On Mon, May 10, 2010 at 18:51, Carsten Bormannwrote: > > > The CORE WG has a milestone to select a WG document for CoAP in > > > April: > > > http://datatracker.ietf.org/wg/core/charter/ > ... > Apr 2010 Select WG document for basis of the CoAP protocol > > Of the various documents that have been contributed, > > > draft-shelby-core-coap has significant discussion, as well as the > largest number of updates (including a previous version that was stil= l > called -6lowapp-coap). > > > Today, another updated version of that draft was announced. See > http://www.ietf.org/mail-archive/web/core/current/msg00138.html > for the announcement and > http://tools.ietf.org/html/draft-shelby-core-coap-01 > for the draft itself. > > However, as the authors say, there are still significant TODOs. > > Are we in a state yet where we can say whether this is the right > > > direction for the WG to take? > > > If yes, is it the right direction? Should we adopt it as a WG > > > document? > > > If you don't think we can say yet, is there a set of technical > > > decisions you would like the authors to take with priority? > > > Note that once a document has become a WG document, the authors act > > > as editors for the working group, making (and usually fleshing out th= e > details of) any change that the WG decides it needs. > > > If you think we can still improve the draft, this is not an obstacle > > > to making it a WG document. > > > But of course we shouldn't do that if we intend to reverse its > > > fundamental technical direction. > > > In order to stay roughly in sync with our milestones, we should > > > reach at a decision on how to go forward this week. > > > Gruesse, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet= " > Mobile: +358 40 7796297 > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > -------------------------------- > Onzo is a limited company number 06097997 registered in England& Wale= s. The > registered office is 6 Great Newport Street, London, WC2H 7JB, United= Kingdom. > > This email message may contain confidential and/or privileged information, and > is intended solely for the addressee(s). If you have received this em= ail in > error, please notify Onzo immediately. Unauthorised copying, disclosu= re or > distribution of the material in this email is forbidden. > -------------------------------- > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > _____________________________________________________________________= _ > This email has been scanned by the MessageLabs Email Security System.= > _____________________________________________________________________= _ > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > -------------------------------- > Onzo is a limited company number 06097997 registered in England& Wale= s. The > registered office is 6 Great Newport Street, London, WC2H 7JB, United= Kingdom. > > This email message may contain confidential and/or privileged information, and > is intended solely for the addressee(s). If you have received this em= ail in > error, please notify Onzo immediately. Unauthorised copying, disclosu= re or > distribution of the material in this email is forbidden. > -------------------------------- > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > > _____________________________________________________________________= _ > This email has been scanned by the MessageLabs Email Security System.= > _______________________________________________________________________= ______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ = --1__=4EBBFDA2DFDAF18F8f9e8a93df938690918c4EBBFDA2DFDAF18F Content-transfer-encoding: quoted-printable Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline
  • Request
  • Response
  • Notify
A thread of execution will call request and will typically (though not necessarily - see emulated blocking/continuations) wait for a response. If the thread blocks, it is typically woken by another worker thread handling a notify. The worker thread handles notifies asynchronously and buffers and/or signals the associated task accordingly.

This is why I think the current foundation level of messages in coap-01 is right.

On top of this, the payload of the messages can reflect the actual method. Personally, I don't see the need for a specific SUBSCRIBE message; a POST/create to a subscription resource seems adequate to me. The notify message can carry a PUT or POST depending on whether the resource was simply updated or appended to (again it is no accident the data types in JSON are as they are).

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com


On 28/05/2010 2:13 PM, Angelo P. Castellani wrote: 
In my opinion Subscribe/Notify are special methods of in=
teraction
between resources.

1) SUBSCRIBE: Any resource A can send a Request to SUBSCRIBE with a
resource B (to the resource B URI).

When B receives the request, B can (should/must?) answer with a
Response to the SUBSCRIBE Request, telling the result of the request
(subscription accepted/denied/unsupported?).

2) NOTIFY: When subscription condition fires the resource B sends a
NOTIFY Request to resource A URI.

When A receives the request, A can (should/must?) answer with a
Response to the NOTIFY Request, telling the result of the request (OK,
cancel subscription, change notify options?).

In each Request must be specified the URI of the resource doing the
Request too (Option? From-URI?).

Angelo

On Fri, May 28, 2010 at 14:50, Zach Shelby <zach@sensinode.com> wr=
ote:
  
Hi,

This is a really good conversation. One thing we need to do is remember w=
hat our minimum requirements are for subscribe/notify and not try to solv=
e something more than we should. From what I know it is sufficient to be =
able to receive notifications when a URI changes or periodically. You mig=
ht consider new URIs under this URI path to be changes to a URI though...=


On May 28, 2010, at 3:08 PM, Adriano Pezzuto (apezzuto) wrote:

    
Hello,
with this flavor, the SUBSCRIBE may be replaced by a simple POST. So no n=
eeds to have an explicit SUBSCRIBE method.
      
This is what coap-01 assumes.

    
If we want support a more oriented peer-to-peer tran=
saction on CoAP, it looks to me both SUB and NOTIFY should be treated as =
messages.
      
The Request/Response model can be used peer-to-peer, and in CoAP you can =
even use a Request asynchronously. Additionally, we want a native RESTful=
 subscribe/notify technique, that is, we want to subscribe to resources a=
nd be susequently notified about those resources when they change.

In that sense, you can think of a subscription as a request to receive as=
ynchronous notifications about a resource (about a URI). This can be achi=
eved by:

1.  as a SUBSCRIBE Request on the URI with some option indicating th=
e lifetime as in coap-01,
2.  as a Subcsribe message (no methods) on the URI with some option,=

3.  or as a POST Request on the URI with options indicating that thi=
s is actually a subscription and the lifetime.  This bends the meani=
ng of POST quite a bit and might be prone to mistakes?

The asynchronous response is a harder one. Can we bend the meaning of a R=
equest for making asynchronous notifications? Also a notification include=
s a URI about a resource on the requestor, which is inverse from normal R=
equests in REST. So the options here are:

1. as a Notify message about a URI (no methods) as in coap-01,
2. as a NOTIFY Request about a URI as was in coap-00,
3. hmmm... reusing CRUD methods really doesn't work for this one at all..=
=2E

I wonder what the HTTP designers would have done if this would have been =
a requirement back then? Maybe we should ask them...

Zach

    
Adriano

From: matthieu.vial@fr.non.schneider-electric.co=
m [mailto:matthieu.vial@fr.non.schneider-elec=
tric.com]
Sent: venerdì 28 maggio 2010 13.52
To: Adriano Pezzuto (apezzuto)
Cc: core; core-bounces@ietf.org; robert.cragie@gridmerge.=
com
Subject: Re: [core] Subscribe/Notify for CoAP

      
So strictly speaking, both NOTIFY and SUBSCRIBE ar=
e message types not  methods!
        
SUBSCRIBE can be just an asynchronous GET on update then I think it is a =
method and NOTIFY is an asynchronous response so a message.
But if we want to have selective notifications when a resource is created=
, updated or deleted then I think you're right NOTIFY and SUBSCRIBE are m=
essages.

Does that make sense ?

Matthieu

<image001.gif>"Adriano Pezzuto (apezzuto)" <apezzuto@cisco.com><=
/a>




"Adriano Pezzuto (apezzuto)" <apezzuto@cisco.com>
Envoyé par : core-bounces@ietf.org
28/05/2010 12:50

<image003.png>
A
<image004.png>
<robert.cragie@gridmerge.com>
<image003.png>
cc
<image004.png>
core <=
;core@ietf.org>
<image003.png>
Objet
<image004.png>
Re: [core] Subscribe/Notify for CoAP
<image004.png>
<image004.png>

Hi Roberto,
I understand your point and personally agree on M2M is quite different fr=
om web page model. On the architectural RESTful style, the method informa=
tion tells the server what to do with data kept in the URI information.

So strictly speaking, both NOTIFY and SUBSCRIBE are message types not &nb=
sp;methods!

Adriano

From: Robert Cragie [mailto:robert.cragie@gridmerge.com]
Sent: venerdì 28 maggio 2010 11.53
To: Adriano Pezzuto (apezzuto)
Cc: Paul Duffy (paduffy); Zach Shelby; core
Subject: Re: [core] Subscribe/Notify for CoAP

I think the point here is that there are two levels we are considering.

At the lowest (foundation) level, there are the transaction messages as d=
escribed below. This provides a flexible mechanism for the application wi=
th regard to synchronicity and threading. This is important for the types=
 of devices CoAP is being aimed at.

Above that, the methods can be used according to the architectural style.=
 So in this case, it is RESTful (COnstrained Restful Environments), which=
 will naturally limit the number of methods and how transactions occur.

The actual architecture using a combination of the methods and messages a=
lso depends on what is required at the application layer. Consider a typi=
cal client which wants to subscribe to a resource. That client controls t=
he feed of data but needs a component which is capable of handling (possi=
bly buffering) the data it receives through notifications. Is this a sepa=
rate server? Or would we want to consider it part of an enhanced client m=
odel which is able to process feeds of data? These are the sort of models=
 which have led to the myriad of solutions (GENA, Webhooks, long polling,=
 pubsubhubbub, RESTMS etc.) based around HTTP which are all essentially i=
ngenious ways of getting around the limitations imposed by HTTP and how i=
t is processed for anything which deviates from the classic web page acce=
ss model.

I think the aim of CoAP should be clean from the word go with regard to s=
upporting these more peer-to-peer transactions, where the client can exis=
t on either entity and both entities can feed data to each other; typical=
 in M2M applications.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http=
://www.gridmerge.com

On 27/05/2010 7:08 PM, Adriano Pezzuto (apezzuto) wrote:
Hi Robert,

in my personal opinion, the option 1a) brings some sort of ambiguity to C=
oAP specs.

My be my understatement of new CoAP specs is not so deep, but now we have=
 5 methods and 3 message types: request, response and notify. Which metho=
ds are allowed with which messages types?
I suppose you have to use PUT/POST method with notify message for asynch =
data notification. How to make a subscribe? I suppose you would use a SUB=
SCRIBE method with request/response message or SUBSCRIBE with notify mess=
age? Also what about POST/DELETE methods in a notify message? They not ma=
ke any sense..

I think the choice is between: option 1) -> only CRUD methods and opti=
on 1b) -> CRUD + SUB/NOTIFY methods, keeping in mind cost/benefits of =
both solutions.

Adriano

From: Robert Cragie [mailto:robert.cragie@gridmerge.com]
Sent: mercoledì 26 maggio 2010 20.09
To: Adriano Pezzuto (apezzuto)
Cc: Paul Duffy (paduffy); Zach Shelby; core
Subject: Re: [core] Subscribe/Notify for CoAP

Hi Adrian,

I would also prefer to keep the protocol in CoAP asynchronous. You can al=
ways map an asynchronous protocol to a synchronous one but, as we see in =
HTTP, it always ends up as a kludge to do it the other way round. The eff=
orts which have been gone to to make HTTP quasi-asynchronous via all the =
schemes mentioned below and many more besides (all non-interoperable of c=
ourse) is testament to how important this is for M2M communication.

So, back to Zach's list, I favor 1a) for the following reasons:

Foundation level of messages:

1. request/response can be asynchronous or synchronous messages (as there=
 is a transaction ID in there)
2. notify is an asynchronous message
Derived methods:

I think it makes sense to add a pub/sub model as a useful mechanism for M=
2M.

So, looking at it the other way round: It will be entirely possible to tr=
anslate whatever is currently built on HTTP to CoAP based on the above, w=
ith all its restrictions regarding synchronous and client/server transact=
ions. What may be harder is to translate directly is a CoAP-based applica=
tion to HTTP. So I guess the question is: Do we want to be hamstrung to s=
ynchronous client/server transactions as dictated by HTTP and provide a d=
irect mapping to HTTP, then have to come up with similar kludges for asyn=
chronous peer-to-peer transactions as has been done in numerous ways for =
HTTP, or do we want to define the protocol cleanly to start with and acce=
pt that some sort of transaction relaying/conversion would have to take p=
lace at a mapping node?

Robert
Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http=
://www.gridmerge.com

On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote:
Hi,
it looks to me that CoAP should use an explicit sub/notify mechanism sinc=
e this is the core of the machine-to-machine interaction model.
HTTP suffers of this lack and we have seen a plethora of solutions to giv=
e an asynch taste to it. Webhooks and websockets are only the lasts of th=
e list.
As someone has already pointed out on this list, it is theoretically poss=
ible to describe sub/notify using only CRUD methods but it looks a little=
 bit tricky and verbose.

Now we have a chance to build from scratch a new protocol with and I thin=
k using explicit sub/notify methods with a clear and well defined semanti=
c is the best option. It is easily understanding from every developer and=
 will prevent to build other fanny solutions on top of the CoAP. HTTP doe=
s not have this well defined semantic and (for hundreds of other reasons =
also) it is not used as wide protocol for machine-to-machine communicatio=
n.

CoAP - as binary protocol - and with an explicit asynch model has a chanc=
e to be a really wide protocol for M2M communication not only for constra=
ined environments.

my 2 cents

- adriano

-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On =
Behalf Of Paul Duffy (paduffy)
Sent: mercoledì 26 maggio 2010 0.47
To: Zach Shelby
Cc: core
Subject: Re: [core] Subscribe/Notify for CoAP

On 5/25/2010 6:41 PM, Zach Shelby wrote:

Hi,

On May 26, 2010, at 12:23 AM, Charles Palmer wrote:


Hi folks

It occurs to me that CoRE should be keeping a close eye on ZigBee SE2.0 w=
ork, so that it is as easy as possible for ZigBee SE to use CoRE when rea=
dy. That suggests to me that we should align with their subscribe/notify =
process.


I am not sure I understand that. I mean, ZigBee SE2.0 is defining an appl=
ication specific subscribe/notify mechanism for that purpose so far for H=
TTP. This uses standard HTTP methods and some custom payload and REST int=
erfaces. CoAP Req/Res is already totally compatible with SE2.0 in that re=
spect, so alignment is already OK there. Nothing stopping someone from us=
ing SE2.0 over CoAP.

Specifying a native susbcription/notify into CoAP is another matter. We c=
an't adopt a solution specific to one application as that won't solve the=
 problems of other applications nor general HTTP mapping at all (probably=
 would make it worse). It seems that for the near future there will be a =
bunch of HTTP push mechanisms in use without any clear standard appearing=
 - or am I wrong there?




If COAP extends HTTP semantics with new subscription methods, it will
not be possible to easily interchange HTTP/COAP, and translation
gateways will become more complex to implement.



Zach


Regards - Charles


-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On =
Behalf Of Paul Duffy
Sent: 25 May 2010 03:48
To: Zach Shelby
Cc: core
Subject: Re: [core] Subscribe/Notify for CoAP

Recommend something like #2, primarily to avoid introducing non HTTP
method semantics, simplifying HTTP/COAP translation.gateways, etc.


On 5/24/2010 11:49 AM, Zach Shelby wrote:

(thread renamed)

We have two different paths with regard to a subscribe/notify mechanism f=
or CoAP:

1. Use specific Subscription and Notify mechanisms for CoAP as HTTP reall=
y does not include this concept.
1a) Notify as a message and SUBSCRIBE as a method. This is currently used=
 in coap-01.
1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but we had=
 a good list discussion about this leading to a. In practice it doesn't m=
ake a big difference if notification is a message or method.

2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2.0 prop=
osal or GENA.

So far we have focused on 1 in the WG, and every now and again 2 comes up=
=2E At least I am not convinced that we need to suffer the drawbacks of H=
TTP here. Anyways 2 does not help our mapping to HTTP in reality very muc=
h as there is no standard way of doing this over HTTP. Thus a CoAP-HTTP p=
roxy may end up anyways translating between multiple HTTP frameworks depe=
nding on the application. So instead of doing a CoAP Notify/Subscribe to =
Webhooks mapping, you will could end up having to do a CoAP Webhooks to H=
TTP GENA mapping.



I don't understand this last para. If CoAP sticks to the semantics of
the current HTTP methods, would this not offer a fairly straightforward
translation to/from HTTP?



=46rom what I have heard so far 1 still seems like a wise choice, althoug=
h I need to look at Webhooks more deeply. In reality many applications sp=
ecify their own way of doing a push interface using REST methods and spec=
ific payloads (ZigBee SE2.0 is such an example). That is just fine, and m=
ight be used instead of a specific CoAP notify/subscribe in that case. So=
 1 doesn't prevent the application using its own mechanism, it just provi=
des a native way for doing push.

What do people think?

Zach

On May 17, 2010, at 6:44 PM,matthieu.vial@fr.non=
=2Eschneider-electric.com wrote:



Hi,

My comments about the subscribe/notify mechanism of Zigbee IP.

Pros:
- Derived from the webhooks concept
- If used by CORE it will be easier to map to HTTP because it uses only C=
RUD verbs.
- The subscription message is extendable and could support advanced optio=
ns (delays, increment, ...)
- Only one listening port whatever the transport binding is.

Cons:
- No interoperability without well known URIs and a well defined subscrip=
tion message format (Not sure CoAP draft is the right place to specify th=
is).
- XML/EXI is too complex to be the required format for the default subscr=
iption/notification mechanism.
- The notification should not require a subsequent GET to retrieve the co=
ntent.
- Subresource subscription is redundant.

Hope this could help,
Matthieu


<graycol.gif>"Charles Palmer"<charles.palmer@onzo.com>




"Charles Palmer"<charles.palmer@onzo.com>
Envoyé par : core-bounces@ietf.org
15/05/2010 14:06

<ecblank.gif>
A
<ecblank.gif>
"core"&l=
t;core@ietf.org>
<ecblank.gif>
cc
<ecblank.gif>
<ecblank.gif>
Objet
<ecblank.gif>
Re: [core] Selecting a WG document for CoAP
<ecblank.gif> <ecblank.gif>

Dear all

Those interested in the subscribe/notify discussion might like to look
at the draft Smart Energy Profile 2.0 Application Protocol
Specification. It is available here:
http://zigbee.org/Markets/Zig=
BeeSmartEnergy/ZigBeeSmartEnergy20PublicApp
licationProfile.aspx

It manages subscribe/notify by using POST. This seems to remove the need
for SUBSCRIBE and notify.

"Imagine a host A, which exposes a resource at http{s}://A/resource and
a second host B, which wishes to learn of changes to this resource. To
facilitate a subscription/ notification mechanism, A would expose a
resource http{s}://A/sub and B would expose a resource http{s}://B/ntfy.
To subscribe to notifications regarding http{s}://A/resource, B would
send a POST to the address http{s}://A/sub/B containing the URI of the
resource of interest (http{s}://A/resource) and the URI of B's
notification resource (http{s}://B/ntfy). Following this subscription
step, should A wish to notify B of a change to the resource addressed at
http{s}://A/resource, A would send a POST to the address
http{s}://B/ntfy containing the URI of the resource changed
(http{s}://A/resource) and the URI of A's subscription resource
(http{s}://A/sub/B), should A wish to change its subscription. The host
B can then query the resource (or not) at its leisure."

Sleepy nodes are not allowed to subscribe, and must poll.

Regards - Charles Palmer

-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On =
Behalf Of
Angelo P. Castellani
Sent: 14 May 2010 13:14
To: Zach Shelby
Cc: core
Subject: Re: [core] Selecting a WG document for CoAP

Zach,

thanks for the comments, but please refer to my most recent e-mail for
a more specific list of technical issues I'm pointing to.

I want to do only a little integration to what I've written there.

In my very personal opinion, to maximize adherence with the REST model
and minimize implementation effort SUBSCRIBE and NOTIFY should be
mapped to methods (as discussed many times together...).

Uniform interface principle (Fielding PhD dissertation Section 5.1.5,
"The central feature that distinguishes the REST architectural style
[...]") states that to simplify the software architecture, resource
interfaces/interfaces should be as general as possible.

I agree with this principle in this specific case, mainly because
handling a special message type for notify leads node software design
to a more complex architecture.

The reason is that this new message type requires special handling and
introduces a complexity in the software modularization.

Best,
Angelo

On Fri, May 14, 2010 at 13:06, Zach Shelby<zach@sensinode.com> wro=
te:


Hi Angelo,

On May 13, 2010, at 14:24 , Angelo P. Castellani wrote:



Dear C. Bormann, all,

before deciding for the final direction, I've the following
observations about draft-shelby-core-coap-01

While I mostly share Zach's view of the protocol approach, and
appreciate many aspects of the proposal, there are in my opinion


still


some open issues that need to be at least discussed before the


current


document can be selected.


Of course there are plenty of open issues. Remember that working group


documents still undertake as much change and improvement as the WG
wants, so by no means is coap-01 set in stone. I would expect at least
5-10 more revisions still along the way. Already several of your ideas
have been integrated into coap-01, and several more are under
consideration, so it is coming along. Patience ;-)



In particular, I would like to highlight the following:

a) As it is now, it is not possible to have a straightforward
translation of HTTP -> CoAP and viceversa: see
http://www.ietf.org/mail-archive/web/c=
ore/current/msg00133.html (this
impacts the scalability of the web service model too)


In coap-01 the Method names are now identical to HTTP methods. The


Req/Res interaction is a direct translation. The URI hierarchy is
compatible, and the URI binary code format we are still working on
obviously. The only thing that takes some state to translate is
Subscribe/Notify. But note, Subscribe/Notify takes some state no matter
how you do it, even with HTTP-HTTP there is no clean and easy way to
handle subscriptions.



b) Moreover, CoAP's implementation is not as simple as it should be.
I've investigated the implementation and some design choices (as
Options) are leading to very high program complexity (ROM) on a
MSP430-based device.


This we can definitely improve, and already made several optimizations


from -00 to -01. Here I need some very concrete proposals though. Also
remember that many things are optional, for example subscribe/notify is
not required if you don't need it.



c) Finally when comparing HTTP message size with CoAP message size,
the resulting compression isn't as good as you may expect.

Example:
HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B
CoAP: 24 B with options parsing procedure requiring an added
implementation complexity


Right, that is not how it will work in practice. Working with a real


HTTP server that HTTP header will be more complex, and on the CoAP side
you would chose shorter URLs. The biggest improvement possible here is
from using binary coded URLs of course. We need to look at a wider range
of interactions and real HTTP headers as well to check that we are
efficient enough.



Addressing all these points potentially leads to major technical
modifications (especially point a) on the current draft, hence it is
appropriate in my opinion to discuss these points before making the
final decision.


I am not sure what else you have in mind for a). If we just forget


about Subscribe/Notify then you are good to go. But then you are also
not fulfilling the charter or the industry needs in that respect.


Thanks,
Zach



Best regards,

Angelo P. Castellani


On Mon, May 10, 2010 at 18:51, Carsten Bormann<cabo@tzi.org>wrote:


The CORE WG has a milestone to select a WG document for CoAP in


April:


http://datatracker.ietf.org/wg/core/charter/
=2E..
Apr 2010 Select WG document for basis of the CoAP protocol

Of the various documents that have been contributed,


draft-shelby-core-coap has significant discussion, as well as the
largest number of updates (including a previous version that was still
called -6lowapp-coap).


Today, another updated version of that draft was announced. See
http://www.ietf.org/mail-archive/web/c=
ore/current/msg00138.html
for the announcement and
http://tools.ietf.org/html/draft-shelby-core-coap=
-01
for the draft itself.

However, as the authors say, there are still significant TODOs.

Are we in a state yet where we can say whether this is the right


direction for the WG to take?


If yes, is it the right direction? Should we adopt it as a WG


document?


If you don't think we can say yet, is there a set of technical


decisions you would like the authors to take with priority?


Note that once a document has become a WG document, the authors act


as editors for the working group, making (and usually fleshing out the
details of) any change that the WG decides it needs.


If you think we can still improve the draft, this is not an obstacle


to making it a WG document.


But of course we shouldn't do that if we intend to reverse its


fundamental technical direction.


In order to stay roughly in sync with our milestones, we should


reach at a decision on how to go forward this week.


Gruesse, Carsten

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



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


--
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://=
zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet=
"
Mobile: +358 40 7796297




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

--------------------------------
Onzo is a limited company number 06097997 registered in England& Wale=
s. The
registered office is 6 Great Newport Street, London, WC2H 7JB, United Kin=
gdom.

This email message may contain confidential and/or privileged information=
, and
is intended solely for the addressee(s). If you have received this email =
in
error, please notify Onzo immediately. Unauthorised copying, disclosure o=
r
distribution of the material in this email is forbidden.
--------------------------------

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

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________

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



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

--------------------------------
Onzo is a limited company number 06097997 registered in England& Wale=
s. The
registered office is 6 Great Newport Street, London, WC2H 7JB, United Kin=
gdom.

This email message may contain confidential and/or privileged information=
, and
is intended solely for the addressee(s). If you have received this email =
in
error, please notify Onzo immediately. Unauthorised copying, disclosure o=
r
distribution of the material in this email is forbidden.
--------------------------------




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



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
_________________________________________________________________________=
____________________________________________
core mailing list
core@=
ietf.org
https://www.ietf.org/mailman/listinfo/core

_______________________________________________
core mailing list
core@=
ietf.org
https://www.ietf.org/mailman/listinfo/core
      
--
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://=
zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet=
"
Mobile: +358 40 7796297

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

    
_______________________________________________
core mailing list
core@=
ietf.org
https://www.ietf.org/mailman/listinfo/core
--------------010004030807040508000401-- --------------ms000609040001000604050103 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA1 MjgxNzIyNDRaMCMGCSqGSIb3DQEJBDEWBBT865U7WDzJ3crkuFjotZKhJ2/94DBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAAPCiSysfFEMaqfJVnyp+IJ+qjkexkqEnTMu3lJtPflfJ4SCukiWHTYen7lqEV4DOKwn s11vco8ZAyX2WhIq5EJG26g3jZcaiez9il4gi1gn5+lksSA4OyuZ+Us3ZvGads1fAr6PufqQ XIg1675iQZTYxe8h6Br88jbQf1pGbxRzHxxuHSfXKCCESvH/uPNzLf6dzX4Zvl/qiu4o4VFE 1xFcW98E/Se6lVd5Rp4DGNnl5XXWM+eBkpnu2GjG8gGi80GgAlWvJ+1JWkFr18HAlWAJQpi9 exFvZISbIT8m/8MempNJzbg2zzzCymqXqRhk+s+w5xENVK9vKZZr6jeA8g8AAAAAAAA= --------------ms000609040001000604050103-- From brian.tridium@gmail.com Fri May 28 14:21:49 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9A583A687C for ; Fri, 28 May 2010 14:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.302 X-Spam-Level: ** X-Spam-Status: No, score=2.302 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRX2peQFRVw0 for ; Fri, 28 May 2010 14:21:44 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id C09EC3A6806 for ; Fri, 28 May 2010 14:21:43 -0700 (PDT) Received: by wwa36 with SMTP id 36so1222637wwa.31 for ; Fri, 28 May 2010 14:21:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=TnDmUv3H4DoC1rSl7TqsO7xLiCyQEbk8G3UAPtDzNEc=; b=t2E3VQU5bIfzWeXrByG3XUtgjgHM0Z1QAHF2u3nG6NkU5P2N+cAPEdkQV+GqwxFuPe e08PgoyqAK3zCUPSamOWGj7EDHef1F0uIDuTisqmhwaZjf7qNp731T7yenA9U5/Kmtg6 sEUljyF/V05MLsOuvUqzFdjYkXqt67fswvly4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=J3VKaerlLJq/2UPt22MfHx1Mk/hUU7sM//J/9YdGPUHArqzTXuuzph8AxexmpRYAfm 3adkAfWdVX787TPdaAhJEZ6QbhbfChQeOUBVorFOnTHUcqVMKCYkVr0b3ssrBTraHr54 RZXTiuxmanbRUJtczADVnzywdWMxWM2WZ/yIM= MIME-Version: 1.0 Received: by 10.216.85.68 with SMTP id t46mr2013156wee.75.1275081690561; Fri, 28 May 2010 14:21:30 -0700 (PDT) Received: by 10.216.48.207 with HTTP; Fri, 28 May 2010 14:21:30 -0700 (PDT) In-Reply-To: <4BFFFBE4.4090108@gridmerge.com> References: <0D212BD466921646B58854FB79092CEC021F4E91@XMB-AMS-106.cisco.com> <0D212BD466921646B58854FB79092CEC021F4EF2@XMB-AMS-106.cisco.com> <6A9FCAC7-E2FA-482D-ABFF-DB6B111A9EA2@sensinode.com> <4BFFFBE4.4090108@gridmerge.com> Date: Fri, 28 May 2010 17:21:30 -0400 Message-ID: From: Brian Frank To: core@ietf.org Content-Type: multipart/alternative; boundary=0016e6d645a839ca0c0487ae17ec Subject: Re: [core] Subscribe/Notify for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 21:21:49 -0000 --0016e6d645a839ca0c0487ae17ec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My two cents: Personally I find it confusing to have both a message type *and* a method. Do we really need both? It seems we just combine the two into a single method byte. Maybe reserve a bit to say a message is a response to a GET, PUT, DELETE, etc. On Fri, May 28, 2010 at 1:22 PM, Robert Cragie wrote: > I think sometimes it makes more sense to think about threads of executio= n. > > Forgive me for this lengthy preamble but it will hopefully put things int= o > context. > > In the most abstract sense, processing is governed by a thread of > execution, which sequences a series of data transformations to expedite t= he > required processing. If a data transformation can be completed synchronou= sly > in the thread of execution, then the thread is conceptually easier to > understand and follow. Most threading models assume this to be the case a= nd > if the data transformation cannot complete, it usually blocks pending the > required event to complete the transformation. During blocking, the threa= d > is suspended. In simple CPU models without any sort of scheduler, there a= re > two threads of execution: A main thread, pre-emptable by an interrupt > thread, usually not pre-emptable. In the main thread, sub-threads are > emulated; data transformations can be simply function calls which don't > block and therefore return effectively immediately and synchronously. > Blocking data transformations are emulated by storing state relevant to e= ach > sub-thread then marshaling each event as it is received e.g. through > interrupt handling, which causes the second thread to run and thus allows > changing sub-thread state so when the main thread runs, the blocking data > transformation can complete. Operating system schedulers for these simple > CPUs simply abstract this operation through a kernel and associated > task/thread scheduling calls. Continuations are a simpler form used in > memory-constrained implementations. > > Why the lengthy pre-amble? However you look at it, what essentially is > required for any threading model (using kernel/scheduler, continuations, > emulated, whatever) are fundamentally three primitives: > > - Request > - Response > - Notify > > A thread of execution will call request and will typically (though not > necessarily - see emulated blocking/continuations) wait for a response. I= f > the thread blocks, it is typically woken by another worker thread handlin= g a > notify. The worker thread handles notifies asynchronously and buffers and= /or > signals the associated task accordingly. > > This is why I think the current foundation level of messages in coap-01 i= s > right. > > On top of this, the payload of the messages can reflect the actual method= . > Personally, I don't see the need for a specific SUBSCRIBE message; a > POST/create to a subscription resource seems adequate to me. The notify > message can carry a PUT or POST depending on whether the resource was sim= ply > updated or appended to (again it is no accident the data types in JSON ar= e > as they are). > > Robert > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 1924 910888 > +1 415 513 0064 > http://www.gridmerge.com > > On 28/05/2010 2:13 PM, Angelo P. Castellani wrote: > > In my opinion Subscribe/Notify are special methods of interaction > between resources. > > 1) SUBSCRIBE: Any resource A can send a Request to SUBSCRIBE with a > resource B (to the resource B URI). > > When B receives the request, B can (should/must?) answer with a > Response to the SUBSCRIBE Request, telling the result of the request > (subscription accepted/denied/unsupported?). > > 2) NOTIFY: When subscription condition fires the resource B sends a > NOTIFY Request to resource A URI. > > When A receives the request, A can (should/must?) answer with a > Response to the NOTIFY Request, telling the result of the request (OK, > cancel subscription, change notify options?). > > In each Request must be specified the URI of the resource doing the > Request too (Option? From-URI?). > > Angelo > > On Fri, May 28, 2010 at 14:50, Zach Shelby wrote: > > > Hi, > > This is a really good conversation. One thing we need to do is remember w= hat our minimum requirements are for subscribe/notify and not try to solve = something more than we should. From what I know it is sufficient to be able= to receive notifications when a URI changes or periodically. You might con= sider new URIs under this URI path to be changes to a URI though... > > On May 28, 2010, at 3:08 PM, Adriano Pezzuto (apezzuto) wrote: > > > > Hello, > with this flavor, the SUBSCRIBE may be replaced by a simple POST. So no n= eeds to have an explicit SUBSCRIBE method. > > > This is what coap-01 assumes. > > > > If we want support a more oriented peer-to-peer transaction on CoAP, it = looks to me both SUB and NOTIFY should be treated as messages. > > > The Request/Response model can be used peer-to-peer, and in CoAP you can= even use a Request asynchronously. Additionally, we want a native RESTful = subscribe/notify technique, that is, we want to subscribe to resources and = be susequently notified about those resources when they change. > > In that sense, you can think of a subscription as a request to receive as= ynchronous notifications about a resource (about a URI). This can be achiev= ed by: > > 1. as a SUBSCRIBE Request on the URI with some option indicating the lif= etime as in coap-01, > 2. as a Subcsribe message (no methods) on the URI with some option, > 3. or as a POST Request on the URI with options indicating that this is = actually a subscription and the lifetime. This bends the meaning of POST q= uite a bit and might be prone to mistakes? > > The asynchronous response is a harder one. Can we bend the meaning of a R= equest for making asynchronous notifications? Also a notification includes = a URI about a resource on the requestor, which is inverse from normal Reque= sts in REST. So the options here are: > > 1. as a Notify message about a URI (no methods) as in coap-01, > 2. as a NOTIFY Request about a URI as was in coap-00, > 3. hmmm... reusing CRUD methods really doesn't work for this one at all..= . > > I wonder what the HTTP designers would have done if this would have been = a requirement back then? Maybe we should ask them... > > Zach > > > > Adriano > > From: matthieu.vial@fr.non.schneider-electric.com [mailto:matthieu.vial@f= r.non.schneider-electric.com ] > Sent: venerd=EC 28 maggio 2010 13.52 > To: Adriano Pezzuto (apezzuto) > Cc: core; core-bounces@ietf.org; robert.cragie@gridmerge.com > Subject: Re: [core] Subscribe/Notify for CoAP > > > > So strictly speaking, both NOTIFY and SUBSCRIBE are message types not m= ethods! > > > SUBSCRIBE can be just an asynchronous GET on update then I think it is a= method and NOTIFY is an asynchronous response so a message. > But if we want to have selective notifications when a resource is created= , updated or deleted then I think you're right NOTIFY and SUBSCRIBE are mes= sages. > > Does that make sense ? > > Matthieu > > "Adriano Pezzuto (apezzuto)" > > > > > "Adriano Pezzuto (apezzuto)" > Envoy=E9 par : core-bounces@ietf.org > 28/05/2010 12:50 > > > A > > > cc > > core > > Objet > > Re: [core] Subscribe/Notify for CoAP > > > > Hi Roberto, > I understand your point and personally agree on M2M is quite different fr= om web page model. On the architectural RESTful style, the method informati= on tells the server what to do with data kept in the URI information. > > So strictly speaking, both NOTIFY and SUBSCRIBE are message types not me= thods! > > Adriano > > From: Robert Cragie [mailto:robert.cragie@gridmerge.com ] > Sent: venerd=EC 28 maggio 2010 11.53 > To: Adriano Pezzuto (apezzuto) > Cc: Paul Duffy (paduffy); Zach Shelby; core > Subject: Re: [core] Subscribe/Notify for CoAP > > I think the point here is that there are two levels we are considering. > > At the lowest (foundation) level, there are the transaction messages as d= escribed below. This provides a flexible mechanism for the application with= regard to synchronicity and threading. This is important for the types of = devices CoAP is being aimed at. > > Above that, the methods can be used according to the architectural style.= So in this case, it is RESTful (COnstrained Restful Environments), which w= ill naturally limit the number of methods and how transactions occur. > > The actual architecture using a combination of the methods and messages a= lso depends on what is required at the application layer. Consider a typica= l client which wants to subscribe to a resource. That client controls the f= eed of data but needs a component which is capable of handling (possibly bu= ffering) the data it receives through notifications. Is this a separate ser= ver? Or would we want to consider it part of an enhanced client model which= is able to process feeds of data? These are the sort of models which have = led to the myriad of solutions (GENA, Webhooks, long polling, pubsubhubbub,= RESTMS etc.) based around HTTP which are all essentially ingenious ways of= getting around the limitations imposed by HTTP and how it is processed for= anything which deviates from the classic web page access model. > > I think the aim of CoAP should be clean from the word go with regard to s= upporting these more peer-to-peer transactions, where the client can exist = on either entity and both entities can feed data to each other; typical in = M2M applications. > > Robert > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 1924 910888 > +1 415 513 0064http://www.gridmerge.com > > On 27/05/2010 7:08 PM, Adriano Pezzuto (apezzuto) wrote: > Hi Robert, > > in my personal opinion, the option 1a) brings some sort of ambiguity to C= oAP specs. > > My be my understatement of new CoAP specs is not so deep, but now we have= 5 methods and 3 message types: request, response and notify. Which methods= are allowed with which messages types? > I suppose you have to use PUT/POST method with notify message for asynch = data notification. How to make a subscribe? I suppose you would use a SUBSC= RIBE method with request/response message or SUBSCRIBE with notify message?= Also what about POST/DELETE methods in a notify message? They not make any= sense.. > > I think the choice is between: option 1) -> only CRUD methods and option = 1b) -> CRUD + SUB/NOTIFY methods, keeping in mind cost/benefits of both sol= utions. > > Adriano > > From: Robert Cragie [mailto:robert.cragie@gridmerge.com ] > Sent: mercoled=EC 26 maggio 2010 20.09 > To: Adriano Pezzuto (apezzuto) > Cc: Paul Duffy (paduffy); Zach Shelby; core > Subject: Re: [core] Subscribe/Notify for CoAP > > Hi Adrian, > > I would also prefer to keep the protocol in CoAP asynchronous. You can al= ways map an asynchronous protocol to a synchronous one but, as we see in HT= TP, it always ends up as a kludge to do it the other way round. The efforts= which have been gone to to make HTTP quasi-asynchronous via all the scheme= s mentioned below and many more besides (all non-interoperable of course) i= s testament to how important this is for M2M communication. > > So, back to Zach's list, I favor 1a) for the following reasons: > > Foundation level of messages: > > 1. request/response can be asynchronous or synchronous messages (as there= is a transaction ID in there) > 2. notify is an asynchronous message > Derived methods: > > I think it makes sense to add a pub/sub model as a useful mechanism for M= 2M. > > So, looking at it the other way round: It will be entirely possible to tr= anslate whatever is currently built on HTTP to CoAP based on the above, wit= h all its restrictions regarding synchronous and client/server transactions= . What may be harder is to translate directly is a CoAP-based application t= o HTTP. So I guess the question is: Do we want to be hamstrung to synchrono= us client/server transactions as dictated by HTTP and provide a direct mapp= ing to HTTP, then have to come up with similar kludges for asynchronous pee= r-to-peer transactions as has been done in numerous ways for HTTP, or do we= want to define the protocol cleanly to start with and accept that some sor= t of transaction relaying/conversion would have to take place at a mapping = node? > > Robert > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 1924 910888 > +1 415 513 0064http://www.gridmerge.com > > On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote: > Hi, > it looks to me that CoAP should use an explicit sub/notify mechanism sinc= e this is the core of the machine-to-machine interaction model. > HTTP suffers of this lack and we have seen a plethora of solutions to giv= e an asynch taste to it. Webhooks and websockets are only the lasts of the = list. > As someone has already pointed out on this list, it is theoretically poss= ible to describe sub/notify using only CRUD methods but it looks a little b= it tricky and verbose. > > Now we have a chance to build from scratch a new protocol with and I thin= k using explicit sub/notify methods with a clear and well defined semantic = is the best option. It is easily understanding from every developer and wil= l prevent to build other fanny solutions on top of the CoAP. HTTP does not = have this well defined semantic and (for hundreds of other reasons also) it= is not used as wide protocol for machine-to-machine communication. > > CoAP - as binary protocol - and with an explicit asynch model has a chanc= e to be a really wide protocol for M2M communication not only for constrain= ed environments. > > my 2 cents > > - adriano > > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org ] On Behalf Of Paul Duffy (paduffy) > Sent: mercoled=EC 26 maggio 2010 0.47 > To: Zach Shelby > Cc: core > Subject: Re: [core] Subscribe/Notify for CoAP > > On 5/25/2010 6:41 PM, Zach Shelby wrote: > > Hi, > > On May 26, 2010, at 12:23 AM, Charles Palmer wrote: > > > Hi folks > > It occurs to me that CoRE should be keeping a close eye on ZigBee SE2.0 w= ork, so that it is as easy as possible for ZigBee SE to use CoRE when ready= . That suggests to me that we should align with their subscribe/notify proc= ess. > > > I am not sure I understand that. I mean, ZigBee SE2.0 is defining an appl= ication specific subscribe/notify mechanism for that purpose so far for HTT= P. This uses standard HTTP methods and some custom payload and REST interfa= ces. CoAP Req/Res is already totally compatible with SE2.0 in that respect,= so alignment is already OK there. Nothing stopping someone from using SE2.= 0 over CoAP. > > Specifying a native susbcription/notify into CoAP is another matter. We c= an't adopt a solution specific to one application as that won't solve the p= roblems of other applications nor general HTTP mapping at all (probably wou= ld make it worse). It seems that for the near future there will be a bunch = of HTTP push mechanisms in use without any clear standard appearing - or am= I wrong there? > > > > > If COAP extends HTTP semantics with new subscription methods, it will > not be possible to easily interchange HTTP/COAP, and translation > gateways will become more complex to implement. > > > > Zach > > > Regards - Charles > > > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org ] On Behalf Of Paul Duffy > Sent: 25 May 2010 03:48 > To: Zach Shelby > Cc: core > Subject: Re: [core] Subscribe/Notify for CoAP > > Recommend something like #2, primarily to avoid introducing non HTTP > method semantics, simplifying HTTP/COAP translation.gateways, etc. > > > On 5/24/2010 11:49 AM, Zach Shelby wrote: > > (thread renamed) > > We have two different paths with regard to a subscribe/notify mechanism f= or CoAP: > > 1. Use specific Subscription and Notify mechanisms for CoAP as HTTP reall= y does not include this concept. > 1a) Notify as a message and SUBSCRIBE as a method. This is currently used= in coap-01. > 1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but we had= a good list discussion about this leading to a. In practice it doesn't mak= e a big difference if notification is a message or method. > > 2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2.0 prop= osal or GENA. > > So far we have focused on 1 in the WG, and every now and again 2 comes up= . At least I am not convinced that we need to suffer the drawbacks of HTTP = here. Anyways 2 does not help our mapping to HTTP in reality very much as t= here is no standard way of doing this over HTTP. Thus a CoAP-HTTP proxy may= end up anyways translating between multiple HTTP frameworks depending on t= he application. So instead of doing a CoAP Notify/Subscribe to Webhooks map= ping, you will could end up having to do a CoAP Webhooks to HTTP GENA mappi= ng. > > > > I don't understand this last para. If CoAP sticks to the semantics of > the current HTTP methods, would this not offer a fairly straightforward > translation to/from HTTP? > > > > From what I have heard so far 1 still seems like a wise choice, although = I need to look at Webhooks more deeply. In reality many applications specif= y their own way of doing a push interface using REST methods and specific p= ayloads (ZigBee SE2.0 is such an example). That is just fine, and might be = used instead of a specific CoAP notify/subscribe in that case. So 1 doesn't= prevent the application using its own mechanism, it just provides a native= way for doing push. > > What do people think? > > Zach > > On May 17, 2010, at 6:44 PM,matthieu.vial@fr.non.schneider-electric.com w= rote: > > > > Hi, > > My comments about the subscribe/notify mechanism of Zigbee IP. > > Pros: > - Derived from the webhooks concept > - If used by CORE it will be easier to map to HTTP because it uses only C= RUD verbs. > - The subscription message is extendable and could support advanced optio= ns (delays, increment, ...) > - Only one listening port whatever the transport binding is. > > Cons: > - No interoperability without well known URIs and a well defined subscrip= tion message format (Not sure CoAP draft is the right place to specify this= ). > - XML/EXI is too complex to be the required format for the default subscr= iption/notification mechanism. > - The notification should not require a subsequent GET to retrieve the co= ntent. > - Subresource subscription is redundant. > > Hope this could help, > Matthieu > > > "Charles Palmer" > > > > > "Charles Palmer" > Envoy=E9 par : core-bounces@ietf.org > 15/05/2010 14:06 > > > A > > "core" > > cc > > > Objet > > Re: [core] Selecting a WG document for CoAP > > > Dear all > > Those interested in the subscribe/notify discussion might like to look > at the draft Smart Energy Profile 2.0 Application Protocol > Specification. It is available here:http://zigbee.org/Markets/ZigBeeSmart= Energy/ZigBeeSmartEnergy20PublicApp > licationProfile.aspx > > It manages subscribe/notify by using POST. This seems to remove the need > for SUBSCRIBE and notify. > > "Imagine a host A, which exposes a resource at http{s}://A/resource and > a second host B, which wishes to learn of changes to this resource. To > facilitate a subscription/ notification mechanism, A would expose a > resource http{s}://A/sub and B would expose a resource http{s}://B/ntfy. > To subscribe to notifications regarding http{s}://A/resource, B would > send a POST to the address http{s}://A/sub/B containing the URI of the > resource of interest (http{s}://A/resource) and the URI of B's > notification resource (http{s}://B/ntfy). Following this subscription > step, should A wish to notify B of a change to the resource addressed at > http{s}://A/resource, A would send a POST to the address > http{s}://B/ntfy containing the URI of the resource changed > (http{s}://A/resource) and the URI of A's subscription resource > (http{s}://A/sub/B), should A wish to change its subscription. The host > B can then query the resource (or not) at its leisure." > > Sleepy nodes are not allowed to subscribe, and must poll. > > Regards - Charles Palmer > > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org ] On Behalf Of > Angelo P. Castellani > Sent: 14 May 2010 13:14 > To: Zach Shelby > Cc: core > Subject: Re: [core] Selecting a WG document for CoAP > > Zach, > > thanks for the comments, but please refer to my most recent e-mail for > a more specific list of technical issues I'm pointing to. > > I want to do only a little integration to what I've written there. > > In my very personal opinion, to maximize adherence with the REST model > and minimize implementation effort SUBSCRIBE and NOTIFY should be > mapped to methods (as discussed many times together...). > > Uniform interface principle (Fielding PhD dissertation Section 5.1.5, > "The central feature that distinguishes the REST architectural style > [...]") states that to simplify the software architecture, resource > interfaces/interfaces should be as general as possible. > > I agree with this principle in this specific case, mainly because > handling a special message type for notify leads node software design > to a more complex architecture. > > The reason is that this new message type requires special handling and > introduces a complexity in the software modularization. > > Best, > Angelo > > On Fri, May 14, 2010 at 13:06, Zach Shelby wrote: > > > Hi Angelo, > > On May 13, 2010, at 14:24 , Angelo P. Castellani wrote: > > > > Dear C. Bormann, all, > > before deciding for the final direction, I've the following > observations about draft-shelby-core-coap-01 > > While I mostly share Zach's view of the protocol approach, and > appreciate many aspects of the proposal, there are in my opinion > > > still > > > some open issues that need to be at least discussed before the > > > current > > > document can be selected. > > > Of course there are plenty of open issues. Remember that working group > > > documents still undertake as much change and improvement as the WG > wants, so by no means is coap-01 set in stone. I would expect at least > 5-10 more revisions still along the way. Already several of your ideas > have been integrated into coap-01, and several more are under > consideration, so it is coming along. Patience ;-) > > > > In particular, I would like to highlight the following: > > a) As it is now, it is not possible to have a straightforward > translation of HTTP -> CoAP and viceversa: seehttp://www.ietf.org/mail-ar= chive/web/core/current/msg00133.html (this > impacts the scalability of the web service model too) > > > In coap-01 the Method names are now identical to HTTP methods. The > > > Req/Res interaction is a direct translation. The URI hierarchy is > compatible, and the URI binary code format we are still working on > obviously. The only thing that takes some state to translate is > Subscribe/Notify. But note, Subscribe/Notify takes some state no matter > how you do it, even with HTTP-HTTP there is no clean and easy way to > handle subscriptions. > > > > b) Moreover, CoAP's implementation is not as simple as it should be. > I've investigated the implementation and some design choices (as > Options) are leading to very high program complexity (ROM) on a > MSP430-based device. > > > This we can definitely improve, and already made several optimizations > > > from -00 to -01. Here I need some very concrete proposals though. Also > remember that many things are optional, for example subscribe/notify is > not required if you don't need it. > > > > c) Finally when comparing HTTP message size with CoAP message size, > the resulting compression isn't as good as you may expect. > > Example: > HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B > CoAP: 24 B with options parsing procedure requiring an added > implementation complexity > > > Right, that is not how it will work in practice. Working with a real > > > HTTP server that HTTP header will be more complex, and on the CoAP side > you would chose shorter URLs. The biggest improvement possible here is > from using binary coded URLs of course. We need to look at a wider range > of interactions and real HTTP headers as well to check that we are > efficient enough. > > > > Addressing all these points potentially leads to major technical > modifications (especially point a) on the current draft, hence it is > appropriate in my opinion to discuss these points before making the > final decision. > > > I am not sure what else you have in mind for a). If we just forget > > > about Subscribe/Notify then you are good to go. But then you are also > not fulfilling the charter or the industry needs in that respect. > > > Thanks, > Zach > > > > Best regards, > > Angelo P. Castellani > > > On Mon, May 10, 2010 at 18:51, Carsten Bormann wrote: > > > The CORE WG has a milestone to select a WG document for CoAP in > > > April: > > http://datatracker.ietf.org/wg/core/charter/ > ... > Apr 2010 Select WG document for basis of the CoAP protocol > > Of the various documents that have been contributed, > > > draft-shelby-core-coap has significant discussion, as well as the > largest number of updates (including a previous version that was still > called -6lowapp-coap). > > > Today, another updated version of that draft was announced. Seehttp://www= .ietf.org/mail-archive/web/core/current/msg00138.html > for the announcement andhttp://tools.ietf.org/html/draft-shelby-core-coap= -01 > for the draft itself. > > However, as the authors say, there are still significant TODOs. > > Are we in a state yet where we can say whether this is the right > > > direction for the WG to take? > > > If yes, is it the right direction? Should we adopt it as a WG > > > document? > > > If you don't think we can say yet, is there a set of technical > > > decisions you would like the authors to take with priority? > > > Note that once a document has become a WG document, the authors act > > > as editors for the working group, making (and usually fleshing out the > details of) any change that the WG decides it needs. > > > If you think we can still improve the draft, this is not an obstacle > > > to making it a WG document. > > > But of course we shouldn't do that if we intend to reverse its > > > fundamental technical direction. > > > In order to stay roughly in sync with our milestones, we should > > > reach at a decision on how to go forward this week. > > > Gruesse, Carsten > > _______________________________________________ > core mailing listcore@ietf.orghttps://www.ietf.org/mailman/listinfo/core > > > > _______________________________________________ > core mailing listcore@ietf.orghttps://www.ietf.org/mailman/listinfo/core > > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd.http://zachshelby.org - My blog "O= n the Internet of Things" > http://6lowpan.net - My book " 6LoWPAN: The Wi= reless Embedded Internet" > Mobile: +358 40 7796297 > > > > > _______________________________________________ > core mailing listcore@ietf.orghttps://www.ietf.org/mailman/listinfo/core > > -------------------------------- > Onzo is a limited company number 06097997 registered in England& Wales. T= he > registered office is 6 Great Newport Street, London, WC2H 7JB, United Kin= gdom. > > This email message may contain confidential and/or privileged information= , and > is intended solely for the addressee(s). If you have received this email = in > error, please notify Onzo immediately. Unauthorised copying, disclosure o= r > distribution of the material in this email is forbidden. > -------------------------------- > > _______________________________________________ > core mailing listcore@ietf.orghttps://www.ietf.org/mailman/listinfo/core > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > ______________________________________________________________________ > > _______________________________________________ > core mailing listcore@ietf.orghttps://www.ietf.org/mailman/listinfo/core > > > > _______________________________________________ > core mailing listcore@ietf.orghttps://www.ietf.org/mailman/listinfo/core > > -------------------------------- > Onzo is a limited company number 06097997 registered in England& Wales. T= he > registered office is 6 Great Newport Street, London, WC2H 7JB, United Kin= gdom. > > This email message may contain confidential and/or privileged information= , and > is intended solely for the addressee(s). If you have received this email = in > error, please notify Onzo immediately. Unauthorised copying, disclosure o= r > distribution of the material in this email is forbidden. > -------------------------------- > > > > > _______________________________________________ > core mailing listcore@ietf.orghttps://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing listcore@ietf.orghttps://www.ietf.org/mailman/listinfo/core > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > _________________________________________________________________________= ____________________________________________ > core mailing listcore@ietf.orghttps://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing listcore@ietf.orghttps://www.ietf.org/mailman/listinfo/core > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd.http://zachshelby.org - My blog "= On the Internet of Things" > http://6lowpan.net - My book " 6LoWPAN: The Wi= reless Embedded Internet" > Mobile: +358 40 7796297 > > _______________________________________________ > core mailing listcore@ietf.orghttps://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing listcore@ietf.orghttps://www.ietf.org/mailman/listinfo/core > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --0016e6d645a839ca0c0487ae17ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
My two cents:=A0

Personally I find it confusing to= have both a message type *and* a method.

Do we really n= eed both? =A0It seems we just combine the two into a single method byte. = =A0Maybe reserve a bit to say a message is a response to a GET, PUT, DELETE= , etc.



On Fri, May 28, 2010= at 1:22 PM, Robert Cragie <robert.cragie@gridmerge.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex;"> =20
I think sometimes it makes more sense to think about threads of execution.

Forgive me for this lengthy preamble but it will hopefully put things into context.

In the most abstract sense, processing is governed by a thread of execution, which sequences a series of data transformations to expedite the required processing. If a data transformation can be completed synchronously in the thread of execution, then the thread is conceptually easier to understand and follow. Most threading models assume this to be the case and if the data transformation cannot complete, it usually blocks pending the required event to complete the transformation. During blocking, the thread is suspended. In simple CPU models without any sort of scheduler, there are two threads of execution: A main thread, pre-emptable by an interrupt thread, usually not pre-emptable. In the main thread, sub-threads are emulated; data transformations can be simply function calls which don't block and therefore return effectively immediately and synchronously. Blocking data transformations are emulated by storing state relevant to each sub-thread then marshaling each event as it is received e.g. through interrupt handling, which causes the second thread to run and thus allows changing sub-thread state so when the main thread runs, the blocking data transformation can complete. Operating system schedulers for these simple CPUs simply abstract this operation through a kernel and associated task/thread scheduling calls. Continuations are a simpler form used in memory-constrained implementations.

Why the lengthy pre-amble? However you look at it, what essentially is required for any threading model (using kernel/scheduler, continuations, emulated, whatever) are fundamentally three primitives:
  • Request
  • Response
  • Notify
A thread of execution will call request and will typically (though not necessarily - see emulated blocking/continuations) wait for a response. If the thread blocks, it is typically woken by another worker thread handling a notify. The worker thread handles notifies asynchronously and buffers and/or signals the associated task accordingly.

This is why I think the current foundation level of messages in coap-01 is right.

On top of this, the payload of the messages can reflect the actual method. Personally, I don't see the need for a specific SUBSCRIBE message; a POST/create to a subscription resource seems adequate to me. The notify message can carry a PUT or POST depending on whether the resource was simply updated or appended to (again it is no accident the data types in JSON are as they are).

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerg= e.com


On 28/05/2010 2:13 PM, Angelo P. Castellani wrote: 
In my opinion Subscribe/Notify are special methods of interaction
between resources.

1) SUBSCRIBE: Any resource A can send a Request to SUBSCRIBE with a
resource B (to the resource B URI).

When B receives the request, B can (should/must?) answer with a
Response to the SUBSCRIBE Request, telling the result of the request
(subscription accepted/denied/unsupported?).

2) NOTIFY: When subscription condition fires the resource B sends a
NOTIFY Request to resource A URI.

When A receives the request, A can (should/must?) answer with a
Response to the NOTIFY Request, telling the result of the request (OK,
cancel subscription, change notify options?).

In each Request must be specified the URI of the resource doing the
Request too (Option? From-URI?).

Angelo

On Fri, May 28, 2010 at 14:50, Zach Shelby <zach@sensinode.com> wrote:
  
Hi,

This is a really good conversation. One thing we need to do is remember wha=
t our minimum requirements are for subscribe/notify and not try to solve so=
mething more than we should. From what I know it is sufficient to be able t=
o receive notifications when a URI changes or periodically. You might consi=
der new URIs under this URI path to be changes to a URI though...

On May 28, 2010, at 3:08 PM, Adriano Pezzuto (apezzuto) wrote:

    
Hello,
with this flavor, the SUBSCRIBE may be replaced by a simple POST. So no nee=
ds to have an explicit SUBSCRIBE method.
      
This is what coap-01 assumes.

    
If we want support a more oriented peer-to-peer transaction on C=
oAP, it looks to me both SUB and NOTIFY should be treated as messages.
      
The Request/Response model can be used peer-to-peer, and in CoAP y=
ou can even use a Request asynchronously. Additionally, we want a native RE=
STful subscribe/notify technique, that is, we want to subscribe to resource=
s and be susequently notified about those resources when they change.

In that sense, you can think of a subscription as a request to receive asyn=
chronous notifications about a resource (about a URI). This can be achieved=
 by:

1. =A0as a SUBSCRIBE Request on the URI with some option indicating the lif=
etime as in coap-01,
2. =A0as a Subcsribe message (no methods) on the URI with some option,
3. =A0or as a POST Request on the URI with options indicating that this is =
actually a subscription and the lifetime. =A0This bends the meaning of POST=
 quite a bit and might be prone to mistakes?

The asynchronous response is a harder one. Can we bend the meaning of a Req=
uest for making asynchronous notifications? Also a notification includes a =
URI about a resource on the requestor, which is inverse from normal Request=
s in REST. So the options here are:

1. as a Notify message about a URI (no methods) as in coap-01,
2. as a NOTIFY Request about a URI as was in coap-00,
3. hmmm... reusing CRUD methods really doesn't work for this one at all=
...

I wonder what the HTTP designers would have done if this would have been a =
requirement back then? Maybe we should ask them...

Zach

    
Adriano

From: matthieu.vial@fr.non.schneider-electric.com [mailto:m=
atthieu.vial@fr.non.schneider-electric.com]
Sent: venerd=EC 28 maggio 2010 13.52
To: Adriano Pezzuto (apezzuto)
Cc: core; core-b=
ounces@ietf.org; robert.cragie@gridmerge.com
Subject: Re: [core] Subscribe/Notify for CoAP

      
So strictly speaking, both NOTIFY and SUBSCRIBE are message ty=
pes not =A0methods!
        
SUBSCRIBE can be just an asynchronous GET on update then I think=
 it is a method and NOTIFY is an asynchronous response so a message.
But if we want to have selective notifications when a resource is created, =
updated or deleted then I think you're right NOTIFY and SUBSCRIBE are m=
essages.

Does that make sense ?

Matthieu

<image001.gif>"Adriano Pezzuto (apezzuto)" <apezzuto@cisco.com>




"Adriano Pezzuto (apezzuto)" <apezzuto@cisco.com>
Envoy=E9 par : c=
ore-bounces@ietf.org
28/05/2010 12:50

<image003.png>
A
<image004.png>
<robert=
.cragie@gridmerge.com>
<image003.png>
cc
<image004.png>
core <core@ietf.org&g=
t;
<image003.png>
Objet
<image004.png>
Re: [core] Subscribe/Notify for CoAP
<image004.png>
<image004.png>

Hi Roberto,
I understand your point and personally agree on M2M is quite different from=
 web page model. On the architectural RESTful style, the method information=
 tells the server what to do with data kept in the URI information.

So strictly speaking, both NOTIFY and SUBSCRIBE are message types not =A0me=
thods!

Adriano

From: Robert Cragie [mailto:robert.cragie@gridmerge.com]
Sent: venerd=EC 28 maggio 2010 11.53
To: Adriano Pezzuto (apezzuto)
Cc: Paul Duffy (paduffy); Zach Shelby; core
Subject: Re: [core] Subscribe/Notify for CoAP

I think the point here is that there are two levels we are considering.

At the lowest (foundation) level, there are the transaction messages as des=
cribed below. This provides a flexible mechanism for the application with r=
egard to synchronicity and threading. This is important for the types of de=
vices CoAP is being aimed at.

Above that, the methods can be used according to the architectural style. S=
o in this case, it is RESTful (COnstrained Restful Environments), which wil=
l naturally limit the number of methods and how transactions occur.

The actual architecture using a combination of the methods and messages als=
o depends on what is required at the application layer. Consider a typical =
client which wants to subscribe to a resource. That client controls the fee=
d of data but needs a component which is capable of handling (possibly buff=
ering) the data it receives through notifications. Is this a separate serve=
r? Or would we want to consider it part of an enhanced client model which i=
s able to process feeds of data? These are the sort of models which have le=
d to the myriad of solutions (GENA, Webhooks, long polling, pubsubhubbub, R=
ESTMS etc.) based around HTTP which are all essentially ingenious ways of g=
etting around the limitations imposed by HTTP and how it is processed for a=
nything which deviates from the classic web page access model.

I think the aim of CoAP should be clean from the word go with regard to sup=
porting these more peer-to-peer transactions, where the client can exist on=
 either entity and both entities can feed data to each other; typical in M2=
M applications.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge=
.com

On 27/05/2010 7:08 PM, Adriano Pezzuto (apezzuto) wrote:
Hi Robert,

in my personal opinion, the option 1a) brings some sort of ambiguity to CoA=
P specs.

My be my understatement of new CoAP specs is not so deep, but now we have 5=
 methods and 3 message types: request, response and notify. Which methods a=
re allowed with which messages types?
I suppose you have to use PUT/POST method with notify message for asynch da=
ta notification. How to make a subscribe? I suppose you would use a SUBSCRI=
BE method with request/response message or SUBSCRIBE with notify message? A=
lso what about POST/DELETE methods in a notify message? They not make any s=
ense..

I think the choice is between: option 1) -> only CRUD methods and option=
 1b) -> CRUD + SUB/NOTIFY methods, keeping in mind cost/benefits of both=
 solutions.

Adriano

From: Robert Cragie [mailto:robert.cragie@gridmerge.com]
Sent: mercoled=EC 26 maggio 2010 20.09
To: Adriano Pezzuto (apezzuto)
Cc: Paul Duffy (paduffy); Zach Shelby; core
Subject: Re: [core] Subscribe/Notify for CoAP

Hi Adrian,

I would also prefer to keep the protocol in CoAP asynchronous. You can alwa=
ys map an asynchronous protocol to a synchronous one but, as we see in HTTP=
, it always ends up as a kludge to do it the other way round. The efforts w=
hich have been gone to to make HTTP quasi-asynchronous via all the schemes =
mentioned below and many more besides (all non-interoperable of course) is =
testament to how important this is for M2M communication.

So, back to Zach's list, I favor 1a) for the following reasons:

Foundation level of messages:

1. request/response can be asynchronous or synchronous messages (as there i=
s a transaction ID in there)
2. notify is an asynchronous message
Derived methods:

I think it makes sense to add a pub/sub model as a useful mechanism for M2M=
.

So, looking at it the other way round: It will be entirely possible to tran=
slate whatever is currently built on HTTP to CoAP based on the above, with =
all its restrictions regarding synchronous and client/server transactions. =
What may be harder is to translate directly is a CoAP-based application to =
HTTP. So I guess the question is: Do we want to be hamstrung to synchronous=
 client/server transactions as dictated by HTTP and provide a direct mappin=
g to HTTP, then have to come up with similar kludges for asynchronous peer-=
to-peer transactions as has been done in numerous ways for HTTP, or do we w=
ant to define the protocol cleanly to start with and accept that some sort =
of transaction relaying/conversion would have to take place at a mapping no=
de?

Robert
Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge=
.com

On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote:
Hi,
it looks to me that CoAP should use an explicit sub/notify mechanism since =
this is the core of the machine-to-machine interaction model.
HTTP suffers of this lack and we have seen a plethora of solutions to give =
an asynch taste to it. Webhooks and websockets are only the lasts of the li=
st.
As someone has already pointed out on this list, it is theoretically possib=
le to describe sub/notify using only CRUD methods but it looks a little bit=
 tricky and verbose.

Now we have a chance to build from scratch a new protocol with and I think =
using explicit sub/notify methods with a clear and well defined semantic is=
 the best option. It is easily understanding from every developer and will =
prevent to build other fanny solutions on top of the CoAP. HTTP does not ha=
ve this well defined semantic and (for hundreds of other reasons also) it i=
s not used as wide protocol for machine-to-machine communication.

CoAP - as binary protocol - and with an explicit asynch model has a chance =
to be a really wide protocol for M2M communication not only for constrained=
 environments.

my 2 cents

- adriano

-----Original Message-----
From: core-bounc=
es@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Paul Duffy (paduffy)
Sent: mercoled=EC 26 maggio 2010 0.47
To: Zach Shelby
Cc: core
Subject: Re: [core] Subscribe/Notify for CoAP

On 5/25/2010 6:41 PM, Zach Shelby wrote:

Hi,

On May 26, 2010, at 12:23 AM, Charles Palmer wrote:


Hi folks

It occurs to me that CoRE should be keeping a close eye on ZigBee SE2.0 wor=
k, so that it is as easy as possible for ZigBee SE to use CoRE when ready. =
That suggests to me that we should align with their subscribe/notify proces=
s.


I am not sure I understand that. I mean, ZigBee SE2.0 is defining an applic=
ation specific subscribe/notify mechanism for that purpose so far for HTTP.=
 This uses standard HTTP methods and some custom payload and REST interface=
s. CoAP Req/Res is already totally compatible with SE2.0 in that respect, s=
o alignment is already OK there. Nothing stopping someone from using SE2.0 =
over CoAP.

Specifying a native susbcription/notify into CoAP is another matter. We can=
't adopt a solution specific to one application as that won't solve=
 the problems of other applications nor general HTTP mapping at all (probab=
ly would make it worse). It seems that for the near future there will be a =
bunch of HTTP push mechanisms in use without any clear standard appearing -=
 or am I wrong there?




If COAP extends HTTP semantics with new subscription methods, it will
not be possible to easily interchange HTTP/COAP, and translation
gateways will become more complex to implement.



Zach


Regards - Charles


-----Original Message-----
From: core-bounc=
es@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Paul Duffy
Sent: 25 May 2010 03:48
To: Zach Shelby
Cc: core
Subject: Re: [core] Subscribe/Notify for CoAP

Recommend something like #2, primarily to avoid introducing non HTTP
method semantics, simplifying HTTP/COAP translation.gateways, etc.


On 5/24/2010 11:49 AM, Zach Shelby wrote:

(thread renamed)

We have two different paths with regard to a subscribe/notify mechanism for=
 CoAP:

1. Use specific Subscription and Notify mechanisms for CoAP as HTTP really =
does not include this concept.
1a) Notify as a message and SUBSCRIBE as a method. This is currently used i=
n coap-01.
1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but we had a=
 good list discussion about this leading to a. In practice it doesn't m=
ake a big difference if notification is a message or method.

2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2.0 propos=
al or GENA.

So far we have focused on 1 in the WG, and every now and again 2 comes up. =
At least I am not convinced that we need to suffer the drawbacks of HTTP he=
re. Anyways 2 does not help our mapping to HTTP in reality very much as the=
re is no standard way of doing this over HTTP. Thus a CoAP-HTTP proxy may e=
nd up anyways translating between multiple HTTP frameworks depending on the=
 application. So instead of doing a CoAP Notify/Subscribe to Webhooks mappi=
ng, you will could end up having to do a CoAP Webhooks to HTTP GENA mapping=
.



I don't understand this last para. If CoAP sticks to the semantics of
the current HTTP methods, would this not offer a fairly straightforward
translation to/from HTTP?



>From what I have heard so far 1 still seems like a wise choice, although I =
need to look at Webhooks more deeply. In reality many applications specify =
their own way of doing a push interface using REST methods and specific pay=
loads (ZigBee SE2.0 is such an example). That is just fine, and might be us=
ed instead of a specific CoAP notify/subscribe in that case. So 1 doesn'=
;t prevent the application using its own mechanism, it just provides a nati=
ve way for doing push.

What do people think?

Zach

On May 17, 2010, at 6:44 PM,matthieu.vial@fr.non.schneider-electric.c=
om wrote:



Hi,

My comments about the subscribe/notify mechanism of Zigbee IP.

Pros:
- Derived from the webhooks concept
- If used by CORE it will be easier to map to HTTP because it uses only CRU=
D verbs.
- The subscription message is extendable and could support advanced options=
 (delays, increment, ...)
- Only one listening port whatever the transport binding is.

Cons:
- No interoperability without well known URIs and a well defined subscripti=
on message format (Not sure CoAP draft is the right place to specify this).
- XML/EXI is too complex to be the required format for the default subscrip=
tion/notification mechanism.
- The notification should not require a subsequent GET to retrieve the cont=
ent.
- Subresource subscription is redundant.

Hope this could help,
Matthieu


<graycol.gif>"Charles Palmer"<charles.palmer@onzo.com>




"Charles Palmer"<charles.palmer@onzo.com>
Envoy=E9 par : c=
ore-bounces@ietf.org
15/05/2010 14:06

<ecblank.gif>
A
<ecblank.gif>
"core"<core=
@ietf.org>
<ecblank.gif>
cc
<ecblank.gif>
<ecblank.gif>
Objet
<ecblank.gif>
Re: [core] Selecting a WG document for CoAP
<ecblank.gif> <ecblank.gif>

Dear all

Those interested in the subscribe/notify discussion might like to look
at the draft Smart Energy Profile 2.0 Application Protocol
Specification. It is available here:
http://zigbee.org/Markets/ZigBeeSmartEnergy/Zig=
BeeSmartEnergy20PublicApp
licationProfile.aspx

It manages subscribe/notify by using POST. This seems to remove the need
for SUBSCRIBE and notify.

"Imagine a host A, which exposes a resource at http{s}://A/resource an=
d
a second host B, which wishes to learn of changes to this resource. To
facilitate a subscription/ notification mechanism, A would expose a
resource http{s}://A/sub and B would expose a resource http{s}://B/ntfy.
To subscribe to notifications regarding http{s}://A/resource, B would
send a POST to the address http{s}://A/sub/B containing the URI of the
resource of interest (http{s}://A/resource) and the URI of B's
notification resource (http{s}://B/ntfy). Following this subscription
step, should A wish to notify B of a change to the resource addressed at
http{s}://A/resource, A would send a POST to the address
http{s}://B/ntfy containing the URI of the resource changed
(http{s}://A/resource) and the URI of A's subscription resource
(http{s}://A/sub/B), should A wish to change its subscription. The host
B can then query the resource (or not) at its leisure."

Sleepy nodes are not allowed to subscribe, and must poll.

Regards - Charles Palmer

-----Original Message-----
From: core-bounc=
es@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of
Angelo P. Castellani
Sent: 14 May 2010 13:14
To: Zach Shelby
Cc: core
Subject: Re: [core] Selecting a WG document for CoAP

Zach,

thanks for the comments, but please refer to my most recent e-mail for
a more specific list of technical issues I'm pointing to.

I want to do only a little integration to what I've written there.

In my very personal opinion, to maximize adherence with the REST model
and minimize implementation effort SUBSCRIBE and NOTIFY should be
mapped to methods (as discussed many times together...).

Uniform interface principle (Fielding PhD dissertation Section 5.1.5,
"The central feature that distinguishes the REST architectural style
[...]") states that to simplify the software architecture, resource
interfaces/interfaces should be as general as possible.

I agree with this principle in this specific case, mainly because
handling a special message type for notify leads node software design
to a more complex architecture.

The reason is that this new message type requires special handling and
introduces a complexity in the software modularization.

Best,
Angelo

On Fri, May 14, 2010 at 13:06, Zach Shelby<zach@sensinode.com> wrote:


Hi Angelo,

On May 13, 2010, at 14:24 , Angelo P. Castellani wrote:



Dear C. Bormann, all,

before deciding for the final direction, I've the following
observations about draft-shelby-core-coap-01

While I mostly share Zach's view of the protocol approach, and
appreciate many aspects of the proposal, there are in my opinion


still


some open issues that need to be at least discussed before the


current


document can be selected.


Of course there are plenty of open issues. Remember that working group


documents still undertake as much change and improvement as the WG
wants, so by no means is coap-01 set in stone. I would expect at least
5-10 more revisions still along the way. Already several of your ideas
have been integrated into coap-01, and several more are under
consideration, so it is coming along. Patience ;-)



In particular, I would like to highlight the following:

a) As it is now, it is not possible to have a straightforward
translation of HTTP -> CoAP and viceversa: see
http://www.ietf.org/mail-archive/web/core/current/msg001=
33.html (this
impacts the scalability of the web service model too)


In coap-01 the Method names are now identical to HTTP methods. The


Req/Res interaction is a direct translation. The URI hierarchy is
compatible, and the URI binary code format we are still working on
obviously. The only thing that takes some state to translate is
Subscribe/Notify. But note, Subscribe/Notify takes some state no matter
how you do it, even with HTTP-HTTP there is no clean and easy way to
handle subscriptions.



b) Moreover, CoAP's implementation is not as simple as it should be.
I've investigated the implementation and some design choices (as
Options) are leading to very high program complexity (ROM) on a
MSP430-based device.


This we can definitely improve, and already made several optimizations


from -00 to -01. Here I need some very concrete proposals though. Also
remember that many things are optional, for example subscribe/notify is
not required if you don't need it.



c) Finally when comparing HTTP message size with CoAP message size,
the resulting compression isn't as good as you may expect.

Example:
HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B
CoAP: 24 B with options parsing procedure requiring an added
implementation complexity


Right, that is not how it will work in practice. Working with a real


HTTP server that HTTP header will be more complex, and on the CoAP side
you would chose shorter URLs. The biggest improvement possible here is
from using binary coded URLs of course. We need to look at a wider range
of interactions and real HTTP headers as well to check that we are
efficient enough.



Addressing all these points potentially leads to major technical
modifications (especially point a) on the current draft, hence it is
appropriate in my opinion to discuss these points before making the
final decision.


I am not sure what else you have in mind for a). If we just forget


about Subscribe/Notify then you are good to go. But then you are also
not fulfilling the charter or the industry needs in that respect.


Thanks,
Zach



Best regards,

Angelo P. Castellani


On Mon, May 10, 2010 at 18:51, Carsten Bormann<cabo@tzi.org>wrote:


The CORE WG has a milestone to select a WG document for CoAP in


April:


=
http://datatracker.ietf.org/wg/core/charter/
...
Apr 2010 Select WG document for basis of the CoAP protocol

Of the various documents that have been contributed,


draft-shelby-core-coap has significant discussion, as well as the
largest number of updates (including a previous version that was still
called -6lowapp-coap).


Today, another updated version of that draft was announced. See
http://www.ietf.org/mail-archive/web/core/current/msg001=
38.html
for the announcement and
http://tools.ietf.org/html/draft-shelby-core-coap-01
for the draft itself.

However, as the authors say, there are still significant TODOs.

Are we in a state yet where we can say whether this is the right


direction for the WG to take?


If yes, is it the right direction? Should we adopt it as a WG


document?


If you don't think we can say yet, is there a set of technical


decisions you would like the authors to take with priority?


Note that once a document has become a WG document, the authors act


as editors for the working group, making (and usually fleshing out the
details of) any change that the WG decides it needs.


If you think we can still improve the draft, this is not an obstacle


to making it a WG document.


But of course we shouldn't do that if we intend to reverse its


fundamental technical direction.


In order to stay roughly in sync with our milestones, we should


reach at a decision on how to go forward this week.


Gruesse, Carsten

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



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


--
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Inter=
net"
Mobile: +358 40 7796297




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

--------------------------------
Onzo is a limited company number 06097997 registered in England& Wales.=
 The
registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingd=
om.

This email message may contain confidential and/or privileged information, =
and
is intended solely for the addressee(s). If you have received this email in
error, please notify Onzo immediately. Unauthorised copying, disclosure or
distribution of the material in this email is forbidden.
--------------------------------

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

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________

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



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

--------------------------------
Onzo is a limited company number 06097997 registered in England& Wales.=
 The
registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingd=
om.

This email message may contain confidential and/or privileged information, =
and
is intended solely for the addressee(s). If you have received this email in
error, please notify Onzo immediately. Unauthorised copying, disclosure or
distribution of the material in this email is forbidden.
--------------------------------




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



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
___________________________________________________________________________=
__________________________________________
core mailing list
core@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/core

_______________________________________________
core mailing list
core@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/core
      
--
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org =A0- My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Inter=
net"
Mobile: +358 40 7796297

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

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

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

Hi,

The Waka protocol from Roy Fielding has a new monitor verb
http://en.= wikipedia.org/wiki/Waka_%28protocol%29

Matthieu

3D"InactiveZach Shelby <zach@sensinode.com&g= t;




=
          Zach Shelby <zach@sensinode.com>

          28/05/2010 14:50

 =
3D=
A
3D""
Adriano Pezzuto (apezzuto) <apezzuto@cisco.com><= /font>
3D=
cc
3D""
Matthieu Vial/FR/Non/Schneider@Europe, core <core@i= etf.org>
3D=
Objet
3D""
Re: [core] Subscribe/Notify for CoAP
3D=3D""

Hi,

This is a really good conversation. One thing we need to do is remember= what our minimum requirements are for subscribe/notify and not try to = solve something more than we should. From what I know it is sufficient = to be able to receive notifications when a URI changes or periodically.= You might consider new URIs under this URI path to be changes to a URI= though...

On May 28, 2010, at 3:08 PM, Adriano Pezzuto (apezzuto) wrote:

> Hello,
> with this flavor, the SUBSCRIBE may be replaced by a simple POST. = So no needs to have an explicit SUBSCRIBE method.

This is what coap-01 assumes.

> If we want support a more oriented peer-to-peer transaction on CoA= P, it looks to me both SUB and NOTIFY should be treated as messages.
The Request/Response model can be used peer-to-peer, and in CoAP you ca= n even use a Request asynchronously. Additionally, we want a native RES= Tful subscribe/notify technique, that is, we want to subscribe to resou= rces and be susequently notified about those resources when they change= .

In that sense, you can think of a subscription as a request to receive = asynchronous notifications about a resource (about a URI). This can be = achieved by:

1.  as a SUBSCRIBE Request on the URI with some option indicating = the lifetime as in coap-01,
2.  as a Subcsribe message (no methods) on the URI with some optio= n,
3.  or as a POST Request on the URI with options indicating that t= his is actually a subscription and the lifetime.  This bends the m= eaning of POST quite a bit and might be prone to mistakes?

The asynchronous response is a harder one. Can we bend the meaning of a= Request for making asynchronous notifications? Also a notification inc= ludes a URI about a resource on the requestor, which is inverse from no= rmal Requests in REST. So the options here are:

1. as a Notify message about a URI (no methods) as in coap-01,
2. as a NOTIFY Request about a URI as was in coap-00,
3. hmmm... reusing CRUD methods really doesn't work for this one at all= ...

I wonder what the HTTP designers would have done if this would have bee= n a requirement back then? Maybe we should ask them...

Zach

>  
> Adriano
>  
> From: matthieu.vial@fr.non.schneider-electric.com [mailto:matthieu.vial@fr= .non.schneider-electric.com]
> Sent: venerd=EC 28 maggio 2010 13.52
> To: Adriano Pezzuto (apezzuto)
> Cc: core; core-bounces@ietf.org; robert.cragie@gridmerge.com
> Subject: Re: [core] Subscribe/Notify for CoAP
>  
> > So strictly speaking, both NOTIFY and SUBSCRIBE are message t= ypes not  methods!
>
> SUBSCRIBE can be just an asynchronous GET on update then I think i= t is a method and NOTIFY is an asynchronous response so a message.
> But if we want to have selective notifications when a resource is = created, updated or deleted then I think you're right NOTIFY and SUBSCR= IBE are messages.
>
> Does that make sense ?
>
> Matthieu
>
> <image001.gif>"Adriano Pezzuto (apezzuto)" <ape= zzuto@cisco.com>
>
>
>
>
> "Adriano Pezzuto (apezzuto)" <apezzuto@cisco.com> =
> Envoy=E9 par : core-bounces@ietf.org
> 28/05/2010 12:50
>
> <image003.png>
> A
> <image004.png>
> <robert.cragie@gridmerge.com>
> <image003.png>
> cc
> <image004.png>
> core <core@ietf.org>
> <image003.png>
> Objet
> <image004.png>
> Re: [core] Subscribe/Notify for CoAP
> <image004.png>
> <image004.png>
>
> Hi Roberto,
> I understand your point and personally agree on M2M is quite diffe= rent from web page model. On the architectural RESTful style, the metho= d information tells the server what to do with data kept in the URI inf= ormation.
>
> So strictly speaking, both NOTIFY and SUBSCRIBE are message types = not  methods!
>
> Adriano
>
> From: Robert Cragie [mailto:robert.cragie@gridmerge.com]
> Sent: venerd=EC 28 maggio 2010 11.53
> To: Adriano Pezzuto (apezzuto)
> Cc: Paul Duffy (paduffy); Zach Shelby; core
> Subject: Re: [core] Subscribe/Notify for CoAP
>
> I think the point here is that there are two levels we are conside= ring.
>
> At the lowest (foundation) level, there are the transaction messag= es as described below. This provides a flexible mechanism for the appli= cation with regard to synchronicity and threading. This is important fo= r the types of devices CoAP is being aimed at.
>
> Above that, the methods can be used according to the architectural= style. So in this case, it is RESTful (COnstrained Restful Environment= s), which will naturally limit the number of methods and how transactio= ns occur.
>
> The actual architecture using a combination of the methods and mes= sages also depends on what is required at the application layer. Consid= er a typical client which wants to subscribe to a resource. That client= controls the feed of data but needs a component which is capable of ha= ndling (possibly buffering) the data it receives through notifications.= Is this a separate server? Or would we want to consider it part of an = enhanced client model which is able to process feeds of data? These are= the sort of models which have led to the myriad of solutions (GENA, We= bhooks, long polling, pubsubhubbub, RESTMS etc.) based around HTTP whic= h are all essentially ingenious ways of getting around the limitations = imposed by HTTP and how it is processed for anything which deviates fro= m the classic web page access model.
>
> I think the aim of CoAP should be clean from the word go with rega= rd to supporting these more peer-to-peer transactions, where the client= can exist on either entity and both entities can feed data to each oth= er; typical in M2M applications.
>
> Robert
>
> Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, UK
> +44 1924 910888
> +1 415 513 0064
> http://www.gridmerge= .com
>
> On 27/05/2010 7:08 PM, Adriano Pezzuto (apezzuto) wrote:
> Hi Robert,
>
> in my personal opinion, the option 1a) brings some sort of ambigui= ty to CoAP specs.
>
> My be my understatement of new CoAP specs is not so deep, but now = we have 5 methods and 3 message types: request, response and notify. Wh= ich methods are allowed with which messages types?
> I suppose you have to use PUT/POST method with notify message for = asynch data notification. How to make a subscribe? I suppose you would = use a SUBSCRIBE method with request/response message or SUBSCRIBE with = notify message? Also what about POST/DELETE methods in a notify message= ? They not make any sense..
>
> I think the choice is between: option 1) -> only CRUD methods a= nd option 1b) -> CRUD + SUB/NOTIFY methods, keeping in mind cost/ben= efits of both solutions.
>
> Adriano
>
> From: Robert Cragie [mailto:robert.cragie@gridmerge.com]
> Sent: mercoled=EC 26 maggio 2010 20.09
> To: Adriano Pezzuto (apezzuto)
> Cc: Paul Duffy (paduffy); Zach Shelby; core
> Subject: Re: [core] Subscribe/Notify for CoAP
>
> Hi Adrian,
>
> I would also prefer to keep the protocol in CoAP asynchronous. You= can always map an asynchronous protocol to a synchronous one but, as w= e see in HTTP, it always ends up as a kludge to do it the other way rou= nd. The efforts which have been gone to to make HTTP quasi-asynchronous= via all the schemes mentioned below and many more besides (all non-int= eroperable of course) is testament to how important this is for M2M com= munication.
>
> So, back to Zach's list, I favor 1a) for the following reasons: >
> Foundation level of messages:
>
> 1. request/response can be asynchronous or synchronous messages (a= s there is a transaction ID in there)
> 2. notify is an asynchronous message
> Derived methods:
>
> I think it makes sense to add a pub/sub model as a useful mechanis= m for M2M.
>
> So, looking at it the other way round: It will be entirely possibl= e to translate whatever is currently built on HTTP to CoAP based on the= above, with all its restrictions regarding synchronous and client/serv= er transactions. What may be harder is to translate directly is a CoAP-= based application to HTTP. So I guess the question is: Do we want to be= hamstrung to synchronous client/server transactions as dictated by HTT= P and provide a direct mapping to HTTP, then have to come up with simil= ar kludges for asynchronous peer-to-peer transactions as has been done = in numerous ways for HTTP, or do we want to define the protocol cleanly= to start with and accept that some sort of transaction relaying/conver= sion would have to take place at a mapping node?
>
> Robert
> Robert Cragie (Pacific Gas & Electric)
>
> Gridmerge Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, UK
> +44 1924 910888
> +1 415 513 0064
> http://www.gridmerge= .com
>
> On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote:
> Hi,
> it looks to me that CoAP should use an explicit sub/notify mechani= sm since this is the core of the machine-to-machine interaction model.<= br> > HTTP suffers of this lack and we have seen a plethora of solutions= to give an asynch taste to it. Webhooks and websockets are only the la= sts of the list.
> As someone has already pointed out on this list, it is theoretical= ly possible to describe sub/notify using only CRUD methods but it looks= a little bit tricky and verbose.
>
> Now we have a chance to build from scratch a new protocol with and= I think using explicit sub/notify methods with a clear and well define= d semantic is the best option. It is easily understanding from every de= veloper and will prevent to build other fanny solutions on top of the C= oAP. HTTP does not have this well defined semantic and (for hundreds of= other reasons also) it is not used as wide protocol for machine-to-mac= hine communication.
>
> CoAP - as binary protocol - and with an explicit asynch model has = a chance to be a really wide protocol for M2M communication not only fo= r constrained environments.
>
> my 2 cents
>
> - adriano
>
> -----Original Message-----
> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Paul Duffy (paduffy)=
> Sent: mercoled=EC 26 maggio 2010 0.47
> To: Zach Shelby
> Cc: core
> Subject: Re: [core] Subscribe/Notify for CoAP
>
> On 5/25/2010 6:41 PM, Zach Shelby wrote:
>
> Hi,
>
> On May 26, 2010, at 12:23 AM, Charles Palmer wrote:
>
>
> Hi folks
>
> It occurs to me that CoRE should be keeping a close eye on ZigBee = SE2.0 work, so that it is as easy as possible for ZigBee SE to use CoRE= when ready. That suggests to me that we should align with their subscr= ibe/notify process.
>
>
> I am not sure I understand that. I mean, ZigBee SE2.0 is defining = an application specific subscribe/notify mechanism for that purpose so = far for HTTP. This uses standard HTTP methods and some custom payload a= nd REST interfaces. CoAP Req/Res is already totally compatible with SE2= .0 in that respect, so alignment is already OK there. Nothing stopping = someone from using SE2.0 over CoAP.
>
> Specifying a native susbcription/notify into CoAP is another matte= r. We can't adopt a solution specific to one application as that won't = solve the problems of other applications nor general HTTP mapping at al= l (probably would make it worse). It seems that for the near future the= re will be a bunch of HTTP push mechanisms in use without any clear sta= ndard appearing - or am I wrong there?
>
>
>
>
> If COAP extends HTTP semantics with new subscription methods, it w= ill
> not be possible to easily interchange HTTP/COAP, and translation <= br> > gateways will become more complex to implement.
>
>
>
> Zach
>
>
> Regards - Charles
>
>
> -----Original Message-----
> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Paul Duffy
> Sent: 25 May 2010 03:48
> To: Zach Shelby
> Cc: core
> Subject: Re: [core] Subscribe/Notify for CoAP
>
> Recommend something like #2, primarily to avoid introducing non HT= TP
> method semantics, simplifying HTTP/COAP translation.gateways, etc.=
>
>
> On 5/24/2010 11:49 AM, Zach Shelby wrote:
>
> (thread renamed)
>
> We have two different paths with regard to a subscribe/notify mech= anism for CoAP:
>
> 1. Use specific Subscription and Notify mechanisms for CoAP as HTT= P really does not include this concept.
> 1a) Notify as a message and SUBSCRIBE as a method. This is current= ly used in coap-01.
> 1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but= we had a good list discussion about this leading to a. In practice it = doesn't make a big difference if notification is a message or method. >
> 2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2= .0 proposal or GENA.
>
> So far we have focused on 1 in the WG, and every now and again 2 c= omes up. At least I am not convinced that we need to suffer the drawbac= ks of HTTP here. Anyways 2 does not help our mapping to HTTP in reality= very much as there is no standard way of doing this over HTTP. Thus a = CoAP-HTTP proxy may end up anyways translating between multiple HTTP fr= ameworks depending on the application. So instead of doing a CoAP Notif= y/Subscribe to Webhooks mapping, you will could end up having to do a C= oAP Webhooks to HTTP GENA mapping.
>
>
>
> I don't understand this last para. If CoAP sticks to the semantics= of
> the current HTTP methods, would this not offer a fairly straightfo= rward
> translation to/from HTTP?
>
>
>
> From what I have heard so far 1 still seems like a wise choice, al= though I need to look at Webhooks more deeply. In reality many applicat= ions specify their own way of doing a push interface using REST methods= and specific payloads (ZigBee SE2.0 is such an example). That is just = fine, and might be used instead of a specific CoAP notify/subscribe in = that case. So 1 doesn't prevent the application using its own mechanism= , it just provides a native way for doing push.
>
> What do people think?
>
> Zach
>
> On May 17, 2010, at 6:44 PM,matthieu.vial@fr.non.schneider-electri= c.com wrote:
>
>
>
> Hi,
>
> My comments about the subscribe/notify mechanism of Zigbee IP.
= >
> Pros:
> - Derived from the webhooks concept
> - If used by CORE it will be easier to map to HTTP because it uses= only CRUD verbs.
> - The subscription message is extendable and could support advance= d options (delays, increment, ...)
> - Only one listening port whatever the transport binding is.
>
> Cons:
> - No interoperability without well known URIs and a well defined s= ubscription message format (Not sure CoAP draft is the right place to s= pecify this).
> - XML/EXI is too complex to be the required format for the default= subscription/notification mechanism.
> - The notification should not require a subsequent GET to retrieve= the content.
> - Subresource subscription is redundant.
>
> Hope this could help,
> Matthieu
>
>
> <graycol.gif>"Charles Palmer"<charles.palmer@on= zo.com>
>
>
>
>
> "Charles Palmer"<charles.palmer@onzo.com>
> Envoy=E9 par : core-bounces@ietf.org
> 15/05/2010 14:06
>
> <ecblank.gif>
> A
> <ecblank.gif>
> "core"<core@ietf.org>
> <ecblank.gif>
> cc
> <ecblank.gif>
> <ecblank.gif>
> Objet
> <ecblank.gif>
> Re: [core] Selecting a WG document for CoAP
> <ecblank.gif> <ecblank.gif>
>
> Dear all
>
> Those interested in the subscribe/notify discussion might like to = look
> at the draft Smart Energy Profile 2.0 Application Protocol
> Specification. It is available here:
> http://zigbee.org/Markets/ZigBeeSmartEnergy= /ZigBeeSmartEnergy20PublicApp
> licationProfile.aspx
>
> It manages subscribe/notify by using POST. This seems to remove th= e need
> for SUBSCRIBE and notify.
>
> "Imagine a host A, which exposes a resource at http{s}://A/re= source and
> a second host B, which wishes to learn of changes to this resource= . To
> facilitate a subscription/ notification mechanism, A would expose = a
> resource http{s}://A/sub and B would expose a resource http{s}://B= /ntfy.
> To subscribe to notifications regarding http{s}://A/resource, B wo= uld
> send a POST to the address http{s}://A/sub/B containing the URI of= the
> resource of interest (http{s}://A/resource) and the URI of B's
= > notification resource (http{s}://B/ntfy). Following this subscript= ion
> step, should A wish to notify B of a change to the resource addres= sed at
> http{s}://A/resource, A would send a POST to the address
> http{s}://B/ntfy containing the URI of the resource changed
> (http{s}://A/resource) and the URI of A's subscription resource > (http{s}://A/sub/B), should A wish to change its subscription. The= host
> B can then query the resource (or not) at its leisure."
>
> Sleepy nodes are not allowed to subscribe, and must poll.
>
> Regards - Charles Palmer
>
> -----Original Message-----
> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of
> Angelo P. Castellani
> Sent: 14 May 2010 13:14
> To: Zach Shelby
> Cc: core
> Subject: Re: [core] Selecting a WG document for CoAP
>
> Zach,
>
> thanks for the comments, but please refer to my most recent e-mail= for
> a more specific list of technical issues I'm pointing to.
>
> I want to do only a little integration to what I've written there.=
>
> In my very personal opinion, to maximize adherence with the REST m= odel
> and minimize implementation effort SUBSCRIBE and NOTIFY should be<= br> > mapped to methods (as discussed many times together...).
>
> Uniform interface principle (Fielding PhD dissertation Section 5.1= .5,
> "The central feature that distinguishes the REST architectura= l style
> [...]") states that to simplify the software architecture, re= source
> interfaces/interfaces should be as general as possible.
>
> I agree with this principle in this specific case, mainly because<= br> > handling a special message type for notify leads node software des= ign
> to a more complex architecture.
>
> The reason is that this new message type requires special handling= and
> introduces a complexity in the software modularization.
>
> Best,
> Angelo
>
> On Fri, May 14, 2010 at 13:06, Zach Shelby<zach@sensinode.com&g= t; wrote:
>
>
> Hi Angelo,
>
> On May 13, 2010, at 14:24 , Angelo P. Castellani wrote:
>
>
>
> Dear C. Bormann, all,
>
> before deciding for the final direction, I've the following
> observations about draft-shelby-core-coap-01
>
> While I mostly share Zach's view of the protocol approach, and
= > appreciate many aspects of the proposal, there are in my opinion >
>
> still
>
>
> some open issues that need to be at least discussed before the
= >
>
> current
>
>
> document can be selected.
>
>
> Of course there are plenty of open issues. Remember that working g= roup
>
>
> documents still undertake as much change and improvement as the WG=
> wants, so by no means is coap-01 set in stone. I would expect at l= east
> 5-10 more revisions still along the way. Already several of your i= deas
> have been integrated into coap-01, and several more are under
> consideration, so it is coming along. Patience ;-)
>
>
>  
> In particular, I would like to highlight the following:
>
> a) As it is now, it is not possible to have a straightforward
> translation of HTTP -> CoAP and viceversa: see
> http://www.ietf.org/mail-archive/web/core/current/ms= g00133.html (this
> impacts the scalability of the web service model too)
>
>
> In coap-01 the Method names are now identical to HTTP methods. The=
>
>
> Req/Res interaction is a direct translation. The URI hierarchy is<= br> > compatible, and the URI binary code format we are still working on=
> obviously. The only thing that takes some state to translate is > Subscribe/Notify. But note, Subscribe/Notify takes some state no m= atter
> how you do it, even with HTTP-HTTP there is no clean and easy way = to
> handle subscriptions.
>
>
>  
> b) Moreover, CoAP's implementation is not as simple as it should b= e.
> I've investigated the implementation and some design choices (as > Options) are leading to very high program complexity (ROM) on a > MSP430-based device.
>
>
> This we can definitely improve, and already made several optimizat= ions
>
>
> from -00 to -01. Here I need some very concrete proposals though. = Also
> remember that many things are optional, for example subscribe/noti= fy is
> not required if you don't need it.
>
>
>  
> c) Finally when comparing HTTP message size with CoAP message size= ,
> the resulting compression isn't as good as you may expect.
>
> Example:
> HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B
> CoAP: 24 B with options parsing procedure requiring an added
> implementation complexity
>
>
> Right, that is not how it will work in practice. Working with a re= al
>
>
> HTTP server that HTTP header will be more complex, and on the CoAP= side
> you would chose shorter URLs. The biggest improvement possible her= e is
> from using binary coded URLs of course. We need to look at a wider= range
> of interactions and real HTTP headers as well to check that we are=
> efficient enough.
>
>
>  
> Addressing all these points potentially leads to major technical > modifications (especially point a) on the current draft, hence it = is
> appropriate in my opinion to discuss these points before making th= e
> final decision.
>
>
> I am not sure what else you have in mind for a). If we just forget=
>
>
> about Subscribe/Notify then you are good to go. But then you are a= lso
> not fulfilling the charter or the industry needs in that respect.<= br> >
>
> Thanks,
> Zach
>
>
>
> Best regards,
>
> Angelo P. Castellani
>
>
> On Mon, May 10, 2010 at 18:51, Carsten Bormann<cabo@tzi.org>= wrote:
>
>
> The CORE WG has a milestone to select a WG document for CoAP in >
>
> April:
>
>
> = http://datatracker.ietf.org/wg/core/charter/
> ...
> Apr 2010 Select WG document for basis of the CoAP protocol
>
> Of the various documents that have been contributed,
>
>
> draft-shelby-core-coap has significant discussion, as well as the<= br> > largest number of updates (including a previous version that was s= till
> called -6lowapp-coap).
>
>
> Today, another updated version of that draft was announced. See > http://www.ietf.org/mail-archive/web/core/current/ms= g00138.html
> for the announcement and
> http://tools.ietf.org/html/draft-shelby-core-coap-01
> for the draft itself.
>
> However, as the authors say, there are still significant TODOs. >
> Are we in a state yet where we can say whether this is the right >
>
> direction for the WG to take?
>
>
> If yes, is it the right direction? Should we adopt it as a WG
>
>
> document?
>
>
> If you don't think we can say yet, is there a set of technical
= >
>
> decisions you would like the authors to take with priority?
>
>
> Note that once a document has become a WG document, the authors ac= t
>
>
> as editors for the working group, making (and usually fleshing out= the
> details of) any change that the WG decides it needs.
>
>
> If you think we can still improve the draft, this is not an obstac= le
>
>
> to making it a WG document.
>
>
> But of course we shouldn't do that if we intend to reverse its
= >
>
> fundamental technical direction.
>
>
> In order to stay roughly in sync with our milestones, we should >
>
> reach at a decision on how to go forward this week.
>
>
> Gruesse, Carsten
>
> _______________________________________________
> core mailing list
> core@ietf.org
> ht= tps://www.ietf.org/mailman/listinfo/core
>
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> ht= tps://www.ietf.org/mailman/listinfo/core
>
>
> --
> Zach Shelby, Chief Nerd, Sensinode Ltd.
> http://zachshelby.org - My blog "On the Internet of Things"
> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"= ;
> Mobile: +358 40 7796297
>
>
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> ht= tps://www.ietf.org/mailman/listinfo/core
>
> --------------------------------
> Onzo is a limited company number 06097997 registered in England&am= p; Wales. The
> registered office is 6 Great Newport Street, London, WC2H 7JB, Uni= ted Kingdom.
>
> This email message may contain confidential and/or privileged info= rmation, and
> is intended solely for the addressee(s). If you have received this= email in
> error, please notify Onzo immediately. Unauthorised copying, discl= osure or
> distribution of the material in this email is forbidden.
> --------------------------------
>
> _______________________________________________
> core mailing list
> core@ietf.org
> ht= tps://www.ietf.org/mailman/listinfo/core
>
> __________________________________________________________________= ____
> This email has been scanned by the MessageLabs Email Security Syst= em.
> __________________________________________________________________= ____
>
> _______________________________________________
> core mailing list
> core@ietf.org
> ht= tps://www.ietf.org/mailman/listinfo/core
>
>
>  
> _______________________________________________
> core mailing list
> core@ietf.org
> ht= tps://www.ietf.org/mailman/listinfo/core
>
> --------------------------------
> Onzo is a limited company number 06097997 registered in England&am= p; Wales. The
> registered office is 6 Great Newport Street, London, WC2H 7JB, Uni= ted Kingdom.
>
> This email message may contain confidential and/or privileged info= rmation, and
> is intended solely for the addressee(s). If you have received this= email in
> error, please notify Onzo immediately. Unauthorised copying, discl= osure or
> distribution of the material in this email is forbidden.
> --------------------------------
>
>
>  
>
> _______________________________________________
> core mailing list
> core@ietf.org
> ht= tps://www.ietf.org/mailman/listinfo/core
> _______________________________________________
> core mailing list
> core@ietf.org
> ht= tps://www.ietf.org/mailman/listinfo/core
>
>
>
> __________________________________________________________________= ____
> This email has been scanned by the MessageLabs Email Security Syst= em.
> __________________________________________________________________= ___________________________________________________
> core mailing list
> core@ietf.org
> ht= tps://www.ietf.org/mailman/listinfo/core
>
> _______________________________________________
> core mailing list
> core@ietf.org
> ht= tps://www.ietf.org/mailman/listinfo/core

--
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net=  - My book "6LoWPAN: The Wireless Embedded Internet"
= Mobile: +358 40 7796297


______________________________________________________________________<= br> This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________<= br>
= --1__=4EBBFDA2DFDAF18F8f9e8a93df938690918c4EBBFDA2DFDAF18F-- --0__=4EBBFDA2DFDAF18F8f9e8a93df938690918c4EBBFDA2DFDAF18F Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=4EBBFDA2DFDAF18F8@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=4EBBFDA2DFDAF18F8f9e8a93df938690918c4EBBFDA2DFDAF18F Content-type: image/gif; name="pic28315.gif" Content-Disposition: inline; filename="pic28315.gif" Content-ID: <2__=4EBBFDA2DFDAF18F8@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=4EBBFDA2DFDAF18F8f9e8a93df938690918c4EBBFDA2DFDAF18F Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=4EBBFDA2DFDAF18F8@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=4EBBFDA2DFDAF18F8f9e8a93df938690918c4EBBFDA2DFDAF18F-- From angelo.castellani@gmail.com Fri May 28 06:51:39 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B3FC3A6959 for ; Fri, 28 May 2010 06:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.218 X-Spam-Level: * X-Spam-Status: No, score=1.218 tagged_above=-999 required=5 tests=[AWL=0.595, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtYbHl1R9act for ; Fri, 28 May 2010 06:51:38 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id D17023A68AB for ; Fri, 28 May 2010 06:51:37 -0700 (PDT) Received: by gwj19 with SMTP id 19so948659gwj.31 for ; Fri, 28 May 2010 06:51:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=tkjHFovuDW8H2DmeXIv7nXpqucO1MjEA2r3jifLYOxc=; b=XzxmfQArIgaCWa+4h97JGw9XHAzqB+LnrbhgYrlqyAr2QruFvW99LJx3666hSaQVUD tlitcnItR3dL0lvz57UgATfbFW4nNS/GcJCv25r+nI5CWP95/Nm5ZVZSy9wtkf1IUvq1 PQBIIztndlMEbjw+UFV7J8w5JsdXT2Tt23Pl0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=F7RuzlcS1qUujEvdnFFYKoZbkVg9QZnP5tDVh2CGYKLCsl5Ia6lI5unZG0JaY6BsRC rYEKLko1XkKpwHMpXjH6uHhv2oawNB7ZPFy9wBC1z59C/rVA8sVqzv3ypj3djsVx/Q55 y2eyHFtRby4ggfJ6iMXoyqtAWJE7mY4ETwDQY= MIME-Version: 1.0 Received: by 10.91.14.8 with SMTP id r8mr763472agi.60.1275052789591; Fri, 28 May 2010 06:19:49 -0700 (PDT) Sender: angelo.castellani@gmail.com Received: by 10.90.26.2 with HTTP; Fri, 28 May 2010 06:19:49 -0700 (PDT) In-Reply-To: <0924B0BC-BFA7-40E5-8ED9-1AF27533F401@cisco.com> References: <0924B0BC-BFA7-40E5-8ED9-1AF27533F401@cisco.com> Date: Fri, 28 May 2010 15:19:49 +0200 X-Google-Sender-Auth: j8J8ZFAZPrq66KhLrNHv5RVTBHE Message-ID: From: "Angelo P. Castellani" To: Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core Subject: Re: [core] Date option in draft-shelby-core-coap-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 13:51:39 -0000 Cullen, I agree with you about relative times in CoAP. Under the assumption that message delay is smaller of the required accuracy, using a flag we can distinguish between absolute time and relative time. In my opinion POSIX format for absolute time is good (we can also represent events in the past, useful?), relative time can be represented with a signed integer of a similar size. Best, Angelo On Thu, May 27, 2010 at 05:05, Cullen Jennings wrote: > > Peter, > > These are all excellent points and I think I (not Zach) am partial to bla= me for the current text... I just pointed him towards some cut and pasted t= ext from some other RFC - I figured we needed something in the draft as a s= tarting point to get this conversation going. Dealing with time is always c= omplicated and even more so in this constrained environment. If we start by= looking at our constraints, I suspect we come to the conclusions you sugge= sted below. > > My guess is that if we asked everyone, most people would say that we coul= d not require a COAP node to do any of the following. Some nodes might do t= hese but it would not be required > > 1) run NTP > 2) have a table of when leap seconds were going to happened and way to ke= ep that table up to date > 3) have a time source was more accurate than a simple non temperature com= pensated crystal > 4) have any clue about timezones > > I really have no idea how some of these devices are even going to set the= ir time when they first get turned on other than perhaps looking at the tim= e of some other node. > > All this leads me to wonder if we could get away with only having relativ= e times in CoAP. > > On May 13, 2010, at 8:35 AM, Peter Bigot wrote: > >> Section 3.3.6 introduces a Date option that can be used to timestamp a m= easurement. =A0The description specifies that leap seconds are excluded. = =A0It's not crystal clear to me what "excluded" means in this situation. = =A0I don't see any discussion in the list archive. >> >> Pretending leap seconds don't exist (one sense of exclude) makes sense a= s it trivializes the translation between POSIX- time representations (secon= ds since 1970-01-01T00:00:00Z) and UTC-aligned wall clock times that people= normally deal with: this becomes simple division and modulus operations wi= th a little hassle imposed by leap years. =A0On the other hand, the represe= ntation can express times that do not exist (23:59:59 when a negative leap = second takes effect), and can be ambiguous (23:59:60 or a repeated 23:59:59= when a positive leap second takes effect). =A0More importantly, simple sub= traction of two event times does not necessarily result in the duration of = the event. >> >> For an in-development system to which CoAP could apply, my recommendatio= n was to use times expressed as atomic seconds since the POSIX epoch (there= by excluding leap second adjustments from the value). =A0This does mean tha= t translation to civil time requires knowledge of the number of leap second= s in effect at that time (currently UTC is 24 seconds behind TAI relative t= o the POSIX epoch). =A0In return, devices that maintain an internal clock u= sed to timestamp events do not need to be updated to take into account leap= second adjustments, which can take a fair amount of code and support infra= structure to handle a very rare event. =A0It also trivializes calculation o= f event durations, even when the duration spans application of a leap secon= d. >> >> My feeling is that any software component that needs to translate betwee= n between device time and civil time can be expected to account for leap se= conds, while those that are operating in a constrained environment would be= st be isolated from their effects. =A0Note that GPS time is similarly measu= red in atomic seconds since an epoch (1980-01-06T00:00:00Z). >> >> So, do Date values in the proposed COAP match what you get from running = "date +%s" on a Linux system synchronized to UTC, or are they that value pl= us 24? =A0I read the draft as specifying the latter, which is my preference= , but anticipate great confusion from people who haven't had to deal with l= eap seconds before. >> >> Recommend changing "number of seconds, excluding leap seconds, after" to= "number of (atomic) seconds since". > > I suspect that using a EPOCH of 2010 instead of 1970 would reduce the bit= s we need and also, more importantly, encourage people not to confuse these= times with "date +%s" =A0times. > >> >> Peter >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From zach@sensinode.com Fri May 28 07:31:44 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28D723A6A6A for ; Fri, 28 May 2010 07:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6eCUDy3j8fz for ; Fri, 28 May 2010 07:31:40 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id C965D28C16A for ; Fri, 28 May 2010 07:30:02 -0700 (PDT) Received: from [192.168.1.3] (line-5627.dyn.kponet.fi [85.29.68.80]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o4SETEGd022299 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 28 May 2010 17:29:15 +0300 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: Zach Shelby In-Reply-To: Date: Fri, 28 May 2010 17:29:15 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <54C0D124-0AD3-4A30-8D98-4FC0FE134134@sensinode.com> References: <0D212BD466921646B58854FB79092CEC021F4E91@XMB-AMS-106.cisco.com> <0D212BD466921646B58854FB79092CEC021F4EF2@XMB-AMS-106.cisco.com> <6A9FCAC7-E2FA-482D-ABFF-DB6B111A9EA2@sensinode.com> To: "Angelo P. Castellani" X-Mailer: Apple Mail (2.1078) Cc: core Subject: Re: [core] Subscribe/Notify for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 14:31:44 -0000 On May 28, 2010, at 4:13 PM, Angelo P. Castellani wrote: > In my opinion Subscribe/Notify are special methods of interaction > between resources. This is definitely one valid way to look at it. >=20 > 1) SUBSCRIBE: Any resource A can send a Request to SUBSCRIBE with a > resource B (to the resource B URI). Small correction, it is not a resource sending the SUBSCRIBE, it is an = end-point (source address + port) sending it. Correct, it is being sent = for resource B. So end-point A sends a SUBSCRIBE for resource B. >=20 > When B receives the request, B can (should/must?) answer with a MUST I would say (so the A flag must be set). > Response to the SUBSCRIBE Request, telling the result of the request > (subscription accepted/denied/unsupported?). Yep. >=20 > 2) NOTIFY: When subscription condition fires the resource B sends a > NOTIFY Request to resource A URI. The end-point sends a NOTIFY Request about resource B's URI to end-point = A. So there is not a source and destination "resource", instead there is = just resource B.=20 > When A receives the request, A can (should/must?) answer with a > Response to the NOTIFY Request, telling the result of the request (OK, > cancel subscription, change notify options?). The A flag would control the need for a response. > In each Request must be specified the URI of the resource doing the > Request too (Option? From-URI?). Actually, this is the URI (resource B) so you only need one URI. This is = why I say that a notification is like an inverse GET request.=20 Zach >=20 > Angelo >=20 > On Fri, May 28, 2010 at 14:50, Zach Shelby wrote: >> Hi, >>=20 >> This is a really good conversation. One thing we need to do is = remember what our minimum requirements are for subscribe/notify and not = try to solve something more than we should. =46rom what I know it is = sufficient to be able to receive notifications when a URI changes or = periodically. You might consider new URIs under this URI path to be = changes to a URI though... >>=20 >> On May 28, 2010, at 3:08 PM, Adriano Pezzuto (apezzuto) wrote: >>=20 >>> Hello, >>> with this flavor, the SUBSCRIBE may be replaced by a simple POST. So = no needs to have an explicit SUBSCRIBE method. >>=20 >> This is what coap-01 assumes. >>=20 >>> If we want support a more oriented peer-to-peer transaction on CoAP, = it looks to me both SUB and NOTIFY should be treated as messages. >>=20 >> The Request/Response model can be used peer-to-peer, and in CoAP you = can even use a Request asynchronously. Additionally, we want a native = RESTful subscribe/notify technique, that is, we want to subscribe to = resources and be susequently notified about those resources when they = change. >>=20 >> In that sense, you can think of a subscription as a request to = receive asynchronous notifications about a resource (about a URI). This = can be achieved by: >>=20 >> 1. as a SUBSCRIBE Request on the URI with some option indicating the = lifetime as in coap-01, >> 2. as a Subcsribe message (no methods) on the URI with some option, >> 3. or as a POST Request on the URI with options indicating that this = is actually a subscription and the lifetime. This bends the meaning of = POST quite a bit and might be prone to mistakes? >>=20 >> The asynchronous response is a harder one. Can we bend the meaning of = a Request for making asynchronous notifications? Also a notification = includes a URI about a resource on the requestor, which is inverse from = normal Requests in REST. So the options here are: >>=20 >> 1. as a Notify message about a URI (no methods) as in coap-01, >> 2. as a NOTIFY Request about a URI as was in coap-00, >> 3. hmmm... reusing CRUD methods really doesn't work for this one at = all... >>=20 >> I wonder what the HTTP designers would have done if this would have = been a requirement back then? Maybe we should ask them... >>=20 >> Zach >>=20 >>>=20 >>> Adriano >>>=20 >>> From: matthieu.vial@fr.non.schneider-electric.com = [mailto:matthieu.vial@fr.non.schneider-electric.com] >>> Sent: venerd=EC 28 maggio 2010 13.52 >>> To: Adriano Pezzuto (apezzuto) >>> Cc: core; core-bounces@ietf.org; robert.cragie@gridmerge.com >>> Subject: Re: [core] Subscribe/Notify for CoAP >>>=20 >>>> So strictly speaking, both NOTIFY and SUBSCRIBE are message types = not methods! >>>=20 >>> SUBSCRIBE can be just an asynchronous GET on update then I think it = is a method and NOTIFY is an asynchronous response so a message. >>> But if we want to have selective notifications when a resource is = created, updated or deleted then I think you're right NOTIFY and = SUBSCRIBE are messages. >>>=20 >>> Does that make sense ? >>>=20 >>> Matthieu >>>=20 >>> "Adriano Pezzuto (apezzuto)" >>>=20 >>>=20 >>>=20 >>>=20 >>> "Adriano Pezzuto (apezzuto)" >>> Envoy=E9 par : core-bounces@ietf.org >>> 28/05/2010 12:50 >>>=20 >>> >>> A >>> >>> >>> >>> cc >>> >>> core >>> >>> Objet >>> >>> Re: [core] Subscribe/Notify for CoAP >>> >>> >>>=20 >>> Hi Roberto, >>> I understand your point and personally agree on M2M is quite = different from web page model. On the architectural RESTful style, the = method information tells the server what to do with data kept in the URI = information. >>>=20 >>> So strictly speaking, both NOTIFY and SUBSCRIBE are message types = not methods! >>>=20 >>> Adriano >>>=20 >>> From: Robert Cragie [mailto:robert.cragie@gridmerge.com] >>> Sent: venerd=EC 28 maggio 2010 11.53 >>> To: Adriano Pezzuto (apezzuto) >>> Cc: Paul Duffy (paduffy); Zach Shelby; core >>> Subject: Re: [core] Subscribe/Notify for CoAP >>>=20 >>> I think the point here is that there are two levels we are = considering. >>>=20 >>> At the lowest (foundation) level, there are the transaction messages = as described below. This provides a flexible mechanism for the = application with regard to synchronicity and threading. This is = important for the types of devices CoAP is being aimed at. >>>=20 >>> Above that, the methods can be used according to the architectural = style. So in this case, it is RESTful (COnstrained Restful = Environments), which will naturally limit the number of methods and how = transactions occur. >>>=20 >>> The actual architecture using a combination of the methods and = messages also depends on what is required at the application layer. = Consider a typical client which wants to subscribe to a resource. That = client controls the feed of data but needs a component which is capable = of handling (possibly buffering) the data it receives through = notifications. Is this a separate server? Or would we want to consider = it part of an enhanced client model which is able to process feeds of = data? These are the sort of models which have led to the myriad of = solutions (GENA, Webhooks, long polling, pubsubhubbub, RESTMS etc.) = based around HTTP which are all essentially ingenious ways of getting = around the limitations imposed by HTTP and how it is processed for = anything which deviates from the classic web page access model. >>>=20 >>> I think the aim of CoAP should be clean from the word go with regard = to supporting these more peer-to-peer transactions, where the client can = exist on either entity and both entities can feed data to each other; = typical in M2M applications. >>>=20 >>> Robert >>>=20 >>> Robert Cragie (Pacific Gas & Electric) >>>=20 >>> Gridmerge Ltd. >>> 89 Greenfield Crescent, >>> Wakefield, WF4 4WA, UK >>> +44 1924 910888 >>> +1 415 513 0064 >>> http://www.gridmerge.com >>>=20 >>> On 27/05/2010 7:08 PM, Adriano Pezzuto (apezzuto) wrote: >>> Hi Robert, >>>=20 >>> in my personal opinion, the option 1a) brings some sort of ambiguity = to CoAP specs. >>>=20 >>> My be my understatement of new CoAP specs is not so deep, but now we = have 5 methods and 3 message types: request, response and notify. Which = methods are allowed with which messages types? >>> I suppose you have to use PUT/POST method with notify message for = asynch data notification. How to make a subscribe? I suppose you would = use a SUBSCRIBE method with request/response message or SUBSCRIBE with = notify message? Also what about POST/DELETE methods in a notify message? = They not make any sense.. >>>=20 >>> I think the choice is between: option 1) -> only CRUD methods and = option 1b) -> CRUD + SUB/NOTIFY methods, keeping in mind cost/benefits = of both solutions. >>>=20 >>> Adriano >>>=20 >>> From: Robert Cragie [mailto:robert.cragie@gridmerge.com] >>> Sent: mercoled=EC 26 maggio 2010 20.09 >>> To: Adriano Pezzuto (apezzuto) >>> Cc: Paul Duffy (paduffy); Zach Shelby; core >>> Subject: Re: [core] Subscribe/Notify for CoAP >>>=20 >>> Hi Adrian, >>>=20 >>> I would also prefer to keep the protocol in CoAP asynchronous. You = can always map an asynchronous protocol to a synchronous one but, as we = see in HTTP, it always ends up as a kludge to do it the other way round. = The efforts which have been gone to to make HTTP quasi-asynchronous via = all the schemes mentioned below and many more besides (all = non-interoperable of course) is testament to how important this is for = M2M communication. >>>=20 >>> So, back to Zach's list, I favor 1a) for the following reasons: >>>=20 >>> Foundation level of messages: >>>=20 >>> 1. request/response can be asynchronous or synchronous messages (as = there is a transaction ID in there) >>> 2. notify is an asynchronous message >>> Derived methods: >>>=20 >>> I think it makes sense to add a pub/sub model as a useful mechanism = for M2M. >>>=20 >>> So, looking at it the other way round: It will be entirely possible = to translate whatever is currently built on HTTP to CoAP based on the = above, with all its restrictions regarding synchronous and client/server = transactions. What may be harder is to translate directly is a = CoAP-based application to HTTP. So I guess the question is: Do we want = to be hamstrung to synchronous client/server transactions as dictated by = HTTP and provide a direct mapping to HTTP, then have to come up with = similar kludges for asynchronous peer-to-peer transactions as has been = done in numerous ways for HTTP, or do we want to define the protocol = cleanly to start with and accept that some sort of transaction = relaying/conversion would have to take place at a mapping node? >>>=20 >>> Robert >>> Robert Cragie (Pacific Gas & Electric) >>>=20 >>> Gridmerge Ltd. >>> 89 Greenfield Crescent, >>> Wakefield, WF4 4WA, UK >>> +44 1924 910888 >>> +1 415 513 0064 >>> http://www.gridmerge.com >>>=20 >>> On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote: >>> Hi, >>> it looks to me that CoAP should use an explicit sub/notify mechanism = since this is the core of the machine-to-machine interaction model. >>> HTTP suffers of this lack and we have seen a plethora of solutions = to give an asynch taste to it. Webhooks and websockets are only the = lasts of the list. >>> As someone has already pointed out on this list, it is theoretically = possible to describe sub/notify using only CRUD methods but it looks a = little bit tricky and verbose. >>>=20 >>> Now we have a chance to build from scratch a new protocol with and I = think using explicit sub/notify methods with a clear and well defined = semantic is the best option. It is easily understanding from every = developer and will prevent to build other fanny solutions on top of the = CoAP. HTTP does not have this well defined semantic and (for hundreds of = other reasons also) it is not used as wide protocol for = machine-to-machine communication. >>>=20 >>> CoAP - as binary protocol - and with an explicit asynch model has a = chance to be a really wide protocol for M2M communication not only for = constrained environments. >>>=20 >>> my 2 cents >>>=20 >>> - adriano >>>=20 >>> -----Original Message----- >>> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Paul Duffy (paduffy) >>> Sent: mercoled=EC 26 maggio 2010 0.47 >>> To: Zach Shelby >>> Cc: core >>> Subject: Re: [core] Subscribe/Notify for CoAP >>>=20 >>> On 5/25/2010 6:41 PM, Zach Shelby wrote: >>>=20 >>> Hi, >>>=20 >>> On May 26, 2010, at 12:23 AM, Charles Palmer wrote: >>>=20 >>>=20 >>> Hi folks >>>=20 >>> It occurs to me that CoRE should be keeping a close eye on ZigBee = SE2.0 work, so that it is as easy as possible for ZigBee SE to use CoRE = when ready. That suggests to me that we should align with their = subscribe/notify process. >>>=20 >>>=20 >>> I am not sure I understand that. I mean, ZigBee SE2.0 is defining an = application specific subscribe/notify mechanism for that purpose so far = for HTTP. This uses standard HTTP methods and some custom payload and = REST interfaces. CoAP Req/Res is already totally compatible with SE2.0 = in that respect, so alignment is already OK there. Nothing stopping = someone from using SE2.0 over CoAP. >>>=20 >>> Specifying a native susbcription/notify into CoAP is another matter. = We can't adopt a solution specific to one application as that won't = solve the problems of other applications nor general HTTP mapping at all = (probably would make it worse). It seems that for the near future there = will be a bunch of HTTP push mechanisms in use without any clear = standard appearing - or am I wrong there? >>>=20 >>>=20 >>>=20 >>>=20 >>> If COAP extends HTTP semantics with new subscription methods, it = will >>> not be possible to easily interchange HTTP/COAP, and translation >>> gateways will become more complex to implement. >>>=20 >>>=20 >>>=20 >>> Zach >>>=20 >>>=20 >>> Regards - Charles >>>=20 >>>=20 >>> -----Original Message----- >>> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Paul Duffy >>> Sent: 25 May 2010 03:48 >>> To: Zach Shelby >>> Cc: core >>> Subject: Re: [core] Subscribe/Notify for CoAP >>>=20 >>> Recommend something like #2, primarily to avoid introducing non HTTP >>> method semantics, simplifying HTTP/COAP translation.gateways, etc. >>>=20 >>>=20 >>> On 5/24/2010 11:49 AM, Zach Shelby wrote: >>>=20 >>> (thread renamed) >>>=20 >>> We have two different paths with regard to a subscribe/notify = mechanism for CoAP: >>>=20 >>> 1. Use specific Subscription and Notify mechanisms for CoAP as HTTP = really does not include this concept. >>> 1a) Notify as a message and SUBSCRIBE as a method. This is currently = used in coap-01. >>> 1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but = we had a good list discussion about this leading to a. In practice it = doesn't make a big difference if notification is a message or method. >>>=20 >>> 2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2.0 = proposal or GENA. >>>=20 >>> So far we have focused on 1 in the WG, and every now and again 2 = comes up. At least I am not convinced that we need to suffer the = drawbacks of HTTP here. Anyways 2 does not help our mapping to HTTP in = reality very much as there is no standard way of doing this over HTTP. = Thus a CoAP-HTTP proxy may end up anyways translating between multiple = HTTP frameworks depending on the application. So instead of doing a CoAP = Notify/Subscribe to Webhooks mapping, you will could end up having to do = a CoAP Webhooks to HTTP GENA mapping. >>>=20 >>>=20 >>>=20 >>> I don't understand this last para. If CoAP sticks to the semantics = of >>> the current HTTP methods, would this not offer a fairly = straightforward >>> translation to/from HTTP? >>>=20 >>>=20 >>>=20 >>> =46rom what I have heard so far 1 still seems like a wise choice, = although I need to look at Webhooks more deeply. In reality many = applications specify their own way of doing a push interface using REST = methods and specific payloads (ZigBee SE2.0 is such an example). That is = just fine, and might be used instead of a specific CoAP notify/subscribe = in that case. So 1 doesn't prevent the application using its own = mechanism, it just provides a native way for doing push. >>>=20 >>> What do people think? >>>=20 >>> Zach >>>=20 >>> On May 17, 2010, at 6:44 = PM,matthieu.vial@fr.non.schneider-electric.com wrote: >>>=20 >>>=20 >>>=20 >>> Hi, >>>=20 >>> My comments about the subscribe/notify mechanism of Zigbee IP. >>>=20 >>> Pros: >>> - Derived from the webhooks concept >>> - If used by CORE it will be easier to map to HTTP because it uses = only CRUD verbs. >>> - The subscription message is extendable and could support advanced = options (delays, increment, ...) >>> - Only one listening port whatever the transport binding is. >>>=20 >>> Cons: >>> - No interoperability without well known URIs and a well defined = subscription message format (Not sure CoAP draft is the right place to = specify this). >>> - XML/EXI is too complex to be the required format for the default = subscription/notification mechanism. >>> - The notification should not require a subsequent GET to retrieve = the content. >>> - Subresource subscription is redundant. >>>=20 >>> Hope this could help, >>> Matthieu >>>=20 >>>=20 >>> "Charles Palmer" >>>=20 >>>=20 >>>=20 >>>=20 >>> "Charles Palmer" >>> Envoy=E9 par : core-bounces@ietf.org >>> 15/05/2010 14:06 >>>=20 >>> >>> A >>> >>> "core" >>> >>> cc >>> >>> >>> Objet >>> >>> Re: [core] Selecting a WG document for CoAP >>> >>>=20 >>> Dear all >>>=20 >>> Those interested in the subscribe/notify discussion might like to = look >>> at the draft Smart Energy Profile 2.0 Application Protocol >>> Specification. It is available here: >>> = http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicApp >>> licationProfile.aspx >>>=20 >>> It manages subscribe/notify by using POST. This seems to remove the = need >>> for SUBSCRIBE and notify. >>>=20 >>> "Imagine a host A, which exposes a resource at http{s}://A/resource = and >>> a second host B, which wishes to learn of changes to this resource. = To >>> facilitate a subscription/ notification mechanism, A would expose a >>> resource http{s}://A/sub and B would expose a resource = http{s}://B/ntfy. >>> To subscribe to notifications regarding http{s}://A/resource, B = would >>> send a POST to the address http{s}://A/sub/B containing the URI of = the >>> resource of interest (http{s}://A/resource) and the URI of B's >>> notification resource (http{s}://B/ntfy). Following this = subscription >>> step, should A wish to notify B of a change to the resource = addressed at >>> http{s}://A/resource, A would send a POST to the address >>> http{s}://B/ntfy containing the URI of the resource changed >>> (http{s}://A/resource) and the URI of A's subscription resource >>> (http{s}://A/sub/B), should A wish to change its subscription. The = host >>> B can then query the resource (or not) at its leisure." >>>=20 >>> Sleepy nodes are not allowed to subscribe, and must poll. >>>=20 >>> Regards - Charles Palmer >>>=20 >>> -----Original Message----- >>> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of >>> Angelo P. Castellani >>> Sent: 14 May 2010 13:14 >>> To: Zach Shelby >>> Cc: core >>> Subject: Re: [core] Selecting a WG document for CoAP >>>=20 >>> Zach, >>>=20 >>> thanks for the comments, but please refer to my most recent e-mail = for >>> a more specific list of technical issues I'm pointing to. >>>=20 >>> I want to do only a little integration to what I've written there. >>>=20 >>> In my very personal opinion, to maximize adherence with the REST = model >>> and minimize implementation effort SUBSCRIBE and NOTIFY should be >>> mapped to methods (as discussed many times together...). >>>=20 >>> Uniform interface principle (Fielding PhD dissertation Section = 5.1.5, >>> "The central feature that distinguishes the REST architectural style >>> [...]") states that to simplify the software architecture, resource >>> interfaces/interfaces should be as general as possible. >>>=20 >>> I agree with this principle in this specific case, mainly because >>> handling a special message type for notify leads node software = design >>> to a more complex architecture. >>>=20 >>> The reason is that this new message type requires special handling = and >>> introduces a complexity in the software modularization. >>>=20 >>> Best, >>> Angelo >>>=20 >>> On Fri, May 14, 2010 at 13:06, Zach Shelby = wrote: >>>=20 >>>=20 >>> Hi Angelo, >>>=20 >>> On May 13, 2010, at 14:24 , Angelo P. Castellani wrote: >>>=20 >>>=20 >>>=20 >>> Dear C. Bormann, all, >>>=20 >>> before deciding for the final direction, I've the following >>> observations about draft-shelby-core-coap-01 >>>=20 >>> While I mostly share Zach's view of the protocol approach, and >>> appreciate many aspects of the proposal, there are in my opinion >>>=20 >>>=20 >>> still >>>=20 >>>=20 >>> some open issues that need to be at least discussed before the >>>=20 >>>=20 >>> current >>>=20 >>>=20 >>> document can be selected. >>>=20 >>>=20 >>> Of course there are plenty of open issues. Remember that working = group >>>=20 >>>=20 >>> documents still undertake as much change and improvement as the WG >>> wants, so by no means is coap-01 set in stone. I would expect at = least >>> 5-10 more revisions still along the way. Already several of your = ideas >>> have been integrated into coap-01, and several more are under >>> consideration, so it is coming along. Patience ;-) >>>=20 >>>=20 >>>=20 >>> In particular, I would like to highlight the following: >>>=20 >>> a) As it is now, it is not possible to have a straightforward >>> translation of HTTP -> CoAP and viceversa: see >>> http://www.ietf.org/mail-archive/web/core/current/msg00133.html = (this >>> impacts the scalability of the web service model too) >>>=20 >>>=20 >>> In coap-01 the Method names are now identical to HTTP methods. The >>>=20 >>>=20 >>> Req/Res interaction is a direct translation. The URI hierarchy is >>> compatible, and the URI binary code format we are still working on >>> obviously. The only thing that takes some state to translate is >>> Subscribe/Notify. But note, Subscribe/Notify takes some state no = matter >>> how you do it, even with HTTP-HTTP there is no clean and easy way to >>> handle subscriptions. >>>=20 >>>=20 >>>=20 >>> b) Moreover, CoAP's implementation is not as simple as it should be. >>> I've investigated the implementation and some design choices (as >>> Options) are leading to very high program complexity (ROM) on a >>> MSP430-based device. >>>=20 >>>=20 >>> This we can definitely improve, and already made several = optimizations >>>=20 >>>=20 >>> from -00 to -01. Here I need some very concrete proposals though. = Also >>> remember that many things are optional, for example subscribe/notify = is >>> not required if you don't need it. >>>=20 >>>=20 >>>=20 >>> c) Finally when comparing HTTP message size with CoAP message size, >>> the resulting compression isn't as good as you may expect. >>>=20 >>> Example: >>> HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B >>> CoAP: 24 B with options parsing procedure requiring an added >>> implementation complexity >>>=20 >>>=20 >>> Right, that is not how it will work in practice. Working with a real >>>=20 >>>=20 >>> HTTP server that HTTP header will be more complex, and on the CoAP = side >>> you would chose shorter URLs. The biggest improvement possible here = is >>> from using binary coded URLs of course. We need to look at a wider = range >>> of interactions and real HTTP headers as well to check that we are >>> efficient enough. >>>=20 >>>=20 >>>=20 >>> Addressing all these points potentially leads to major technical >>> modifications (especially point a) on the current draft, hence it is >>> appropriate in my opinion to discuss these points before making the >>> final decision. >>>=20 >>>=20 >>> I am not sure what else you have in mind for a). If we just forget >>>=20 >>>=20 >>> about Subscribe/Notify then you are good to go. But then you are = also >>> not fulfilling the charter or the industry needs in that respect. >>>=20 >>>=20 >>> Thanks, >>> Zach >>>=20 >>>=20 >>>=20 >>> Best regards, >>>=20 >>> Angelo P. Castellani >>>=20 >>>=20 >>> On Mon, May 10, 2010 at 18:51, Carsten Bormannwrote: >>>=20 >>>=20 >>> The CORE WG has a milestone to select a WG document for CoAP in >>>=20 >>>=20 >>> April: >>>=20 >>>=20 >>> http://datatracker.ietf.org/wg/core/charter/ >>> ... >>> Apr 2010 Select WG document for basis of the CoAP protocol >>>=20 >>> Of the various documents that have been contributed, >>>=20 >>>=20 >>> draft-shelby-core-coap has significant discussion, as well as the >>> largest number of updates (including a previous version that was = still >>> called -6lowapp-coap). >>>=20 >>>=20 >>> Today, another updated version of that draft was announced. See >>> http://www.ietf.org/mail-archive/web/core/current/msg00138.html >>> for the announcement and >>> http://tools.ietf.org/html/draft-shelby-core-coap-01 >>> for the draft itself. >>>=20 >>> However, as the authors say, there are still significant TODOs. >>>=20 >>> Are we in a state yet where we can say whether this is the right >>>=20 >>>=20 >>> direction for the WG to take? >>>=20 >>>=20 >>> If yes, is it the right direction? Should we adopt it as a WG >>>=20 >>>=20 >>> document? >>>=20 >>>=20 >>> If you don't think we can say yet, is there a set of technical >>>=20 >>>=20 >>> decisions you would like the authors to take with priority? >>>=20 >>>=20 >>> Note that once a document has become a WG document, the authors act >>>=20 >>>=20 >>> as editors for the working group, making (and usually fleshing out = the >>> details of) any change that the WG decides it needs. >>>=20 >>>=20 >>> If you think we can still improve the draft, this is not an obstacle >>>=20 >>>=20 >>> to making it a WG document. >>>=20 >>>=20 >>> But of course we shouldn't do that if we intend to reverse its >>>=20 >>>=20 >>> fundamental technical direction. >>>=20 >>>=20 >>> In order to stay roughly in sync with our milestones, we should >>>=20 >>>=20 >>> reach at a decision on how to go forward this week. >>>=20 >>>=20 >>> Gruesse, Carsten >>>=20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>>=20 >>>=20 >>> -- >>> Zach Shelby, Chief Nerd, Sensinode Ltd. >>> http://zachshelby.org - My blog "On the Internet of Things" >>> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded = Internet" >>> Mobile: +358 40 7796297 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>>=20 >>> -------------------------------- >>> Onzo is a limited company number 06097997 registered in England& = Wales. The >>> registered office is 6 Great Newport Street, London, WC2H 7JB, = United Kingdom. >>>=20 >>> This email message may contain confidential and/or privileged = information, and >>> is intended solely for the addressee(s). If you have received this = email in >>> error, please notify Onzo immediately. Unauthorised copying, = disclosure or >>> distribution of the material in this email is forbidden. >>> -------------------------------- >>>=20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>>=20 >>> = ______________________________________________________________________ >>> This email has been scanned by the MessageLabs Email Security = System. >>> = ______________________________________________________________________ >>>=20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>>=20 >>> -------------------------------- >>> Onzo is a limited company number 06097997 registered in England& = Wales. The >>> registered office is 6 Great Newport Street, London, WC2H 7JB, = United Kingdom. >>>=20 >>> This email message may contain confidential and/or privileged = information, and >>> is intended solely for the addressee(s). If you have received this = email in >>> error, please notify Onzo immediately. Unauthorised copying, = disclosure or >>> distribution of the material in this email is forbidden. >>> -------------------------------- >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>>=20 >>>=20 >>>=20 >>> = ______________________________________________________________________ >>> This email has been scanned by the MessageLabs Email Security = System. >>> = __________________________________________________________________________= ___________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>>=20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>=20 >> -- >> Zach Shelby, Chief Nerd, Sensinode Ltd. >> http://zachshelby.org - My blog "On the Internet of Things" >> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded = Internet" >> Mobile: +358 40 7796297 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >>=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From robert.cragie@gridmerge.com Fri May 28 10:23:07 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 288DE3A67F2 for ; Fri, 28 May 2010 10:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.233 X-Spam-Level: * X-Spam-Status: No, score=1.233 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_50=0.001, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3hipY34pTIK for ; Fri, 28 May 2010 10:23:02 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id A9AF23A685A for ; Fri, 28 May 2010 10:23:01 -0700 (PDT) Received: from client-82-26-176-40.pete.adsl.virginmedia.com ([82.26.176.40] helo=[192.168.1.70]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) id 1OI3Gi-0008Hc-2j for core@ietf.org; Fri, 28 May 2010 18:22:49 +0100 Message-ID: <4BFFFBE4.4090108@gridmerge.com> Date: Fri, 28 May 2010 18:22:44 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: core@ietf.org References: <0D212BD466921646B58854FB79092CEC021F4E91@XMB-AMS-106.cisco.com> <0D212BD466921646B58854FB79092CEC021F4EF2@XMB-AMS-106.cisco.com> <6A9FCAC7-E2FA-482D-ABFF-DB6B111A9EA2@sensinode.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000609040001000604050103" Subject: Re: [core] Subscribe/Notify for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 17:23:07 -0000 This is a cryptographically signed message in MIME format. --------------ms000609040001000604050103 Content-Type: multipart/alternative; boundary="------------010004030807040508000401" This is a multi-part message in MIME format. --------------010004030807040508000401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I think sometimes it makes more sense to think about threads of execution= =2E Forgive me for this lengthy preamble but it will hopefully put things=20 into context. In the most abstract sense, processing is governed by a thread of=20 execution, which sequences a series of data transformations to expedite=20 the required processing. If a data transformation can be completed=20 synchronously in the thread of execution, then the thread is=20 conceptually easier to understand and follow. Most threading models=20 assume this to be the case and if the data transformation cannot=20 complete, it usually blocks pending the required event to complete the=20 transformation. During blocking, the thread is suspended. In simple CPU=20 models without any sort of scheduler, there are two threads of=20 execution: A main thread, pre-emptable by an interrupt thread, usually=20 not pre-emptable. In the main thread, sub-threads are emulated; data=20 transformations can be simply function calls which don't block and=20 therefore return effectively immediately and synchronously. Blocking=20 data transformations are emulated by storing state relevant to each=20 sub-thread then marshaling each event as it is received e.g. through=20 interrupt handling, which causes the second thread to run and thus=20 allows changing sub-thread state so when the main thread runs, the=20 blocking data transformation can complete. Operating system schedulers=20 for these simple CPUs simply abstract this operation through a kernel=20 and associated task/thread scheduling calls. Continuations are a simpler = form used in memory-constrained implementations. Why the lengthy pre-amble? However you look at it, what essentially is=20 required for any threading model (using kernel/scheduler, continuations, = emulated, whatever) are fundamentally three primitives: * Request * Response * Notify A thread of execution will call request and will typically (though not=20 necessarily - see emulated blocking/continuations) wait for a response.=20 If the thread blocks, it is typically woken by another worker thread=20 handling a notify. The worker thread handles notifies asynchronously and = buffers and/or signals the associated task accordingly. This is why I think the current foundation level of messages in coap-01=20 is right. On top of this, the payload of the messages can reflect the actual=20 method. Personally, I don't see the need for a specific SUBSCRIBE=20 message; a POST/create to a subscription resource seems adequate to me.=20 The notify message can carry a PUT or POST depending on whether the=20 resource was simply updated or appended to (again it is no accident the=20 data types in JSON are as they are). Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 28/05/2010 2:13 PM, Angelo P. Castellani wrote: > In my opinion Subscribe/Notify are special methods of interaction > between resources. > > 1) SUBSCRIBE: Any resource A can send a Request to SUBSCRIBE with a > resource B (to the resource B URI). > > When B receives the request, B can (should/must?) answer with a > Response to the SUBSCRIBE Request, telling the result of the request > (subscription accepted/denied/unsupported?). > > 2) NOTIFY: When subscription condition fires the resource B sends a > NOTIFY Request to resource A URI. > > When A receives the request, A can (should/must?) answer with a > Response to the NOTIFY Request, telling the result of the request (OK, > cancel subscription, change notify options?). > > In each Request must be specified the URI of the resource doing the > Request too (Option? From-URI?). > > Angelo > > On Fri, May 28, 2010 at 14:50, Zach Shelby wrote: > =20 >> Hi, >> >> This is a really good conversation. One thing we need to do is remembe= r what our minimum requirements are for subscribe/notify and not try to s= olve something more than we should. From what I know it is sufficient to = be able to receive notifications when a URI changes or periodically. You = might consider new URIs under this URI path to be changes to a URI though= =2E.. >> >> On May 28, 2010, at 3:08 PM, Adriano Pezzuto (apezzuto) wrote: >> >> =20 >>> Hello, >>> with this flavor, the SUBSCRIBE may be replaced by a simple POST. So = no needs to have an explicit SUBSCRIBE method. >>> =20 >> This is what coap-01 assumes. >> >> =20 >>> If we want support a more oriented peer-to-peer transaction on CoAP, = it looks to me both SUB and NOTIFY should be treated as messages. >>> =20 >> The Request/Response model can be used peer-to-peer, and in CoAP you c= an even use a Request asynchronously. Additionally, we want a native REST= ful subscribe/notify technique, that is, we want to subscribe to resource= s and be susequently notified about those resources when they change. >> >> In that sense, you can think of a subscription as a request to receive= asynchronous notifications about a resource (about a URI). This can be a= chieved by: >> >> 1. as a SUBSCRIBE Request on the URI with some option indicating the = lifetime as in coap-01, >> 2. as a Subcsribe message (no methods) on the URI with some option, >> 3. or as a POST Request on the URI with options indicating that this = is actually a subscription and the lifetime. This bends the meaning of P= OST quite a bit and might be prone to mistakes? >> >> The asynchronous response is a harder one. Can we bend the meaning of = a Request for making asynchronous notifications? Also a notification incl= udes a URI about a resource on the requestor, which is inverse from norma= l Requests in REST. So the options here are: >> >> 1. as a Notify message about a URI (no methods) as in coap-01, >> 2. as a NOTIFY Request about a URI as was in coap-00, >> 3. hmmm... reusing CRUD methods really doesn't work for this one at al= l... >> >> I wonder what the HTTP designers would have done if this would have be= en a requirement back then? Maybe we should ask them... >> >> Zach >> >> =20 >>> Adriano >>> >>> From: matthieu.vial@fr.non.schneider-electric.com [mailto:matthieu.vi= al@fr.non.schneider-electric.com] >>> Sent: venerd=EC 28 maggio 2010 13.52 >>> To: Adriano Pezzuto (apezzuto) >>> Cc: core; core-bounces@ietf.org; robert.cragie@gridmerge.com >>> Subject: Re: [core] Subscribe/Notify for CoAP >>> >>> =20 >>>> So strictly speaking, both NOTIFY and SUBSCRIBE are message types no= t methods! >>>> =20 >>> SUBSCRIBE can be just an asynchronous GET on update then I think it i= s a method and NOTIFY is an asynchronous response so a message. >>> But if we want to have selective notifications when a resource is cre= ated, updated or deleted then I think you're right NOTIFY and SUBSCRIBE a= re messages. >>> >>> Does that make sense ? >>> >>> Matthieu >>> >>> "Adriano Pezzuto (apezzuto)" >>> >>> >>> >>> >>> "Adriano Pezzuto (apezzuto)" >>> Envoy=E9 par : core-bounces@ietf.org >>> 28/05/2010 12:50 >>> >>> >>> A >>> >>> >>> >>> cc >>> >>> core >>> >>> Objet >>> >>> Re: [core] Subscribe/Notify for CoAP >>> >>> >>> >>> Hi Roberto, >>> I understand your point and personally agree on M2M is quite differen= t from web page model. On the architectural RESTful style, the method inf= ormation tells the server what to do with data kept in the URI informatio= n. >>> >>> So strictly speaking, both NOTIFY and SUBSCRIBE are message types not= methods! >>> >>> Adriano >>> >>> From: Robert Cragie [mailto:robert.cragie@gridmerge.com] >>> Sent: venerd=EC 28 maggio 2010 11.53 >>> To: Adriano Pezzuto (apezzuto) >>> Cc: Paul Duffy (paduffy); Zach Shelby; core >>> Subject: Re: [core] Subscribe/Notify for CoAP >>> >>> I think the point here is that there are two levels we are considerin= g. >>> >>> At the lowest (foundation) level, there are the transaction messages = as described below. This provides a flexible mechanism for the applicatio= n with regard to synchronicity and threading. This is important for the t= ypes of devices CoAP is being aimed at. >>> >>> Above that, the methods can be used according to the architectural st= yle. So in this case, it is RESTful (COnstrained Restful Environments), w= hich will naturally limit the number of methods and how transactions occu= r. >>> >>> The actual architecture using a combination of the methods and messag= es also depends on what is required at the application layer. Consider a = typical client which wants to subscribe to a resource. That client contro= ls the feed of data but needs a component which is capable of handling (p= ossibly buffering) the data it receives through notifications. Is this a = separate server? Or would we want to consider it part of an enhanced clie= nt model which is able to process feeds of data? These are the sort of mo= dels which have led to the myriad of solutions (GENA, Webhooks, long poll= ing, pubsubhubbub, RESTMS etc.) based around HTTP which are all essential= ly ingenious ways of getting around the limitations imposed by HTTP and h= ow it is processed for anything which deviates from the classic web page = access model. >>> >>> I think the aim of CoAP should be clean from the word go with regard = to supporting these more peer-to-peer transactions, where the client can = exist on either entity and both entities can feed data to each other; typ= ical in M2M applications. >>> >>> Robert >>> >>> Robert Cragie (Pacific Gas& Electric) >>> >>> Gridmerge Ltd. >>> 89 Greenfield Crescent, >>> Wakefield, WF4 4WA, UK >>> +44 1924 910888 >>> +1 415 513 0064 >>> http://www.gridmerge.com >>> >>> On 27/05/2010 7:08 PM, Adriano Pezzuto (apezzuto) wrote: >>> Hi Robert, >>> >>> in my personal opinion, the option 1a) brings some sort of ambiguity = to CoAP specs. >>> >>> My be my understatement of new CoAP specs is not so deep, but now we = have 5 methods and 3 message types: request, response and notify. Which m= ethods are allowed with which messages types? >>> I suppose you have to use PUT/POST method with notify message for asy= nch data notification. How to make a subscribe? I suppose you would use a= SUBSCRIBE method with request/response message or SUBSCRIBE with notify = message? Also what about POST/DELETE methods in a notify message? They no= t make any sense.. >>> >>> I think the choice is between: option 1) -> only CRUD methods and op= tion 1b) -> CRUD + SUB/NOTIFY methods, keeping in mind cost/benefits of = both solutions. >>> >>> Adriano >>> >>> From: Robert Cragie [mailto:robert.cragie@gridmerge.com] >>> Sent: mercoled=EC 26 maggio 2010 20.09 >>> To: Adriano Pezzuto (apezzuto) >>> Cc: Paul Duffy (paduffy); Zach Shelby; core >>> Subject: Re: [core] Subscribe/Notify for CoAP >>> >>> Hi Adrian, >>> >>> I would also prefer to keep the protocol in CoAP asynchronous. You ca= n always map an asynchronous protocol to a synchronous one but, as we see= in HTTP, it always ends up as a kludge to do it the other way round. The= efforts which have been gone to to make HTTP quasi-asynchronous via all = the schemes mentioned below and many more besides (all non-interoperable = of course) is testament to how important this is for M2M communication. >>> >>> So, back to Zach's list, I favor 1a) for the following reasons: >>> >>> Foundation level of messages: >>> >>> 1. request/response can be asynchronous or synchronous messages (as t= here is a transaction ID in there) >>> 2. notify is an asynchronous message >>> Derived methods: >>> >>> I think it makes sense to add a pub/sub model as a useful mechanism f= or M2M. >>> >>> So, looking at it the other way round: It will be entirely possible t= o translate whatever is currently built on HTTP to CoAP based on the abov= e, with all its restrictions regarding synchronous and client/server tran= sactions. What may be harder is to translate directly is a CoAP-based app= lication to HTTP. So I guess the question is: Do we want to be hamstrung = to synchronous client/server transactions as dictated by HTTP and provide= a direct mapping to HTTP, then have to come up with similar kludges for = asynchronous peer-to-peer transactions as has been done in numerous ways = for HTTP, or do we want to define the protocol cleanly to start with and = accept that some sort of transaction relaying/conversion would have to ta= ke place at a mapping node? >>> >>> Robert >>> Robert Cragie (Pacific Gas& Electric) >>> >>> Gridmerge Ltd. >>> 89 Greenfield Crescent, >>> Wakefield, WF4 4WA, UK >>> +44 1924 910888 >>> +1 415 513 0064 >>> http://www.gridmerge.com >>> >>> On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote: >>> Hi, >>> it looks to me that CoAP should use an explicit sub/notify mechanism = since this is the core of the machine-to-machine interaction model. >>> HTTP suffers of this lack and we have seen a plethora of solutions to= give an asynch taste to it. Webhooks and websockets are only the lasts o= f the list. >>> As someone has already pointed out on this list, it is theoretically = possible to describe sub/notify using only CRUD methods but it looks a li= ttle bit tricky and verbose. >>> >>> Now we have a chance to build from scratch a new protocol with and I = think using explicit sub/notify methods with a clear and well defined sem= antic is the best option. It is easily understanding from every developer= and will prevent to build other fanny solutions on top of the CoAP. HTTP= does not have this well defined semantic and (for hundreds of other reas= ons also) it is not used as wide protocol for machine-to-machine communic= ation. >>> >>> CoAP - as binary protocol - and with an explicit asynch model has a c= hance to be a really wide protocol for M2M communication not only for con= strained environments. >>> >>> my 2 cents >>> >>> - adriano >>> >>> -----Original Message----- >>> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Paul Duffy (paduffy) >>> Sent: mercoled=EC 26 maggio 2010 0.47 >>> To: Zach Shelby >>> Cc: core >>> Subject: Re: [core] Subscribe/Notify for CoAP >>> >>> On 5/25/2010 6:41 PM, Zach Shelby wrote: >>> >>> Hi, >>> >>> On May 26, 2010, at 12:23 AM, Charles Palmer wrote: >>> >>> >>> Hi folks >>> >>> It occurs to me that CoRE should be keeping a close eye on ZigBee SE2= =2E0 work, so that it is as easy as possible for ZigBee SE to use CoRE wh= en ready. That suggests to me that we should align with their subscribe/n= otify process. >>> >>> >>> I am not sure I understand that. I mean, ZigBee SE2.0 is defining an = application specific subscribe/notify mechanism for that purpose so far f= or HTTP. This uses standard HTTP methods and some custom payload and REST= interfaces. CoAP Req/Res is already totally compatible with SE2.0 in tha= t respect, so alignment is already OK there. Nothing stopping someone fro= m using SE2.0 over CoAP. >>> >>> Specifying a native susbcription/notify into CoAP is another matter. = We can't adopt a solution specific to one application as that won't solve= the problems of other applications nor general HTTP mapping at all (prob= ably would make it worse). It seems that for the near future there will b= e a bunch of HTTP push mechanisms in use without any clear standard appea= ring - or am I wrong there? >>> >>> >>> >>> >>> If COAP extends HTTP semantics with new subscription methods, it will= >>> not be possible to easily interchange HTTP/COAP, and translation >>> gateways will become more complex to implement. >>> >>> >>> >>> Zach >>> >>> >>> Regards - Charles >>> >>> >>> -----Original Message----- >>> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Paul Duffy >>> Sent: 25 May 2010 03:48 >>> To: Zach Shelby >>> Cc: core >>> Subject: Re: [core] Subscribe/Notify for CoAP >>> >>> Recommend something like #2, primarily to avoid introducing non HTTP >>> method semantics, simplifying HTTP/COAP translation.gateways, etc. >>> >>> >>> On 5/24/2010 11:49 AM, Zach Shelby wrote: >>> >>> (thread renamed) >>> >>> We have two different paths with regard to a subscribe/notify mechani= sm for CoAP: >>> >>> 1. Use specific Subscription and Notify mechanisms for CoAP as HTTP r= eally does not include this concept. >>> 1a) Notify as a message and SUBSCRIBE as a method. This is currently = used in coap-01. >>> 1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but we= had a good list discussion about this leading to a. In practice it doesn= 't make a big difference if notification is a message or method. >>> >>> 2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2.0 = proposal or GENA. >>> >>> So far we have focused on 1 in the WG, and every now and again 2 come= s up. At least I am not convinced that we need to suffer the drawbacks of= HTTP here. Anyways 2 does not help our mapping to HTTP in reality very m= uch as there is no standard way of doing this over HTTP. Thus a CoAP-HTTP= proxy may end up anyways translating between multiple HTTP frameworks de= pending on the application. So instead of doing a CoAP Notify/Subscribe t= o Webhooks mapping, you will could end up having to do a CoAP Webhooks to= HTTP GENA mapping. >>> >>> >>> >>> I don't understand this last para. If CoAP sticks to the semantics of= >>> the current HTTP methods, would this not offer a fairly straightforwa= rd >>> translation to/from HTTP? >>> >>> >>> >>> From what I have heard so far 1 still seems like a wise choice, alth= ough I need to look at Webhooks more deeply. In reality many applications= specify their own way of doing a push interface using REST methods and s= pecific payloads (ZigBee SE2.0 is such an example). That is just fine, an= d might be used instead of a specific CoAP notify/subscribe in that case.= So 1 doesn't prevent the application using its own mechanism, it just pr= ovides a native way for doing push. >>> >>> What do people think? >>> >>> Zach >>> >>> On May 17, 2010, at 6:44 PM,matthieu.vial@fr.non.schneider-electric.c= om wrote: >>> >>> >>> >>> Hi, >>> >>> My comments about the subscribe/notify mechanism of Zigbee IP. >>> >>> Pros: >>> - Derived from the webhooks concept >>> - If used by CORE it will be easier to map to HTTP because it uses on= ly CRUD verbs. >>> - The subscription message is extendable and could support advanced o= ptions (delays, increment, ...) >>> - Only one listening port whatever the transport binding is. >>> >>> Cons: >>> - No interoperability without well known URIs and a well defined subs= cription message format (Not sure CoAP draft is the right place to specif= y this). >>> - XML/EXI is too complex to be the required format for the default su= bscription/notification mechanism. >>> - The notification should not require a subsequent GET to retrieve th= e content. >>> - Subresource subscription is redundant. >>> >>> Hope this could help, >>> Matthieu >>> >>> >>> "Charles Palmer" >>> >>> >>> >>> >>> "Charles Palmer" >>> Envoy=E9 par : core-bounces@ietf.org >>> 15/05/2010 14:06 >>> >>> >>> A >>> >>> "core" >>> >>> cc >>> >>> >>> Objet >>> >>> Re: [core] Selecting a WG document for CoAP >>> >>> >>> Dear all >>> >>> Those interested in the subscribe/notify discussion might like to loo= k >>> at the draft Smart Energy Profile 2.0 Application Protocol >>> Specification. It is available here: >>> http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20Public= App >>> licationProfile.aspx >>> >>> It manages subscribe/notify by using POST. This seems to remove the n= eed >>> for SUBSCRIBE and notify. >>> >>> "Imagine a host A, which exposes a resource at http{s}://A/resource a= nd >>> a second host B, which wishes to learn of changes to this resource. T= o >>> facilitate a subscription/ notification mechanism, A would expose a >>> resource http{s}://A/sub and B would expose a resource http{s}://B/nt= fy. >>> To subscribe to notifications regarding http{s}://A/resource, B would= >>> send a POST to the address http{s}://A/sub/B containing the URI of th= e >>> resource of interest (http{s}://A/resource) and the URI of B's >>> notification resource (http{s}://B/ntfy). Following this subscription= >>> step, should A wish to notify B of a change to the resource addressed= at >>> http{s}://A/resource, A would send a POST to the address >>> http{s}://B/ntfy containing the URI of the resource changed >>> (http{s}://A/resource) and the URI of A's subscription resource >>> (http{s}://A/sub/B), should A wish to change its subscription. The ho= st >>> B can then query the resource (or not) at its leisure." >>> >>> Sleepy nodes are not allowed to subscribe, and must poll. >>> >>> Regards - Charles Palmer >>> >>> -----Original Message----- >>> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of >>> Angelo P. Castellani >>> Sent: 14 May 2010 13:14 >>> To: Zach Shelby >>> Cc: core >>> Subject: Re: [core] Selecting a WG document for CoAP >>> >>> Zach, >>> >>> thanks for the comments, but please refer to my most recent e-mail fo= r >>> a more specific list of technical issues I'm pointing to. >>> >>> I want to do only a little integration to what I've written there. >>> >>> In my very personal opinion, to maximize adherence with the REST mode= l >>> and minimize implementation effort SUBSCRIBE and NOTIFY should be >>> mapped to methods (as discussed many times together...). >>> >>> Uniform interface principle (Fielding PhD dissertation Section 5.1.5,= >>> "The central feature that distinguishes the REST architectural style >>> [...]") states that to simplify the software architecture, resource >>> interfaces/interfaces should be as general as possible. >>> >>> I agree with this principle in this specific case, mainly because >>> handling a special message type for notify leads node software design= >>> to a more complex architecture. >>> >>> The reason is that this new message type requires special handling an= d >>> introduces a complexity in the software modularization. >>> >>> Best, >>> Angelo >>> >>> On Fri, May 14, 2010 at 13:06, Zach Shelby wrote= : >>> >>> >>> Hi Angelo, >>> >>> On May 13, 2010, at 14:24 , Angelo P. Castellani wrote: >>> >>> >>> >>> Dear C. Bormann, all, >>> >>> before deciding for the final direction, I've the following >>> observations about draft-shelby-core-coap-01 >>> >>> While I mostly share Zach's view of the protocol approach, and >>> appreciate many aspects of the proposal, there are in my opinion >>> >>> >>> still >>> >>> >>> some open issues that need to be at least discussed before the >>> >>> >>> current >>> >>> >>> document can be selected. >>> >>> >>> Of course there are plenty of open issues. Remember that working grou= p >>> >>> >>> documents still undertake as much change and improvement as the WG >>> wants, so by no means is coap-01 set in stone. I would expect at leas= t >>> 5-10 more revisions still along the way. Already several of your idea= s >>> have been integrated into coap-01, and several more are under >>> consideration, so it is coming along. Patience ;-) >>> >>> >>> >>> In particular, I would like to highlight the following: >>> >>> a) As it is now, it is not possible to have a straightforward >>> translation of HTTP -> CoAP and viceversa: see >>> http://www.ietf.org/mail-archive/web/core/current/msg00133.html (this= >>> impacts the scalability of the web service model too) >>> >>> >>> In coap-01 the Method names are now identical to HTTP methods. The >>> >>> >>> Req/Res interaction is a direct translation. The URI hierarchy is >>> compatible, and the URI binary code format we are still working on >>> obviously. The only thing that takes some state to translate is >>> Subscribe/Notify. But note, Subscribe/Notify takes some state no matt= er >>> how you do it, even with HTTP-HTTP there is no clean and easy way to >>> handle subscriptions. >>> >>> >>> >>> b) Moreover, CoAP's implementation is not as simple as it should be. >>> I've investigated the implementation and some design choices (as >>> Options) are leading to very high program complexity (ROM) on a >>> MSP430-based device. >>> >>> >>> This we can definitely improve, and already made several optimization= s >>> >>> >>> from -00 to -01. Here I need some very concrete proposals though. Als= o >>> remember that many things are optional, for example subscribe/notify = is >>> not required if you don't need it. >>> >>> >>> >>> c) Finally when comparing HTTP message size with CoAP message size, >>> the resulting compression isn't as good as you may expect. >>> >>> Example: >>> HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B >>> CoAP: 24 B with options parsing procedure requiring an added >>> implementation complexity >>> >>> >>> Right, that is not how it will work in practice. Working with a real >>> >>> >>> HTTP server that HTTP header will be more complex, and on the CoAP si= de >>> you would chose shorter URLs. The biggest improvement possible here i= s >>> from using binary coded URLs of course. We need to look at a wider ra= nge >>> of interactions and real HTTP headers as well to check that we are >>> efficient enough. >>> >>> >>> >>> Addressing all these points potentially leads to major technical >>> modifications (especially point a) on the current draft, hence it is >>> appropriate in my opinion to discuss these points before making the >>> final decision. >>> >>> >>> I am not sure what else you have in mind for a). If we just forget >>> >>> >>> about Subscribe/Notify then you are good to go. But then you are also= >>> not fulfilling the charter or the industry needs in that respect. >>> >>> >>> Thanks, >>> Zach >>> >>> >>> >>> Best regards, >>> >>> Angelo P. Castellani >>> >>> >>> On Mon, May 10, 2010 at 18:51, Carsten Bormannwrote: >>> >>> >>> The CORE WG has a milestone to select a WG document for CoAP in >>> >>> >>> April: >>> >>> >>> http://datatracker.ietf.org/wg/core/charter/ >>> ... >>> Apr 2010 Select WG document for basis of the CoAP protocol >>> >>> Of the various documents that have been contributed, >>> >>> >>> draft-shelby-core-coap has significant discussion, as well as the >>> largest number of updates (including a previous version that was stil= l >>> called -6lowapp-coap). >>> >>> >>> Today, another updated version of that draft was announced. See >>> http://www.ietf.org/mail-archive/web/core/current/msg00138.html >>> for the announcement and >>> http://tools.ietf.org/html/draft-shelby-core-coap-01 >>> for the draft itself. >>> >>> However, as the authors say, there are still significant TODOs. >>> >>> Are we in a state yet where we can say whether this is the right >>> >>> >>> direction for the WG to take? >>> >>> >>> If yes, is it the right direction? Should we adopt it as a WG >>> >>> >>> document? >>> >>> >>> If you don't think we can say yet, is there a set of technical >>> >>> >>> decisions you would like the authors to take with priority? >>> >>> >>> Note that once a document has become a WG document, the authors act >>> >>> >>> as editors for the working group, making (and usually fleshing out th= e >>> details of) any change that the WG decides it needs. >>> >>> >>> If you think we can still improve the draft, this is not an obstacle >>> >>> >>> to making it a WG document. >>> >>> >>> But of course we shouldn't do that if we intend to reverse its >>> >>> >>> fundamental technical direction. >>> >>> >>> In order to stay roughly in sync with our milestones, we should >>> >>> >>> reach at a decision on how to go forward this week. >>> >>> >>> Gruesse, Carsten >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >>> >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >>> >>> -- >>> Zach Shelby, Chief Nerd, Sensinode Ltd. >>> http://zachshelby.org - My blog "On the Internet of Things" >>> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet= " >>> Mobile: +358 40 7796297 >>> >>> >>> >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >>> -------------------------------- >>> Onzo is a limited company number 06097997 registered in England& Wal= es. The >>> registered office is 6 Great Newport Street, London, WC2H 7JB, United= Kingdom. >>> >>> This email message may contain confidential and/or privileged informa= tion, and >>> is intended solely for the addressee(s). If you have received this em= ail in >>> error, please notify Onzo immediately. Unauthorised copying, disclosu= re or >>> distribution of the material in this email is forbidden. >>> -------------------------------- >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >>> _____________________________________________________________________= _ >>> This email has been scanned by the MessageLabs Email Security System.= >>> _____________________________________________________________________= _ >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >>> >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >>> -------------------------------- >>> Onzo is a limited company number 06097997 registered in England& Wal= es. The >>> registered office is 6 Great Newport Street, London, WC2H 7JB, United= Kingdom. >>> >>> This email message may contain confidential and/or privileged informa= tion, and >>> is intended solely for the addressee(s). If you have received this em= ail in >>> error, please notify Onzo immediately. Unauthorised copying, disclosu= re or >>> distribution of the material in this email is forbidden. >>> -------------------------------- >>> >>> >>> >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >>> >>> >>> _____________________________________________________________________= _ >>> This email has been scanned by the MessageLabs Email Security System.= >>> _____________________________________________________________________= ________________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>> =20 >> -- >> Zach Shelby, Chief Nerd, Sensinode Ltd. >> http://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 >> >> =20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > =20 --------------010004030807040508000401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think sometimes it makes more sense to think about threads of execution.

Forgive me for this lengthy preamble but it will hopefully put things into context.

In the most abstract sense, processing is governed by a thread of execution, which sequences a series of data transformations to expedite the required processing. If a data transformation can be completed synchronously in the thread of execution, then the thread is conceptually easier to understand and follow. Most threading models assume this to be the case and if the data transformation cannot complete, it usually blocks pending the required event to complete the transformation. During blocking, the thread is suspended. In simple CPU models without any sort of scheduler, there are two threads of execution: A main thread, pre-emptable by an interrupt thread, usually not pre-emptable. In the main thread, sub-threads are emulated; data transformations can be simply function calls which don't block and therefore return effectively immediately and synchronously. Blocking data transformations are emulated by storing state relevant to each sub-thread then marshaling each event as it is received e.g. through interrupt handling, which causes the second thread to run and thus allows changing sub-thread state so when the main thread runs, the blocking data transformation can complete. Operating system schedulers for these simple CPUs simply abstract this operation through a kernel and associated task/thread scheduling calls. Continuations are a simpler form used in memory-constrained implementations.

Why the lengthy pre-amble? However you look at it, what essentially is required for any threading model (using kernel/scheduler, continuations, emulated, whatever) are fundamentally three primitives:


--0016e6d645a839ca0c0487ae17ec-- From matthieu.vial@fr.non.schneider-electric.com Mon May 31 01:58:24 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6517A3A69C7; Mon, 31 May 2010 01:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.15 X-Spam-Level: *** X-Spam-Status: No, score=3.15 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEPKnCMSaBYF; Mon, 31 May 2010 01:58:20 -0700 (PDT) Received: from mailX03.eud.schneider-electric.com (mailx03.eud.schneider-electric.com [205.167.7.41]) by core3.amsl.com (Postfix) with ESMTP id 9B36A3A69A6; Mon, 31 May 2010 01:58:17 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX03.eud.schneider-electric.com with ESMTP id 2010053110480182-93480 ; Mon, 31 May 2010 10:48:01 +0200 In-Reply-To: <4BFFB246.4010600@gridmerge.com> To: robert.cragie@gridmerge.com X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: matthieu.vial@fr.non.schneider-electric.com Date: Mon, 31 May 2010 10:57:59 +0200 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 31/05/2010 10:58:05, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 31/05/2010 10:48:01, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 31/05/2010 10:48:02 Content-type: multipart/related; Boundary="0__=4EBBFDA7DFBEBDC58f9e8a93df938690918c4EBBFDA7DFBEBDC5" Cc: core-bounces@ietf.org, core Subject: Re: [core] Subscribe/Notify for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 08:58:24 -0000 --0__=4EBBFDA7DFBEBDC58f9e8a93df938690918c4EBBFDA7DFBEBDC5 Content-type: multipart/alternative; Boundary="1__=4EBBFDA7DFBEBDC58f9e8a93df938690918c4EBBFDA7DFBEBDC5" --1__=4EBBFDA7DFBEBDC58f9e8a93df938690918c4EBBFDA7DFBEBDC5 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Robert, Here is a complete scenario: The resource /event is a collection of events that occured in device A. Device B wants to be notified each time a new event has occured in A. One solution could be to subscribe when the method POST (thus a creation) is acted upon /event. A would send a notify message with the URI of the new event (/event/1, /event/2 ...). The second solution using the actual COAP specification is to define /event/last as an alias to the last created event. Device B would receive a notification each time /event/last has changed. The definition of "changed" becomes tricky if 2 successive events are identical. The content of /event/last is identical but it points to a different resource. Of course the etag could reflect that change. So what is the RESTfulest solution ? Matthieu = Robert Cragie = A = Matthieu = 28/05/2010 14:08 Vial/FR/Non/Schneider@Europe = cc = "Adriano Pezzuto (apezzuto)" = Veuillez r=E9pondre , core = =20 =E0 , = =20 robert.cragie@gri core-bounces@ietf.org = dmerge.com Objet = Re: [core] Subscribe/Notify for = CoAP = = = = = = = Hi Matthieu, I am not sure what you mean here. Do you mean that some other client can subscribe to be notified whenever some method is acted upon for a particular resource? Can you describe the transaction model? Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 28/05/2010 12:51 PM, matthieu.vial@fr.non.schneider-electric.com wrote: > So strictly speaking, both NOTIFY and SUBSCRIBE are message types not methods! SUBSCRIBE can be just an asynchronous GET on update then I think it is a method and NOTIFY is an asynchronous response so a message. But if we want to have selective notifications when a resource is created, updated or deleted then I think you're right NOTIFY and SUBSCRIBE are messages. Does that make sense ? Matthieu Inactive hide details for "Adriano Pezzuto (apezzuto)" "Adriano Pezzuto (apezzuto)" = "Adriano Pezzuto = (apezzuto)" = = Envoy=E9 par : = A=20 core-bounces@iet = f.org = = 28/05/2010 12:50 cc = = core = = = Objet = = Re: [core] = Subscribe/Notify = for CoAP = = = = = = = Hi Roberto, I understand your point and personally agree on M2M is quite different from web page model. On the architectural RESTful style, the method information tells the server what to do with data kept in the URI information. So strictly speaking, both NOTIFY and SUBSCRIBE are message types not methods! Adriano From: Robert Cragie [mailto:robert.cragie@gridmerge.com] Sent: venerd=EC 28 maggio 2010 11.53 To: Adriano Pezzuto (apezzuto) Cc: Paul Duffy (paduffy); Zach Shelby; core Subject: Re: [core] Subscribe/Notify for CoAP I think the point here is that there are two levels we are considering. At the lowest (foundation) level, there are the transaction messages as described below. This provides a flexible mechanism for the application with regard to synchronicity and threading. This is important for the types of devices CoAP is being aimed at. Above that, the methods can be used according to the architectural style. So in this case, it is RESTful (COnstrained Restful Environments), which will naturally limit the number of methods and how transactions occur. The actual architecture using a combination of the methods and messages also depends on what is required at the application layer. Consider a typical client which wants to subscribe to a resource. That client controls the feed of data but needs a component which is capable of handling (possibly buffering) the data it receives through notifications. Is this a separate server? Or would we want to consider it part of an enhanced client model which is able to process feeds of data? These are the sort of models which have led to the myriad of solutions (GENA, Webhooks, long polling, pubsubhubbub, RESTMS etc.) based around HTTP which are all essentially ingenious ways of getting around the limitations imposed by HTTP and how it is processed for anything which deviates from the classic web page access model. I think the aim of CoAP should be clean from the word go with regard to supporting these more peer-to-peer transactions, where the client can exist on either entity and both entities can feed data to each other; typical in M2M applications. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 27/05/2010 7:08 PM, Adriano Pezzuto (apezzuto) wrote: Hi Robert, in my personal opinion, the option 1a) brings some sort of ambiguity to CoAP specs. My be my understatement of new CoAP specs is not so deep, but now we have 5 methods and 3 message types: request, response and notify. Which methods are allowed with which messages types? I suppose you have to use PUT/POST method with notify message for asynch data notification. How to make a subscribe? I suppose you would use a SUBSCRIBE method with request/response message or SUBSCRIBE with notify message? Also what about POST/DELETE methods in a notify message? They not make any sense.. I think the choice is between: option 1) -> only CRUD methods and option 1b) -> CRUD + SUB/NOTIFY methods, keeping in mind cost/benefits of both solutions. Adriano From: Robert Cragie [mailto:robert.cragie@gridmerge.com] Sent: mercoled=EC 26 maggio 2010 20.09 To: Adriano Pezzuto (apezzuto) Cc: Paul Duffy (paduffy); Zach Shelby; core Subject: Re: [core] Subscribe/Notify for CoAP Hi Adrian, I would also prefer to keep the protocol in CoAP asynchronous. You can always map an asynchronous protocol to a synchronous one but, as we see in HTTP, it always ends up as a kludge to do it the other way round. The efforts which have been gone to to make HTTP quasi-asynchronous via all the schemes mentioned below and many more besides (all non-interoperable of course) is testament to how important this is for M2M communication. So, back to Zach's list, I favor 1a) for the following reasons: Foundation level of messages: 1. request/response can be asynchronous or synchronous messages (as there is a transaction ID in there) 2. notify is an asynchronous message Derived methods: I think it makes sense to add a pub/sub model as a useful mechanism for M2M. So, looking at it the other way round: It will be entirely possible to translate whatever is currently built on HTTP to CoAP based on the above, with all its restrictions regarding synchronous and client/server transactions. What may be harder is to translate directly is a CoAP-based application to HTTP. So I guess the question is: Do we want to be hamstrung to synchronous client/server transactions as dictated by HTTP and provide a direct mapping to HTTP, then have to come up with similar kludges for asynchronous peer-to-peer transactions as has been done in numerous ways for HTTP, or do we want to define the protocol cleanly to start with and accept that some sort of transaction relaying/conversion would have to take place at a mapping node? Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote: Hi, it looks to me that CoAP should use an explicit sub/notify mechanism since this is the core of the machine-to-machine interaction model. HTTP suffers of this lack and we have seen a plethora of solutions to give an asynch taste to it. Webhooks and websockets are only the lasts of the list. As someone has already pointed out on this list, it is theoretically possible to describe sub/notify using only CRUD methods but it looks a little bit tricky and verbose. Now we have a chance to build from scratch a new protocol with and I think using explicit sub/notify methods with a clear and well defined semantic is the best option. It is easily understanding from every developer and will prevent to build other fanny solutions on top of the CoAP. HTTP does not have this well defined semantic and (for hundreds of other reasons also) it is not used as wide protocol for machine-to-machine communication. CoAP - as binary protocol - and with an explicit asynch model has a chance to be a really wide protocol for M2M communication not only for constrained environments. my 2 cents - adriano -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Paul Duffy (paduffy) Sent: mercoled=EC 26 maggio 2010 0.47 To: Zach Shelby Cc: core Subject: Re: [core] Subscribe/Notify for CoAP On 5/25/2010 6:41 PM, Zach Shelby wrote: Hi, On May 26, 2010, at 12:23 AM, Charles Palmer wrote: Hi folks It occurs to me that CoRE should be keeping a close eye on ZigBee SE2.0 work, so that it is as easy as possible for ZigBee SE to use CoRE when ready. That suggests to me that we should align with their subscribe/notify process. I am not sure I understand that. I mean, ZigBee SE2.0 is defining an application specific subscribe/notify mechanism for that purpose so far for HTTP. This uses standard HTTP methods and some custom payload and REST interfaces. CoAP Req/Res is already totally compatible with SE2.0 in that respect, so alignment is already OK there. Nothing stopping someone from using SE2.0 over CoAP. Specifying a native susbcription/notify into CoAP is another matter. We can't adopt a solution specific to one application as that won't solve the problems of other applications nor general HTTP mapping at all (probably would make it worse). It seems that for the near future there will be a bunch of HTTP push mechanisms in use without any clear standard appearing - or am I wrong there? If COAP extends HTTP semantics with new subscription methods, it will not be possible to easily interchange HTTP/COAP, and translation gateways will become more complex to implement. Zach Regards - Charles -----Original Message----- From: core-bounces@ietf.org [ mailto:core-bounces@ietf.org] On Behalf Of Paul Duffy Sent: 25 May 2010 03:48 To: Zach Shelby Cc: core Subject: Re: [core] Subscribe/Notify for CoAP Recommend something like #2, primarily to avoid introducing non HTTP method semantics, simplifying HTTP/COAP translation.gateways, etc. On 5/24/2010 11:49 AM, Zach Shelby wrote: (thread renamed) We have two different paths with regard to a subscribe/notify mechanism for CoAP: 1. Use specific Subscription and Notify mechanisms for CoAP as HTTP really does not include this concept. 1a) Notify as a message and SUBSCRIBE as a method. This is currently used in coap-01. 1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but we had a good list discussion about this leading to a. In practice it doesn't make a big difference if notification is a message or method. 2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2.0 proposal or GENA. So far we have focused on 1 in the WG, and every now and again 2 comes up. At least I am not convinced that we need to suffer the drawbacks of HTTP here. Anyways 2 does not help our mapping to HTTP in reality very much as there is no standard way of doing this over HTTP. Thus a CoAP-HTTP proxy may end up anyways translating between multiple HTTP frameworks depending on the application. So instead of doing a CoAP Notify/Subscribe to Webhooks mapping, you will could end up having to do a CoAP Webhooks to HTTP GENA mapping. I don't understand this last para. If CoAP sticks to the semantics of the current HTTP methods, would this not offer a fairly straightforward translation to/from HTTP? From what I have heard so far 1 still seems like a wise choice, although I need to look at Webhooks more deeply. In reality many applications specify their own way of doing a push interface using REST methods and specific payloads (ZigBee SE2.0 is such an example). That is just fine, and might be used instead of a specific CoAP notify/subscribe in that case. So 1 doesn't prevent the application using its own mechanism, it just provides a native way for doing push. What do people think? Zach On May 17, 2010, at 6:44 PM, matthieu.vial@fr.non.schneider-el= ectric.com wrote: Hi, My comments about the subscribe/notify mechanism of Zigbee IP. Pros: - Derived from the webhooks concept - If used by CORE it will be easier to map to HTTP because it uses only CRUD verbs. - The subscription message is extendable and could support advanced options (delays, increment, ...) - Only one listening port whatever the transport binding is. Cons: - No interoperability without well known URIs and a well defined subscription message format (Not sure CoAP draft is the right place to specify this). - XML/EXI is too complex to be the required format for the default subscription/notifica= tion mechanism. - The notification should not require a subsequent GET to retrieve the content. - Subresource subscription is redundant. Hope this could help, Matthieu "Charles Palmer" "Charles Palmer" Envoy=E9 par : core-bounces@ietf.org 15/05/2010 14:06 A "core" cc Objet Re: [core] Selecting a WG document for CoAP Dear all Those interested in the subscribe/notify discussion might like to look at the draft Smart Energy Profile 2.0 Application Protocol Specification. It is available here: http://zigbee.org/Mar= kets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicApp licationProfile.aspx It manages subscribe/notify by using POST. This seems to remove the need for SUBSCRIBE and notify. "Imagine a host A, which exposes a resource at http {s}://A/resource and a second host B, which wishes to learn of changes to this resource. To facilitate a subscription/ notification mechanism, A would expose a resource http {s}://A/sub and B would expose a resource http {s}://B/ntfy. To subscribe to notifications regarding http {s}://A/resource, B would send a POST to the address http {s}://A/sub/B containing the URI of the resource of interest (http {s}://A/resource) and the URI of B's notification resource (http{s}://B/ntfy). Following this subscription step, should A wish to notify B of a change to the resource addressed at http{s}://A/resource, A would send a POST to the address http{s}://B/ntfy containing the URI of the resource changed (http {s}://A/resource) and the URI of A's subscription resource (http{s}://A/sub/B), should A wish to change its subscription. The host B can then query the resource (or not) at its leisure." Sleepy nodes are not allowed to subscribe, and must poll. Regards - Charles Palmer -----Original Message----- From: core-bounces@ietf.org [ mailto:core-bounces@i= etf.org ] On Behalf Of Angelo P. Castellani Sent: 14 May 2010 13:14 To: Zach Shelby Cc: core Subject: Re: [core] Selecting a WG document for CoAP Zach, thanks for the comments, but please refer to my most recent e-mail for a more specific list of technical issues I'm pointing to. I want to do only a little integration to what I've written there. In my very personal opinion, to maximize adherence with the REST model and minimize implementation effort SUBSCRIBE and NOTIFY should be mapped to methods (as discussed many times together...). Uniform interface principle (Fielding PhD dissertation Section 5.1.5, "The central feature that distinguishes the REST architectural style [...]") states that to simplify the software architecture, resource interfaces/interfaces should be as general as possible. I agree with this principle in this specific case, mainly because handling a special message type for notify leads node software design to a more complex architecture. The reason is that this new message type requires special handling and introduces a complexity in the software modularization. Best, Angelo On Fri, May 14, 2010 at 13:06, Zach Shelby wrote: Hi Angelo, On May 13, 2010, at 14:24 , Angelo P. Castellani wrote: Dear C. Bormann, all, before deciding for the final direction, I've the following observations about draft-shelby-core-coap-01 While I mostly share Zach's view of the protocol approach, and appreciate many aspects of the proposal, there are in my opinion still some open issues that need to be at least discussed before the current document can be selected. Of course there are plenty of open issues. Remember that working group documents still undertake as much change and improvement as the WG wants, so by no means is coap-01 set in stone. I would expect at least 5-10 more revisions still along the way. Already several of your ideas have been integrated into coap-01, and several more are under consideration, so it is coming along. Patience ;-) In particular, I would like to highlight the following: a) As it is now, it is not possible to have a straightforward translation of HTTP -> CoAP and viceversa: see http://www.ietf.org/mail-archive/web/core/current/msg00133.html (this impacts the scalability of the web service model too) In coap-01 the Method names are now identical to HTTP methods. The Req/Res interaction is a direct translation. The URI hierarchy is compatible, and the URI binary code format we are still working on obviously. The only thing that takes some state to translate is Subscribe/Notify. But note, Subscribe/Notify takes some state no matter how you do it, even with HTTP-HTTP there is no clean and easy way to handle subscriptions. b) Moreover, CoAP's implementation is not as simple as it should be. I've investigated the implementation and some design choices (as Options) are leading to very high program complexity (ROM) on a MSP430-based device. This we can definitely improve, and already made several optimizations from -00 to -01. Here I need some very concrete proposals though. Also remember that many things are optional, for example subscribe/notify is not required if you don't need it. c) Finally when comparing HTTP message size with CoAP message size, the resulting compression isn't as good as you may expect. Example: HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B CoAP: 24 B with options parsing procedure requiring an added implementation complexity Right, that is not how it will work in practice. Working with a real HTTP server that HTTP header will be more complex, and on the CoAP side you would chose shorter URLs. The biggest improvement possible here is from using binary coded URLs of course. We need to look at a wider range of interactions and real HTTP headers as well to check that we are efficient enough. Addressing all these points potentially leads to major technical modifications (especially point a) on the current draft, hence it is appropriate in my opinion to discuss these points before making the final decision. I am not sure what else you have in mind for a). If we just forget about Subscribe/Notify then you are good to go. But then you are also not fulfilling the charter or the industry needs in that respect. Thanks, Zach Best regards, Angelo P. Castellani On Mon, May 10, 2010 at 18:51, Carsten Bormann wrote: The CORE WG has a milestone to select a WG document for CoAP in April: http://datatracker.ietf.org/wg/core/charter/ ... Apr 2010 Select WG document for basis of the CoAP protocol Of the various documents that have been contributed, draft-shelby-core-coap has significant discussion, as well as the largest number of updates (including a previous version that was still called -6lowapp-coap). Today, another updated version of that draft was announced. See http://www.ietf.org/mail-archive/web/core/current/msg00138.h= tml for the announcement and http://tools.ietf.org/html/draft-shelby-core-coap-01 for the draft itself. However, as the authors say, there are still significant TODOs. Are we in a state yet where we can say whether this is the right direction for the WG to take? If yes, is it the right direction? Should we adopt it as a WG document? If you don't think we can say yet, is there a set of technical decisions you would like the authors to take with priority? Note that once a document has become a WG document, the authors act as editors for the working group, making (and usually fleshing out the details of) any change that the WG decides it needs. If you think we can still improve the draft, this is not an obstacle to making it a WG document. But of course we shouldn't do that if we intend to reverse its fundamental technical direction. In order to stay roughly in sync with our milestones, we should reach at a decision on how to go forward this week. Gruesse, Carsten =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://za= chshelby.org - My blog "On the Internet of Things " http://6l= owpan.net - My book " 6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 =5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F core mailing list core@ietf.org https://www.ietf.org/= mailman/listinfo/core ---------------------= ----------- Onzo is a limited company number 06097997 registered in England& Wales. The registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingdom. This email message may contain confidential and/or privileged information, and is intended solely for the addressee(s). If you have received this email in error, please notify Onzo immediately. Unauthorised copying, disclosure or distribution of the material in this email is forbidden. ---------------------= ----------- =5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F core mailing list core@ietf.org https://www.ietf.org/= mailman/listinfo/core =5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F This email has been scanned by the MessageLabs Email Security System. =5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F core mailing list core@ietf.org https://www.ietf.org/= mailman/listinfo/core =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core -------------------------------- Onzo is a limited company number 06097997 registered in England& Wales. The registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingdom. This email message may contain confidential and/or privileged information, and is intended solely for the addressee(s). If you have received this email in error, please notify Onzo immediately. Unauthorised copying, disclosure or distribution of the material in this email is forbidden. -------------------------------- =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F This email has been scanned by the MessageLabs Email Security System. =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core --1__=4EBBFDA7DFBEBDC58f9e8a93df938690918c4EBBFDA7DFBEBDC5 Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Hi Robert,

Here is a complete scenario:

The resource /event is a collection of events that occured in device A.
Device B wants to be notified each time a new event has occured in A.

One solution could be to subscribe when the method POST (thus a creation) i= s acted upon /event.
A would send a notify message with the URI of the new event (/event/1, /eve= nt/2 ...).

The second solution using the actual COAP specification is to define /event= /last as an alias to the last created event.
Device B would receive a notification each time /event/last has changed. The definition of "changed" becomes tricky if 2 successive events= are identical.
The content of /event/last is identical but it points to a different resour= ce.
Of course the etag could reflect that change.

So what is the RESTfulest solution ?

Matthieu

3D"InactiveRobert Cragie <robert.cragie@g= ridmerge.com>




          Robert Cragie <robert.cragie@gridmerge.com>

          28/05/2010 14:08
          Veuillez r=E9pondre =E0
          robert.cragie@gridmerge.com
3D"=
A
3D""
Matthieu Vial/FR/Non/Schneider@Europe
3D"=
cc
3D""
"Adriano Pezzuto (apezzuto)" <apezzuto@cisco.= com>, core <core@ietf.org>, core-bounces@ietf.org
3D"=
Objet
3D""
Re: [core] Subscribe/Notify for CoAP
3D""=3D""

Hi Matthieu,

I am not sure what you mean here. Do you mean that some other client can su= bscribe to be notified whenever some method is acted upon for a particular = resource? Can you describe the transaction model?

Robert

Robert Cragie (Pacific Gas & Elect= ric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com


On 28/05/2010 12:51 PM, matthieu.vial@fr.n= on.schneider-electric.com wrote:

      > So strictly sp= eaking, both NOTIFY and SUBSCRIBE are message types not methods!

      SUBSCRIBE can be just an asynchronous GET on update then I think it is a me= thod and NOTIFY is an asynchronous response so a message.
      But if we want to have selective notifications when a resource is created, = updated or deleted then I think you're right NOTIFY and SUBSCRIBE are messa= ges.

      Does that make sense ?

      Matthieu

      3D"Inactive"Adriano Pezzuto (apezzuto)" <apezzuto@cisco.com>
      A

      <robert.cragie@gridmerge.com>
      cc

      core <core@i= etf.org>
      Objet

      Re: [core] Subscribe/Notify for CoAP

      Hi Roberto,
      I understand your point and personally agree on M2M is quite different from= web page model. On the architectural RESTful style, the method information= tells the server what to do with data kept in the URI information.      <= font size=3D"4">

      So strictly speaking, both NOTIFY and SUBSCRIBE are message types not meth= ods!

      Adriano

      From:       Robert Cragie [mailto:robert.cragie@gridmerge.com] =
      Sent:       venerd=EC 28 maggio 2010 = 11.53
      To:       Adriano Pezzuto (apezzuto)<= /font>
      Cc:       Paul Duffy (paduffy); Zach = Shelby; core
      Subject:       Re: [core] Subscribe/N= otify for CoAP

      I think the point here is that there are two levels we are considering.

      At the lowest (foundation) level, there are the transaction messages as des= cribed below. This provides a flexible mechanism for the application with r= egard to synchronicity and threading. This is important for the types of de= vices CoAP is being aimed at.

      Above that, the methods can be used according to the architectural style. S= o in this case, it is RESTful (COnstrained Restful Environments), which wil= l naturally limit the number of methods and how transactions occur.

      The actual architecture using a combination of the methods and messages als= o depends on what is required at the application layer. Consider a typical = client which wants to subscribe to a resource. That client controls the fee= d of data but needs a component which is capable of handling (possibly buff= ering) the data it receives through notifications. Is this a separate serve= r? Or would we want to consider it part of an enhanced client model which i= s able to process feeds of data? These are the sort of models which have le= d to the myriad of solutions (GENA, Webhooks, long polling, pubsubhubbub, R= ESTMS etc.) based around HTTP which are all essentially ingenious ways of g= etting around the limitations imposed by HTTP and how it is processed for a= nything which deviates from the classic web page access model.

      I think the aim of CoAP should be clean from the word go with regard to sup= porting these more peer-to-peer transactions, where the client can exist on= either entity and both entities can feed data to each other; typical in M2= M applications.

      Robert

      Robert Cragie (Pacific Gas & Elect= ric)

      Gridmerge Ltd.
      89 Greenfield Crescent,
      Wakefield, WF4 4WA, UK
      +44 1924 910888
      +1 415 513 0064
      http://www.gridmerge.com

      On 27/05/2010 7:08 PM, Adriano Pezzuto (apezzuto) wrote:
      Hi Robert,

      in my personal opinion, the option 1a) brings some sort of ambiguity to CoA= P specs.

      My be my understatement of new CoAP specs is not so deep, but now we have 5= methods and 3 message types: request, response and notify. Which methods a= re allowed with which messages types?
      I suppose you have to use PUT/POST method with notify message for asynch da= ta notification. How to make a subscribe? I suppose you would use a SUBSCRI= BE method with request/response message or SUBSCRIBE with notify message? A= lso what about POST/DELETE methods in a notify message? They not make any s= ense..

      I think the choice is between: option 1) -> only CRUD methods and option= 1b) -> CRUD + SUB/NOTIFY methods, keeping in mind cost/benefits of both= solutions.

      Adriano

      From:       Robert Cragie [mailto:robert.cragie@gridmerge.com]       =
      Sent:       mercoled=EC 26 maggio 201= 0 20.09
      To:       Adriano Pezzuto (apezzuto)<= /font>
      Cc:       Paul Duffy (paduffy); Zach = Shelby; core
      Subject:       Re: [core] Subscribe/N= otify for CoAP

      Hi Adrian,

      I would also prefer to keep the protocol in CoAP asynchronous. You can alwa= ys map an asynchronous protocol to a synchronous one but, as we see in HTTP= , it always ends up as a kludge to do it the other way round. The efforts w= hich have been gone to to make HTTP quasi-asynchronous via all the schemes = mentioned below and many more besides (all non-interoperable of course) is = testament to how important this is for M2M communication.

      So, back to Zach's list, I favor 1a) for the following reasons:

      Foundation level of messages:

          1. re= quest/response can be asynchronous or synchronous messages (as there is a t= ransaction ID in there)
          2.           notify is an asynchrono= us message
      Derived methods:

      I think it makes sense to add a pub/sub model as a useful mechanism for M2M= .

      So, looking at it the other way round: It will be entirely possible to tran= slate whatever is currently built on HTTP to CoAP based on the above, with = all its restrictions regarding synchronous and client/server transactions. = What may be harder is to translate directly is a CoAP-based application to = HTTP. So I guess the question is: Do we want to be hamstrung to synchronous= client/server transactions as dictated by HTTP and provide a direct mappin= g to HTTP, then have to come up with similar kludges for asynchronous peer-= to-peer transactions as has been done in numerous ways for HTTP, or do we w= ant to define the protocol cleanly to start with and accept that some sort = of transaction relaying/conversion would have to take place at a mapping no= de?

      Robert

      Robert Cragie (Pacific Gas & Elect= ric)

      Gridmerge Ltd.
      89 Greenfield Crescent,
      Wakefield, WF4 4WA, UK
      +44 1924 910888
      +1 415 513 0064
      http://www.gridmerge.com

      On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote:
      Hi,
      it looks to me that CoAP should use an explicit sub/notify mechanism since = this is the core of the machine-to-machine interaction model.
      HTTP suffers of this lack and we have seen a plethora of solutions to give = an asynch taste to it. Webhooks and websockets are only the lasts of the li= st.
      As someone has already pointed out on this list, it is theoretically possib= le to describe sub/notify using only CRUD methods but it looks a little bit= tricky and verbose.

      Now we have a chance to build from scratch a new protocol with and I think = using explicit sub/notify methods with a clear and well defined semantic is= the best option. It is easily understanding from every developer and will = prevent to build other fanny solutions on top of the CoAP. HTTP does not ha= ve this well defined semantic and (for hundreds of other reasons also) it i= s not used as wide protocol for machine-to-machine communication.

      CoAP - as binary protocol - and with an explicit asynch model has a chance = to be a really wide protocol for M2M communication not only for constrained= environments.

      my 2 cents

      - adriano

      -----Original Message-----
      From:       core-bounces@ietf.org<= font size=3D"5" face=3D"Courier New"> [      mail= to:core-bounces@ietf.org

      On 5/25/2010 6:41 PM, Zach Shelby wrote:

              Hi,

              On May 26, 2010, at 12:23 AM, Charles Palmer wrote:              =

                      Hi folks<= br>
                      It occurs to me that CoRE should be keeping a close eye on ZigBee SE2.0 wor= k, so that it is as easy as possible for ZigBee SE to use CoRE when ready. = That suggests to me that we should align with their subscribe/notify proces= s.

              I am not sure I understand that. I me= an, ZigBee SE2.0 is defining an application specific subscribe/notify mecha= nism for that purpose so far for HTTP. This uses standard HTTP methods and = some custom payload and REST interfaces. CoAP Req/Res is already totally co= mpatible with SE2.0 in that respect, so alignment is already OK there. Noth= ing stopping someone from using SE2.0 over CoAP.

              Specifying a native susbcription/notify into CoAP is another matter. We can= 't adopt a solution specific to one application as that won't solve the pro= blems of other applications nor general HTTP mapping at all (probably would= make it worse). It seems that for the near future there will be a bunch of= HTTP push mechanisms in use without any clear standard appearing - or am I= wrong there?



      If COAP extends HTTP semantics with new subscription methods, it will
      not be possible to easily interchange HTTP/COAP, and translation
      gateways will become more complex to implement.
              Zach
                      Regards - Charles


                      -----Original Message-----
                      From:                       core-bounces@ietf.org<= font size=3D"5" face=3D"Courier New"> [mail= to:core-bounces@ietf.org

                      Recommend something like #2, primarily to avoid introducing non HTTP
                      method semantics, simplifying HTTP/COAP translation.gateways, etc.


                      On 5/24/2010 11:49 AM, Zach Shelby wrote:
                              (thread renamed)

                              We have two different paths with regard to a subscribe/notify mechanism for= CoAP:

                              1. Use specific Subscription and Notify mechanisms for CoAP as HTTP really = does not include this concept.
                              1a) Notify as a message and SUBSCRIBE as a method. This is currently used i= n coap-01.
                              1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but we had a= good list discussion about this leading to a. In practice it doesn't make = a big difference if notification is a message or method.

                              2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2.0 propos= al or GENA.

                              So far we have focused on 1 in the WG, and every now and again 2 comes up. = At least I am not convinced that we need to suffer the drawbacks of HTTP he= re. Anyways 2 does not help our mapping to HTTP in reality very much as the= re is no standard way of doing this over HTTP. Thus a CoAP-HTTP proxy may e= nd up anyways translating between multiple HTTP frameworks depending on the= application. So instead of doing a CoAP Notify/Subscribe to Webhooks mappi= ng, you will could end up having to do a CoAP Webhooks to HTTP GENA mapping= .


                      I don't understand this last para. If CoAP sticks to the semantics of
                      the current HTTP methods, would this not offer a fairly straightforward
                      translation to/from HTTP?
                                      From what I have heard so far 1 s= till seems like a wise choice, although I need to look at Webhooks more dee= ply. In reality many applications specify their own way of doing a push int= erface using REST methods and specific payloads (ZigBee SE2.0 is such an ex= ample). That is just fine, and might be used instead of a specific CoAP not= ify/subscribe in that case. So 1 doesn't prevent the application using its = own mechanism, it just provides a native way for doing push.
                              What do people think?

                              Zach

                              On May 17, 2010, at 6:44 PM,                               matthieu.vial@fr.non.schneider-electric.com wrote:
                                      Hi,

                                      My comments about the subscribe/notify mechanism of Zigbee IP.

                                      Pros:
                                      - Derived from the webhooks concept
                                      - If used by CORE it will be easier to map to HTTP because it uses only CRU= D verbs.
                                      - The subscription message is extendable and could support advanced options= (delays, increment, ...)
                                      - Only one listening port whatever the transport binding is.

                                      Cons:
                                      - No interoperability without well known URIs and a well defined subscripti= on message format (Not sure CoAP draft is the right place to specify this).=
                                      - XML/EXI is too complex to be the required format for the default subscrip= tion/notification mechanism.
                                      - The notification should not require a subsequent GET to retrieve the cont= ent.
                                      - Subresource subscription is redundant.

                                      Hope this could help,
                                      Matthieu


                                      <graycol.gif>"Charles Palmer"                                      <charles.palmer@onzo.com>




                                      "Charles Palmer"                                      <charles.pal= mer@onzo.com>
                                      Envoy=E9 par :                                       core-bounces@ietf.org=
                                      15/05/2010 14:06

                                      <ecblank.gif>
                                      A
                                      <ecblank.gif>
                                      "core"                                      <core@ietf.org>
                                      <ecblank.gif>
                                      cc
                                      <ecblank.gif>
                                      <ecblank.gif>
                                      Objet
                                      <ecblank.gif>
                                      Re: [core] Selecting a WG document for CoAP
                                      <ecblank.gif> <ecblank.gif>

                                      Dear all

                                      Those interested in the subscribe/notify discussion might like to look
                                      at the draft Smart Energy Profile 2.0 Application Protocol
                                      Specification. It is available here:
                                      http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicA= pp
                                      licationProfile.aspx

                                      It manages subscribe/notify by using POST. This seems to remove the need
                                      for SUBSCRIBE and notify.

                                      "Imagine a host A, which exposes a resource at http{s}://A/resource an= d
                                      a second host B, which wishes to learn of changes to this resource. To
                                      facilitate a subscription/ notification mechanism, A would expose a
                                      resource http{s}://A/sub and B would expose a resource http{s}://B/ntfy.
                                      To subscribe to notifications regarding http{s}://A/resource, B would
                                      send a POST to the address http{s}://A/sub/B containing the URI of the
                                      resource of interest (http{s}://A/resource) and the URI of B's
                                      notification resource (http{s}://B/ntfy). Following this subscription
                                      step, should A wish to notify B of a change to the resource addressed at
                                      http{s}://A/resource, A would send a POST to the address
                                      http{s}://B/ntfy containing the URI of the resource changed
                                      (http{s}://A/resource) and the URI of A's subscription resource
                                      (http{s}://A/sub/B), should A wish to change its subscription. The host
                                      B can then query the resource (or not) at its leisure."

                                      Sleepy nodes are not allowed to subscribe, and must poll.

                                      Regards - Charles Palmer

                                      -----Original Message-----
                                      From:                                       core-bounces@ietf.org<= font size=3D"5" face=3D"Courier New"> [mail= to:core-bounces@ietf.org

                                      Zach,

                                      thanks for the comments, but please refer to my most recent e-mail for
                                      a more specific list of technical issues I'm pointing to.

                                      I want to do only a little integration to what I've written there.

                                      In my very personal opinion, to maximize adherence with the REST model
                                      and minimize implementation effort SUBSCRIBE and NOTIFY should be
                                      mapped to methods (as discussed many times together...).

                                      Uniform interface principle (Fielding PhD dissertation Section 5.1.5,
                                      "The central feature that distinguishes the REST architectural style [...]") states that to simplify the software architecture, resource
                                      interfaces/interfaces should be as general as possible.

                                      I agree with this principle in this specific case, mainly because
                                      handling a special message type for notify leads node software design
                                      to a more complex architecture.

                                      The reason is that this new message type requires special handling and
                                      introduces a complexity in the software modularization.

                                      Best,
                                      Angelo

                                      On Fri, May 14, 2010 at 13:06, Zach Shelby                                      <= zach@sensinode.com>= wrote:
                                              Hi Angelo,

                                              On May 13, 2010, at 14:24 , Angelo P. Castellani wrote:
                                                      Dear C. Bormann, all,

                                                      before deciding for the final direction, I've the following
                                                      observations about draft-shelby-core-coap-01

                                                      While I mostly share Zach's view of the protocol approach, and
                                                      appreciate many aspects of the proposal, there are in my opinion

                                      still
                                                      some open issues that need to be = at least discussed before the

                                      current
                                                      document can be selected.<= font size=3D"4">

                                              Of course there are plenty of open is= sues. Remember that working group

                                      documents still undertake as much cha= nge and improvement as the WG
                                      wants, so by no means is coap-01 set in stone. I would expect at least
                                      5-10 more revisions still along the way. Already several of your ideas
                                      have been integrated into coap-01, and several more are under
                                      consideration, so it is coming along. Patience ;-)                                      <= br>
                                                      In particular, I would like to hi= ghlight the following:

                                                      a) As it is now, it is not possible to have a straightforward
                                                      translation of HTTP -> CoAP and viceversa: see
                                                      http= ://www.ietf.org/mail-archive/web/core/current/msg00133.html<= font size=3D"5" face=3D"Courier New"> (this
                                                      impacts the scalability of the web service model too)

                                              In coap-01 the Method names are now i= dentical to HTTP methods. The

                                      Req/Res interaction is a direct trans= lation. The URI hierarchy is
                                      compatible, and the URI binary code format we are still working on
                                      obviously. The only thing that takes some state to translate is
                                      Subscribe/Notify. But note, Subscribe/Notify takes some state no matter
                                      how you do it, even with HTTP-HTTP there is no clean and easy way to
                                      handle subscriptions.
                                                      b) Moreover, CoAP's implementatio= n is not as simple as it should be.
                                                      I've investigated the implementation and some design choices (as
                                                      Options) are leading to very high program complexity (ROM) on a
                                                      MSP430-based device.

                                              This we can definitely improve, and a= lready made several optimizations

                                      from -00 to -01. Here I need some ver= y concrete proposals though. Also
                                      remember that many things are optional, for example subscribe/notify is
                                      not required if you don't need it.
                                                      c) Finally when comparing HTTP me= ssage size with CoAP message size,
                                                      the resulting compression isn't as good as you may expect.

                                                      Example:
                                                      HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B
                                                      CoAP: 24 B with options parsing procedure requiring an added
                                                      implementation complexity

                                              Right, that is not how it will work i= n practice. Working with a real

                                      HTTP server that HTTP header will be = more complex, and on the CoAP side
                                      you would chose shorter URLs. The biggest improvement possible here is
                                      from using binary coded URLs of course. We need to look at a wider range
                                      of interactions and real HTTP headers as well to check that we are
                                      efficient enough.
                                                      Addressing all these points poten= tially leads to major technical
                                                      modifications (especially point a) on the current draft, hence it is
                                                      appropriate in my opinion to discuss these points before making the
                                                      final decision.

                                              I am not sure what else you have in m= ind for a). If we just forget

                                      about Subscribe/Notify then you are g= ood to go. But then you are also
                                      not fulfilling the charter or the industry needs in that respect.

                                              Thanks,
                                              Zach
                                                      Best regards,

                                                      Angelo P. Castellani


                                                      On Mon, May 10, 2010 at 18:51, Carsten Bormann                                                      <ca= bo@tzi.org> wrote:<= /font>
                                                              The CORE WG has a milestone to se= lect a WG document for CoAP in

                                      April:

                                       draft-shelby-core-coap has significan= t discussion, as well as the
                                      largest number of updates (including a previous version that was still
                                      called -6lowapp-coap).

                                                                             direction for the WG to take?<= font size=3D"4">
                                                              If yes, is it the right direction= ? Should we adopt it as a WG

                                      document?
                                                              If you don't think we can say yet= , is there a set of technical

                                      decisions you would like the authors = to take with priority?
                                                              Note that once a document has bec= ome a WG document, the authors act

                                      as editors for the working group, mak= ing (and usually fleshing out the
                                      details of) any change that the WG decides it needs.
                                                              If you think we can still improve= the draft, this is not an obstacle

                                      to making it a WG document.

                                                              But of course we shouldn't do tha= t if we intend to reverse its

                                      fundamental technical direction.
                                                              In order to stay roughly in sync = with our milestones, we should

                                      reach at a decision on how to go forw= ard this week.

                                       =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
                                      core mailing list
                                      core@ietf.org
                                      https://www.ietf.org/mail= man/listinfo/core

                                      --------------------------------
                                      Onzo is a limited company number 06097997 registered in England& Wales.= The
                                      registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingd= om.

                                      This email message may contain confidential and/or privileged information, = and
                                      is intended solely for the addressee(s). If you have received this email in=
                                      error, please notify Onzo immediately. Unauthorised copying, disclosure or<= br> distribution of the material in this email is forbidden.
                                      --------------------------------

                                      =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
                                      core mailing list
                                      core@ietf.org
                                      https://www.ietf.org/mail= man/listinfo/core

                                      =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
                                      This email has been scanned by the MessageLabs Email Security System.
                                      =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F

                                      =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
                                      core mailing list
                                      core@ietf.org
                                      https://www.ietf.org/mail= man/listinfo/core

                      =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
                      core mailing list
                      core@ietf.org
                      https://www.ietf.org/mail= man/listinfo/core

                      --------------------------------
                      Onzo is a limited company number 06097997 registered in England& Wales.= The
                      registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingd= om.

                      This email message may contain confidential and/or privileged information, = and
                      is intended solely for the addressee(s). If you have received this email in=
                      error, please notify Onzo immediately. Unauthorised copying, disclosure or<= br> distribution of the material in this email is forbidden.
                      --------------------------------


      =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
      core mailing list
      core@ietf.org
      https://www.ietf.org/mail= man/listinfo/core
      =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
      core mailing list
      core@ietf.org
      https://www.ietf.org/mail= man/listinfo/core



      =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
      This email has been scanned by the MessageLabs Email Security System.
      =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F      =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F
      core mailing list
      core@ietf.org
      = https://www.ietf.org/mailman/listinfo= /core

--1__=4EBBFDA7DFBEBDC58f9e8a93df938690918c4EBBFDA7DFBEBDC5-- --0__=4EBBFDA7DFBEBDC58f9e8a93df938690918c4EBBFDA7DFBEBDC5 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <2__=4EBBFDA7DFBEBDC58@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=4EBBFDA7DFBEBDC58f9e8a93df938690918c4EBBFDA7DFBEBDC5 Content-type: image/gif; name="pic09930.gif" Content-Disposition: inline; filename="pic09930.gif" Content-ID: <3__=4EBBFDA7DFBEBDC58@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=4EBBFDA7DFBEBDC58f9e8a93df938690918c4EBBFDA7DFBEBDC5 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <4__=4EBBFDA7DFBEBDC58@schneider-electric.com> Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=4EBBFDA7DFBEBDC58f9e8a93df938690918c4EBBFDA7DFBEBDC5-- From angelo.castellani@gmail.com Mon May 31 03:09:31 2010 Return-Path: X-Original-To: core@core3.amsl.com Delivered-To: core@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CF9C28C0E5 for ; Mon, 31 May 2010 03:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.773 X-Spam-Level: * X-Spam-Status: No, score=1.773 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6Xl+zuDLzyK for ; Mon, 31 May 2010 03:09:27 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 27B0D28C0E1 for ; Mon, 31 May 2010 03:09:27 -0700 (PDT) Received: by yxn35 with SMTP id 35so429505yxn.31 for ; Mon, 31 May 2010 03:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=/gQQyfSXKEmtL3wyl9u3LRSQ2mr8A45ZxRUiNwIiWEw=; b=auKkxJnYjmzzJSM0YeH3CVJZc0QuyA0n0MSDUnRp7saaZh8uWEXbuDWR/LhGw137gk 2EPanSSm0ViXMRId1SJKAAauhlpx23JWcJLX+BCcO5/jt2BjvQJGhZHH4BPEiafwURdg nEWLSJnL2dFfV1y8/v+WYd0+Cfwty2v+gdyC4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Jv9hl2PeNEPw+TC4j4JC3egEEsEnWeZNrQRSKhnuR9rCrbJYE+ZSEHZIEHLp8fkrNQ 4VQzMt9AoyD3oE6c+DOeteN0z6a0bVOEGGQiCW7KA2frQRBpbySgboNRVdV6rWBV1EJ7 SX4M2/sME/iHpNZus9TBFD6nbQ5yCF47//pbA= MIME-Version: 1.0 Received: by 10.91.162.16 with SMTP id p16mr2222726ago.101.1275300551928; Mon, 31 May 2010 03:09:11 -0700 (PDT) Sender: angelo.castellani@gmail.com Received: by 10.90.26.2 with HTTP; Mon, 31 May 2010 03:09:11 -0700 (PDT) In-Reply-To: <54C0D124-0AD3-4A30-8D98-4FC0FE134134@sensinode.com> References: <0D212BD466921646B58854FB79092CEC021F4E91@XMB-AMS-106.cisco.com> <0D212BD466921646B58854FB79092CEC021F4EF2@XMB-AMS-106.cisco.com> <6A9FCAC7-E2FA-482D-ABFF-DB6B111A9EA2@sensinode.com> <54C0D124-0AD3-4A30-8D98-4FC0FE134134@sensinode.com> Date: Mon, 31 May 2010 12:09:11 +0200 X-Google-Sender-Auth: Xt6q6-kpMp3Dh9_VeRNBvrM1AXc Message-ID: From: "Angelo P. Castellani" To: Zach Shelby Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: core Subject: Re: [core] Subscribe/Notify for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 10:09:31 -0000 Zach, Robert, all, I want add a short clarification about my previous message. To integrate SUBSCRIBE/NOTIFY in a RESTful protocol, the entities involved in the process should be *both* resources and not an endpoint and a resource. In my opinion when we talk of REST, the main concept is that every destination of an interaction is a resource. However SUBSCRIBE/NOTIFY interaction methods are different from the GET/POST/PUT/etc. methods, because they're stateful by design. In its very radical design constraints REST does not want to retain state informations about anything. So in my opinion to better cope with this paradoxical requirement we should work to retain the best stateless design for a stateful interaction. This is the reason why when we require a SUBSCRIBE to a resource, the resource itself should became an endpoint that has to access a different resource (the NOTIFY resource!). End-points in REST retain state, and for this reason the subscribed resource has become an endpoint. This is why I think that SUBSCRIBE/NOTIFY methods require two different URI= : - Destination-URI (the traditional URI), that specifies the resource destination of the interaction - Source-URI, that specifies the resource *source* of the interaction Best, Angelo On Fri, May 28, 2010 at 16:29, Zach Shelby wrote: > On May 28, 2010, at 4:13 PM, Angelo P. Castellani wrote: > >> In my opinion Subscribe/Notify are special methods of interaction >> between resources. > > This is definitely one valid way to look at it. > >> >> 1) SUBSCRIBE: Any resource A can send a Request to SUBSCRIBE with a >> resource B (to the resource B URI). > > Small correction, it is not a resource sending the SUBSCRIBE, it is an en= d-point (source address + port) sending it. Correct, it is being sent for r= esource B. So end-point A sends a SUBSCRIBE for resource B. > >> >> When B receives the request, B can (should/must?) answer with a > > MUST I would say (so the A flag must be set). > >> Response to the SUBSCRIBE Request, telling the result of the request >> (subscription accepted/denied/unsupported?). > > Yep. > >> >> 2) NOTIFY: When subscription condition fires the resource B sends a >> NOTIFY Request to resource A URI. > > The end-point sends a NOTIFY Request about resource B's URI to end-point = A. So there is not a source and destination "resource", instead there is ju= st resource B. > >> When A receives the request, A can (should/must?) answer with a >> Response to the NOTIFY Request, telling the result of the request (OK, >> cancel subscription, change notify options?). > > The A flag would control the need for a response. > >> In each Request must be specified the URI of the resource doing the >> Request too (Option? From-URI?). > > Actually, this is the URI (resource B) so you only need one URI. This is = why I say that a notification is like an inverse GET request. > > Zach > >> >> Angelo >> >> On Fri, May 28, 2010 at 14:50, Zach Shelby wrote: >>> Hi, >>> >>> This is a really good conversation. One thing we need to do is remember= what our minimum requirements are for subscribe/notify and not try to solv= e something more than we should. From what I know it is sufficient to be ab= le to receive notifications when a URI changes or periodically. You might c= onsider new URIs under this URI path to be changes to a URI though... >>> >>> On May 28, 2010, at 3:08 PM, Adriano Pezzuto (apezzuto) wrote: >>> >>>> Hello, >>>> with this flavor, the SUBSCRIBE may be replaced by a simple POST. So n= o needs to have an explicit SUBSCRIBE method. >>> >>> This is what coap-01 assumes. >>> >>>> If we want support a more oriented peer-to-peer transaction on CoAP, i= t looks to me both SUB and NOTIFY should be treated as messages. >>> >>> The Request/Response model can be used peer-to-peer, and in CoAP you ca= n even use a Request asynchronously. Additionally, we want a native RESTful= subscribe/notify technique, that is, we want to subscribe to resources and= be susequently notified about those resources when they change. >>> >>> In that sense, you can think of a subscription as a request to receive = asynchronous notifications about a resource (about a URI). This can be achi= eved by: >>> >>> 1. =A0as a SUBSCRIBE Request on the URI with some option indicating the= lifetime as in coap-01, >>> 2. =A0as a Subcsribe message (no methods) on the URI with some option, >>> 3. =A0or as a POST Request on the URI with options indicating that this= is actually a subscription and the lifetime. =A0This bends the meaning of = POST quite a bit and might be prone to mistakes? >>> >>> The asynchronous response is a harder one. Can we bend the meaning of a= Request for making asynchronous notifications? Also a notification include= s a URI about a resource on the requestor, which is inverse from normal Req= uests in REST. So the options here are: >>> >>> 1. as a Notify message about a URI (no methods) as in coap-01, >>> 2. as a NOTIFY Request about a URI as was in coap-00, >>> 3. hmmm... reusing CRUD methods really doesn't work for this one at all= ... >>> >>> I wonder what the HTTP designers would have done if this would have bee= n a requirement back then? Maybe we should ask them... >>> >>> Zach >>> >>>> >>>> Adriano >>>> >>>> From: matthieu.vial@fr.non.schneider-electric.com [mailto:matthieu.via= l@fr.non.schneider-electric.com] >>>> Sent: venerd=EC 28 maggio 2010 13.52 >>>> To: Adriano Pezzuto (apezzuto) >>>> Cc: core; core-bounces@ietf.org; robert.cragie@gridmerge.com >>>> Subject: Re: [core] Subscribe/Notify for CoAP >>>> >>>>> So strictly speaking, both NOTIFY and SUBSCRIBE are message types not= =A0methods! >>>> >>>> SUBSCRIBE can be just an asynchronous GET on update then I think it is= a method and NOTIFY is an asynchronous response so a message. >>>> But if we want to have selective notifications when a resource is crea= ted, updated or deleted then I think you're right NOTIFY and SUBSCRIBE are = messages. >>>> >>>> Does that make sense ? >>>> >>>> Matthieu >>>> >>>> "Adriano Pezzuto (apezzuto)" >>>> >>>> >>>> >>>> >>>> "Adriano Pezzuto (apezzuto)" >>>> Envoy=E9 par : core-bounces@ietf.org >>>> 28/05/2010 12:50 >>>> >>>> >>>> A >>>> >>>> >>>> >>>> cc >>>> >>>> core >>>> >>>> Objet >>>> >>>> Re: [core] Subscribe/Notify for CoAP >>>> >>>> >>>> >>>> Hi Roberto, >>>> I understand your point and personally agree on M2M is quite different= from web page model. On the architectural RESTful style, the method inform= ation tells the server what to do with data kept in the URI information. >>>> >>>> So strictly speaking, both NOTIFY and SUBSCRIBE are message types not = =A0methods! >>>> >>>> Adriano >>>> >>>> From: Robert Cragie [mailto:robert.cragie@gridmerge.com] >>>> Sent: venerd=EC 28 maggio 2010 11.53 >>>> To: Adriano Pezzuto (apezzuto) >>>> Cc: Paul Duffy (paduffy); Zach Shelby; core >>>> Subject: Re: [core] Subscribe/Notify for CoAP >>>> >>>> I think the point here is that there are two levels we are considering= . >>>> >>>> At the lowest (foundation) level, there are the transaction messages a= s described below. This provides a flexible mechanism for the application w= ith regard to synchronicity and threading. This is important for the types = of devices CoAP is being aimed at. >>>> >>>> Above that, the methods can be used according to the architectural sty= le. So in this case, it is RESTful (COnstrained Restful Environments), whic= h will naturally limit the number of methods and how transactions occur. >>>> >>>> The actual architecture using a combination of the methods and message= s also depends on what is required at the application layer. Consider a typ= ical client which wants to subscribe to a resource. That client controls th= e feed of data but needs a component which is capable of handling (possibly= buffering) the data it receives through notifications. Is this a separate = server? Or would we want to consider it part of an enhanced client model wh= ich is able to process feeds of data? These are the sort of models which ha= ve led to the myriad of solutions (GENA, Webhooks, long polling, pubsubhubb= ub, RESTMS etc.) based around HTTP which are all essentially ingenious ways= of getting around the limitations imposed by HTTP and how it is processed = for anything which deviates from the classic web page access model. >>>> >>>> I think the aim of CoAP should be clean from the word go with regard t= o supporting these more peer-to-peer transactions, where the client can exi= st on either entity and both entities can feed data to each other; typical = in M2M applications. >>>> >>>> Robert >>>> >>>> Robert Cragie (Pacific Gas & Electric) >>>> >>>> Gridmerge Ltd. >>>> 89 Greenfield Crescent, >>>> Wakefield, WF4 4WA, UK >>>> +44 1924 910888 >>>> +1 415 513 0064 >>>> http://www.gridmerge.com >>>> >>>> On 27/05/2010 7:08 PM, Adriano Pezzuto (apezzuto) wrote: >>>> Hi Robert, >>>> >>>> in my personal opinion, the option 1a) brings some sort of ambiguity t= o CoAP specs. >>>> >>>> My be my understatement of new CoAP specs is not so deep, but now we h= ave 5 methods and 3 message types: request, response and notify. Which meth= ods are allowed with which messages types? >>>> I suppose you have to use PUT/POST method with notify message for asyn= ch data notification. How to make a subscribe? I suppose you would use a SU= BSCRIBE method with request/response message or SUBSCRIBE with notify messa= ge? Also what about POST/DELETE methods in a notify message? They not make = any sense.. >>>> >>>> I think the choice is between: option 1) -> only CRUD methods and opti= on 1b) -> CRUD + SUB/NOTIFY methods, keeping in mind cost/benefits of both = solutions. >>>> >>>> Adriano >>>> >>>> From: Robert Cragie [mailto:robert.cragie@gridmerge.com] >>>> Sent: mercoled=EC 26 maggio 2010 20.09 >>>> To: Adriano Pezzuto (apezzuto) >>>> Cc: Paul Duffy (paduffy); Zach Shelby; core >>>> Subject: Re: [core] Subscribe/Notify for CoAP >>>> >>>> Hi Adrian, >>>> >>>> I would also prefer to keep the protocol in CoAP asynchronous. You can= always map an asynchronous protocol to a synchronous one but, as we see in= HTTP, it always ends up as a kludge to do it the other way round. The effo= rts which have been gone to to make HTTP quasi-asynchronous via all the sch= emes mentioned below and many more besides (all non-interoperable of course= ) is testament to how important this is for M2M communication. >>>> >>>> So, back to Zach's list, I favor 1a) for the following reasons: >>>> >>>> Foundation level of messages: >>>> >>>> 1. request/response can be asynchronous or synchronous messages (as th= ere is a transaction ID in there) >>>> 2. notify is an asynchronous message >>>> Derived methods: >>>> >>>> I think it makes sense to add a pub/sub model as a useful mechanism fo= r M2M. >>>> >>>> So, looking at it the other way round: It will be entirely possible to= translate whatever is currently built on HTTP to CoAP based on the above, = with all its restrictions regarding synchronous and client/server transacti= ons. What may be harder is to translate directly is a CoAP-based applicatio= n to HTTP. So I guess the question is: Do we want to be hamstrung to synchr= onous client/server transactions as dictated by HTTP and provide a direct m= apping to HTTP, then have to come up with similar kludges for asynchronous = peer-to-peer transactions as has been done in numerous ways for HTTP, or do= we want to define the protocol cleanly to start with and accept that some = sort of transaction relaying/conversion would have to take place at a mappi= ng node? >>>> >>>> Robert >>>> Robert Cragie (Pacific Gas & Electric) >>>> >>>> Gridmerge Ltd. >>>> 89 Greenfield Crescent, >>>> Wakefield, WF4 4WA, UK >>>> +44 1924 910888 >>>> +1 415 513 0064 >>>> http://www.gridmerge.com >>>> >>>> On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote: >>>> Hi, >>>> it looks to me that CoAP should use an explicit sub/notify mechanism s= ince this is the core of the machine-to-machine interaction model. >>>> HTTP suffers of this lack and we have seen a plethora of solutions to = give an asynch taste to it. Webhooks and websockets are only the lasts of t= he list. >>>> As someone has already pointed out on this list, it is theoretically p= ossible to describe sub/notify using only CRUD methods but it looks a littl= e bit tricky and verbose. >>>> >>>> Now we have a chance to build from scratch a new protocol with and I t= hink using explicit sub/notify methods with a clear and well defined semant= ic is the best option. It is easily understanding from every developer and = will prevent to build other fanny solutions on top of the CoAP. HTTP does n= ot have this well defined semantic and (for hundreds of other reasons also)= it is not used as wide protocol for machine-to-machine communication. >>>> >>>> CoAP - as binary protocol - and with an explicit asynch model has a ch= ance to be a really wide protocol for M2M communication not only for constr= ained environments. >>>> >>>> my 2 cents >>>> >>>> - adriano >>>> >>>> -----Original Message----- >>>> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf O= f Paul Duffy (paduffy) >>>> Sent: mercoled=EC 26 maggio 2010 0.47 >>>> To: Zach Shelby >>>> Cc: core >>>> Subject: Re: [core] Subscribe/Notify for CoAP >>>> >>>> On 5/25/2010 6:41 PM, Zach Shelby wrote: >>>> >>>> Hi, >>>> >>>> On May 26, 2010, at 12:23 AM, Charles Palmer wrote: >>>> >>>> >>>> Hi folks >>>> >>>> It occurs to me that CoRE should be keeping a close eye on ZigBee SE2.= 0 work, so that it is as easy as possible for ZigBee SE to use CoRE when re= ady. That suggests to me that we should align with their subscribe/notify p= rocess. >>>> >>>> >>>> I am not sure I understand that. I mean, ZigBee SE2.0 is defining an a= pplication specific subscribe/notify mechanism for that purpose so far for = HTTP. This uses standard HTTP methods and some custom payload and REST inte= rfaces. CoAP Req/Res is already totally compatible with SE2.0 in that respe= ct, so alignment is already OK there. Nothing stopping someone from using S= E2.0 over CoAP. >>>> >>>> Specifying a native susbcription/notify into CoAP is another matter. W= e can't adopt a solution specific to one application as that won't solve th= e problems of other applications nor general HTTP mapping at all (probably = would make it worse). It seems that for the near future there will be a bun= ch of HTTP push mechanisms in use without any clear standard appearing - or= am I wrong there? >>>> >>>> >>>> >>>> >>>> If COAP extends HTTP semantics with new subscription methods, it will >>>> not be possible to easily interchange HTTP/COAP, and translation >>>> gateways will become more complex to implement. >>>> >>>> >>>> >>>> Zach >>>> >>>> >>>> Regards - Charles >>>> >>>> >>>> -----Original Message----- >>>> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf O= f Paul Duffy >>>> Sent: 25 May 2010 03:48 >>>> To: Zach Shelby >>>> Cc: core >>>> Subject: Re: [core] Subscribe/Notify for CoAP >>>> >>>> Recommend something like #2, primarily to avoid introducing non HTTP >>>> method semantics, simplifying HTTP/COAP translation.gateways, etc. >>>> >>>> >>>> On 5/24/2010 11:49 AM, Zach Shelby wrote: >>>> >>>> (thread renamed) >>>> >>>> We have two different paths with regard to a subscribe/notify mechanis= m for CoAP: >>>> >>>> 1. Use specific Subscription and Notify mechanisms for CoAP as HTTP re= ally does not include this concept. >>>> 1a) Notify as a message and SUBSCRIBE as a method. This is currently u= sed in coap-01. >>>> 1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but we = had a good list discussion about this leading to a. In practice it doesn't = make a big difference if notification is a message or method. >>>> >>>> 2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2.0 p= roposal or GENA. >>>> >>>> So far we have focused on 1 in the WG, and every now and again 2 comes= up. At least I am not convinced that we need to suffer the drawbacks of HT= TP here. Anyways 2 does not help our mapping to HTTP in reality very much a= s there is no standard way of doing this over HTTP. Thus a CoAP-HTTP proxy = may end up anyways translating between multiple HTTP frameworks depending o= n the application. So instead of doing a CoAP Notify/Subscribe to Webhooks = mapping, you will could end up having to do a CoAP Webhooks to HTTP GENA ma= pping. >>>> >>>> >>>> >>>> I don't understand this last para. If CoAP sticks to the semantics of >>>> the current HTTP methods, would this not offer a fairly straightforwar= d >>>> translation to/from HTTP? >>>> >>>> >>>> >>>> From what I have heard so far 1 still seems like a wise choice, althou= gh I need to look at Webhooks more deeply. In reality many applications spe= cify their own way of doing a push interface using REST methods and specifi= c payloads (ZigBee SE2.0 is such an example). That is just fine, and might = be used instead of a specific CoAP notify/subscribe in that case. So 1 does= n't prevent the application using its own mechanism, it just provides a nat= ive way for doing push. >>>> >>>> What do people think? >>>> >>>> Zach >>>> >>>> On May 17, 2010, at 6:44 PM,matthieu.vial@fr.non.schneider-electric.co= m wrote: >>>> >>>> >>>> >>>> Hi, >>>> >>>> My comments about the subscribe/notify mechanism of Zigbee IP. >>>> >>>> Pros: >>>> - Derived from the webhooks concept >>>> - If used by CORE it will be easier to map to HTTP because it uses onl= y CRUD verbs. >>>> - The subscription message is extendable and could support advanced op= tions (delays, increment, ...) >>>> - Only one listening port whatever the transport binding is. >>>> >>>> Cons: >>>> - No interoperability without well known URIs and a well defined subsc= ription message format (Not sure CoAP draft is the right place to specify t= his). >>>> - XML/EXI is too complex to be the required format for the default sub= scription/notification mechanism. >>>> - The notification should not require a subsequent GET to retrieve the= content. >>>> - Subresource subscription is redundant. >>>> >>>> Hope this could help, >>>> Matthieu >>>> >>>> >>>> "Charles Palmer" >>>> >>>> >>>> >>>> >>>> "Charles Palmer" >>>> Envoy=E9 par : core-bounces@ietf.org >>>> 15/05/2010 14:06 >>>> >>>> >>>> A >>>> >>>> "core" >>>> >>>> cc >>>> >>>> >>>> Objet >>>> >>>> Re: [core] Selecting a WG document for CoAP >>>> >>>> >>>> Dear all >>>> >>>> Those interested in the subscribe/notify discussion might like to look >>>> at the draft Smart Energy Profile 2.0 Application Protocol >>>> Specification. It is available here: >>>> http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicA= pp >>>> licationProfile.aspx >>>> >>>> It manages subscribe/notify by using POST. This seems to remove the ne= ed >>>> for SUBSCRIBE and notify. >>>> >>>> "Imagine a host A, which exposes a resource at http{s}://A/resource an= d >>>> a second host B, which wishes to learn of changes to this resource. To >>>> facilitate a subscription/ notification mechanism, A would expose a >>>> resource http{s}://A/sub and B would expose a resource http{s}://B/ntf= y. >>>> To subscribe to notifications regarding http{s}://A/resource, B would >>>> send a POST to the address http{s}://A/sub/B containing the URI of the >>>> resource of interest (http{s}://A/resource) and the URI of B's >>>> notification resource (http{s}://B/ntfy). Following this subscription >>>> step, should A wish to notify B of a change to the resource addressed = at >>>> http{s}://A/resource, A would send a POST to the address >>>> http{s}://B/ntfy containing the URI of the resource changed >>>> (http{s}://A/resource) and the URI of A's subscription resource >>>> (http{s}://A/sub/B), should A wish to change its subscription. The hos= t >>>> B can then query the resource (or not) at its leisure." >>>> >>>> Sleepy nodes are not allowed to subscribe, and must poll. >>>> >>>> Regards - Charles Palmer >>>> >>>> -----Original Message----- >>>> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf O= f >>>> Angelo P. Castellani >>>> Sent: 14 May 2010 13:14 >>>> To: Zach Shelby >>>> Cc: core >>>> Subject: Re: [core] Selecting a WG document for CoAP >>>> >>>> Zach, >>>> >>>> thanks for the comments, but please refer to my most recent e-mail for >>>> a more specific list of technical issues I'm pointing to. >>>> >>>> I want to do only a little integration to what I've written there. >>>> >>>> In my very personal opinion, to maximize adherence with the REST model >>>> and minimize implementation effort SUBSCRIBE and NOTIFY should be >>>> mapped to methods (as discussed many times together...). >>>> >>>> Uniform interface principle (Fielding PhD dissertation Section 5.1.5, >>>> "The central feature that distinguishes the REST architectural style >>>> [...]") states that to simplify the software architecture, resource >>>> interfaces/interfaces should be as general as possible. >>>> >>>> I agree with this principle in this specific case, mainly because >>>> handling a special message type for notify leads node software design >>>> to a more complex architecture. >>>> >>>> The reason is that this new message type requires special handling and >>>> introduces a complexity in the software modularization. >>>> >>>> Best, >>>> Angelo >>>> >>>> On Fri, May 14, 2010 at 13:06, Zach Shelby wrote: >>>> >>>> >>>> Hi Angelo, >>>> >>>> On May 13, 2010, at 14:24 , Angelo P. Castellani wrote: >>>> >>>> >>>> >>>> Dear C. Bormann, all, >>>> >>>> before deciding for the final direction, I've the following >>>> observations about draft-shelby-core-coap-01 >>>> >>>> While I mostly share Zach's view of the protocol approach, and >>>> appreciate many aspects of the proposal, there are in my opinion >>>> >>>> >>>> still >>>> >>>> >>>> some open issues that need to be at least discussed before the >>>> >>>> >>>> current >>>> >>>> >>>> document can be selected. >>>> >>>> >>>> Of course there are plenty of open issues. Remember that working group >>>> >>>> >>>> documents still undertake as much change and improvement as the WG >>>> wants, so by no means is coap-01 set in stone. I would expect at least >>>> 5-10 more revisions still along the way. Already several of your ideas >>>> have been integrated into coap-01, and several more are under >>>> consideration, so it is coming along. Patience ;-) >>>> >>>> >>>> >>>> In particular, I would like to highlight the following: >>>> >>>> a) As it is now, it is not possible to have a straightforward >>>> translation of HTTP -> CoAP and viceversa: see >>>> http://www.ietf.org/mail-archive/web/core/current/msg00133.html (this >>>> impacts the scalability of the web service model too) >>>> >>>> >>>> In coap-01 the Method names are now identical to HTTP methods. The >>>> >>>> >>>> Req/Res interaction is a direct translation. The URI hierarchy is >>>> compatible, and the URI binary code format we are still working on >>>> obviously. The only thing that takes some state to translate is >>>> Subscribe/Notify. But note, Subscribe/Notify takes some state no matte= r >>>> how you do it, even with HTTP-HTTP there is no clean and easy way to >>>> handle subscriptions. >>>> >>>> >>>> >>>> b) Moreover, CoAP's implementation is not as simple as it should be. >>>> I've investigated the implementation and some design choices (as >>>> Options) are leading to very high program complexity (ROM) on a >>>> MSP430-based device. >>>> >>>> >>>> This we can definitely improve, and already made several optimizations >>>> >>>> >>>> from -00 to -01. Here I need some very concrete proposals though. Also >>>> remember that many things are optional, for example subscribe/notify i= s >>>> not required if you don't need it. >>>> >>>> >>>> >>>> c) Finally when comparing HTTP message size with CoAP message size, >>>> the resulting compression isn't as good as you may expect. >>>> >>>> Example: >>>> HTTP: GET /sensor/temp.xml HTTP/1.0 =3D 32 B >>>> CoAP: 24 B with options parsing procedure requiring an added >>>> implementation complexity >>>> >>>> >>>> Right, that is not how it will work in practice. Working with a real >>>> >>>> >>>> HTTP server that HTTP header will be more complex, and on the CoAP sid= e >>>> you would chose shorter URLs. The biggest improvement possible here is >>>> from using binary coded URLs of course. We need to look at a wider ran= ge >>>> of interactions and real HTTP headers as well to check that we are >>>> efficient enough. >>>> >>>> >>>> >>>> Addressing all these points potentially leads to major technical >>>> modifications (especially point a) on the current draft, hence it is >>>> appropriate in my opinion to discuss these points before making the >>>> final decision. >>>> >>>> >>>> I am not sure what else you have in mind for a). If we just forget >>>> >>>> >>>> about Subscribe/Notify then you are good to go. But then you are also >>>> not fulfilling the charter or the industry needs in that respect. >>>> >>>> >>>> Thanks, >>>> Zach >>>> >>>> >>>> >>>> Best regards, >>>> >>>> Angelo P. Castellani >>>> >>>> >>>> On Mon, May 10, 2010 at 18:51, Carsten Bormannwrote: >>>> >>>> >>>> The CORE WG has a milestone to select a WG document for CoAP in >>>> >>>> >>>> April: >>>> >>>> >>>> http://datatracker.ietf.org/wg/core/charter/ >>>> ... >>>> Apr 2010 Select WG document for basis of the CoAP protocol >>>> >>>> Of the various documents that have been contributed, >>>> >>>> >>>> draft-shelby-core-coap has significant discussion, as well as the >>>> largest number of updates (including a previous version that was still >>>> called -6lowapp-coap). >>>> >>>> >>>> Today, another updated version of that draft was announced. See >>>> http://www.ietf.org/mail-archive/web/core/current/msg00138.html >>>> for the announcement and >>>> http://tools.ietf.org/html/draft-shelby-core-coap-01 >>>> for the draft itself. >>>> >>>> However, as the authors say, there are still significant TODOs. >>>> >>>> Are we in a state yet where we can say whether this is the right >>>> >>>> >>>> direction for the WG to take? >>>> >>>> >>>> If yes, is it the right direction? Should we adopt it as a WG >>>> >>>> >>>> document? >>>> >>>> >>>> If you don't think we can say yet, is there a set of technical >>>> >>>> >>>> decisions you would like the authors to take with priority? >>>> >>>> >>>> Note that once a document has become a WG document, the authors act >>>> >>>> >>>> as editors for the working group, making (and usually fleshing out the >>>> details of) any change that the WG decides it needs. >>>> >>>> >>>> If you think we can still improve the draft, this is not an obstacle >>>> >>>> >>>> to making it a WG document. >>>> >>>> >>>> But of course we shouldn't do that if we intend to reverse its >>>> >>>> >>>> fundamental technical direction. >>>> >>>> >>>> In order to stay roughly in sync with our milestones, we should >>>> >>>> >>>> reach at a decision on how to go forward this week. >>>> >>>> >>>> Gruesse, Carsten >>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>> >>>> >>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>> >>>> >>>> -- >>>> Zach Shelby, Chief Nerd, Sensinode Ltd. >>>> http://zachshelby.org - My blog "On the Internet of Things" >>>> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" >>>> Mobile: +358 40 7796297 >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>> >>>> -------------------------------- >>>> Onzo is a limited company number 06097997 registered in England& Wales= . The >>>> registered office is 6 Great Newport Street, London, WC2H 7JB, United = Kingdom. >>>> >>>> This email message may contain confidential and/or privileged informat= ion, and >>>> is intended solely for the addressee(s). If you have received this ema= il in >>>> error, please notify Onzo immediately. Unauthorised copying, disclosur= e or >>>> distribution of the material in this email is forbidden. >>>> -------------------------------- >>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>> >>>> ______________________________________________________________________ >>>> This email has been scanned by the MessageLabs Email Security System. >>>> ______________________________________________________________________ >>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>> >>>> >>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>> >>>> -------------------------------- >>>> Onzo is a limited company number 06097997 registered in England& Wales= . The >>>> registered office is 6 Great Newport Street, London, WC2H 7JB, United = Kingdom. >>>> >>>> This email message may contain confidential and/or privileged informat= ion, and >>>> is intended solely for the addressee(s). If you have received this ema= il in >>>> error, please notify Onzo immediately. Unauthorised copying, disclosur= e or >>>> distribution of the material in this email is forbidden. >>>> -------------------------------- >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>> >>>> >>>> >>>> ______________________________________________________________________ >>>> This email has been scanned by the MessageLabs Email Security System. >>>> ______________________________________________________________________= _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>> >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>> >>> -- >>> Zach Shelby, Chief Nerd, Sensinode Ltd. >>> http://zachshelby.org =A0- 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 >>> > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org =A0- My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > >